Miguel Avella
Me gustan los ejemplos sencillos, poder ejecutar los comandos y ver los resultados sin complicaciones. Eso me ayuda a hacer pruebas en el entorno de Minikube sin errores.
Cuando empiezas a trabajar con Kubernetes, descubres que existen dos formas de comunicarte con el clúster: el enfoque imperativo y el enfoque declarativo. Aprender ambos te permite movernos con agilidad en pruebas rápidas y, al mismo tiempo, mantener entornos productivos confiables y versionables.
¿Qué es el enfoque imperativo en Kubernetes?
El enfoque imperativo consiste en darle a Kubernetes una instrucción clara, concisa y directa para que ejecute una acción puntual sobre un recurso.
Un ejemplo típico es crear un pod con una sola línea en la terminal usando kubectl. Cuando ejecutas kubectl run my-pod --image=nginx, el clúster recibe la orden y crea el pod inmediatamente, sin más detalles que el nombre y la imagen del contenedor.
¿Cómo crear, listar y eliminar un pod de forma imperativa?
El flujo imperativo se entiende mejor con tres comandos básicos que conviene memorizar.
kubectl run my-pod --image=nginx crea el pod usando la imagen de nginx.kubectl get pods lista los pods activos y muestra estado, reinicios y tiempo de ejecución.kubectl delete pod my-pod elimina el pod indicando explícitamente el tipo de recurso.Este flujo es ideal para debuggear o validar el comportamiento de un pod específico en cuestión de segundos.
¿Cuándo conviene usar el enfoque imperativo? Cuando necesitas hacer pruebas efímeras, depurar un recurso o validar rápidamente que un objeto se comporta como esperas dentro del clúster.
¿Qué es el enfoque declarativo y cómo se usa con archivos YAML?
El enfoque declarativo no le dice a Kubernetes qué hacer paso a paso, sino que le describe el estado deseado de la aplicación a través de un archivo YAML. Kubernetes se encarga de interpretar ese archivo y de llevar el clúster a ese estado.
Un archivo my-pod.yaml típico incluye tres bloques: el tipo de objeto (en este caso Pod), la metadata con el nombre del recurso y la especificación de los contenedores con su imagen, por ejemplo nginx.
¿Cómo aplicar y eliminar recursos con kubectl apply?
Para llevar a la práctica el archivo YAML, basta con dos comandos que reemplazan al flujo imperativo.
kubectl apply -f my-pod.yaml crea el recurso descrito en el archivo. La bandera -f apunta al archivo o a la carpeta donde están los manifiestos.kubectl delete -f my-pod.yaml elimina el recurso sin que tengas que especificar su tipo, porque Kubernetes lo lee desde el manifiesto.Esta diferencia es clave: en imperativo nombras el recurso (delete pod my-pod), mientras que en declarativo el archivo es la fuente de verdad.
¿Qué es un archivo YAML en Kubernetes? Es un manifiesto de texto plano donde describes el estado deseado de tus objetos: tipo, metadata y especificaciones como imagen, réplicas o recursos asignados.
¿Cuál es la diferencia entre imperativo y declarativo en Kubernetes?
Una analogía musical lo deja claro. El enfoque imperativo es como pedirle a un músico: "interpreta Para Elisa de Beethoven". El declarativo, en cambio, es entregarle la partitura completa: la persona que la lea puede traducirla, y Kubernetes interpretará el estado deseado para gestionar todos los elementos hasta lograr el resultado final.
¿Cuáles son las ventajas y desventajas de cada enfoque?
Cada modo tiene un terreno donde brilla y otro donde se queda corto.
La buena noticia es que YAML no solo se usa en Kubernetes. También aparece en herramientas como GitHub Actions y Jenkins, así que dominarlo te sirve en todo el entorno DevOps y cloud.
¿Cuándo usar uno u otro en proyectos reales?
La decisión depende del contexto y del ciclo de vida de tu aplicación.
Las aplicaciones reales rara vez se reducen a un solo pod. Por eso el siguiente paso natural son los deployments y los replicaSets, objetos que permiten orquestar múltiples pods y combinar estos dos enfoques en escenarios productivos.
¿Probaste a crear un pod con dos contenedores de imágenes distintas usando ambos enfoques? Cuéntame en los comentarios qué diferencias notaste al escribir el comando frente al manifiesto YAML.
veo con preocupación esto ya que si una persona desea aprender Kubernet es por que ya paso el curso de docker básico por lo menos y comprende el funcionamiento de los sistema contenerizados y uy seguramente por practicidad ya conoce docker compose que esto le facilita mas entender un sistema de orquestamiento pero solo veo comnados pare un curso mas de minikube que de kubernet ya que el curso básico si hay comandos pero en realidad lo importante son los pipilines que son la base del orquestamiento y los mas importante que este sistema funciona como un CDK donde también puedo programar mi orquestamieto que es eso de que haba como en el capitulo 2 o 3 que es lo que te permita validar comportamientos de tu orquestamiento y si cumplen con los requisitos básicos de arranque, que es lo mágico de kubenet y pues también las trasversalidad de sistemas hasta hora solo habla de pods y pues eso esta fuera de contesto ya que en la documentación oficial esto es la explicación de el maping nuclear de los servicios o contenedores y esto ni siquiera es la mínima parte de un servicio por que en mi caso me gusta muchas veces tener imágenes propias por temas de control y versatilidad en la gestión y administración de lo que se necesita desplegar ejemplo necesito un front con node js pero si despliego la imagen defaul va a usar el ios de alpine y después le mando comando de debían o Ubuntu por eso yo creo mis imágenes para controlar sistema y servicios, todo esto no lo veo en ningún lado y esto es básico tenerlo presente ya los temas de arquitectura de servicios es al final cuando ya sepa como manjar kubernet comprenda que es un orquestador y para que se usa y por que es importante de lo contrario todo esto es perdido.
Miguel Avella
Me gustan los ejemplos sencillos, poder ejecutar los comandos y ver los resultados sin complicaciones. Eso me ayuda a hacer pruebas en el entorno de Minikube sin errores.
Santiago Gómez
Desde una perspectiva más general, un paradigma imperativo es un estilo de programación en el cual los desarrolladores definen el flujo de control (serie ordenada de instrucciones) necesario para completar una tarea. Por ejemplo, si se quiere ejecutar y, posteriormente, eliminar un Pod, entonces primero se le indica a Kubernetes que debe ejecutar el Pod y luego eliminarlo:
kubectl run mypod --image nginxkubectl delete pod mypodPor otro lado, un paradigma declarativo es un estilo de programación en el cual los desarrolladores expresan la lógica de una computación (Un cálculo bien definido) sin especificar el flujo de control. Por ejemplo, en el archivo mypod.yaml se le indica a Kubernetes que se necesita crear un contenedor a partir de la imagen de nginx que se debe llamar nginx. Sin embargo, las instrucciones específicas (flujo de control) para obtener este resultado no se están definiendo.
Miguel Angel Reyes Moreno
Si queremos hacer 1 pod con 2 diferentes imágenes, de forma imperativa sería más difícil porque hay que hacerlo todo más 'manual' con comandos en la terminal, uno por uno.
Pero de forma declarativa sería más sencillo, porque todo lo podemos declarar en un archivo yaml y con eso lo ejecutamos con solo 1 comando.
Ejemplo, creamos un archivo yaml:
apiVersion: v1 kind: Pod metadata:   name: multi-pod   labels:   app: multi-pod spec:   containers:   \- name: web   image: nginx:1.27   ports:   \- containerPort: 80   \- name: sidecar   image: busybox:1.36   command: \["sh", "-c", "while true; do echo hello from sidecar; sleep 10; done"]
Y ejecutamos:
kubectl apply -f two-containers.yaml
kubectl get pod multi-pod # READY should show 2/2
kubectl describe pod multi-pod
kubectl delete -f two-containers.yaml
Steven Sanchez
La diferencia entre utilizar Kubernetes de forma imperativa o declarativa está en cómo le indicamos lo que queremos conseguir.
El enfoque imperativo consiste en ejecutar instrucciones directamente, una por una. Es especialmente útil cuando estamos aprendiendo Kubernetes, realizando pruebas específicas o identificando problemas y comportamientos.
En cambio, el enfoque declarativo nos permite definir mediante archivos YAML (.yaml) cómo queremos que funcione nuestra aplicación. Kubernetes se encarga de alcanzar y mantener ese estado, sin necesidad de ejecutar constantemente las mismas instrucciones.
Además, facilita los despliegues, el mantenimiento y la comprensión de la arquitectura del proyecto, ya que toda la configuración queda documentada y puede modificarse o reutilizarse.
Es como construir un edificio: en el enfoque imperativo, le indicamos a los trabajadores qué hacer paso a paso; mientras que en el declarativo, entregamos los planos al arquitecto, donde ya está definido el resultado esperado, y su equipo se encarga de llevarlo a cabo.
Adrianh De Lucio Chavero
Cool
Jorge Lopez
Según voy entendiendo, la forma declarativa se hace a través de un archivo YAML, en el cual se configura todo el pod y se definen los contenedores que van dentro del pod, pero de la forma imperativa, no es como ejecutar una secuencia de pasos: primero creo el pod, luego agrego el primer contenedor, luego el segundo contenedor; esto no se puede porque, según la teoría, una vez que se crea el pod y sus contenedores, este se vuelve inmutable, lo que da a entender que apenas se cree el primer contenedor ya no se puede modificar.
Marlon Alberto Melendez Tejada
Los archivos YAML, con relacion a Docker, Kubernetes, Jenkins, GitHub Actions, etc. Es el mismo YAML en cuanto a sintaxis base, pero cada herramienta define su propio "vocabulario" o "estructura" (Schema). La indentación, los guiones para listas, los dos puntos para claves, etc. Eso es universal para las distintas herramientas, pero cada herramienta tiene particularidades con relacion a sus archivos YAML. Una referencia para aprender lo basico de YAML es:
Ruben Dario Hernandez Centeno
Para aprender este curso me compré mis propios mini pcs y empecé a crear mi cluster OnPremise, usando Talos Linux instalando todo "Bare Metal", creo que es la mejor decisión que he tomado, puedo entender mejor como funciona la afinidad de los pods entre otras cosas en Kubernetes.