kubectl apply vs set: Elegir el Comando Correcto para las Actualizaciones de Recursos

Kubernetes, la plataforma líder de orquestación de contenedores, proporciona herramientas potentes para gestionar el ciclo de vida de las aplicaciones. Un aspecto central de esta gestión implica la actualización de recursos existentes como Deployments, Services o ConfigMaps. Si bien kubectl ofrece varios comandos para este propósito, kubectl apply y la familia kubectl set/kubectl edit representan dos filosofías fundamentalmente diferentes: actualizaciones declarativas vs. imperativas.

Comprender cuándo y cómo usar cada enfoque es crucial para mantener despliegues de Kubernetes estables, fiables y auditables. El uso incorrecto de estos comandos puede llevar a la deriva de configuración, depuración difícil e inconsistencias operativas. Este artículo profundizará en los matices de kubectl apply, kubectl set y kubectl edit, equipándolo con el conocimiento para tomar decisiones informadas para sus estrategias de actualización de recursos.

El Desafío Principal: Gestionar el Estado de los Recursos

En Kubernetes, cada componente —desde un Pod en ejecución hasta un Service de red— se representa como un objeto de API. Estos objetos tienen un estado deseado, que usted define en archivos de manifiesto YAML o JSON, y un estado observado, que refleja su realidad actual dentro del clúster. El objetivo principal de cualquier comando de actualización de kubectl es conciliar estos dos estados, pero el método de conciliación varía significativamente.

Entendiendo kubectl apply: El Enfoque Declarativo

kubectl apply es la piedra angular de la gestión declarativa de recursos en Kubernetes. Con este enfoque, usted define el estado deseado de sus recursos en un archivo de configuración local (o directorio de archivos) y luego le indica a Kubernetes que haga que el estado del clúster coincida con esa definición.

Cómo funciona kubectl apply (Fusión a Tres Bandas)

Cuando ejecuta kubectl apply -f your-manifest.yaml, Kubernetes realiza una sofisticada fusión a tres bandas:

1. Última Configuración Aplicada: El estado del recurso tal como fue aplicado por última vez usando kubectl apply. Este estado se almacena en una anotación (kubectl.kubernetes.io/last-applied-configuration) en el objeto activo.
2. Configuración en Vivo: El estado actual del recurso en el servidor API de Kubernetes.
3. Nueva Configuración: El estado definido en su archivo your-manifest.yaml.

El algoritmo de fusión compara estas tres versiones para determinar qué cambios deben realizarse. Maneja los conflictos de forma inteligente, priorizando los cambios de la nueva configuración mientras respeta los campos que han sido modificados imperativamente desde la última aplicación (aunque esto puede generar problemas, como se discutirá más adelante).

Este proceso garantiza la idempotencia: aplicar el mismo manifiesto varias veces resultará en el mismo estado del clúster sin efectos secundarios no deseados, siempre que no se hayan producido otros cambios.

Ejemplo Práctico: Aplicando un Deployment

Supongamos que tiene un archivo deployment.yaml:

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-webapp
  labels:
    app: my-webapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-webapp
  template:
    metadata:
      labels:
        app: my-webapp
    spec:
      containers:
      - name: webapp-container
        image: nginx:1.21.0
        ports:
        - containerPort: 80

Para crear o actualizar este despliegue, ejecutaría:

kubectl apply -f deployment.yaml

Si luego cambia la image a nginx:1.22.0 en deployment.yaml y vuelve a ejecutar kubectl apply, Kubernetes actualizará el Deployment para usar la nueva imagen mientras conserva otras configuraciones.

Beneficios de kubectl apply

• Fuente de Verdad: Sus archivos de configuración se convierten en la única fuente de verdad para el estado deseado de su clúster. Esto se alinea bien con los principios de GitOps.
• Auditabilidad y Control de Versiones: Los cambios se rastrean en su sistema de control de versiones (por ejemplo, Git), proporcionando un rastro de auditoría claro y reversiones sencillas.
• Consistencia: Asegura la consistencia entre entornos (desarrollo, preproducción, producción).
• Idempotencia: Las operaciones apply repetidas tienen el mismo efecto, previniendo modificaciones no intencionadas.
• Actualizaciones Complejas: Maneja actualizaciones complejas que involucran múltiples tipos de recursos o cambios significativos en muchos campos.

Cuándo usar kubectl apply

• Método principal para toda creación y actualización de recursos.
• Al desplegar aplicaciones a través de pipelines de CI/CD.
• Para gestionar la infraestructura como código.
• Al trabajar en equipos para asegurar configuraciones consistentes.

Consejos y Advertencias para kubectl apply

• Mantenga siempre sus archivos de manifiesto actualizados con el estado deseado. Cualquier cambio realizado con kubectl set o kubectl edit que no se refleje en sus archivos de manifiesto será sobrescrito o causará conflictos de fusión en la siguiente operación apply.
• Gestores de Campo: Kubernetes 1.16+ introdujo Server-Side Apply (SSA), que rastrea el "gestor de campo" (por ejemplo, kubectl, un controlador) responsable de cada campo en un recurso. Esto ayuda a prevenir conflictos cuando múltiples fuentes modifican el mismo recurso. Si bien es potente, tenga en cuenta cómo las diferentes herramientas podrían interactuar con la gestión de campos.

Entendiendo kubectl set y kubectl edit: El Enfoque Imperativo

kubectl set y kubectl edit pertenecen a la familia de comandos imperativos. En lugar de definir el estado deseado en un archivo, usted instruye directamente a Kubernetes para que realice acciones específicas o modifique objetos activos dentro del clúster. Estos comandos son excelentes para cambios rápidos y ad-hoc, pero vienen con ciertas advertencias.

kubectl set: Modificaciones Imperativas Enfocadas

kubectl set está diseñado para realizar modificaciones específicas y comunes en los recursos sin necesidad de tocar un archivo de manifiesto. Ofrece varios subcomandos para modificar campos particulares.

Cómo funciona kubectl set

kubectl set modifica directamente el objeto activo en el servidor API de Kubernetes basándose en los argumentos de línea de comandos que usted proporciona. No interactúa con los archivos de manifiesto locales ni actualiza la anotación last-applied-configuration.

Ejemplo Práctico: Estableciendo una Imagen

Para actualizar la imagen de un contenedor dentro de un despliegue llamado my-webapp:

kubeclt set image deployment/my-webapp webapp-container=nginx:1.22.0

Este comando modifica directamente el campo image para el webapp-container dentro del Deployment my-webapp. Si previamente había gestionado my-webapp con kubectl apply, este cambio crearía una "deriva" entre su deployment.yaml local y el estado del clúster en vivo.

Otros comandos kubectl set comunes:

• kubectl set resources: Para establecer solicitudes/límites de recursos.
• kubectl set env: Para agregar o actualizar variables de entorno.
• kubectl set selector: Para modificar el selector de un recurso.

kubectl edit: Modificaciones Imperativas Interactivas

kubectl edit le permite modificar directamente cualquier campo de un objeto de recurso activo en su clúster utilizando su editor de texto predeterminado configurado (por ejemplo, vi, nano).

Cómo funciona kubectl edit

Cuando ejecuta kubectl edit <tipo-de-recurso>/<nombre-de-recurso>:

1. kubectl recupera la definición YAML actual del recurso activo del servidor API.
2. Abre esta definición en su editor de texto local.
3. Usted realiza los cambios deseados y guarda el archivo.
4. kubectl luego envía la definición modificada de vuelta al servidor API, que intenta aplicar los cambios. Si hay errores de sintaxis o campos no válidos, los cambios serán rechazados.

Al igual que kubectl set, kubectl edit también opera directamente sobre el objeto activo y no actualiza los archivos de manifiesto locales ni la anotación last-applied-configuration.

Ejemplo Práctico: Editando un Deployment

Para abrir el despliegue my-webapp en su editor:

kubeclt edit deployment/my-webapp

Su editor se abrirá con una representación YAML del despliegue en vivo. Luego puede cambiar campos como replicas, image o agregar nuevas anotaciones/etiquetas. Una vez que guarde y cierre el editor, kubectl intentará aplicar esos cambios.

Beneficios de kubectl set y kubectl edit

• Velocidad: Excelente para arreglos rápidos y puntuales o depuración en un entorno de desarrollo.
• Flexibilidad: Modifique directamente cualquier campo de un recurso (con edit).
• Cambios Ad-hoc: Útil cuando no tiene un archivo de manifiesto disponible o no desea crear uno para un cambio trivial.

Cuándo usar kubectl set/kubectl edit

• Depuración en un clúster de desarrollo: Aumentar temporalmente el número de réplicas o cambiar una imagen para probar una solución.
• Cambios pequeños, no críticos y temporales en entornos que no son de producción.
• Explorar definiciones de recursos: kubectl edit es una forma conveniente de ver el YAML completo y en vivo de un recurso.

Advertencias para kubectl set y kubectl edit

• Deriva de Configuración: Los cambios realizados con set o edit no se reflejan en sus archivos de manifiesto locales. La próxima operación kubectl apply desde su manifiesto sobrescribirá estos cambios imperativos o causará conflictos.
• Falta de Auditabilidad: Estos cambios no se rastrean en el control de versiones, lo que dificulta saber quién cambió qué y cuándo, obstaculizando la depuración y el cumplimiento.
• No Idempotente: Realizar el mismo cambio imperativo repetidamente puede llevar a un comportamiento inesperado si se desconoce el estado inicial.
• Riesgo de Errores: La edición manual (especialmente con edit) aumenta la probabilidad de introducir errores de sintaxis o configuraciones no válidas.

Diferencias Clave: kubectl apply vs. kubectl set/kubectl edit

Para resumir las distinciones principales:

Característica	kubectl apply (Declarativo)	kubectl set/kubectl edit (Imperativo)
Enfoque	Define el estado deseado en el archivo, Kubernetes concilia.	Manipula directamente objetos activos o campos específicos.
Fuente de Verdad	Archivos de configuración local (por ejemplo, repositorio Git).	El propio objeto activo del clúster (efímero).
Idempotencia	Sí, aplicar el mismo archivo produce el mismo resultado.	No, no inherentemente. Cada comando es una acción explícita.
Auditabilidad	Alta (cambios rastreados en Git, last-applied-configuration).	Baja (sin control de versiones, los cambios son inmediatos en el clúster).
Gestión de Conflictos	Fusión a 3 bandas, utiliza la anotación last-applied-configuration.	Sobreescribe directamente (para set) o fusiona interactivamente (para edit).
Caso de Uso	Despliegues de producción, CI/CD, GitOps, colaboración en equipo.	Correcciones rápidas, depuración, cambios ad-hoc en entornos que no son de producción.
Riesgo de Deriva	Bajo, siempre que los archivos se mantengan actualizados.	Alto, muy probable que cause una deriva de configuración con respecto a los archivos fuente.

Elegir el Comando Correcto: Mejores Prácticas

Para entornos de producción y equipos colaborativos, la elección es clara:

• Prefiera siempre kubectl apply (o herramientas GitOps basadas en él como Argo CD o Flux CD) para gestionar sus recursos de Kubernetes. Esto asegura que el estado de su clúster esté versionado, sea auditable y consistente.
• Trate sus archivos de manifiesto de Kubernetes como su única fuente de verdad. Todos los cambios en las configuraciones de los recursos deben originarse idealmente en estos archivos y ser confirmados al control de versiones.

Los comandos imperativos como kubectl set y kubectl edit deben reservarse para:

• Depuración o pruebas temporales en clústeres de desarrollo/preproducción. Si los utiliza, asegúrese de revertir el cambio o actualizar inmediatamente sus archivos de manifiesto fuente para reflejar el nuevo estado.
• Operaciones puntuales y efímeras que no representen un estado deseado a largo plazo (por ejemplo, pausar un despliegue por un breve momento).

Enfoque Híbrido (Usar con Precaución)

En algunos escenarios, es posible que necesite aplicar rápidamente una solución temporal en producción. Aunque generalmente se desaconseja, si debe usar kubectl edit:

1. Comprenda las implicaciones de la deriva de configuración.
2. Capture inmediatamente los cambios haciendo kubectl get <recurso> -o yaml > nuevo-manifiesto.yaml.
3. Integre esos cambios de nuevo en sus archivos de manifiesto versionados lo más rápido posible.

Advertencia: Usar regularmente kubectl edit o kubectl set en producción sin actualizar sus manifiestos fuente conducirá a un estado del clúster inmanejable e irrecuperable donde la configuración real diverge enormemente de lo que su equipo cree que debería ser.

Conclusión

kubectl apply, kubectl set y kubectl edit son herramientas potentes para interactuar con su clúster de Kubernetes. Sin embargo, sirven para diferentes propósitos y encarnan filosofías distintas de gestión de recursos. Al comprender la naturaleza declarativa de kubectl apply y la naturaleza imperativa de kubectl set y kubectl edit, puede adoptar las mejores prácticas que conducen a despliegues de Kubernetes más estables, fiables y mantenibles.

Para casi toda la gestión persistente de recursos, especialmente en producción, adopte kubectl apply y controle las versiones de sus archivos de configuración. Reserve los comandos imperativos para la resolución de problemas temporales y ad-hoc, y asegúrese de que cualquier cambio crítico se refleje rápidamente en sus manifiestos declarativos. Esta disciplina será invaluable para operaciones fluidas y una colaboración sin interrupciones dentro de su entorno Kubernetes.