Lo que entendí por la documentación es que:

• crear kubectl = Crea un nuevo recurso k8s en el clúster
• kubectl replace = Actualiza un recurso en el clúster en vivo
• kubectl apply = Si quiero hacer crear + reemplazar ( Referencia )

Mis preguntas son

1. ¿Por qué hay tres operaciones para hacer la misma tarea en un clúster?
2. ¿Cuáles son los casos de uso para estas operaciones?
3. ¿Cómo se diferencian entre sí debajo del capó?

Esos son dos enfoques diferentes:

Manejo imperativo

kubectl createes lo que llamamos gestión imperativa . En este enfoque, le dice a la API de Kubernetes qué desea crear, reemplazar o eliminar, no cómo desea que se vea su mundo de clúster K8s.

Manejo declarativo

kubectl applyes parte del enfoque de Gestión declarativa , donde los cambios que puede haber aplicado a un objeto vivo (es decir, a través de scale) se " mantienen " incluso si realiza applyotros cambios en el objeto.

Puede leer más sobre la gestión imperativa y declarativa en la documentación de Kubernetes Object Management .

Cuando se ejecuta en un script de CI, tendrá problemas con los comandos imperativos, ya que crear genera un error si el recurso ya existe.

Lo que puede hacer es aplicar (patrón declarativo) la salida de su comando imperativo, usando --dry-run=truey -o yamlopciones:

kubectl create whatever --dry-run=true -o yaml | kubectl apply -f -

El comando anterior no generará un error si el recurso ya existe (y lo actualizará si es necesario).

Esto es muy útil en algunos casos en los que no puede utilizar el patrón declarativo (por ejemplo, al crear un secreto de registro de acopladores).

Solo para dar una respuesta más directa, desde mi entendimiento:

apply- realiza cambios incrementales en un objeto existente
create- crea un objeto completamente nuevo (previamente inexistente / eliminado)


Tomando esto de un artículo de DigitalOcean que fue vinculado por el sitio web de Kubernetes:

Usamos aplicar en lugar de crear aquí para que en el futuro podamos aplicar cambios incrementales a los objetos del Controlador de Ingreso en lugar de sobrescribirlos por completo.

Estos son comandos imperativos :

kubectl run = kubectl create deployment

Ventajas:

• Simple, fácil de aprender y fácil de recordar.
• Solo requiere un solo paso para realizar cambios en el clúster.

Desventajas

• No integre con los procesos de revisión de cambios.
• No proporcione un seguimiento de auditoría asociado con los cambios.
• No proporcione una fuente de registros, excepto lo que está en vivo.
• No proporcione una plantilla para crear nuevos objetos.

Estas son configuraciones de objetos imprescindibles :

kubectl create -f your-object-config.yaml

kubectl delete -f your-object-config.yaml

kubectl replace -f your-object-config.yaml

Ventajas en comparación con los comandos imperativos:

• Se puede almacenar en un sistema de control de fuente como Git.
• Puede integrarse con procesos como la revisión de cambios antes de las pistas de inserción y auditoría.
• Proporciona una plantilla para crear nuevos objetos.

Desventajas en comparación con los comandos imperativos:

• Requiere una comprensión básica del esquema del objeto.
• Requiere el paso adicional de escribir un archivo YAML.

Ventajas en comparación con la configuración de objetos declarativos:

• Más simple y más fácil de entender.
• Más maduro después de Kubernetes versión 1.5.

Desventajas en comparación con la configuración de objetos declarativos:

• Funciona mejor en archivos, no en directorios.
• Las actualizaciones de los objetos vivos deben reflejarse en los archivos de configuración, o se perderán durante el próximo reemplazo.

Estas son configuraciones de objetos declarativos

kubectl diff -f configs/

kubectl apply -f configs/

Ventajas en comparación con la configuración de objeto imperativo:

• Los cambios realizados directamente en los objetos vivos se conservan, incluso si no se fusionan nuevamente en los archivos de configuración.
• Mejor soporte para operar en directorios y detectar automáticamente los tipos de operación (crear, parchar, eliminar) por objeto.

Desventajas en comparación con la configuración imperativa de objetos:

• Es más difícil depurar y comprender los resultados cuando son inesperados.
• Las actualizaciones parciales que utilizan diffs crean operaciones complejas de fusión y parche.

La explicación a continuación de la documentación oficial me ayudó a entender kubectl apply.

Este comando comparará la versión de la configuración que está presionando con la versión anterior y aplicará los cambios que haya realizado, sin sobrescribir ningún cambio automático a las propiedades que no haya especificado.

kubectl create por otro lado creará (debería ser inexistente) recursos.

kubectl create puede funcionar con un archivo de configuración de objeto a la vez. Esto también se conoce como gestión imperativa.

kubectl create -f filename | url

kubectl apply funciona con directorios y sus subdirectorios que contienen archivos yaml de configuración de objetos. Esto también se conoce como gestión declarativa. Se pueden recoger múltiples archivos de configuración de objetos de directorios. kubectl apply -f directorio /

Detalles:
https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/ https://kubernetes.io/docs/tasks/manage-kubernetes-objects/imperative-config/

Amamos a Kubernetes porque una vez que les damos lo que queremos pasa a descubrir cómo lograrlo sin nuestra participación.

"crear" es como jugar a DIOS tomando las cosas en nuestras propias manos. Es bueno para la depuración local cuando solo desea trabajar con el POD y no le importa el Controlador de implementación / replicación.

"aplicar" es jugar según las reglas. "aplicar" es como una herramienta maestra que te ayuda a crear y modificar y no requiere nada de ti para administrar los pods.