¿Cómo están estimados? ¡Espero que bien! Hoy les traigo una publicación sobre un error que nos apareció en VMware vSphere with Tanzu a la hora de desplegar el servicio de Harbor Registry embebido.
Vayamos por parte. Antes que nada, quisiera realizar una muy breve explicación de que es Harbor y a que me refiero con «embebido»:
¿Qué es Harbor Registry? Harbor es un repositorio de código abierto que almacena, firma y escanea contenido, al cual protege mediante políticas y control de acceso basado en funciones. Dicho contenido son imágenes de contenedores, que son básicamente templates (una plantilla maestra inmutable) que se utilizan para desplegar contenedores que sean exactamente iguales. Para hacer una analogía, son como las templates que se utilizan en VMware para desplegar VMs que tengan una configuración similar (mismo Guest OS, hardware virtual, etc.). Harbor garantiza que las imágenes se escaneen y estén libres de vulnerabilidades, y luego las firma como confiables. Harbor es un proyecto de la CNCF (Cloud Native Computing Foundation), ofrece cumplimiento, rendimiento e interoperabilidad para administrar imágenes de manera consistente y segura en plataformas informáticas nativas de la nube como Kubernetes y Docker.
Como administrador de vSphere, se puede desplegar Harbor Registry de dos maneras: embebido con vSphere with Tanzu o a través de un Cluster TKG (Tanzu Kubernetes Grid) despleagado desde Tanzu Mission Control o mediante un archivo YAML. Las ultimas dos opciones sería de la manera «no embebida». Cualquiera de los despliegue anteriormente mencionados, te permitirán insertar o extraer imágenes de contenedores, así como desplegar contenedores utilizando dichas imágenes. La diferencia entre ambos despliegues es que el embebido, no está recomendado para ambientes productivos y una vez que esté habilitado, por cada namesapace que se crea a nivel de Supervisor Cluster, dentro de Harbor se creará de manera automática un proyecto asociado con el mismo nombre. Además cada usuario o grupo de usuarios, que tenga permisos para editar o ver el namespace, se convertirá automáticamente en un miembro con el rol correspondiente en el proyecto asociado. El ciclo de vida de los proyectos y de los miembros correspondientes, está vinculado y se administrará de manera automática. En pocas palabras, si creo o elimino un namespace con nombre «X», el proyecto vinculado dentro de Harbor (que también tendrá el mismo nombre «X»), será creado o eliminado de manera automática sin necesidad de una intervención manual. Otra gran diferencia es que en el modo embebido, Harbor se ejecuta mediante vSphere Pods (es un pod de Kubernetes ejecutando directamente sobre el ESXI), en cambio en el otro modo se ejecutará como un Pod de Kubernetes dentro de un Cluster TKG (conformado por VMs, en donde algunas cumplirán el rol de Control Plane y otras funcionarán como Worker Nodes). Por ultimo, en la versión no embebida, los proyectos deben crearse y asociarse de manera manual (o sea, con la intervención de un administrador).
Ahora bien, ya explicado que es Harbor, para que se utiliza y sus diferentes tipos de despliegues dentro de Tanzu, pasaré a detallar que fue lo sucedido. Al habilitar el servicio de Harbor embebido en nuestro entorno productivo, funcionó de manera correcta durante algunos días. Permitía conectarnos a la web de management, loguearnos con nuestros usuarios y realizar cualquier tipo de acción necesaria. Además, por cada nuevo namespace que se creaba a nivel de Supervisor Cluster, se generaba un proyecto con el mismo nombre de manera automática.
Todo muy lindo, hasta que un día apareció el siguiente error:
Al principio suponíamos que era producto de algún cambio que se había realizado en la infraestructura. Era la conclusión mas lógica, si algo viene funcionando bien y de un momento al otro deja de hacerlo, se supone que algún cambio se habrá efectuado (lo cual afectó de manera directa al servicio). Aunque en realidad el error era un poco confuso, ya que por un lado mostraba el mensaje, pero cuando se verificaba el estado del servicio a través de la API, nos devolvía el detalle de que todos los componentes que conforman el servicio gozaban de buena salud:
{
«status»: «healthy»,
«components»: [
{
«name»: «portal»,
«status»: «healthy»
},
{
«name»: «jobservice»,
«status»: «healthy»
},
{
«name»: «registry»,
«status»: «healthy»
},
{
«name»: «registryctl»,
«status»: «healthy»
},
{
«name»: «database»,
«status»: «healthy»
},
{
«name»: «redis»,
«status»: «healthy»
},
{
«name»: «core»,
«status»: «healthy»
}
]
}
Algunos síntomas que habíamos detectado en relación al error fueron los siguientes:
- El servicio siempre se desplegaba sin ningún error. Lo habíamos desactivado y vuelto a activar en varias ocasiones, y nunca fallaba ni al momento del despliegue ni a la hora de desactivarlo.
- El servicio funcionaba bien aproximadamente durante una semana y a los pocos días comenzaba a fallar, presentando el mensaje de error que compartí en la imagen.
- Una vez que aparecía el mensaje de error, durante los primeros días, si se creaba un nuevo namespace no se generaba el proyecto correspondiente dentro de Harbor. Por lo tanto, ya no cumplía la función para lo cual se utiliza el servicio.
- Seguido al problema anterior, podías continuar accediendo al management por unos días, aunque no podías ejecutar ninguna acción desde la consola web. No solo eso, los desarrolladores tampoco podía acceder a sus imágenes, las cuales ya no aparecían.
- Por ultimo el servicio dejaba de funcionar en su totalidad y ni siquiera se podía llegar a la URL del management.
En pocas palabras, el error no aparecía desde el primer momento del despliegue, sino que el servicio se iba degradando cada vez mas, al cabo de unos pocos días. Luego de varias pruebas, detectamos un síntoma que se presentaba de manera muy particular. Cada vez que el host en donde se estaban ejecutando los vSphere Pods de Harbor, entraba en modo mantenimiento, el mensaje de error aparecía. Forzando el error en varias ocasiones (o sea activando el servicio de Harbor embebido y cambiando el estado del nodo ESXI a modo mantenimiento), ejecutamos un rastreo en conjunto con el soporte oficial de VMware, hasta que llegamos a detectar un puerto bloqueado en la red de Management entre las VMs Control Plane y los hosts ESXi del Supervisor Cluster. El puerto en cuestión era el TCP 10250, encargado de brindar el acceso al servicio Spherelet. ¿Y que función cumple Spherelet?. Permite que un host ESXI, actué como un Kerbernetes Worker Node (o sea que se puedan ejecutar Pods de Kubernetes, directamente sobre el host). Dicho esto, si el puerto se encuentra bloqueado, es correcto que si se activa el servicio de Harbor como un vSphere Pod (o sea en modo embebido), el mismo sufra algún error durante su ejecución. Ahora bien, te estarás preguntando (al igual que lo hice yo en su momento), ¿si dicho puerto estaba bloqueado desde un principio, no debería haber fallado ni bien se activó el servicio de Harbor?. Sería lo mas lógico, pero al parecer el servicio de Spherelet no interviene a la hora de desplegar o de desactivar Harbor, sino que lo hace durante el resto del ciclo de vida de los pods.
Sumado a lo anterior, te preguntarás: ¿por que no revisaron los requisitos de puertos necesarios antes de comenzar el proyecto?. La realidad es que lo hicimos, pero paso a explicar a que se debió nuestra confusión. Si buscas la lista de puertos necesarios en la siguiente web:
Podrás filtrar los puertos que se necesitan para la integración de vSphere con Tanzu. Como verás en la imagen a continuación, el error fue de interpretación, ya que entendimos que «Tanzu Cluster» hacía referencia solo a las 3 VMs que conforman el Supervisor Control Plane:
Pero la realidad es que cuando se activa el servicio de Tanzu en un vSphere Cluster, el Tanzu Cluster está conformado tanto por las 3 VMs que se despliegan de manera automatica para el Control Plane, como por los host ESXI que cumplirán la función de Worker Nodes. En conjunto conforman el llamado Supervisor Cluster. Por lo tanto nuestra falta de experiencia con el producto, hizo que solo habilitemos los puertos para las 3 VMs. Cosas que pasan….😅
Si quieren saber mas sobre como está conformada la arquitectura de vSphere with Tanzu, les dejo la documentación oficial en donde está muy bien explicado:
¡Bueno gente, hasta acá llegamos con la publicación del día de hoy! Espero que les pueda servir, en caso de que tengan el mismo inconveniente. Por cualquier consulta o duda. podrán contactarme a través de los comentarios o vía mail.
Por ultimo te pido que me ayudes a difundir mi blog compartiendo el link 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 