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

Arroz. 1. Ecosistema Kubernetes en Alibaba Cloud

Desde 2015, Alibaba Cloud Container Service for Kubernetes (ACK) foi un dos servizos na nube de máis rápido crecemento en Alibaba Cloud. Atende a numerosos clientes e tamén admite a infraestrutura interna de Alibaba e outros servizos na nube da empresa.

Do mesmo xeito que con servizos de contedores similares de provedores de nube de clase mundial, as nosas principais prioridades son a fiabilidade e a dispoñibilidade. Polo tanto, creouse unha plataforma escalable e accesible a nivel mundial para decenas de miles de clústeres de Kubernetes.

Neste artigo, compartiremos a nosa experiencia na xestión dunha gran cantidade de clústeres de Kubernetes en infraestruturas de nube, así como a arquitectura da plataforma subxacente.

Entrada

Kubernetes converteuse no estándar de facto para unha variedade de cargas de traballo na nube. Como se mostra na Fig. 1 anterior, cada vez máis aplicacións Alibaba Cloud están a executarse en clústeres de Kubernetes: aplicacións con estado e sen estado, así como xestores de aplicacións. A xestión de Kubernetes sempre foi un tema de discusión interesante e serio para os enxeñeiros que constrúen e manteñen infraestruturas. Cando se trata de provedores de nube como Alibaba Cloud, o problema da escala pasa a primer plano. Como xestionar os clústeres de Kubernetes a esta escala? Xa cubrimos as mellores prácticas para xestionar enormes clústeres de Kubernetes de 10 nodos. Por suposto, este é un problema de escalado interesante. Pero hai outra escala: a cantidade os propios clusters.

Discutimos este tema con moitos usuarios de ACK. A maioría deles optan por executar decenas, se non centos, de clústeres de Kubernetes pequenos ou medianos. Hai boas razóns para iso: limitar os danos potenciais, separar clusters para diferentes equipos, crear clusters virtuais para probar. Se ACK pretende servir a unha audiencia global con este modelo de uso, debe xestionar de forma fiable e eficiente un gran número de clústeres en máis de 20 rexións.

Arroz. 2. Problemas de xestión dun gran número de clústeres de Kubernetes

Cales son os principais retos da xestión de clusters a esta escala? Como se mostra na figura, hai catro cuestións que tratar:

• Heteroxeneidade

ACK debería admitir varios tipos de clústeres, incluíndo estándar, sen servidor, Edge, Windows e varios outros. Os diferentes clústeres requiren diferentes opcións, compoñentes e modelos de hospedaxe. Algúns clientes necesitan axuda coa personalización dos seus casos específicos.

• Varios tamaños de racimos

Os clústeres varían en tamaño: desde un par de nodos con varias vainas ata decenas de miles de nodos con miles de vainas. Os requisitos de recursos tamén varían moito. A asignación inadecuada de recursos pode afectar o rendemento ou incluso provocar fallos.

• Diferentes versións

Kubernetes está evolucionando moi rapidamente. Cada poucos meses lánzanse novas versións. Os clientes sempre están dispostos a probar novas funcións. Por iso queren colocar a carga de proba nas novas versións de Kubernetes e a carga de produción nas estables. Para cumprir este requisito, ACK debe entregar continuamente novas versións de Kubernetes aos clientes mentres mantén versións estables.

• Cumprimento de seguridade

Os clústeres distribúense en diferentes rexións. Polo tanto, deben cumprir varios requisitos de seguridade e normativas oficiais. Por exemplo, un clúster en Europa debe cumprir o GDPR, mentres que unha nube financeira en China debe ter capas adicionais de protección. Estes requisitos son obrigatorios e é inaceptable ignoralos, xa que isto xera riscos enormes para os clientes da plataforma na nube.

A plataforma ACK está deseñada para resolver a maioría dos problemas anteriores. Actualmente xestiona de forma fiable e estable máis de 10 mil clústeres de Kubernetes en todo o mundo. Vexamos como se logrou isto, incluso a través de varios principios clave de deseño/arquitectura.

Proxecto

Cubo sobre cubo e panal de mel

A diferenza dunha xerarquía centralizada, a arquitectura baseada en células adoita utilizarse para escalar unha plataforma máis aló dun único centro de datos ou para ampliar o alcance da recuperación ante desastres.

Cada rexión da nube Alibaba consta de varias zonas (AZ) e normalmente corresponde a un centro de datos específico. Nunha rexión grande (por exemplo, Huangzhou), moitas veces hai miles de clústeres de clientes de Kubernetes que executan ACK.

ACK xestiona estes clústeres de Kubernetes mediante o propio Kubernetes, o que significa que temos un metaclúster de Kubernetes en execución para xestionar os clústeres de Kubernetes do cliente. Esta arquitectura tamén se chama "kube-on-kube" (KoK). A arquitectura KoK simplifica a xestión dos clústeres de clientes porque a implantación do clúster é sinxela e determinista. Máis importante aínda, podemos reutilizar as funcións nativas de Kubernetes. Por exemplo, xestionar servidores de API mediante a implantación, utilizando o operador etcd para xestionar varios etcd. Tal recursividade sempre trae un pracer especial.

Varios metaclústeres de Kubernetes están implantados nunha rexión, dependendo do número de clientes. Chamamos células a estes metacúmulos. Para protexerse contra o fallo dunha zona enteira, ACK admite despregamentos multiactivos nunha única rexión: o metaclúster distribúe os compoñentes mestres do clúster de clientes de Kubernetes en varias zonas e execútaos simultaneamente, é dicir, en modo multiactivo. Para garantir a fiabilidade e a eficiencia do mestre, ACK optimiza a colocación dos compoñentes e garante que o servidor API e etcd estean preto uns dos outros.

Este modelo permítelle xestionar Kubernetes de forma eficiente, flexible e fiable.

Planificación de recursos de metacluster

Como xa mencionamos, o número de metaclústeres en cada rexión depende do número de clientes. Pero en que momento engadir un novo metaclúster? Este é un problema típico de planificación de recursos. Como regra xeral, é habitual crear un novo cando os metaclústeres existentes esgotan todos os seus recursos.

Tomemos os recursos da rede, por exemplo. Na arquitectura KoK, os compoñentes de Kubernetes dos clústeres de clientes despréganse como pods nun metaclúster. Usamos Terway (Fig. 3) é un complemento de alto rendemento desenvolvido por Alibaba Cloud para a xestión de redes de contedores. Ofrece un rico conxunto de políticas de seguridade e permítelle conectarse ás nubes privadas virtuais (VPC) dos clientes a través da Interfaz de rede elástica de Alibaba Cloud (ENI). Para distribuír eficazmente os recursos de rede entre nodos, pods e servizos nun metaclúster, debemos supervisar coidadosamente o seu uso dentro do metaclúster de nubes privadas virtuais. Cando os recursos da rede chegan ao fin, créase unha nova cela.

Para determinar o número óptimo de clústeres de clientes en cada metaclúster, tamén temos en conta os nosos custos, requisitos de densidade, cota de recursos, requisitos de fiabilidade e estatísticas. A decisión de crear un novo metaclúster tómase en función de toda esta información. Teña en conta que os clústeres pequenos poden expandirse moito no futuro, polo que o consumo de recursos aumenta aínda que o número de clústeres non cambie. Normalmente deixamos espazo libre suficiente para que cada clúster medre.

Arroz. 3. Arquitectura de rede Terway

Escalar os compoñentes do asistente en clústeres de clientes

Os compoñentes do asistente teñen diferentes necesidades de recursos. Dependen do número de nodos e pods do clúster, do número de controladores/operadores non estándar que interactúan con APIServer.

En ACK, cada clúster de clientes de Kubernetes difire en tamaño e requisitos de tempo de execución. Non hai unha configuración universal para colocar compoñentes do asistente. Se por erro establecemos un límite de recursos baixo para un cliente grande, entón o seu clúster non poderá facer fronte á carga. Se estableces un límite alto conservador para todos os clústeres, desperdiciaranse recursos.

Para atopar unha sutil compensación entre fiabilidade e custo, ACK usa un sistema de tipos. É dicir, definimos tres tipos de clusters: pequenos, medianos e grandes. Cada tipo ten un perfil de asignación de recursos separado. O tipo determínase en función da carga dos compoñentes do asistente, o número de nós e outros factores. O tipo de clúster pode cambiar co paso do tempo. ACK supervisa continuamente estes factores e pode escribir arriba/abajo en consecuencia. Unha vez que se cambia o tipo de clúster, a asignación de recursos actualízase automaticamente cunha intervención mínima do usuario.

Estamos traballando para mellorar este sistema cun escalado máis fino e unha actualización de tipos máis precisa para que estes cambios se produzan con máis fluidez e teñan máis sentido económico.

Arroz. 4. Conmutación intelixente de varias etapas

Evolución dos clústeres de clientes a escala

As seccións anteriores cubriron algúns aspectos da xestión de grandes cantidades de clústeres de Kubernetes. Porén, hai outro problema que hai que solucionar: a evolución dos clusters.

Kubernetes é o "Linux" do mundo da nube. Actualízase continuamente e faise máis modular. Debemos entregar constantemente novas versións aos nosos clientes, corrixir vulnerabilidades e actualizar os clústeres existentes, así como xestionar un gran número de compoñentes relacionados (CSI, CNI, Device Plugin, Scheduler Plugin e moitos outros).

Tomemos como exemplo a xestión de compoñentes de Kubernetes. Para comezar, desenvolvemos un sistema centralizado para rexistrar e xestionar todos estes compoñentes conectados.

Arroz. 5. Compoñentes flexibles e enchufables

Antes de seguir adiante, cómpre asegurarse de que a actualización foi exitosa. Para iso, desenvolvemos un sistema para comprobar a funcionalidade dos compoñentes. A comprobación realízase antes e despois da actualización.

Arroz. 6. Comprobación previa dos compoñentes do cluster

Para actualizar estes compoñentes de forma rápida e fiable, un sistema de implantación continua funciona con soporte para avances parciales (escala de grises), pausas e outras funcións. Os controladores estándar de Kubernetes non son moi adecuados para este caso de uso. Polo tanto, para xestionar os compoñentes do clúster, desenvolvemos un conxunto de controladores especializados, que inclúe un complemento e un módulo de control auxiliar (xestión de sidecar).

Por exemplo, o controlador BroadcastJob está deseñado para actualizar os compoñentes en cada máquina traballadora ou comprobar os nós en cada máquina. O traballo Broadcast executa un pod en cada nodo do clúster, como un DaemonSet. Non obstante, DaemonSet sempre mantén o pod funcionando durante moito tempo, mentres que BroadcastJob o contrae. O controlador Broadcast tamén lanza pods en nós recén unidos e inicializa os nodos cos compoñentes necesarios. En xuño de 2019, abrimos o código fonte do motor de automatización OpenKruise, que nós mesmos usamos na empresa.

Arroz. 7. OpenKurise organiza a execución da tarefa Broadcast en todos os nodos

Para axudar aos clientes a seleccionar as configuracións de clúster correctas, tamén ofrecemos un conxunto de perfís predefinidos, incluíndo perfís Serverless, Edge, Windows e Bare Metal. A medida que o panorama se amplía e as necesidades dos nosos clientes medran, engadiremos máis perfís para simplificar o tedioso proceso de configuración.

Arroz. 8. Perfís de cluster avanzados e flexibles para varios escenarios

Observabilidade global en centros de datos

Como se mostra na fig. 9, o servizo na nube Alibaba Cloud Container implantouse en vinte rexións de todo o mundo. Dada esta escala, un dos obxectivos fundamentais de ACK é supervisar facilmente o estado dos clústeres en execución para que, se un clúster de clientes atopa un problema, poidamos responder rapidamente á situación. Noutras palabras, cómpre atopar unha solución que lle permita recoller estatísticas de forma eficiente e segura en tempo real dos clústeres de clientes de todas as rexións e presentar visualmente os resultados.

Arroz. 9. Implantación global do servizo Alibaba Cloud Container en vinte rexións

Como moitos sistemas de monitorización de Kubernetes, usamos Prometheus como a nosa principal ferramenta. Para cada metaclúster, os axentes de Prometheus recollen as seguintes métricas:

• Métricas do SO como os recursos do host (CPU, memoria, disco, etc.) e ancho de banda da rede.
• Métricas para o metaclúster e o sistema de xestión de clústeres de clientes, como kube-apiserver, kube-controller-manager e kube-scheduler.
• Métricas de kubernetes-state-metrics e cadvisor.
• métricas etcd como o tempo de escritura do disco, o tamaño da base de datos, o rendemento das ligazóns entre os nodos, etc.

As estatísticas globais recóllense mediante un modelo típico de agregación multicapa. Os datos de seguimento de cada metaclúster son primeiro agregados en cada rexión e despois envíanse a un servidor central que mostra a imaxe xeral. Todo funciona a través do mecanismo federativo. Un servidor Prometheus de cada centro de datos recolle as métricas dese centro de datos e o servidor central de Prometheus é o responsable de agregar os datos de seguimento. AlertManager conéctase á central Prometheus e envía alertas segundo sexa necesario a través de DingTalk, correo electrónico, SMS, etc. Visualización - Usando Grafana.

Na figura 10, o sistema de seguimento pódese dividir en tres niveis:

• Nivel límite

A capa máis afastada do centro. O servidor Prometheus Edge execútase en cada metaclúster, recollendo métricas de meta clústeres e de clientes dentro do mesmo dominio de rede.

• Nivel cascada

A función da capa de cascada de Prometheus é recoller datos de seguimento de varias rexións. Estes servidores operan a nivel de unidades xeográficas máis grandes como China, Asia, Europa e América. A medida que crecen os clústeres, a rexión pódese dividir e, a continuación, aparecerá un servidor Prometheus a nivel de cascada en cada nova rexión grande. Con esta estratexia, pode escalar sen problemas segundo sexa necesario.

• Nivel central

O servidor central de Prometheus conéctase a todos os servidores en cascada e realiza a agregación final de datos. Por motivos de fiabilidade, levantáronse dúas instancias centrais de Prometheus en zonas diferentes, conectadas aos mesmos servidores en cascada.

Arroz. 10. Arquitectura global de monitorización multinivel baseada no mecanismo de federación Prometheus

Resumo

As solucións na nube baseadas en Kubernetes seguen transformando o noso sector. O servizo de contedores de Alibaba Cloud ofrece hospedaxe seguro, fiable e de alto rendemento: é un dos mellores hospedaxe na nube de Kubernetes. O equipo de Alibaba Cloud cre firmemente nos principios do código aberto e da comunidade de código aberto. Definitivamente seguiremos compartindo o noso coñecemento no campo da operación e xestión de tecnoloxías na nube.

Fonte: www.habr.com