Presentació de Kubernetes CCM (Cloud Controller Manager) per a Yandex.Cloud

A continuació del recent Alliberament del controlador CSI per a Yandex.Cloud estem publicant un altre projecte de codi obert per a aquest núvol: Gestor del controlador del núvol. CCM és necessari no només per al clúster en conjunt, sinó també per al propi controlador CSI. Els detalls sobre el seu propòsit i algunes característiques d'implementació estan sota el tall.

Introducció

Per què és això?

Els motius que ens van impulsar a desenvolupar CCM per a Yandex.Cloud coincideixen completament amb els ja descrits a anunci Controladors CSI. Mantenim molts clústers de Kubernetes de diferents proveïdors de núvol, per als quals fem servir una única eina. Implementa nombroses comoditats "obviant" les solucions gestionades d'aquests proveïdors. Sí, tenim un cas i unes necessitats força concretes, però els desenvolupaments creats a causa d'ells poden ser útils per a altres usuaris.

Què és exactament el CCM?

Normalment, preparem l'entorn que ens envolta per al clúster des de fora - per exemple, utilitzant Terraform. Però de vegades cal gestionar l'entorn del núvol que ens envolta del clúster. Aquesta possibilitat està prevista, i és la que s'implementa CCM.

Concretament, Cloud Controller Manager ofereix cinc tipus principals d'interacció:

1. Instàncies – implementa una relació 1:1 entre un objecte node a Kubernetes (Node) i una màquina virtual al proveïdor de núvol. Per això nosaltres:
   • ompliu el camp spec.providerID en l'objecte Node. Per exemple, per a OpenStack CCM, aquest camp té el format següent: openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Podeu veure el nom del proveïdor de núvol i l'UUID únic del servidor (màquina virtual a OpenStack) de l'objecte;
   • complement nodeInfo en l'objecte Node informació sobre la màquina virtual. Per exemple, especifiquem el tipus d'instància a AWS;
   • Comprovem la presència d'una màquina virtual al núvol. Per exemple, si un objecte Node va entrar en un estat NotReady, podeu comprovar si la màquina virtual existeix al proveïdor del núvol mitjançant providerID. Si no hi és, suprimiu l'objecte Node, que d'altra manera romandria al clúster per sempre;
2. zones – estableix el domini d'error per a l'objecte Node, perquè el planificador pugui seleccionar un node per al Pod segons les regions i zones del proveïdor de núvol;
3. LoadBalancer - en crear un objecte Service amb tipus LoadBalancer crea una mena d'equilibrador que dirigirà el trànsit des de l'exterior als nodes del clúster. Per exemple, a Yandex.Cloud podeu utilitzar NetworkLoadBalancer и TargetGroup per a aquests efectes;
4. Ruta – construeix una xarxa entre nodes, perquè Segons els requisits de Kubernetes, cada pod ha de tenir la seva pròpia adreça IP i poder arribar a qualsevol altre pod. Per a aquests propòsits, podeu utilitzar una xarxa de superposició (VXLAN, GENEVE) o establir una taula d'encaminament directament a la xarxa virtual del proveïdor de núvol:

   

5. volum – Permet l'ordenació dinàmica de FV mitjançant PVC i SC. Inicialment, aquesta funcionalitat formava part del CCM, però a causa de la seva gran complexitat es va traslladar a un projecte separat, Container Storage Interface (CSI). Hem parlat més d'una vegada de CSI писали i, com ja s'ha dit, fins i tot alliberat Controlador CSI.

Anteriorment, tot el codi que interactua amb el núvol es trobava al dipòsit principal de Git del projecte Kubernetes a k8s.io/kubernetes/pkg/cloudprovider/providers, però van decidir abandonar-ho a causa dels inconvenients de treballar amb una base de codi gran. Totes les implementacions antigues s'han mogut a repositori separat. Per a la comoditat del suport i desenvolupament addicionals, també es van traslladar tots els components comuns repositori separat.

Igual que amb CSI, molts grans proveïdors de núvols ja han dissenyat els seus CCM per aprofitar els núvols a Kubernetes. Si el proveïdor no té CCM, però totes les funcions necessàries estan disponibles mitjançant l'API, podeu implementar CCM vosaltres mateixos.

Per escriure la vostra pròpia implementació de CCM, n'hi ha prou amb implementar-la interfícies Go necessàries.

И això és el que tenim.

Implementació

Com vas arribar a això

Hem començat el desenvolupament (o millor dit, fins i tot l'ús) amb llest(!) CCM per a Yandex.Cloud fa un any.

Tanmateix, en aquesta implementació trobàvem a faltar:

• autenticació mitjançant testimoni JWT IAM;
• Suport al controlador de servei.

D'acord amb l'autor (dlisin) a Telegram, hem bifurcat yandex-cloud-controller-manager i hem afegit les funcions que falten.

Característiques clau

Actualment, CCM admet les interfícies següents:

• Instàncies;
• zones;
• LoadBalancer.

En el futur, quan Yandex.Cloud comenci a treballar amb capacitats avançades de VPC, afegirem una interfície rutes.

LoadBalanacer com a repte principal

Inicialment, vam intentar, com altres implementacions de CCM, crear un parell de LoadBalancer и TargetGroup per cadascú Service amb tipus LoadBalancer. Tanmateix, Yandex.Cloud va descobrir una limitació interessant: no podeu utilitzar TargetGroups amb intersecció Targets (parell SubnetID - IpAddress).

Per tant, dins del CCM creat, es llança un controlador que, quan canvien els objectes Node recull informació sobre totes les interfícies de cada màquina virtual, les agrupa segons la seva pertinença a determinades NetworkID, crea per TargetGroup en NetworkID, i també supervisa la rellevància. Posteriorment, en crear un objecte Service amb tipus LoadBalanacer simplement adjuntem un pre-creat TargetGroup a nou NetworkLoadBalanacer'sóc.

Com començar a utilitzar-lo?

CCM és compatible amb Kubernetes versió 1.15 i superior. En un clúster, perquè funcioni, requereix que la bandera --cloud-provider=external estava establert a true per a kube-apiserver, kube-controller-manager, kube-scheduler i tots els kubelets.

Tots els passos necessaris per a la instal·lació es descriuen a README. La instal·lació es redueix a crear objectes a Kubernetes a partir de manifests.

Per utilitzar CCM també necessitareu:

• indicar al manifest l'identificador del directori (folder-id) Yandex.Cloud;
• compte de servei per interactuar amb l'API Yandex.Cloud. En el manifest Secret necessari transferir les claus autoritzades des del compte de servei. A la documentació descrit, com crear un compte de servei i obtenir claus.

Estarem encantats de rebre els vostres comentaris i nous temessi trobeu algun problema!

Resultats de

Hem estat utilitzant el CCM implementat en cinc clústers de Kubernetes durant les últimes dues setmanes i tenim previst ampliar-ne el nombre a 20 el mes que ve. Actualment no recomanem utilitzar CCM per a instal·lacions grans i crítiques de K8s.

Com en el cas de CSI, estarem encantats si els desenvolupadors de Yandex assumeixen el desenvolupament i el suport d'aquest projecte: estem preparats per transferir el dipòsit a petició seva per fer front a les tasques que ens són més rellevants.

PS

Llegeix també al nostre blog:

• «La nostra experiència en el desenvolupament d'un controlador CSI a Kubernetes per a Yandex.Cloud»;
• «És fàcil i convenient preparar un clúster de Kubernetes? Anunciant l'operador de complements»;
• «Ampliar i complementar Kubernetes (visió general i informe de vídeo)».

Font: www.habr.com