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, por ejemplo, mediante la configuración manual de un balanceador de cargas externo. Hay un instructivo adjunto a este documento que muestra cómo actualizar un entorno de GKE de varios clústeres con Ingress de varios clústeres. Este documento está dirigido a los administradores de Google Cloud responsables de mantener las flotas de clústeres de GKE.
La necesidad de la arquitectura de varios clústeres
En esta sección, se explican varios motivos por los que puedes necesitar una arquitectura de Kubernetes de varios clústeres.
Kubernetes como infraestructura
En este documento, se considera que los clústeres de Kubernetes son componentes de la infraestructura. La infraestructura es desechable. No se debe brindar ningún tratamiento especial a ningún componente de infraestructura, ya que estos existen para cumplir con un propósito. El propósito de Kubernetes es ofrecer automatización y organización a los desarrolladores y operadores para entregar aplicaciones y servicios basados en contenedores a los consumidores. Los consumidores pueden ser equipos internos, otros servicios o clientes externos.
Situaciones comunes de varios clústeres
Además del argumento de Kubernetes como infraestructura, existen múltiples motivos para tener un entorno de varios clústeres, como los siguientes:
- Geográficos. Muchos servicios deben estar en varias regiones. Si un servicio se ubica más cerca del consumidor (en su región), se brinda una mejor experiencia debido a la latencia más baja que si el servicio se entrega desde una sola región. Un clúster de Kubernetes se ejecuta en una sola región. En implementaciones multirregionales, se requieren varios clústeres de Kubernetes en varias regiones. Los entornos de nube híbrida o múltiples nubes también requieren varios clústeres en cada entorno. A menudo, los clústeres de Kubernetes también se ubican junto con 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, por ejemplo, un sistema de administración de bases de datos relacionales (RDBMS).
- Usuarios y entornos. Los clústeres de Kubernetes están diseñados para multiusuarios. Varios equipos pueden compartir un solo clúster para sus respectivos servicios. Kubernetes proporciona recursos estándar, como espacios de nombres, control de acceso basado en la función (RBAC), políticas de red y autenticación, para configurar de forma adecuada los controles de acceso en entornos de multiusuarios. En algunos casos, es posible que ciertos servicios no puedan coexistir en un clúster con otros servicios debido a la política de la empresa, la privacidad, la seguridad o el reglamento de la industria. En esos casos, se requieren varios clústeres para separar determinadas instancias en sus propios clústeres. Los entornos (desarrollo, etapa de pruebas y producción) también se crean como clústeres independientes. El alcance del acceso y los tipos de aplicaciones instaladas en diferentes entornos varían mucho y deben mantenerse como clústeres independientes.
- Composición y función. En ocasiones, se crea un clúster para realizar una función en particular. Por ejemplo, los flujos de trabajo del aprendizaje automático usan Kubeflow o los trabajos de análisis de datos que pueden requerir nodos con GPU o algún otro requisito de hardware para los clústeres de instancias compuestos por Spot VMs para cargas de trabajo de estadísticas por lotes. Es posible que estos requisitos de hardware no se apliquen a otros servicios. Es posible que estos flujos de trabajo no sean fundamentales para administrar el negocio y pueden requerir clústeres efímeros (clústeres de corta duración). Los servicios compartidos, como la observabilidad (registros, métricas y seguimientos) y las herramientas de CI/CD, son más adecuados en su propio clúster de administración de plataforma. Los clústeres independientes específicos de la función suelen usarse en los flujos de trabajo no empresariales.
- Resiliencia. Suelen usarse 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 la cantidad de servicios que se ven perjudicados debido a una falla del clúster, una configuración incorrecta o un clúster que se queda sin conexión debido a las tareas de mantenimiento planificado o no planificado. Si tienes una gran cantidad de clústeres más pequeños, tienes una gran cantidad de áreas de impacto más pequeñas. Si existe un servicio en dos clústeres, estos comparten la carga de forma equitativa. Si un clúster se queda sin conexión, el 50% del tráfico se ve afectado. Si un solo clúster entrega el mismo servicio, cualquier evento en ese clúster provocaría una interrupción del 100% para ese servicio. Por esta razón, a menudo se usan varios clústeres para la recuperación ante desastres.
Este documento se centra en el aspecto de resiliencia de las implementaciones de varios clústeres.
Servicio distribuidos y de varios clústeres
Un servicio distribuido es un servicio de Kubernetes que se implementa 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 queda sin conexión, ocurre lo mismo con el servicio de Kubernetes. Los servicios distribuidos se abstraen de los clústeres individuales de Kubernetes. Si uno o más clústeres de Kubernetes están inactivos, el servicio distribuido podría estar en línea 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 de servicio y espacio de nombres.
Con esta arquitectura, el servicio de frontend no está vinculado a un solo clúster y se representa de forma conceptual en el diagrama como una capa que abarca la capa de infraestructura del clúster de Kubernetes. Si alguno de los clústeres individuales que ejecutan el servicio de frontend deja de funcionar, el frontend permanece en línea.
Hay servicios adicionales que se ejecutan en clústeres individuales: el servicio de accounts y el servicio de ledger. Su tiempo de actividad y la disponibilidad dependen del tiempo de actividad del clúster de Kubernetes en el que residen.
La resiliencia es una de las razones para las implementaciones de varios clústeres. Los servicios distribuidos crean servicios resilientes en una arquitectura de varios clústeres. Los servicios sin estado son candidatos excelentes para los servicios distribuidos en un entorno de varios clústeres. Cuando trabajas con servicios distribuidos, se aplican los siguientes requisitos y consideraciones:
Herramientas de redes de varios clústeres. Puedes enviar tráfico destinado a un servicio distribuido a clústeres que ejecutan ese servicio mediante una tecnología de entrada de varios clústeres, como Ingress de varios clústeres, o mediante tu propio balanceador de cargas externo o solución de proxy. Cualquier opción que uses debe darte control sobre cuándo, dónde y cuánto tráfico se enruta a una instancia particular de un servicio distribuido. En el siguiente diagrama, se muestra un balanceador de cargas que envía tráfico a un
frontendde servicio distribuido que se ejecuta en dos clústeres de GKE.
Observabilidad. Usa herramientas a fin de medir los SLO, disponibilidad y latencia por lo general, de forma colectiva para un servicio distribuido. Esta configuración proporciona una vista global del rendimiento de cada servicio en varios clústeres. Si bien el servicio distribuido no es un recurso bien definido en la mayoría de las soluciones de observabilidad, puedes recopilar y combinar métricas individuales del servicio de Kubernetes. Las soluciones como Cloud Monitoring o las herramientas de código abierto como Grafana proporcionan métricas del servicio de Kubernetes. Las soluciones de la malla de servicios, como Istio y Anthos Service Mesh también proporcionan métricas de servicio sin ninguna instrumentación requerida.
Ubicación del servicio. Los servicios de Kubernetes proporcionan tolerancia a errores a nivel de nodo dentro de un solo clúster de Kubernetes. Esto significa que un servicio de Kubernetes puede resistir a las interrupciones del nodo. Durante las interrupciones de nodos, un nodo del plano de control de Kubernetes reprograma de forma automática los Pods en nodos en buen estado. Un servicio distribuido proporciona tolerancia a errores a nivel de clúster. Esto significa que un servicio distribuido puede resistir las interrupciones de los clústeres. Cuando planificas la capacidad de un servicio distribuido, debes considerar esta ubicación del servicio. No es necesario que un servicio distribuido se ejecute en cada clúster. 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 requerido para el servicio distribuido?
- ¿Qué tipo de tolerancia a errores se requiere para el servicio distribuido: ¿del clúster, zonal o regional? Por ejemplo, ¿necesitas varios clústeres en una sola zona o varios clústeres entre zonas en una sola región o varias regiones?
¿Qué nivel de interrupción debe resistir el servicio distribuido en el peor de los casos? Las siguientes opciones están disponibles en la capa del clúster:
- N+1 (N representa la cantidad de clústeres necesarios para satisfacer las necesidades de capacidad del servicio). Un servicio distribuido puede resistir una sola falla del clúster.
- N+2. Un servicio distribuido puede resistir dos fallas simultáneas. Por ejemplo, una interrupción planificada y una no planificada de un servicio de Kubernetes en dos clústeres al mismo tiempo.
Lanzamientos y reversiones. Los servicios distribuidos, como los servicios de Kubernetes, permiten el lanzamiento y la reversión graduales. A diferencia de los servicios de Kubernetes, los servicios distribuidos permiten que los clústeres sean una unidad adicional de implementación como un medio para el cambio gradual. Los lanzamientos y las reversiones también dependen del requisito del servicio. En algunos casos, es posible que debas actualizar el servicio en todos los clústeres al mismo tiempo, por ejemplo, una corrección de errores. En otros casos, es posible que tengas que lanzar con lentitud (o escalonar) el cambio de a un clúster por vez. Este lanzamiento gradual disminuye el riesgo para el servicio distribuido mediante la introducción gradual de los cambios en el servicio. Sin embargo, esto puede tardar más en función de la cantidad de clústeres. Ninguna estrategia de actualización es mejor. A menudo, se usan varias estrategias de lanzamiento y reversión según los requisitos del servicio distribuido. Lo importante es que los servicios distribuidos deben permitir cambios graduales y controlados en el entorno.
Continuidad empresarial y recuperación ante desastres (BCDR). A menudo, estos términos se usan juntos. “Continuidad empresarial” hace referencia a la continuación de servicios esenciales en caso de que se produzca un evento importante (planificado o no), mientras que “recuperación ante desastres” hace referencia a los pasos que se toman o que son necesarios para regresar las operaciones empresariales a su estado normal después de estos eventos. Existen muchas estrategias para la BCDR que están fuera del alcance de este documento. La BCDR requiere cierto nivel de redundancia en los sistemas y los servicios. La premisa clave de los servicios distribuidos es que se ejecutan en varias ubicaciones (clústeres, zonas y regiones).
A menudo, las estrategias de la BCDR dependen de las estrategias de lanzamiento y reversión mencionadas con anterioridad. Por ejemplo, si los lanzamientos se realizan de forma escalonada o controlada, el efecto de un error o del envío de una configuración errónea se puede detectar de forma anticipada sin que afecte a una gran cantidad de usuarios. A gran escala y combinadas con una frecuencia de cambio rápida (por ejemplo, en las prácticas de CI/CD modernas), es común que no todos los usuarios reciban la misma versión de un servicio distribuido. La planificación y las estrategias de la BCDR en sistemas y servicios distribuidos difieren de las arquitecturas de aplicación monolítica tradicionales. En los sistemas tradicionales, el cambio se hace al por mayor, lo que afecta a una gran cantidad de usuarios (o quizás a todos). Por lo tanto, se necesita un sistema redundante o de copia de seguridad en caso de que se produzcan efectos no deseados de un lanzamiento. En sistemas y servicios distribuidos, casi todos los cambios se realizan de forma gradual para afectar solo a una pequeña cantidad de usuarios.
Administración del ciclo de vida de los clústeres. Al igual que los lanzamientos y las reversiones controladas, los servicios distribuidos permiten la administración controlada del ciclo de vida de los clústeres. Los servicios distribuidos proporcionan resiliencia a nivel de clúster para que estos puedan quitarse de la rotación a fin de realizar tareas de mantenimiento. La administración del ciclo de vida del clúster es un principio de los servicios distribuidos que no se aplican a los servicios de Kubernetes.
El resto de este documento se centra en el ciclo de vida del clúster de los servicios distribuidos.
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.
Este documento se centra en la administración del ciclo de vida de GKE. Sin embargo, puedes aplicar estos conceptos a otras distribuciones de Kubernetes.
Control de versiones y actualizaciones de GKE
Antes de analizar las estrategias y la planificación para la administración del ciclo de vida del clúster, es importante comprender qué constituye una actualización del clúster.
Un clúster contiene dos componentes: los nodos del planos de control y los nodos trabajadores. Una actualización del clúster de Kubernetes requiere que todos los nodos se actualicen a la misma versión. Kubernetes sigue un esquema de control de versiones semántico.
Las versiones de Kubernetes se expresan como X.Y.Z:, en el que X es la versión principal, Y es la versión secundaria y Z es la versión del parche. Las actualizaciones secundarias se producen alrededor de cada tres meses (por trimestre) y el proyecto de Kubernetes mantiene las ramas de versiones para las tres actualizaciones secundarias más recientes. Esto significa que una versión secundaria de Kubernetes de nueve meses ya no se mantiene y es posible que se requieran cambios en la API cuando actualices a la versión más reciente. Las actualizaciones de Kubernetes se deben planificar a una cadencia regular. Te recomendamos realizar actualizaciones de GKE planificadas de forma trimestral o cada dos trimestres.
Los clústeres de GKE admiten la ejecución de las versiones de Kubernetes de cualquier actualización secundaria compatible. Hay al menos dos versiones secundarias disponibles en todo momento.
GKE tiene los siguientes tipos de disponibilidad del clúster:
- Clústeres de zona única. Un solo nodo del plano de control y todos los grupos de nodos se encuentran en una única zona en una región única.
- Clústeres de varias zonas. Un solo nodo del plano de control está en una zona y los grupos de nodos se encuentran en varias zonas en una única región.
- Clústeres regionales. Varios nodos del plano de control y grupos de nodos se encuentran en varias zonas en una única región.
GKE es un servicio administrado y ofrece actualizaciones automáticas para los nodos del plano de control y los nodos trabajadores.
Actualización automática de GKE
La actualización automática de GKE es una estrategia popular del ciclo de vida del clúster que se usa con frecuencia. La actualización automática de GKE proporciona una forma completamente administrada de mantener actualizados tus clústeres de GKE a versiones compatibles. Las actualizaciones automáticas de GKE actualizan los nodos del plano de control y los nodos trabajadores por separado:
Actualizaciones automáticas de la instancia principal. De forma predeterminada, los nodos del plano de control de GKE se actualizan de manera automática. Los clústeres de zona única y de varias zonas tienen un solo plano de control (nodo del plano de control). Durante las actualizaciones del nodo del plano de control, las cargas de trabajo continúan ejecutándose. Sin embargo, no puedes implementar cargas de trabajo nuevas, modificar cargas de trabajo existentes ni realizar 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 una réplica se actualiza a la vez. Durante la actualización, el clúster sigue teniendo alta disponibilidad, y las réplicas del plano de control no están disponibles solo mientras se actualizan.
Actualizaciones automáticas del nodo trabajador. Los grupos de nodos se actualizan de a uno. Dentro de un grupo de nodos, los nodos se actualizan de a uno, en orden aleatorio. Puedes cambiar la cantidad de nodos que se actualizan a la vez, pero este proceso puede tardar varias horas en función de la cantidad de nodos y la configuración de las cargas de trabajo.
Estrategia del ciclo de vida de la actualización automática de GKE
Recomendamos usar la actualización automática de GKE cuando sea posible. Las actualizaciones automáticas de GKE priorizan la conveniencia sobre el control. Sin embargo, las actualizaciones automáticas de GKE ofrecen muchas formas de influir en cuándo y cómo se actualizan los clústeres dentro de ciertos parámetros. Puedes influir en las exclusiones y los períodos de mantenimiento. Los canales de versiones influyen en la selección de versiones y las estrategias de actualización de nodos influyen en el orden y momento en que se actualizan los nodos. A pesar de estos controles y 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 elegir no usar la función de actualización automática de GKE si necesitas una o más de las siguientes opciones:
- Control de la versión exacta de los clústeres de GKE
- Control del momento exacto en que se actualiza GKE
- Control de la estrategia de actualización (que se explica en la siguiente sección) para tu flota de GKE
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.
Usa Ingress de varios clústeres para administrar el ciclo de vida de los clústeres de GKE
Casi todas las estrategias dependen de la capacidad de desviar y redirigir el tráfico a otros clústeres durante las actualizaciones. Ingress de varios clústeres es una solución que proporciona esta función de entrada de varios clústeres. Ingress de varios clústeres es un controlador de entrada de varios clústeres alojado en Google Cloud para 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 for 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 Anthos Service Mesh o Istio, que proporcionan funcionalidades similares entre los servicios distribuidos.
En los entornos de varios clústeres de GKE, puedes usar Ingress de varios clústeres a fin de manipular el tráfico a varios clústeres para usar las estrategias de administración del ciclo de vida de los clústeres que se analizó antes. Puedes seguir un instructivo sobre cómo usar Ingress de varios clústeres para las actualizaciones de GKE mediante la estrategia azul y verde.
¿Qué sigue?
- Obtén más información sobre Ingress de varios clústeres.
- Obtén más información para implementar Ingress de varios clústeres en diferentes clústeres.