Cubo su cubo, metacluster, favi, distribuzione delle risorse

Riso. 1. Ecosistema Kubernetes su Alibaba Cloud

Dal 2015, Alibaba Cloud Container Service for Kubernetes (ACK) è uno dei servizi cloud in più rapida crescita in Alibaba Cloud. Serve numerosi clienti e supporta anche l'infrastruttura interna di Alibaba e gli altri servizi cloud dell'azienda.

Come per servizi container simili di provider cloud di livello mondiale, le nostre priorità principali sono l'affidabilità e la disponibilità. Pertanto è stata creata una piattaforma scalabile e accessibile a livello globale per decine di migliaia di cluster Kubernetes.

In questo articolo condivideremo la nostra esperienza nella gestione di un gran numero di cluster Kubernetes sull'infrastruttura cloud, nonché l'architettura della piattaforma sottostante.

Iscrizione

Kubernetes è diventato lo standard de facto per una varietà di carichi di lavoro nel cloud. Come mostrato nella Fig. 1 sopra, sempre più applicazioni Alibaba Cloud sono ora in esecuzione su cluster Kubernetes: applicazioni stateful e stateless, nonché gestori di applicazioni. La gestione di Kubernetes è sempre stata un argomento di discussione interessante e serio per gli ingegneri che costruiscono e mantengono l'infrastruttura. Quando si tratta di fornitori di servizi cloud come Alibaba Cloud, la questione della scalabilità viene in primo piano. Come gestire i cluster Kubernetes su questa scala? Abbiamo già trattato le best practice per la gestione di enormi cluster Kubernetes da 10 nodi. Naturalmente, questo è un interessante problema di ridimensionamento. Ma c’è un’altra scala: la quantità i cluster stessi.

Abbiamo discusso questo argomento con molti utenti ACK. La maggior parte di loro sceglie di eseguire dozzine, se non centinaia, di cluster Kubernetes di piccole o medie dimensioni. Ci sono buone ragioni per questo: limitare i danni potenziali, separare i cluster per diversi team, creare cluster virtuali per i test. Se ACK mira a servire un pubblico globale con questo modello di utilizzo, deve gestire in modo affidabile ed efficiente un gran numero di cluster in più di 20 regioni.

Riso. 2. Problemi nella gestione di un numero enorme di cluster Kubernetes

Quali sono le principali sfide nella gestione dei cluster su questa scala? Come mostrato nella figura, ci sono quattro questioni da affrontare:

• Eterogeneità

ACK dovrebbe supportare vari tipi di cluster, inclusi standard, serverless, Edge, Windows e molti altri. Cluster diversi richiedono opzioni, componenti e modelli di hosting diversi. Alcuni clienti necessitano di assistenza con la personalizzazione per i loro casi specifici.

• Varie dimensioni di cluster

I cluster variano in dimensioni, da un paio di nodi con pochi pod a decine di migliaia di nodi con migliaia di pod. Anche i requisiti in termini di risorse variano notevolmente. Un'allocazione impropria delle risorse può influire sulle prestazioni o addirittura causare guasti.

• Versioni differenti

Kubernetes si sta evolvendo molto rapidamente. Nuove versioni vengono rilasciate ogni pochi mesi. I clienti sono sempre disposti a provare nuove funzionalità. Quindi vogliono posizionare il carico di test sulle nuove versioni di Kubernetes e il carico di produzione su quelle stabili. Per soddisfare questo requisito, ACK deve fornire continuamente nuove versioni di Kubernetes ai clienti mantenendo le versioni stabili.

• Conformità alla sicurezza

I cluster sono distribuiti in diverse regioni. In quanto tali, devono rispettare vari requisiti di sicurezza e normative ufficiali. Ad esempio, un cluster in Europa deve essere conforme al GDPR, mentre un cloud finanziario in Cina deve avere livelli di protezione aggiuntivi. Questi requisiti sono obbligatori ed è inaccettabile ignorarli, poiché ciò crea enormi rischi per i clienti della piattaforma cloud.

La piattaforma ACK è progettata per risolvere la maggior parte dei problemi di cui sopra. Attualmente gestisce in modo affidabile e stabile più di 10mila cluster Kubernetes in tutto il mondo. Diamo un'occhiata a come ciò è stato ottenuto, anche attraverso diversi principi chiave di progettazione/architettura.

disegno

Cubo su cubo e nido d'ape

A differenza di una gerarchia centralizzata, l'architettura basata su celle viene generalmente utilizzata per scalare una piattaforma oltre un singolo data center o per espandere l'ambito del disaster recovery.

Ogni regione di Alibaba Cloud è composta da diverse zone (AZ) e solitamente corrisponde a un data center specifico. In una vasta regione (ad esempio Huangzhou), ci sono spesso migliaia di cluster client Kubernetes che eseguono ACK.

ACK gestisce questi cluster Kubernetes utilizzando Kubernetes stesso, il che significa che abbiamo un metacluster Kubernetes in esecuzione per gestire i cluster Kubernetes client. Questa architettura è anche chiamata “kube-on-kube” (KoK). L'architettura KoK semplifica la gestione dei cluster client perché la distribuzione dei cluster è semplice e deterministica. Ancora più importante, possiamo riutilizzare le funzionalità native di Kubernetes. Ad esempio, la gestione dei server API tramite la distribuzione, utilizzando l'operatore etcd per gestire più etcd. Tale ricorsione porta sempre un piacere speciale.

All'interno di una regione vengono distribuiti diversi metacluster Kubernetes, a seconda del numero di client. Chiamiamo questi metacluster cellule. Per proteggere dal guasto di un'intera zona, ACK supporta distribuzioni multiattive in una singola regione: il metacluster distribuisce i componenti master del cluster client Kubernetes su più zone e li esegue simultaneamente, ovvero in modalità multiattiva. Per garantire l'affidabilità e l'efficienza del master, ACK ottimizza il posizionamento dei componenti e garantisce che il server API e etcd siano vicini tra loro.

Questo modello consente di gestire Kubernetes in modo efficiente, flessibile e affidabile.

Pianificazione delle risorse del metacluster

Come già accennato, il numero di metacluster in ciascuna regione dipende dal numero di client. Ma a che punto aggiungere un nuovo metacluster? Questo è un tipico problema di pianificazione delle risorse. Di norma, è consuetudine crearne uno nuovo quando i metacluster esistenti hanno esaurito tutte le loro risorse.

Prendiamo ad esempio le risorse di rete. Nell'architettura KoK, i componenti Kubernetes dei cluster client vengono distribuiti come pod in un metacluster. Noi usiamo Terway (Fig. 3) è un plugin ad alte prestazioni sviluppato da Alibaba Cloud per la gestione della rete di contenitori. Fornisce un ricco set di policy di sicurezza e consente di connettersi ai cloud privati ​​virtuali (VPC) dei clienti tramite Alibaba Cloud Elastic Networking Interface (ENI). Per distribuire in modo efficace le risorse di rete tra nodi, pod e servizi in un metacluster, dobbiamo monitorare attentamente il loro utilizzo all'interno del metacluster di cloud privati ​​virtuali. Quando le risorse di rete giungono al termine, viene creata una nuova cella.

Per determinare il numero ottimale di cluster client in ciascun metacluster, prendiamo in considerazione anche i nostri costi, i requisiti di densità, la quota di risorse, i requisiti di affidabilità e le statistiche. La decisione di creare un nuovo metacluster viene presa sulla base di tutte queste informazioni. Tieni presente che i piccoli cluster possono espandersi notevolmente in futuro, quindi il consumo di risorse aumenta anche se il numero di cluster rimane invariato. Di solito lasciamo abbastanza spazio libero per la crescita di ciascun cluster.

Riso. 3. Architettura della rete Terway

Ridimensionamento dei componenti della procedura guidata tra cluster client

I componenti della procedura guidata hanno esigenze di risorse diverse. Dipendono dal numero di nodi e pod nel cluster e dal numero di controller/operatori non standard che interagiscono con APIServer.

In ACK, ogni cluster client Kubernetes differisce per dimensioni e requisiti di runtime. Non esiste una configurazione universale per il posizionamento dei componenti della procedura guidata. Se impostiamo erroneamente un limite basso di risorse per un client di grandi dimensioni, il suo cluster non sarà in grado di far fronte al carico. Se imposti un limite prudenzialmente alto per tutti i cluster, le risorse verranno sprecate.

Per trovare un sottile compromesso tra affidabilità e costo, ACK utilizza un sistema di tipi. Definiamo cioè tre tipologie di cluster: piccolo, medio e grande. Ogni tipo ha un profilo di allocazione delle risorse separato. Il tipo viene determinato in base al carico dei componenti della procedura guidata, al numero di nodi e ad altri fattori. Il tipo di cluster può cambiare nel tempo. ACK monitora continuamente questi fattori e può eseguire l'up/down del tipo di conseguenza. Una volta modificato il tipo di cluster, l'allocazione delle risorse viene aggiornata automaticamente con un intervento minimo da parte dell'utente.

Stiamo lavorando per migliorare questo sistema con un ridimensionamento più preciso e un aggiornamento del tipo più preciso in modo che questi cambiamenti avvengano in modo più fluido e abbiano più senso economico.

Riso. 4. Commutazione intelligente di tipo multistadio

Evoluzione dei cluster di clienti su larga scala

Le sezioni precedenti trattavano alcuni aspetti della gestione di un gran numero di cluster Kubernetes. C’è però un altro problema da risolvere: l’evoluzione dei cluster.

Kubernetes è il “Linux” del mondo cloud. Viene continuamente aggiornato e diventa sempre più modulare. Dobbiamo fornire costantemente nuove versioni ai nostri clienti, correggere le vulnerabilità e aggiornare i cluster esistenti, nonché gestire un gran numero di componenti correlati (CSI, CNI, Device Plugin, Scheduler Plugin e molti altri).

Prendiamo come esempio la gestione dei componenti Kubernetes. Per cominciare, abbiamo sviluppato un sistema centralizzato per la registrazione e la gestione di tutti questi componenti collegati.

Riso. 5. Componenti flessibili e collegabili

Prima di andare avanti, è necessario assicurarsi che l'aggiornamento abbia avuto esito positivo. Per fare questo, abbiamo sviluppato un sistema per controllare la funzionalità dei componenti. Il controllo viene eseguito prima e dopo l'aggiornamento.

Riso. 6. Verifica preliminare dei componenti del cluster

Per aggiornare questi componenti in modo rapido e affidabile, un sistema di distribuzione continua funziona con il supporto per l'avanzamento parziale (scala di grigi), le pause e altre funzioni. I controller Kubernetes standard non sono adatti per questo caso d'uso. Pertanto, per gestire i componenti del cluster, abbiamo sviluppato una serie di controller specializzati, tra cui un plugin e un modulo di controllo ausiliario (gestione del sidecar).

Ad esempio, il controller BroadcastJob è progettato per aggiornare i componenti su ciascuna macchina lavoratore o controllare i nodi su ciascuna macchina. Il lavoro Broadcast esegue un pod su ogni nodo del cluster, come un DaemonSet. Tuttavia, DaemonSet mantiene sempre il pod in esecuzione per un lungo periodo, mentre BroadcastJob lo comprime. Il controller Broadcast avvia inoltre i pod sui nodi appena uniti e inizializza i nodi con i componenti necessari. Nel giugno 2019 abbiamo aperto il codice sorgente del motore di automazione OpenKruise, che noi stessi utilizziamo all'interno dell'azienda.

Riso. 7. OpenKurise organizza l'esecuzione dell'attività Broadcast su tutti i nodi

Per aiutare i clienti a selezionare le giuste configurazioni del cluster, forniamo anche una serie di profili predefiniti, inclusi i profili Serverless, Edge, Windows e Bare Metal. Man mano che il panorama si espande e crescono le esigenze dei nostri clienti, aggiungeremo più profili per semplificare il noioso processo di configurazione.

Riso. 8. Profili cluster avanzati e flessibili per vari scenari

Osservabilità globale tra i data center

Come mostrato nella seguente fig. 9, il servizio cloud Alibaba Cloud Container è stato distribuito in venti regioni in tutto il mondo. Data questa scala, uno degli obiettivi chiave di ACK è monitorare facilmente lo stato dei cluster in esecuzione in modo che, se un cluster client riscontra un problema, possiamo rispondere rapidamente alla situazione. In altre parole, è necessario trovare una soluzione che consenta di raccogliere statistiche in modo efficiente e sicuro in tempo reale dai cluster di clienti in tutte le regioni e di presentare visivamente i risultati.

Riso. 9. Distribuzione globale del servizio Alibaba Cloud Container in venti regioni

Come molti sistemi di monitoraggio Kubernetes, utilizziamo Prometheus come strumento principale. Per ciascun metacluster, gli agenti Prometheus raccolgono i seguenti parametri:

• Metriche del sistema operativo come risorse host (CPU, memoria, disco, ecc.) e larghezza di banda della rete.
• Metriche per il metacluster e il sistema di gestione dei cluster client, come kube-apiserver, kube-controller-manager e kube-scheduler.
• Metriche di kubernetes-state-metrics e cadvisor.
• parametri etcd come tempo di scrittura del disco, dimensione del database, velocità effettiva delle connessioni tra i nodi, ecc.

Le statistiche globali vengono raccolte utilizzando un tipico modello di aggregazione multistrato. I dati di monitoraggio di ciascun metacluster vengono prima aggregati in ciascuna regione e quindi inviati a un server centrale che mostra il quadro generale. Tutto funziona attraverso il meccanismo della federazione. Un server Prometheus in ogni data center raccoglie i parametri da quel data center e il server Prometheus centrale è responsabile dell'aggregazione dei dati di monitoraggio. AlertManager si connette al Prometheus centrale e, se necessario, invia avvisi tramite DingTalk, e-mail, SMS, ecc. Visualizzazione - utilizzando Grafana.

Nella Figura 10, il sistema di monitoraggio può essere suddiviso in tre livelli:

• Livello limite

Lo strato più lontano dal centro. Prometheus Edge Server viene eseguito in ogni metacluster, raccogliendo parametri da meta e cluster client all'interno dello stesso dominio di rete.

• Livello a cascata

La funzione del livello a cascata Prometheus è quella di raccogliere dati di monitoraggio da più regioni. Questi server operano a livello di unità geografiche più grandi come Cina, Asia, Europa e America. Man mano che i cluster crescono, la regione può essere divisa e in ogni nuova grande regione apparirà un server Prometheus a livello di cascata. Con questa strategia, puoi scalare facilmente secondo necessità.

• Livello centrale

Il server centrale Prometheus si connette a tutti i server in cascata ed esegue l'aggregazione finale dei dati. Per motivi di affidabilità, sono state create due istanze centrali di Prometheus in zone diverse, connesse agli stessi server in cascata.

Riso. 10. Architettura globale di monitoraggio multilivello basata sul meccanismo di federazione Prometheus

Riassunto

Le soluzioni cloud basate su Kubernetes continuano a trasformare il nostro settore. Il servizio container Alibaba Cloud fornisce hosting sicuro, affidabile e ad alte prestazioni: è uno dei migliori hosting cloud Kubernetes. Il team di Alibaba Cloud crede fortemente nei principi dell'Open Source e nella comunità open source. Continueremo sicuramente a condividere le nostre conoscenze nel campo del funzionamento e della gestione delle tecnologie cloud.

Fonte: habr.com