Alexandre Vazquez

Descubre cómo los Init Containers pueden proporcionar capacidades adicionales a tus cargas de trabajo en Kubernetes

Hay muchos nuevos desafíos que vienen con el nuevo patrón de desarrollo de una manera mucho más distribuida y colaborativa, y cómo gestionamos las dependencias es crucial para nuestro éxito.

Kubernetes y las distribuciones dedicadas se han convertido en el nuevo estándar de implementación para nuestra aplicación nativa de la nube y proporcionan muchas características para gestionar esas dependencias. Pero, por supuesto, el recurso más habitual que utilizarás para hacer eso son las sondas.

Kubernetes proporciona diferentes tipos de sondas que permitirán a la plataforma conocer el estado de tu aplicación. Nos ayudará a saber si nuestra aplicación está «viva» (sonda de vivacidad), ha sido iniciada (sonda de inicio) y si está lista para procesar solicitudes (sonda de preparación).

Las sondas de Kubernetes son la forma estándar de hacerlo, y si has implementado alguna carga de trabajo en un clúster de Kubernetes, probablemente hayas usado una. Pero hay ocasiones en las que esto no es suficiente.

Eso puede ser porque la sonda que te gustaría hacer es demasiado compleja o porque te gustaría crear algún orden de inicio entre tus componentes. Y en esos casos, confías en otra herramienta: los Init Containers.

Los Init Containers son otro tipo de contenedor en el que tienen su propia imagen que puede tener cualquier herramienta que puedas necesitar para establecer los diferentes chequeos o sondas que te gustaría realizar.

Tienen las siguientes características únicas:

• Los init containers siempre se ejecutan hasta completarse.
• Cada init container debe completarse con éxito antes de que comience el siguiente.

¿Por qué usarías init containers?

#1 .- Gestionar Dependencias

El primer caso de uso para utilizar init containers es definir una relación de dependencias entre dos componentes como Deployments, y necesitas que uno comience antes que el otro. Imagina la siguiente situación:

Tenemos dos componentes: una aplicación web y una base de datos; ambos se gestionan como contenedores en la plataforma. Así que si los implementas de la manera habitual, ambos intentarán comenzar simultáneamente, o el programador de Kubernetes definirá el orden, por lo que podría ser posible que la aplicación web intente comenzar cuando la base de datos no esté disponible.

Podrías pensar que eso no es un problema porque para eso tienes una sonda de preparación o de vivacidad en tus contenedores, y tienes razón: el Pod no estará listo hasta que la base de datos esté lista, pero hay varias cosas a tener en cuenta aquí:

• Ambas sondas tienen un límite de intentos; después de eso, entrarás en un escenario de CrashLoopBack, y el pod no intentará comenzar de nuevo hasta que lo reinicies manualmente.
• El pod de la aplicación web consumirá más recursos de los necesarios cuando sabes que la aplicación no comenzará en absoluto. Así que, al final, estás desperdiciando recursos en el proceso.

Por lo tanto, definir un init container como parte de la implementación de la aplicación web que verifique si la base de datos está disponible, tal vez solo incluyendo un cliente de base de datos para ver rápidamente si la base de datos y todas las tablas están adecuadamente pobladas, será suficiente para resolver ambas situaciones.

#2 .- Optimización de recursos

Una cosa crítica cuando defines tus contenedores es asegurarte de que tienen todo lo que necesitan para realizar su tarea y que no tienen nada que no sea necesario para ese propósito.

Así que en lugar de agregar más herramientas para verificar el comportamiento del componente, especialmente si esto es algo para gestionar en momentos específicos, puedes descargar eso a un init container y mantener el contenedor principal más optimizado en términos de tamaño y recursos utilizados.

#3.- Precarga de datos

A veces necesitas realizar algunas actividades al inicio de tu aplicación, y puedes separar eso del trabajo habitual de tu aplicación, por lo que te gustaría evitar el tipo de lógica para verificar si el componente ha sido inicializado o no.

Usando este patrón, tendrás un init container gestionando todo el trabajo de inicialización y asegurando que todo el trabajo de inicialización se haya realizado cuando se ejecute el contenedor principal.

¿Cómo definir un Init Container?

Para poder definir un init container, necesitas usar una sección específica de la sección de especificaciones de tu archivo YAML, como se muestra en la imagen a continuación:

apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
  - name: myapp-container
image: busybox:1.28
command: ['sh', '-c', 'echo ¡La aplicación está en ejecución! && sleep 3600']
initContainers:
  - name: init-myservice
image: busybox:1.28
command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo esperando a myservice; sleep 2; done"]
  - name: init-mydb
image: busybox:1.28
command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo esperando a mydb; sleep 2; done"]

Puedes definir tantos Init Containers como necesites. Sin embargo, notarás que todos los init containers se ejecutarán en secuencia como se describe en el archivo YAML, y un init container solo puede ejecutarse si el anterior se ha completado con éxito.

Resumen

Espero que este artículo te haya proporcionado una nueva forma de definir la gestión de tus dependencias entre cargas de trabajo en Kubernetes y, al mismo tiempo, también otros grandes casos de uso donde la capacidad del init container puede aportar valor a tus cargas de trabajo.

Aprende cómo puedes usar CodeReady Containers para configurar la última versión de Openshift Local solo en tu computadora.

En este momento, todos sabemos que el modo de implementación predeterminado para cualquier aplicación que queramos lanzar será una plataforma basada en contenedores y, especialmente, será una plataforma basada en Kubernetes.

Pero ya sabemos que hay muchas variantes diferentes de distribuciones de Kubernetes, incluso escribí un artículo sobre eso que puedes encontrar aquí:

Algunas de estas distribuciones intentan seguir lo más cerca posible la experiencia de Kubernetes, pero otras están tratando de mejorar y aumentar las capacidades que la plataforma proporciona.

Debido a eso, a veces es importante tener una forma de realmente probar nuestro desarrollo en la plataforma objetivo sin esperar un modo de desarrollador basado en servidor. Sabemos que tenemos en nuestra propia laptop una plataforma basada en Kubernetes para ayudar a hacer el trabajo.

minikube es la opción más común para hacer esto y proporcionará una vista muy básica de Kubernetes, pero a veces necesitamos un tipo diferente de plataforma.

[visual-link-preview encoded=»eyJ0eXBlIjoiZXh0ZXJuYWwiLCJwb3N0IjowLCJwb3N0X2xhYmVsIjoiIiwidXJsIjoiaHR0cHM6Ly9taW5pa3ViZS5zaWdzLms4cy5pby9kb2NzLyIsImltYWdlX2lkIjowLCJpbWFnZV91cmwiOiIiLCJ0aXRsZSI6IiIsInN1bW1hcnkiOiIiLCJ0ZW1wbGF0ZSI6InVzZV9kZWZhdWx0X2Zyb21fc2V0dGluZ3MifQ==»]

Openshift de RedHat se está convirtiendo en una de las soluciones de facto para implementaciones en la nube privada y especialmente para cualquier empresa que no planea mudarse a una solución gestionada en la nube pública como EKS, GKE o AKS. En el pasado teníamos un proyecto similar a minikube conocido como minishift que permitía ejecutar en sus propias palabras:

Minishift es una herramienta que te ayuda a ejecutar OpenShift localmente ejecutando un clúster de OpenShift de un solo nodo dentro de una VM. Puedes probar OpenShift o desarrollarlo, día a día, en tu localhost.

[visual-link-preview encoded=»eyJ0eXBlIjoiZXh0ZXJuYWwiLCJwb3N0IjowLCJwb3N0X2xhYmVsIjoiIiwidXJsIjoiaHR0cHM6Ly9naXRodWIuY29tL2NvZGUtcmVhZHkvY3JjIiwiaW1hZ2VfaWQiOi0xLCJpbWFnZV91cmwiOiJodHRwczovL29wZW5ncmFwaC5naXRodWJhc3NldHMuY29tL2I4NTI3NjdhZTZiZjRmOTk3MWMyMTMxZGZmZGU2M2NkZDY3MzhhMTA0NDlhN2IwN2MxNzc4OGNjMjY0NDE0M2EvY29kZS1yZWFkeS9jcmMiLCJ0aXRsZSI6IkdpdEh1YiAtIGNvZGUtcmVhZHkvY3JjOiBSZWQgSGF0IENvZGVSZWFkeSBDb250YWluZXJzIGlzIGEgdG9vbCB0aGF0IG1hbmFnZXMgYSBsb2NhbCBPcGVuU2hpZnQgNC54IGNsdXN0ZXIgb3B0aW1pemVkIGZvciB0ZXN0aW5nIGFuZCBkZXZlbG9wbWVudCBwdXJwb3NlcyIsInN1bW1hcnkiOiJSZWQgSGF0IENvZGVSZWFkeSBDb250YWluZXJzIGlzIGEgdG9vbCB0aGF0IG1hbmFnZXMgYSBsb2NhbCBPcGVuU2hpZnQgNC54IGNsdXN0ZXIgb3B0aW1pemVkIGZvciB0ZXN0aW5nIGFuZCBkZXZlbG9wbWVudCBwdXJwb3NlcyAtIEdpdEh1YiAtIGNvZGUtcmVhZHkvY3JjOiBSZWQgSGF0IENvZGVSZWFkeSBDb250YWluZXJzIGlzIGEgdG9vbCB0aC4uLiIsInRlbXBsYXRlIjoidXNlX2RlZmF1bHRfZnJvbV9zZXR0aW5ncyJ9″]

El único problema con minishift es que solo soportan la versión 3.x de Openshift, pero estamos viendo que la mayoría de los clientes ya están actualizando a la versión 4.x, por lo que podríamos pensar que estamos un poco solos en esa tarea, ¡pero esto está lejos de la verdad!

Porque tenemos CodeReady Containers o CRC para ayudarnos en esa tarea.

[visual-link-preview encoded=»eyJ0eXBlIjoiZXh0ZXJuYWwiLCJwb3N0IjowLCJwb3N0X2xhYmVsIjoiIiwidXJsIjoiaHR0cHM6Ly9naXRodWIuY29tL2NvZGUtcmVhZHkvY3JjIiwiaW1hZ2VfaWQiOi0xLCJpbWFnZV91cmwiOiJodHRwczovL29wZW5ncmFwaC5naXRodWJhc3NldHMuY29tL2I4NTI3NjdhZTZiZjRmOTk3MWMyMTMxZGZmZGU2M2NkZDY3MzhhMTA0NDlhN2IwN2MxNzc4OGNjMjY0NDE0M2EvY29kZS1yZWFkeS9jcmMiLCJ0aXRsZSI6IkdpdEh1YiAtIGNvZGUtcmVhZHkvY3JjOiBSZWQgSGF0IENvZGVSZWFkeSBDb250YWluZXJzIGlzIGEgdG9vbCB0aGF0IG1hbmFnZXMgYSBsb2NhbCBPcGVuU2hpZnQgNC54IGNsdXN0ZXIgb3B0aW1pemVkIGZvciB0ZXN0aW5nIGFuZCBkZXZlbG9wbWVudCBwdXJwb3NlcyIsInN1bW1hcnkiOiJSZWQgSGF0IENvZGVSZWFkeSBDb250YWluZXJzIGlzIGEgdG9vbCB0aGF0IG1hbmFnZXMgYSBsb2NhbCBPcGVuU2hpZnQgNC54IGNsdXN0ZXIgb3B0aW1pemVkIGZvciB0ZXN0aW5nIGFuZCBkZXZlbG9wbWVudCBwdXJwb3NlcyAtIEdpdEh1YiAtIGNvZGUtcmVhZHkvY3JjOiBSZWQgSGF0IENvZGVSZWFkeSBDb250YWluZXJzIGlzIGEgdG9vbCB0aC4uLiIsInRlbXBsYXRlIjoidXNlX2RlZmF1bHRfZnJvbV9zZXR0aW5ncyJ9″]

El propósito de Code Ready Containers es proporcionarte un clúster mínimo de Openshift optimizado para propósitos de desarrollo. Su proceso de instalación es muy, muy simple.

Funciona de manera similar al modo de distribución anterior de VM y OVA, por lo que necesitarás obtener algunos binarios para poder configurar esto directamente desde Red Hat usando la siguiente dirección: https://console.redhat.com/openshift/create/local

Necesitarás crear una cuenta, pero es gratuita y en unos pocos pasos obtendrás un gran binario de aproximadamente 3–4 GB y tu código de firma para poder ejecutar la plataforma y eso es todo, en unos minutos tendrás a tu disposición una plataforma completa de Openshift lista para que la uses.

Podrás encender y apagar la plataforma usando los comandos crc start y crc stop.

Como puedes imaginar, esto solo es adecuado para el entorno local y de ninguna manera para la implementación en producción y también tiene algunas restricciones que pueden afectarte, tales como:

• El clúster de OpenShift de CodeReady Containers es efímero y no está destinado para uso en producción.
• No hay una ruta de actualización compatible a versiones más nuevas de OpenShift. Actualizar la versión de OpenShift puede causar problemas que son difíciles de reproducir.
• Utiliza un solo nodo que actúa como nodo maestro y trabajador.
• Desactiva el Operador de monitoring por defecto. Este Operador desactivado causa que la parte correspondiente de la consola web no funcione.
• La instancia de OpenShift se ejecuta en una máquina virtual. Esto puede causar otras diferencias, particularmente con la red externa.

Espero que encuentres esto útil y que puedas usarlo como parte de tu proceso de implementación.

Aprende algunos consejos sobre cómo crear tu API de manera eficiente y lidiar con el trabajo real simultáneamente.

Al crear una API para exponer una capacidad o integrar diferentes sistemas, hay principalmente dos formas de hacerlo: enfoque de Contrato-Primero o enfoque de Contrato-Último. La diferencia radica en la metodología que seguirás para crear la API.

En un enfoque de contrato-primero, la definición del contrato es el punto de partida. No importa qué lenguaje o tecnología estés utilizando. Esta realidad ha sido la misma desde el comienzo del sistema distribuido en tiempos de RMI y CORBA y continúa siendo la misma en los tiempos extraordinarios de gRPC y GraphQL.

Comienzas con la definición del contrato entre ambas partes: la que expone la capacidad y el consumidor inicial de la información. Eso implica la definición de varios aspectos de él:

• Propósito de las operaciones.
• Campos que tiene cada operación.
• Información de retorno dependiendo de cada escenario.
• Información de errores reportados, y así sucesivamente.

Después de eso, comenzarás a diseñar la API en sí y la implementación para cumplir con la definición acordada entre las partes.

Este enfoque tiene varias ventajas y desventajas, pero hoy en día es la forma más «aceptable» de desarrollar API. Como ventajas podemos comentar las siguientes:

• Reducción de Actividades de Retrabajo: Al comenzar definiendo el contrato, puedes validar rápidamente que todas las partes están de acuerdo con el contrato antes de escribir cualquier trabajo de implementación. Eso evitaría cualquier actividad de recodificación o retrabajo debido a un malentendido o simplemente adaptación de las expectativas y se volvería más eficiente.
• Separación de Funciones: También proporcionará la separación de funciones para ambas partes, el proveedor y los consumidores. Porque tan pronto como tengas el contrato, ambos equipos pueden comenzar a trabajar en eso. Incluso puedes proporcionar un simulacro para que el consumidor pruebe cualquier escenario rápidamente sin la necesidad de esperar a que se cree el servicio real.

Pero el enfoque de Contrato-Primero tiene algunos requisitos o suposiciones para tener éxito que no son muy fáciles de cumplir en un escenario del mundo real. Esta situación es esperada. Hay muchas metodologías, consejos o recomendaciones que aprendes cuando estás estudiando que no son aplicables en la vida real. Para validar ese comentario, permíteme hacerte una pregunta:

¿Creaste una API y la interfaz que creaste fue 100% la misma que tenías al final?

La respuesta a esa pregunta en mi caso es «No, nunca». Y puedes pensar que soy un mal diseñador de API, y podrías tener razón. Estoy seguro de que la mayoría de las personas que leen este artículo definirían sus contratos mucho mejor que yo, pero ese no es el punto. Porque cuando estamos en la fase de implementación, generalmente detectamos algo que no pensamos en la fase de diseño, o cuando intentamos hacer un diseño de bajo nivel, hay otros conceptos que no contemplamos en el punto que hace que otra solución sea la más adecuada para el escenario, por lo que impactarás la API, y eso tiene un costo.

Es posible que mitiges ese riesgo simplemente dedicando más tiempo a la fase de definición del contrato para asegurarte de que nada esté bien considerado o incluso crear algunos prototipos para garantizar que la API generada sea la final. Pero si haces esto, solo estás reduciendo la probabilidad de que esto suceda, nunca eliminándola, y al mismo tiempo, estás reduciendo los beneficios del enfoque.

Uno de los puntos críticos que comentamos anteriormente fue la eficiencia. Supongamos que pensamos en la eficiencia ahora cuando dedicarás más tiempo a esa fase. Eso significa que será menos eficiente. También comentamos sobre lo grandioso de hacer la separación de funciones: pero en este caso, mientras se extiende el tiempo de creación de la interfaz, también se extiende el tiempo que ambos equipos necesitan esperar hasta que puedan trabajar en sus partes.

Pero implementar el otro enfoque no proporcionará mucho beneficio. Puede llevar a un trabajo aún más costoso porque no obtendrás validación para el cliente hasta que la API esté implementada. Y nuevamente, otra pregunta:

¿Alguna vez compartiste algo con tu cliente por primera vez y no pidieron ningún cambio?

Nuevamente, la respuesta es la misma: «No, nunca». Y ese costo siempre será mayor que el que se habla del cambio en la definición, porque como sabes, el cambio es mucho más costoso cuanto más tarde lo detectes en el ciclo de desarrollo, y no es un aumento lineal. Es mucho más cercano a un aumento exponencial.

Entonces, ¿cuál es mi recomendación aquí? Sigue el enfoque de contrato-primero y acepta la vida real. Así que haz tu mejor esfuerzo para definir la API y tener un acuerdo entre las partes y si detectas algo que pueda impactar la API, notifícalo lo antes posible a las partes. Al final, esto no es más que un enfoque interactivo también para la definición de la API, y no hay nada de malo en ello.

Seamos honestos, no hay una bala de plata que proporcione el camino verde en tu trabajo diario, y eso es lo grandioso de hacerlo y por qué lo disfrutamos tanto. Porque en cada una de nuestras decisiones de trabajo, como sucede en cualquier otro aspecto de la vida, hay tantos aspectos, tantas situaciones, tantos detalles que siempre impactan la increíble y hermosa metodología que puedes ver en un artículo, un documento, una clase o un tweet.