Hace aproximadamente nueve meses la comunidad de Kubernetes acordó formar el Grupo de Interés Especial para Proveedores en la Nube (SIG). El objetivo de este grupo es disponer de un único órgano de gobierno desde donde gestionar los diferentes puntos de integración entre Kubernetes y los muchos proveedores de nube que admite. En estos primeros meses de recorrido del SIG ha habido mucho movimiento alrededor del grupo, originalmente impulsado por los grandes proveedores de nube pública y privada como Amazon, Google y VMware.
Conasa participa del SIG de Kubernetes en su integración con los proveedores cloud
El objetivo del SIG de Kubernetes
La misión del SIG es simplificar, desarrollar y mantener integraciones de proveedores en la nube como extensiones o complementos a los clusters de Kubernetes. La motivación detrás de esto es doble: asegurar que Kubernetes siga siendo extensible y agnóstico en la nube.
El estado actual de los proveedores en la nube en Kubernetes
Con el fin de obtener una perspectiva de futuro para el trabajo del SIG es importante analizar el estado actual de los proveedores en la nube. Actualmente cada componente central de Kubernetes (excepto el programador y kube-proxy) tiene una marca –cloud provider- que puede configurar para habilitar un conjunto de funcionalidades que se integran con el proveedor de infraestructura subyacente, el proveedor en la nube. La habilitación de esta integración desbloquea un amplio conjunto de funciones para sus clústeres, como el descubrimiento de zonas y zonas de nodo, equilibradores de carga en la nube para servicios con tipo LoadBalancer, administración de direcciones IP y gestión de redes de clusters a través de tablas de enrutamiento VPC. Hoy en día las integraciones de proveedores se pueden realizar tanto In-Tree como Out-of-Tree.
Proveedores In-Tree & Out-of-Tree
Los proveedores In-Tree son los proveedores que desarrollan y lanzan el código fuente en el repositorio principal propio de Kubernetes que es k8s.io/kubernetes. Esto da como resultado la incorporación del conocimiento y el contexto de cada proveedor de la nube en la mayoría de los componentes de Kubernetes y permite que más integraciones nativas, como kubelet, soliciten información sobre sí mismo a través de un servicio de metadatos del proveedor de la nube.
Arquitectura In-Tree (fuente: kubernetes.io)
Los proveedores Out-of-Tree son proveedores que pueden desarrollarse, construirse y liberarse independientemente del núcleo de Kubernetes. Esto requiere la implementación de un nuevo componente llamado el controlador de la nube que es responsable de ejecutar todos los controladores específicos de la nube que se ejecutaron anteriormente en el kube-controller-manager.
Arquitectura Out-of-Tree (fuente: kubernetes.io)
Las integraciones de proveedores en la nube se desarrollaron inicialmente In-Tree. Se integró cada proveedor cerca del núcleo de Kubernetes. A medida que Kubernetes se hizo más ubicuo y más proveedores de infraestructura querían unirse al movimiento se vio la falta de escalabilidad de este modelo. Al incluirlo de forma nativa aparecen problemas difíciles de resolver como por ejemplo que cada proveedor trae consigo un amplio conjunto de dependencias que aumenta las vulnerabilidades potenciales en nuestra base de código y aumenta significativamente el tamaño binario de cada componente. Además de esto, la mayoría de los changelog en cada versión de Kubernetes comenzaron a centrarse en los cambios específicos del proveedor en lugar de los cambios centrales que afectaron a todos los usuarios de Kubernetes.
A fines de 2017 se desarrolló un nuevo API para que los proveedores de la nube construyan integraciones sin agregarlas al árbol principal de Kubernetes (Out-of-Tree), el cual se convirtió en la manera de facto para que los nuevos proveedores de infraestructura en el ecosistema se integren con Kubernetes. Desde entonces, el SIG ha estado trabajando activamente para migrar a todos los proveedores de nube a usar la arquitectura fuera de árbol, ya que la mayoría de los clústeres de hoy en día siguen utilizando los proveedores In-Tree.
Próximos pasos del SIG de Kubernetes
De cara al futuro, el objetivo del SIG es eliminar a todos los proveedores In-Tree a favor de sus equivalentes Out-of-Tree con un impacto mínimo para los usuarios. Además de la integración del proveedor de la nube central mencionada anteriormente, hay más puntos de extensión para las integraciones de la nube como CSI y el proveedor de credenciales de imagen que se están trabajando activamente para versión 1.15. Llegar a este punto significaría que Kubernetes es realmente independiente de la nube sin integraciones nativas para ningún proveedor de la nube. Al hacer este trabajo, se habilita a cada proveedor de la nube para que desarrolle y lance nuevas versiones con su propia cadencia independiente de Kubernetes. Ya hemos aprendido que esta es una gran hazaña con un conjunto único de desafíos. Migrar cargas de trabajo nunca es fácil, especialmente cuando es una parte esencial del plano de control. Proporcionar una ruta de migración segura y fácil entre los proveedores de nube dentro y fuera del árbol es de la más alta prioridad para el SIG en las próximas versiones.
Para concluir, desde Conasa animamos a todo aquel que le parezca interesante a revisar algunos de los KEP y a que se ponga en contacto con nuestro SIG uniéndose a la lista de correo o a nuestro canal (#sig-cloud-provider en Kubernetes slack).
