Comenzar desde cero K8s | Orquestación de aplicaciones con estado - StatefulSet
https: // www.kubernetes.org.cn/6724.html
Autor | Jiuzhu Alibaba Experto técnico
Este artículo está compilado de la Conferencia 22 del "Curso abierto de tecnología nativa de la nube CNCF x Alibaba".
Siga la cuenta pública "Alibaba Cloud Native" y responda a la palabra clave "Getting Started" para descargar el PPT de la serie de artículos K8 desde cero.
Introducción: el despliegue y la entrega de aplicaciones con estado siempre ha sido una de las dificultades en el campo de la operación y el mantenimiento de la aplicación. Los requisitos con estado comunes, como el estado persistente del disco, cada máquina necesita una identificación de red independiente y estable, y la certeza del orden de lanzamiento. En respuesta a tales problemas, Kubernetes proporciona un controlador StatefulSet como carga de trabajo para ayudar a la implementación y el aterrizaje de aplicaciones con estado en el entorno K8.
1. Requisitos "declarativos"
Hablamos sobre la implementación como una herramienta de administración de la orquestación de aplicaciones, ¿qué funciones nos brinda?
Como se muestra a continuación:
- En primer lugar, admite la definición del número esperado de Pods. El Controlador mantendrá el número de Pods en la versión deseada y el número esperado para nosotros;
- En segundo lugar, es compatible con la configuración del método de liberación del Pod. Una vez completada la configuración, el Controlador actualizará el Pod de acuerdo con la estrategia que le demos. Al mismo tiempo, durante el proceso de actualización, también se asegurará de que el número de Pods inutilizables esté dentro del rango que definimos;
- En tercer lugar, si encontramos problemas durante el proceso de lanzamiento, la implementación también admite la reversión con un solo clic.
En pocas palabras, Deployment cree que las mismas versiones de Pods que administra son copias idénticas. En otras palabras, desde la perspectiva del Controlador de implementación, todos los Pods de la misma versión, independientemente de la aplicación o el comportamiento implementado en el interior, son exactamente iguales.
Dicha capacidad es compatible con aplicaciones sin estado. ¿Qué sucede si encontramos algunas aplicaciones con estado?
Análisis de necesidades
Por ejemplo, algunos requisitos que se muestran en la figura a continuación:
Deployment no puede cumplir con todos los requisitos anteriores, por lo que la comunidad de Kubernetes nos proporciona un recurso llamado StatefluSet para administrar aplicaciones con estado.
StatefulSet: controlador para la gestión de aplicaciones con estado
De hecho, muchas aplicaciones sin estado en la comunidad también se administran a través de StatefulSet. A través del estudio de este artículo, todos también entenderán por qué también administramos algunas aplicaciones sin estado a través de StatefulSet.
Como se muestra en el lado derecho de la figura anterior, los Pods en StatefulSet están numerados, comenzando desde 0 hasta que el número de réplicas definidas disminuye en uno. Cada Pod tiene una identificación de red independiente: un nombre de host, un almacenamiento independiente de pvc y pv. En este caso, diferentes Pods bajo el mismo StatefulSet tienen identificaciones de red diferentes y sus propios discos de almacenamiento exclusivos, que pueden satisfacer las necesidades de la mayoría de las aplicaciones con estado.
Como se muestra en el lado derecho de la imagen de arriba:
- Primero, cada Pod tendrá un número de Orden, que se creará, eliminará y actualizará de acuerdo con el número;
- En segundo lugar, al configurar un servicio sin cabeza, cada Pod tiene un identificador de red único (nombre de host);
- Tercero, al configurar la plantilla de pvc, que es la plantilla de pvc, cada Pod tiene uno o más discos de almacenamiento de pv;
- Finalmente, se admite un cierto número de versiones en escala de grises. Por ejemplo, ahora hay tres copias de StatefulSet, podemos especificar que actualice solo una o dos de ellas, o incluso tres a la nueva versión. De esta manera, para lograr el propósito de la actualización en escala de grises.
Segundo, interpretación de casos de uso
Creación de ejemplo de StatefulSet
El lado izquierdo de la figura anterior es una configuración de Servicio. Al configurar el Servicio sin cabeza, realmente queremos lograr el objetivo: esperar que el Pod en el StatefulSet tenga una identificación de red independiente. El nombre del servicio aquí se llama nginx.
El lado derecho de la figura anterior es una configuración StatefulSet. Hay un serviceName en la especificación también llamado nginx. Utilice este serviceName para especificar a qué servicio corresponde este StatefulSet.
Hay varios otros campos familiares en esta especificación, como el selector y la plantilla. selector es un selector de etiquetas. La lógica de selección de etiquetas definida por el selector debe coincidir con las etiquetas en los metadatos de la plantilla, incluida la aplicación: nginx. Defina un contenedor nginx en la plantilla, la versión de la imagen utilizada por este contenedor es la versión alpina, y el puerto expuesto 80 se utiliza como un servicio web.
Finalmente, se define un volumeMounts en template.spec, este volumeMounts no es de Volumes en la especificación, sino de volumeClaimTemplates, que es la plantilla de pvc. Hemos definido un nombre de pvc llamado www-storage en la plantilla de pvc. Este nombre de pvc, también escribiremos volumeMounts como un nombre de volumen, montado en el directorio / usr / share / nginx / html. De esta manera, cada pod tiene un pvc independiente y se monta en el directorio correspondiente en el contenedor.
Servicio, StatefulSet state
Después de crear los dos objetos anteriores, podemos ver que el recurso Service nginx se ha creado con éxito a través del comando get.
Al mismo tiempo, puede ver al observar los puntos finales que este backend ha registrado tres IP y puertos: estas tres IP corresponden a las IP de Pod, y los puertos corresponden a los 80 puertos configurados en la especificación anterior.
Finalmente, obtenga sts (abreviatura de StatefulSet) nginx-web. Como puede ver en el resultado, hay una columna llamada READY con un valor de 3/3. El denominador 3 es el número deseado en StatefulSet, y el numerador 3 indica que el Pod ha alcanzado el número deseado de estados en READY.
Pod, estado de PVC
El pod de obtención en la figura a continuación muestra que los tres Pod están en estado de Ejecución y LISTO. Su IP es la dirección del punto final visto anteriormente.
Puede ver el nombre de NAME a través de get pvc, el prefijo es www-storage, el medio es nginx-web y el sufijo es un número de serie. A través del análisis, podemos saber que www-storage es el nombre definido en volumeClaimTemplates, el nombre definido en el medio es StatefulSet, y el número de serie al final corresponde al número de serie del Pod, es decir, los tres PVC están unidos por tres Pods. De esta forma, diferentes Pods disfrutan de diferentes PVC; el PVC también se unirá a un PV correspondiente para lograr el propósito de unir diferentes PV con diferentes Pods.
Versión pod
Anteriormente supimos que Deployment usa ReplicaSet para administrar la versión del Pod y el número esperado de Pods, pero en StatefulSet, el Controlador StatefulSet administra los Pods subordinados, por lo que StatefulSet usa la etiqueta Pod para identificar la versión de este Pod, llamada aquí controlador-revision-hash. Esta etiqueta es similar al hash de la plantilla Pod inyectado por Deployment y StatefulSet en el Pod.
Como se muestra en la figura anterior, el controlador-revision-hash se ve a través del pod de obtención. El hash aquí es la versión de plantilla correspondiente a la primera creación del Pod. Puede ver que el sufijo es 677759c9b8. Grabemos aquí primero, y luego hagamos la actualización del Pod, y luego veamos si el controlador-revision-hash cambiará.
Actualizar espejo
Al ejecutar el comando anterior, puede ver que en la configuración StatefulSet debajo de la imagen de arriba, la imagen en StatefulSet se ha actualizado a la nueva versión de la línea principal.
Ver el estado de la nueva versión
Al consultar el hash de revisión a través del comando get pod, puede ver que el controlador-revision-hash detrás de los tres pods se ha actualizado al nuevo hash de revisión, que luego se convierte en 7c55499668. A través del tiempo de creación de estos tres Pods, se puede encontrar que el Pod con el número de serie 2 es el primero, y luego los números de serie son 1 y 0. Esto significa que durante el proceso de actualización, la secuencia de actualización real es 2-1-0, y el Pod se actualiza gradualmente a la nueva versión a través de un orden inverso, y el Pod que actualizamos también reutiliza el PVC utilizado por el Pod anterior. Por lo tanto, los datos en el disco de almacenamiento PV aún se montarán en el nuevo Pod.
La parte superior derecha de la figura anterior son los datos vistos en el estado del StatefulSet. Hay varios campos importantes:
- currentReplica: indica el número de la versión actual
- currentRevision: indica el número de versión actual
- updateReplicas: indica el número de nuevas versiones
- updateRevision: indica el número de versión que se actualizará
Por supuesto, también puede ver que currentReplica y updateReplica, así como currentRevision y updateRevision son iguales, lo que significa que todos los Pods se han actualizado a la versión requerida.
3. Demostración de la operación.
Archivo de orquestación StatefulSet
En primer lugar, aquí se ha conectado a un clúster de Alibaba Cloud, hay tres nodos en el clúster.
Ahora, para crear un StatefulSet y el Servicio correspondiente, primero mire el archivo de diseño correspondiente.
Como se muestra en el ejemplo de la figura anterior, nginx correspondiente al Servicio expone el puerto 80 al mundo exterior. Los metadatos en la configuración StatefulSet definen el nombre como nginx-web; los contenedores en la plantilla definen la información de la imagen; y finalmente definen un volumeClaimTemplates como la plantilla de PVC.
Comienza a crear
Después de ejecutar el comando anterior, hemos creado correctamente Service y StatefulSet. A través de get pod, puede ver que el Pod creado primero tiene un número de serie de 0; a través de get pvc, puede ver que el PVC con número de serie 0 se ha vinculado al PV.
El Pod con el número de secuencia 0 ya se ha creado y el estado es ContainerCreating.
Cuando se crea el Pod con el número de serie 0, comienza a crearse el Pod con el número de serie 1, y luego ve que el nuevo PVC también se ha creado con éxito, seguido del Pod con el número de serie 2.
Puede ver que antes de crear cada Pod, se crea un PVC. Después de crear el PVC, el Pod se une al PV desde el estado Pendiente, luego se convierte en ContainerCreating y finalmente llega a Running.
Ver estado
Luego verifique el estado de StatefulSet a través de kubectl get sts nginx-web -o yaml.
Como se muestra en la figura anterior, el número esperado de réplicas es 3, el número disponible actualmente es 3 y se alcanza la última versión.
Luego mire el Servicio y los puntos finales, puede ver que el Puerto de servicio es 80 y el punto final tiene tres direcciones IP correspondientes.
Venga a obtener el pod nuevamente, puede ver que los tres pod corresponden a las direcciones IP de los puntos finales anteriores.
Los resultados de las operaciones anteriores son: tres PVC y tres Pods han alcanzado el estado deseado, y en el estado informado por StatefulSet, hay tres réplicas y réplicas actuales.
Operación de actualización
Aquí nuevamente, la imagen de conjunto de kubectl es una redacción fija para declarar imágenes; StatefulSet indica un tipo voluntario; nginx-web es el nombre del recurso; nginx = nginx: mainline, nginx antes del signo igual es el nombre del contenedor que definimos en la plantilla, y este último nginx: mainline es la versión de la imagen que desea actualizar.
A través del comando anterior, la imagen en StatefulSet se ha actualizado con éxito a la nueva versión.
Mirando el estado a través de get pod, nginx-web-1 y nginx-web-2 han entrado en el estado Running. El controlador-revision-hash correspondiente ya es una nueva versión. Luego, el pod de nginx-web-0, el antiguo pod se ha eliminado y el nuevo pod todavía está en el estado Creación.
Verifique el estado nuevamente, todos los pods ya están en estado de ejecución.
Mirando la información de StatefulSet, la Revisión actual definida en el estado en StatefulSet se ha actualizado a una nueva versión, lo que indica que los tres Pods que StatefulSet ha adquirido han ingresado a la nueva versión.
¿Cómo verificar si estos tres Pods todavía reutilizan el logotipo de red anterior y el disco de almacenamiento?
De hecho, el nombre de host configurado por el servicio sin cabeza solo está vinculado al nombre del Pod, por lo que siempre que el nombre del Pod actualizado sea el mismo que el nombre del Pod anterior, se puede usar la ID de red utilizada por el Pod anterior.
Con respecto a los discos de almacenamiento, puede ver el estado de los PVC en la imagen de arriba. Su tiempo de creación no ha cambiado. Es el momento en que se creó el Pod por primera vez, por lo que ahora el Pod actualizado utiliza el PVC utilizado en el Pod anterior.
Por ejemplo, puede ver uno de los Pods. Este Pod también tiene un volumen declarado. El nombre www-storage-nginx-web-0 en persistentVolumeClaim corresponde al PVC con el número de serie 0 visto en la lista de PVC. Utilizado por las antiguas vainas. Durante el proceso de actualización, el Controlador elimina el Pod antiguo y crea un Pod nuevo con el mismo nombre. El Pod nuevo todavía reutiliza el PVC utilizado por el Pod antiguo.
De esta forma, el propósito del almacenamiento en red se puede reutilizar antes y después de la actualización.
Cuatro, diseño de la arquitectura
Modo de gestión
StatefulSet puede crear tres tipos de recursos.
- El primer recurso: ControllerRevision
A través de este recurso, StatefulSet puede administrar fácilmente diferentes versiones de plantillas de plantillas.
Por ejemplo: para el nginx mencionado anteriormente, la primera versión de la plantilla al comienzo de la creación creará una Revisión del controlador correspondiente. Cuando se modifica la versión de la imagen, StatefulSet Controller creará una nueva ControllerRevision. Puede comprender que cada ControllerRevision corresponde a cada versión de la Plantilla y también corresponde a cada versión del hash ControllerRevision. De hecho, el hash ControllerRevision definido en la etiqueta Pod es el nombre de ControllerRevision. A través de este recurso StatefulSet Controller puede gestionar diferentes versiones de recursos de plantilla.
- El segundo recurso: PVC
Si volumeClaimTemplates se define en StatefulSet, StatefulSet creará un PVC basado en esta plantilla antes de crear el Pod y agregará el PVC al volumen del Pod.
Si el usuario define volumeClaimTemplates en la plantilla de pvc de la especificación, StatefulSet crea un PVC de acuerdo con la plantilla antes de crear el Pod y lo agrega al volumen correspondiente al Pod. Por supuesto, no puede definir la plantilla de pvc en la especificación, entonces el Pod creado no montará un solo pv.
- El tercer recurso: Pod
StatefulSet crea, elimina y actualiza Pods en secuencia, y cada Pod tiene un número de serie único.
Como se muestra en la figura anterior, StatefulSet Controller posee tres recursos: ControllerRevision, Pod, PVC.
La diferencia aquí es que la versión actual de StatefulSet solo agregará OwnerReference en ControllerRevision y Pod, pero no agregará OwnerReference en PVC. Como se mencionó en la serie anterior de artículos, el recurso con OwnerReference eliminará los recursos subordinados en cascada de forma predeterminada cuando se elimine el recurso bajo administración. Por lo tanto, después de que StatefulSet se elimine de manera predeterminada, se eliminarán ControllerRevision y Pod creados por StatefulSet, pero el PVC no se eliminará en cascada porque el OwnerReference no se escribe en el PVC.
Controlador StatefulSet
La imagen de arriba muestra el flujo de trabajo del controlador StatefulSet. Presentemos brevemente todo el flujo de trabajo.
Primero, registre el controlador de eventos del informador para manejar los cambios de StatefulSet y Pod. En la lógica del controlador, cada vez que cambia un StatefulSet o Pod, encontrará el StatefulSet correspondiente y lo colocará en la cola. Inmediatamente después de ser sacado de la cola para el procesamiento, la primera operación es Actualizar revisión, es decir, primero verifique la plantilla en el StatefulSet actual, si existe una Revisión del controlador correspondiente. De lo contrario, significa que la plantilla se ha actualizado, y el Controlador creará una nueva versión de Revisión, y habrá un nuevo número de versión hash de ControllerRevision.
Luego, el controlador extraerá todos los números de versión y los ordenará de acuerdo con el número de serie. Durante este proceso de clasificación, si falta un Pod, se creará de acuerdo con el número de serie, si se descubre que hay un exceso de Pod, se eliminará de acuerdo con el número de serie. Cuando se garantiza que el número de Pods y los números de serie del Pod coinciden con el número de Réplica, el Controlador verificará si el Pod necesita ser actualizado. En otras palabras, la diferencia entre estos dos pasos es que los pods Manger para verificar si todos los Pods cumplen con el número de serie; y la última Actualización para verificar si la versión deseada del Pod cumple con los requisitos, y actualizar por número de serie.
Actualización en orden El proceso de actualización se muestra en la figura anterior. De hecho, este proceso es relativamente simple, es decir, eliminar el Pod. Después de eliminar el Pod, en realidad es el siguiente evento desencadenante. Después de que el Controlador obtenga este éxito, descubrirá que falta el Pod, y luego creará un nuevo Pod del pod del Administrador del paso anterior en orden. Después de esto, el Controlador realizará un estado de actualización, que es la información de estado que se vio anteriormente a través de la línea de comando.
A través de todo este proceso, StatefulSet logra la capacidad de administrar aplicaciones con estado.
Simulación de expansión de capacidad
Supongamos que la configuración inicial de las réplicas StatefulSet es 1, hay un Pod0. Luego, después de modificar las réplicas de 1 a 3, en realidad creamos primero Pod1. Por defecto, esperamos el estado de Pod1 LISTO antes de crear Pod2.
Como puede ver en la imagen de arriba, los Pods debajo de cada StatefulSet se crean a partir de la secuencia número 0. Por lo tanto, se crea un StatefulSet con réplicas N con un número de secuencia Pod [0, N), 0 es una curva abierta y N es una curva cerrada, es decir, cuando N> 0, los números de secuencia son 0 a N-1.
Estrategia de gestión de expansión
Algunos estudiantes pueden tener preguntas: si no quiero crear y eliminar según el número de serie, StatefulSet también admite otra lógica de creación y eliminación, por lo que algunas personas de la comunidad también administran aplicaciones sin estado a través de StatefulSet. Su ventaja es que puede tener una identificación de red única y almacenamiento de red, y también puede expandirse y reducirse de manera concurrente.
Hay un campo en StatefulSet.spec llamado campo podMangementPolicy. Las estrategias opcionales de este campo son OrderedReady y Parallel, que es la primera por defecto.
Como en el ejemplo que acabamos de crear, podMangementPolicy no está definido en la especificación. Luego, el controlador predeterminado es OrderedReady como estrategia, y luego, en el caso de OrderedReady, la expansión y la contracción se realizan estrictamente en el orden de la Orden. Debe esperar a que el estado del Pod anterior esté Listo antes de expandir el próximo Pod. Al reducir, elimine en orden inverso y elimine el número de secuencia de mayor a menor.
Por ejemplo, cuando se expande de Pod0 a Pod0, Pod1 y Pod2 en el lado derecho de la figura anterior, primero debe crear Pod1 y esperar a que Pod1 esté listo para crear Pod2. De hecho, existe una posibilidad: por ejemplo, al crear Pod1, Pod0 puede convertirse en el estado NotReady por alguna razón, que puede ser la causa de la máquina host o la razón de la aplicación misma. En este momento, el Controlador no creará Pod2, por lo que no solo el Pod anterior que creamos debe estar Listo, sino que todos los Pods anteriores deben estar listos, y luego se creará el próximo Pod. En el ejemplo anterior, si desea crear Pod2, entonces Pod0 y Pod1 deben estar listos.
Otra estrategia se llama Paralelo. Como su nombre lo indica, es expandir y reducir en paralelo. No necesita esperar a que el Pod anterior esté Listo o eliminarlo antes de procesar el siguiente.
Post simulación
Suponiendo que la plantilla StatefulSet1 aquí corresponde a la Revisión lógica1, entonces los tres Pods bajo StatefulSet pertenecen a la versión Revisión1. Después de modificar la plantilla, como la imagen, el Controlador actualizó los Pods uno por uno en orden inverso. En la figura anterior, puede ver que el Controlador creó primero una Revisión2, correspondiente a la creación de un recurso como ControllerRevision2, y el nombre de Resource ControllerRevision2 como un nuevo hash de Revisión. Después de actualizar Pod2 a la nueva versión, elimine Pod0 y Pod1 uno por uno, y luego cree Pod0 y Pod1.
Su lógica es realmente muy simple. Durante el proceso de actualización, el Controlador eliminará el Pod con el número de serie más alto y cumplirá con las condiciones. Luego, después de la eliminación, la próxima vez que el Controlador se reconcilie, encontrará el Pod que carece de este número de serie y luego seguirá la nueva versión Crea la vaina.
Análisis de campo de especificaciones
Primero mire los primeros campos de la especificación: Réplica y Selector son los campos con los que estamos más familiarizados.
- La réplica es principalmente la cantidad esperada;
- Selector es un selector de eventos y debe coincidir con las condiciones definidas en spec.template.metadata.labels;
- Plantilla: plantilla de Pod, que define la plantilla de información básica del Pod que se creará;
- VolumeClaimTemplates: Lista de plantillas de PVC. Si se define en la especificación, se creará PVC antes de la plantilla Pod. Después de crear el PVC, el nombre del PVC creado se inyecta en el Pod creado de acuerdo con la Plantilla como un volumen.
- ServiceName: el nombre correspondiente al servicio sin cabeza. Por supuesto, si alguien no necesita esta función, al Servicio se le asignará un valor inexistente y el Controlador no realizará la verificación, por lo que puede escribir un Nombre de servicio falso. Sin embargo, se recomienda configurar un servicio sin cabeza para cada servicio, independientemente de si el Pod bajo el StatefulSet requiere una identificación de red;
- PodMangementPolicy: estrategia de gestión de pod. Como se mencionó anteriormente, las estrategias opcionales para este campo son OrderedReady y Parallel, que es la primera por defecto;
- UpdataStrategy: estrategia de actualización de pod. Esta es una estructura, descrita en detalle a continuación;
- RevisionHistoryLimit: limite el número de ControllerRevisions para mantener el historial (el valor predeterminado es 10). Cabe señalar que la versión clara aquí, no debe haber un Pod relacionado que corresponda a estas versiones, si todavía hay Pods en esta versión, esta Revisión del Controlador no se puede eliminar.
Análisis de campo de estrategia de actualización
En el lado derecho de la imagen de arriba, puede ver que StatefulSetUpdateStrategy tiene un campo de tipo, que define dos tipos: uno es RollingUpdate; uno es OnDelete.
- RollingUpdate es en realidad un poco similar a la actualización en Deployment, que consiste en actualizar de acuerdo con el método de actualización renovable;
- OnDelete se actualiza cuando se elimina. Se llama para prohibir la actualización activa. El Controlador no actualiza activamente los Pods sobrevivientes, sino a través de OnDelete. Por ejemplo, actualmente hay tres Pods antiguos, pero la estrategia de actualización es OnDelete, por lo que al actualizar el espejo en la especificación, el Controlador no actualizará los tres Pods a la nueva versión uno por uno, pero cuando reduzcamos la Réplica, el Controlador primero Eliminar el Pod. Cuando expandimos la capacidad la próxima vez, el Controlador expandirá la nueva versión del Pod.
En RollingUpdateStatefulSetSetStrategy, puede ver que hay un campo llamado Partición. Esta partición significa que el número de pods en la versión anterior se conserva durante la actualización continua. Muchos estudiantes que acaban de terminar StatefulSet pueden pensar que esta es la cantidad de nuevas versiones de escala de grises, lo cual es incorrecto.
Por ejemplo: suponga que actualmente hay un StatefulSet con réplicas de 10. Cuando actualizamos la versión, si la Partición es 8, no significa que necesitemos actualizar los 8 Pods a la nueva versión, sino que necesitamos mantener los 8 Pods como la versión anterior. , Actualice solo 2 nuevas versiones como escala de grises. Cuando la réplica es 10, el siguiente número de serie del Pod es [0,9), por lo que cuando configuramos Partition a 8, en realidad conservamos [0,7) estos 8 Pods son versiones antiguas, solo [8,9) Ingrese la nueva versión.
Para resumir, suponga réplicas = N, Partición = M (M
V. Resumen de esta sección
Este es el final del contenido principal de este artículo, aquí hay un breve resumen para todos:
- StatefulSet es una carga de trabajo común en Kubernetes. Su objetivo inicial es implementar aplicaciones con estado, pero también es compatible con la implementación de aplicaciones sin estado;
- A diferencia de la implementación, StatefulSet opera directamente Pod para expandir / contraer / publicar, y no está controlado por otras cargas de trabajo como ReplicaSet;
- Las características de StatefulSet son: soporte para cada PVC exclusivo de Pod, tiene una identificación de red única y también puede reutilizar PVC e identificación de red después del lanzamiento de la actualización;