Actualización continua: ¿Cómo lograr una actualización y una degradación de la aplicación sin problemas?

La función de "escalado de aplicaciones" de Deployment es una operación común y operación de mantenimiento. En Kubernetes, usando el comando kubectl scale, podemos ajustar fácilmente la cantidad de Pods en Deployment. Debido a que StatefulSet es un caso especial de Deployment, también se puede usar Escala kubectl para lograr el "escalado de aplicaciones".

Además del "escalamiento de la aplicación", ¿qué se debe hacer para otras operaciones de operación y mantenimiento, como la actualización de la aplicación y la reversión de la versión? Estos también son problemas que encontramos a menudo en nuestra operación y mantenimiento diarios.

En Kubernetes, la actualización de la versión no usa objetos API, sino dos comandos: kubectl apply y kubectl rollout. Por supuesto, también deben combinarse con archivos YAML como Deployment y DaemonSet necesarios para implementar aplicaciones.

En Kubernetes, las aplicaciones se ejecutan en forma de Pods, y los Pods generalmente son administrados por objetos como Deployment, por lo que la "actualización de la versión" de la aplicación en realidad actualiza todo el Pod.

El cambio de versión que se aplica en Kubernetes es el cambio del Pod en la plantilla, aunque solo se cambie un campo de la plantilla, formará una nueva versión, que también es un cambio de versión.

 En la salida del estado de implementación de kubectl, Kubernetes no destruye todos los Pods antiguos y crea nuevos Pods a la vez, sino que crea nuevos Pods uno por uno y destruye los Pods antiguos al mismo tiempo para garantizar que siempre haya suficientes Pods ejecutándose en el sistema. No habrá interrupción del servicio por "ventana".

El proceso de aumentar la cantidad de Pods nuevos es un poco como "bola de nieve", comenzando desde cero y creciendo cada vez más, por lo que esta es la llamada "actualización continua".

Durante el proceso de actualización de la aplicación, puede usar kubectl rollout pause para pausar la actualización en cualquier momento, revisar y modificar el Pod, o probar y verificar. Si no hay problema, use kubectl rollout resume para continuar con la actualización.

Si desea volver a la versión anterior, puede usar el comando kubectl rollout undo o agregar el parámetro --to-revision para volver a cualquier versión histórica.

El proceso de operación de kubectl rollout undo es en realidad el mismo que el de kubectl apply. La ejecución aún es una "actualización continua", pero se usa la plantilla de Pod de la versión anterior, la cantidad de Pods de la versión nueva se reduce a 0 y la versión anterior Los pods se expanden al valor especificado.

Simplemente agregue un nuevo campo de anotaciones a los metadatos de la implementación.

El significado del campo de anotaciones es "anotación" y "comentario". En forma, es lo mismo que las etiquetas, las cuales son clave-valor, y también agregan información adicional al objeto API, pero el uso es muy diferente. .

  • La información agregada por las anotaciones generalmente se usa para varios objetos dentro de Kubernetes, que es un poco como "atributos extendidos";
  • Las etiquetas son principalmente para usuarios fuera de Kubernetes y se utilizan para filtrar y filtrar objetos.

Si usa una metáfora simple, las anotaciones son las instrucciones del producto en la caja y las etiquetas son las etiquetas autoadhesivas fuera de la caja.

Con la ayuda de las anotaciones, Kubernetes puede agregar información adicional arbitraria a los objetos API sin destruir la estructura del objeto ni agregar nuevos campos. Este es el típico "principio de apertura y cierre" de OCP en el diseño orientado a objetos, lo que hace que los objetos sean más escalables y flexibles.

Este artículo es una nota de estudio para el día 21 de julio. El contenido proviene del "Curso práctico introductorio de Kubernetes" de Geek Time . Se recomienda este curso.

Supongo que te gusta

Origin blog.csdn.net/key_3_feng/article/details/131859990
Recomendado
Clasificación