Exposer des applications avec des Services

Dans Kubernetes, les pods sont les plus petites unités déployables. Ils sont conçus pour être temporaires et peuvent être créés, détruits ou déplacés par Kubernetes à tout moment.

Cette flexibilité est excellente pour la résilience, mais elle pose un problème : comment les autres applications peuvent-elles trouver et contacter de manière fiable ces pods en constante évolution ?

Chaque pod possède sa propre adresse IP. Lorsqu’un pod redémarre ou change d’échelle, il obtient souvent une nouvelle adresse IP. Se connecter directement à l’adresse IP d’un pod revient à essayer d’atteindre une cible mouvante !

Imaginez une application web composée de plusieurs pods. Si l’un d’eux redémarre, son adresse IP change, ce qui interrompt les connexions des autres services ou des utilisateurs.

C’est là qu’interviennent les Services Kubernetes ! Un Service fournit un point d’accès réseau stable et fixe pour un ensemble de pods.

Considérez-le comme une adresse permanente pour votre application, même si les pods qui se trouvent derrière changent constamment d’adresse individuelle.

Un Service agit comme une couche d’abstraction au-dessus d’un groupe de pods. Il leur attribue une seule adresse IP et un seul nom DNS cohérents.

• Les autres applications utilisent l’adresse IP ou le nom stable du Service.
• Le Service achemine ensuite le trafic vers les pods sains qu’il gère.
• Cela dissocie les clients des adresses IP individuelles des pods.

Comment un Service sait-il vers quels pods acheminer le trafic ? Il utilise des étiquettes et des sélecteurs !

Lorsque vous définissez un Service, vous indiquez un selector. Tout pod correspondant à ces étiquettes est automatiquement intégré au groupe de ce Service.

Cette association dynamique signifie que les nouveaux pods sont automatiquement ajoutés et que les pods non sains sont supprimés.

Les Services gèrent la circulation du trafic réseau. Ils définissent des ports pour associer les requêtes entrantes aux ports appropriés de vos pods.

Concepts clés liés aux ports :

• port : le port sur lequel le Service lui-même est à l’écoute.
• targetPort : le port du pod vers lequel le Service achemine le trafic.

Comme la plupart des ressources Kubernetes, les Services sont définis à l’aide de fichiers YAML. Examinons leur structure de base :

• apiVersion : v1
• kind : Service
• metadata : nom, étiquettes
• spec : contient la définition principale, notamment selector et ports.

Le type de Service le plus courant pour les communications internes est ClusterIP. Il expose le Service sur une adresse IP interne au sein du cluster.

Voici un exemple d’application web simple :

Une fois votre YAML de Service prêt, vous pouvez le déployer dans votre cluster à l’aide de kubectl, comme pour les pods ou les Deployments.

Cette commande demande à Kubernetes de créer le Service à partir de votre définition :

Après son déploiement, votre Service obtient une adresse IP et un nom DNS stables au sein du cluster. Les autres pods peuvent désormais accéder à votre application en utilisant ce nom.

Par exemple, un autre pod pourrait se connecter à my-web-service:80, et le Service acheminerait le trafic vers les bons pods my-webapp.

Vous avez appris comment les Services Kubernetes fournissent un accès réseau stable à des pods dynamiques.

Laquelle des propositions suivantes décrit le mieux le rôle principal d’un Service Kubernetes ?

Bravo ! Dans cette leçon, nous avons étudié les Services Kubernetes.

• Les pods sont éphémères et possèdent des adresses IP dynamiques.
• Les Services fournissent des points d’accès réseau stables pour les pods.
• Ils utilisent des sélecteurs pour trouver les pods ciblés.
• Les Services associent le port externe au targetPort interne.
• ClusterIP est un type courant pour les communications internes.

Nous allons maintenant approfondir les différents types de Services et leurs utilisations !