[Artículos de recursos de Kubernetes] Explicación práctica detallada de la entrada del controlador de implementación

1. Teoría del controlador avanzado de implementación

Documentos oficiales de referencia chinos:

1. Introducción al controlador de implementación

La implementación es una abstracción de alto nivel de ReplicaSet. La implementación tiene todas las funciones que tiene el controlador ReplicaSet y la implementación que ReplicaSet no tiene. Por ejemplo, proporciona funciones de actualización y reversión graduales . La implementación controla múltiples ReplicaSets, lo que permite actualizaciones y reversiones sin inconvenientes.

Características del controlador de implementación:

• Selector: un ReplicaSet usa un selector de etiquetas para seleccionar qué réplicas de pod administrar.
• Escalabilidad: el controlador avanzado de implementación puede escalar automáticamente la cantidad de contenedores según la carga para satisfacer las necesidades de la aplicación.
• Autorreparación: los controladores avanzados de implementación pueden monitorear el estado de los contenedores y reiniciarlos o reemplazarlos automáticamente si fallan.
• Equilibrio de carga: el controlador avanzado de implementación puede distribuir solicitudes a diferentes instancias de contenedores a través de algoritmos de equilibrio de carga para mejorar el rendimiento y la disponibilidad de la aplicación.
• Control de versiones: la implementación puede especificar múltiples ReplicaSets, y cada ReplicaSet puede controlar diferentes versiones de Pods, para lograr la liberación y reversión en escala de grises.
• Declarativo: se refiere a modificar directamente el archivo yaml de la lista de recursos y luego cambiar los recursos a través de apply.

2. Principio de funcionamiento de la implementación

El controlador de implementación se basa en el controlador ReplicaSet y administra varios ReplicaSets. Cada vez que se actualiza la versión reflejada, se generará un nuevo ReplicaSet para reemplazar el antiguo ReplicaSet. Existen varios ReplicaSets al mismo tiempo, pero solo se ejecuta un ReplicaSet.

Como se muestra en la figura anterior: la versión ReplicaSet V1 controla tres Pods, la versión ReplicaSet V1 elimina un Pod y crea un nuevo Pod en la versión ReplicaSet V2, y así sucesivamente hasta que la versión ReplicaSet V2 se reemplace por completo.

Si hay un problema con la actualización de la versión V2 de ReplicaSet, se puede deshacer. La implementación se basa en el ReplicaSet. Múltiples ReplicaSets forman una implementación, pero solo un ReplicaSet está activo.

2. Escritura YAML de implementación y explicación de parámetros

Utilice explainla definición de la vista de comandos para ver deploymentlas descripciones de los campos del controlador:

kubectl explain deployment

1. Contenido de la lista general de recursos de implementación YAML:

cat demo-deployment.yaml 

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-deployment-1
  labels:
    env: uat
spec:
  replicas: 3
  minReadySeconds: 10  # 更新场景,等待时间,如果没有设置K8S会假设该容器启动起来后就提供服务了
  paused:  # 暂停,当更新Pod时,先暂停,而不是立马更新
  progressDeadlineSeconds: 60 # 更新场景,等待时间超过此值,状态标记False,并说明原因,但是它并不会阻止 Deployment 继续进行卡住后面的操作 
  strategy:
    rollingUpdate:        # 滚动更新,定义滚动更新方式,也就是pod能多几个,少几个
      maxSurge: 20%       # 允许更新中,最多超过Pod数值
      maxUnavailable: 20% # 允许更新中,最多允许几个不可用
  selector:
    matchLabels:
      app: demo-nginx
  template:
    metadata: 
      labels:
        app: demo-nginx
    spec:
      containers:
      - name: demo-nginx
        image: nginx
        imagePullPolicy: IfNotPresent
        startupProbe:      # 启动探测
          tcpSocket:
            port: 80
        livenessProbe:     # 存活探测 
          httpGet:
            port: 80
            path: /index.html
        readinessProbe:    # 就绪探测
          httpGet:
            port: 80
            path: "/index.html"

2. Explicación de los parámetros básicos:

• spec.minReadySeconds: escena de actualización, tiempo de espera, si no se establece, K8S asumirá que el contenedor proporcionará servicios después de que se inicie.
• spec.paused: en pausa, al actualizar el Pod, haga una pausa primero en lugar de actualizar inmediatamente, que se usará más adelante en la versión Canary
• spec.progressDeadlineSeconds: actualice la escena, el tiempo de espera supera este valor, el indicador de estado es falso y explique el motivo, pero no evita que la implementación continúe bloqueada.
• spec.strategy.rollingUpdate : actualización continua, define el método de actualización continua, es decir, cuántos pods se pueden agregar y cuántos menos
• spec.strategy.rollingUpdate.maxSurge: especifica la cantidad máxima de pods nuevos que se pueden crear durante una actualización. Por ejemplo, si maxSurge se establece en 1 y hay 3 pods en la implementación, se pueden crear 4 pods durante una actualización, 3 de los cuales son pods antiguos y 1 es un pod nuevo.
• spec.strategy.rollingUpdate.maxUndisponible: especifica la cantidad máxima de pods antiguos que se pueden detener simultáneamente durante una actualización. Por ejemplo, si maxUndisponible se establece en 1 y hay 3 pods en la implementación, se pueden detener 2 pods durante una actualización, 1 es el pod antiguo y 1 es el nuevo pod.

3. Estrategia de actualización de implementación:

La implementación actualmente admite dos estrategias de actualización

• Recrear: reconstruir la actualización, eliminar todos los Pods y volver a crear, el riesgo es muy alto, no se recomienda su uso

• rollingUpdate: actualización continua, actualización de reemplazo por lotes, actualización sin problemas, sin percepción del usuario

4. Fórmula de cálculo del porcentaje de política de actualización de implementación:

Suponiendo que hay 5 copias, como máximo una no está disponible, lo que significa que al menos 4 están disponibles

• maxSurge: 25% 5*25%=1.25(~=2) 5+2=7 disponible
• maxNo disponible: 25% 5%25%=1.25(~=1) 5-1=4 no disponible

3. Casos prácticos:

1. La implementación implementa el sitio WEB

Descarga del espejo del sitio WEB:

Importar imagen:

ctr -n=k8s.io images import  k8s_web.tar.gz

La lista de recursos es la siguiente:

cat web-deployment.yaml 

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
  labels:
    env: uat
spec:
  replicas: 5
  minReadySeconds: 10  
  progressDeadlineSeconds: 60 
  strategy:
    rollingUpdate:
      maxSurge: 20%       
      maxUnavailable: 20% 
  selector:
    matchLabels:
      app: web-nginx
  template:
    metadata: 
      labels:
        app: web-nginx
    spec:
      containers:
      - name: web-nginx
        image: web:v1
        imagePullPolicy: IfNotPresent
        startupProbe:
          tcpSocket:
            port: 80
        livenessProbe:
          httpGet:
            port: 80
            path: /index.html
        readinessProbe:
          httpGet:
            port: 80
            path: "/index.html"

Ejecute el archivo de manifiesto YAML:

kubectl apply -f web-deployment.yaml

Ver los recursos creados:

kubectl get pod,rs -l app=web-nginx

Visite el sitio WEB:

podIp=$(kubectl get pod -l app=web-nginx|awk NR==2|awk '{print $1}')
kubectl describe pod  ${podIp}|grep -w IP:|awk NR==1|awk '{print $NF}'

curl 10.244.235.214
web version = V1

2. La implementación amplía y reduce la capacidad de los sitios WEB

Expansión, expanda la copia a 7, modifique de acuerdo con el YAML anteriorspec.replicas=7

Una vez completada la modificación, ejecute aplicar de nuevo:

kubectl apply -f web-deployment.yaml

Ver el número de Pods:

kubectl get pods -l app=web-nginx|tail -n +2|wc -l

Reducción, reduzca la copia a 3, modifique de acuerdo con el YAML anteriorspec.replicas=3

Una vez completada la modificación, ejecute aplicar de nuevo:

kubectl apply -f web-deployment.yaml

Ver el número de Pods:

kubectl get pods -l app=web-nginx|tail -n +2|wc -l

3. Actualización continua de implementación para el sitio WEB

La actualización continua es un método de actualización altamente automatizado, es decir, los recursos del pod se actualizan lote por lote y la experiencia del usuario es relativamente fluida. Las actualizaciones de rollover spec.strategy.rollingUpdatese definen usando el campo.

Realice una actualización gradual basada en la lista de recursos YAML anterior y reemplace la versión reflejada con V2 YAML de la siguiente manera:

cat web-deployment.yaml 
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
  labels:
    env: uat
spec:
  replicas: 5
  minReadySeconds: 10  
  progressDeadlineSeconds: 60 
  strategy:
    rollingUpdate:
      maxSurge: 30%         # 5*30%=1.5(~=2), 2+5=7,更新期间最多创建7个Pod 
      maxUnavailable: 20%   # 5*20%=1, 1-5=4,更新期间最多停止4个Pod
  selector:
    matchLabels:
      app: web-nginx
  template:
    metadata: 
      labels:
        app: web-nginx
    spec:
      containers:
      - name: web-nginx
        image: web:v2    # 版本更新
        imagePullPolicy: IfNotPresent
        startupProbe:
          tcpSocket:
            port: 80
        livenessProbe:
          httpGet:
            port: 80
            path: /index.html
        readinessProbe:
          httpGet:
            port: 80
            path: "/index.html"

Ejecute el archivo YAML:

kubectl apply -f web-deployment.yaml

Visite el sitio WEB:

podIp=$(kubectl get pod -l app=web-nginx|awk NR==2|awk '{print $1}')
kubectl describe pod  ${podIp}|grep -w IP:|awk NR==1|awk '{print $NF}'

curl 10.244.235.236
web version = V2

Puede ver que el contenido del sitio web WEB se ha actualizado a V2

4. La implementación revierte la versión del sitio WEB

Ver versiones históricas:

kubectl rollout history deployment web-deployment

Versión revertida: reversión a la versión V1

kubectl rollout undo deployment web-deployment --to-revision=1

Visite el sitio WEB:

podIp=$(kubectl get pod -l app=web-nginx|awk NR==2|awk '{print $1}')
kubectl describe pod  ${podIp}|grep -w IP:|awk NR==1|awk '{print $NF}'

curl 10.244.235.231
web version = V1

Puede ver que el contenido de la web WEB ha sido actualizado a la versión V1

4. Versión de implementación azul-verde

1. Introducción a la implementación azul-verde

En el despliegue azul-verde, se requieren dos sistemas, uno es el sistema que está brindando servicios, marcado en verde , y el otro es el sistema listo para ser liberado, marcado en azul , los dos sistemas son completamente funcionales, solo el verde brinda servicios al mundo exterior, y el azul El color se usa para las pruebas previas al lanzamiento. Si no hay ningún problema en la prueba, el sistema se puede actualizar a azul.

Durante un período de tiempo después del cambio, los sistemas azul y verde coexisten. Después de observar que el sistema azul está realmente bien, elimínelo y recicle los recursos.

• Ventajas: Los dos sistemas significan que solo necesita cambiar la ruta o cambiar el servidor DNS, con bajo riesgo y alta eficiencia.
• Desventajas: Los dos sistemas coexisten y consumen muchos recursos.

2. Caso: realizar una implementación azul-verde

K8S no es compatible con la implementación azul-verde. ¡Necesitamos planificar y crear diferentes implementaciones y servicios para cambiar entre diferentes tráficos!

• Cree el sistema verde (versión 1) YAML de la siguiente manera:

cat green-demo.yaml 

---
apiVersion: v1
kind: Namespace
metadata:
  name: blue-green-demo
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: green-app
  namespace: blue-green-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: green-app
  template:
    metadata:
      name: green-app
      labels: 
        app: green-app
    spec:
      containers:
      - name: green-app
        image: web:v1
        imagePullPolicy: IfNotPresent
        startupProbe:
          tcpSocket:
            port: 80
        livenessProbe:
          httpGet:
            port: 80
            path: "/index.html"
        readinessProbe:
          httpGet:
            port: 80
            path: "/index.html"

Cree un sistema de agente de servicio verde (primera versión):

cat blue-green-svc.yaml

---
apiVersion: v1
kind: Service
metadata:
  name: blue-green-svc
  namespace: blue-green-demo
spec:
  type: NodePort
  ports:
  - port: 80
    nodePort: 30010
    name: http
  selector:
    app: green-app

Ejecute el archivo YAML:

kubectl apply -f green-demo.yaml 
kubectl apply -f blue-green-svc.yaml

Ver recursos de creación:

kubectl get pod,svc -n blue-green-demo

IP de acceso al navegador: 30010

• Cree el sistema azul (versión 2) YAML de la siguiente manera :

cat blue-deom.yaml 
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: blue-app
  namespace: blue-green-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: blue-app
  template:
    metadata:
      name: blue-app
      labels: 
        app: blue-app
    spec:
      containers:
      - name: blue-app
        image: web:v2
        imagePullPolicy: IfNotPresent
        startupProbe:
          tcpSocket:
            port: 80
        livenessProbe:
          httpGet:
            port: 80
            path: "/index.html"
        readinessProbe:
          httpGet:
            port: 80
            path: "/index.html"

Ejecute el archivo de manifiesto de recursos YAML:

kubectl apply -f  blue-deom.yaml

• cambiar

Solo necesita modificar la etiqueta de selección en el Servicio. El servicio se modifica de la siguiente manera:

cat blue-green-svc.yaml 
---
apiVersion: v1
kind: Service
metadata:
  name: blue-green-svc
  namespace: blue-green-demo
spec:
  type: NodePort
  ports:
  - port: 80
    nodePort: 30010
    name: http
  selector:
    app: blue-app  # 关联蓝色系统Pod标签

Ejecute el archivo YAML:

kubectl apply -f  blue-green-svc.yaml

El navegador actualiza la página de acceso:

Lo mismo es cierto para la reversión, ¡solo necesita modificar el Servicio para cambiar la etiqueta del Pod proxy!

5. Implementación Canary (escala de grises)

2. Introducción a la implementación de Canary

La implementación canaria, también conocida como implementación en escala de grises, permite que las nuevas versiones se implementen gradualmente en el entorno de producción para garantizar la estabilidad y confiabilidad de la nueva versión. En una versión Canary, se prueba una nueva versión de la aplicación con solo un pequeño grupo de usuarios y, si no hay problemas, se expande gradualmente hasta que todos los usuarios estén usando la nueva versión. Este enfoque reduce el riesgo de problemas con las nuevas versiones de la aplicación, al mismo tiempo que garantiza que la experiencia del usuario no se vea muy afectada.

• Ventajas: políticas flexibles y personalizadas, implementación canary basada en el tráfico o el contenido, los problemas no afectarán a todos los usuarios de la red.

• Desventajas: no cubre a todos los usuarios de la red y es difícil solucionar problemas.

3. Caso: Implementación de la implementación de Canary

Primero cree un recurso de implementación, usando web:V1la creación de reflejo

cat deploy-demo.yaml 
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-demo
spec:
  replicas: 5
  selector:
    matchLabels:
      app: web-nginx
  template:
    metadata:
      name: nginx
      labels: 
        app: web-nginx
    spec:
      containers:
      - name: web-nginx
        image: web:v1
        imagePullPolicy: IfNotPresent
        startupProbe:
          tcpSocket:
            port: 80
        livenessProbe:
          httpGet:
            port: 80
            path: "/index.html"
        readinessProbe:
          httpGet:
            port: 80
            path: "/index.html"

---
apiVersion: v1
kind: Service
metadata:
  name: deploy-demo-svc
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 80
    nodePort: 30011
    name: http
  selector:
    app: web-nginx

Ejecute el archivo YAML:

kubectl apply -f deploy-demo.yaml 

Actualización de versión, lanzamiento canario , use la actualización de pausa 版本更新为V2al actualizarpause

kubectl set image deployment deploy-demo web-nginx=web:v2 && kubectl rollout pause deployment deploy-demo

Explicación de la sintaxis del comando anterior:

# 更新镜像为web:v2
kubectl set image deployment {
    
    deploy控制器名称} {
    
    容器名称}=web:v2 

Acceso al navegador: actualice la página y aparecerá una página diferente, porque solo se ha actualizado una parte

Si no hay ningún problema con la nueva versión después de la prueba, puede usar Despausa para actualizar todo a la versión web:v2

kubectl rollout resume deployment deploy-demo

V. Resumen

• El controlador avanzado de implementación se basa en el ReplicaSet. Cada vez que se actualice la versión de la imagen, se generará un nuevo ReplicaSet para reemplazar el antiguo. Existen varios ReplicaSets al mismo tiempo, pero solo se ejecuta un ReplicaSet.

• Expansión y contracción del despliegue: modifica directamente replicasel valor del campo y reinicia apply.

• Actualización sucesiva de la implementación: Utilice spec.strategylos campos para definir la estrategia de actualización. Actualmente, se admiten dos estrategias de actualización:

  • rollingUpdate actualización continua: actualización de reemplazo por lotes, actualización suave, sin percepción del usuario.
  • Vuelva a crear la reconstrucción e intente actualizar: elimine todos los pods y vuelva a crearlos, lo cual es muy arriesgado y no se recomienda.

• Reversión de la versión de implementación: se usa rollout historypara ver la versión histórica y usar rollout undo .... --to-revision=xla versión de reversión especificada.

• Versión azul-verde: Cree dos sistemas y use el Servicio modificado para asociar la carga de la etiqueta del Pod al sistema correspondiente.

• Lanzamiento Canary: Solo se actualiza una pequeña parte de los Pods. Si no hay problema, se están realizando todas las actualizaciones. Si hay problema, no afectará a todos los usuarios.