Evitar desvios na configuração

O Config Sync reduz o risco de "operações de sombra" por meio de autocorreção automática, ressincronização periódica e prevenção de desvio opcional. Quando o Config Sync detecta desvio entre o cluster e a fonte da verdade, ele pode ser permitido e revertido rapidamente ou completamente rejeitado.

A autocorreção observa recursos gerenciados, detecta desvios da fonte da verdade e reverte esse desvio. A autocorreção está sempre ativada.

A ressincronização periódica é sincronizada automaticamente uma hora após a última sincronização bem-sucedida, mesmo que nenhuma mudança tenha sido feita na fonte da verdade. A ressincronização periódica está sempre ativada.

Enquanto a autocorreção e as ressincronizações periódicas ajudam a corrigir desvios, a prevenção contra desvio intercepta solicitações para mudar objetos gerenciados e valida se a mudança precisa ser permitida. Se a mudança não corresponder à fonte da verdade, ela será rejeitada. A prevenção de desvio está desativada por padrão. Quando ativada, a prevenção de desvio protege objetos RootSync por padrão e também pode ser configurada para proteger objetos RepoSync.

Para usar a prevenção de desvio, ative as APIs RootSync e RepoSync.

Observação: todos esses recursos usam aplicação do lado do servidor, o que significa que eles só evitam ou revertem alterações em campos explicitamente especificados. na fonte da verdade. Os campos não especificados podem se deslocar. Isso é necessário porque muitos controladores do Kubernetes atualizam metadados e campos de especificação no ambiente de execução, não apenas os campos de status.

Ativar a prevenção de deslocamento

1. Defina o campo preventDrift no arquivo de configuração como true e aplique o arquivo de configuração:

   gcloud

   Ative a prevenção de deslocamento usando a CLI gcloud se você tiver instalado o Config Sync usando o Console do Google Cloud ou a CLI gcloud. Atualize a CLI gcloud para a versão mais recente. Defina o campo spec.configSync.preventDrift do arquivo de configuração da gcloud como true e aplique o arquivo de configuração da gcloud.

   kubectl

   Ative a prevenção de deslocamento usando kubectl se tiver instalado o Config Sync manualmente usando kubectl. Defina o campo spec.preventDrift do objeto ConfigManagement como true e aplique o objeto ConfigManagement.

2. Aguarde até que o objeto ValidateWebhookConfiguration do Config Sync seja criado pelo ConfigManagement Operator:

   kubectl get validatingwebhookconfiguration admission-webhook.configsync.gke.io
   

   O resultado será semelhante a:

   NAME                                  WEBHOOKS   AGE
   admission-webhook.configsync.gke.io   0          2m15s
   

3. Confirme uma nova alteração na fonte de verdade a ser sincronizada para que a implantação root-reconciler possa adicionar webhooks ao objeto Config Sync ValidatingWebhookConfiguration. Uma alternativa é excluir a Implantação root-reconcilier para acionar uma reconciliação. A nova Implantação root-reconciler atualizará o objeto ValidatingWebhookConfiguration do Config Sync.

4. Aguarde até que o servidor do webhook esteja pronto. O registro de implantação do webhook de admissão do Config Sync precisa incluir serving webhook server. Isso pode levar alguns minutos.

   kubectl logs -n config-management-system -l app=admission-webhook --tail=-1 | grep "serving webhook server"
   

   O resultado será semelhante a:

   I1201 18:05:41.805531       1 deleg.go:130] controller-runtime/webhook "level"=0 "msg"="serving webhook server"  "host"="" "port"=10250
   I1201 18:07:04.626199       1 deleg.go:130] controller-runtime/webhook "level"=0 "msg"="serving webhook server"  "host"="" "port"=10250
   

Desativar a prevenção de deslocamento

gcloud

Desative a prevenção de desvio usando a CLI gcloud se você tiver instalado o Config Sync usando o Console do Google Cloud ou a CLI gcloud. Atualize a CLI gcloud para a versão mais recente. Defina o campo spec.configSync.preventDrift do arquivo de configuração da gcloud como false ou remova o campo e, em seguida, aplique o arquivo de configuração da gcloud.

kubectl

Desative a prevenção de desvio usando kubectl se tiver instalado o Config Sync manualmente usando kubectl. Defina o campo spec.preventDrift do objeto ConfigManagement como false ou remova o campo e, em seguida, aplique o objeto ConfigManagement.

Isso exclui todos os recursos do webhook de admissão do Config Sync. Como o objeto ValidatingWebhookConfiguration do Config Sync não existe mais, os reconciliadores do Config Sync não geram mais as configurações do webhook para recursos gerenciados.

Ativar o webhook de admissão em origens com escopo de namespace

As fontes de verdade com escopo de namespace não são totalmente protegidas pelo webhook. O reconciliador do Config Sync para cada origem de namespace não tem permissão para ler ou atualizar os objetos ValidatingWebhookConfiguration no nível do cluster.

Essa falta de permissão resulta em um erro nos registros de reconciliadores do namespace, semelhante ao exemplo a seguir:

Failed to update admission webhook: KNV2013: applying changes to
admission webhook: Insufficient permission. To fix, make sure the reconciler has
sufficient permissions.:
validatingwebhookconfigurations.admissionregistration.k8s.io "admission-
webhook.configsync.gke.io" is forbidden: User "system:serviceaccount:config-
management-system:ns-reconciler-NAMESPACE" cannot update resource
"validatingwebhookconfigurations" in API group "admissionregistration.k8s.io" at
the cluster scope

Ignore esse erro se você não quiser usar a proteção do webhook para sua fonte de verdade com escopo de namespace. No entanto, se você quiser usar o webhook, conceda permissão ao reconciliador para cada fonte de verdade com escopo de namespace depois de configurar a sincronização de mais de uma fonte de verdade. Talvez não seja necessário executar essas etapas se um RoleBinding para o ns-reconciler-NAMESPACE já existir com as permissões ClusterRole cluster-admin.

Cuidado: conceder permissão para ler ou atualizar os objetos ValidatingWebhookConfiguration para uma fonte de verdade com escopo de namespace significa que os proprietários de origem com escopo de namespace podem fazer mudanças em as configurações do webhook de admissão do Config Sync no cluster.

1. Na fonte raiz da verdade, declare uma nova configuração de ClusterRole que conceda permissão ao webhook de admissão do Config Sync. Este ClusterRole só precisa ser definido uma vez por cluster:

   # ROOT_SOURCE/cluster-roles/webhook-role.yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: admission-webhook-role
   rules:
   - apiGroups: ["admissionregistration.k8s.io"]
     resources: ["validatingwebhookconfigurations"]
     resourceNames: ["admission-webhook.configsync.gke.io"]
     verbs: ["get", "update"]
   

2. Para cada origem com o namespace no escopo em que a permissão do webhook de admissão precise ser concedida, declare uma configuração ClusterRoleBinding para conceder acesso ao webhook de admissão:

   # ROOT_SOURCE/NAMESPACE/sync-webhook-rolebinding.yaml
   kind: ClusterRoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: syncs-webhook
   subjects:
   - kind: ServiceAccount
     name: ns-reconciler-NAMESPACE
     namespace: config-management-system
   roleRef:
     kind: ClusterRole
     name: admission-webhook-role
     apiGroup: rbac.authorization.k8s.io
   

   Substitua NAMESPACE pelo namespace em que você criou a origem com escopo de namespace.

3. Confirme as alterações na fonte raiz da verdade, por exemplo, se estiver sincronizando de um repositório Git:

   git add .
   git commit -m 'Providing namespace repository the permission to update the admission webhook.'
   git push
   
   

4. Para verificar, use kubectl get para garantir que o ClusterRole e o ClusterRoleBinding foram criados:

   kubectl get clusterrole admission-webhook-role
   kubectl get clusterrolebindings syncs-webhook
   

Desativar a prevenção de desvio para recursos abandonados

Quando você exclui um objeto RootSync ou RepoSync, por padrão, o Config Sync não modifica os recursos gerenciados anteriormente por esse objeto RootSync ou RepoSync. Isso pode manter vários rótulos e anotações que o Config Sync usa para rastrear esses objetos de recursos. Se a proteção contra desvio estiver ativada, isso poderá fazer com que qualquer alteração nos recursos gerenciados anteriormente seja rejeitada.

Se você não usou a propagação de exclusão, os objetos de recurso deixados para trás ainda podem manter os marcadores e as anotações adicionados pelo Config Sync.

Se você quiser manter esses recursos gerenciados, cancele o gerenciamento deles antes de excluir os objetos RootSync ou RepoSync definindo a anotação configmanagement.gke.io/managed como disabled em cada recurso declarado na fonte da verdade. Isso instrui o Config Sync a remover os rótulos e anotações dos recursos gerenciados sem excluí-los. Quando a sincronização for concluída, remova o objeto RootSync ou RepoSync.

Se quiser excluir esses recursos gerenciados, você tem duas opções:

• Exclua os recursos gerenciados da fonte de verdade. Em seguida, o Config Sync excluirá os objetos gerenciados do cluster. Quando a sincronização for concluída, remova o objeto RootSync ou RepoSync.
• Ative a propagação de exclusão no objeto RootSync ou RepoSync antes de excluí-lo. Em seguida, o Config Sync vai excluir os objetos gerenciados do cluster.

Se o objeto RootSync ou RepoSync for excluído antes de cancelar o gerenciamento ou excluir os recursos gerenciados, será possível recriar o objeto RootSync ou RepoSync para adotar os recursos no cluster que correspondam à fonte da verdade. Em seguida, é possível cancelar o gerenciamento ou excluir os recursos, aguardar a sincronização das mudanças e excluir o objeto RootSync ou RepoSync novamente.

A seguir

• Saiba como resolver problemas com o webhook.