Implementación

Puede que se pregunte por qué Kubernetes tiene objetos diferentes para hacer casi el mismo trabajo. Como se mencionó anteriormente, las características de RC se han ampliado a través de RS y la implementación. Hemos’visto el RS, que ha hecho el mismo trabajo de RC, solo con un formato de selector diferente. Ahora vamos’a desproteger el otro objeto nuevo, implementar – la implementación y explorar las características que provienen.

Crear una implementación

Si simplemente cambia el atributo Kind de ReplicaSet a Deployment,’obtendrá el archivo YAML de un objeto de implementación:

Crear una implementación con el kubectl mando

En realidad, la implementación es un nivel de abstracción relativamente superior al de RC y RS. La implementación no crea un conjunto Pod directamente, y el comando Descripción revela lo siguiente:

Flujo de trabajo de implementación

Cuando se crea una implementación, se crea automáticamente un conjunto de réplicas. Los pods definidos en el objeto de implementación se crean y supervisan mediante’la implementación s REPLICASET.

El flujo de trabajo se muestra en la Figure 1:

Figure 1: Flujo de trabajo de implementación

Es posible que aún se pregunte por qué es necesario utilizar RS como una capa más en el mismo nivel’de implementación y en la siguiente respuesta.

Actualización sucesiva

La característica actualización sucesiva es una de las características más eficaces que incluye el objeto de implementación. A’continuación, demuestre la característica con un caso de prueba para explicar cómo funciona.

Caso de prueba: Actualización sucesiva

Suponga que tiene una nginx-deployment, con réplica = 3 y 1.7.9 de imagen Pod. Deseamos actualizar la imagen de la versión 1.7.9 a la nueva versión 1.9.1 de la imagen. Con kuberctl puede usar la opción definir imagen y especificar el nuevo número de versión para activar la actualización:

Ahora vuelva a comprobar la información de la implementación:

Hay dos cambios que puede observar aquí:

• Se actualiza la versión de la imagen en la implementación

• Se crea un nuevo RS nginx-Deployment-6fdbb596db, con una réplica establecida en 1

Y con el nuevo RS con la réplica en 1, se genera un nuevo conjunto Pod (el cuarto):

El nuevo conjunto Pod se proporciona con la nueva imagen:

Mientras la antigua caja Pod aún está en la imagen antigua:

’Esperemos y siga comprobando el estado… de los pods finalmente se terminarán todos los pods antiguos y se ejecutarán – tres nuevos pods los nombres Pod confirmamos que son nuevos:

Así que la actualización se realiza y todos los pods se ejecutan con la nueva versión de la imagen.

Cómo funciona

Espera, es posible que esto no se actualice, se debe llamar un reemplazo, ya que Kubernetes utilizó tres nuevos pods con nuevas imágenes para reemplazar los pods antiguos. Hablando de forma precisa, esto es cierto. Pero así es cómo funciona. La’filosofía de Kubernetes s es que los pods son más baratos, – y la sustitución es fácil Imagínese qué cantidad de trabajo será cuando tenga que iniciar sesión en cada conjunto Pod, desinstalar imágenes antiguas, limpiar el entorno, solo para instalar una nueva imagen. Veamos’más detalles de este proceso y comprenda por qué se denomina actualización sucesiva.

Cuando se actualiza la caja Pod con nuevo software, el objeto de implementación introduce un nuevo RS que iniciará el proceso de actualización del conjunto Pod. La idea aquí es no iniciar sesión en el conjunto Pod existente y, en su lugar, hacer que la imagen se actualice en contexto, el nuevo RS crea simplemente un nuevo conjunto Pod equipado con el nuevo lanzamiento de software. Una vez que este nuevo conjunto (y adicional) esté activo y en funcionamiento, el RS original se reducirá en uno, por lo que el número total de pods en marcha permanecerá sin cambios. El nuevo RS continuará utilizándose en una sola vez y el original de RS se reducirá en una escala. Este proceso se repite hasta que el número de pods creado por el nuevo RS alcance el número de réplica original definido en la implementación, y eso es cuando se terminan todos los pods de RS originales. El proceso se representa en la Figure 2.

Figure 2: Introducción a la implementación

Como puede ver, todo el proceso de crear un nuevo RS, escalar el nuevo RS, y reducir simultáneamente el antiguo uno al mismo tiempo, está completamente automatizado y se encarga de todo el objeto de implementación. Es una implementación que está implementando y impulsando el objeto ReplicaSet, que, en este sentido, funciona solo como un back-end.

Por este motivo, la implementación se considera un objeto de capa superior en Kubernetes y la razón por la que se recomienda oficialmente que no utilice nunca ReplicaSet solo, sin implementación.

Record

La implementación también tiene la capacidad de registrar todo el proceso de las actualizaciones sucesivas, por si es necesario, puede revisar el historial de actualizaciones después de que finalice el trabajo de actualización:

Pausa/reanudar/deshacer

Además, también puede pausar/reanudar el proceso de actualización para comprobar los cambios antes de continuar:

Puede incluso deshacer la actualización cuando se producen errores durante la ventana de mantenimiento:

Normalmente, esto se hace cuando se rompe algo en la implementación. En comparación con la cantidad de trabajo que se tarda en preparar para actualizar el software durante las ventanas de mantenimiento de los viejos tiempos, ésta es una característica sorprendente para todo el que sufrió la actualización de software.