O que entendi pela documentação é que:

• kubectl create = Cria um novo recurso k8s no cluster
• kubectl replace = Atualiza um recurso no cluster ativo
• kubectl apply = Se eu quiser criar + substituir ( Referência )

Minhas perguntas são

1. Por que existem três operações para executar a mesma tarefa em um cluster?
2. Quais são os casos de uso para essas operações?
3. Como eles diferem um do outro sob o capô?

Essas são duas abordagens diferentes:

Gerenciamento Imperativo

kubectl createé o que chamamos de Gerenciamento Imperativo . Nesta abordagem, você diz à API do Kubernetes como deseja criar, substituir ou excluir, e não como deseja que o mundo do cluster do K8s pareça.

Gestão Declarativa

kubectl applyfaz parte da abordagem de gerenciamento declarativo , na qual as alterações que você pode ter aplicado a um objeto ativo (por exemplo, através scale) são " mantidas ", mesmo que applyoutras alterações sejam feitas no objeto.

Você pode ler mais sobre gerenciamento imperativo e declarativo na documentação do Kubernetes Object Management .

Ao executar em um script de IC, você terá problemas com comandos imperativos, pois create gera um erro se o recurso já existir.

O que você pode fazer é aplicar (padrão declarativo) a saída do seu comando imperativo, usando as opções --dry-run=truee -o yaml:

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

O comando acima não gerará um erro se o recurso já existir (e atualizará o recurso, se necessário).

Isso é muito útil em alguns casos em que você não pode usar o padrão declarativo (por exemplo, ao criar um segredo do estivador-registro).

Apenas para dar uma resposta mais direta, do meu entendimento:

apply- faz alterações incrementais em um objeto existente
create- cria um novo objeto (anteriormente inexistente / excluído).


Retirando isso de um artigo da DigitalOcean que foi vinculado pelo site da Kubernetes:

Usamos apply em vez de create aqui para que, no futuro, possamos aplicar de maneira incremental as alterações nos objetos do Ingress Controller em vez de substituí-los completamente.

Estes são comandos imperativos :

kubectl run = kubectl create deployment

Vantagens:

• Simples, fácil de aprender e fácil de lembrar.
• Exija apenas uma única etapa para fazer alterações no cluster.

Desvantagens:

• Não se integre aos processos de revisão de alterações.
• Não forneça uma trilha de auditoria associada a alterações.
• Não forneça uma fonte de registros, exceto o que é ao vivo.
• Não forneça um modelo para criar novos objetos.

Estas são configurações imperativas de objetos :

kubectl create -f your-object-config.yaml

kubectl delete -f your-object-config.yaml

kubectl replace -f your-object-config.yaml

Vantagens em comparação com comandos imperativos:

• Pode ser armazenado em um sistema de controle de origem, como o Git.
• Pode integrar-se a processos como a revisão de alterações antes das trilhas de envio e auditoria.
• Fornece um modelo para criar novos objetos.

Desvantagens em comparação com comandos imperativos:

• Requer entendimento básico do esquema do objeto.
• Requer a etapa adicional de gravação de um arquivo YAML.

Vantagens em comparação com a configuração declarativa do objeto:

• Mais simples e fácil de entender.
• Mais maduro após a versão 1.5 do Kubernetes.

Desvantagens comparadas à configuração declarativa do objeto:

• Funciona melhor em arquivos, não em diretórios.
• As atualizações dos objetos dinâmicos devem ser refletidas nos arquivos de configuração, ou serão perdidas durante a próxima substituição.

Estas são configurações declarativas de objetos

kubectl diff -f configs/

kubectl apply -f configs/

Vantagens em comparação com a configuração imperativa do objeto:

• As alterações feitas diretamente nos objetos ativos são mantidas, mesmo que não sejam mescladas novamente nos arquivos de configuração.
• Melhor suporte para operação em diretórios e detecção automática de tipos de operação (criar, corrigir, excluir) por objeto.

Desvantagens comparadas à configuração imperativa do objeto:

• Mais difícil para depurar e entender os resultados quando eles são inesperados.
• Atualizações parciais usando diffs criam operações complexas de mesclagem e correção.

A explicação abaixo da documentação oficial me ajudou a entender kubectl apply.

Este comando comparará a versão da configuração que você está enviando com a versão anterior e aplicará as alterações feitas, sem substituir as alterações automatizadas nas propriedades que você não especificou.

kubectl create por outro lado, criará (deve ser inexistente) recursos.

O kubectl create pode funcionar com um arquivo de configuração de objeto por vez. Isso também é conhecido como gerenciamento imperativo

kubectl create -f filename | url

O kubectl apply funciona com diretórios e seus subdiretórios que contêm arquivos yaml de configuração de objeto. Isso também é conhecido como gerenciamento declarativo. Vários arquivos de configuração de objeto dos diretórios podem ser selecionados. Diretório kubectl apply -f /

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

Adoramos o Kubernetes porque, uma vez que damos a eles o que queremos, ele descobre como alcançá-lo sem nosso envolvimento.

"criar" é como brincar de DEUS tomando as coisas em nossas próprias mãos. É bom para depuração local quando você deseja trabalhar apenas com o POD e não se importa com o Deployment / Replication Controller.

"aplicar" está seguindo as regras. "aplicar" é como uma ferramenta principal que ajuda a criar e modificar e não exige nada de você para gerenciar os pods.