Guide Kubernetes, Partie 2: Création et utilisation d'un cluster

La dernière fois, nous avons examiné deux approches pour travailler avec des microservices. En particulier, l'un d'eux implique l'utilisation de conteneurs Docker, dans lesquels vous pouvez exécuter le code des microservices et des programmes auxiliaires. Aujourd'hui, en utilisant nos images de conteneurs existantes, nous travaillerons avec Kubernetes.

Présentation de Kubernetes

Je promets, et je n'exagère pas du tout que lorsque vous lisez cet article, demandez-vous: "Pourquoi les Kubernetes ne s'appellent-ils pas Supernetes?"


Supernetes

Si vous lisez la partie précédente de ce document, vous savez que nous avons examiné beaucoup de choses liées à la préparation des demandes de conteneurisation et au travail avec les conteneurs Docker. Il peut vous sembler que la chose la plus difficile vous attend maintenant, mais, en fait, ce dont nous allons parler ici est beaucoup plus simple que ce que nous avons déjà compris. La seule raison pour laquelle l'apprentissage de Kubernetes peut sembler une tâche intimidante pour quelqu'un est la quantité d'informations supplémentaires dont vous avez besoin pour comprendre Kubernetes et l'utiliser efficacement. Nous avons déjà discuté de toutes les "informations supplémentaires" nécessaires au succès du développement de Kubernetes.

HatQu'est-ce que Kubernetes?

Dans la première partie de cet article, après avoir lancé des microservices dans des conteneurs, on vous a demandé de réfléchir à la question de la mise à l'échelle des applications conteneurisées.
Je propose d'y réfléchir ensemble, sous forme de questions et réponses:

Question: Comment les applications conteneurisées évoluent-elles?
Réponse: lancez des conteneurs supplémentaires.

Question: Et comment la charge est-elle répartie entre eux? Que faire si un certain serveur est déjà utilisé au maximum et que le conteneur doit être déployé sur un autre serveur? Comment trouver le moyen le plus efficace d'utiliser du matériel?
Réponse: Alors ... je vais regarder sur Internet ...

Question: Comment mettre à jour des programmes sans perturber le système? Et, si la mise à jour contient une erreur, comment revenir à la version de travail de l'application?

En fait, c'est la technologie Kubernetes qui donne des réponses valables à ces questions et à bien d'autres. Je vais essayer de limiter la définition de Kubernetes à une phrase: "Kubernetes est un système de gestion de conteneurs qui résume l'infrastructure sous-jacente (l'environnement dans lequel les conteneurs s'exécutent)."

Je pense que maintenant vous n'êtes pas particulièrement clair sur le concept de «gestion des conteneurs», même si nous l'avons déjà mentionné. Ci-dessous, nous considérerons cette technologie dans la pratique. Cependant, le concept «d'abstraire l'infrastructure de base» est d'abord rencontré. Par conséquent, nous allons maintenant l'examiner.

▍ Abstraction des infrastructures de base

Kubernetes permet aux applications de s'éloigner de l'infrastructure, nous donnant une API simple à laquelle vous pouvez envoyer des demandes. Kubernetes essaie de répondre à ces demandes en utilisant toutes ses capacités. Par exemple, dans une langue normale, une requête similaire peut être décrite comme suit: «Kubernetes, développez 4 conteneurs d'images X». Après avoir reçu la commande, Kubernetes trouvera des nœuds qui ne sont pas trop occupés (ils sont également appelés "nœuds" - de l'anglais "nœud"), sur lesquels vous pouvez déployer de nouveaux conteneurs.


Demande de serveur API

Qu'est-ce que cela signifie pour le développeur? Cela signifie qu'il n'a pas besoin de se soucier du nombre de nœuds, de l'endroit exact où les conteneurs sont lancés ou de la façon dont ils interagissent. Il n'a pas à gérer l'optimisation matérielle ni à s'inquiéter des nœuds qui pourraient mal fonctionner (et quelque chose de similaire, selon la loi de Murphy, se produira certainement), car, si nécessaire, de nouveaux nœuds peuvent être ajoutés au cluster Kubernetes. Si quelque chose ne va pas avec certains nœuds existants, Kubernetes déploiera des conteneurs sur les nœuds qui sont toujours dans un état sain.

Une grande partie de ce qui est illustré dans la figure précédente vous est déjà familière. Mais il y a aussi quelque chose de nouveau:

• Serveur API Faire des appels à ce serveur est le seul moyen d'interagir avec le cluster que nous avons, qu'il s'agisse de démarrer ou d'arrêter des conteneurs, de vérifier l'état du système, de travailler avec des journaux ou d'effectuer d'autres actions.
• Kubelet. Il s'agit d'un agent qui surveille les conteneurs à l'intérieur du nœud et interagit avec le nœud principal.

Veuillez noter que dans quelques phrases précédentes, nous utilisons le terme «conteneur», mais ici, il serait plus correct d'utiliser le terme «pod». Ces entités sont souvent appelées «pods» dans les publications en langue russe, et parfois «pods», dans la documentation , clarifiant le concept de «pod», elles parlent de «troupeau de baleines» (pod de baleines) ou de «pod de pois» mais personne ne les appelle "troupeaux" ou "pods". En parlant d'eux, nous utiliserons le mot «sous». Maintenant, vous pouvez les considérer comme des conteneurs, nous parlerons plus en détail des pods ci-dessous.

Nous nous arrêterons ici pour le moment, car nous pouvons parler de tout cela plus loin, et, en plus, il y a beaucoup de bons matériaux concernant la théorie de Kubernetes. Par exemple, il s'agit d'une documentation officielle, bien qu'elle ne soit pas facile à lire, ou de livres comme celui-ci .

▍ Standardisation du travail avec les fournisseurs de services cloud

Une autre force de Kubernetes réside dans le fait que cette technologie contribue à la standardisation du travail avec les prestataires de services cloud (Cloud Service Provider, CSP). Ceci est une déclaration audacieuse. Prenons l'exemple suivant. Un spécialiste qui connaît bien Azure ou Google Cloud Platform doit travailler sur un projet conçu pour un environnement cloud complètement nouveau pour lui, avec lequel il n'est pas familier. Dans cette situation, beaucoup de choses peuvent mal tourner. Par exemple, les délais de livraison du projet peuvent être perturbés, la société cliente du projet peut avoir besoin de louer plus de ressources cloud que prévu, etc.

Lors de l'utilisation de Kubernetes, un tel problème ne peut tout simplement pas se poser, car, quel que soit le fournisseur de services cloud dont nous parlons, travailler avec Kubernetes a toujours la même apparence. Le développeur, dans un style déclaratif, indique au serveur API ce dont il a besoin, et Kubernetes travaille avec les ressources du système, ce qui permet au développeur d'ignorer les détails de la mise en œuvre de ce système.

Attardez-vous un peu sur cette idée, car il s'agit d'une opportunité Kubernetes très puissante. Pour les entreprises, cela signifie que leurs décisions ne sont pas liées à un CSP spécifique. Si une entreprise trouve une meilleure offre sur le marché des services cloud, elle peut librement profiter de cette offre en passant à un nouveau fournisseur. De plus, l'expérience acquise par les spécialistes de l'entreprise ne se perd nulle part.

Parlons maintenant de l'utilisation pratique de Kubernetes

Pratique Kubernetes: Pods

Nous avons configuré le lancement de microservices dans des conteneurs, le processus de configuration a été assez fastidieux, mais nous avons réussi à arriver à un système fonctionnel. De plus, comme déjà mentionné, notre solution ne s'adapte pas bien et ne résiste pas aux pannes. Nous allons résoudre ces problèmes avec Kubernetes. Ensuite, nous amènerons notre système sous une forme correspondant au schéma suivant. À savoir, les conteneurs seront gérés par Kubernetes.


Les microservices fonctionnent dans un cluster géré par Kubernetes

Ici, nous utiliserons Minikube pour le déploiement local du cluster et pour tester les capacités de Kubernetes, bien que tout ce que nous ferons ici puisse se faire à l'aide de plateformes cloud telles qu'Azure ou Google Cloud Platform.

▍Installation et démarrage de Minikube

Pour installer Minikube, suivez les instructions de la documentation . Lors de l'installation de Minikube, vous installerez également Kubectl. Il s'agit d'un client qui permet de faire des demandes au serveur API Kubernetes.

Pour démarrer Minikube, exécutez la commande de minikube start et, une fois celle-ci terminée, exécutez la commande kubectl get nodes . Par conséquent, vous devriez voir quelque chose comme ceci:

 kubectl get nodes NAME       STATUS ROLES     AGE VERSION minikube   Ready <none>    11m v1.9.0 

Minikube met à notre disposition un cluster composé d'un seul nœud. Certes, cela nous convient assez bien. Ceux qui travaillent avec Kubernetes n'ont pas à se soucier du nombre exact de nœuds dans le cluster, car Kubernetes vous permet de faire abstraction de ces détails.

Parlons maintenant des pods.

▍Pods

J'aime vraiment les conteneurs, et vous les aimez probablement aussi maintenant. Pourquoi Kubernetes nous propose-t-il d'utiliser des pods, des entités qui sont les unités informatiques minimum déployables dans ce système? Sous quelles fonctions exerce-t-il? Le fait est que l'âtre peut comprendre un ou plusieurs conteneurs partageant le même temps d'exécution.

Mais est-il nécessaire de réaliser, par exemple, deux conteneurs dans un foyer? Comment dire ... Habituellement, il n'y a qu'un seul conteneur par conteneur, et c'est ce que nous allons faire. Mais dans les cas où, par exemple, deux conteneurs ont besoin d'un accès partagé au même entrepôt de données, ou si une connexion est établie entre eux à l'aide de la technique de communication interprocessus, ou s'ils sont étroitement connectés pour une autre raison, tout cela peut être réalisé en les faisant fonctionner dans un seul foyer. Une autre possibilité que les pods diffèrent est qu'ils n'ont pas à utiliser de conteneurs Docker. Si nécessaire, vous pouvez appliquer ici d'autres technologies pour la conteneurisation d'applications, par exemple - Rkt .

Le diagramme suivant montre les propriétés numérotées de l'âtre.


Propriétés du foyer

Considérez ces propriétés.

1. Chaque pod d'un cluster Kubernetes possède une adresse IP unique.
2. Un foyer peut contenir de nombreux conteneurs. Ils partagent les numéros de port disponibles, c'est-à-dire qu'ils peuvent par exemple échanger des informations via localhost (naturellement, ils ne peuvent pas utiliser les mêmes ports). L'interaction avec les conteneurs situés dans d'autres pods est organisée à l'aide des adresses IP de ces pods.
3. Les conteneurs dans les modules partagent les volumes de stockage de données, l'adresse IP, les numéros de port et l'espace de noms IPC.

Il convient de noter que les conteneurs ont leurs propres systèmes de fichiers isolés, mais ils peuvent partager des données à l'aide de la ressource Kubernetes appelée Volume .

Pour nous, ce qui a déjà été dit sur les foyers est suffisant pour continuer à maîtriser les Kubernetes. En savoir plus à leur sujet ici .

▍ Description du foyer

Ce qui suit est un fichier manifeste pour l'application sa-frontend .

 apiVersion: v1 kind: Pod                                            # 1 metadata: name: sa-frontend                                  # 2 spec:                                                # 3 containers:   - image: rinormaloku/sentiment-analysis-frontend # 4     name: sa-frontend                              # 5     ports:       - containerPort: 80 

Expliquons certains des paramètres qui y sont spécifiés.

1. Kind : spécifie le type de ressource Kubernetes que nous voulons créer. Dans notre cas, c'est Pod .
2. Name : nom de la ressource. Nous l'avons appelé sa-frontend .
3. Spec : un objet qui décrit l'état souhaité de la ressource. La propriété la plus importante ici est le tableau de conteneurs.
4. Image : l'image du conteneur que nous voulons exécuter dans ce pod.
5. Name : un nom unique pour le conteneur en dessous.
6. ContainerPort : le port sur lequel le conteneur écoute. Ce paramètre peut être considéré comme une indication pour qui lit ce fichier (si vous omettez ce paramètre, cela ne limitera pas l'accès au port).

▍Création d'un foyer SA-Frontend

Le fichier de description du pod dont nous avons parlé se trouve dans resource-manifests/sa-frontend-pod.yaml . Vous devez soit accéder à ce dossier à l'aide des outils du terminal, soit, lorsque vous appelez la commande appropriée, spécifier le chemin d'accès complet au fichier. Voici cette commande et un exemple de réaction du système à celle-ci:

 kubectl create -f sa-frontend-pod.yaml pod "sa-frontend" created 

Afin de savoir si cela fonctionne sous, exécutez la commande suivante:

 kubectl get pods NAME                          READY STATUS RESTARTS AGE sa-frontend                   1/1 Running 0 7s 

Si l'état de l'âtre pendant l'exécution de cette commande est ContainerCreating , vous pouvez exécuter la même commande avec le --watch . Pour cette raison, lorsque le foyer est en état de fonctionnement, des informations à ce sujet s'affichent automatiquement.

▍Accès à l'application depuis l'extérieur

Afin d'organiser l'accès à l'application depuis l'extérieur, il sera correct de créer une ressource Kubernetes de type Service, dont nous parlerons ci-dessous, mais ici, pour plus de brièveté, nous utiliserons une simple redirection de port:

 kubectl port-forward sa-frontend 88:80 Forwarding from 127.0.0.1:88 -> 80 

Si vous passez maintenant par un navigateur à 127.0.0.1:88 , vous pouvez voir la page d'application React.

▍ Mauvaise approche de mise à l'échelle

Nous avons déjà dit que l'une des capacités de Kubernetes est la mise à l'échelle des applications. Pour profiter de cette opportunité, nous en exécuterons une autre. Créez une description d'une autre ressource Pod en plaçant le code suivant dans le fichier sa-frontend-pod2.yaml :

 apiVersion: v1 kind: Pod                                           metadata: name: sa-frontend2      #   spec:                                                containers:   - image: rinormaloku/sentiment-analysis-frontend     name: sa-frontend                                  ports:       - containerPort: 80 

Comme vous pouvez le voir, si vous comparez cette description avec ce que nous avons examiné ci-dessus, le seul changement est la valeur de la propriété Name .

Créez-en un nouveau sous:

 kubectl create -f sa-frontend-pod2.yaml pod "sa-frontend2" created 

Assurez-vous qu'il fonctionne:

 kubectl get pods NAME                          READY STATUS RESTARTS AGE sa-frontend                   1/1 Running 0 7s sa-frontend2                  1/1 Running 0 7s 

Maintenant, nous avons deux foyers! Certes, il n'y a rien de spécial à apprécier ici. Veuillez noter que la solution au problème de mise à l'échelle des applications présentée ici présente de nombreux inconvénients. Nous verrons comment le faire correctement dans la section sur une autre ressource Kubernetes appelée Déploiement.

Considérez maintenant ce que nous avons obtenu après avoir lancé deux foyers identiques. À savoir, le serveur Web Nginx s'exécute désormais dans deux modules différents. À cet égard, nous pouvons poser deux questions:

1. Comment donner accès à ces serveurs de l'extérieur, par URL?
2. Comment organiser l'équilibrage de charge entre eux?

Mauvaise approche de mise à l'échelle

Parmi les outils Kubernetes, il existe des ressources du formulaire Service. Parlons-en.

Pratique Kubernetes: Services

Les services Kubernetes agissent comme des points d'accès aux ensembles de foyers qui offrent les mêmes fonctionnalités que ces foyers. Les services effectuent la solution des tâches difficiles consistant à travailler avec des foyers et à équilibrer la charge entre eux.


Le service Kubernetes sert des adresses IP

Dans notre cluster Kubernetes, il y aura des pods qui implémenteront différentes fonctions. Il s'agit d'une application frontale, d'une application Web Spring et d'une application Flask écrite en Python. Cela soulève la question de savoir comment le service doit comprendre avec quel type de pods il doit travailler, c'est-à-dire comment trouver sur la base de quelles informations le système doit générer une liste de points de terminaison pour les pods.

Cela se fait avec une autre abstraction Kubernetes appelée Label. Le travail avec les balises comprend deux étapes:

1. L'attribution d'étiquette donnera le service avec lequel travailler.
2. En appliquant un «sélecteur» au service, qui détermine les pods auxquels les étiquettes sont affectées, le service fonctionnera.

C'est peut-être plus facile à imaginer comme illustration qu'à décrire.


Pods étiquetés et leurs fichiers manifestes

Nous voyons ici deux foyers qui, à l'aide de la construction app: sa-frontend , se voient attribuer les mêmes étiquettes. Le service s'intéresse aux pods avec de telles marques.

▍Étiquettes

Les étiquettes offrent aux développeurs un moyen simple d'organiser les ressources Kubernetes. Ce sont des paires clé-valeur; vous pouvez les affecter à toutes les ressources. Modifiez les fichiers de description du foyer de l'application frontale et amenez-les à la vue illustrée dans la figure précédente. Après cela, enregistrez ces fichiers et exécutez les commandes suivantes:

 kubectl apply -f sa-frontend-pod.yaml Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply pod "sa-frontend" configured kubectl apply -f sa-frontend-pod2.yaml Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply pod "sa-frontend2" configured 

Lorsque ces commandes sont exécutées, le système émet des avertissements (cela ne nous convient pas que nous utilisons apply au lieu de create , nous le comprenons), mais, après un avertissement, il signale que les pods correspondants sont configurés. Nous pouvons vérifier si des étiquettes ont été attribuées aux étiquettes, en filtrant les journaux pour lesquels nous voulons afficher des informations:

 kubectl get pod -l app=sa-frontend NAME           READY STATUS    RESTARTS AGE sa-frontend    1/1 Running   0 2h sa-frontend2   1/1 Running   0 2h 

Une autre façon de vérifier que des étiquettes ont bien été attribuées aux étiquettes consiste à attacher la --show-labels à la commande précédente. Pour cette raison, les informations sur leurs modules incluront également des données sur leurs marques.

Maintenant, des balises ont été attribuées et nous sommes prêts à configurer le service pour fonctionner avec eux. Par conséquent, nous traiterons une description d'un service tel que LoadBalancer .


Équilibrage de charge à l'aide d'un service tel que LoadBalancer

▍ Description du service

Voici une description YAML d'un service comme LoadBalancer :

 apiVersion: v1 kind: Service              # 1 metadata: name: sa-frontend-lb spec: type: LoadBalancer       # 2 ports: - port: 80               # 3   protocol: TCP          # 4   targetPort: 80         # 5 selector:                # 6   app: sa-frontend       # 7 

Expliquez ce texte:

1. Kind : nous créons un service, une ressource Service .
2. Type : le type de ressource indiqué dans sa spécification. Nous avons choisi le type LoadBalancer , car avec ce service nous voulons résoudre le problème d'équilibrage de la charge entre les foyers.
3. Port : port sur lequel le service accepte les requêtes.
4. Protocol : protocole utilisé par le service.
5. TargetPort : port vers lequel les demandes entrantes sont redirigées.
6. Selector : un objet contenant des informations sur les pods avec lesquels le service devrait fonctionner.
7. app: sa-frontend : cette propriété indique avec quels pods le service fonctionnera. À savoir, ce sont les pods auxquels l'étiquette app: sa-frontend a été attribuée.

Pour créer un service, vous devez exécuter la commande suivante:

 kubectl create -f service-sa-frontend-lb.yaml service "sa-frontend-lb" created 

Vous pouvez vérifier l'état du service comme suit:

 kubectl get svc NAME             TYPE CLUSTER-IP      EXTERNAL-IP PORT(S) AGE sa-frontend-lb   LoadBalancer 10.101.244.40   <pending> 80:30708/TCP 7m 

Ici, vous pouvez voir que la propriété EXTERNAL-IP est dans l'état <pending> , mais vous ne pouvez pas attendre de la changer. Cela est dû au fait que nous utilisons Minikube. Si nous avons créé un service similaire en travaillant avec un certain fournisseur de services cloud, tel qu'Azure ou la plateforme Google Cloud, alors le service aurait une adresse IP publique qui permettrait d'y accéder depuis Internet.

Malgré cela, Minikube ne nous permettra pas de déconner, nous donnant une commande utile pour le débogage local du système:

 minikube service sa-frontend-lb Opening kubernetes service default/sa-frontend-lb in default browser... 

Grâce à cette commande, un navigateur sera lancé qui accédera au service. Une fois que le service a reçu la demande, il la redirige vers l'un des foyers (peu importe celui sous lequel il se trouve). Cette abstraction nous permet de percevoir un groupe de foyers comme une entité unique et de travailler avec eux, en utilisant le service comme point d'accès unique à eux.

Dans cette section, nous avons expliqué comment attribuer des étiquettes aux ressources, comment les utiliser lors de la configuration des services en tant que sélecteurs. Ici, nous avons décrit et créé un service comme LoadBalancer . Grâce à cela, nous avons résolu le problème de mise à l'échelle de l'application (la mise à l'échelle consiste à ajouter de nouveaux foyers avec les étiquettes correspondantes au cluster) et à organiser l'équilibrage de charge entre les foyers en utilisant le service comme point d'entrée.

Pratique Kubernetes: Déploiements

Le déploiement est une abstraction de Kubernetes qui nous permet de contrôler ce qui est toujours présent dans le cycle de vie de l'application. Il s'agit de gérer les changements d'application. Les applications qui ne changent pas sont pour ainsi dire des applications «mortes». Si l'application "vit", vous pouvez rencontrer le fait que ses exigences changent périodiquement, son code se développe, ce code est empaqueté et déployé. De plus, des erreurs peuvent être commises à chaque étape du processus.

Une ressource de type Déploiement vous permet d'automatiser le processus de transition d'une version d'une application à une autre. Cela se fait sans interrompre le système, et si une erreur se produit pendant ce processus, nous aurons la possibilité de revenir rapidement à la version de travail précédente de l'application.

▍Utilisation des déploiements

Maintenant, le cluster dispose de deux foyers et d'un service qui leur donne accès de l'extérieur et équilibre la charge sur eux.


État actuel du cluster

Nous avons parlé du fait que faire fonctionner deux foyers différents avec la même fonctionnalité n'est pas une bonne idée. Lors de l'utilisation d'un tel schéma, nous devons travailler avec chaque foyer individuellement, créer, mettre à jour, supprimer chaque foyer spécifique, observer son état. Avec cette approche, il n'est pas nécessaire de parler d'une mise à jour rapide du système ou de la restauration rapide d'une mise à jour infructueuse. Nous ne sommes pas satisfaits de cet état de fait, nous allons donc recourir à la possibilité de ressources de déploiement, qui vise à résoudre les problèmes ci-dessus.

Avant de poursuivre le travail, formulons ses objectifs, qui nous donneront des directives qui seront utiles lors de l'analyse du fichier manifeste de déploiement. Voici donc ce dont nous avons besoin:

1. Nous voulons être en mesure de créer deux foyers basés sur un conteneur rinormaloku/sentiment-analysis-frontend .
2. Nous avons besoin d'un système de déploiement d'applications qui lui permet de fonctionner sans interruption lors de sa mise à jour.
3. Nous voulons que le libellé de l' app: sa-frontend soit attribué app: sa-frontend , qui permettra au service sa-frontend-lb de détecter ces pods.

Nous allons maintenant exprimer ces exigences sous la forme d'une description de la ressource de déploiement.

▍ Description du déploiement

Voici une description YAML d'une ressource de type déploiement, qui a été créée en tenant compte des exigences système ci-dessus:

 apiVersion: extensions/v1beta1 kind: Deployment                                          # 1 metadata: name: sa-frontend spec: replicas: 2                                             # 2 minReadySeconds: 15 strategy:   type: RollingUpdate                                   # 3   rollingUpdate:     maxUnavailable: 1                                   # 4     maxSurge: 1                                         # 5 template:                                               # 6   metadata:     labels:       app: sa-frontend                                  # 7   spec:     containers:       - image: rinormaloku/sentiment-analysis-frontend         imagePullPolicy: Always                         # 8         name: sa-frontend         ports:           - containerPort: 80 

Analysons cette description:

1. Kind : il est dit ici que nous décrivons une ressource de la vue Deployment .
2. Replicas : propriété de l'objet de spécification de déploiement qui définit le nombre d'instances (répliques) de foyers à exécuter.
3. Type : décrit la stratégie utilisée dans ce déploiement lors du passage de la version actuelle à une nouvelle. RollingUpdate stratégie RollingUpdate n'offre aucun temps d'arrêt du système lors des mises à niveau.
4. MaxUnavailable : il s'agit d'une propriété de l'objet RollingUpdate , qui définit le nombre maximal de foyers non disponibles (par rapport au nombre souhaité de foyers) lors de la mise à jour séquentielle du système. Dans notre déploiement, qui implique la présence de 2 répliques, la valeur de cette propriété indique qu'après l'achèvement d'un pod, un autre sera exécuté, ce qui rend l'application disponible lors de la mise à jour.
5. MaxSurge : il s'agit d'une propriété de l'objet RollingUpdate qui décrit le nombre maximal de foyers pouvant être ajoutés à un déploiement (par rapport à un nombre donné de foyers). Dans notre cas, sa valeur, 1, signifie que, lors du passage à une nouvelle version du programme, nous pouvons ajouter un autre sous-cluster, ce qui conduira au fait que jusqu'à trois foyers peuvent être lancés simultanément.
6. Template : cet objet définit le modèle de foyer que la ressource de Deployment décrite utilisera pour créer de nouveaux foyers. Vous trouverez probablement ce paramètre familier.
7. app: sa-frontend : étiquette pour les foyers créés selon un modèle donné.
8. ImagePullPolicy : définit l'ordre de travail avec les images. Dans notre cas, cette propriété est définie sur Always , c'est-à-dire que lors de chaque déploiement, l'image correspondante sera téléchargée à partir du référentiel.

Après avoir examiné tout cela, passons à la pratique. Exécutez le déploiement:

 kubectl apply -f sa-frontend-deployment.yaml deployment "sa-frontend" created 

Vérifiez l'état du système:

 kubectl get pods NAME                           READY STATUS RESTARTS AGE sa-frontend                    1/1 Running 0 2d sa-frontend-5d5987746c-ml6m4   1/1 Running 0 1m sa-frontend-5d5987746c-mzsgg   1/1 Running 0 1m sa-frontend2                   1/1 Running 0 2d 

Comme vous pouvez le voir, nous avons maintenant 4 pods. Deux d'entre eux ont été créés à l'aide de la ressource Déploiement, deux autres sont ceux que nous avons créés nous-mêmes. Vous pouvez maintenant supprimer les pods que nous avons créés nous-mêmes à l'aide de commandes du type suivant:

 kubectl delete pod <pod-name> 

Au fait, voici une mission pour un travail indépendant. Supprimez l'un des foyers créés à l'aide de la ressource Déploiement et surveillez le système. Réfléchissez aux raisons de ce qui se passe avant de continuer à lire.

Lors de la suppression d'un foyer, la ressource Déploiement apprend que l'état actuel du système (1 sous) est différent de celui souhaité (2 sous), donc un autre sous est lancé.

Quelle est l'utilisation des ressources de déploiement, outre le fait que, lorsqu'elles sont utilisées, le système est maintenu dans le bon état? Considérez les points forts de ces ressources.

▍ Réalisation de déploiements sans interruption du système

Supposons qu'un chef de produit vienne nous voir et signale que le client pour lequel nous avons créé ce produit veut un bouton vert dans l'application cliente. Les développeurs implémentent cette exigence et nous donnent la seule chose dont nous avons besoin d'eux - un conteneur d'images appelé rinormaloku/sentiment-analysis-frontend:green . Maintenant vient notre temps. Nous, l'équipe DevOps, devons déployer le système mis à jour et garantir un temps d'arrêt nul. Voyons maintenant si les efforts pour développer et configurer la ressource de déploiement sont justifiés.

Modifiez le fichier sa-frontend-deployment.yaml , en remplaçant le nom du conteneur d'images par un nouveau, avec rinormaloku/sentiment-analysis-frontend:green , puis enregistrez ce fichier sous sa-frontend-deployment-green.yaml et exécutez la commande suivante:

 kubectl apply -f sa-frontend-deployment-green.yaml --record deployment "sa-frontend" configured 

Vérifiez l'état du système avec la commande suivante:

 kubectl rollout status deployment sa-frontend Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 old replicas are pending termination... Waiting for rollout to finish: 1 of 2 updated replicas are available... deployment "sa-frontend" successfully rolled out 

Conformément aux données affichées en réponse à cette commande, nous pouvons conclure que le déploiement de la mise à jour a réussi. Lors de la mise à niveau, les anciennes répliques, une à la fois, ont été remplacées par de nouvelles. , , , . , , .

, , :

 minikube service sa-frontend-lb 

, .




, , — .

RollingUpdate

, kubectl apply -f sa-frontend-deployment-green.yaml --record , Kubernetes , , . , , rinormaloku/sentiment-analysis-frontend:green . , , .




RollingUpdate , , maxUnavailable: 1 maxSurge: 1 . , Deployment , , , . , , , .

Deployment. , . .

▍

, , . «! ! !», — . . , , :

 kubectl rollout history deployment sa-frontend deployments "sa-frontend" REVISION  CHANGE-CAUSE 1         <none>    2         kubectl.exe apply --filename=sa-frontend-deployment-green.yaml --record=true 

: «, , ?».

«. , ?», — .

, , :

 kubectl rollout undo deployment sa-frontend --to-revision=1 deployment "sa-frontend" rolled back 

. , .

.

.

!

, . Kubernetes , , . , !

. , . CHANGE-CAUSE <none> , — kubectl.exe apply –filename=sa-frontend-deployment-green.yaml –record=true ?

, -- record , .

, , , .

Kubernetes:

Kubernetes, , . , .




.

▍ sa-logic

resource-manifests :

 kubectl apply -f sa-logic-deployment.yaml --record deployment "sa-logic" created 

sa-logic . Python-. app: sa-logic . sa-logic , . sa-logic-deployment.yaml .

-, , — sa-logic .

▍ sa-logic

, Service. , Java-, sa-webapp , , Python-. , , , Python-, . , , , .

, , , , . , sa-logic , sa-logic .

:

 kubectl apply -f service-sa-logic.yaml service "sa-logic" created 

, .




sa-logic , sa-webapp , , .

sa-webapp .

▍ sa-webapp

, Deployment - . , sa-web-app-deployment.yaml , :

 - image: rinormaloku/sentiment-analysis-web-app imagePullPolicy: Always name: sa-web-app env:   - name: SA_LOGIC_API_URL     value: "http://sa-logic" ports:   - containerPort: 8080 

env ? , , , SA_LOGIC_API_URL http://sa-logic . , , . ?

kube-dns.

▍DNS- Kubernetes

Kubernetes , kube-dns . DNS-. kube-dns , DNS- .

, sa-logic , IP-. kube-dns IP- . http://sa-logic IP-.

Deployment sa-webapp .

▍ sa-webapp

:

 kubectl apply -f sa-web-app-deployment.yaml --record deployment "sa-web-app" created 

sa-webapp , . React- , sa-webapp .

▍ sa-webapp

service-sa-web-app-lb.yaml , , , , . , , :

 kubectl apply -f service-sa-web-app-lb.yaml service "sa-web-app-lb" created 

. , , . , sa-frontend , Java- sa-webapp , http://localhost:8080/sentiment . , , sa-webapp , React- , Java-.

, . , — , , .

, :

1. IP- sa-webapp , :
   
   minikube service list
|-------------|----------------------|-----------------------------|
| NAMESPACE | NAME | URL |
|-------------|----------------------|-----------------------------|
| default | kubernetes | No node port |
| default | sa-frontend-lb | http://192.168.99.100:30708 |
| default | sa-logic | No node port |
| default | sa-web-app-lb | http://192.168.99.100:31691 |
| kube-system | kube-dns | No node port |
| kube-system | kubernetes-dashboard | http://192.168.99.100:30000 |
|-------------|----------------------|-----------------------------|
2. IP- sa-frontend/src/App.js . , :
   
   

    analyzeSentence() {       fetch('http://192.168.99.100:31691/sentiment', { /*    */})           .then(response => response.json())           .then(data => this.setState(data));   } 

3. React-, sa-frontend npm run build .
4. :
   
   

    docker build -f Dockerfile -t $DOCKER_USER_ID/sentiment-analysis-frontend:minikube. 

5. Docker Hub:
   
   

    docker push $DOCKER_USER_ID/sentiment-analysis-frontend:minikube 

6. sa-frontend-deployment.yaml , .
7. :
   
   

    kubectl apply -f sa-frontend-deployment.yaml 

, , , , minikube service sa-frontend-lb . , - .

Résumé

Kubernetes , , , , . Kubernetes , , . Kubernetes Supernetes.

, :

• , , React, Java Python.
• Docker, , Dockerfile .
• , , Docker Hub.

, Kubernetes:

, , Kubernetes.

Chers lecteurs! Kubernetes?