apiVersion : apps/v1

genre : Déploiement

métadonnées :

Étiquettes:

exécuter : nginx

nom : nginx

spécification :

répliques : 3

sélecteur:

matchÉtiquettes :

exécuter : nginx

modèle:

métadonnées :

Étiquettes:

exécuter : nginx

spécification :

conteneurs :

- nom : nginx

image: nginx:1.16

Les mises à jour du modèle de pod du déploiement déclenchent une mise à jour progressive. Lorsqu'un modèle de pod de déploiement est mis à jour, un nouveau ReplicaSet est créé qui crée ensuite de nouveaux pods en fonction de la spécification de pod mise à jour. Lorsque les nouveaux pods sont créés, le ReplicaSet de la version précédente est mis à l'échelle à zéro pour supprimer les anciens pods. Cette stratégie est connue sous le nom de mise à jour continue.

L'exemple suivant crée un déploiement de pods nginx avec 3 réplicas. L'option --record annote et enregistre la commande kubectl pour référence future. L'état et l'historique du déploiement du déploiement sont vérifiés avec kubectl rollout .

$ kubectl crée le déploiement nginx --image=nginx:1.16 --replicas=3 --record

deploy.apps/nginx créé

$ kubectl état de déploiement déployer nginx

déploiement "nginx" déployé avec succès

$ kubectl historique de déploiement déployer nginx

déploiement.apps/nginx

RÉVISION CHANGEMENT-CAUSE

1 kubectl crée le déploiement nginx --image=nginx:1.16 --replicas=3 --record=true

$

Étant donné que l'option --record a été utilisée pour créer le déploiement, l'annotation est répertoriée dans la colonne CHANGE-CAUSE. Si --record n'était pas utilisé pour annoter, aucun n'apparaîtrait sous CHANGE-CAUSE pour la révision 1.



Ensuite, mettez à jour le déploiement pour utiliser l'image nginx version 1.17. Cette mise à jour déclenchera une mise à jour progressive. Un nouveau ReplicaSet sera créé et les pods sous les anciens ReplicaSets seront terminés (mis à l'échelle à 0). Après avoir mis à jour le déploiement, vérifiez immédiatement l'état du déploiement pour capturer la mise à jour progressive.

$ kubectl set image deploy nginx nginx=nginx:1.17 --record

mise à jour de l'image deploy.apps/nginx

$ kubectl état de déploiement déployer nginx

En attente de la fin du déploiement "nginx" : 2 nouvelles répliques sur 3 ont été mises à jour...

En attente de la fin du déploiement "nginx" : 2 nouvelles répliques sur 3 ont été mises à jour...

En attente de la fin du déploiement "nginx" : 2 nouvelles répliques sur 3 ont été mises à jour...

En attente de la fin du déploiement "nginx" : 1 anciennes répliques sont en attente de résiliation...

En attente de la fin du déploiement "nginx" : 1 anciennes répliques sont en attente de résiliation...

déploiement "nginx" déployé avec succès

$

Kubernetes permet aux utilisateurs d'annuler les mises à jour de déploiement. Les déploiements peuvent être restaurés vers une version précédente avec kubectl rollout undo deploy ou vous pouvez spécifier une révision spécifique.

En utilisant l'exemple précédent, regardons les révisions disponibles.

$ kubectl rollout undo deploy nginx --to-revision=1

deploy.apps/nginx annulé

$ kubectl état de déploiement déployer nginx

En attente de la fin du déploiement "nginx" : 2 nouvelles répliques sur 3 ont été mises à jour...

En attente de la fin du déploiement "nginx" : 2 nouvelles répliques sur 3 ont été mises à jour...

En attente de la fin du déploiement "nginx" : 2 nouvelles répliques sur 3 ont été mises à jour...

En attente de la fin du déploiement "nginx" : 1 anciennes répliques sont en attente de résiliation...

En attente de la fin du déploiement "nginx" : 1 anciennes répliques sont en attente de résiliation...

déploiement "nginx" déployé avec succès

$ kubectl historique de déploiement déployer nginx

déploiement.apps/nginx

RÉVISION CHANGEMENT-CAUSE

2 kubectl set image deploy nginx nginx=nginx:1.17 --record=true

3 kubectl crée le déploiement nginx --image=nginx:1.16 --replicas=3 --record=true

$

Le déploiement utilise à nouveau l'image nginx 1.16.

Emplois et CronJobs

Les travaux complètent les tâches du début à la fin. Un travail est terminé lorsque le pod termine la tâche et le pod se termine avec succès à la fin. Il existe trois types d'emplois :

Tâches non parallèles - une tâche qui exécute un podTâches parallèles avec un achèvement fixe - les tâches exécutent plusieurs pods en parallèle et définit le nombre d'achèvements lorsque le travail est terminéTâches parallèles sans achèvement fixe - les tâches exécutent plusieurs pods en parallèle et lorsqu'un pod réussit, le travail est terminé et tous les autres pods se terminent ; cela s'appelle aussi une file d'attente de travail

Le manifeste suivant décrit une tâche parallèle avec un nombre fixe d'achèvements. Le travail renvoie la date à la sortie standard du conteneur. La tâche exécutera 5 pods en parallèle et s'arrêtera après 20 achèvements réussis.

apiVersion : batch/v1

genre : Travail

métadonnées :

nom: date-job

spécification :

parallélisme : 5

achèvements: 20

modèle:

métadonnées :

nom: date-job

spécification :

conteneurs :

- nom : busybox

image : boîte occupée

commander:

- /bin/sh

- -c

- Date

restartPolicy : OnFailure

À la fin de ce travail, il y aurait 20 pods terminés. L'obtention du journal du conteneur pour l'un des 20 pods renvoie la date d'exécution du conteneur. Les CronJobs exécutent les tâches selon un calendrier et sont utilisés pour automatiser les tâches. Le manifeste CronJob suivant crée un CronJob qui s'exécute toutes les minutes et renvoie la date à la sortie standard du conteneur.

apiVersion : batch/v1beta1

genre : CronJob

métadonnées :

nom: cron-job

spécification :

horaire : "*/1 * * * *"

modèle d'emploi :

spécification :

modèle:

spécification :

conteneurs :

- nom : busybox

image : boîte occupée

arguments :

- /bin/sh

- -c

- Date

restartPolicy : OnFailure

Etiquettes, sélecteurs, annotations

Les JLabels sont des paires clé/valeur attachées aux objets Kubernetes tels que les pods, les volumes persistants et les nœuds de cluster. Les étiquettes aident à gérer et à organiser les objets Kubernetes en groupes logiques et peuvent également être utilisées pour qualifier les objets Kubernetes pour les ressources sur lesquelles s'exécuter. Par exemple, une stratégie réseau cible les pods dans le même espace de noms à l'aide d'étiquettes sur les pods. Certaines commandes utilisent des sélecteurs pour identifier et sélectionner des objets Kubernetes par leurs étiquettes. Les sélecteurs sont utilisés avec l'indicateur -l ou --selector qui filtre sur les étiquettes. Il existe deux types de sélecteurs :

Basée sur l'égalité/l'inégalité = ou == pour l'égalité != pour l'inégalité.

Jetez un œil à l'utilisation des étiquettes et des sélecteurs. Exécutez les déploiements et tâches suivants pour lancer des pods avec un environnement et une étiquette de version. Les pods peuvent avoir une étiquette d'environnement prod , dev ou qa et une étiquette de version stable ou edg . Utilisez ensuite des sélecteurs pour filtrer les pods à l'aide d'étiquettes. NB Lors de la création de déploiements, la première option -l étiquette le déploiement et la seconde option -l étiquette les pods.

$ kubectl exécuter nginx-deploy --image=nginx:1.9 --replicas=5 \

-l environnement=prod -l environnement=prod,release=stable

kubectl run --generator=deployment/apps.v1 est OBLIGATOIRE et sera supprimé dans une future version. Utilisez kubectl run --generator=run-pod/v1 ou kubectl create à la place.

deploy.apps/nginx-deploy créé

$ kubectl run nginx-pod --generator=run-pod/v1 --image=nginx:latest \

-l environnement=dev,release=edge

pod/nginx-pod créé

$ kubectl exécuter nginx-qa --image=nginx:latest --replicas=3 \

-l environnement=qa -l environnement=qa,release=edge

kubectl run --generator=deployment/apps.v1 est OBLIGATOIRE et sera supprimé dans une future version. Utilisez kubectl run --generator=run-pod/v1 ou kubectl create à la place.

deploy.apps/nginx-qa créé

$

Maintenant, nous avons 9 pods en cours d'exécution.

$ kubectl obtenir des pods

NOM ÉTAT PRÊT REDÉMARRAGE ÂGE

nginx-deploy-86f8b8c8d4-8j78k 1/1 Exécution 0 21s

nginx-deploy-86f8b8c8d4-cbsbz 1/1 Exécution 0 21s

nginx-deploy-86f8b8c8d4-jq2cb 1/1 Exécution 0 21s

nginx-deploy-86f8b8c8d4-l8ck8 1/1 Exécution 0 21s

nginx-deploy-86f8b8c8d4-smfmf 1/1 Exécution 0 21s

nginx-pod 1/1 Exécution 0 14s

nginx-qa-55d6b56d5c-fssmn 1/1 Exécution 0 8s

nginx-qa-55d6b56d5c-mmsp9 1/1 Exécution 0 8s

nginx-qa-55d6b56d5c-xlks7 1/1 Exécution 0 8s

$

Utilisons des sélecteurs pour filtrer les étiquettes afin d'identifier les pods appropriés que nous recherchons. Obtenons des pods qui ne fonctionnent pas en production

$ kubectl get pod -l environment!=prod --show-labels

NOM ÉTAT PRÊT REDÉMARRE ÉTIQUETTES D'ÂGE

nginx-pod 1/1 Exécution 0 67s environment=dev,release=edge

nginx-qa-55d6b56d5c-fssmn 1/1 Exécution 0 61s environment=qa,pod-template-hash=55d6b56d5c,release=edge

nginx-qa-55d6b56d5c-mmsp9 1/1 Exécution 0 61s environment=qa,pod-template-hash=55d6b56d5c,release=edge

nginx-qa-55d6b56d5c-xlks7 1/1 Exécution 0 61s environment=qa,pod-template-hash=55d6b56d5c,release=edge

$

Nous pouvons également récupérer des pods hors production avec des exigences basées sur des ensembles :

$ kubectl get pods -l "notin environnement (prod)" --show-labels

NOM ÉTAT PRÊT REDÉMARRE ÉTIQUETTES D'ÂGE

nginx-pod 1/1 Exécution 0 84s environment=dev,release=edge

nginx-qa-55d6b56d5c-fssmn 1/1 Exécution 0 78s environnement=qa,pod-template-hash=55d6b56d5c,release=edge

nginx-qa-55d6b56d5c-mmsp9 1/1 Exécution 0 78s environnement=qa,pod-template-hash=55d6b56d5c,release=edge

nginx-qa-55d6b56d5c-xlks7 1/1 Exécution 0 78s environnement=qa,pod-template-hash=55d6b56d5c,release=edge

$

L'utilisation du séparateur virgule agit comme un opérateur logique et ( && ). L'exemple suivant répertorie les pods dans l'environnement de développement et avec une version Edge :

$ kubectl get pods -l environment=dev,release=edge --show-labels

NOM ÉTAT PRÊT REDÉMARRE ÉTIQUETTES D'ÂGE

nginx-pod 1/1 Exécution 0 108s environnement=dev,release=edge

$

Les annotations sont similaires aux étiquettes en ce qu'elles sont des paires clé/valeur de métadonnées. Les annotations diffèrent des étiquettes en ce qu'elles ne sont pas utilisées pour la sélection d'objets mais sont généralement utilisées par des applications externes. Les annotations sont récupérables par les clients API, les outils et les bibliothèques. Les annotations sont créées dans le manifeste. L'exemple suivant est un manifeste de pod avec des annotations pour les informations de build et d'image.

apiVersion : v1

genre: Pod

métadonnées :

nom : info hôte

annotations :

Construire

constructeur : rxmllc

registre d'images : « https://hub.docker.com/r/rxmllc/hostinfo »

spécification :

conteneurs :

- nom : info hôte

image : rxmllc/hostinfo

restartPolicy : Jamais

Réclamations de volume persistantes

Un volume persistant Kubernetes existe en dehors du cycle de vie de tout pod qui le monte. Les volumes persistants sont des objets de stockage gérés par le cluster Kubernetes et provisionnés à partir de l'infrastructure du cluster (comme le système de fichiers de l'hôte). Les volumes persistants décrivent les détails d'une implémentation de stockage pour le cluster, notamment :

Modes d'accès au volumeLa capacité totale du volumeQu'advient-il des données une fois le volume retiréLe type de stockageUn identifiant de classe de stockage personnalisé et facultatif

Les revendications de volume persistant sont une abstraction des volumes persistants. Une demande de volume persistant est une demande de stockage. Les revendications de volume persistant se lient aux volumes persistants existants sur un certain nombre de facteurs tels que les sélecteurs d'étiquettes, le nom de la classe de stockage, la capacité de stockage et le mode d'accès. Les revendications de volume persistant peuvent créer dynamiquement des volumes persistants à l'aide d'une classe de stockage existante. Les pods se lient aux revendications de volume persistant par leur nom dans le manifeste du pod. Voyons comment les pods se lient à une revendication de volume persistant et comment une revendication de volume persistant se lie à un volume persistant. Le manifeste ci-dessous correspond à un volume persistant présentant les caractéristiques suivantes :

Étiquette de k8scluster : le nom de la classe masterStorage est localLa capacité de stockage est de 200 Le nœud MiOne peut monter le volume en lecture-écriture (mode d'accès = ReadWriteOnce) Le volume persistant est libéré lorsqu'une revendication de volume persistant limité est supprimée mais n'est pas disponible tant que le volume persistant n'est pas supprimé ( persistentVolumeReclaimPolicy = Retain) Monté sur un chemin hôte de /home/ubuntu/persistentvolume.

apiVersion : v1

genre: PersistentVolume

métadonnées :

nom : volume-local

Étiquettes:

k8scluster : maître

spécification :

storageClassName : local

capacité:

stockage: 200Mi

Modes d'accès :

- ReadWriteOnce

persistentVolumeReclaimPolicy : Conserver

hostPath :

chemin : /home/ubuntu/volume persistant

Dans l'exemple ci-dessus, une revendication de volume persistant peut utiliser un ou plusieurs des éléments suivants pour se lier au volume persistant : étiquette, nom de classe de stockage, capacité de stockage et mode d'accès. L'exemple suivant décrit une revendication de volume persistant qui se lie au volume persistant « volume local » en utilisant un sélecteur pour sélectionner l'étiquette k8scluster:master , le nom de la classe de stockage local et la capacité de stockage et le mode d'accès correspondants.

apiVersion : v1

genre : PersistentVolumeClaim

métadonnées :

nom: local-pvc

spécification :

Modes d'accès :

- ReadWriteOnce

Ressources:

demandes :

stockage: 200Mi

storageClassName : local

sélecteur:

matchÉtiquettes :

k8scluster : maître

Créons maintenant un pod qui se lie à la revendication de volume persistant. Le manifeste de pod suivant se lie à la revendication de volume persistant par son nom et monte le volume dans le répertoire /usr/share/nginx/html du conteneur.

apiVersion : v1

genre: Pod

métadonnées :

nom : nginx

spécification :

conteneurs :

- nom : nginx

image: nginx:dernière

volumeMontages :

- nom : données

chemin de montage : /usr/share/nginx/html

tomes :

- nom : données

PersistantVolumeRéclamation :

Nom de la réclamation : local-pvc

Après avoir créé ce pod. Vérifiez la liaison en décrivant la revendication de volume persistant et grep pour « Monté par », puis décrivez le pod et grep pour « Volumes »

$ kubectl décrire pvc local-pvc | grep "Monté par"

Monté par : nginx

$ kubectl décrire pod nginx | grep -A3 Volumes

Volumes :

Les données:

Tapez : PersistentVolumeClaim (une référence à un PersistentVolumeClaim dans le même espace de noms)

Nom de la réclamation : local-pvc

$

Exercice d'entraînement

Créez un déploiement qui crée 2 répliques de pods à l'aide de l'image nginx:1.9. Mettez à jour le déploiement pour utiliser la dernière image nginx. Annulez la mise à jour de l'image et restaurez le déploiement pour utiliser l'image nginx 1.9.