Catégories
Start-up et applications

Comment Kubernetes illustre une application véritablement pilotée par API

Lorsque la plupart des gens pensent aux API, ils pensent à un point d'accès backend pour les interactions client-serveur dans une application distribuée. Dans de nombreuses situations, c'est en effet son but. Mais, une API peut être bien plus qu'une interface entre la logique côté serveur et les consommateurs publics de cette logique. Par exemple, il est tout à fait possible de faire en sorte qu'une couche API serve de centre de contrôle principal pour toute activité se déroulant à l'intérieur et à l'extérieur d'un domaine informatique. En d'autres termes, une couche API peut être le seul anneau qui les régit tous, ce qui est l'approche adoptée par Kubernetes.

Kubernetes, la technologie d'orchestration des charges de travail et des conteneurs créée par Google, mais maintenant maintenue par la Cloud Native Computing Foundation (CNCF), possède un composant appelé API Server qui contrôle une grande partie des activités à l'intérieur et à l'extérieur d'une installation Kubernetes. L'utilisation d'une API comme anneau unique pour régir l'intégralité d'une installation Kubernetes est une approche intéressante de la conception de système et mérite d'être étudiée.

Dans cet article, nous allons faire exactement cela. Nous allons examiner les bases de l'architecture Kubernetes, puis nous allons voir comment le serveur API contrôle les composants au sein de cette architecture. Enfin, nous allons voir comment rendre le serveur API d'une installation Kubernetes tolérant aux pannes.

Comprendre l'architecture de Kubernetes

Kubernetes a débuté chez Google en tant qu'outil interne appelé le système Borg. La première version de Kubernetes a été rendue publique en 2015. Elle a été remise à la CNCF en 2016 où elle est maintenue aujourd'hui. (La CNCF est le résultat d'un partenariat de collaboration entre Google et la Linux Foundation.) L'ensemble du code source de Kubernetes est disponible gratuitement sur GitHub, ce qui est tout à fait un cadeau compte tenu de la complexité de la technologie et des millions de dollars qu'elle doit avoir pris pour le développer.

Comme mentionné ci-dessus, Kubernetes est une technologie d'orchestration de charges de travail et de conteneurs. Ce qui rend Kubernetes si puissant, c'est qu'il est conçu pour gérer de très grandes applications qui s'exécutent à grande échelle. En règle générale, ces applications sont constituées de dizaines, de centaines, voire de milliers de composants faiblement couplés qui fonctionnent sur un ensemble de machines.

Un ensemble de machines exécutant des Kubernetes contrôlés est appelé un cluster. Un cluster Kubernetes peut être composé de dizaines, de centaines, voire de milliers de machines. Un cluster peut avoir n'importe quelle combinaison de machines réelles ou virtuelles

Le cluster comme unité de calcul

Les développeurs peuvent conceptualiser le cluster comme une seule unité de calcul. Un cluster Kubernetes peut être composé d'une centaine de machines, mais le développeur ne sait presque rien de la composition du cluster sous-jacent. Tous les travaux sont menés en termes de cluster Kubernetes en tant qu'abstraction. Masquer les éléments internes de la dynamique de cluster est important car un cluster Kubernetes est éphémère. Kubernetes est conçu pour que la composition du cluster puisse changer à tout moment, mais une telle modification interfère avec le fonctionnement des applications exécutées sur le cluster. L'ajout d'une machine à un Kubernetes n'affecte pas les applications exécutées sur le cluster. La même chose est vraie lorsqu'une machine est supprimée du cluster.

Tout comme un cluster Kubernetes peut faire évoluer les machines à la demande, il en va de même pour une application exécutée sur le cluster. Toute cette activité est complètement opaque. Les applications du cluster ainsi que les services et autres applications utilisant le cluster ne savent rien des composants internes du cluster. À toutes fins utiles, un cluster Kubernetes peut se comporter comme un très, très gros ordinateur.

La nature éphémère de Kubernetes en fait un paradigme informatique très puissant. Mais, avec un tel pouvoir vient une grande complexité. Kubernetes a beaucoup de pièces mobiles qui doivent être gérées. C'est là que le serveur API, dont nous parlerons dans un instant, entre en jeu. Mais examinons d'abord les composants qui composent un cluster Kubernetes.

Conteneurs et pods

L'unité de base de la logique de calcul dans Kubernetes est le conteneur Linux. Vous pouvez considérer un conteneur comme une couche d'abstraction qui fournit un moyen d'exécuter un processus sur un ordinateur d'une manière qui isole virtuellement le processus de tous les autres processus.

Par exemple, vous pouvez avoir un certain nombre de serveurs Web Nginx s'exécutant simultanément, de manière isolée, sur une seule machine en exécutant chaque instance Nginx dans un conteneur. Chaque conteneur peut avoir ses propres allocations de CPU, de mémoire et de stockage. Et bien qu'un conteneur "partagera" des ressources dans le système d'exploitation hôte, le conteneur n'est pas étroitement lié au système d'exploitation hôte. Le conteneur pense avoir son propre système de fichiers et ses propres ressources réseau. Ainsi, si quelque chose ne va pas et que vous devez redémarrer ou détruire l'un des serveurs Nginx, il s'agit simplement de redémarrer ou de détruire le conteneur, ce qui, dans certains cas, ne prend pas plus d'une fraction de seconde. Si vous exécutiez ces serveurs Nginx directement sur la machine hôte sans l'intermédiation de la technologie de conteneur, la suppression et la réinstallation d'un hôte peuvent prendre quelques secondes, voire quelques minutes. Et, en cas de corruption du système de fichiers hôte, l'administration du correctif et le redémarrage de la machine hôte peuvent bien au-delà d'une minute ou deux.

L'isolement et la facilité d'administration ne sont que deux des raisons pour lesquelles les conteneurs sont si populaires et pourquoi ils sont fondamentaux pour Kubernetes.

Un développeur programme un élément de logique hébergé dans un conteneur. Par exemple, la logique pourrait être une sorte d'algorithme d'intelligence artificielle écrit en GoLang. Ou bien, la logique pourrait être du code Node.js qui accède aux données d'une base de données et les transforme en JSON qui est renvoyé à l'appelant. Les possibilités de la logique qui peut être hébergée dans un conteneur sont infinies.

Kubernetes organise un ou plusieurs conteneurs dans une unité d'abstraction appelée pod. Le nom, pod, est spécial pour Kubernetes. Un pod présente son ou ses conteneurs au cluster Kubernetes. L'accès à la logique d'un pod s'effectue via un service Kubernetes. (Voir la figure 1 ci-dessous.)

Figure 1: Dans Kubernetes, un pod contient la logique qui est représentée par un service associé

Figure 1: Dans Kubernetes, un pod contient la logique représentée par un service associé

Les services représentent la logique du ou des pod (s) sur le réseau. Regardons comment la représentation est facilitée.

Comprendre les services et les pods

Les développeurs ou les administrateurs Kubernetes configurent le service pour le lier à des pods qui ont la logique appropriée. À toutes fins utiles, un service représente la «logique du pod» pour les autres services internes au cluster Kubernetes et aux utilisateurs et programmes externes au cluster Kubernetes.

Kubernetes utilise l'étiquetage pour lier un service à un ou plusieurs pods. Les libellés sont essentiels à la manière dont les services et les pods sont décrits dans Kubernetes.

Il existe deux façons de créer un service ou un pod dans Kubernetes. Une façon consiste à utiliser le client Kubernetes nommé kubectl pour appeler la création d'un pod ou d'un service directement sur la ligne de commande. Le listing 1 ci-dessous montre un exemple d'utilisation de kubectl pour créer un pod.

kubectl run pinger --image=reselbob/pinger --port=3000

Liste 1: Création d'un pod nommé pinger qui utilise l'image du conteneur Docker, reselbob / pinger

Le listing 2 montre comment utiliser kubectl en ligne de commande pour créer un service qui utilise le pod créé ci-dessus dans le listing 1.

kubectl expose pod pinger --name=myservice --port=3000 --target-port=3000

Liste 2: Création d'un service nommé myservice qui écoute sur le port 8001 et est lié à un pod nommé pinger

En utilisant kubectl sur la ligne de commande pour créer des pods et des services est appelée la méthode impérative. Bien que la méthode impérative soit utile pour expérimenter avec Kubernetes, au niveau professionnel, l'ajout manuel de pods et de services à un cluster est mal vu. Au contraire, la méthode préférée consiste à utiliser la méthode déclarative plus programmatique.

La méthode déclarative est celle dans laquelle un développeur ou un administrateur crée une configuration appelée fichier manifeste qui décrit le pod ou le service donné. (En règle générale, un fichier manifeste est écrit en YAML, bien que JSON puisse également être utilisé.) Ensuite, le développeur, l'administrateur ou un type de script d'automatisation utilise le kubectl sous-commande appliquer au paramètre de configuration Appliquer dans le fichier manifeste au cluster. Le listing 3 ci-dessous montre un fichier manifeste avec le nom arbitraire, mon_pod.yaml, qui créera le pod pinger tel que créé précédemment en utilisant la méthode impérative.

Listing 3: Le fichier manifeste pour créer un pod contenant le conteneur, pinger

Liste 3: Le fichier manifeste pour créer un pod contenant le conteneur, pinger

Une fois le fichier manifeste défini, nous pouvons créer le pod de manière déclarative comme suit:

kubectl apply -f ./my_pod.yaml

Une fois le pod créé, nous créons ensuite un fichier manifeste avec le nom arbitraire, pinger_service.yaml, comme indiqué dans le listing 4 ci-dessous:

Listing 4: Le fichier manifeste qui définit un service qui est lié aux pods qui ont les étiquettes, app: pinger et purpose: demo

Liste 4: Le fichier manifeste qui définit un service lié aux pods qui ont les étiquettes, app: pinger et purpose: demo

Pour créer le service, pinger_service dans le cluster Kubernetes, nous appliquons le fichier manifeste comme suit:

kubectl apply -f ./my_service.yaml

Pourtant, la question en suspens est de savoir comment le service, pinger_service se lient réellement au pod, pinger_pod. C'est là que l'étiquetage entre en jeu.

Notez les lignes 5 à 7 de la liste 3 qui décrivent le fichier manifeste du pod. Vous verrez l'entrée suivante:

  labels:
    app: pinger
    purpose: demo

Ces lignes indiquent que le pod a été configuré avec les deux étiquettes en tant que paires clé et valeur. Une étiquette est app, avec la valeur pinger. L'autre étiquette est le but avec la valeur, demo. Le terme "Étiquettes"est un mot réservé Kubernetes. Cependant, les libellés app: pinger et objectif: les démos sont complètement arbitraires.

Les étiquettes Kubernetes sont importantes car elles permettent d'identifier le pod au sein du cluster. En fait, le service utilisera ces étiquettes comme mécanisme de liaison.

Jetez un œil aux lignes 5 à 8 du listing 4 qui décrit le fichier manifeste du service. Vous verrez l'entrée suivante:

  selector:
    app: pinger
    purpose: demo

Le terme "sélecteur"est un mot réservé Kubernetes qui indique les étiquettes par lesquelles le service se liera aux pods constituants. N'oubliez pas que le fichier manifeste, mon_pod.yaml ci-dessus publie deux étiquettes, application: pinger et but: démo. Les sélecteurs définis dans mon_service.yaml faire agir le service s'il dit, "Je suis configuré pour sortir dans le cluster et rechercher tous les pods portant les étiquettes application: pinger et but: démo. J'acheminerai tout trafic entrant en moi sur ces pods. "

Certes, la déclaration de recherche analogique faite par le service ci-dessus est simpliste. Il y a beaucoup de travail qui se passe sous les couvertures en termes de découverte de l'adresse IP d'un pod et d'équilibrage de charge par rapport à un ensemble de répliques de pod pour faire fonctionner le routage du service vers le pod. Toujours utiliser des étiquettes est la façon dont Kubernetes lie un ou plusieurs pod (s) à un service. Cela peut être simple, mais cela fonctionne même à l'échelle du Web!

La nature éphémère de Kubernetes

Comprendre les relations entre les conteneurs, les pods et les services est essentiel pour travailler avec Kubernetes, mais il y a plus. N'oubliez pas que Kubernetes est un environnement éphémère. Cela signifie que non seulement des machines peuvent être ajoutées et supprimées du cluster à la demande, mais aussi des conteneurs, des pods et des services. Comme vous pouvez l'imaginer, maintenir le cluster opérationnel et fonctionner correctement nécessite une énorme quantité de gestion d'état, comme vous le verrez lorsque nous le décrirons dans un scénario à venir qui illustre les aspects éphémères de Kubernetes. (Dans ce scénario, nous allons créer plusieurs pods garantis par Kubernetes pour toujours s'exécuter, même en cas de problème avec la machine hôte ou avec les pods eux-mêmes.)

En plus des conteneurs, des pods et des services, il existe de nombreuses autres ressources – réelles, virtuelles et logiques – qui peuvent s'exécuter dans un cluster Kubernetes. Par exemple, il existe des ConfigMaps, des Secrets, des ReplicaSets, des déploiements et des espaces de noms pour n'en citer que quelques-uns. (Allez ici pour lire la documentation complète des ressources de l'API Kubernetes.)

La chose importante à comprendre est qu'il peut y avoir des centaines, voire des milliers de ressources en jeu sur n'importe quel cluster Kubernetes à tout moment. Les ressources agissent de concert et changent d'état en permanence.

Voici un exemple d'une seule instance d'un état de changement de ressource. Lorsqu'un pod créé par un déploiement Kubernetes échoue, il sera réapprovisionné automatiquement par Kubernetes. (Vous lirez les détails d'un déploiement Kubernetes dans la section suivante.) Le nouveau pod peut être réapprovisionné sur la même machine virtuelle (également appelée "nœud") que celle qui échoue ou peut être entièrement réapprovisionné sur une machine virtuelle nouvellement provisionnée . Kubernetes gardera une trace de tous les détails qui accompagnent le réapprovisionnement: adresse IP de la machine hôte, adresse IP du pod lui-même et déploiement de Kubernetes contrôlant le pod, pour ne citer que quelques-uns des détails suivis. Tous les détails associés aux pods, au déploiement, aux services utilisant les pods et aux nœuds hébergeant les pods sont considérés comme faisant partie de l'état du cluster.

Comme vous pouvez le voir, le simple fait de déplacer un pod d'un nœud à un autre est un changement d'état significatif dans le cluster. Cette action n'est que l'un des centaines de changements d'état qui peuvent se produire à un moment donné. Pourtant, Kubernetes sait tout ce qui se passe dans le cluster, tout le temps, sur l'intégralité du réseau sur lequel le cluster s'exécute. La question est, comment? La réponse est dans le plan de contrôle.

Comprendre le plan de contrôle Kubernetes

Comme mentionné ci-dessus, Kubernetes est conçu pour prendre en charge les applications distribuées qui sont réparties sur un certain nombre de machines, réelles ou virtuelles. Les machines peuvent être situées dans le même centre de données. Il est tout aussi possible que la collection de machines qui composent le cluster soit distribuée dans une région informatique nationale ou même dans le monde entier. Kubernetes est conçu pour prendre en charge ce niveau de distribution.

Dans le langage de Kubernetes, une machine est appelée un nœud. Dans un cluster Kubernetes, il existe deux types de nœuds. Il y a le nœud de contrôleur et il y a les nœuds de travail. Le nœud de contrôleur fait comme son nom l'indique. Il contrôle les activités dans le cluster et coordonne les activités entre les nœuds de travail. Les nœuds de travail sont comme leur nom l'indique; ils effectuent le travail réel de l'exécution des conteneurs, des pods et des services.

Le nœud de contrôleur contient un certain nombre de composants nécessaires pour maintenir le cluster opérationnel et gérer l'état en constante évolution du cluster. Ces composants constituent ce qu'on appelle le «plan de contrôle». (Voir la figure 2 ci-dessous)

Figure 2: L'architecture de base d'un cluster Kubernetes

Figure 2: L'architecture de base d'un cluster Kubernetes

Le tableau 1 ci-dessous décrit les composants du nœud de contrôle et des nœuds de travail. Pour une discussion plus approfondie, vous pouvez lire la documentation Kubernetes qui décrit le plan de contrôle et les composants installés sur chaque nœud worker, ici.

Composant Emplacement Objectif
Serveur API Nœud de contrôleur Le serveur API est l'interface principale dans un cluster Kubernetes et pour les composants au sein du cluster Kubernetes donné. C'est un ensemble d'opérations REST pour créer, mettre à jour et supprimer des ressources Kubernetes au sein du cluster. En outre, l'API publie un ensemble de points de terminaison qui permettent aux composants, services et administrateurs de «surveiller» les activités du cluster de manière asynchrone.
etcd Nœud de contrôleur etcd est la technologie de base de données interne utilisée par Kubernetes pour stocker des informations sur toutes les ressources et tous les composants qui sont opérationnels au sein du cluster.
Planificateur Nœud de contrôleur Le planificateur est le composant Kubernetes qui identifie un nœud comme étant l'emplacement hôte où un pod sera créé et exécuté dans le cluster. Scheduler ne crée PAS le conteneur associé à un pod. Le planificateur informe le serveur API qu'un nœud hôte a été identifié. Le composant kubelet sur le nœud worker identifié effectue le travail de création du ou des conteneurs du pod donné.
Gestionnaire de contrôleur Nœud de contrôleur Le Controller Manager est un composant de haut niveau qui contrôle les ressources de contrôleur constitutives qui sont opérationnelles dans un cluster Kubernetes. Des exemples de contrôleurs subordonnés au Controller Manager sont le contrôleur de réplication, le contrôleur de points de terminaison qui lie les services aux pods, le contrôleur d'espace de noms et le contrôleur serviceaccounts.
kubelet Nœud de travail kubelet interagit avec le serveur API dans le nœud de contrôleur pour créer et maintenir l'état des pods sur le nœud dans lequel il est installé. Chaque nœud d'un cluster Kubernetes exécute une instance de kubelet.
Kube-Proxy Nœud de travail Kube-proxy effectue l'activité de gestion du réseau Kubernetes sur le nœud sur lequel il est installé. Chaque nœud d'un cluster Kubernetes exécute une instance de Kube-proxy. Kube-proxy fournit la découverte de services, le routage et l'équilibrage de charge entre les demandes réseau et les points de terminaison de conteneur.
Interface d'exécution du conteneur Nœud de travail Le Container Runtime Interface (CRI) fonctionne avec kubelet pour créer et détruire des conteneurs sur le nœud. Kubernetes est agnostique en termes de technologie utilisée pour réaliser des conteneurs. Le CRI fournit la couche d'abstraction requise pour permettre à kubelet de fonctionner avec n'importe quel environnement d'exécution de conteneur opérationnel dans le nœud.
Runtime du conteneur Nœud de travail Le Container Runtime est la technologie de démon de conteneur en vigueur dans le nœud. Le Container Runtime effectue le travail de création et de destruction de conteneurs sur un nœud. Des exemples de technologies Container Runtime sont Docker, containerd et CRI-O, pour ne citer que les plus populaires.

Le serveur API comme point de commande central

Comme mentionné ci-dessus, Kubernetes adopte une approche «un anneau pour les gouverner tous» pour la gestion des clusters et que «un anneau» est un serveur API. En général, tous les composants qui gèrent un cluster Kubernetes communiquent uniquement avec le serveur API. Ils ne communiquent pas entre eux. Voyons comment cela fonctionne.

Imaginez un administrateur Kubernetes qui souhaite provisionner 3 pods identiques dans un cluster afin d'avoir une redondance de sécurité. L'administrateur crée un fichier manifeste qui définit la configuration d'un déploiement Kubernetes. Un déploiement est une ressource Kubernetes qui représente un ReplicSet de pods identiques garantis par Kubernetes pour tous s'exécuter en permanence. Le nombre de pods dans le ReplicaSet est défini lors de la création du déploiement. Un exemple de fichier manifeste qui définit un tel déploiement est présenté ci-dessous dans le listing 5. Notez que le déploiement a 3 pods dans lesquels chaque pod a un conteneur exécutant un serveur Web Nginx.

--
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Liste 5: Un fichier manifeste qui crée 3 pods avec chaque pod hébergeant un conteneur Nginx.

Une fois que l'administrateur Kubernetes a créé le fichier manifeste pour le déploiement, l'administrateur le soumet au serveur API en appelant l'outil CLI client Kubernetes, kubectl comme ceci:

kubectl apply -f mydeployment.yaml

  • kubectl est l'outil de ligne de commande Kubernetes pour interagir avec le serveur API
  • appliquer est la sous-commande utilisée pour soumettre le contenu du fichier manifeste au serveur API
  • -F est l'option qui indique que les informations de configuration sont stockées dans un fichier en fonction du nom de fichier qui suit
  • mydeployment.yaml est le nom de fichier fictif utilisé à des fins d'exemple contenant les informations de configuration pertinentes pour la ressource Kubernetes en cours de création

kubectl envoie les informations du fichier manifeste au serveur API via HTTP. Le serveur API notifie ensuite les composants nécessaires pour terminer l'approvisionnement. C'est là que commence la véritable action.

Anatomie de la création de pod Kubernetes

La figure 3 ci-dessous illustre le travail effectué lorsqu'un administrateur crée une ressource Kubernetes à l'aide de kubectl outil de ligne de commande. (Dans ce cas, l'administrateur crée un déploiement Kubernetes.) Les détails de l'illustration démontrent le rôle central que joue le serveur API dans un cluster Kubernetes en général et le plan de contrôle en particulier. Jetons un œil aux détails.

Figure 3: Le processus de création de pods dans un déploiement Kubernetes à l'aide de kubectl

Figure 3: Le processus de création de pods dans un déploiement Kubernetes à l'aide de kubectl

Dans le scénario ci-dessus de la figure 3 à Callout (1), un administrateur Kubernetes soumet le contenu d'un fichier manifeste au serveur API s'exécutant sur un cluster Kuberentes en entrant, kubectl apply -f mon déploiement.yaml à l'invite de commande. (Le contenu du fichier manifeste est affiché ci-dessus à la liste 5.) Le serveur API entre les informations de configuration sur le déploiement dans etcd (Légende 2). etcd est la base de données interne qui stocke toutes les informations d'état sur tout ce qui se trouve dans le cluster. Dans ce cas, les informations sur le déploiement et le nombre de réplicas de pod requis sont stockées dans etcd. En outre, les informations de modèle sur lesquelles les pods du déploiement seront configurés sont également stockées.

Une fois les informations de déploiement stockées dans etcd, le serveur API notifie au planificateur de trouver des nœuds pour héberger les pods définis par le déploiement. (Légende 3) Le planificateur trouvera les nœuds qui répondent aux exigences des pods. Par exemple, les pods peuvent nécessiter un nœud qui a un type spécial de CPU ou une configuration particulière de mémoire. Le planificateur connaît les détails de tous les nœuds du cluster et trouvera les nœuds qui répondent aux exigences du pod. (N'oubliez pas que les informations sur chaque nœud du cluster sont stockées dans etcd.)

Le planificateur identifie un ou plusieurs nœuds hôtes pour le déploiement et renvoie ces informations au serveur API. (Légende 4) Le planificateur ne crée AUCUN pod ou conteneur sur le nœud. C'est le travail de kubelet.

Outre la publication d'une interface HTTP REST typique, le serveur API dispose également de points de terminaison asynchrones qui agissent comme des files d'attente dans un courtier de messages PubSub. Chaque nœud d'un cluster Kubernetes exécute une instance de kubelet. Chaque instance de kubelet "écoute" le serveur API. Le serveur API enverra un message annonçant une demande de création et de configuration d'un ou de plusieurs conteneurs sur un nœud Kubernetes particulier. L'instance kubelet s'exécutant sur le nœud concerné récupère ce message dans la file d'attente de messages du serveur API et crée le (s) conteneur (s) conformément à la spécification fournie. (Callout 5) kubelet crée des conteneurs en interagissant avec le Container Runtime Interface (CRI) décrit ci-dessus dans le tableau 1. Le CRI est lié au moteur d'exécution de conteneur spécifique installé sur le nœud.

kubelet envoie les informations d'état du serveur API indiquant que le ou les conteneurs ont été créés avec des informations sur la configuration du ou des conteneurs. À ce stade, kubelet gardera le conteneur sain et informera le serveur API en cas de problème.

Comme vous pouvez le voir, le serveur API est en effet le seul anneau qui les régit tous dans un cluster Kubernetes. Pourtant, le fait d'avoir le serveur API au cœur d'une grande partie de l'activité de traitement critique qui a lieu sur le cluster crée un point de risque de défaillance unique. Que se passe-t-il si le serveur API tombe en panne? Si vous êtes une entreprise telle que Netflix, ce n'est pas un problème trivial. C'est catastrophique. Heureusement, le problème est résolu en utilisant des répliques de nœuds de contrôleur.

S'assurer que le serveur API est toujours disponible

Comme mentionné ci-dessus, Kubernetes garantit la haute disponibilité du serveur API en utilisant des répliques de nœuds de contrôleur. Il s'agit de l'équivalent analogique de la création de réplicas de pod dans un déploiement Kubernetes. Seulement, au lieu de répliquer des pods, vous répliquez des nœuds de contrôleur. Tous les nœuds de contrôleur vivent derrière un équilibreur de charge et, par conséquent, le trafic est acheminé en conséquence.

La configuration d'un ensemble de répliques de nœuds de contrôleur nécessite du travail. Tout d'abord, vous allez installer kubelet, kubectl et kube-proxy et le runtime du conteneur sur chaque nœud du cluster, que le nœud soit un nœud de contrôleur ou un nœud de travail. Ensuite, vous devrez configurer un équilibreur de charge pour acheminer le trafic vers les différents nœuds de contrôleur, mais après cela, vous pouvez utiliser l'outil de ligne de commande Kubernetes, kubeadm pour configurer les nœuds en tant que contrôleur et les nœuds de travail en conséquence. Il y a du travail à faire pour s'assurer que tous les paramètres de configuration sont corrects sur la ligne de commande. Cela demande de l'attention, mais ce n'est pas un travail trop détaillé.

En termes de stockage d'état, etcd est toujours la seule autorité pour l'état du cluster. Dans une configuration de nœud à plusieurs contrôleurs, chaque instance de etcd sur la machine locale transfère les demandes de lecture et d'écriture sur un cluster partagé de serveurs etcd mis en place dans une configuration de quorum. Dans une configuration de quorum, une écriture dans la base de données se produit lorsqu'une majorité des serveurs etcd du cluster approuvent la modification.

La configuration d'un etcd dans une configuration de quorum dans laquelle sont répartis sur le réseau crée-t-il des problèmes de latence en termes de performances de lecture et d'écriture? Oui. Cependant, selon les responsables de Kubernetes, la période de latence entre les machines d'une même région Google Compute Engine est inférieure à 10 millisecondes. Néanmoins, lorsque vous effectuez des opérations extrêmement urgentes, il est sage de faire en sorte que toutes les machines du cluster se trouvent au moins dans le même centre de données, de manière optimale dans la même rangée de racks de serveurs dans le centre de données. Dans des situations extrêmement urgentes, la distance physique entre les machines compte!

Mettre tous ensemble

Les API deviennent la cheville ouvrière critique de l'architecture d'application moderne. Ils peuvent rendre les applications faciles à mettre à l'échelle et à maintenir. Pourtant, une API peut faire plus que d'être la représentation publique de la logique d'application pour les consommateurs côté client. Comme nous l'avons vu dans l'analyse que nous avons présentée dans cet article, Kubernetes API Server est un excellent exemple d'utilisation d'API pour contrôler tous les aspects opérationnels d'un système logiciel. Le serveur d'API Kubernetes fait bien plus que fournir des données. Il gère l'état du système, la création de ressources, la notification de modification ainsi que l'accès au système. C'est en effet le seul anneau qui les gouverne tous.

Le serveur d'API Kubernetes est une technologie complexe, sans aucun doute. Mais le fait que Kubernetes soit si largement utilisé dans tout le secteur renforce le style architectural d'utilisation des API comme centre de contrôle du système. L'utilisation d'une API comme approche un anneau à la règle pour la mise en œuvre de systèmes logiciels est une sensibilité de conception intelligente et mérite d'être prise en compte.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *