Error en vSphere with Tanzu: Harbor registry on cluster domian is unhealtly 馃槺

驴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:

https://ports.esp.vmware.com/

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:

https://docs.vmware.com/en/VMware-vSphere/7.0/vmware-vsphere-with-tanzu/GUID-3E4E6039-BD24-4C40-8575-5AA0EECBBBEC.html

隆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.

Deja una respuesta

Introduce tus datos o haz clic en un icono para iniciar sesi贸n:

Logo de WordPress.com

Est谩s comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Imagen de Twitter

Est谩s comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Est谩s comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: