🥇Presentación de Kubernetes CCM (Xestor de controladores de nube) para Yandex.Cloud

Na continuación do recente Versión do controlador CSI para Yandex.Cloud estamos publicando outro proxecto de código aberto para esta nube - Xestor de controladores de nube. CCM é necesario non só para o clúster no seu conxunto, senón tamén para o propio controlador CSI. Os detalles sobre o seu propósito e algunhas características de implementación están baixo o corte.

Introdución

Por que isto?

Os motivos que nos levaron a desenvolver CCM para Yandex.Cloud coinciden completamente cos xa descritos en anuncio controladores CSI. Mantemos moitos clústeres de Kubernetes de diferentes provedores de nube, para os que utilizamos unha única ferramenta. Implementa numerosas comodidades "obviando" as solucións xestionadas destes provedores. Si, temos un caso e necesidades bastante específicos, pero os desenvolvementos creados por eles poden ser útiles para outros usuarios.

Que é exactamente CCM?

Normalmente, preparamos o ambiente que nos rodea para o clúster dende fóra - por exemplo, usando Terraform. Pero ás veces hai que xestionar o ambiente de nube que nos rodea do clúster. Esta posibilidade está prevista, e é a que se implementa CCM.

En concreto, Cloud Controller Manager ofrece cinco tipos principais de interacción:

Instancias – implementa unha relación 1:1 entre un obxecto nodo en Kubernetes (Node) e unha máquina virtual no provedor de nube. Para iso nós:
- enche o campo spec.providerID no obxecto Node. Por exemplo, para OpenStack CCM este campo ten o seguinte formato: openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Podes ver o nome do provedor de nube e o UUID único do servidor (máquina virtual en OpenStack) do obxecto;
- complemento nodeInfo no obxecto Node información sobre a máquina virtual. Por exemplo, especificamos o tipo de instancia en AWS;
- Comprobamos a presenza dunha máquina virtual na nube. Por exemplo, se un obxecto Node entrou nun estado NotReady, pode comprobar se a máquina virtual existe en absoluto no provedor de nube mediante providerID. Se non está alí, elimine o obxecto Node, que doutro xeito permanecería no clúster para sempre;
zonas – establece o dominio de falla para o obxecto Node, para que o programador poida seleccionar un nodo para o Pod segundo as rexións e zonas do provedor de nube;
LoadBalancer - ao crear un obxecto Service con tipo LoadBalancer crea unha especie de equilibrador que dirixirá o tráfico desde fóra aos nodos do clúster. Por exemplo, en Yandex.Cloud podes usar NetworkLoadBalancer и TargetGroup para estes efectos;
Ruta – constrúe unha rede entre nós, porque Segundo os requisitos de Kubernetes, cada pod debe ter o seu propio enderezo IP e poder acceder a calquera outro pod. Para estes efectos, pode utilizar unha rede de superposición (VXLAN, GENEVE) ou establecer unha táboa de enrutamento directamente na rede virtual do provedor de nube:
Volume – Permite a ordenación dinámica de FV mediante PVC e SC. Inicialmente, esta funcionalidade formaba parte do CCM, pero debido á súa gran complexidade trasladouse a un proxecto separado, Container Storage Interface (CSI). Falamos de CSI máis dunha vez писали e, como xa se mencionou, mesmo liberado controlador CSI.

Anteriormente, todo o código que interactuaba coa nube estaba situado no repositorio principal de Git do proxecto Kubernetes en k8s.io/kubernetes/pkg/cloudprovider/providers, pero decidiron abandonalo debido ao inconveniente de traballar cunha base de código grande. Todas as implementacións antigas foron movidas a repositorio separado. Para facilitar o apoio e desenvolvemento, todos os compoñentes comúns tamén se trasladaron a repositorio separado.

Do mesmo xeito que con CSI, moitos grandes provedores de nube xa deseñaron os seus CCM para aproveitar as nubes en Kubernetes. Se o provedor non ten CCM, pero todas as funcións necesarias están dispoñibles a través da API, pode implementar CCM vostede mesmo.

Para escribir a súa propia implementación de CCM, basta con implementar interfaces Go necesarias.

И isto é o que temos.

Implantación

Como chegaches a isto

Comezamos o desenvolvemento (ou mellor dito, incluso o uso) con listo(!) CCM para Yandex.Cloud hai un ano.

Non obstante, nesta implementación faltábanos:

autenticación mediante token JWT IAM;
Soporte de controlador de servizo.

De acordo co autor (dlisin) en Telegram, bifurcamos yandex-cloud-controller-manager e engadimos as funcións que faltaban.

Características clave

Actualmente, CCM admite as seguintes interfaces:

Instancias;
zonas;
LoadBalancer.

No futuro, cando Yandex.Cloud comece a traballar con capacidades avanzadas de VPC, engadiremos unha interface rutas.

LoadBalanacer como reto principal

Inicialmente, tentamos, como outras implementacións de CCM, crear un par de LoadBalancer и TargetGroup para cada un Service con tipo LoadBalancer. Non obstante, Yandex.Cloud descubriu unha limitación interesante: non pode usar TargetGroups con intersección Targets (par SubnetID - IpAddress).

Polo tanto, dentro do CCM creado, lánzase un controlador que, cando cambian os obxectos Node recolle información sobre todas as interfaces de cada máquina virtual, agrúpaas segundo a súa pertenza a determinadas NetworkID, crea por TargetGroup en NetworkID, e tamén supervisa a relevancia. Posteriormente, ao crear un obxecto Service con tipo LoadBalanacer simplemente adxuntamos un pre-creado TargetGroup a novo NetworkLoadBalanacer'son.

Como comezar a usalo?

CCM admite a versión 1.15 de Kubernetes ou superior. Nun clúster, para que funcione, require que a bandeira --cloud-provider=external estaba configurado para true para kube-apiserver, kube-controller-manager, kube-scheduler e todos os kubelets.

Todos os pasos necesarios para a propia instalación descríbense en README. A instalación redúcese a crear obxectos en Kubernetes a partir de manifestos.

Para usar CCM tamén necesitarás:

sinalar no manifesto o identificador do directorio (folder-id) Yandex.Cloud;
conta de servizo para interactuar coa API de Yandex.Cloud. No manifesto Secret necesario transferir as claves autorizadas desde a conta de servizo. Na documentación descrito, como crear unha conta de servizo e obter claves.

Estaremos encantados de recibir os teus comentarios e novos temasse atopas algún problema!

Resultados de

Estivemos a utilizar o CCM implementado en cinco clústeres de Kubernetes durante as últimas dúas semanas e planeamos ampliar o seu número a 20 no próximo mes. Actualmente non recomendamos usar CCM para instalacións grandes e críticas de K8s.

Como no caso de CSI, estaremos encantados de que os desenvolvedores de Yandex asuman o desenvolvemento e soporte deste proxecto; estamos preparados para transferir o repositorio a petición deste para xestionar tarefas que sexan máis relevantes para nós.

PS

Lea tamén no noso blog:

Fonte: www.habr.com

Presentación de Kubernetes CCM (Cloud Controller Manager) para Yandex.Cloud