Cub sobre cub, metaclusters, bresques, distribució de recursos

Arròs. 1. Ecosistema Kubernetes a Alibaba Cloud

Des del 2015, Alibaba Cloud Container Service per a Kubernetes (ACK) ha estat un dels serveis al núvol de més ràpid creixement a Alibaba Cloud. Serveix a nombrosos clients i també dóna suport a la infraestructura interna d'Alibaba i als altres serveis al núvol de l'empresa.

Igual que amb serveis de contenidors similars de proveïdors de núvol de classe mundial, les nostres principals prioritats són la fiabilitat i la disponibilitat. Per tant, s'ha creat una plataforma escalable i accessible globalment per a desenes de milers de clústers de Kubernetes.

En aquest article, compartirem la nostra experiència de gestió d'un gran nombre de clústers de Kubernetes a la infraestructura del núvol, així com l'arquitectura de la plataforma subjacent.

Entrada

Kubernetes s'ha convertit en l'estàndard de facto per a una varietat de càrregues de treball al núvol. Com es mostra a la Fig. 1 anterior, cada cop més aplicacions d'Alibaba Cloud s'executen als clústers de Kubernetes: aplicacions amb estat i sense estat, així com gestors d'aplicacions. La gestió de Kubernetes sempre ha estat un tema interessant i seriós de discussió per als enginyers que construeixen i mantenen la infraestructura. Quan es tracta de proveïdors de núvol com Alibaba Cloud, el problema de l'escala passa a primer pla. Com gestionar els clústers de Kubernetes a aquesta escala? Ja hem tractat les millors pràctiques per gestionar grans clústers de Kubernetes de 10 nodes. Per descomptat, aquest és un problema d'escala interessant. Però hi ha una altra escala: la quantitat els propis clústers.

Hem parlat d'aquest tema amb molts usuaris d'ACK. La majoria opten per executar desenes, si no centenars, de clústers Kubernetes de mida petita o mitjana. Hi ha bones raons per això: limitar els danys potencials, separar clústers per a diferents equips, crear clústers virtuals per fer proves. Si ACK pretén servir un públic global amb aquest model d'ús, ha de gestionar de manera fiable i eficient un gran nombre de clústers en més de 20 regions.

Arròs. 2. Problemes de gestió d'un gran nombre de clústers Kubernetes

Quins són els principals reptes de la gestió de clústers a aquesta escala? Com es mostra a la figura, hi ha quatre qüestions a tractar:

• Heterogeneïtat

ACK hauria de suportar diversos tipus de clústers, com ara estàndard, sense servidor, Edge, Windows i diversos altres. Els diferents clústers requereixen diferents opcions, components i models d'allotjament. Alguns clients necessiten ajuda amb la personalització dels seus casos específics.

• Clúster de diferents mides

Els clústers varien de mida: des d'un parell de nodes amb diverses beines fins a desenes de milers de nodes amb milers de beines. Els requisits de recursos també varien molt. L'assignació inadequada de recursos pot afectar el rendiment o fins i tot provocar errors.

• Diferents versions

Kubernetes està evolucionant molt ràpidament. Cada pocs mesos es publiquen noves versions. Els clients sempre estan disposats a provar noves funcions. Així que volen col·locar la càrrega de prova a les noves versions de Kubernetes i la càrrega de producció a les estables. Per complir amb aquest requisit, ACK ha de lliurar contínuament noves versions de Kubernetes als clients mentre manté les versions estables.

• Compliment de seguretat

Els clústers es distribueixen en diferents regions. Com a tal, han de complir amb diversos requisits de seguretat i normatives oficials. Per exemple, un clúster a Europa ha de complir amb GDPR, mentre que un núvol financer a la Xina ha de tenir capes de protecció addicionals. Aquests requisits són obligatoris i és inacceptable ignorar-los, ja que això crea grans riscos per als clients de la plataforma núvol.

La plataforma ACK està dissenyada per resoldre la majoria dels problemes anteriors. Actualment gestiona de manera fiable i estable més de 10 mil clústers Kubernetes a tot el món. Vegem com es va aconseguir això, fins i tot mitjançant diversos principis clau de disseny/arquitectura.

Disseny

Cub sobre cub i bresca

A diferència d'una jerarquia centralitzada, l'arquitectura basada en cèl·lules s'utilitza normalment per escalar una plataforma més enllà d'un únic centre de dades o per ampliar l'abast de la recuperació de desastres.

Cada regió del núvol Alibaba consta de diverses zones (AZ) i normalment correspon a un centre de dades específic. En una regió gran (per exemple, Huangzhou), sovint hi ha milers de clústers de clients de Kubernetes que executen ACK.

ACK gestiona aquests clústers de Kubernetes mitjançant el mateix Kubernetes, és a dir, tenim un metaclúster de Kubernetes en execució per gestionar els clústers de Kubernetes del client. Aquesta arquitectura també s'anomena "kube-on-kube" (KoK). L'arquitectura KoK simplifica la gestió dels clústers de clients perquè el desplegament del clúster és senzill i determinista. Més important encara, podem reutilitzar les funcions natives de Kubernetes. Per exemple, la gestió de servidors d'API mitjançant el desplegament, utilitzant l'operador etcd per gestionar diversos etcd. Aquesta recursivitat sempre porta un plaer especial.

Diversos metaclústers de Kubernetes es despleguen dins d'una regió, depenent del nombre de clients. A aquests metacúmuls els anomenem cèl·lules. Per protegir-se de la fallada d'una zona sencera, ACK admet desplegaments multiactius en una sola regió: el metaclúster distribueix els components mestres del clúster de clients de Kubernetes entre diverses zones i els executa simultàniament, és a dir, en mode multiactiu. Per garantir la fiabilitat i l'eficiència del mestre, ACK optimitza la col·locació dels components i assegura que el servidor API i etcd estiguin a prop l'un de l'altre.

Aquest model us permet gestionar Kubernetes de manera eficient, flexible i fiable.

Planificació de recursos del metacluster

Com ja hem comentat, el nombre de metaclusters a cada regió depèn del nombre de clients. Però, en quin moment afegir un nou metaclúster? Aquest és un problema típic de planificació de recursos. Per regla general, és habitual crear-ne un de nou quan els metaclústers existents han esgotat tots els seus recursos.

Prenem, per exemple, els recursos de la xarxa. A l'arquitectura KoK, els components de Kubernetes dels clústers de clients es despleguen com a pods en un metaclúster. Fem servir Terway (Fig. 3) és un connector d'alt rendiment desenvolupat per Alibaba Cloud per a la gestió de xarxes de contenidors. Proporciona un conjunt ric de polítiques de seguretat i us permet connectar-vos als núvols privats virtuals (VPC) dels clients mitjançant la interfície de xarxa elàstica del núvol d'Alibaba (ENI). Per distribuir eficaçment els recursos de xarxa entre nodes, pods i serveis en un metaclúster, hem de supervisar acuradament el seu ús dins del metaclúster de núvols privats virtuals. Quan els recursos de xarxa acaben, es crea una nova cel·la.

Per determinar el nombre òptim de clústers de clients a cada metaclúster, també tenim en compte els nostres costos, requisits de densitat, quota de recursos, requisits de fiabilitat i estadístiques. La decisió de crear un nou metaclúster es pren a partir de tota aquesta informació. Tingueu en compte que els clústers petits poden expandir-se molt en el futur, de manera que el consum de recursos augmenta encara que el nombre de clústers no canviï. Normalment deixem prou espai lliure perquè cada clúster creixi.

Arròs. 3. Arquitectura de xarxa Terway

Escalar els components de l'assistent entre clústers de clients

Els components de l'assistent tenen necessitats de recursos diferents. Depenen del nombre de nodes i pods del clúster, del nombre de controladors/operadors no estàndard que interactuen amb APIServer.

A ACK, cada clúster de clients de Kubernetes difereix en mida i requisits de temps d'execució. No hi ha cap configuració universal per col·locar components de l'assistent. Si establim per error un límit de recursos baix per a un client gran, el seu clúster no podrà fer front a la càrrega. Si establiu un límit alt de manera conservadora per a tots els clústers, els recursos es malbarataran.

Per trobar una compensació subtil entre fiabilitat i cost, ACK utilitza un sistema de tipus. És a dir, definim tres tipus de clústers: petits, mitjans i grans. Cada tipus té un perfil d'assignació de recursos independent. El tipus es determina en funció de la càrrega dels components de l'assistent, el nombre de nodes i altres factors. El tipus de clúster pot canviar amb el temps. ACK supervisa contínuament aquests factors i pot escriure amunt/a baix en conseqüència. Un cop canviat el tipus de clúster, l'assignació de recursos s'actualitza automàticament amb una intervenció mínima de l'usuari.

Estem treballant per millorar aquest sistema amb un escalat més detallat i una actualització de tipus més precisa perquè aquests canvis es produeixin de manera més fluida i tinguin més sentit econòmic.

Arròs. 4. Commutació intel·ligent de tipus multietapa

Evolució dels clústers de clients a escala

Les seccions anteriors van tractar alguns aspectes de la gestió d'un gran nombre de clústers de Kubernetes. Tanmateix, hi ha un altre problema que cal resoldre: l'evolució dels clústers.

Kubernetes és el "Linux" del món del núvol. S'actualitza contínuament i es fa més modular. Hem de lliurar constantment noves versions als nostres clients, solucionar vulnerabilitats i actualitzar clústers existents, així com gestionar un gran nombre de components relacionats (CSI, CNI, Device Plugin, Scheduler Plugin i molts altres).

Prenguem com a exemple la gestió de components de Kubernetes. Per començar, hem desenvolupat un sistema centralitzat per registrar i gestionar tots aquests components connectats.

Arròs. 5. Components flexibles i endollables

Abans de seguir endavant, heu d'assegurar-vos que l'actualització ha tingut èxit. Per fer-ho, hem desenvolupat un sistema de comprovació de la funcionalitat dels components. La comprovació es realitza abans i després de l'actualització.

Arròs. 6. Comprovació prèvia dels components del clúster

Per actualitzar aquests components de manera ràpida i fiable, un sistema de desplegament continu funciona amb suport per a l'avanç parcial (escala de grisos), pauses i altres funcions. Els controladors Kubernetes estàndard no són adequats per a aquest cas d'ús. Per tant, per gestionar els components del clúster, hem desenvolupat un conjunt de controladors especialitzats, que inclou un complement i un mòdul de control auxiliar (gestió de sidecar).

Per exemple, el controlador BroadcastJob està dissenyat per actualitzar components a cada màquina de treball o comprovar els nodes de cada màquina. El treball Broadcast executa un pod a cada node del clúster, com un DaemonSet. Tanmateix, DaemonSet sempre manté el pod en funcionament durant molt de temps, mentre que BroadcastJob el col·lapsa. El controlador Broadcast també llança pods als nodes recentment units i inicialitza els nodes amb els components necessaris. El juny de 2019, vam obrir el codi font del motor d'automatització OpenKruise, que nosaltres mateixos utilitzem a l'empresa.

Arròs. 7. OpenKurise organitza l'execució de la tasca Broadcast a tots els nodes

Per ajudar els clients a seleccionar les configuracions de clúster adequades, també oferim un conjunt de perfils predefinits, inclosos els perfils Serverless, Edge, Windows i Bare Metal. A mesura que el panorama s'ampliï i les necessitats dels nostres clients creixin, afegirem més perfils per simplificar el tediós procés de configuració.

Arròs. 8. Perfils de clúster avançats i flexibles per a diversos escenaris

Observabilitat global als centres de dades

Com es mostra a la fig. 9, el servei al núvol Alibaba Cloud Container s'ha desplegat a vint regions d'arreu del món. Donada aquesta escala, un dels objectius clau d'ACK és controlar fàcilment l'estat dels clústers en execució de manera que si un clúster de client troba un problema, podem respondre ràpidament a la situació. En altres paraules, heu de trobar una solució que us permeti recopilar estadístiques de manera eficient i segura en temps real dels clústers de clients de totes les regions i presentar visualment els resultats.

Arròs. 9. Desplegament global del servei Alibaba Cloud Container a vint regions

Com molts sistemes de monitorització de Kubernetes, utilitzem Prometheus com a eina principal. Per a cada metaclúster, els agents de Prometheus recullen les mètriques següents:

• Mètriques del sistema operatiu com ara recursos de l'amfitrió (CPU, memòria, disc, etc.) i ample de banda de xarxa.
• Mètriques per al sistema de gestió de clúster de metaclúster i client, com ara kube-apiserver, kube-controller-manager i kube-scheduler.
• Mètriques de kubernetes-state-metrics i cadvisor.
• mètriques etcd com ara el temps d'escriptura del disc, la mida de la base de dades, el rendiment dels enllaços entre nodes, etc.

Les estadístiques globals es recullen mitjançant un model típic d'agregació multicapa. Les dades de seguiment de cada metaclúster s'agreguen primer a cada regió i després s'envien a un servidor central que mostra la imatge general. Tot funciona a través del mecanisme federatiu. Un servidor Prometheus de cada centre de dades recopila mètriques d'aquest centre de dades i el servidor central de Prometheus és responsable d'agregar les dades de monitorització. AlertManager es connecta a la central Prometheus i envia alertes segons sigui necessari mitjançant DingTalk, correu electrònic, SMS, etc. Visualització - Ús de Grafana.

A la figura 10, el sistema de monitorització es pot dividir en tres nivells:

• Nivell límit

La capa més allunyada del centre. El servidor Prometheus Edge s'executa a cada metaclúster, recopilant mètriques de meta clústers i de clients dins del mateix domini de xarxa.

• Nivell cascada

La funció de la capa de cascada de Prometheus és recollir dades de seguiment de diverses regions. Aquests servidors operen a nivell d'unitats geogràfiques més grans com la Xina, Àsia, Europa i Amèrica. A mesura que creixen els clústers, la regió es pot dividir i, a continuació, apareixerà un servidor Prometheus a nivell de cascada a cada regió gran nova. Amb aquesta estratègia, podeu escalar sense problemes segons sigui necessari.

• Nivell central

El servidor central de Prometheus es connecta a tots els servidors en cascada i realitza l'agregació de dades final. Per fiabilitat, es van crear dues instàncies centrals de Prometheus en zones diferents, connectades als mateixos servidors en cascada.

Arròs. 10. Arquitectura global de monitorització multinivell basada en el mecanisme de federació Prometheus

Resum

Les solucions al núvol basades en Kubernetes continuen transformant la nostra indústria. El servei de contenidors Alibaba Cloud ofereix un allotjament segur, fiable i d'alt rendiment: és un dels millors allotjament en núvol de Kubernetes. L'equip d'Alibaba Cloud creu fermament en els principis de codi obert i la comunitat de codi obert. Sens dubte, continuarem compartint el nostre coneixement en l'àmbit de l'operació i gestió de tecnologies al núvol.

Font: www.habr.com