Presentamos Kubernetes CCM (Cloud Controller Manager) para Yandex.Cloud

A continuación de la reciente Lanzamiento del controlador CSI para Yandex.Cloud estamos publicando otro proyecto de código abierto para esta nube: Administrador del controlador de la nube. CCM es necesario no sólo para el clúster en su conjunto, sino también para el propio controlador CSI. Los detalles sobre su propósito y algunas características de implementación se encuentran debajo.

introducción

Porque es esto

Los motivos que nos impulsaron a desarrollar CCM para Yandex.Cloud coinciden completamente con los ya descritos en anuncio Conductores CSI. Mantenemos muchos clústeres de Kubernetes de diferentes proveedores de nube, para los cuales utilizamos una única herramienta. Implementa numerosas comodidades "evitando" las soluciones administradas de estos proveedores. Sí, tenemos un caso y unas necesidades bastante específicas, pero los desarrollos creados a partir de ellos pueden ser de utilidad para otros usuarios.

¿Qué es exactamente CCM?

Normalmente, preparamos el entorno que nos rodea para el clúster. desde afuera - por ejemplo, usando Terraform. Pero a veces es necesario gestionar el entorno de nube que nos rodea. del grupo. Esta posibilidad se brinda, y es la que se implementa. CCM.

Específicamente, Cloud Controller Manager proporciona cinco tipos principales de interacción:

1. Instancias – implementa una relación 1:1 entre un objeto de nodo en Kubernetes (Node) y una máquina virtual en el proveedor de la nube. Para esto nosotros:
   • rellena el campo spec.providerID en el objeto Node. Por ejemplo, para OpenStack CCM este campo tiene el siguiente formato: openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Puede ver el nombre del proveedor de la nube y el UUID único del servidor (máquina virtual en OpenStack) del objeto;
   • complementar nodeInfo en el objeto Node información sobre la máquina virtual. Por ejemplo, especificamos el tipo de instancia en AWS;
   • Comprobamos la presencia de una máquina virtual en la nube. Por ejemplo, si un objeto Node entró en un estado NotReady, puede comprobar si la máquina virtual existe en el proveedor de la nube haciendo clic en providerID. Si no está allí, elimine el objeto. Node, que de otro modo permanecería en el clúster para siempre;
2. Zonas – establece el dominio de falla para el objeto Node, para que el programador pueda seleccionar un nodo para el Pod de acuerdo con las regiones y zonas en el proveedor de la nube;
3. equilibrador de carga – al crear un objeto Service con tipo LoadBalancer Crea una especie de equilibrador que dirigirá el tráfico desde el exterior a los nodos del clúster. Por ejemplo, en Yandex.Cloud puedes usar NetworkLoadBalancer и TargetGroup para estos fines;
4. Ruta – construye una red entre nodos, porque Según los requisitos de Kubernetes, cada pod debe tener su propia dirección IP y poder comunicarse con cualquier otro pod. Para estos fines, puede utilizar una red superpuesta (VXLAN, GENEVE) o configurar una tabla de enrutamiento directamente en la red virtual del proveedor de la nube:

   

5. Volumen – Permite el ordenamiento dinámico de PV usando PVC y SC. Inicialmente, esta funcionalidad era parte de CCM, pero debido a su gran complejidad se trasladó a un proyecto separado, Container Storage Interface (CSI). Hemos hablado de CSI más de una vez. escribió y, como ya se mencionó, incluso liberado Conductor CSI.

Anteriormente, todo el código que interactuaba con la nube se encontraba en el repositorio principal de Git del proyecto Kubernetes en k8s.io/kubernetes/pkg/cloudprovider/providers, pero decidieron abandonarlo debido al inconveniente de trabajar con una base de código grande. Todas las implementaciones antiguas se han movido a repositorio separado. Para facilitar un mayor soporte y desarrollo, todos los componentes comunes también se trasladaron a repositorio separado.

Al igual que CSI, muchos grandes proveedores de nube ya han diseñado sus CCM para aprovechar las nubes en Kubernetes. Si el proveedor no tiene CCM, pero todas las funciones necesarias están disponibles a través de API, entonces usted mismo puede implementar CCM.

Para escribir su propia implementación de CCM, es suficiente implementar interfaces Go requeridas.

И Esto es lo que tenemos.

implementación

¿Cómo llegaste a esto?

Comenzamos el desarrollo (o mejor dicho, incluso el uso) con listo (!) CCM para Yandex.Cloud hace un año.

Sin embargo, en esta implementación nos faltaba:

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

De acuerdo con el autor (dlisin) en Telegram, bifurcamos yandex-cloud-controller-manager y agregamos las funciones que faltaban.

Características principales

Actualmente, CCM admite las siguientes interfaces:

• Instancias;
• Zonas;
• equilibrador de carga.

En el futuro, cuando Yandex.Cloud comience a funcionar con capacidades avanzadas de VPC, agregaremos una interfaz Rutas .

LoadBalanacer como principal desafío

Inicialmente, intentamos, al igual que otras implementaciones de CCM, crear un par de LoadBalancer и TargetGroup para cada Service con tipo LoadBalancer. Sin embargo, Yandex.Cloud descubrió una limitación interesante: no se puede utilizar TargetGroups con intersección Targets (par SubnetID - IpAddress).

Por lo tanto, dentro del CCM creado, se lanza un controlador que, cuando los objetos cambian Node recopila información sobre todas las interfaces en cada máquina virtual, las agrupa según su pertenencia a ciertos NetworkID, crea por TargetGroup en NetworkIDy también monitorea la relevancia. Posteriormente, al crear un objeto. Service con tipo LoadBalanacer simplemente adjuntamos un pre-creado TargetGroup a la nueva NetworkLoadBalanacer'soy.

¿Cómo empezar a usarlo?

CCM admite Kubernetes versión 1.15 y superiores. En un cluster, para que funcione, se requiere que la bandera --cloud-provider=external estaba establecido en true para kube-apiserver, kube-controller-manager, kube-scheduler y todos los kubelets.

Todos los pasos necesarios para la instalación en sí se describen en README. La instalación se reduce a crear objetos en Kubernetes a partir de manifiestos.

Para utilizar CCM también necesitará:

• especificar en el manifiesto el identificador del directorio (folder-id) Yandex.Cloud;
• cuenta de servicio para interactuar con la API Yandex.Cloud. en el manifiesto Secret necesario transferir claves autorizadas de la cuenta de servicio. en la documentacion descrito, cómo crear una cuenta de servicio y obtener claves.

Estaremos encantados de recibir sus comentarios y nuevos problemassi encuentra algún problema!

resultados

Hemos estado utilizando el CCM implementado en cinco clústeres de Kubernetes durante las últimas dos semanas y planeamos ampliar su número a 20 en el próximo mes. Actualmente no recomendamos utilizar CCM para instalaciones K8 grandes y críticas.

Como en el caso de CSI, estaremos encantados de que los desarrolladores de Yandex se hagan cargo del desarrollo y soporte de este proyecto; estamos listos para transferir el repositorio a petición suya para poder hacer frente a las tareas que sean más relevantes para nosotros.

PS

Lea también en nuestro blog:

• «Nuestra experiencia en el desarrollo de un controlador CSI en Kubernetes para Yandex.Cloud";
• «¿Es fácil y conveniente preparar un clúster de Kubernetes? Anuncio del operador adicional";
• «Ampliando y complementando Kubernetes (revisión y reportaje en vídeo)".

Fuente: habr.com