Maitriser la découverte automatique de services dans Kubernetes

Adresses IP uniques

En raison de l'architecture de l'outil d'orchestration, la découverte du service dans Kubernetes repose sur de multiples couches. Kubernetes instancie les conteneurs, regroupés en pods, sur des nœuds. Ensuite, ces pods sont regroupées en clusters, chaque nœud faisant tourner plusieurs clusters. Chaque pod de Kubernetes a une adresse IP unique et chaque pod a un réplica. Lorsqu'un pod est supprimé, son adresse IP est supprimée avec lui, et tout nouveau pod créé par Kubernetes est accompagné d'une nouvelle adresse IP unique. Les adresses IP jouent un rôle essentiel dans la gestion des tâches réseau, comme la découverte de services et l'équilibrage de charge.

Labels et sélecteurs

Kubernetes fournit de nombreuses adresses IP. Le système attribue des labels administrateur et des sélecteurs pour mieux organiser et gérer les pods à l'échelle. Ces labels permettent à l'administrateur du conteneur d’identifier facilement les composants du système et les sélecteurs facilitent la façon dont les utilisateurs regroupent et exécutent les actions sur les composants portant le même label. Les labels et les sélecteurs sont des paires clé/valeur de métadonnées qui ne font pas partie du système. Ils sont utilisés pour coupler « lâchement » des ressources comme les pods.

Les labels et les sélecteurs permettent également de gérer les pods qui servent à différents aspects de la livraison logicielle. Par exemple, on peut utiliser des labels et des sélecteurs pour organiser différents types de déploiements, le même déploiement sur plusieurs environnements ou même avec des données client différentes. Par exemple, un déploiement de microservices est étiqueté (labelled) en trois versions : stable, alpha et bêta. Ces nombreuses utilisations des labels et des sélecteurs de Kubernetes facilitent la découverte de services.

Contrôleurs de réplica

Le contrôleur de réplica de Kubernetes contrôle quant à lui la façon dont l'outil crée et supprime automatiquement les pods et leurs réplicas. Il vise à maintenir la haute disponibilité des ressources à tout moment. Le contrôleur de réplica reconnaît les labels et les sélecteurs et effectue des opérations sur les pods sur la base des données entrées. Ces informations sont ensuite placées dans un fichier YAML et peuvent définir n'importe quels pods. Comme les labels ont un couplage lâche, elles existent indépendamment des contrôleurs de réplica. Même si ces contrôleurs sont remplacés, les labels restent bien accessibles. Ces labels apportent de la cohérence à un système autrement dynamique.

Variables d'environnement et DNS

Deux méthodes principales existent en matière de découverte de services avec Kubernetes : via les variables d'environnement et via le système de noms de domaine (DNS).

Une variable d'environnement - aussi appelée envar - définit comment le pod est nommé. Ce nom est indiqué dans un champ du fichier de configuration du pod. Grâce aux variables d'environnement, il est facile d'identifier chaque pod, individuellement. On est assuré que chaque pod a donc été découvert. Placez les variables d'environnement non seulement au niveau du pod, mais aussi au niveau du conteneur. Exécutez la commande printenv pour afficher une liste de toutes les variables d'environnement.

La deuxième option pour la découverte de service est le DNS. Kubernetes attribue en effet un DNS à chaque service. Il utilise SkyDNS pour cela.

Chaque service doit être exposé à d'autres services dans Kubernetes - ce qui peut se produire de plusieurs façons. L’orchestrateur attribue à chaque service une IP de cluster, qui restera la même pendant toute la durée de vie du service. Une IP de cluster est visible en interne à tous les pods sur le même cluster, et chaque service a une IP de cluster par défaut.

Pour rendre le service visible de l'extérieur, il  convient d’utiliser un port du nœud. Cette connexion expose le service à l'adresse IP du nœud. Cette approche est utile si vous devez mettre en place la découverte de services sur une plateforme qui ne supporte pas nativement Kubernetes.

Une autre façon d'exposer les services est d'utiliser un load balancer proposé par un fournisseur de cloud. Tous ont leur propre version d'un répartiteur de charge, et tous se comportent de la même façon en s'assurant que les services peuvent être découverts par d'autres et que la charge est partagée entre les services d'une manière contrôlée.

Les requêtes DNS peuvent être contrôlées en assignant des politiques précises pour chaque pod. Par défaut, un pod hérite de ses propriétés DNS à partir du nœud sur lequel il tourne. Cependant, la politique DNS ClusterFirst de Kubernetes permet de personnaliser les sous-domaines - zones DNS privées - et les serveurs DNS. Alternativement, le fait de fixer la politique DNS à « Aucune » (None) garantit que les politiques doivent être fournies au niveau des pods manuellement, au lieu de les hériter de l'environnement Kubernetes.

Avec  les valeurs par défaut du système, les options de découverte de services de Kubernetes vont de la personnalisation à l'automatisation. Des fonctionnalités telles que des adresses IP uniques, des labels et des sélecteurs, des contrôleurs de réplica, des variables d'environnement et des paramètres DNS permettent de contrôler finement la découverte de services, mais présentent également un degré de complexité supplémentaire pour qui a à gérer les déploiements.