Container Services Extension

Container Services Extension – Kubernetes as a Service para vCloud Director

Por Nicolás Bardier, Cloud admin en Pyxis

Container Services Extension (CSE), es una extensión de vCloud Director desarrollada por VMware para desplegar clusters de Kubernetes por parte de administradores de organización de vCloud Director (Kubernetes as a Service).

Resumen

• Introducción
• Casos de uso
• Roles y funciones en CSE
• Notas sobre despliegue y uso
• Para terminar
• Agradecimientos

Introducción

Con el surgimiento de servicios basados en contenedores y DevOps, han aparecido multitud de soluciones para despliegue automático de infraestructura. CSE es una de ellas.
CSE apalanca la infraestructura existente de vCloud Director para generar clusters de Kubernetes rápidamente, para disponibilizarlos a equipos que consuman ese servicio, tales como QA y desarrollo.

Caso de uso


En base a nuestras pruebas, el caso de uso más adecuado para CSE es el de despliegue de clusters de Kubernetes ‘descartables’, para equipos de desarrollo o QA, por parte de administradores de IaaS sin experiencia en despliegue de Kubernetes.

Otro caso de uso muy similar es el despliegue de clusters de Kubernetes para demos de aplicaciones basadas en contenedores.

Ejemplo de flujo de uso de CSE. Imagen obtenida del sitio de CSE

Ejemplo de flujo de uso de CSE. Imagen obtenida del sitio de CSE

 

Roles y funciones en CSE


A los efectos de CSE, hay cuatro roles definidos:

 

-Administrador de nube
Configura, despliega y administra el servicio CSE y su conexión a vCloud Director y vCenter
Es el administrador de la plataforma de nube basada en vCloud Director

-Administrador de organización
Administra la organización (también llamada tenant) de vCloud Director
Crea, reconfigura y destruye clusters de Kubernete definidos en vCloud Director

-Administrador K8s
Gestiona el cluster K8s, con kubectl, vía SSH directamente hacia los nodos del cluster.

-Usuario K8s
Gestiona pods y servicios de un cluster Kubernetes dado, por ejemplo usando kubectl

 

Imagen obtenida del sitio de CSE

Imagen obtenida del sitio de CSE

 

Imagen obtenida del sitio de CSE

Imagen obtenida del sitio de CSE

 

Notar que la documentación oficial de CSE no distingue entre administrador y usuario de K8s

Notas sobre despliegue y uso

Hay un buen ejemplo cómo desplegar un cluster de Kubernetes y un grupo de pods con CSE en la web de CSE, hay algunos puntos a considerar al desplegar Kubernetes con CSE

Al crear el cluster:

-Definir la clave SSH a usar.
Una vez desplegado el cluster, no permite cambiar la clave SSH desde vcd-cli

-Definir un nodo NFS.
Desde vcd-cli no se puede agregar un nodo NFS a un cluster existente.

-No hay un control explícito de las IPs a usar en cada VM de la vAPP.
El proceso de creación del cluster toma direcciones IPs disponibles del pool de la red local.

Esto puede implicar rehacer los DNATs y las reglas de firewall existentes en caso de reconstruir el cluster.

-El comandovcd cse cluster create puede demorar unos minutos.
Demora según la velocidad del enlace a Internet y la performance de la infraestructura sobre donde corre.

Por ejemplo, en un laboratorio con virtualización anidada en discos locales y un enlace de 10Mbit, desplegar un cluster de 3 VMs (master, nodo y nfs), demora 30 minutos aproximadamente.

Las versiones de K8s y SO se ven condicionadas a los templates disponibles. Dicha condicionante se traslada de forma transitiva al cliente final. Estos templates residen de forma oficial en un repositorio remoto, mantenido y administrado por los colaboradores del proyecto CSE.

-Considerar usar la versión 2.5 de CSE.
Según la documentación oficial, la versión CSE 2.5 ofrece varias mejoras, como poder usar templates customizados

-Tener en cuenta la compatibilidad de versiones de vcd-cli y container-service-extension.
Puede causar problemas no usar una versión idéntica a los componentes del lado del servidor.

-La arquitectura posible de k8s es siempre 1 master + n workers.
Esto implica que no sea aconsejable usar esta solución para cargas productivas que requieran alta disponibilidad.

Operando el cluster:

-Ajustar la configuración del archivo de configuración para kubectl según corresponda.
Tener en cuenta los parámetros ‘server’, ‘certificate-authority-data’ y ‘insecure-skip-tls-verify’, según si se usa un entorno de pruebas, y/o se accede con kubectl desde fuera de la organización de vCloud Director.

Por ejemplo, para el cluster kaas01 se puede generar un archivo .conf para kubectl de esta forma:

$ vcd cse cluster config kaas01 > ~/kaas01.conf

-Crear, modificar y destruir clusters CSE sólo es posible a través de la API o de vcd-cli.
No hay integración con las interfaces web (HTML5 ni Flash) a la versión 9.7 de vCloud Director.

Para escalar el cluster, ejecutar

$ vcd cse cluster resize <cluster-name> -N <count>

-El storage persistente que habilita la solución es solo NFS.
No fué posible habilitar storageOS.

Para terminar


-CSE permite desplegar clusters de Kubernetes rápidamente.
-Un usuario de Kubernetes que quiere focalizarse en probar su aplicación, puede disponer rápidamente de un cluster sobre el que trabajar.
-Un administrador de organización puede crear y destruir un cluster de Kubernetes con relativa facilidad a traves de la API o de vcd-cli.

Cito además a las conclusiones del equipo de DevOps:

«Se destaca la facilidad de despliegue, lo cual hace sumamente sencillo montar un cluster, sin ostentar conocimientos previos. Por otro lado, la administración del día cero es muy limitada, ya que la solución no cuenta con componentes básicos, tales como ingress controller o dashboard. Lo cual requiere de un usuario mas avanzado de K8s para disponibilizar.

Esto hace que la entrega de la solución como un producto, exija conocimientos

técnicos de k8s para su consumo.

Por otro lado, la incapacidad de contar con despliegues Multi-Master limitaría el uso a ambientes de desarrollo, demo o QA solamente.

En líneas generales encuentro la solución con varias limitantes desde el punto de vista de administrador de K8s, limitantes que al parecer serian propias de la maduración del proyecto. El release GA inicial fue a mediados de 2018.»

Agradecimientos

A los equipos de Research y DevOps de Pyxis por coordinar y ejecutar las pruebas de la solución, y darme una devolución sobre la misma.

Como siempre, al equipo de Comunicación por ayudarnos a que la entrada del blog quede lo mejor posible 🙂

Links de interés

Kubernetes as a Service on vCloud Director por Steve Dockar