En este documento, se describe cómo implementar, diseñar y planificar actualizaciones en un entorno de Google Kubernetes Engine (GKE) de varios clústeres. Si bien en este documento se usa Ingress de varios clústeres para las actualizaciones, los conceptos se pueden aplicar a otras soluciones. Este documento está dirigido a los Google Cloud administradores que se encargan de mantener las flotas de los clústeres de GKE.
Administración del ciclo de vida de los clústeres de GKE
La administración del ciclo de vida del clúster puede definirse como las estrategias y la planificación necesarias para mantener actualizada y en buen estado una flota de clústeres de Kubernetes sin infringir los SLO de servicio. Con las estrategias y la planificación adecuadas, la administración del ciclo de vida del clúster debe ser rutinaria, predecible y sin problemas.
Para obtener más información sobre cómo administrar la versión de GKE de un clúster, consulta Acerca de las clúster de GKE de GKE. Para obtener más información sobre cómo administrar todos los tipos de cambios durante el ciclo de vida de un clúster, consulta Administra los cambios en el ciclo de vida del clúster para minimizar las interrupciones.
Administración del ciclo de vida de varios clústeres de GKE
En esta sección, se describen múltiples estrategias de administración del ciclo de vida de varios clústeres de GKE y cómo planificarlas.
Consideraciones de planificación y diseño
La arquitectura de varios clústeres de GKE influye en la selección de una estrategia de administración del ciclo de vida de los clústeres. Antes de analizar estas estrategias, es importante tener en cuenta algunas decisiones de diseño que pueden afectar o verse afectadas por la estrategia de administración del ciclo de vida de los clústeres.
Tipo de clústeres
Si usas la actualización automática de GKE como una estrategia de administración del ciclo de vida de los clústeres, el tipo de clúster puede ser importante. Por ejemplo, los clústeres regionales tienen varios nodos del plano de control en los que los nodos del plano de control se actualizan de forma automática, uno a la vez, y los clústeres zonales tienen un único nodo de plano de control. Si no usas la actualización automática de GKE y consideras que todos los clústeres de Kubernetes son una infraestructura desechable, es posible que no importe el tipo de clúster que elijas cuando se decide una estrategia de administración del ciclo de vida de los clústeres. Puedes aplicar las estrategias que se analizaron en la siguiente sección, Administración del ciclo de vida de varios clústeres de GKE a cualquier tipo de clúster.
Ubicación y huella del clúster
Considera los siguientes factores cuando decidas la ubicación y la huella del clúster:
- Zonas y regiones en las que se necesitan los clústeres
- Cantidad y tamaño de clústeres necesarios
El primer factor suele ser fácil de abordar, ya que las zonas y las regiones las establecen tu empresa y las regiones en las que entregas servicios a los usuarios.
Abordar la cantidad de clústeres y su tamaño, por lo general, pertenece a las siguientes categorías, cada una con ventajas y desventajas:
- Cantidad pequeña de clústeres grandes. Puedes elegir usar la redundancia y la resiliencia que proporcionan los clústeres regionales y ubicar uno (o dos) clústeres regionales grandes por región. La ventaja de este enfoque es la sobrecarga operativa baja de administrar varios clústeres. La desventaja es que puede afectar a una gran cantidad de servicios a la vez debido a su gran área de impacto.
- Gran cantidad de clústeres pequeños. Puedes crear una gran cantidad de clústeres pequeños para reducir el área de impacto de los clústeres, ya que tus servicios se dividen en varios. Este enfoque también funciona bien para clústeres efímeros de corta duración (por ejemplo, clústeres que ejecutan una carga de trabajo por lotes). La desventaja de este enfoque es que genera una sobrecarga operativa más alta, ya que hay más clústeres que se deben actualizar. También pueden existir costos adicionales asociados a una mayor cantidad de nodos del plano de control. Puedes compensar los costos y la sobrecarga operativa alta con automatización, un programa y una estrategia predecibles, y establecer una coordinación cuidadosa entre los equipos y los servicios que se verían afectados.
En este documento, no se recomienda un enfoque sobre otro; son opciones. En algunos casos, puedes elegir ambos patrones de diseño para diferentes categorías de servicios.
Las siguientes estrategias funcionan con cualquiera de las opciones de diseño.
Planificación de la capacidad
Cuando planifiques la capacidad, es importante tener en cuenta la estrategia del ciclo de vida de los clústeres elegida. Para la planificación de la capacidad, se deben tener en cuenta los siguientes eventos de carga y mantenimiento de servicios comunes:
- Eventos planificados, como actualizaciones de los clústeres
- Eventos no planificados, como interrupciones de los clúster, por ejemplo, envíos de configuración errónea y lanzamientos incorrectos
Cuando planificas la capacidad, debes tener en cuenta las interrupciones totales o parciales. Si diseñas solo para los eventos de mantenimiento planificados, todos los servicios distribuidos deben tener un clúster adicional de los necesarios. De esta manera, puedes quitar un clúster de la rotación a la vez para actualizarlo sin modificar el servicio. Este enfoque también se conoce como planificación de capacidad N+1. Si diseñas para eventos de mantenimiento planificados y no planificados, todos los servicios distribuidos deben tener dos (o más) clústeres adicionales de los necesarios a fin de entregar la capacidad prevista: uno para el evento planificado y uno para un evento no planificado en caso que suceda durante el período de mantenimiento planificado. Este enfoque también se conoce como planificación de capacidad N+2.
En las arquitecturas de varios clústeres, los términos desvío y desborde se usan con frecuencia. Estos términos hacen referencia al proceso de quitar (o desviar) el tráfico de un clúster y redireccionarlo (o desbordarlo) a otros clústeres durante las actualizaciones y los eventos de mantenimiento. Este proceso se lleva a cabo mediante el uso de soluciones de Herramientas de redes, como Ingress de varios clústeres o algún otro método de balanceo de cargas. El uso cuidadoso del desvío y el desborde es la base de algunas estrategias de administración del ciclo de vida de los clústeres. Cuando planificas la capacidad, debes tener en cuenta el desvío y el desborde. Por ejemplo, cuando se desvía un solo clúster, debes tener en cuenta si los demás clústeres tienen suficiente capacidad para manejar el tráfico desbordado adicional. Entre otras consideraciones, se incluyen la capacidad suficiente en la zona o la región, o la necesidad de enviar tráfico a una región diferente (si usas un solo clúster regional por región). En el siguiente diagrama, se muestra el tráfico que se quita (a veces denominado “desviar un clúster”) de un clúster y se envía a otro clúster que ejecuta el mismo servicio distribuido.
Clústeres y servicios distribuidos
El diseño del clúster basado en servicios determina que la arquitectura del clúster (cantidad, tamaño y ubicación) se establece mediante los servicios que deben ejecutarse en los clústeres. Por lo tanto, la ubicación de tus clústeres está determinada según la ubicación en la que se necesiten los servicios distribuidos. Ten en cuenta lo siguiente cuando elijas la ubicación de los servicios distribuidos:
- Requisito de ubicación. ¿En qué regiones necesita que se entregue el servicio?
- Importancia. ¿Qué importancia tiene la disponibilidad de un servicio para la empresa?
- SLO. ¿Cuáles son los objetivos de nivel de servicio del servicio (por lo general, se basan en la importancia)?
- Resiliencia. ¿Qué nivel de resiliencia debe tener el servicio? ¿Debe soportar fallas de clústeres, zonales o incluso regionales?
Cuando planificas las actualizaciones de los clústeres, debes tener en cuenta la cantidad de servicios a la que afecta un solo clúster cuando se desvía y que se deben desbordar cada uno de los servicios en otros clústeres adecuados. Los clústeres pueden ser de usuario único o de multiusuario. Los clústeres de usuario único entregan un solo servicio o un producto representado por un conjunto de servicios. Los clústeres de usuario único no comparten el clúster con otros servicios o productos. Los clústeres de multiusuario pueden ejecutar varios servicios y productos que, por lo general, se particionan en espacios de nombres.
Impacto para los equipos
Un evento de clúster no solo afecta a los servicios, sino también a los equipos. Por ejemplo, es posible que el equipo de DevOps deba redireccionar o detener sus canalizaciones de CI/CD durante una actualización del clúster. Del mismo modo, los equipos de asistencia pueden recibir alertas sobre interrupciones planificadas. La automatización y las herramientas deben implementarse para suavizar el impacto en varios equipos. La actualización de un clúster o de una flota de clústeres deben considerarse como de rutina y sin problemas cuando se informa a todos los equipos.
Tiempo, programación y coordinación
Kubernetes lanza una versión secundaria nueva de forma trimestral y mantiene las últimas tres actualizaciones. Debes planificar con cuidado el tiempo y la programación de las actualizaciones de un clúster. Debe haber un acuerdo entre los propietarios, los operadores del servicio y los administradores de la plataforma cuando se realizan estas actualizaciones. Cuando planifiques las actualizaciones, ten en cuenta las siguientes preguntas:
- ¿Con qué frecuencia realizas actualizaciones? ¿Actualizas cada trimestre o de acuerdo a un cronograma diferente?
- ¿Cuándo realizas las actualizaciones? ¿Realizas las actualizaciones al principio del trimestre cuando el negocio disminuye o durante otros tiempos de inactividad empresarial que genera tu industria?
- ¿Cuándo no deberías realizar las actualizaciones? ¿Tienes una planificación clara para cuando no debes realizar actualizaciones, por ejemplo, evitar eventos de escala máxim, como Black Friday, Cyber Monday o durante conferencias de alto perfil y otros eventos específicos de la industria?
Es importante contar con una estrategia que se comunique de forma clara a los propietarios del servicio, y los equipos de operaciones y asistencia al cliente. No debería haber sorpresas y todos deberían saber cuándo y cómo se actualizan los clústeres. Esto requiere una buena coordinación con todos los equipos involucrados. Un único servicio tiene varios equipos que interactúan con él. Por lo general, estos equipos pueden agruparse en las siguientes categorías:
- El desarrollador del servicio, que es el responsable de crear y codificar la lógica empresarial en un servicio
- El operador del servicio, que es el responsable de ejecutar el servicio de forma segura y confiable. Los operadores pueden estar compuestos de varios equipos, como el administrador de seguridad o de políticas, el administrador de red y los equipos de asistencia al cliente
Todos deben comunicarse durante las actualizaciones de los clústeres para adoptar las medidas adecuadas durante este tiempo. Un enfoque es planificar las actualizaciones de la misma manera que se planifica para un incidente de interrupción. Tienes un comandante de incidentes, una sala de chat y una retrospectiva (incluso si no se vieron afectados los usuarios). Para obtener más información, consulta Respuesta ante incidentes.
Estrategias del ciclo de vida de un clúster de GKE
En esta sección, se analizan las principales estrategias de administración del ciclo de vida de los clústeres que se usan con frecuencia en la arquitectura de varios clústeres de GKE. Es importante tener en cuenta que una estrategia no funcionará en todas las situaciones y que podrías elegir varias estrategias para múltiples categorías de servicios y necesidades de la empresa.
Actualizaciones progresivas
En el siguiente diagrama, se muestra la estrategia de actualización progresiva.
Mediante un balanceador de cargas, se desvía todo el tráfico de un clúster de GKE, que se actualiza. La carga del tráfico desviado se desborda a un clúster de GKE diferente.
Las actualizaciones progresivas son la estrategia más sencilla y rentable de las que se analizan en este documento. Puedes comenzar con una cantidad n de clústeres que ejecutan la versión old_ver (o la de producción actual). Luego, desvías m clústeres a la vez, en el que m es menor que n. A continuación, borra y vuelve a crear los clústeres nuevos con la versión nueva, o actualiza los clústeres desviados.
La decisión entre borrar y actualizar clústeres nuevos depende de su tamaño y si consideras que los clústeres son una infraestructura inmutable. La infraestructura inmutable determina que, en lugar de actualizar un clúster de forma constante, que puede producir resultados no deseados en el tiempo, creas clústeres nuevos y evitas cualquier desvío de configuración imprevisto.
Si usas GKE, puedes crear un clúster de GKE con un único comando o una llamada a la API. La estrategia nueva del clúster requiere que se almacene toda la configuración del clúster (manifiestos del clúster) fuera de él, por lo general, en Git. Luego, puedes usar la misma plantilla de configuración en el clúster nuevo. Si este es un clúster nuevo, asegúrate de que las canalizaciones de CI/CD apunten hacia el clúster correcto. Después de que el clúster esté configurado de forma correcta, puedes enviar con lentitud el tráfico de vuelta al clúster mientras supervisas los SLO de los servicios.
El proceso se repite en todos los clústeres. Según la planificación de capacidad, puedes actualizar varios clústeres a la vez sin infringir los SLO de servicio.
Usa la estrategia de actualización progresiva si valoras la simplicidad y el costo por sobre la resiliencia. En esta estrategia, nunca debes superar la capacidad requerida de la flota de GKE para todos los servicios distribuidos.
En el siguiente diagrama, se compara el cronograma y el requisito de capacidad de servicio durante la actualización de un clúster de GKE en una arquitectura de varios clústeres.
En el diagrama anterior, se muestra que durante todo el proceso de actualización de GKE, la capacidad para admitir servicios nunca se encuentra por debajo de lo que se requiere. Cuando el clúster de GKE que se actualizará se quita de la rotación, los demás clústeres se escalan verticalmente para admitir la carga.
Actualizaciones azules y verdes
En el siguiente diagrama, se muestra una estrategia de actualización azul y verde.
En el diagrama anterior, se agrega un clúster de GKE nuevo que ejecuta la versión nueva. Luego, se usa un balanceador de cargas para enviar tráfico al clúster nuevo mientras se desvía con lentitud uno de los clústeres antiguos hasta que se deje de enviar el tráfico a él. Se puede quitar el clúster antiguo que se desvió por completo. Se puede realizar el mismo proceso para los clústeres restantes.
La estrategia de actualización azul y verde proporciona cierta resiliencia.
Esta estrategia es similar a las actualizaciones progresivas, pero es más costosa. La única diferencia es que, en lugar de desviar los clústeres existentes primero, debes crear m clústeres nuevos con la versión, en el que m es menor o igual que n. Agrega los clústeres nuevos a las canalizaciones de CI/CD y, luego, desborda con lentitud el tráfico mientras supervisas los SLO del servicio. Cuando los clústeres nuevos toman el tráfico por completo, debes desviar y borrar los clústeres con la versión anterior.
La estrategia azul y verde para actualizar clústeres es similar a una estrategia azul y verde que se usa, por lo general, en los servicios. La creación de varios clústeres nuevos a la vez aumenta el costo general, pero obtienes el beneficio de acelerar el tiempo de actualización de la flota. El costo agregado es solo para el tiempo de la actualización cuando se usan clústeres adicionales. El beneficio de crear clústeres nuevos primero es que, en caso de que se produzca un error, puedes revertirlo. También puedes probar el clúster nuevo antes de enviarle tráfico de producción. Dado que estos clústeres coexisten con sus versiones anteriores equivalentes durante un período breve, los costos adicionales son mínimos.
Usa la estrategia de actualización azul y verde si valoras la simplicidad y la resiliencia por sobre los costos. Los clústeres adicionales se agregan primero y exceden la capacidad requerida de la flota de GKE durante las actualizaciones.
En el diagrama anterior, agregar un clúster nuevo primero aumenta de forma temporal la capacidad disponible sobre la capacidad requerida, mientras que otro clúster de la flota se desvía y se quita de ella. Sin embargo, después de quitar uno de los clústeres antiguos (completamente desviados), la capacidad vuelve a ser la necesaria. El cambio de capacidad se destaca, ya que puede haber un aumento en el costo con este modelo, en función de la cantidad y el tamaño de los clústeres en la flota.
Actualizaciones de los clústeres de la versión canary
La actualización de un clúster de la versión canary es la estrategia más resiliente y compleja de las que se analizan en este documento. Esta estrategia abstrae por completo la administración del ciclo de vida de los clústeres de la administración del ciclo de vida de los servicios, lo que ofrece el riesgo más bajo y la resiliencia más alta para tus servicios. En las estrategias de actualización anteriores (azul y verde, y progresiva), conservas toda la flota de GKE en una sola versión. En esta estrategia, se mantienen dos o quizás tres flotas de clústeres de GKE que ejecutan versiones diferentes. En lugar de actualizar los clústeres, migra los servicios de una flota de clústeres a la otra flota a lo largo del tiempo. Cuando se desvía la flota de GKE más antigua (es decir, todos los servicios se migraron a la flota de GKE con la siguiente versión), deberás borrarla.
Esta estrategia requiere que mantengas un mínimo de dos flotas de GKE: una para la producción actual y otra para la próxima versión candidata de producción. También puedes mantener más de dos flotas de GKE. Las flotas adicionales te dan más flexibilidad, pero el costo y la sobrecarga operativa también aumentarán. Contar con estas flotas adicionales no es lo mismo que tener clústeres en diferentes entornos, por ejemplo, en los entornos de desarrollo, de etapa de pruebas y de producción. Los entornos que no son de producción son ideales para probar las funciones y los servicios de Kubernetes con tráfico que no es de producción.
Esta estrategia de usar de actualizaciones de clústeres de la versión canary determina que mantienes varias versiones de la flota de GKE en el entorno de producción. Es similar a las estrategias de lanzamiento Canary que suelen usar los servicios. Con las implementaciones de servicios de la versión canary, el propietario del servicio siempre puede identificar problemas en una determinada versión del servicio. Con los clústeres de la versión canary, el propietario de los servicios también debe tener en cuenta las versiones de la flota de GKE en las que se ejecutan sus servicios. Es posible que una versión única del servicio distribuido se ejecute en varias versiones de la flota de GKE. La migración de un servicio puede ocurrir de forma gradual, de modo que puedas ver los efectos del servicio en la flota nueva antes de enviar todo el tráfico del servicio a los clústeres con versiones nuevas.
En el siguiente diagrama, se muestra que administrar diferentes flotas de clústeres de GKE puede abstraer por completo el ciclo de vida de los clústeres del ciclo de vida de los servicios.
En el diagrama anterior, se muestra que el frontend de un servicio distribuido se migra con lentitud de una flota de clústeres de GKE a la siguiente flota que ejecuta la versión nueva hasta que la flota más antigua se desvía por completo. Una vez que la flota se desvía, se puede quitar y se crea una flota nueva. Todos los servicios se migran a la siguiente flota y se quitan las flotas más antiguas a medida que se desvían.
Usa la estrategia de actualización de clústeres de la versión canary si valoras la resiliencia por sobre todo lo demás.
Elige una estrategia de actualización
El siguiente diagrama puede ayudarte a determinar qué estrategia es la mejor para ti en función de las necesidades de los servicios y de la empresa.
En el diagrama anterior, se muestra un árbol de decisión que te ayuda a elegir la estrategia de actualización adecuada para ti:
- Si no necesitas control total sobre la versión exacta y el momento de la actualización, puedes elegir la función de actualización automática disponible en GKE.
- Puedes elegir la estrategia de actualización progresiva si tu prioridad es el costo bajo.
- Puedes elegir la estrategia azul y verde si tu prioridad es equilibrar el costo y la resiliencia.
- Puedes elegir la estrategia de actualización de clústeres de la versión canary, si tu prioridad es la resiliencia por sobre el costo.
Administración del tráfico de varios clústeres para el ciclo de vida de clúster de GKE
Para mantener la disponibilidad del servicio durante las actualizaciones de varios clústeres, debes agotar y redireccionar el tráfico entre los clústeres. Puedes administrar este tráfico con la puerta de enlace de varios clústeres (recomendada) o con Ingress de varios clústeres. La puerta de enlace de varios clústeres es la sucesora de Ingress de varios clústeres y proporciona un enfoque más expresivo y orientado a los roles para la creación de redes de servicios.
Usa la puerta de enlace de varios clústeres para administrar el ciclo de vida del clúster
La puerta de enlace de varios clústeres (MCG) usa la API de Gateway para administrar el tráfico de los servicios implementados en varios clústeres de GKE dentro de una flota.
El controlador de GKE Gateway es un servicio alojado en Google que supervisa los recursos de Gateway y HTTPRoute en un clúster de configuración designado. El controlador aprovisiona y mantiene automáticamente la infraestructura de balanceo de cargas, lo que proporciona un único punto de entrada unificado para las aplicaciones en todos los clústeres de la flota. Esta arquitectura te permite desacoplar el ciclo de vida del balanceador de cargas de los clústeres individuales de GKE en los que residen las cargas de trabajo.
Para la administración del ciclo de vida de clúster de GKE, la puerta de enlace de varios clústeres habilita estrategias avanzadas de control de tráfico:
- Actualizaciones azul-verde: Implementa un nuevo clúster “verde” y cambia gradualmente el tráfico del clúster “azul” modificando los pesos en el recurso HTTPRoute.
- Balanceo de cargas basado en la capacidad: Redirige automáticamente el tráfico cuando un servicio en un clúster alcanza su límite de capacidad definido, lo que ayuda a protegerlo de la sobrecarga durante las actualizaciones continuas.
- Conmutación por error basada en el estado: Supervisa el estado de los backends en todos los clústeres y redirecciona automáticamente el tráfico lejos de un clúster que se está vaciando o que experimenta problemas.
Para obtener más información, sigue el instructivo para implementar una puerta de enlace de varios clústeres para la división del tráfico ponderado.
Usa Ingress de varios clústeres para administrar el ciclo de vida de los clústeres
Ingress de varios clústeres es otra solución para la administración del tráfico de varios clústeres. Ingress de varios clústeres es un controlador de entrada de varios clústeres alojado en Google Cloudpara clústeres de GKE que admite la implementación de recursos de balanceo de cargas compartidas entre clústeres y regiones. Ingress de varios clústeres es una solución para dirigir tráfico de clientes a un servicio distribuido que se ejecuta en diversos clústeres en varias regiones. Al igual que Ingress para GKE, usa Cloud Load Balancing para enviar tráfico a un servicio de backend. El servicio de backend es el servicio distribuido. El servicio de backend envía el tráfico a varios backends, que son servicios de Kubernetes que se ejecutan en varios clústeres de GKE. Para el tráfico de servicio a servicio entre clústeres, puedes usar tecnología de la malla de servicios, como Cloud Service Mesh o Istio, que proporcionan funcionalidades similares entre los servicios distribuidos.
Para obtener más información, sigue el instructivo para actualizar un entorno de GKE de varios clústeres con Ingress de varios clústeres.
¿Qué sigue?
- Obtén más información sobre la puerta de enlace de varios clústeres.
- Obtén más información sobre Ingress de varios clústeres.