🥇Presentazione di Kubernetes CCM (Cloud Controller Manager) per Yandex.Cloud

In continuazione al recente Rilascio del driver CSI per Yandex.Cloud stiamo pubblicando un altro progetto Open Source per questo cloud - Gestore del controller cloud. CCM è richiesto non solo per il cluster nel suo insieme, ma anche per il driver CSI stesso. I dettagli sul suo scopo e alcune funzionalità di implementazione sono sotto taglio.

Introduzione

Perché questo?

Le motivazioni che ci hanno spinto a sviluppare CCM per Yandex.Cloud coincidono completamente con quelle già descritte in annuncio Autisti CSI. Manteniamo molti cluster Kubernetes di diversi fornitori di servizi cloud, per i quali utilizziamo un unico strumento. Implementa numerose comodità “aggirando” le soluzioni gestite di questi fornitori. Sì, abbiamo casi ed esigenze piuttosto specifici, ma gli sviluppi creati a causa di essi potrebbero essere utili ad altri utenti.

Cos'è esattamente il CCM?

In genere, prepariamo l'ambiente intorno a noi per il cluster dall'esterno - ad esempio, utilizzando Terraform. Ma a volte è necessario gestire l’ambiente cloud che ci circonda dal grappolo. Questa possibilità è prevista ed è questa che viene implementata CCM.

Nello specifico, Cloud Controller Manager prevede cinque tipologie principali di interazione:

Istanze – implementa una relazione 1:1 tra un oggetto nodo in Kubernetes (Node) e una macchina virtuale nel provider cloud. Per questo noi:
- compilare il campo spec.providerID nell'oggetto Node. Ad esempio, per OpenStack CCM questo campo ha il seguente formato: openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Puoi vedere il nome del cloud provider e l'UUID univoco del server (macchina virtuale in OpenStack) dell'oggetto;
- complemento nodeInfo nell'oggetto Node informazioni sulla macchina virtuale. Ad esempio, specifichiamo il tipo di istanza in AWS;
- Verifichiamo la presenza di una macchina virtuale nel cloud. Ad esempio, se un oggetto Node entrò in uno stato NotReady, puoi verificare se la macchina virtuale esiste nel provider cloud tramite providerID. Se non è presente, elimina l'oggetto Node, che altrimenti rimarrebbe per sempre nel cluster;
Zone – imposta il dominio di errore per l'oggetto Node, in modo che lo scheduler possa selezionare un nodo per il Pod in base alle regioni e alle zone del cloud provider;
Load Balancer – durante la creazione di un oggetto Service con il tipo LoadBalancer crea una sorta di bilanciatore che indirizzerà il traffico dall'esterno verso i nodi del cluster. Ad esempio, in Yandex.Cloud puoi utilizzare NetworkLoadBalancer и TargetGroup per questi scopi;
strada – costruisce una rete tra i nodi, perché Secondo i requisiti Kubernetes, ogni pod deve avere il proprio indirizzo IP ed essere in grado di raggiungere qualsiasi altro pod. A questo scopo è possibile utilizzare una rete overlay (VXLAN, GENEVE) o impostare una tabella di routing direttamente nella rete virtuale del fornitore di servizi cloud:
Volume – Consente l'ordinamento dinamico di PV utilizzando PVC e SC. Inizialmente questa funzionalità faceva parte di CCM, ma a causa della sua grande complessità è stata spostata in un progetto separato, Container Storage Interface (CSI). Abbiamo parlato di CSI più di una volta ha scritto e, come già accennato, anche rilasciato Autista CSI.

In precedenza, tutto il codice che interagiva con il cloud si trovava nel repository Git principale del progetto Kubernetes su k8s.io/kubernetes/pkg/cloudprovider/providers, ma hanno deciso di abbandonarlo a causa dell'inconveniente di lavorare con una base di codice di grandi dimensioni. Tutte le vecchie implementazioni sono state spostate in deposito separato. Per comodità di ulteriore supporto e sviluppo, sono stati spostati anche tutti i componenti comuni deposito separato.

Come nel caso di CSI, molti grandi provider cloud hanno già progettato i propri CCM per sfruttare i cloud su Kubernetes. Se il fornitore non dispone di CCM, ma tutte le funzioni necessarie sono disponibili tramite API, puoi implementare tu stesso CCM.

Per scrivere la propria implementazione di CCM, è sufficiente implementare interfacce Go richieste.

И questo è ciò che abbiamo ottenuto.

implementazione

Come sei arrivato a questo?

Abbiamo iniziato lo sviluppo (o meglio, anche l'utilizzo) con pronto(!) CCM per Yandex.Cloud un anno fa.

Tuttavia, in questa implementazione ci mancava:

autenticazione tramite token JWT IAM;
Supporto del controller di servizio.

D'accordo con l'autore (dlisin) in Telegram abbiamo biforcato yandex-cloud-controller-manager e aggiunto le funzioni mancanti.

Caratteristiche principali

Attualmente, CCM supporta le seguenti interfacce:

Istanze;
Zone;
Load Balancer.

In futuro, quando Yandex.Cloud inizierà a funzionare con funzionalità VPC avanzate, aggiungeremo un'interfaccia Itinerari.

LoadBalanacer come sfida principale

Inizialmente, abbiamo provato, come altre implementazioni CCM, a creare una coppia di LoadBalancer и TargetGroup per ogni Service con il tipo LoadBalancer. Tuttavia, Yandex.Cloud ha scoperto una limitazione interessante: non puoi usarlo TargetGroups con intersezione Targets (paio SubnetID - IpAddress).

Pertanto, all'interno del CCM creato, viene avviato un controller che, quando gli oggetti cambiano Node raccoglie informazioni su tutte le interfacce su ciascuna macchina virtuale, le raggruppa in base alla loro appartenenza a determinate NetworkID, crea da TargetGroup su NetworkIDe monitora anche la pertinenza. Successivamente, durante la creazione di un oggetto Service con il tipo LoadBalanacer alleghiamo semplicemente un file pre-creato TargetGroup a nuovo NetworkLoadBalanacer'Sono.

Come iniziare a utilizzare?

CCM supporta Kubernetes versione 1.15 e successive. In un cluster, affinché funzioni, è necessario che il flag --cloud-provider=external era impostato su true per kube-apiserver, kube-controller-manager, kube-scheduler e tutti i kubelet.

Tutti i passaggi necessari per l'installazione stessa sono descritti in README. L'installazione si riduce alla creazione di oggetti in Kubernetes dai manifest.

Per utilizzare CCM avrai bisogno anche di:

specificare nel manifest l'identificatore della directory (folder-id) Yandex.Cloud;
account di servizio per interagire con l'API Yandex.Cloud. Nel manifesto Secret necessario trasferire le chiavi autorizzate dal conto del servizio. Nella documentazione descritto, come creare un account di servizio e ottenere le chiavi.

Saremo lieti di ricevere il tuo feedback e nuove questionise riscontri problemi!

Risultati di

Nelle ultime due settimane abbiamo utilizzato il CCM implementato in cinque cluster Kubernetes e prevediamo di espanderne il numero a 20 nel prossimo mese. Al momento non consigliamo di utilizzare CCM per installazioni K8 critiche e di grandi dimensioni.

Come nel caso di CSI, saremo lieti se gli sviluppatori Yandex si assumeranno lo sviluppo e il supporto di questo progetto: siamo pronti a trasferire il repository su loro richiesta per occuparci dei compiti che sono più rilevanti per noi.

Presentazione di Kubernetes CCM (Cloud Controller Manager) per Yandex.Cloud