$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 rôles et ClusterRoles sont attribués aux utilisateurs et aux processus à l'aide de RoleBindings et ClusterRoleBindings. Les RoleBindings associent un utilisateur, comme un compte de service, à un rôle. Toutes les autorisations accordées par un rôle sont transmises à l'utilisateur via le RoleBinding. Les liaisons de rôle peuvent également être créées impérativement à l'aide de kubectl create rolebinding . Les liaisons de rôles lient les rôles aux utilisateurs à l'aide de l'indicateur --user et serviceAccounts à l'aide de l'indicateur --serviceaccount. L'exemple suivant lie le rôle default-appmanager au compte de service par défaut de l'espace de noms par défaut :

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'a pas été utilisé pour annoter, aucun n'apparaîtra 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

$

Déploiements et restaurations

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 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

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

$

La mise à jour du déploiement est maintenant en révision 2. Encore une fois, si --record n'était pas utilisé pour annoter, aucun ne serait répertorié dans la colonne CHANGE-CAUSE. Ensuite, nous annulons le déploiement vers une révision spécifique, observons l'état et vérifions l'historique de déploiement.

$ 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.

Configurer les applications

Il existe plusieurs façons de configurer les applications exécutées sous Kubernetes. L'une des méthodes consiste à modifier la commande et les arguments exécutés dans le conteneur à l'aide des tableaux command et args dans un fichier yaml :

apiVersion : v1

genre: Pod

métadonnées :

Étiquettes:

exécuter : occupébox

nom: busybox

spécification :

conteneurs :

- commande :

- /bin/sh

arguments :

- -c

- tail -f /dev/null

image : boîte occupée

nom: busybox

Les configurations d'application et les informations d'identification peuvent être stockées dans le cluster en tant que ressources ConfigMap ou secrètes. Les conteneurs s'exécutant dans des pods peuvent utiliser ConfigMaps et Secrets en tant que volumes ou variables d'environnement. Les ConfigMaps peuvent être créés à partir de paires clé-valeur littérales ou à partir de fichiers. Ci-dessous, nous créons un ConfigMap à partir d'un fichier de configuration redis sur le disque.

$ chat redis.conf

lier 127.0.0.1

mode protégé oui

port 6379

tcp-arriéré 511

délai d'attente 0

tcp-garder en vie 300

$ kubectl create configmap --from-file redis.conf redisconf

configmap/redisconf créé

$ kubectl décrit configmap redisconf

Nom : redisconf

Espace de noms : par défaut

Étiquettes:

Annotations :

Données

====

redis.conf:

----

lier 127.0.0.1

mode protégé oui

port 6379

tcp-arriéré 511

délai d'attente 0

tcp-garder en vie 300

Événements:

$

Le fichier redis.conf est désormais disponible pour n'importe quel pod à utiliser et à monter. ConfigMaps est un bon moyen de rendre les fichiers de configuration courants disponibles pour les applications s'exécutant n'importe où dans un cluster Kubernetes. L'exemple ci-dessous montre un pod qui exécute redis à l'aide du fichier redis.conf stocké en tant que ConfigMap :

piVersion : v1

genre: Pod

métadonnées :

Étiquettes:

exécuter : redis-dev

nom : redis-dev

spécification :

conteneurs :

- commande :

- redis-serveur

- /config/redis.conf

  image: redis

nom : redis-dev

volumeMontages :

- nom : redis

chemin de montage : /config

tomes :

- nom : redis

configMap :

nom : redisconf

restartPolicy : OnFailure

Applications d'échelle

Les applications déployées à l'aide d'un contrôleur comme un Deployment ou un StatefulSet peuvent être augmentées ou réduites en modifiant le nombre de réplicas. La modification de la valeur de la clé de réplicas dans la spécification du contrôleur déclenchera une mise à jour du jeu de réplicas actuel de l'application qui augmente (ou réduit) le nombre de pods qui exécutent l'application. Cela se fait impérativement à l'aide de l'échelle kubectl :

$ kubectl scale deploy redis-prod --replicas=3

deploy.apps/redis-prod mis à l'échelle

$

Ou de manière déclarative en modifiant le YAML de la spécification du contrôleur et en l'appliquant au cluster :

$ nano redis-prod.yaml

apiVersion : apps/v1

genre : Déploiement

métadonnées :

Étiquettes:

application : retour-prod

nom: redis-prod

spécification :

répliques : 5

sélecteur:

matchÉtiquettes :

application : retour-prod

modèle:

métadonnées :

Étiquettes:

application : retour-prod

spécification :

conteneurs :

  - image: redis:4.0

nom : redis

$ kubectl applique -f redis-prod.yaml

deploy.apps/redis-prod configuré

$

Applications d'auto-guérison

Une application d'auto-guérison dans le contexte de Kubernetes :

Récupère automatiquement les conteneurs d'un état défectueux Assure qu'au moins une seule copie de l'application est en cours d'exécution à tout moment Maintenir une identité réseau cohérente

Les utilisateurs peuvent créer une application d'auto-réparation simple à l'aide d'un contrôleur pour maintenir un état souhaité (au moins un pod en cours d'exécution) et un service pour maintenir une identité réseau cohérente face à la suppression/récréation de pod.

$ kubectl create deploy apache-prod --image httpd

deploy.apps/apache-prod créé

$ kubectl expose deploy apache-prod --port 80

service/apache-prod exposé

$

Cela crée un déploiement, qui garantit qu'au moins une seule copie de l'application s'exécute à tout moment et un service qui maintient l'identité du réseau cohérente.

Une sonde d'activité configurée dans la spécification de déploiement fournit au kubelet de gestion du pod un moyen de vérifier si l'application est active.

apiVersion : apps/v1

genre : Déploiement

métadonnées :

Étiquettes:

application : apache-prod

nom: apache-prod

spécification :

avancementDélaiSecondes : 600

répliques : 1

sélecteur:

matchÉtiquettes :

application : apache-prod

modèle:

métadonnées :

creationTimestamp : null

Étiquettes:

application : apache-prod

spécification :

conteneurs :

- image : httpd

imagePullPolicy : Toujours

vivacitéSonde :

Seuil d'échec : 1

httpObtenir :

chemin: /

ports : 80

schéma : HTTP

périodeSecondes : 10

Seuil de réussite : 1

timeoutSecondes : 1

nom : httpd

Ressources: {}

TerminationMessagePath : /dev/termination-log

résiliationMessagePolicy : Fichier

dnsPolicy : ClusterFirst

restartPolicy : Toujours

Si le livenessProbe de cette sonde renvoie un échec, le kubelet indique au runtime du conteneur de redémarrer le conteneur et de ramener l'application d'un état défectueux.