Cubo sobre cubo, metaclusters, panales, distribución de recursos

Arroz. 1. Ecosistema de Kubernetes en Alibaba Cloud

Desde 2015, Alibaba Cloud Container Service para Kubernetes (ACK) ha sido uno de los servicios en la nube de más rápido crecimiento en Alibaba Cloud. Presta servicios a numerosos clientes y también respalda la infraestructura interna de Alibaba y otros servicios en la nube de la empresa.

Al igual que con servicios de contenedores similares de proveedores de nube de clase mundial, nuestras principales prioridades son la confiabilidad y la disponibilidad. Por lo tanto, se ha creado una plataforma escalable y accesible globalmente para decenas de miles de clústeres de Kubernetes.

En este artículo, compartiremos nuestra experiencia en la gestión de una gran cantidad de clústeres de Kubernetes en la infraestructura de la nube, así como la arquitectura de la plataforma subyacente.

Entrada

Kubernetes se ha convertido en el estándar de facto para una variedad de cargas de trabajo en la nube. Como se muestra en la Fig. 1 anterior, cada vez se ejecutan más aplicaciones de Alibaba Cloud en clústeres de Kubernetes: aplicaciones con estado y sin estado, así como administradores de aplicaciones. La gestión de Kubernetes siempre ha sido un tema de discusión interesante y serio para los ingenieros que construyen y mantienen infraestructura. Cuando se trata de proveedores de nube como Alibaba Cloud, la cuestión del escalamiento pasa a primer plano. ¿Cómo gestionar los clústeres de Kubernetes a esta escala? Ya hemos cubierto las mejores prácticas para administrar enormes clústeres de Kubernetes de 10 000 nodos. Por supuesto, este es un problema de escala interesante. Pero hay otra escala: la cantidad los propios grupos.

Hemos discutido este tema con muchos usuarios de ACK. La mayoría de ellos optan por ejecutar docenas, si no cientos, de clústeres de Kubernetes pequeños o medianos. Hay buenas razones para ello: limitar daños potenciales, separar clústeres para diferentes equipos, crear clústeres virtuales para pruebas. Si ACK pretende servir a una audiencia global con este modelo de uso, debe gestionar de manera confiable y eficiente una gran cantidad de clústeres en más de 20 regiones.

Arroz. 2. Problemas de gestionar una gran cantidad de clústeres de Kubernetes

¿Cuáles son los principales desafíos de la gestión de clusters a esta escala? Como se muestra en la figura, hay cuatro cuestiones que abordar:

• Heterogeneidad

ACK debería admitir varios tipos de clústeres, incluidos los estándar, sin servidor, Edge, Windows y varios otros. Los diferentes clústeres requieren diferentes opciones, componentes y modelos de alojamiento. Algunos clientes necesitan ayuda con la personalización para sus casos específicos.

• Varios tamaños de clúster

Los clústeres varían en tamaño, desde un par de nodos con unos pocos pods hasta decenas de miles de nodos con miles de pods. Los requisitos de recursos también varían mucho. La asignación inadecuada de recursos puede afectar el rendimiento o incluso causar fallas.

• Diferentes versiones

Kubernetes está evolucionando muy rápidamente. Cada pocos meses se lanzan nuevas versiones. Los clientes siempre están dispuestos a probar nuevas funciones. Por eso quieren colocar la carga de prueba en las nuevas versiones de Kubernetes y la carga de producción en las estables. Para cumplir con este requisito, ACK debe entregar continuamente nuevas versiones de Kubernetes a los clientes mientras mantiene versiones estables.

• Cumplimiento de seguridad

Los grupos se distribuyen en diferentes regiones. Como tales, deben cumplir con diversos requisitos de seguridad y normativas oficiales. Por ejemplo, un clúster en Europa debe cumplir con el RGPD, mientras que una nube financiera en China debe tener capas adicionales de protección. Estos requisitos son obligatorios y es inaceptable ignorarlos, ya que esto genera enormes riesgos para los clientes de la plataforma en la nube.

La plataforma ACK está diseñada para resolver la mayoría de los problemas anteriores. Actualmente gestiona de forma fiable y estable más de 10 clústeres de Kubernetes en todo el mundo. Veamos cómo se logró esto, incluso a través de varios principios clave de diseño/arquitectura.

diseño

Cubo sobre cubo y panal

A diferencia de una jerarquía centralizada, la arquitectura basada en células se utiliza normalmente para escalar una plataforma más allá de un único centro de datos o para ampliar el alcance de la recuperación ante desastres.

Cada región de Alibaba Cloud consta de varias zonas (AZ) y normalmente corresponde a un centro de datos específico. En una región grande (por ejemplo, Huangzhou), suele haber miles de clústeres de clientes de Kubernetes que ejecutan ACK.

ACK administra estos clústeres de Kubernetes utilizando el propio Kubernetes, lo que significa que tenemos un metaclúster de Kubernetes ejecutándose para administrar los clústeres de Kubernetes del cliente. Esta arquitectura también se llama “kube-on-kube” (KoK). La arquitectura KoK simplifica la gestión de clústeres de clientes porque la implementación del clúster es simple y determinista. Más importante aún, podemos reutilizar funciones nativas de Kubernetes. Por ejemplo, administrar servidores API mediante implementación y utilizar el operador etcd para administrar múltiples etcd. Esta recursividad siempre produce un placer especial.

Se implementan varios metaclústeres de Kubernetes dentro de una región, según la cantidad de clientes. A estos metaclusters los llamamos células. Para proteger contra la falla de una zona completa, ACK admite implementaciones multiactivas en una sola región: el metacluster distribuye los componentes maestros del clúster de clientes de Kubernetes en múltiples zonas y los ejecuta simultáneamente, es decir, en modo multiactivo. Para garantizar la confiabilidad y eficiencia del maestro, ACK optimiza la ubicación de los componentes y garantiza que el servidor API y etcd estén cerca uno del otro.

Este modelo le permite gestionar Kubernetes de manera eficiente, flexible y confiable.

Planificación de recursos de metaclúster

Como ya mencionamos, la cantidad de metaclusters en cada región depende de la cantidad de clientes. Pero, ¿en qué momento agregar un nuevo metacluster? Este es un problema típico de planificación de recursos. Como regla general, se acostumbra crear uno nuevo cuando los metaclusters existentes han agotado todos sus recursos.

Tomemos como ejemplo los recursos de red. En la arquitectura KoK, los componentes de Kubernetes de los clústeres de clientes se implementan como pods en un metaclúster. Usamos terway (Fig. 3) es un complemento de alto rendimiento desarrollado por Alibaba Cloud para la gestión de redes de contenedores. Proporciona un amplio conjunto de políticas de seguridad y le permite conectarse a las nubes privadas virtuales (VPC) de los clientes a través de la interfaz de red elástica (ENI) de Alibaba Cloud. Para distribuir eficazmente los recursos de red entre nodos, pods y servicios en un metaclúster, debemos monitorear cuidadosamente su uso dentro del metaclúster de nubes privadas virtuales. Cuando los recursos de la red llegan a su fin, se crea una nueva celda.

Para determinar la cantidad óptima de clústeres de clientes en cada metaclúster, también tomamos en cuenta nuestros costos, requisitos de densidad, cuota de recursos, requisitos de confiabilidad y estadísticas. La decisión de crear un nuevo metacluster se toma en base a toda esta información. Tenga en cuenta que los clústeres pequeños pueden expandirse mucho en el futuro, por lo que el consumo de recursos aumenta incluso si la cantidad de clústeres permanece sin cambios. Normalmente dejamos suficiente espacio libre para que crezca cada grupo.

Arroz. 3. Arquitectura de red Terway

Escalado de componentes del asistente entre clústeres de clientes

Los componentes del asistente tienen diferentes necesidades de recursos. Dependen de la cantidad de nodos y pods en el clúster, la cantidad de controladores/operadores no estándar que interactúan con APIServer.

En ACK, cada clúster de clientes de Kubernetes difiere en tamaño y requisitos de tiempo de ejecución. No existe una configuración universal para colocar los componentes del asistente. Si establecemos por error un límite de recursos bajo para un cliente grande, su clúster no podrá hacer frente a la carga. Si establece un límite conservadormente alto para todos los clústeres, se desperdiciarán recursos.

Para encontrar un equilibrio sutil entre confiabilidad y costo, ACK utiliza un sistema de tipos. Es decir, definimos tres tipos de clusters: pequeños, medianos y grandes. Cada tipo tiene un perfil de asignación de recursos independiente. El tipo se determina en función de la carga de componentes del asistente, la cantidad de nodos y otros factores. El tipo de clúster puede cambiar con el tiempo. ACK monitorea continuamente estos factores y puede escribir hacia arriba o hacia abajo en consecuencia. Una vez que se cambia el tipo de clúster, la asignación de recursos se actualiza automáticamente con una mínima intervención del usuario.

Estamos trabajando para mejorar este sistema con un escalado más detallado y una actualización de tipos más precisa para que estos cambios se realicen sin problemas y tengan más sentido económico.

Arroz. 4. Conmutación inteligente de tipo multietapa

Evolución de los clusters de clientes a escala

Las secciones anteriores cubrieron algunos aspectos de la gestión de una gran cantidad de clústeres de Kubernetes. Sin embargo, hay otro problema que hay que resolver: la evolución de los clusters.

Kubernetes es el "Linux" del mundo de la nube. Se actualiza continuamente y se vuelve más modular. Debemos entregar constantemente nuevas versiones a nuestros clientes, corregir vulnerabilidades y actualizar los clústeres existentes, así como administrar una gran cantidad de componentes relacionados (CSI, CNI, Device Plugin, Scheduler Plugin y muchos otros).

Tomemos como ejemplo la gestión de componentes de Kubernetes. Para empezar, desarrollamos un sistema centralizado para registrar y gestionar todos estos componentes conectados.

Arroz. 5. Componentes flexibles y enchufables

Antes de continuar, debe asegurarse de que la actualización se haya realizado correctamente. Para ello, hemos desarrollado un sistema para comprobar la funcionalidad de los componentes. La verificación se realiza antes y después de la actualización.

Arroz. 6. Comprobación preliminar de los componentes del clúster.

Para actualizar estos componentes de manera rápida y confiable, un sistema de implementación continua funciona con soporte para avance parcial (escala de grises), pausas y otras funciones. Los controladores estándar de Kubernetes no son adecuados para este caso de uso. Por lo tanto, para gestionar los componentes del clúster, hemos desarrollado un conjunto de controladores especializados, que incluyen un complemento y un módulo de control auxiliar (gestión de sidecar).

Por ejemplo, el controlador BroadcastJob está diseñado para actualizar componentes en cada máquina de trabajo o verificar nodos en cada máquina. El trabajo de transmisión ejecuta un pod en cada nodo del clúster, como un DaemonSet. Sin embargo, DaemonSet siempre mantiene el pod funcionando durante mucho tiempo, mientras que BroadcastJob lo colapsa. El controlador de transmisión también lanza pods en nodos recién unidos e inicializa los nodos con los componentes necesarios. En junio de 2019 abrimos el código fuente del motor de automatización OpenKruise, que nosotros mismos utilizamos dentro de la empresa.

Arroz. 7. OpenKurise organiza la ejecución de la tarea de transmisión en todos los nodos.

Para ayudar a los clientes a seleccionar las configuraciones de clúster adecuadas, también proporcionamos un conjunto de perfiles predefinidos, incluidos perfiles Serverless, Edge, Windows y Bare Metal. A medida que el panorama se expanda y las necesidades de nuestros clientes crezcan, agregaremos más perfiles para simplificar el tedioso proceso de configuración.

Arroz. 8. Perfiles de clúster avanzados y flexibles para diversos escenarios

Observabilidad global en los centros de datos

Como se muestra en la siguiente figura. 9, el servicio en la nube Alibaba Cloud Container se ha implementado en veinte regiones de todo el mundo. Dada esta escala, uno de los objetivos clave de ACK es monitorear fácilmente el estado de los clústeres en ejecución para que, si un clúster de cliente encuentra un problema, podamos responder rápidamente a la situación. En otras palabras, debe encontrar una solución que le permita recopilar estadísticas de manera eficiente y segura en tiempo real de grupos de clientes en todas las regiones y presentar visualmente los resultados.

Arroz. 9. Despliegue global del servicio Alibaba Cloud Container en veinte regiones

Como muchos sistemas de monitoreo de Kubernetes, utilizamos Prometheus como nuestra herramienta principal. Para cada metacluster, los agentes de Prometheus recopilan las siguientes métricas:

• Métricas del sistema operativo, como recursos del host (CPU, memoria, disco, etc.) y ancho de banda de la red.
• Métricas para el metaclúster y el sistema de gestión de clústeres de clientes, como kube-apiserver, kube-controller-manager y kube-scheduler.
• Métricas de kubernetes-state-metrics y cadvisor.
• Métricas de etcd como tiempo de escritura en disco, tamaño de base de datos, rendimiento de conexiones entre nodos, etc.

Las estadísticas globales se recopilan utilizando un modelo típico de agregación multicapa. Los datos de monitoreo de cada metacluster primero se agregan en cada región y luego se envían a un servidor central que muestra el panorama general. Todo funciona a través del mecanismo de la federación. Un servidor Prometheus en cada centro de datos recopila métricas de ese centro de datos, y el servidor Prometheus central es responsable de agregar datos de monitoreo. AlertManager se conecta a Prometheus central y, si es necesario, envía alertas a través de DingTalk, correo electrónico, SMS, etc. Visualización: utilizando Grafana.

En la Figura 10, el sistema de monitoreo se puede dividir en tres niveles:

• nivel límite

La capa más alejada del centro. El servidor perimetral Prometheus se ejecuta en cada metaclúster y recopila métricas de los metaclústeres y de clientes dentro del mismo dominio de red.

• Nivel de cascada

La función de la capa en cascada de Prometheus es recopilar datos de monitoreo de múltiples regiones. Estos servidores operan a nivel de unidades geográficas más grandes como China, Asia, Europa y América. A medida que los clústeres crecen, la región se puede dividir y luego aparecerá un servidor Prometheus a nivel de cascada en cada nueva región grande. Con esta estrategia, puede escalar sin problemas según sea necesario.

• nivel central

El servidor central de Prometheus se conecta a todos los servidores en cascada y realiza la agregación de datos final. Para mayor confiabilidad, se crearon dos instancias centrales de Prometheus en diferentes zonas, conectadas a los mismos servidores en cascada.

Arroz. 10. Arquitectura de monitoreo global multinivel basada en el mecanismo de federación Prometheus

Resumen

Las soluciones en la nube basadas en Kubernetes continúan transformando nuestra industria. El servicio de contenedores Alibaba Cloud proporciona alojamiento seguro, confiable y de alto rendimiento: es uno de los mejores alojamientos en la nube de Kubernetes. El equipo de Alibaba Cloud cree firmemente en los principios del código abierto y la comunidad de código abierto. Definitivamente continuaremos compartiendo nuestro conocimiento en el campo de la operación y gestión de tecnologías en la nube.

Fuente: habr.com