Alexandre Vazquez

ConfigMaps es uno de los objetos más conocidos y, al mismo tiempo, menos utilizados en el ecosistema de Kubernetes. Es uno de los objetos principales que ha estado allí desde el principio, incluso si probamos muchas otras formas de implementar una solución de Gestión de Configuración (como Consul, Spring Cloud Config y otros).

Basado en las palabras de su propia documentación:

Un ConfigMap es un objeto API utilizado para almacenar datos no confidenciales en pares clave-valor.

https://kubernetes.io/docs/concepts/configuration/configmap/

Su motivación fue proporcionar una solución nativa para la gestión de configuraciones para implementaciones nativas de la nube. Una forma de gestionar e implementar configuraciones enfocándose en un código diferente de la configuración. Ahora, todavía recuerdo los archivos WAR con el archivo application.properties dentro de él.

ConfigMap es un recurso tan simple como puedes ver en el fragmento a continuación:

apiVersion: v1
kind: ConfigMap
metadata:
  name: game-demo
data:
  player_initial_lives: "3"
  ui_properties_file_name: "user-interface.properties"

Los ConfigMaps son objetos que pertenecen a un namespace. Tienen una fuerte relación con Deployment y Pod y permiten la opción de tener diferentes entornos lógicos usando namespace donde pueden implementar la misma aplicación. Aún así, con una configuración específica, por lo que necesitarán un configMap particular para soportar eso, incluso si se basa en el mismo archivo YAML de recursos.

Desde una perspectiva técnica, el contenido del ConfigMap se almacena en la base de datos etcd como sucede con cualquier información relacionada con el entorno de Kubernetes, y debes recordar que etcd por defecto no está cifrado, por lo que todos los datos pueden ser recuperados por cualquiera que tenga acceso a él.

Propósitos de los ConfigMaps

Parámetros de Configuración

El primer y principal propósito del configMap es proporcionar parámetros de configuración a tu carga de trabajo. Una forma industrializada de eliminar la necesidad de variables de entorno es vincular la configuración del entorno desde tu aplicación.

Proporcionar Archivos Dependientes del Entorno

Otro uso significativo es proporcionar o reemplazar archivos dentro de tus contenedores que contengan el archivo de configuración crítica. Uno de los ejemplos principales que ilustra esto es proporcionar una configuración de registro para tu aplicación si tu aplicación está utilizando la biblioteca logback. En este caso, necesitas proporcionar un archivo logback.xml, para que sepa cómo aplicar tu configuración de registro.

Otras opciones pueden ser propiedades. El archivo necesita estar ubicado allí o incluso certificados de clave pública para manejar conexiones SSL solo con servidores en lista segura.

Carpetas de Solo Lectura

Otra opción es usar el ConfigMap como una carpeta de solo lectura para proporcionar una forma inmutable de vincular información al contenedor. Un caso de uso de esto puede ser los Dashboards de Grafana que estás agregando a tu pod de Grafana (si no estás usando el operador de Grafana)

Diferentes formas de crear un ConfigMap

Tienes varias formas de crear un ConfigMap usando el modo interactivo que simplifica su creación. Aquí están las que más uso:

Crear un configMap para alojar pares clave-valor con fines de configuración

kubectl create configMap name  --from-literal=key=value

Crear un configMap usando un archivo de propiedades similar a Java para poblar el ConfigMap en un par clave-valor.

 kubectl create configMap name --from-env-file=filepath

Crear un configMap usando un archivo para ser parte del contenido del ConfigMap

 kubectl create configMap name --from-file=filepath

 Ciclo de Vida de Actualización del ConfigMap

Los ConfigMaps se actualizan de la misma manera que cualquier otro objeto de Kubernetes, y puedes usar incluso los mismos comandos como kubctl apply para hacerlo. Pero debes tener cuidado porque una cosa es actualizar el ConfigMap en sí y otra cosa es que el recurso que usa este ConfigMap se actualice.

En todos los casos de uso que hemos descrito aquí, el contenido del ConfigMap depende del ciclo de vida del Pod. Eso significa que el contenido del ConfigMap se lee en el proceso de inicialización del Pod. Por lo tanto, para actualizar los datos del ConfigMap dentro del pod, necesitarás reiniciar o traer una nueva instancia del pod después de haber modificado el objeto ConfigMap en sí.

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.

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.