Introducción
Las sondas son cómo podemos decirle a Kubernetes que todo dentro del pod está funcionando como se espera. Kubernetes no tiene forma de saber qué está sucediendo dentro a nivel detallado y no tiene forma de saber para cada contenedor si está saludable o no, por eso necesitan ayuda del propio contenedor.
Imagina que eres el controlador de Kubernetes y tienes como ocho pods diferentes, uno con una aplicación por lotes de Java, otro con alguna instancia de Redis, otro con una aplicación de nodejs, otro con un microservicio de Flogo (Nota: ¿Aún no has oído hablar de Flogo? Tómate unos minutos para conocer una de las próximas novedades que puedes usar ahora para construir tus aplicaciones nativas en la nube), otro con una base de datos Oracle, otro con algún servidor web jetty y finalmente otro con una aplicación de BusinessWorks Container Edition. ¿Cómo puedes saber que cada componente está funcionando bien?
Primero, puedes pensar que puedes hacerlo con el componente de punto de entrada de tu Dockerfile ya que solo especificas un comando para ejecutar dentro de cada contenedor, así que verifica si ese proceso está en ejecución, ¿y eso significa que todo está saludable? Ok… bastante justo…
Pero, ¿esto es siempre cierto? ¿Un proceso en ejecución a nivel de SO/contenedor significa que todo está funcionando bien? Pensemos en la base de datos Oracle por un minuto, imagina que tienes un problema con la memoria compartida y se mantiene en un estado de inicialización para siempre, K8S va a verificar el comando, va a encontrar que está en ejecución y le dice a todo el clúster: ¡Ok! ¡No te preocupes! La base de datos está funcionando perfectamente, ¡adelante y envía tus consultas a ella!
Esto podría suceder con componentes similares como un servidor web o incluso con una aplicación en sí, pero es muy común cuando tienes servidores que pueden manejar implementaciones en él, como BusinessWorks Container Edition en sí. Y por eso esto es muy importante para nosotros como desarrolladores e incluso más importante para nosotros como administradores. ¡Así que empecemos!
Lo primero que vamos a hacer es construir una aplicación de BusinessWorks Container Edition, como este no es el propósito principal de este artículo, vamos a usar las mismas que he creado para la Integración de BusinessWorks Container Edition — Istio que puedes encontrar aquí.
Entonces, esta es una aplicación bastante simple que expone un servicio web SOAP. Todas las aplicaciones en BusinessWorks Container Edition (así como en BusinessWorks Enterprise Edition) tienen su propio estado, por lo que puedes preguntarles si están en ejecución o no, eso es algo que el “motor” interno de BusinessWorks Container (NOTA: Vamos a usar la palabra motor para simplificar cuando hablamos de los internos de BWCE. En detalle, el componente que conoce el estado de la aplicación es el AppNode interno que inicia el contenedor, pero mantengámoslo simple por ahora)
Sondas de Kubernetes
En Kubernetes, existe el concepto de “sonda” para realizar verificaciones de salud a tu contenedor. Esto se realiza configurando sondas de vivacidad o sondas de preparación.
- Sonda de vivacidad: Kubernetes utiliza sondas de vivacidad para saber cuándo reiniciar un contenedor. Por ejemplo, las sondas de vivacidad podrían detectar un bloqueo, donde una aplicación está en ejecución, pero no puede avanzar.
- Sonda de preparación: Kubernetes utiliza sondas de preparación para saber cuándo un contenedor está listo para comenzar a aceptar tráfico. Un pod se considera listo cuando todos sus contenedores están listos. Un uso de esta señal es controlar qué pods se utilizan como backends para los servicios. Cuando un pod no está listo, se elimina del balance de carga del servicio
Incluso cuando hay dos tipos de sondas para BusinessWorks Container Edition, ambas se manejan de la misma manera, la idea es la siguiente: Mientras la aplicación esté en ejecución, puedes comenzar a enviar tráfico y cuando no esté en ejecución necesitamos reiniciar el contenedor, por lo que eso lo hace más simple para nosotros.
Implementación de Sondas
Cada aplicación de BusinessWorks Container Edition que se inicia tiene una forma predeterminada de saber si está saludable o no. Esto se hace mediante un endpoint especial publicado por el propio motor:
Entonces, si tenemos una aplicación normal de BusinessWorks Container Edition desplegada en nuestro clúster de Kubernetes como la que teníamos para la integración de Istio, tenemos registros similares a estos:
Como puedes ver, los registros dicen que la aplicación está iniciada. Entonces, como no podemos lanzar una solicitud curl desde dentro del contenedor (ya que no hemos expuesto el puerto 7777 al exterior aún y curl no está instalado en la imagen base), lo primero que vamos a hacer es exponerlo al resto del clúster.
Para hacer eso, cambiamos nuestro archivo Deployment.yml que hemos usado a este:
Ahora, podemos ir a cualquier contenedor en el clúster que tenga “curl” instalado o cualquier otra forma de lanzar una solicitud como esta con el código HTTP 200 y el mensaje “La aplicación está en ejecución”.
NOTA: Si olvidas la última / e intentas invocar _ping en lugar de _ping/ vas a obtener un código HTTP 302 Found con la ubicación final como puedes ver aquí:
Ok, veamos qué pasa si ahora detenemos la aplicación. Para hacer eso vamos a entrar en el contenedor y usar la consola OSGi.
Para hacer eso, una vez que estés dentro del contenedor, ejecutas el siguiente comando:
ssh -p 1122 equinox@localhost
Va a pedir credenciales y usa la contraseña predeterminada ‘equinox’. Después de eso, te dará la oportunidad de crear un nuevo usuario y puedes usar las credenciales que te funcionen. En mi ejemplo, voy a usar admin / adminadmin (NOTA: La longitud mínima para una contraseña es de ocho (8) caracteres.
Y ahora, estamos dentro. Y esto nos permite la opción de ejecutar varios comandos, como este no es el tema principal de hoy voy a omitir toda la explicación, pero puedes echar un vistazo a este enlace con toda la información sobre esta consola.
Si ejecutamos frwk:la va a mostrar las aplicaciones desplegadas, en nuestro caso la única, como debería ser en la aplicación de BusinessWorks Container Edition:
Para detenerla, vamos a ejecutar el siguiente comando para listar todos los paquetes OSGi que tenemos en este momento en ejecución en el sistema:
frwk:lb
Ahora, encontramos los paquetes que pertenecen a nuestra aplicación (al menos dos paquetes (1 por módulo BW y otro para la aplicación)
Y ahora podemos detenerlo usando felix:stop <ID>, así que en mi caso, necesito ejecutar los siguientes comandos:
stop “603”
stop “604”
Y ahora la aplicación está detenida
Entonces, si ahora intentamos lanzar el mismo comando curl que ejecutamos antes, obtenemos la siguiente salida:
Como puedes ver, un error HTTP 500 que significa que algo no está bien. Si ahora intentamos iniciar nuevamente la aplicación usando el comando de inicio de paquete (equivalente al comando de detención de paquete que usamos antes) para ambos paquetes de la aplicación, verás que la aplicación dice que está en ejecución nuevamente:
Y el comando tiene la salida HTTP 200 como debería tener y el mensaje “La aplicación está en ejecución”
Entonces, ahora, después de saber cómo funciona el endpoint _ping/ solo necesitamos agregarlo a nuestro archivo deployment.yml de Kubernetes. Así que modificamos nuevamente nuestro archivo de implementación para que sea algo como esto:
NOTA: Es bastante importante la presencia del parámetro initialDelaySeconds para asegurarse de que la aplicación tenga la opción de iniciarse antes de comenzar a ejecutar la sonda. En caso de que no pongas este valor, puedes obtener un bucle de reinicio en tu contenedor.
NOTA: El ejemplo muestra el puerto 7777 como un puerto exportado, pero esto solo es necesario para los pasos que hemos hecho antes y no será necesario en un entorno de producción real.
Así que ahora desplegamos nuevamente el archivo YML y una vez que tengamos la aplicación en ejecución, vamos a intentar el mismo enfoque, pero ahora como tenemos las sondas definidas tan pronto como detenga la aplicación, los contenedores se reiniciarán. ¡Veamos!
Como puedes ver en la imagen de arriba, después de que la aplicación se detiene, el contenedor se ha reiniciado y debido a eso, hemos sido expulsados de dentro del contenedor.
Así que eso es todo, espero que te ayude a configurar tus sondas y en caso de que necesites más detalles, por favor echa un vistazo a la documentación de Kubernetes sobre sondas httpGet para ver toda la configuración y opciones que puedes aplicarles.