Mejores prácticas de Kubernetes. Actualización del clúster de tiempo de inactividad cero de Kubernetes

Mejores prácticas de Kubernetes. Creación de contenedores pequeños
Las mejores prácticas de Kubernetes. Organización de Kubernetes con el espacio de
nombres de mejores prácticas de Kubernetes . Prueba de viabilidad de Kubernetes con pruebas de preparación y vitalidad
Mejores prácticas de Kubernetes . Establecer consultas y límites de
recursos Mejores prácticas de Kubernetes. Corregir Terminar
Desactivar las mejores prácticas de Kubernetes. Mapeo de servicios externos

Todo el mundo sabe lo bueno que es mantener sus aplicaciones actualizadas. Kubernetes y Docker pueden facilitar mucho el proceso de actualización, por lo que puede crear un nuevo contenedor con dependencias actualizadas y desplegarlo fácilmente. Además de actualizar las dependencias de las aplicaciones, Kubernetes actualiza constantemente las características y las políticas de seguridad.
Por lo tanto, los nodos base y la infraestructura de Kubernetes deben estar actualizados. En esta serie, aprenderemos cómo Google Kubernetes Engine puede actualizar fácilmente el clúster de Kubernetes.

Por lo tanto, al actualizar un clúster, debe actualizar los asistentes y nodos, y los asistentes deben actualizarse primero. Veamos cómo actualizar ambos elementos con Google Kubernetes Engine. Este sistema actualiza automáticamente el asistente a medida que libera versiones puntuales. Sin embargo, por regla general, no se actualizará a la nueva versión, por ejemplo, 1.7-1.8, automáticamente. Cuando esté listo para actualizar a la nueva versión, simplemente haga clic en el enlace Actualizar disponible en la consola GKE, después de lo cual aparecerá un cuadro de diálogo en la pantalla. Contiene una advertencia de que cambiar la versión maestra puede llevar varios minutos, durante los cuales no puede editar este clúster, mientras que durante la actualización del asistente sus implementaciones y servicios continuarán funcionando normalmente. Sin embargo, toda la infraestructura que necesita la API de Kubernetes no funcionará.



Esto significa que QPTL y todas las aplicaciones que usan la API de Kubernetes para obtener información del clúster se deshabilitarán y no podrá realizar ningún cambio en el clúster.

Veamos cómo puede resolver este problema actualizando el asistente sin tiempo de inactividad.



Si bien el clúster de zona GKE estándar solo admite un asistente, puede crear clústeres regionales que proporcionen asistentes de alta disponibilidad de varias zonas. Por lo tanto, al crear su clúster, asegúrese de elegir una opción regional.

Sus nodos y asistentes se crearán automáticamente en tres zonas, y los asistentes tendrán direcciones IP con equilibrio de carga. Esto mantendrá la API de Kubernetes funcionando sin problemas durante la actualización.

Al actualizar nodos, hay varias estrategias diferentes que puede usar. Quiero centrar su atención en dos cosas: actualizaciones continuas y migraciones mediante grupos de nodos.

La forma más fácil de actualizar los nodos de Kubernetes es usar la actualización continua, el mecanismo de actualización predeterminado que GKE usa para actualizar sus nodos. Funciona de la siguiente manera.



Los nodos de la versión anterior se retiran uno tras otro para que todos los módulos dejen de funcionar en ellos. Luego, estos nodos se eliminan y, en lugar de ellos, aparecen nuevos nodos de la versión actualizada de Kubernetes uno tras otro. Después de que un nodo comienza a funcionar, el otro continúa con el proceso de actualización, y esto continúa hasta que se actualicen todos los nodos. Puede permitir que GKE administre este proceso por usted activando la actualización automática de nodos en el grupo de nodos seleccionando Habilitado.



Si no lo hace, el panel de control de GKE le avisará cuando haya una nueva actualización disponible. En este caso, para realizar la actualización, debe hacer clic en el enlace Actualizaciones automáticas de nodos y seguir las instrucciones.



Al mismo tiempo, es muy importante asegurarse de que sus pods estén controlados utilizando el conjunto de réplicas, un conjunto con estado o algo similar. Entonces los hogares autónomos no serán reestructurados.

Aunque las actualizaciones continuas son bastante fáciles de hacer con GKE, todavía tiene algunos inconvenientes. Una de ellas es que cuando actualiza, la capacidad de su clúster disminuye en un nodo. Esta desventaja se elimina fácilmente al escalar el grupo de nodos al agregar capacidad adicional y luego reducirla después de la actualización.

Además, la naturaleza totalmente automatizada de las actualizaciones continuas facilita la actualización, pero le deja con menos control sobre el proceso. Si algo sale mal y tiene que volver a la versión anterior, llevará tiempo detener las actualizaciones y descartar los cambios que ya se hayan realizado. Veamos cómo puede usar grupos de múltiples nodos para actualizar su clúster.



Por lo tanto, en lugar de actualizar el grupo activo de nodos mediante actualizaciones continuas, crea un grupo completamente nuevo de nodos, espera a que se inicien todos los nodos y luego transfiere las cargas de trabajo de un nodo a la vez. A medida que ejecuta estos comandos usted mismo, obtiene más control sobre el proceso de migración, mientras que GKE continúa administrando sus nodos.
Supongamos que un clúster de Kubernetes consta de 3 máquinas virtuales. Puede ver los nodos con el comando get node.



Para crear un nuevo grupo de nodos llamado grupo dos, debe usar el comando apropiado, configurándolo exactamente de la misma manera que el comando para el grupo anterior.



Opcionalmente, también puede usar la GUI para crear un nuevo grupo de nodos. Para obtener más información sobre esto, use el enlace de creación del grupo de nodos ubicado debajo de este video.

Si vuelve a comprobar el número de nodos, encontrará tres nuevos nodos con el nombre del grupo de dos grupos, sin embargo, los pods aún estarán en los nodos antiguos.



Vamos a moverlos a un nuevo grupo de nodos, moviendo un nodo a la vez en modo continuo. Para hacer esto, use el comando cordon para cada nodo antiguo para protegerlos y evitar la formación de nuevos hogares en ellos.



Tan pronto como todos los nodos antiguos estén cercados, la creación de hogares se planificará solo en nuevos nodos. Esto significa que puede comenzar a eliminar las vainas de los nodos antiguos, y Kubernetes planificará automáticamente crearlos en nuevos nodos. Luego debe "drenar" cada nodo, lo que conducirá a la eliminación de todos los hogares en el nodo.



Después de hacer esto para un nodo, asegúrese de que los nuevos pods estén listos y funcionando, y luego pase al siguiente nodo. Si tuvo algún problema durante la migración, ejecute uncordon para el grupo anterior y luego ejecute cordon y drenaje para el grupo nuevo. En este caso, las vainas se transferirán automáticamente al grupo anterior. Una vez que todos los pods se hayan transferido de forma segura, puede eliminar el grupo anterior. Para hacer esto, reemplace el grupo predeterminado con el grupo que desea eliminar.



Google Kubernetes Engine le permite mantener actualizado su clúster de Kubernetes con solo unos pocos clics. Recomiendo utilizar clústeres regionales GKE para asistentes de alta disponibilidad y actualizaciones automáticas de nodos para garantizar actualizaciones correctas y sin problemas.

Si necesita control adicional sobre el proceso de actualización de nodos, puede proporcionarlo con la ayuda de grupos, sin renunciar a las ventajas de la plataforma de administración que proporciona GKE.

Si no está utilizando GKE, utilice el método de actualización continua o los nodos del grupo de nodos para actualizar los nodos de su clúster. Pero recuerde que en este caso debe agregar manualmente nuevos nodos al clúster y realizar actualizaciones críticas usted mismo, lo que puede no ser bastante simple.

Continuará muy pronto ...

Un poco de publicidad :)

Gracias por estar con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más materiales interesantes? Apóyenos haciendo un pedido o recomendando a sus amigos VPS basado en la nube para desarrolladores desde $ 4.99 , un análogo único de servidores de nivel básico que inventamos para usted: toda la verdad sobre VPS (KVM) E5-2697 v3 (6 núcleos) 10GB DDR4 480GB SSD 1Gbps desde $ 19 o cómo dividir el servidor? (las opciones están disponibles con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).

Dell R730xd 2 veces más barato en el centro de datos Equinix Tier IV en Amsterdam? ¡Solo tenemos 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV desde $ 199 en los Países Bajos!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $ 99! Lea sobre Cómo construir un edificio de infraestructura. clase c con servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?