Kubernetes POD combat de mise à niveau du conteneur

Les mises à jour du site traditionnel, généralement tous les hors de service, puis les mises à jour d'affaires et arrêt de configuration, puis redémarrez le service. Ce modèle a été totalement incapable de répondre aux besoins de développement.
forte concurrence, les systèmes de haute disponibilité populaire aujourd'hui, mise à niveau de mise à jour de service moins à faire « affaires sans interruption. » Le roulement (-mise à jour de roulement) juste pour répondre à ce besoin d' une mise à niveau du système du programme.
Capotage est plus d'une instance du service ne soit pas interrompu les services de mise à niveau de mise à jour. En règle générale, par exemple multi-services, en utilisant une mise à jour rouler chaque instance , un par un plutôt que en même temps une mise à jour séparée à toutes les instances de toutes les mises à jour.

Kubernetes dans kubectl cli outil fournit un support roulant pour le contrôleur de mise à jour de réplication visualiser uniquement les informations instruction kubectl -help;

Kubernetes POD combat de mise à niveau du conteneur

1. Vérifier les mises à jour chaque conteneur pod groupe de navires

Note: Cette commande est généralement dans le renversement, vous utilisez toujours la vue.

kubectl get deployment -n default
#default为默认的命名空间，一般来说企业中会指定地域作为命名空间

• SOUHAITEE nombre final désiré de copies à l'état prêt;
• COURANT Le nombre total actuel de copies;
• UP-TO-DATE numéro en cours mis à jour des copies est terminée;
• DISPONIBLE actuellement disponibles des copies;

Spécifiez l'espace de noms:
Vous pouvez modifier le fichier YAML modifier les valeurs des paramètres ci - dessus, puis kubectl créé. Aussi:
Cliquez sur Créer, cliquez sur Options avancées, vous pouvez créer un espace de noms.

2, voir l'opération de groupe pod

kubectl get pod -n default

3, voir le déploiement de l'effet de l'information

kubectl describe deployment registry-wujincheng-com -n default

4, mise à jour de mise à niveau du conteneur

source d'entrepôt dans le miroir pour faire avancer les dernières mises à jour, exécutez la commande suivante pour mettre à jour la version de l'image, (avant la mise à niveau doit veiller à ce qu'il y ait une source d'entrepôt en miroir le dernier soumis)

kubectl set image deployment/tomcat-wujincheng-com tomcat-wujincheng-com=docker.io/nginx  -n default

5, voir le processus de mise à jour contenant la mise à niveau

kubectl -n default rollout status deployment/tomcat-wujincheng-com

Note: En général, nous mettons à jour la valeur par défaut est une mise à jour d'un.

注：首先说明tomcat这个pod组里只有4个容器，DESIRED从更新开始到结束都等于pod组里的容器数，表示最终应该有多少个容器处于READY状态，当前更新完成的容器为2，当前可用容器数为3，一个一个更新，所以只会有一个处于不可用状态，所以更新过程中，这个状态一直都为3.

Je mets les changements ci - dessus dans les états respectifs au cours du processus de mise à jour sont exprimés en.
Pourquoi payer l' attention au prochain point courant au - delà du 4, 5 devient.

6, un processus de retournement détaillé

La figure comprise en liaison avec le mode opératoire détaillé ci - dessous:
2 + 3 est égale à 5. Une copie du nombre total actuel de la
procédure de roulement:
noter ici que le récipient est un cas dans lequel chaque mise à jour.

• Création d'une nouvelle série de répliques, et d'attribuer deux nouvelles versions du conteneur, la destruction des anciennes versions du conteneur 1, ce qui porte le total à 5 ​​exemplaires, tout est normal.
• Notification de nouvelle série de répliques, créer et exécuter un récipient, portant le nombre total de copies disponibles maintenue à 3, avec la normale.
• Quand une ancienne copie et détruire avec succès, informer le nouveau jeu de réplicas, créer et exécuter une nouvelle version du conteneur, de sorte que la nouvelle version du nombre total de conteneurs jusqu'à 4, tout est normal.
• Lorsqu'une nouvelle version du nombre total de conteneurs a atteint DÉSIRÉ, ne sera plus créer le conteneur, la destruction d'une ancienne copie du conteneur, vous pouvez exécuter une nouvelle version du conteneur.

Résumé: En capotage de fait, qui est la copie originale de la destruction continue de mettre le récipient jusqu'à la destruction complète. Créer un nouveau conteneur de plus en plus ensemble réplique (copie), jusqu'à ce qu'il atteigne le nombre désiré. Il suffit de lancer entre la destruction et à la création associée à
elle!

7, la restauration de la version du conteneur

Rouleau Retour à la version (une version) avant la mise à jour:

kubectl rollout undo deployments/tomcat-wujincheng-com -n default

8, pour voir si un rollback

kubectl -n default rollout status deployments/nginx-v1

Nous commençons à changer tomcat nginx, après l'annulation doit être un tomcat.
kubectl describe pod/tomcat-wujincheng-com-3184522042-0jh7q -n default
succès Rollback!
commande clé avec le résumé:

kubectl get pod -n default
kubectl describe pod/tomcat-wujincheng-com-3184522042-0jh7q -n default

kubectl get deployment -n default
kubectl describe deployment/tomcat-wujincheng-com -n default

kubectl get svc -n default
kubectl describe svc/kubernetes -n default

9, à l'image du groupe de conteneurs version historique de dosette

(1) Voir une fois déployé la version

kubectl rollout history deploy/tomcat-wujincheng-com

(2) Voir les détails d'une version

kubectl rollout history deployment/tomcat-wujincheng-com --revision=8

(3) K8S arrière du rouleau à une version du support parfait

kubectl rollout undo deployment/tomcat-wujincheng-com  --to-revision=2  -n default

10, le nombre de récipients prévus dans chaque mise à jour

K8S contrôle avec précision le processus de publication, par lots de roulement ordonné de manière, jusqu'à ce que toutes les anciennes copies de toutes les mises à jour pour la nouvelle version. En effet K8S par deux paramètres pour contrôler avec précision le nombre par rouleau pod:

• maxSurge, roulant initiée lors de l'opération de mise à jour POD désiré nombre maximum de copies peut être absolue (par exemple 5), mais ne peut pas être égal à zéro, ou peut être un pourcentage (par exemple 10%), valeur par défaut est de 25%;
• Le nombre maximal de pod utilisé maxUnavailable, un processus de retournement ne peut pas, peut être absolue (par exemple 5), mais ne peut pas être égal à zéro, ou peut être un pourcentage (par exemple 10%), valeur par défaut est de 25%;

Remarque: Ces deux valeurs sont généralement les mêmes!
Si ces deux paramètres en option n'est pas spécifié, les K8S de configuration par défaut cherchera les instructions de configuration par défaut sont les suivantes:

kubectl get deployment tomcat-wujincheng-com -o yaml  -n default

Modifier maxSurge, valeur maxUnavailable:

Succès!

11, supprimer l'état anormal du récipient

Comment supprimer?
Supprimer cette façon peut pas se permettre!

kubectl delete pod tomcat-wujincheng-com-4175885076-j1vnz –grace-period=0 --force -n default 

Une commande pour obtenir:

for i in `kubectl get pod -n default|awk '{print $1}'|grep tomcat-wujincheng-com-4175885076`;do kubectl delete pod $i –grace-period=0 --force -n default;done

Si ce groupe de conteneurs et l'utiliser, après cette suppression, il redéposer le conteneur approprié.

Supprimer tout navire porte-conteneurs commande groupe tomcat-wujincheng-com où:

for i in `kubectl get pod -n default|awk '{print $1}'|grep tomcat-wujincheng-com`;do kubectl delete pod $i –grace-period=0 --force -n default;done

Retirez ensuite complètement le groupe de conteneurs, le besoin correspondant au premier Déployez le service, supprimez tous les jeux de répliques, ce cliquez sur le bouton Supprimer interface K8S , groupe contenant uniquement du navire Masqués seulement besoin de commande, peut être complètement supprimé.

Note: La photo ci - dessus fait le conteneur, ainsi que le groupe de conteneurs, puis continuer à exécuter sur commande fou!
Supprimé avec succès tomcat-wujincheng-com groupe de conteneurs!