Una breve descripción del problema  Un día, durante una actualización planificada del clúster k8s, descubrimos que casi todos nuestros POD (aproximadamente 500 de 1000) en los nuevos nodos no podían iniciarse y los minutos se convirtieron rápidamente en horas. Buscamos activamente la causa raíz, pero después de tres horas, los POD todavía estaban en estado   .  ContainerCreating  Afortunadamente, no se trataba del entorno de producción y el período de mantenimiento estaba programado para el fin de semana. Tuvimos tiempo para investigar el problema sin ninguna presión.  ¿Por dónde debería empezar a buscar la causa raíz? ¿Le gustaría saber más sobre la solución que encontramos? ¡Abróchese el cinturón y disfrute!  Más detalles sobre el problema  El problema era que teníamos una gran cantidad de imágenes de Docker que debían extraerse e iniciarse en cada nodo del clúster al mismo tiempo. Esto se debía a que varias extracciones simultáneas de imágenes de Docker en un solo nodo pueden generar una alta utilización del disco y tiempos de inicio en frío prolongados.  De vez en cuando, el proceso de CD tarda hasta 3 horas en extraer las imágenes. Sin embargo, esta vez se quedó completamente bloqueado, porque la cantidad de PODS durante la actualización de EKS (en línea, cuando reemplazamos todos los nodos del clúster) era demasiado alta.  Todas nuestras aplicaciones se ejecutan en K8S (basadas en   ). Para ahorrar en costos en el entorno DEV, utilizamos instancias puntuales. EKS  Utilizamos la imagen   para los nodos. AmazonLinux2  Contamos con una gran cantidad de   (FB) en el entorno de desarrollo que se implementan continuamente en nuestro clúster de Kubernetes. Cada FB tiene su propio conjunto de aplicaciones y cada aplicación tiene su propio conjunto de dependencias (dentro de una imagen). ramas de funciones  En nuestro proyecto, hay casi 200 aplicaciones y esta cifra va en aumento. Cada aplicación utiliza una de las 7 imágenes base de Docker con un tamaño de aproximadamente 2 GB. El tamaño total máximo de la imagen archivada (en el   ) es de aproximadamente 3 GB. ECR  Todas las imágenes se almacenan en Amazon Elastic Container Registry (ECR).  Utilizamos el tipo de volumen EBS gp3 predeterminado para los nodos.   Problemas a los que nos enfrentamos    iniciar un nuevo pod con una nueva imagen puede llevar más de una hora, en particular cuando se extraen varias imágenes simultáneamente en un solo nodo. Tiempo de inicio en frío extendido:      frecuente o atascado en los estados   , lo que indica problemas con la extracción de imágenes. Errores de ErrImagePull: ErrImagePull ContainerCreating    la utilización del disco se mantiene cerca del 100 % durante el proceso de extracción de imágenes, principalmente debido a la intensa E/S del disco necesaria para la descompresión (por ejemplo, “unpigz”). Alta utilización del disco:    algunos DaemonSets del sistema (como   o   ) pasaron al estado "no listo" debido a la presión del disco, lo que afectó la preparación del nodo. Problemas con DaemonSet del sistema: aws-node ebs-csi-node    debido a que utilizamos instancias puntuales, no podemos usar el disco local para almacenar imágenes en caché. No hay caché de imágenes en los nodos:  Esto da como resultado muchas implementaciones estancadas en las ramas de características, en particular porque los diferentes FB tienen diferentes conjuntos de imágenes base.  Después de una rápida investigación, descubrimos que el problema principal era la presión del disco sobre los nodos por parte del proceso   . Este proceso es responsable de descomprimir las imágenes de Docker. No cambiamos la configuración predeterminada para el tipo de volumen EBS gp3, porque no es adecuado para nuestro caso. unpigz  Revisión rápida para recuperar el clúster  Como primer paso, decidimos reducir la cantidad de POD en los nodos.  Movemos los nuevos nodos al estado “Cordón”  Retire todos los PODS atascados para reducir la presión del disco.  Ejecute uno por uno los POD para calentar los nodos  Después de eso, movemos los nodos calentados al estado normal (“unCordon”)  Se eliminaron todos los nodos en estado bloqueado  Todos los PODS se iniciaron correctamente al usar el caché de imágenes de Docker   Un diseño CI/CD original  La idea principal de la solución es calentar los nodos antes de que comience el proceso de CD mediante la mayor parte de la imagen de Docker (capa de dependencias de JS), que se utiliza como imagen raíz para todas nuestras aplicaciones. Tenemos al menos 7 tipos de imágenes raíz con las dependencias de JS, que están relacionadas con el tipo de aplicación. Por lo tanto, analicemos el diseño CI/CD original.     En nuestro pipeline de CI/CD, tenemos 3 pilares:   Una canalización CI/CD original:  En el paso   it: preparamos el entorno/variables, definimos el conjunto de imágenes a reconstruir, etc... Init  En el paso   : construimos las imágenes y las enviamos al ECR Build  En el paso   : implementamos las imágenes en los k8s (implementaciones de actualizaciones, etc.) Deploy   Más detalles sobre el diseño original del CICD:  Nuestras ramas de características (FB) se bifurcan de la rama   . En el proceso de integración continua, siempre analizamos el conjunto de imágenes que se modificaron en la FB y las reconstruimos. La rama   siempre es estable, ya que, por definición, siempre debe existir la última versión de las imágenes base. main main  Creamos por separado las imágenes de Docker de las dependencias de JS (para cada entorno) y las enviamos al ECR para reutilizarlas como imagen raíz (base) en el Dockerfile. Tenemos entre 5 y 10 tipos de imágenes de Docker de las dependencias de JS.  El FB se implementa en el clúster k8s en un espacio de nombres independiente, pero en los nodos comunes para el FB. El FB puede tener aproximadamente 200 aplicaciones, con un tamaño de imagen de hasta 3 GB.  Contamos con el sistema de escalamiento automático de cluster, que escala los nodos del cluster en función de la carga o PODS pendientes con el nodeSelector y la tolerancia correspondientes.  Utilizamos las instancias puntuales para los nodos.  Implementación del proceso de calentamiento  Existen requisitos para el proceso de calentamiento.  Obligatorio:    : aborda y resuelve problemas   . Resolución de problemas ContainerCreating    : reduce significativamente el tiempo de inicio al utilizar imágenes base precalentadas (dependencias JS). Rendimiento mejorado  Es bueno tener mejoras:    : permite realizar cambios sencillos en el tipo de nodo y su vida útil (por ejemplo, SLA alto o tiempo de vida útil extendido). Flexibilidad    : proporciona métricas claras sobre el uso y el rendimiento. Transparencia    : ahorra costos al eliminar el VNG inmediatamente después de eliminar la rama de funciones asociada. Eficiencia de costos    : este enfoque garantiza que otros entornos no se vean afectados. Aislamiento  Solución  Después de analizar los requisitos y las limitaciones, decidimos implementar un proceso de calentamiento que precalentaría los nodos con las imágenes de caché de JS base. Este proceso se activaría antes de que comience el proceso de CD, lo que garantizaría que los nodos estén listos para la implementación del FB y que tengamos la máxima posibilidad de acceder a la caché.  Esta mejora la dividimos en tres grandes pasos:  Crea el   (Grupo de nodos virtuales)  conjunto de nodos por cada FB  Agregue   para los nuevos nodos imágenes base al script cloud-init  Agregue un   con la sección   para descargar las imágenes de Docker necesarias a los nodos antes de que comience el proceso de CD. paso previo a la implementación para ejecutar DaemonSet initContainers     Una secuencia de CI/CD actualizada se vería así:   Una secuencia de CI/CD actualizada:  Paso   1.1.(nuevo paso)   : si se trata de un primer inicio del FB, se crea un nuevo conjunto personal de instancias de nodo (en nuestros términos, es Virtual Node Group o VNG) y se descargan todas las imágenes base de JS (5 a 10 imágenes) de la rama principal. Es justo hacerlo, porque bifurcamos el FB de la rama principal. Un punto importante: no es una operación de bloqueo. inicial Implementación inicial    paso Construir  Paso   Descargue imágenes base JS recién horneadas con la etiqueta FB específica del ECR.  3.1.(nuevo paso)   : Es una operación de bloqueo, ya que debemos reducir la presión del disco. Una a una, descargamos las imágenes base para cada nodo relacionado.  Por cierto, gracias por el paso “   , ya tenemos las imágenes base de Docker de la rama principal, lo que nos da una gran posibilidad de acceder al caché en el primer inicio. de pre-implementación Puntos importantes init deployment”  **Desplegar  **No hay cambios en este paso. Pero gracias al paso anterior, ya tenemos todas las capas de imágenes pesadas de Docker en los nodos necesarios.  Paso de implementación inicial    a través de una llamada API (al sistema de escalado automático de terceros) desde nuestra canalización CI. Cree un nuevo conjunto de nodos para cada FB   Problemas resueltos:    : cada FB tiene su propio conjunto de nodos, lo que garantiza que el entorno no se vea afectado por otros FB. Aislamiento    : Podemos cambiar fácilmente el tipo de nodo y su vida útil. Flexibilidad    : Podemos eliminar los nodos inmediatamente después de eliminar el FB. Rentabilidad    : Podemos rastrear fácilmente el uso y el rendimiento de los nodos (cada nodo tiene una etiqueta relacionada con el FB). Transparencia    : la instancia puntual comienza con imágenes base ya predefinidas, lo que significa que, después de que se inicia el nodo puntual, ya existen imágenes base en el nodo (desde la rama principal). Uso efectivo de las instancias puntuales    a través del script   . Descargue todas las imágenes base de JS de la rama principal a los nuevos nodos cloud-init  Mientras se descargan las imágenes en segundo plano, el proceso de CD puede continuar creando nuevas imágenes sin problemas. Además, los siguientes nodos (que se crearán mediante el sistema de escalado automático) de este grupo se crearán con los datos actualizados   , que ya tienen instrucciones para descargar imágenes antes de comenzar. cloud-init  Problemas resueltos:    : la presión del disco desapareció porque actualizamos el script   agregando la descarga de las imágenes base desde la rama principal. Esto nos permite acceder a la memoria caché en el primer inicio del FB. Resolución del problema cloud-init    : la instancia de Spot se inicia con datos   actualizados. Esto significa que, después de que se inicia el nodo de Spot, ya existen las imágenes base en el nodo (de la rama principal). Uso eficaz de las instancias de Spot cloud-init    : el proceso de CD puede continuar creando nuevas imágenes sin problemas. Rendimiento mejorado  Esta acción agregó ~17 segundos (llamada API) a nuestro flujo de trabajo de CI/CD.  Esta acción solo tiene sentido la primera vez que iniciamos el FB. La próxima vez, implementamos nuestras aplicaciones en nodos ya existentes, que ya tienen las imágenes base que entregamos en la implementación anterior.  Paso previo a la implementación  Necesitamos este paso porque las imágenes de FB son diferentes de las imágenes de la rama principal. Necesitamos descargar las imágenes base de FB a los nodos antes de que comience el proceso de CD. Esto ayudará a mitigar los tiempos de inicio en frío prolongados y la alta utilización del disco que pueden ocurrir cuando se extraen varias imágenes pesadas simultáneamente.   Objetivos del paso previo a la implementación    : descargar secuencialmente las imágenes más pesadas de Docker. Después del paso de implementación inicial, ya tenemos las imágenes base en los nodos, lo que significa que tenemos una gran posibilidad de acceder a la caché. Prevenir la presión del disco    : asegúrese de que los nodos estén precalentados con imágenes de Docker esenciales, lo que genera tiempos de inicio de POD más rápidos (casi de inmediato). Mejore la eficiencia de la implementación    : minimice las posibilidades de encontrar errores   /   y asegúrese de que los conjuntos de demonios del sistema permanezcan en un estado "listo". Mejorar la estabilidad ErrImagePull ContainerCreating  En este paso añadimos entre 10 y 15 minutos al proceso de CD.  Detalles del paso previo a la implementación:  En el CD creamos un DaemonSet con la sección   . initContainers  La sección   se ejecuta antes de que se inicie el contenedor principal, lo que garantiza que las imágenes necesarias se descarguen antes de que se inicie el contenedor principal. initContainers  En el CD, verificamos continuamente el estado del daemonSet. Si el daemonSet está en estado “listo”, procedemos con la implementación. De lo contrario, esperamos a que el daemonSet esté listo.  Comparación  Comparación de los pasos originales y actualizados con el proceso de precalentamiento.  Paso  Paso de implementación inicial  Paso previo a la implementación  Desplegar  Tiempo total  Diferencia  Sin precalentamiento  0  0  11 minutos 21 segundos  11 minutos 21 segundos  0  Con precalentamiento  8 segundos  58 segundos  25 segundos  1 minuto 31 segundos  -9m 50s  Lo más importante es que el tiempo de “Implementación” cambió (desde el primer comando de aplicación hasta el estado de ejecución de los pods) de 11 min 21 s a 25 segundos. El tiempo total cambió de 11 min 21 s a 1 min 31 s. Un punto importante, si no hay imágenes base de la rama principal, entonces el tiempo de “Implementación” será el mismo que el tiempo original o un poco más. Pero de todos modos, resolvimos un problema con la presión del disco y el tiempo de arranque en frío.  Conclusión   El problema principal   se resolvió con el proceso de calentamiento. Como beneficio, redujimos significativamente el tiempo de arranque en frío de los POD.  La presión del disco desapareció porque ya tenemos las imágenes base en los nodos. Los conjuntos de demonios del sistema están en un estado "listo" y "en buen estado" (porque no hay presión del disco) y no hemos encontrado ningún error   relacionado con este problema. ContainerCreating ErrImagePull  Posibles soluciones y enlaces  Utilice instancias   para los nodos en lugar de   No podemos utilizar este método porque está fuera del alcance de nuestro presupuesto para entornos que no sean de producción. bajo demanda instancias puntuales    No podemos utilizar esta opción porque esta función también queda fuera del alcance de nuestro presupuesto para entornos que no son de producción. Además, AWS tiene   de IOPS para su cuenta por región. Utilice el tipo de volumen gp3 (o mejor) de Amazon EBS con el aumento de IOPS límites    En realidad no podemos avanzar de esta manera, porque tiene un impacto demasiado alto en la producción y otros entornos, pero también es una buena solución a nuestro problema. Reduzca el tiempo de inicio del contenedor en Amazon EKS con el volumen de datos de Bottlerocket   Solución de problemas: el escalador automático de clústeres de Kubernetes tarda 1 hora en ampliar 600 pods    Me gustaría agradecer al gran equipo técnico de   (   ) por su incansable trabajo y su enfoque realmente creativo ante cualquier problema al que se enfrentan. En particular, quiero agradecer a Ronny Sharaby, el excelente líder que es responsable del excelente trabajo que está haciendo el equipo. Espero ver cada vez más ejemplos excelentes de cómo su creatividad impacta en el producto Justt. PD: Justt https://www.linkedin.com/company/justt-ai

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Read My Stories

Este audio es producido en el idioma original de la historia!

Cómo optimizar Kubernetes para imágenes Docker de gran tamaño

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

Cómo mejorar su flujo de trabajo 10 veces: 17 aplicaciones esenciales

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

Toque para ganar: Telegram puede incorporar a los próximos 10 mil millones de usuarios de criptomonedas antes de Solana

Cómo mejorar su flujo de trabajo 10 veces: 17 aplicaciones esenciales

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps