Exemple de démonstration du contrôleur de pod Kubernetes

Contrôleur de pod

Le concept de contrôleur
k8s intègre de nombreux contrôleurs (contrôleurs), qui sont équivalents à une machine à états, utilisés pour contrôler l'état et le comportement spécifiques du Pod

Classification différente du cycle de vie

• Pod autonome: le pod sort, ce type de pod ne sera pas créé

• Pod géré par le contrôleur: pendant le cycle de vie du contrôleur, le nombre de copies du pod doit toujours être maintenu

Type de contrôleur

• ReplicationController 和 ReplicaSet
• Déploiement
• DaemonSet
• StateFulSet
• Emploi / ConJob
• Mise à l'échelle automatique du pod horizontal

❤Voir les articles précédents pour plus de détails
Type de contrôle du pod

Instance de contrôleur

1. RS et RC sont associés à Deployment RC (ReplicationController)

La fonction principale est de s'assurer que le nombre de copies de l'application conteneur reste toujours au nombre de copies défini par l'utilisateur. Autrement dit, si un conteneur sort anormalement, un nouveau pod sera automatiquement créé pour le remplacer; et si le conteneur anormalement supplémentaire est également automatiquement recyclé

Kubernetes recommande officiellement d'utiliser RS ​​(ReplicaSet) au lieu de RC (ReplicationController) pour le déploiement. RS n'est pas essentiellement différent de RC, mais le nom est différent et RS prend en charge les sélecteurs collectifs

Voir les informations complètes sur le modèle RS: kubectl explique rs
vim rs.yaml

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: frontend
spec: 
  replicas: 3  # 3个副本
  selector: # 选择标签
    matchLabels: # 匹配标签，匹配上就是rs的
      tier: frontend  # keys:values
  template: # 模板，后面是pod属性
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: myapp
        image: hub.atguigu.com/library/myapp:v1
        env: # 注入环境变量
        - name: GET_HOSTS_FROM
          value: dns
        ports:
        - containerPort: 80

kubectl delete pod --all
kubectl create -f rs.yaml
kubectl get pod
kubectl get pod --show-labels
kubectl label pod frontend-2q74g tier = frontend1 --overwrite = True
kubectl get pod --show-labels
trouvera quatre Un, le quatrième est le précédent 3, car le nombre de copies rs est de 3, et la correspondance d'étiquette ne peut correspondre qu'à l'interface, car il n'y en a que deux et un nouveau rvckj doit être créé pour atteindre la valeur attendue de 3.

Ensuite, supprimez le rs et trouvez qu'il existe un
kubectl qui n'est pas géré par rs. Delete rs --all
kubectl get pod --show-labels

 

2. Association entre RS et déploiement

Le déploiement fournit une méthode déclarative permettant au pod et au ReplicaSet de remplacer l'ancien ReplicationController afin de faciliter les applications de gestion. Les scénarios d'application typiques incluent:

• Définir le déploiement pour créer un pod et un ReplicaSet
• Mise à niveau et restauration progressives
• Expansion et contraction de l'application
• Suspendre et reprendre le déploiement

★ Déployez une application Nginx simple

1创建 创建
vim deployment.yaml
kubectl apply -f deployment.yaml --record

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: myapp
        image: hub.atguigu.com/library/myapp:v1
        ports:
        - containerPort: 80

kubectl create -f https://kubernetes.io/docs/user-guide/nginx-deployment.yaml --record ## --record paramètre peut enregistrer la commande, nous pouvons facilement vérifier les changements de chaque révision

La création du déploiement créera les rs correspondants, qui sont déterminés par 7bb4cb8f64 et les étiquettes.

2. Expansion
kubectl scale deployment nginx-deployment --replicas 10
expansion et contraction sans état

3. Si le cluster prend en charge l'
autoscaling horizontal des pods, vous pouvez également définir l'extension automatique kubectl autoscale deployment nginx-deployment --min = 10 – max = 15 – cpu-percent = 80 pour le déploiement

4. Il est également relativement simple de mettre à jour l'image.
Déploiement d'image set kubectl / nginx déploiement monapp (nom du conteneur) =
wangyanglinux / myapp: v2
. La modification de kubectl get rs l' image déclenche la création de rs, comme mentionné précédemment. Les opérations de mise à jour et de restauration se feront dans un processus alternatif de pod

5. Rollback
kubectl rollout undo deployment / nginx-deployment
update and rollback operations will be in the pod alternative process

3. Déploiement de mise à jour

Stratégie de mise à jour du déploiement

• Le déploiement peut garantir que seul un certain nombre de pods sont en panne pendant la mise à niveau. Par défaut, il s'assurera qu'au moins un pod de moins que le nombre prévu de pods est actif (au plus un n'est pas disponible)
• Le déploiement peut également garantir que seul un certain nombre de pods dépassant le nombre attendu sont créés. Par défaut, cela garantira qu'au plus un pod de plus que le nombre prévu de pods est en hausse (au plus 1 surtension)
• Dans la future version de Kuberentes, il passera de 1-1 à 25% -25%

déploiement de descirbe kubectl

Survol (plusieurs déploiements en parallèle)

Supposons que vous créez un déploiement avec 5 répliques nginx: 1.7.9, mais lorsque seulement 3 répliques nginx: 1.7.9 sont créées, vous commencez à mettre à jour le déploiement avec 5 répliques nginx: 1.9.1. Dans ce cas, le déploiement tuera immédiatement les 3 pods nginx: 1.7.9 qui ont été créés et commencera à créer des pods nginx: 1.9.1 . Il n'attendra pas que les 5 pods nginx: 1.7.9 soient créés avant de commencer à changer de cap

回 退 Déploiement

kubectl set image deployment/nginx-deployment nginx=nginx:1.91

查看当前的回滚状态：kubectl rollout status deployments nginx-deployment

查看历史版本：kubectl rollout history deployment/nginx-deployment

如果创建的时候加了record，那么CHANGE-CAUSE才会记录

kubectl rollout undo deployment/nginx-deployment

可以使用 --revision参数指定某个历史版本：kubectl rollout undo deployment/nginx-deployment --to-revision=2

暂停 deployment 的更新：kubectl rollout pause deployment/nginx-deployment   

Vous pouvez utiliser la commande kubectl rollout status pour vérifier si le déploiement est terminé. Si le déploiement est terminé avec succès, kubectl rolloutstatus renverra un code de sortie de 0

kubectl rollout status deployments nginx-deployment
echo $?

Politique de nettoyage

Vous pouvez définir l'élément .spec.revisonHistoryLimit pour spécifier le nombre maximal d'enregistrements d'historique des révisions conservés par le déploiement. Par défaut, toutes les révisions seront conservées; si cet élément est défini sur 0, le déploiement n'autorisera pas la restauration

 

4 、 DaemonSet

daemonset.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: daemonset-example  # 对应1 与对应2 要一致
  labels:
    app: daemonset
spec:
  selector:
    matchLabels:
      name: daemonset-example  # 对应2  pod
  template:
    metadata:
      labels:
        name: daemonset-example
    spec:
      containers:
      - name: daemonset-example
        image: wangyanglinux/myapp:v1
        # 模板可以复杂点，init C,start stop,readiness等

kubectl create -f daemonset.yaml
kubectl get pod -o wide
master node ne sera pas créé par défaut

kubectl delete pod daemonset-example-t5fzc

 

5. Job et CronJob

vim job.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    metadata:
      name: pi
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]  # 圆周率计算小数点
      restartPolicy: Never

kubectl create -f job.yaml
kubectl describe pod pi-9vt9h Afficher l'état d'exécution

kubectl get job #look à la tâche en cours

Vérifiez le résultat, obtenez les 2000 chiffres de Pi, corrigez

 

6 、 CronJob

Le déploiement gère le pod en créant rs, tandis que
CronJob gère en créant un pod pour gérer les tâches temporelles, à savoir:

• Exécuter une seule fois à un moment donné
• Exécuter périodiquement à un moment donné
• Prérequis pour l'utilisation: le cluster Kubernetes actuellement utilisé, version> = 1.8 (pour CronJob). Pour la version précédente du cluster, version <1.8, lors du démarrage du serveur API, transmettez l'option -runtime-config = batch / v2alpha1 = true pour activer batch / v2alpha1API

L'utilisation typique est la suivante:

• Planifier l'exécution de la tâche à un moment donné
• Créez un travail qui s'exécute périodiquement, par exemple: sauvegarde de la base de données, envoi de courrier électronique

vim cronjob.yaml

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"  # 调度的时间
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date;echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

kubectl apply -f cronjob.yaml
kubectl obtenir cronjob
kubectl obtenir des travaux
et vérifier le journal pour vérification.

[root@k8s-master01 ~]# vim cronjob.yaml
[root@k8s-master01 ~]# kubectl apply -f cronjob.yaml 
cronjob.batch/hello created
[root@k8s-master01 ~]# kubectl get cronjob
NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
hello   */1 * * * *   False     0        <none>          15s
[root@k8s-master01 ~]# kubectl get job
NAME               COMPLETIONS   DURATION   AGE
hello-1601467260   1/1           9s         90s
hello-1601467320   1/1           10s        30s
[root@k8s-master01 ~]# kubectl get pod
NAME                     READY   STATUS      RESTARTS   AGE
hello-1601467260-466fs   0/1     Completed   0          108s
hello-1601467320-c5b5b   0/1     Completed   0          48s
[root@k8s-master01 ~]# kubectl log hello-1601467260-466fs
log is DEPRECATED and will be removed in a future version. Use logs instead.
Wed Sep 30 12:01:13 UTC 2020
Hello from the Kubernetes cluster
[root@k8s-master01 ~]# kubectl log hello-1601467320-c5b5b
log is DEPRECATED and will be removed in a future version. Use logs instead.
Wed Sep 30 12:02:14 UTC 2020
[root@k8s-master01 ~]# kubectl delete cronjob --all
cronjob.batch "hello" deleted

Quelques limites de CrondJob lui-même: l'opération de création d'un Job doit être idempotente. Le
succès de CrondJob n'est pas facile à juger, il ne sera responsable que de la création du Job, mais le succès du Job peut être jugé

StateFullSet et HPA, les connaissances temporaires ne suffisent pas à prendre en charge, à plus tard