Pod IP, ClusterIP ou équilibreur interne pour les utilisateurs VPN
Une Pod IP est routable via le VPN jusqu’au remplacement du Pod. Comparez l’accès direct au Pod, ClusterIP et un équilibreur interne, et ce que chacun vous coûte.
Avec le VPC CNI, un Pod peut détenir une adresse du VPC, et un utilisateur VPN disposant de la bonne route peut l’atteindre directement. Cela donne à l’accès direct au Pod l’air de l’option la plus simple, et il l’est, jusqu’au remplacement du Pod. L’adresse dont un utilisateur se souvient devrait appartenir à l’application, pas à une réplique. Comparer les trois entrées revient à savoir quel objet possède l’adresse et ce qui doit continuer de fonctionner lorsque la charge de travail se déplace.
Choisissez d’abord selon le cycle de vie, ensuite selon ce que le réseau doit faire pour rendre l’entrée joignable.
Trois entrées, trois durées de vie
Une Pod IP appartient à un Pod : elle est allouée avec lui et libérée lorsqu’il se termine. Une ClusterIP appartient à un Service et est virtuelle, elle n’a de sens que là où le routage des services du cluster existe. Un équilibreur interne appartient à une ressource cloud que le contrôleur du cluster programme avec des backends. Ces modèles de propriété prédisent la panne que vous obtiendrez : une adresse périmée, un nom injoignable ou un ensemble de backends obsolète.
Écrivez la comparaison avant de choisir. Une fois le propriétaire et la panne nommés, le choix se fait généralement de lui-même.
| Entry | Owner | Failure when the workload moves |
|---|---|---|
| Pod IP | The Pod | Address changes and saved links break |
| ClusterIP | The Service | Virtual address with no meaning outside cluster routing |
| Internal balancer | Cloud resource plus controller | Backends update, but the DNS view is yours to maintain |
Accès direct au Pod : utile, temporaire
L’accès direct est réellement utile pour un contrôle encadré : un administrateur, une session courte, un port précis. Mais c’est un mauvais contrat pour les utilisateurs, car l’adresse est un détail d’implémentation qui change à chaque déploiement. Et en consigner une dans un wiki, c’est ainsi qu’un service qui fonctionne devient une rumeur.
Il invite aussi à des règles larges. L’autorisation pour un administrateur d’atteindre un Pod n’est pas une autorisation pour chaque adresse du sous-réseau du nœud, et c’est la seconde qui est généralement écrite.
ClusterIP : limité au cluster par conception
Une ClusterIP fonctionne parce que le plan de données du cluster programme le routage pour elle à l’intérieur du cluster. Depuis un ordinateur portable sur le VPN, l’adresse ne signifie rien à moins que quelque chose ne l’expose délibérément. Un nom se terminant par svc.cluster.local appartient au DNS du cluster, donc le copier sur un client doté d’un autre résolveur produit un nom qui n’existe pas plutôt qu’une erreur de routage.
ClusterIP reste la bonne entrée pour les appelants internes au cluster, y compris les autres charges de travail. Ce n’est simplement pas un mécanisme de publication pour les utilisateurs hors du domaine de routage du cluster.
Équilibreur interne : le chemin publié
Un équilibreur interne vous donne une adresse privée stable et un nom vers lequel votre propre zone peut pointer, tandis que le contrôleur maintient l’ensemble des backends à jour, comme le décrit le guide d’équilibrage de charge d’EKS. C’est l’entrée qui survit à un remplacement ordinaire de Pod sans que personne ne modifie un document. Elle coûte une ressource cloud, une configuration de contrôleur et une route depuis le VPN, et ce sont ces parties que les gens sous-estiment.
Utilisez le modèle de contrôleur que le cluster exécute réellement. Les annotations écrites pour une intégration ne s’appliquent pas à une autre.
Qui est l’adresse source
Les groupes de sécurité voient la source qui arrive à leur frontière, et celle-ci peut être le client connecté ou une adresse traduite selon le chemin VPN et d’équilibrage de charge. Sur les nœuds basés sur EC2, les Pods VPC CNI ordinaires héritent par défaut des groupes de l’ENI du nœud, tandis que les configurations prises en charge peuvent attacher des groupes propres au Pod. Écrivez des règles pour le chemin documenté plutôt que pour une adresse d’ordinateur portable supposée.
Gardez l’écouteur et l’authentification propres à l’application comme des contrôles distincts. Une règle réseau qui autorise le flux n’est pas une décision d’autorisation et ne doit pas être traitée comme telle.
Que remettre aux utilisateurs
Donnez aux utilisateurs un nom de service, pas une adresse. Publiez le nom dans la zone privée, pointez-le vers l’entrée interne, puis testez en remplaçant un Pod backend tandis qu’un client garde le même nom ouvert. Cet exercice vérifie la propriété qui compte : atteindre la même application après un déploiement de routine.
Gardez l’accès direct au Pod comme une exception opérationnelle documentée avec sa propre portée, loin des instructions destinées aux utilisateurs.