Georgi Arnaudov - Lo que pienso sobre Kubernetes

Más que un orquestador de contenedores

26 de diciembre de 2025

A menudo se describe a Kubernetes como una herramienta de orquestación de contenedores, pero después de pasar algún tiempo con él, ese modelo mental no siempre parece la forma más útil de pensar en lo que está sucediendo.

En muchos casos, para mí, Kubernetes se parece menos a un orquestador y más a una plataforma donde declaras el estado deseado de tu infraestructura y dejas que el sistematrabaje continuamente para adaptarse a tu intención.

Por eso me gusta pensar en Kubernetes como un entorno de ejecución para infraestructura declarativa con un sistema de tipos. Permítanme explicarlo.

Sistema de tipos

Considere este manifiesto:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
    - name: nginx
      image: nginx:stable
      ports:
        - containerPort: 80

Si has pasado algún tiempo con k8s, probablemente sepas qué es. Es un recurso de tipo Pod, la unidad más pequeña que Kubernetes programa y ejecuta. Este ejecuta un contenedor nginx y declara que este escucha en el puerto 80.

Los pods no suelen vivir solos. En sistemas reales, se integran en recursos de nivel superior: un ReplicaSet para mantener N copias, un Deployment para gestionar las implementaciones adicionales, un Service para darles una identidad de red estable y un Ingress para enrutar el tráfico entre Services.

Ves cómo Kubernetes viene con todo un vocabulario de tipos de recursos que son responsables de diferentes partes de tu infraestructura y, cuanto más piensas en ello, más comienza a comportarse ese vocabulario como un sistema de tipos.

Un Pod no es solo un contenedor, ni una Implementación es solo un script que crea Pods. Cada uno es un tipo con una definición estricta y una semántica específica: qué significa, qué campos son válidos, cómo puede cambiar y con qué otros tipos se integra.

Al igual que un sistema de tipos estándar en un lenguaje de programación, excepto que en lugar de tipos como int, chary string, obtienes Pod, Deployment y Service.

Y, al igual que en un lenguaje de programación, también puedes definir tus propios tipos. Eso es lo que son los CRD: nuevos tipos de recursos que amplían la API, con operadores que implementan el significado de esos nuevos tipos.

Tradicionalmente, consideramos las cargas de trabajo como procesos o contenedores. Kubernetes aún los ejecuta, pero los abstrae al asignarle a su infraestructura un sistema de tipos.

Tiempo de ejecución

El manifiesto que mostré antes es simplemente un archivo donde se declara el estado deseado. Ahora veamos qué sucede al aplicarlo al clúster.

kubectl apply -f pod.yaml

Kubernetes no ejecuta tu YAML como un script. Lo que ocurre es que envías una declaración tipificada a un entorno de ejecución, y este trabaja continuamente para que la infraestructura se ajuste a tu intención.

• El servidor API acepta su objeto. Analiza la solicitud, verifica su validez, aplica las reglas de admisión y políticas, y lo almacena como parte del estado del clúster.
• El clúster ahora "recuerda" tu intención. Ese objeto adquiere un estado duradero. No es un comando ejecutado, sino algo que existe (hasta que lo modifiques o lo elimines).
• Los controladores se reconcilian continuamente . Observan los objetos relevantes y reaccionan a los cambios. Comparan el estado deseado (el declarado) con el estado real (el existente) y toman medidas para reducir la diferencia.
• En nuestro caso, el programador elige un nodo para colocar el Pod .
• Kubelet lo hace real en el nodo. El agente del nodo convierte la frase «debería existir un pod aquí» en «los contenedores se están ejecutando aquí».

declarar → persistir → reconciliar → colocar → ejecutar, repetir.

Lo que diferencia a Kubernetes de la orquestación es la palabra "continuamente". Kubernetes no lo intenta solo una vez. Si algo se desvía, el entorno de ejecución intenta recuperarlo.

Es por eso que las soluciones manuales a menudo no funcionan:

• Eliminar un Pod no elimina la carga de trabajo si el estado deseado aún indica que debería existir intención.
• La edición de recursos en vivo se puede revertir si un controlador posee esa intención.

No es que Kubernetes sea molesto. Es que Kubernetes hace lo que hace un entorno de ejecución: reforzar el significado de tus declaraciones.

Una vez que vea la especificación del comportamiento en tiempo de ejecución yel estadocomiencen a sentirse como entradas y salidas:

• La especificación es lo que quieres
• El estado es lo que el tiempo de ejecución observó y calculó

Esta es una forma muy práctica de depurar. Cuando algo no funciona, reviso si el entorno de ejecución avanza según la especificación y qué indica el estado sobre el motivo.

Sin embargo, los controladores de Kubernetes no se limitan a realizar bucles ciegos. Reaccionan a los cambios.

• cambias una declaración
• El tiempo de ejecución se da cuenta y converge
• quitas algo
• El tiempo de ejecución lo revierte si la especificación aún lo exige

Una vez que veas eso, GitOps encaja perfectamente en la imagen:

• Kubernetes almacena el estado deseado dentro del clúster.
• GitOps establece que el verdadero estado deseado reside en Git.
• Un controlador GitOps compara continuamente Git (deseado) vs. clúster (real) y aplica cambios hasta que coincidan.

Entonces, en este modelo, Git se convierte en su "repositorio de código fuente", el clúster, el tiempo de ejecución y el controlador GitOps es la parte que mantiene el estado del tiempo de ejecución alineado con la fuente.

Si eskubectl editalgo que administra GitOps, está cambiando el estado de ejecución, pero la fuente de verdad sigue siendo Git, por lo que el controlador de GitOps probablemente lo revertirá.

Esto no es una pelea entre herramientas, son dos reconciliaciones haciendo su trabajo:

• Kubernetes se reconcilia con los objetos API
• GitOps reconcilia los objetos de API hacia Git

Esto nos lleva a una regla general muy práctica: si algo se gestiona mediante GitOps, considera kubectl como una herramienta de depuración, no como la forma de realizar cambios.

Pensar en Kubernetes como un entorno de ejecución para una infraestructura declarativa en lugar de un mero orquestador da como resultado enfoques muy prácticos para operar su clúster.

• cambiar el estado deseado, no los síntomas
• Dejemos que la reconciliación haga el trabajo
• Hacer explícita la propiedad (especialmente con GitOps)
• Utilice el sistema de tipos (elija el tipo de recurso correcto) en lugar de inventar sus propias convenciones

How I think about Kubernetes