¿Cómo están estimados? ¡Espero que bien! Hoy les traigo un tema que nos pasó hace unas semanas durante el despliegue y configuración de VMware vSphere with Tanzu. La idea de esta publicación es reflejar de alguna manera como nos puede llegar a invadir la incertidumbre cuando se tiene un problema y se está trabajando con una tecnología desconocida (o mejor dicho que se conoce poco), sumado con la falta de lectura de la documentación correspondiente. Si bien al final no fue un inconveniente grave, el no saber en ese momento cual era la causa raíz, terminó magnificando el asunto. Seamos sinceros, ¿a quién no le paso esto alguna vez?.
Hecha la introducción, vayamos al detalle del problema. Resulta que durante la configuración de Tanzu sobre nuestro entorno vSphere, nos tocaba realizar una tarea ya programada: actualizar el vCenter Server a la versión «7 u2». Es sabido que en este ultimo tiempo han salido varios parches, debido a la gran cantidad de vulnerabilidades detectadas por parte de VMware. Por lo tanto, la actualización de la infraestructura cada vez se hace mas frecuente. En este caso, ya teníamos conocimiento de cuales eran las versiones de todas las plataformas de VMware desplegadas (vCenter, ESXI, vROps, NSX-T, etc,) y si eran compatibles entre sí (matriz de interoperabilidad, https://interopmatrix.vmware.com/Interoperability). Además habíamos seguido la secuencia correspondiente tal cual lo recomendado por VMware:
https://kb.vmware.com/s/article/78221
Como podrán observar, el producto «Tanzu» no figura en dicho cuadro, por lo tanto nuestra conclusión fue: «si no figura dentro de la secuencia, debe ser que no tiene ningún impacto»….Error numero uno: suponer cosas sin antes preguntar. ¡Que error fatal! Y eso que veníamos trabajando en conjunto con la propia gente de VMware. En fin, cosas que suceden y nos enseñan a mejorar.
¿Cuál fue puntualmente el error? Al actualizar vCenter de 7u1 a 7u2, desapareció una de las opciones necesarias a la hora de configurar un «Namespace»:
A simple vista no se ve, pero si ya conoces la plataforma notarás que falta la opción «VM Service» justo al lado del cuadro «vSphere Pods»:
Así es como se debería ver, si estuviese todo en condiciones:
¿Qué función cumple «VM Service»?. Es un componente de vSphere with Tanzu que proporciona una API declarativa al estilo Kubernetes, para la administración de máquinas virtuales y recursos asociados a vSphere. Permite a los administradores de vSphere entregar recursos y proporcionar plantillas (templates), como «VM classes» y «VM images». Los DevOps pueden usar estos recursos para describir el estado deseado de una VM. Después de que los DevOps especifiquen el estado de la máquina virtual, el «VM Service» convierte el estado deseado en un estado realizado, utilizando los recursos de infraestructura. Una VM creada a través de «VM Service» solo se puede administrar desde un «Namespace» de Kubernetes, utilizando los comandos kubectl. Los administradores de vSphere no pueden administrar la VM desde «vSphere Client», pero si pueden ver sus detalles y monitorear los recursos que utiliza.
Volviendo al asunto en cuestión, el problema ya estaba reportado por VMware. Error numero dos: no leer la documentación pertinente antes de realizar un upgrade. Si hubiéramos leído la guía de vCenter, nos hubiéramos percatado del siguiente párrafo:
Lamentablemente, el artículo mencionado, lo encontramos unos días después de que el problema se había presentado. Algo que habíamos intentado hacer, fue reiniciar los servicios de «Workload Control Plane» (WCP) y «VMware vSphere Client», pensando que podría llegar a corregir el problema. Pero no funcionó. Se imaginan que durante ese tiempo, se nos pasó por la cabeza la idea de que se había «roto» la configuración realizada y que teníamos que volver a desplegar todo de nuevo. ¡Damage control!.
Para arreglar el estado de los «Namespaces», procedimos a ejecutar la actualización del Supervisor Cluster, tal cual se indicaba en dicho artículo. Dentro del web cliente de vCenter hay que dirigirse a, Home–>Workload Management–>Updates
Como observarán en la imagen anterior, muestra cual es la versión que actualmente tenemos (v1.19) y que versión se encuentra disponible (v1.20). Por ultimo hacemos click en «Apply Updates» para ejecutar la actualización de las tres VMs que conforman el «SupervisorControlPlane Cluster»:
Al igual que sucede con el ciclo de vida en Kubernetes, cuando se actualicen las tres VMs lo que hará es: desplegar una nueva VM, copiar los datos de una VM obsoleta a la nueva y eliminar una VM obsoleta:
Como verán en la imagen anterior, se desplegó una «VM 4», la cual pasará a remplazar la «VM 1». Una vez que finalice todo el ciclo dentro del Cluster, quedará de la siguiente manera:
Tres VMs (4, 5 y 6) nuevas desplegadas con la configuración correspondiente y en versión 1.20. Tres VMs (1, 2 y 3) versión 1.19 eliminadas.
Una vez concluida la actualización, volveremos a recuperar la opción de «VM Service» sobre nuestros «Namespaces» configurados.
En mi opinión, dependiendo a que versión se quiera actualizar la infraestructura, la secuencia correcta debería ser la siguiente:
Al final se puede concluir que no fue nada grave, quedando simplemente como una linda experiencia 😀.
¡Bueno gente, hasta acá llegamos con el post del día de hoy! Cualquier consulta que tengas no dudes en contactarme a través de los comentarios o vía mail. Compartilo con colegas, compañeros o amigos. Si te gusta mi contenido, si la virtualización es tu hobby o si te dedicas de manera profesional, te invito a que te suscribas para recibir una notificación cada vez que escriba un artículo nuevo.
¡Hasta la próxima publicación!
Se autoriza la reproducción de los materiales de este blog citando la fuente e incluyendo un enlace al mismo.
Blog de Cloud Computing y Virtualización 