En este documento se describe cómo diseñar, planificar e implementar actualizaciones en un entorno de Google Kubernetes Engine (GKE) de varios clústeres. Aunque en este documento se usa Multi Cluster Ingress para las actualizaciones, los conceptos se pueden aplicar a otras soluciones, como configurar manualmente un balanceador de carga externo. Este documento incluye un tutorial complementario que muestra cómo actualizar un entorno de GKE de varios clústeres con Multi Cluster Ingress. Este documento está dirigido a los administradores que se encargan de mantener flotas de clústeres de GKE. Google Cloud
La necesidad de una arquitectura de varios clústeres
En esta sección se analizan varios motivos por los que puede necesitar una arquitectura de Kubernetes multiclúster.
Kubernetes como infraestructura
En este documento, los clústeres de Kubernetes se consideran componentes de la infraestructura. La infraestructura es desechable. No se debe dar ningún trato especial a ningún componente de la infraestructura, ya que los componentes están ahí para cumplir un propósito. El objetivo de Kubernetes es proporcionar automatización y orquestación a los desarrolladores y operadores para ofrecer aplicaciones y servicios basados en contenedores a los consumidores. Los consumidores pueden ser equipos internos, otros servicios o clientes externos.
Situaciones habituales de varios clústeres
Además del argumento de Kubernetes como infraestructura, hay varios motivos para tener un entorno de varios clústeres:
- Área geográfica. Muchos servicios deben estar en varias regiones. Si colocas un servicio más cerca del consumidor (en su región), la experiencia será mejor, ya que la latencia será menor que si el servicio se ofrece desde una sola región. Un clúster de Kubernetes se ejecuta en una sola región. En el caso de los despliegues multirregionales, se necesitan varios clústeres de Kubernetes en varias regiones. Los entornos multinube o de nube híbrida también requieren varios clústeres en cada entorno. Los clústeres de Kubernetes también suelen estar ubicados en el mismo lugar que las fuentes de datos (con estado) de los Servicios. Es posible que algunas aplicaciones deban estar en la misma ubicación (región y zona) que su backend, como un sistema de gestión de bases de datos relacionales (RDBMS).
- Tenencia y entornos. Los clústeres de Kubernetes se han diseñado para entornos multiinquilino. Varios equipos pueden compartir un mismo clúster para sus respectivos servicios. Kubernetes proporciona recursos estándar, como espacios de nombres, control de acceso basado en roles (RBAC), políticas de red y autenticación, para configurar correctamente los controles de acceso en entornos multiarrendatario. En algunos casos, es posible que determinados Servicios no puedan coexistir en un clúster con otros Servicios debido a la política de la empresa, la privacidad, la seguridad o la normativa del sector. En estos casos, se necesitan varios clústeres para separar determinados inquilinos en sus propios clústeres. Los entornos (desarrollo, staging y producción) también se suelen crear como clústeres independientes. El alcance del acceso y los tipos de aplicaciones instaladas en diferentes entornos varían enormemente y deben mantenerse como clústeres independientes.
- Composición y función. A veces, se crea un clúster para realizar una función concreta. Por ejemplo, los flujos de trabajo de aprendizaje automático usan Kubeflow o tareas de analíticas de datos que pueden requerir nodos con GPUs u otros requisitos de hardware para clústeres de instancias formados por VMs Spot con el fin de realizar cargas de trabajo de analíticas por lotes. Es posible que estos requisitos de hardware no se apliquen a otros Servicios. Puede que estos flujos de trabajo no sean cruciales para el funcionamiento de la empresa y que requieran clústeres efímeros (clústeres de corta duración). Los servicios compartidos, como la observabilidad (registros, métricas y trazas) y las herramientas de CI/CD, se adaptan mejor a su propio clúster de administrador de plataforma. A menudo, se ven clústeres específicos de funciones independientes para flujos de trabajo que no son esenciales para la empresa.
- Resiliencia. A menudo se usan varios clústeres para aumentar la resiliencia en un entorno. Cada clúster tiene un área de impacto. En este contexto, un área de impacto es el número de servicios que se ven afectados negativamente debido a un fallo o un error de configuración de un clúster, o bien a que un clúster se desconecta debido a tareas de mantenimiento planificadas o no planificadas. Si tienes un gran número de clústeres de menor tamaño, tendrás un gran número de áreas de impacto de menor tamaño. Si un servicio existe en dos clústeres, estos comparten la carga por igual. Si un clúster se queda sin conexión, se verá afectado el 50% del tráfico. Si el mismo Servicio se hubiera ofrecido mediante un solo clúster, cualquier evento en ese clúster habría provocado una interrupción del 100% de ese Servicio. Por este motivo, también se suelen usar varios clústeres para la recuperación tras fallos.
Este documento se centra en la resiliencia de los despliegues multiclúster.
Servicios distribuidos y de varios clústeres
Un servicio distribuido es un servicio de Kubernetes que se despliega en varios clústeres de Kubernetes. Los servicios distribuidos son servicios sin estado y actúan de forma idéntica en varios clústeres. Esto significa que un servicio distribuido tiene el mismo nombre de servicio de Kubernetes y se implementa en el mismo espacio de nombres en varios clústeres. Los servicios de Kubernetes están vinculados al clúster de Kubernetes en el que se ejecutan. Si un clúster de Kubernetes se desconecta, también lo hace el servicio de Kubernetes. Los servicios distribuidos se abstraen de los clústeres de Kubernetes individuales. Si uno o varios clústeres de Kubernetes están inactivos, el servicio distribuido puede estar online y dentro del objetivo de nivel de servicio (SLO).
En el siguiente diagrama, frontend es un servicio distribuido que se ejecuta en varios clústeres con el mismo nombre y espacio de nombres.
Con esta arquitectura, el servicio frontend no está vinculado a un solo clúster y se representa conceptualmente en el diagrama como una capa que abarca la capa de infraestructura del clúster de Kubernetes. Si falla alguno de los clústeres individuales que ejecutan el servicio frontend, este seguirá online.frontend
Hay servicios adicionales que se ejecutan en clústeres individuales: accounts
Service y ledger Service. Su tiempo de actividad y disponibilidad dependen del tiempo de actividad del clúster de Kubernetes en el que residen.
La resiliencia es uno de los motivos de los despliegues multiclúster. Los servicios distribuidos crean servicios resilientes en una arquitectura de varios clústeres. Los servicios sin estado son los candidatos ideales para los servicios distribuidos en un entorno multiclúster. Se aplican los siguientes requisitos y consideraciones cuando trabajas con servicios distribuidos:
Redes de varios clústeres. Puedes enviar tráfico destinado a un servicio distribuido a clústeres que ejecuten ese servicio mediante una tecnología de entrada multiclúster, como Multi Cluster Ingress, o bien usando tu propio balanceador de carga externo o solución de proxy. Independientemente de la opción que elijas, debes tener control sobre cuándo, dónde y cuánto tráfico se dirige a una instancia concreta de un servicio distribuido. En el siguiente diagrama se muestra un balanceador de carga que envía tráfico a un servicio distribuido
frontendque se ejecuta en dos clústeres de GKE.
Observabilidad. Usa herramientas para medir tus SLOs (normalmente, la disponibilidad y la latencia) de forma colectiva en un servicio distribuido. Esta configuración ofrece una vista global del rendimiento de cada servicio en varios clústeres. Aunque el servicio distribuido no es un recurso bien definido en la mayoría de las soluciones de observabilidad, puedes recoger y combinar métricas de servicios de Kubernetes individuales. Soluciones como Cloud Monitoring o herramientas de software libre como Grafana proporcionan métricas de servicio de Kubernetes. Las soluciones de malla de servicios, como Istio y Cloud Service Mesh, también proporcionan métricas de servicio sin necesidad de instrumentación.
Colocación de servicios. Los servicios de Kubernetes proporcionan tolerancia a fallos a nivel de nodo en un único clúster de Kubernetes. Esto significa que un servicio de Kubernetes puede resistir interrupciones de nodos. Durante las interrupciones de los nodos, un nodo del plano de control de Kubernetes vuelve a programar automáticamente los pods en nodos en buen estado. Un servicio distribuido proporciona tolerancia a fallos a nivel de clúster. Esto significa que un servicio distribuido puede resistir interrupciones del clúster. Cuando planifiques la capacidad de un servicio distribuido, debes tener en cuenta la colocación de este servicio. No es necesario que un servicio distribuido se ejecute en todos los clústeres. Los clústeres en los que se ejecuta un servicio distribuido dependen de los siguientes requisitos:
- ¿Dónde o en qué regiones se requiere el Servicio?
- ¿Cuál es el SLO necesario para el servicio distribuido?
- ¿Qué tipo de tolerancia a fallos se requiere para el servicio distribuido: clúster, zonal o regional? Por ejemplo, ¿necesitas varios clústeres en una sola zona o varios clústeres en varias zonas de una sola región o de varias regiones?
¿Qué nivel de interrupciones debería soportar el servicio distribuido en el peor de los casos? Las siguientes opciones están disponibles en la capa de clúster:
- N+1 (donde N representa el número de clústeres necesarios para satisfacer las necesidades de capacidad del servicio). Un servicio distribuido puede resistir un fallo de un solo clúster.
- N+2. Un servicio distribuido puede resistir dos fallos simultáneos. Por ejemplo, una interrupción planificada y otra no planificada de un servicio de Kubernetes en dos clústeres al mismo tiempo.
Lanzamientos y restauraciones. Los servicios distribuidos, como los servicios de Kubernetes, permiten realizar lanzamientos y restauraciones graduales. A diferencia de los servicios de Kubernetes, los servicios distribuidos permiten que los clústeres sean una unidad de implementación adicional como medio para realizar cambios graduales. Los lanzamientos y las reversiones también dependen de los requisitos del servicio. En algunos casos, es posible que tengas que actualizar el servicio en todos los clústeres al mismo tiempo, por ejemplo, para corregir un error. En otros casos, es posible que tengas que implementar el cambio lentamente (o de forma escalonada) un clúster a la vez. Este lanzamiento gradual reduce el riesgo para el servicio distribuido, ya que introduce cambios en el servicio de forma gradual. Sin embargo, este proceso puede tardar más en función del número de clústeres. No hay una estrategia de actualización que sea la mejor. A menudo, se utilizan varias estrategias de lanzamiento y reversión en función de los requisitos del servicio distribuido. Lo importante es que los servicios distribuidos deben permitir cambios graduales y controlados en el entorno.
Continuidad de la actividad empresarial y recuperación tras fallos (BCDR). Estos términos se suelen usar juntos. La continuidad de negocio se refiere a la continuación de los servicios críticos en caso de que se produzca un evento importante (planificado o no), mientras que la recuperación tras desastres se refiere a las medidas que se toman o que se deben tomar para que las operaciones de la empresa vuelvan a su estado normal después de dichos eventos. Hay muchas estrategias de continuidad de negocio y recuperación ante desastres que no se tratan en este documento. La continuidad de negocio y recuperación ante desastres requiere cierto nivel de redundancia en los sistemas y servicios. La premisa clave de los servicios distribuidos es que se ejecutan en varias ubicaciones (clústeres, zonas y regiones).
Las estrategias de continuidad de negocio y recuperación ante desastres suelen depender de las estrategias de implementación y restauración que hemos comentado anteriormente. Por ejemplo, si las implementaciones se realizan de forma escalonada o controlada, el efecto de un error o de una configuración incorrecta se puede detectar pronto sin que afecte a un gran número de usuarios. A gran escala y junto con una tasa de cambio rápida (por ejemplo, en las prácticas modernas de CI/CD), es habitual que no todos los usuarios reciban la misma versión de un servicio distribuido. La planificación y las estrategias de continuidad de negocio y recuperación ante desastres en sistemas y servicios distribuidos son diferentes de las arquitecturas monolíticas tradicionales. En los sistemas tradicionales, los cambios se realizan de forma generalizada, lo que afecta a un gran número de usuarios (o a todos), por lo que debe haber un sistema redundante o de copia de seguridad en caso de que se produzcan efectos no deseados. En los sistemas y servicios distribuidos, casi todos los cambios se realizan de forma gradual para que solo afecten a un pequeño número de usuarios.
Gestión del ciclo de vida de los clústeres. Al igual que las implementaciones y las reversiones controladas, los servicios distribuidos permiten gestionar el ciclo de vida de los clústeres de forma controlada. Los servicios distribuidos proporcionan resiliencia a nivel de clúster, por lo que los clústeres se pueden retirar de la rotación para realizar tareas de mantenimiento. La gestión del ciclo de vida de los clústeres es un principio de los servicios distribuidos que no se aplica a los servicios de Kubernetes.
El resto de este documento se centra en el aspecto del ciclo de vida del clúster de los servicios distribuidos.
Gestión del ciclo de vida de los clústeres de GKE
La gestión del ciclo de vida de los clústeres se puede definir como las estrategias y la planificación necesarias para mantener una flota de clústeres de Kubernetes en buen estado y actualizada sin incumplir los SLOs de los servicios. Si se aplican las estrategias y la planificación adecuadas, la gestión del ciclo de vida de los clústeres debería ser rutinaria, predecible y sin incidentes.
Este documento se centra en la gestión del ciclo de vida de GKE. Sin embargo, puedes aplicar estos conceptos a otras distribuciones de Kubernetes.
Gestionar y actualizar versiones de GKE
Antes de hablar sobre las estrategias y la planificación de la gestión del ciclo de vida de los clústeres, es importante saber qué es una actualización de clúster.
Un clúster contiene dos componentes: nodos del plano de control y nodos de trabajador. Para actualizar un clúster de Kubernetes, todos los nodos deben actualizarse a la misma versión. Kubernetes sigue un esquema de versionado semántico.
Las versiones de Kubernetes se expresan como X.Y.Z:, donde X es la versión principal, Y es la versión secundaria y Z es la versión del parche. Las versiones secundarias se publican aproximadamente cada tres meses (trimestralmente) y el proyecto de Kubernetes mantiene ramas de lanzamiento para las tres versiones secundarias más recientes. Esto significa que una versión secundaria de Kubernetes de nueve meses ya no se mantiene y puede requerir cambios en la API cuando actualices a la versión más reciente. Las actualizaciones de Kubernetes deben planificarse de forma periódica. Te recomendamos que hagas las actualizaciones de GKE planificadas cada trimestre o cada dos trimestres.
Los clústeres de GKE admiten versiones de Kubernetes de cualquier versión secundaria compatible. Hay al menos dos versiones secundarias disponibles en cualquier momento.
GKE es un servicio gestionado que ofrece actualizaciones automáticas para los nodos del plano de control y los nodos de trabajo.
Actualización automática de GKE
Actualización automática de GKE es una estrategia de ciclo de vida de clústeres popular y que se usa a menudo. La actualización automática de GKE ofrece una forma totalmente gestionada de mantener tus clústeres de GKE actualizados a versiones compatibles. Las actualizaciones automáticas de GKE actualizan los nodos del plano de control y los nodos de trabajador por separado:
Controla las actualizaciones automáticas. De forma predeterminada, los nodos del plano de control de GKE se actualizan automáticamente. Los clústeres de una sola zona y multizona tienen un único plano de control (nodo de plano de control). Durante las actualizaciones de los nodos del plano de control, las cargas de trabajo siguen ejecutándose. Sin embargo, no puedes implementar cargas de trabajo nuevas, modificar las que ya tengas ni hacer otros cambios en la configuración del clúster hasta que se complete la actualización.
Los clústeres regionales tienen varias réplicas del plano de control y solo se actualiza una réplica a la vez. Durante la actualización, el clúster sigue teniendo una alta disponibilidad y cada réplica del plano de control solo no está disponible mientras se actualiza.
Actualizaciones automáticas de nodos de trabajo. Los grupos de nodos se actualizan de uno en uno. En un grupo de nodos, los nodos se actualizan de uno en uno en un orden indefinido. Puedes cambiar el número de nodos que se actualizan a la vez, pero este proceso puede tardar varias horas en función del número de nodos y de sus configuraciones de carga de trabajo.
Estrategia del ciclo de vida de las actualizaciones automáticas de GKE
Te recomendamos que utilices la actualización automática de GKE siempre que sea posible. Las actualizaciones automáticas de GKE priorizan la comodidad sobre el control. Sin embargo, las actualizaciones automáticas de GKE ofrecen muchas formas de influir en cuándo y cómo se actualizan tus clústeres dentro de ciertos parámetros. Puedes influir en las ventanas de mantenimiento y las exclusiones de mantenimiento. Los canales de lanzamiento influyen en la selección de la versión y las estrategias de actualización de nodos influyen en el orden y el momento de las actualizaciones de nodos. A pesar de estos controles y de los clústeres regionales (con varios planos de control de Kubernetes), la actualización automática de GKE no garantiza el tiempo de actividad de los servicios. Puedes decidir no usar la función de actualización automática de GKE si necesitas una o varias de las siguientes opciones:
- Control de la versión exacta de los clústeres de GKE.
- Controla la hora exacta en la que quieres actualizar GKE.
- Controla la estrategia de actualización (que se explica en la siguiente sección) de tu flota de GKE.
Gestión del ciclo de vida de varios clústeres de GKE
En esta sección se describen varias estrategias de gestión del ciclo de vida de varios clústeres de GKE y cómo planificarlas.
Consideraciones sobre la planificación y el diseño
La arquitectura multiclúster de GKE influye en la selección de una estrategia de gestión del ciclo de vida de los clústeres. Antes de hablar de estas estrategias, es importante comentar ciertas decisiones de diseño que pueden afectar o verse afectadas por la estrategia de gestión del ciclo de vida del clúster.
Tipos de clústeres
Si usas la actualización automática de GKE como estrategia de gestió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 de plano de control, donde los nodos de plano de control se actualizan automáticamente de uno en uno, mientras que 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 infraestructura desechable, puede que no importe el tipo de clúster que elijas al decidir una estrategia de gestión del ciclo de vida de los clústeres. Puedes aplicar las estrategias que se describen en la siguiente sección, Gestión del ciclo de vida multiclúster de GKE, a cualquier tipo de clúster.
Ubicación y huella del clúster
A la hora de decidir la ubicación y el espacio del clúster, ten en cuenta los siguientes factores:
- Zonas y regiones en las que deben estar los clústeres.
- Número y tamaño de los clústeres necesarios.
El primer factor suele ser fácil de abordar, ya que las zonas y las regiones se determinan en función de tu empresa y de las regiones en las que ofreces tus servicios a los usuarios.
El número y el tamaño de los clústeres suelen clasificarse en las siguientes categorías, cada una con sus ventajas e inconvenientes:
- Pocos clústeres grandes. Puedes usar la redundancia y la resiliencia que ofrecen los clústeres regionales y colocar uno (o dos) clústeres regionales grandes por región. La ventaja de este enfoque es que la sobrecarga operativa de gestionar varios clústeres es baja. El inconveniente es que puede afectar a un gran número de servicios a la vez debido a su gran área de impacto.
- Gran número de clústeres pequeños. Puedes crear un gran número de clústeres pequeños para reducir el área de impacto de los clústeres, ya que tus servicios se dividen en muchos clústeres. Este enfoque también funciona bien con clústeres efímeros de corta duración (por ejemplo, clústeres que ejecutan una carga de trabajo por lotes). El inconveniente de este enfoque es que la sobrecarga operativa es mayor, ya que hay más clústeres que actualizar. También puede haber costes adicionales asociados a un mayor número de nodos del plano de control. Puedes compensar los costes y los elevados gastos operativos con la automatización, una programación y una estrategia predecibles, y una coordinación cuidadosa entre los equipos y los servicios afectados.
En este documento no se recomienda un enfoque sobre otro, sino que se ofrecen 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 dos opciones de diseño.
Planificación de la capacidad
Al planificar la capacidad, es importante tener en cuenta la estrategia del ciclo de vida del clúster elegida. En la planificación de la capacidad se deben tener en cuenta los siguientes eventos de mantenimiento y carga de servicio normales:
- Eventos planificados, como las actualizaciones de clústeres
- Eventos imprevistos, como interrupciones de clústeres, por ejemplo, implementaciones o configuraciones incorrectas
Al planificar la capacidad, debes tener en cuenta las interrupciones totales o parciales. Si solo diseñas para eventos de mantenimiento programados, todos los servicios distribuidos deben tener un clúster adicional del necesario para que puedas sacar un clúster de la rotación a la vez para realizar actualizaciones sin que el servicio se vea afectado. Este enfoque también se conoce como N+1 capacity planning (planificación de la capacidad N+1). Si diseña los eventos de mantenimiento planificados y no planificados, todos los servicios distribuidos deben tener dos (o más) clústeres adicionales de los necesarios para ofrecer la capacidad prevista: uno para el evento planificado y otro para el evento no planificado, por si se produce durante la ventana de mantenimiento planificada. Este enfoque también se conoce como N+2.
En las arquitecturas de varios clústeres, se suelen usar los términos drenaje y derrame. Estos términos hacen referencia al proceso de eliminar (o drenar) el tráfico de un clúster y redirigir (o derivar) el tráfico a otros clústeres durante las actualizaciones y los eventos de mantenimiento. Este proceso se lleva a cabo mediante soluciones de red, como Ingress multiclúster u otros métodos de balanceo de carga. El uso cuidadoso de los drenajes y los derrames es fundamental en algunas estrategias de gestión del ciclo de vida de los clústeres. Cuando planifiques la capacidad, debes tener en cuenta el drenaje y el derrame. Por ejemplo, cuando se agota un solo clúster, debes plantearte si los demás clústeres tienen capacidad suficiente para gestionar el tráfico adicional. Otros aspectos que debes tener en cuenta son si hay capacidad suficiente en la zona o región, o si necesitas enviar tráfico a otra región (si usas un solo clúster regional por región). En el siguiente diagrama se muestra cómo se elimina el tráfico (a veces se denomina "drenar un clúster") de un clúster y se envía a otro que ejecuta el mismo servicio distribuido.
Clústeres y servicios distribuidos
El diseño de clústeres basado en servicios determina que la arquitectura de los clústeres (número, tamaño y ubicación) se determina en función de los servicios que se deben ejecutar en los clústeres. Por lo tanto, la colocación de los clústeres depende de dónde se necesiten los servicios distribuidos. Ten en cuenta lo siguiente a la hora de decidir la ubicación de los servicios distribuidos:
- Requisito de ubicación. ¿Desde qué regiones se debe ofrecer el Servicio?
- Criticidad. ¿Cómo de crítica es la disponibilidad de un servicio para la empresa?
- SLO. ¿Cuáles son los objetivos de nivel de servicio del servicio (normalmente, en función de la criticidad)?
- Resiliencia. ¿Qué nivel de resiliencia debe tener el Servicio? ¿Necesita resistir fallos de clúster, de zona o incluso regionales?
Cuando planifiques las actualizaciones de clústeres, debes tener en cuenta el número de servicios que afecta un clúster cuando se vacía y debes prever el derrame de cada uno de estos servicios a otros clústeres adecuados. Los clústeres pueden ser de un solo inquilino o de varios. Los clústeres de un solo arrendatario solo sirven un servicio o un producto representado por un conjunto de servicios. Los clústeres de un solo inquilino no comparten el clúster con otros servicios o productos. Los clústeres multicliente pueden ejecutar muchos servicios y productos que suelen estar particionados en espacios de nombres.
Impacto en los equipos
Un evento de clúster no solo afecta a los servicios, sino que también puede repercutir en los equipos. Por ejemplo, el equipo de DevOps puede tener que redirigir o detener sus flujos de procesamiento de CI/CD durante una actualización del clúster. Del mismo modo, los equipos de asistencia pueden recibir alertas sobre interrupciones programadas. Deben implementarse la automatización y las herramientas necesarias para reducir el impacto en varios equipos. Una actualización de un clúster o de una flota de clústeres debe considerarse rutinaria y sin incidentes cuando se informa a todos los equipos.
Tiempos, programación y coordinación
Kubernetes lanza una nueva versión menor cada trimestre y mantiene las tres últimas versiones. Debes planificar cuidadosamente los tiempos y la programación de las actualizaciones del clúster. Los propietarios, los operadores y los administradores de la plataforma deben ponerse de acuerdo sobre cuándo se llevarán a cabo estas actualizaciones. Cuando planifiques las actualizaciones, ten en cuenta las siguientes preguntas:
- ¿Con qué frecuencia actualizas tu versión? ¿Actualizáis cada trimestre o en otro plazo?
- ¿Cuándo se cambia de edición? ¿Actualizas al principio del trimestre cuando el negocio se ralentiza o durante otros periodos de inactividad empresarial impulsados por tu sector?
- ¿Cuándo no deberías cambiar a un plan superior? ¿Tienes una planificación clara sobre cuándo no debes hacer la actualización? Por ejemplo, evita los eventos de gran escala, como el Black Friday, el Cyber Monday o las conferencias de alto perfil y otros eventos específicos del sector.
Es importante tener una estrategia claramente comunicada a los propietarios del servicio, así como a los equipos de operaciones y asistencia. No debería haber sorpresas y todos deberían saber cuándo y cómo se actualizan los clústeres. Para ello, es necesario coordinarse claramente con todos los equipos implicados. Un solo servicio tiene varios equipos que interactúan con él. Normalmente, estos equipos se pueden agrupar en las siguientes categorías:
- El desarrollador del servicio, que es responsable de crear y codificar la lógica empresarial en un servicio.
- El operador del Servicio, que es responsable de ejecutar el Servicio de forma segura y fiable. Los operadores pueden estar formados por varios equipos, como el administrador de políticas o de seguridad, el administrador de redes y los equipos de asistencia.
Todos los participantes deben estar en contacto durante las actualizaciones del clúster para poder tomar las medidas adecuadas durante este tiempo. Una opción es planificar las actualizaciones de la misma forma que planificas una interrupción. Tienes un responsable de incidentes, una sala de chat y una retrospectiva (aunque no se haya visto afectado ningún usuario). Para obtener más información, consulta Respuesta a incidentes.
Estrategias de ciclo de vida de los clústeres de GKE
En esta sección se describen las principales estrategias de gestión del ciclo de vida de los clústeres que se suelen usar en la arquitectura de varios clústeres de GKE. Es importante tener en cuenta que una estrategia no funcionará en todos los casos y que puedes elegir varias estrategias para diferentes categorías de servicios y necesidades de la empresa.
Actualizaciones continuas
En el siguiente diagrama se muestra la estrategia de actualización gradual.
Con un balanceador de carga, se vacía de todo el tráfico un clúster de GKE y se actualiza. La carga de tráfico drenada se deriva a otro clúster de GKE.
Las actualizaciones continuas son la estrategia más sencilla y rentable de las que se describen en este documento. Empiezas con n clústeres que ejecutan la versión old_ver (o la versión de producción actual). Después, se agotan los clústeres de m en m, donde m es menor que n. A continuación, elimina y vuelve a crear clústeres con la nueva versión o actualiza los clústeres drenados.
La decisión de eliminar o actualizar los clústeres nuevos depende del tamaño de los clústeres y de si consideras que los clústeres son una infraestructura inmutable. La infraestructura inmutable exige que, en lugar de actualizar constantemente un clúster, lo que podría producir resultados no deseados con el tiempo, crees clústeres nuevos y evites cualquier desviación de configuración imprevista.
Si usas GKE, puedes crear un clúster de GKE con un solo comando o una llamada a la API. La nueva estrategia de clúster requiere que tengas toda la configuración del clúster (manifiestos del clúster) almacenada fuera del clúster, normalmente en Git. Después, puedes usar la misma plantilla de configuración en el nuevo clúster. Si se trata de un clúster nuevo, asegúrate de que tus pipelines de CI/CD apunten al clúster correcto. Una vez que el clúster esté configurado correctamente, podrás volver a enviar tráfico al clúster lentamente mientras monitorizas los SLOs de los servicios.
El proceso se repite para todos los clústeres. En función de tu planificación de la capacidad, puedes actualizar varios clústeres a la vez sin infringir los SLOs del servicio.
Si prefieres la sencillez y el coste a la resiliencia, usa la estrategia de actualizaciones continuas. Con esta estrategia, nunca superas la capacidad necesaria de la flota de GKE para todos los servicios distribuidos.
En el siguiente diagrama se comparan la cronología y el requisito de capacidad de servicio durante una actualización de un clúster de GKE en una arquitectura de varios clústeres.
El diagrama anterior muestra que, durante todo el proceso de actualización de GKE, la capacidad para admitir los servicios nunca es inferior a la necesaria. Cuando se retira de la rotación el clúster de GKE que se va a actualizar, los demás clústeres se escalan para admitir la carga.
Actualizaciones azul-verde
En el siguiente diagrama se muestra una estrategia de actualización azul/verde.
En el diagrama anterior, se añade un nuevo clúster de GKE que ejecuta la nueva versión. A continuación, se usa un balanceador de carga para enviar tráfico al nuevo clúster mientras se va retirando lentamente uno de los clústeres antiguos hasta que no se le envíe tráfico. A continuación, se puede eliminar el clúster antiguo que se ha vaciado por completo. Puedes seguir el mismo proceso con el resto de los clústeres.
La estrategia de actualización azul/verde proporciona una mayor resiliencia.
Esta estrategia es similar a las actualizaciones continuas, pero es más costosa. La única diferencia es que, en lugar de agotar los clústeres actuales, primero creas clústeres m con la versión, donde m es menor o igual que n. Añades los nuevos clústeres a las pipelines de CI/CD y, a continuación, vas desviando el tráfico lentamente mientras monitorizas los SLOs de los servicios. Cuando los nuevos clústeres reciban todo el tráfico, elimina los clústeres con la versión anterior.
La estrategia azul/verde para actualizar clústeres es similar a la estrategia azul/verde que se suele usar para los servicios. Crear varios clústeres a la vez aumenta el coste total, pero te permite acelerar el tiempo de actualización de la flota. El coste adicional solo se aplica durante la actualización cuando se usan clústeres adicionales. La ventaja de crear primero clústeres nuevos es que, en caso de error, puedes restaurar la versión anterior. También puedes probar el nuevo clúster antes de enviarle tráfico de producción. Como estos clústeres coexisten con sus versiones antiguas durante un breve periodo, los costes adicionales son mínimos.
Si prefieres la sencillez y la resiliencia al coste, utiliza la estrategia de actualización azul/verde. Primero se añaden clústeres adicionales y se supera la capacidad necesaria de la flota de GKE durante las actualizaciones.
En el diagrama anterior, al añadir un nuevo clúster, la capacidad disponible supera temporalmente la capacidad necesaria mientras se agota otro clúster de la flota y se elimina de ella. Sin embargo, después de quitar uno de los clústeres antiguos (con las baterías agotadas), la capacidad vuelve a ser la necesaria. Este cambio en la capacidad se destaca porque puede haber un aumento del coste con este modelo, en función del número y el tamaño de los clústeres de la flota.
Actualizaciones de clústeres canary
Una actualización de clúster canary es la estrategia más resistente y compleja de las que se describen en este documento. Esta estrategia abstrae por completo la gestión del ciclo de vida del clúster de la gestión del ciclo de vida de los servicios, lo que ofrece el menor riesgo y la mayor resiliencia para tus servicios. En las estrategias de actualización continua y azul/verde anteriores, toda tu flota de GKE se mantiene en una sola versión. En esta estrategia, mantienes dos o tres flotas de clústeres de GKE que ejecutan diferentes versiones. En lugar de actualizar los clústeres, migra los servicios de una flota de clústeres a la otra con el tiempo. Cuando se haya drenado la flota de GKE más antigua (es decir, cuando todos los servicios se hayan migrado a la flota de GKE con la siguiente versión), elimina la flota.
Esta estrategia requiere que mantengas un mínimo de dos flotas de GKE: una para la producción actual y otra para la siguiente versión candidata de producción. También puedes mantener más de dos flotas de GKE. Las flotas adicionales te ofrecen más flexibilidad, pero también aumentan los costes y la sobrecarga operativa. Estas flotas adicionales no son lo mismo que tener clústeres en diferentes entornos, como los de desarrollo, staging y 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 actualizaciones de clústeres canary implica que debes mantener varias versiones de flotas 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 canary, el propietario del servicio siempre puede identificar los problemas de una versión concreta del servicio. En el caso de los clústeres canary, el propietario del servicio también debe tener en cuenta las versiones de la flota de GKE en las que se ejecutan sus servicios. Una sola versión de servicio distribuido puede ejecutarse en varias versiones de flota de GKE. La migración de un servicio puede realizarse de forma gradual para que puedas ver los efectos del servicio en la nueva flota antes de enviar todo el tráfico del servicio a los nuevos clústeres versionados.
En el siguiente diagrama se muestra que la gestión de diferentes flotas de clústeres de GKE puede abstraer por completo el ciclo de vida del clúster del ciclo de vida de los servicios.
En el diagrama anterior se muestra cómo se migra lentamente un servicio distribuido frontend de una flota de clústeres de GKE a la siguiente, que ejecuta la nueva versión, hasta que la flota anterior se agota por completo con el tiempo. Una vez que se haya agotado la flota, se puede eliminar y crear una nueva. Todos los servicios se migran a la siguiente flota, y las flotas antiguas se retiran a medida que se agotan.
Si lo más importante para ti es la resiliencia, utiliza la estrategia de actualización de clúster canary.
Elegir una estrategia de actualización
El siguiente diagrama puede ayudarte a determinar qué estrategia es la más adecuada para ti en función de las necesidades del servicio y de la empresa.
El diagrama anterior es un árbol de decisiones que te ayudará a elegir la estrategia de actualización que más te convenga:
- Si no necesitas tener un control total sobre la versión y la hora exactas de la actualización, puedes elegir la función de actualización automática disponible en GKE.
- Si tu prioridad es el bajo coste, puedes elegir la estrategia de actualización continua.
- Si tu prioridad es equilibrar el coste y la resiliencia, puedes elegir la estrategia azul/verde.
- Si priorizas la resiliencia por encima del coste, puedes elegir la estrategia de actualización de clúster canary.
Usar Ingress de varios clústeres para gestionar el ciclo de vida de los clústeres de GKE
Casi cualquier estrategia depende de la capacidad de drenar y redirigir el tráfico a otros clústeres durante las actualizaciones. Una solución que ofrece esta función de entrada de varios clústeres es Multi Cluster Ingress. Multi Cluster Ingress es un controlador de entrada multi-clúster alojado en Google Cloudpara clústeres de GKE que admite el despliegue de recursos de balanceo de carga compartidos en varios clústeres y regiones. Multi Cluster Ingress es una solución para dirigir el tráfico de clientes a un servicio distribuido que se ejecuta en muchos clústeres de muchas 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 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ías de malla de servicios como Cloud Service Mesh o Istio, que proporcionan funciones similares en servicios distribuidos.
En los entornos de varios clústeres de GKE, puedes usar Multi Cluster Ingress para manipular el tráfico a varios clústeres con las estrategias de gestión del ciclo de vida de los clústeres que hemos comentado anteriormente. Puedes seguir un tutorial para usar Ingress de varios clústeres en las actualizaciones de GKE con la estrategia azul-verde.
Siguientes pasos
- Consulta más información sobre Multi Cluster Ingress.
- Consulta cómo desplegar Ingress de varios clústeres en clústeres.