[ad_1]
O Server-Side Apply (SSA) está geralmente disponível no Kubernetes desde a versão v1.22 em agosto de 2021. É uma estratégia para gerenciamento de recursos declarativos que melhora os cálculos de diferenças e alerta sobre conflitos de mesclagem ao mover a lógica de kubectl apply comando no servidor.
Este artigo explicará como o SSA funciona e por que ele é preferível à abordagem mais antiga de aplicativo do lado do cliente (CSA). Você também aprenderá como habilitar o SSA ao fazer alterações em objetos em seu cluster.
Entenda as atualizações declarativas
a kubectl apply O comando executa atualizações declarativas em objetos. Em vez de dizer ao Kubernetes para modificar campos específicos, você fornece uma representação completa do objeto como gostaria que aparecesse. O sistema calcula automaticamente as diferenças em comparação com o estado existente do seu cluster. Ele então realizará as ações que transformam o estado no estado desejado expresso por seu arquivo de manifesto.
Aqui está um manifesto de pod simples:
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx:latest
Corre kubectl apply com este manifesto iniciará um novo pod que executa o nginx:latest imagem. A diferença entre o estado atual do cluster e o desejado é clara: um Pod foi criado, onde não havia antes com o nginx Nome.
Você pode modificar o manifesto alterando uma das propriedades do pod:
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx:1.23
Desta vez, a diferença entre o estado existente e o desejado é menos substancial. a kubectl apply o comando detectará a versão revisada image campo e atualize suas configurações de pod de acordo.
Problemas com o aplicativo do lado do cliente
Diferenciar as alterações e resolver quaisquer conflitos é a parte mais importante das atualizações declarativas. Esse processo é executado dentro do Kubectl por padrão. O cliente é responsável por identificar o objeto existente no servidor e comparar suas alterações.
a kubectl apply comando escreve um last-applied-configuration anotação em objetos para ajudar nesse processo. Permite a identificação de campos que existem no objeto ativo, mas foram removidos do manifesto recebido. O cliente então sabe que deve excluí-los do objeto para atingir o novo estado.
Essa abordagem é problemática quando há vários agentes atualizando o mesmo objeto. Um único objeto pode ser modificado por Kubectl e um controlador dedicado em seu cluster, por exemplo. O aplicativo do lado do cliente não pode rastrear qual agente modificou um campo, nem pode entender quando ocorre um conflito. Ele apenas compara seu manifesto local com o do objeto existente last-applied-configuration e mescla em qualquer alteração.
O aplicativo do lado do cliente também está inerentemente vinculado ao Kubectl. As ferramentas de terceiros que desejam fazer suas próprias atualizações declarativas devem chamar Kubectl ou recriar o apply lógica do zero. Nenhuma dessas duas opções é particularmente ideal.
Como funciona o aplicativo do lado do servidor
O problema fundamental com o CSA é que os manifestos locais desatualizados nunca são detectados. Se outro aplicador alterar um objeto antes de executar kubectl apply, suas antigas revisões locais podem sobrescrever as novas corretas. Com o SSA ativado, o conflito será detectado e a atualização será bloqueada. É um sistema centralizado que exige que seu status local seja mantido atualizado.
O SSA funciona adicionando um mecanismo de plano de controle que armazena informações sobre cada campo em seus objetos. Substitui o last-applied-configuration anotação com um novo metadata.managedFields campo. Cada campo em seu objeto é rastreado dentro do managedFields.
Os campos são atribuídos a um “gerente de campo” que identifica o cliente que os possui. Se você aplicar um manifesto com Kubectl, Kubectl será o administrador designado. O gerenciador de um campo também pode ser um controlador ou uma integração externa que atualiza seus objetos.
Os administradores estão proibidos de atualizar os campos uns dos outros. Você não poderá alterar um campo com kubectl apply se atualmente pertence a um driver diferente. Três estratégias estão disponíveis para resolver esses conflitos de mesclagem:
- forçar sobrescrever valor – Em algumas situações, você pode querer forçar a atualização. Isso mudará seu valor e transferirá a propriedade para o novo gerente de campo. Destina-se principalmente aos controladores que precisam manter a gestão dos campos que preencheram. Você pode forçar manualmente uma atualização configurando o
--force-conflictsbandeira em kubectl. - Não sobrescreva o valor – O aplicador pode retirar o campo de sua configuração local e então repetir a solicitação. O campo manterá seu valor existente. A remoção do campo corrige o conflito ao atribuir a propriedade ao administrador existente.
- Gerenciamento de compartilhamento – O aplicador pode atualizar seu valor local para corresponder ao valor existente no servidor. Se você se inscrever novamente enquanto ainda reivindica a propriedade, o SSA permitirá que você compartilhe o gerenciamento com o gerente existente. Isso ocorre porque o aplicador aceita o estado atual do campo, mas indicou que pode querer gerenciá-lo no futuro.
Essa abordagem é muito mais poderosa do que a tradicional. kubectl apply. Ele evita substituições acidentais, permite que os controladores reivindiquem de forma confiável a propriedade dos campos que controlam e é totalmente declarativo. O SSA rastreia como campos individuais foram alterados por usuários diferentes, em vez de apenas registrar o último estado completo do objeto. Isso também significa que agora você pode usar o apply em qualquer ferramenta, independentemente do idioma ou kubectl disponibilidade binária. Você obterá os mesmos resultados consistentes, independentemente de como iniciar a negociação.
Como usar o SSA hoje
Você pode ativar o SSA configurando o --server-side sinalizar cada vez que você executa o Kubectl apply:
$ kubectl apply -f nginx.yaml --server-side pod/nginx serverside-applied
A saída do comando muda para destacar que o SSA foi usado.
A inspeção do manifesto YAML do objeto revelará os campos gerenciados:
$ kubectl get pod nginx -o yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: "2022-11-24T16:02:29Z"
managedFields:
- apiVersion: v1
fieldsType: FieldsV1
fieldsV1:
f:spec:
f:containers:
k:{"name":"nginx"}:
.: {}
f:image: {}
f:name: {}
manager: kubectl
operation: Apply
time: "2022-11-24T16:02:29Z"
- apiVersion: v1
fieldsType: FieldsV1
fieldsV1:
f:status:
f:conditions:
k:{"type":"ContainersReady"}:
.: {}
f:lastProbeTime: {}
f:lastTransitionTime: {}
f:status: {}
f:type: {}
k:{"type":"Initialized"}:
.: {}
f:lastProbeTime: {}
f:lastTransitionTime: {}
f:status: {}
f:type: {}
k:{"type":"Ready"}:
.: {}
f:lastProbeTime: {}
f:lastTransitionTime: {}
f:status: {}
f:type: {}
f:containerStatuses: {}
f:hostIP: {}
f:phase: {}
f:podIP: {}
f:podIPs:
.: {}
k:{"ip":"10.244.0.186"}:
.: {}
f:ip: {}
f:startTime: {}
manager: kubelet
operation: Update
subresource: status
time: "2022-11-24T16:02:31Z"
...
Os campos são agrupados pelo administrador que os possui. Neste exemplo, spec ele é gerenciado pelo Kubectl porque foi assim que o Pod foi criado. a status No entanto, o Kubelet gerencia o campo porque o nó que executa o pod altera o valor desse campo durante o ciclo de vida do pod.
O SSA também está pronto para uso em controladores. Ele permite uma semântica mais forte e novos tipos de controladores, incluindo aqueles que reconstroem objetos. Esse modelo lida com as alterações primeiro reconstruindo os campos de um objeto do zero para a satisfação do controlador e, em seguida, aplicando o resultado ao servidor. É um método mais natural do que estabelecer manualmente a sequência de operações que produzirá uma mudança desejada.
Verifique se um objeto é gerenciado com SSA
Você pode verificar se um objeto usa CSA ou SSA recuperando seu manifesto YAML no Kubectl:
$ kubectl get pod nginx -o yaml
se você ver um last-applied-configuration anotação, seu objeto é gerenciado pelo CSA:
apiVersion: v1
kind: Pod
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec":{"containers":[{"image":"nginx:latest","name":"nginx"}]}}
creationTimestamp: "2022-11-24T14:20:07Z"
name: nginx
namespace: default
...
...
SSA foi usado para o objeto se metadata.managedFields aparece em vez disso:
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: "2022-11-24T16:02:29Z"
managedFields:
- apiVersion: v1
fieldsType: FieldsV1
fieldsV1:
f:spec:
f:containers:
k:{"name":"nginx"}:
.: {}
f:image: {}
f:name: {}
manager: kubectl
operation: Apply
time: "2022-11-24T16:02:29Z"
...
...
...
Você pode mover um objeto entre CSA e SSA simplesmente adicionando ou omitindo o --server-side marque a próxima vez que correr kubectl apply. O Kubernetes gerencia a conversão de last-applied-configuration dentro de managedFields e vice-versa.
As atualizações para SSA podem entrar em conflito se seu manifesto local for diferente do objeto no servidor. Isso ocorre quando você executa um comando imperativo como kubectl scale qualquer kubectl label desde sua última operação de aplicação no objeto. Você deve verificar se seu manifesto local corresponde exatamente ao objeto ativo antes de convertê-lo em SSA.
Resumo
O aplicativo do lado do servidor é uma abordagem para gerenciamento de objetos declarativos em que o plano de controle do Kubernetes rastreia os campos. Isso facilita a detecção robusta de conflitos e estratégias de resolução flexíveis. O SSA aborda as limitações de aplicativos do lado do cliente que permitem que os campos sejam substituídos inadvertidamente sem qualquer aviso.
Embora o SSA agora esteja disponível para todos, você ainda precisa especificá-lo manualmente sempre que executar kubectl apply. Vale a pena observar que o SSA é mais útil em situações em que os objetos são gerenciados por vários processos diferentes, como operadores humanos com Kubectl e um controlador de loop. Você não obterá muitos benefícios do SSA se usar exclusivamente kubectl apply para criar e atualizar objetos.
Espera-se que uma versão futura do Kubernetes remova o CSA, tornando o SSA a única opção padrão. a --server-side então o sinalizador se tornará redundante.
[ad_2]
