¿Cuál es un buen plano de control para operar un gran número de clústeres de Kubernetes?

Este blog específico describe cómo Volterra ayuda a los usuarios a operar sus aplicações e infraestructura como una flota. Explicaremos cómo nuestro enfoque basado en el plano de control facilita las operaciones de una gran flota de clústeres de aplicaciones y lo compararemos con otros enfoques de plano de gestión de múltiples clústeres como Google Anthos, Azure Arc, Rancher, etc.

A estas alturas, quizás te estés preguntando si simplemente estamos haciendo una estrategia de marketing y llamamos a nuestra gestión de múltiples clústeres "operaciones de flota". Los enfoques de gestión de múltiples clústeres y operaciones de flotas abordan diferentes casos de uso y son fundamentalmente diferentes en sus arquitecturas. Un enfoque de múltiples clústeres está diseñado para abordar los escenarios en los que hay relativamente pocos clústeres y el usuario desea administrar estos clústeres de infraestructura utilizando un modelo operativo consistente. Considerando que el enfoque de flota está diseñado para abordar los escenarios en los que hay una gran escala de clústeres (por ejemplo, clústeres K8 en robots, automotrices, puertas de enlace industriales, decenas de regiones de nube pública, etc.) y el usuario desea implementar la misma aplicação y red/seguridad en estos clústeres de gran escala. Las siguientes dos secciones describen y comparan con mayor detalle el enfoque de operaciones de flotas y de múltiples clústeres.

Enfoque multiclúster

Un enfoque de gestión de múltiples clústeres está diseñado para abordar casos de uso cuando hay relativamente pocos clústeres bajo las operaciones de un solo equipo. Algunos ejemplos de tales escenarios incluyen decenas de grupos en varias zonas de disponibilidad para reducir el radio de explosión. De manera similar, los usuarios podrían optar por tener múltiples clústeres en varias regiones para abordar necesidades regulatorias.

Los dos ejemplos siguientes destacan cómo funcionan las soluciones multiclúster (a un alto nivel):

Configuración

Tomemos un ejemplo de implementación de una aplicação que utiliza un enfoque de múltiples clústeres de Rancher como se muestra en la Figura 1. En un enfoque de múltiples clústeres, el cliente selecciona los sitios de destino para la implementación de la aplicação uno por uno. Este enfoque de seleccionar sitios de destino uno por uno funciona cuando tienes unos pocos clústeres. Sin embargo, este enfoque no está diseñado para, digamos, mil clústeres.

observabilidad

La figura 2 muestra cómo funciona la observabilidad en un enfoque multiclúster utilizando Rancher como ejemplo. En un enfoque de múltiples clústeres, el cliente debe hacer doble clic en cada clúster uno por uno para ver el estado de los pods implementados y la utilización de recursos de CPU y memoria. Este enfoque de observar los sitios objetivo uno por uno es adecuado para una pequeña cantidad de clústeres, pero no para gestionar una gran cantidad de clústeres.

Grupo 1:

Grupo 2:

Un enfoque obvio para resolver el problema descrito en el primer ejemplo sería escribir alguna forma de automatización que repitiera tareas para cada uno de los clústeres. Por ejemplo, cada vez que se agrega un nuevo clúster, el script podría realizar la siguiente operación para implementar una nueva aplicação (checkoutservice, por ejemplo)

exportar KUBECONFIG=~/Documentos/kubeconfig/ce01-ashburn-aws-staging

kubectl apply -f checkoutservice.yaml

Sin embargo, será necesario crear automatización para cada operación (implementación, actualización, política, reserva de recursos, etc.). Esta automatización no solo tendrá que realizar la operación individual en muchos clústeres, sino que también tendrá que encargarse de manejar las condiciones de falla. Además, cuando hay escenarios complejos (por ejemplo, pruebas beta en un subconjunto de clústeres, actualizaciones continuas en todos los clústeres), la automatización se volverá cada vez más compleja. Nos dimos cuenta de esto temprano en el proceso y construimos un plano de control distribuido que ofrece toda esta funcionalidad, utilizando un enfoque de operaciones de flota que se describe a continuación.

Enfoque de operaciones de flota de Volterra

Operaciones de flota significa que el cliente define de manera declarativa su intención una vez para la flota y el sistema asume la responsabilidad de garantizar que los sitios afectados estén alineados con la intención definida. Los ejemplos de intención incluyen la versión del software de aplicação , la versión del software de infraestructura (por ejemplo, la versión del sistema operativo), la política de red, la política de seguridad y la reserva de recursos.

Una vez que la intención surte efecto, el sistema permite a los usuarios ver el estado y la salud de la flota. Lo que esto significa es que los usuarios obtienen una vista agregada del estado de la infraestructura y las aplicações en todos los sitios de la flota en un solo panel, lo que reduce la complejidad operativa para el equipo de operaciones del cliente. Los usuarios no tienen que hacer clic en cada sitio o grupo uno por uno para determinar el estado y escribir herramientas de automatización para agregar la información.

El enfoque de operaciones de flota de Volterra consta de tres componentes principales: segmentación, configuración y observabilidad, que analizaremos en las siguientes secciones.

Segmentación de flotas

Los usuarios suelen tener una combinación de sitios en la flota, como sitios de desarrollo, prueba y producción. Es necesario implementar diferentes cargas de trabajo en un segmento específico de sitios debido a políticas de la organización, como que las cargas de trabajo de desarrollo solo se realizan en sitios de desarrollo. Permitimos a los usuarios etiquetar sitios de forma flexible con una etiqueta que se compone de dos partes: clave y valor. Los ejemplos incluyen: 

• Etiqueta-Clave=región. Valor de etiqueta = EE. UU.-Oeste, JP-Norte, JP-Sur
   
• año-modelo=(2015, 2016, 2017, 2018)
   
• función=(pulverizar, soldar)

Una vez etiquetados los sitios, los usuarios pueden definir un “sitio virtual” utilizando condiciones clave-valor de etiqueta. En un escenario de múltiples nubes, los usuarios pueden etiquetar sus sitios como desarrollo, preproducción o producción, por ejemplo. La siguiente Figura 3 muestra un ejemplo de un caso de uso de robótica que utiliza los valores de clave de etiqueta descritos anteriormente.

Aquí hay un fragmento de configuración en Volterra donde el usuario puede usar la sintaxis blend/go-sdk para crear un sitio virtual. En este ejemplo particular, los sitios individuales se etiquetaron con la clave de etiqueta = ves.io/country y el valor de etiqueta de ves-io-jpn

Los usuarios están acostumbrados a un modelo operativo que define segmentos de su flota a priori y luego etiqueta sus sitios en el momento del aprovisionamiento para incluirlos en la flota; los sitios virtuales se integran perfectamente con el modelo operativo existente de los usuarios. Cuando se proporciona un nuevo sitio con la etiqueta adecuada, se incluye automáticamente en el sitio virtual definido anteriormente sin necesidad de pasos manuales adicionales. Además, Volterra descubre información proporcionada previamente, como el fabricante del hardware o el tipo de nube pública, para completar previamente las etiquetas del sistema. Los usuarios pueden optar opcionalmente por utilizar estas etiquetas descubiertas automáticamente para definir sus sitios virtuales.

Configuración de la flota

Las capacidades de configuración de la flota se pueden describir mejor a través de los siguientes tres ejemplos: 

• Configuración de una política de red/seguridad : tomemos el ejemplo de un cliente que implementa un nuevo servicio que requiere que cada clúster tenga la capacidad de comunicarse con una URL específica, por ejemplo, github.com . Normalmente los usuarios emplean listas blancas, lo que significa que a los clústeres solo se les permite llegar a destinos específicos. Por lo tanto, implementar este nuevo servicio requeriría que los usuarios vayan a cada clúster y modifiquen la política de red para agregar github.com a la lista blanca. Además, al cliente le gustaría probar esto en algunos sitios de prueba antes de implementarlo en todos los sitios. Para lograr esta intención en Volterra, el cliente comienza definiendo un sitio virtual de “prueba” en la consola SaaS de Volterra que selecciona un segmento de la flota. Luego, el usuario define una política de red, como la lista blanca de URL ( github.com en este ejemplo), y la aplica al sitio virtual de “prueba”. El plano de control distribuido de Volterra envía la política de red al plano de control local en cada sitio seleccionado por el sitio virtual (como se define anteriormente). El plano de control local de cada sitio aplica la política de red y recopila estadísticas de las reglas alcanzadas por cada sitio. Una vez que el cliente está satisfecho de que el servicio funciona como se esperaba, puede aplicar la política de red al sitio virtual “prod”, que selecciona los sitios restantes de la flota. Aquí hay un fragmento de configuración que utiliza Json y utiliza la interfaz de usuario en el sistema de Volterra.

• Actualización del software de infraestructura : la capacidad de configuración de la flota permite al usuario actualizar el software de infraestructura, por ejemplo, la versión del sistema operativo en toda la flota (o segmento de la flota). En primer lugar, el usuario define la intención de actualizar el sistema operativo de la versión 1 a la versión 2. A continuación, el usuario define una estrategia de implementación en toda la flota, como una actualización continua, azul/verde, entre otras. Una actualización continua significa que el sistema operativo de cada sitio de la flota (o segmento de la flota) se actualiza secuencialmente. Una estrategia de implementación azul/verde significa que el usuario desea probar la actualización en un conjunto de sitios “azules” (por ejemplo, sitios de desarrollo) y comparar el estado con el de los sitios “verdes” (por ejemplo, sitios de producción) que no están actualizados. En cualquier caso, el plano de control distribuido de Volterra envía el software de la versión 2 al plano de control local en cada sitio seleccionado por el sitio virtual y según lo definido en la estrategia de implementación. El plano de control local en cada sitio actualiza el sistema operativo de manera A/B, es decir, crea una nueva partición, implementa la versión 2 en la nueva partición y permite al cliente medir la salud. Si la instalación de la versión 2 no es exitosa, el sistema vuelve automáticamente a la versión 1 en la partición original. A continuación se muestran algunas capturas de pantalla de cómo el usuario puede realizar una actualización del software de infraestructura utilizando el portal Volterra SaaS. El usuario puede ver la versión actual del software de infraestructura y la última versión del software disponible para todos los sitios como se muestra en la siguiente figura. El usuario puede actualizar fácilmente los sitios específicos o todos los sitios según lo dicte el modelo operativo.

• Implementación de aplicações en toda la flota: Volterra proporciona un objeto llamado Virtual Kubernetes (vK8s) que permite a los usuarios administrar aplicações en toda su flota mediante las API de Kubernetes. El usuario implementa sus aplicações utilizando métodos estándar de Kubernetes (es decir, el archivo Kubeconfig y las API de Kubernetes) con el archivo de manifiesto de implementación e indica el segmento de sitios (o flota completa) donde se debe implementar la aplicação . Luego, Virtual Kubernetes (vK8s) de Volterra asume la responsabilidad de implementar la aplicação en cada sitio (o segmento de) la flota. Si hay alguna falla durante la implementación de la aplicação , como fallas de conectividad o de infraestructura, Volterra Virtual Kubernetes continúa intentando la implementación siguiendo el paradigma de Kubernetes de un modelo eventualmente consistente. La siguiente captura de pantalla muestra un ejemplo del usuario que implementa una aplicação llamada “kuard” (ver Kubernetes-up-and-running-demo-app ) en un sitio virtual llamado “jpn-all-sites” que selecciona 140 sitios de la flota. Para agregar una nueva implementación, el usuario simplemente tiene que agregar una nueva implementación haciendo clic en “Agregar implementación” y especificando la ubicación de la implementación en términos del sitio virtual.

Si se agrega un nuevo sitio a la flota con la etiqueta adecuada, el nuevo sitio se agrega automáticamente al sitio virtual (jpn-all-sites en este ejemplo) y la configuración de la flota (es decir, la implementación de Kuard en este ejemplo) se aplica automáticamente al sitio recientemente agregado, lo que reduce la carga de los equipos de operación y elimina los errores humanos.

Observabilidad de la flota

Los sitios virtuales y Kubernetes virtuales (vK8) no solo se utilizan para la configuración, sino que también se utilizan para agregar el estado de los sitios distribuidos en la flota. Esta es una herramienta realmente poderosa en comparación con otras soluciones donde los usuarios tendrían que escribir herramientas para obtener el estado de cada sitio uno por uno y agregar la información. El sistema agrega automáticamente el estado de salud de todos los sitios, en un solo panel, lo que reduce la complejidad operativa para el equipo de operaciones del cliente. El estado de salud recopilado incluye muchos aspectos, como el estado de implementación de la aplicação , el estado del sitio y el estado de la aplicação , etc.

Los usuarios pueden obtener una descripción general rápida del estado de todos sus sitios en un mapa, como se muestra en la siguiente captura de pantalla. El color indica si la puntuación de salud es mayor a 75 (verde), entre 40 y 75 (naranja) y rojo si es menor a 40. La puntuación de salud es una puntuación agregada que comprende conectividad, confiabilidad, seguridad y rendimiento (es decir, consumo de recursos).

Los usuarios también pueden ver una vista agregada de la conectividad en todos sus sitios junto con el estado del sitio. El estado de la conectividad de cada enlace que conecta los sitios a la red troncal de Volterra también se muestra como se visualiza en la Figura 10. El usuario puede hacer clic en enlaces de bajo rendimiento según su estado para revelar estadísticas detalladas sobre solicitudes y errores y solucionar cualquier problema de conectividad como se muestra en la Figura 11.

A continuación, el usuario puede ver información agregada de todos los sitios a través de la distribución de la carga de CPU y memoria en los sitios. Esta información es útil para los administradores de TI o del sitio para identificar qué sitios están siendo utilizados intensivamente y corren el riesgo de quedarse sin recursos. Los administradores del sitio pueden configurar alertas para recibir notificaciones cuando el consumo de recursos exceda los umbrales. En esta captura de pantalla, los usuarios pueden ver que la mitad de los sitios consumen más del 75% de la memoria disponible. No tienen que hacer clic en sitios individuales ni escribir herramientas adicionales para obtener esta información.

Las capacidades de verificación continua en el objeto de la flota proporcionan el estado de las implementaciones de POD: cuántos POD se implementaron, están en progreso o han fallado. Una vez implementados, los usuarios también pueden ver el estado de salud de los Pods: si están en ejecución, esperando una imagen, sin memoria, etc.

Además, los usuarios pueden ver una vista agregada de la eficacia de la política de seguridad y obtener visitas a todos sus sitios como se ve en la siguiente captura de pantalla.

resumen

Para obtener más información sobre cómo se utilizó el enfoque de operaciones de flota de Volterra para administrar una flota de 3000 clústeres, mire la presentación de Volterra en una conferencia de Kubernetes y lea este blog de Jakub Pavlik.

En el próximo blog, titulado “Tiempo para entrar en vigor”, explicaré cómo el plano de control distribuido y la red troncal de Volterra ayudan a propagar y garantizar la coherencia de la configuración en sitios distribuidos globalmente en muy poco tiempo. ¡Manténganse al tanto!