Evite a deriva da configuração

O Config Sync reduz o risco de "operações ocultas" através da autocura automática, da resincronização periódica e da prevenção opcional de desvios. Quando o Config Sync deteta uma divergência entre o cluster e a fonte de verdade, esta pode ser permitida e rapidamente revertida ou completamente rejeitada.

A autocorreção monitoriza os recursos geridos, deteta o desvio da fonte de informações fidedignas e reverte esse desvio. A autorrecuperação está sempre ativada.

A sincronização periódica volta a sincronizar automaticamente uma hora após a última sincronização bem-sucedida, mesmo que não tenha sido feita nenhuma alteração à fonte de dados fidedigna. A ressincronização periódica está sempre ativada.

Embora a autorrecuperação e as resincronizações periódicas ajudem a corrigir a deriva, a prevenção da deriva interceta pedidos de alteração de objetos geridos e valida se a alteração deve ser permitida. Se a alteração não corresponder à fonte de verdade, a alteração é rejeitada. A prevenção de desvio está desativada por predefinição. Quando ativada, a prevenção de desvio protege os objetos RootSync por predefinição e também pode ser configurada para proteger os objetos RepoSync.

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

Nota: todas estas funcionalidades usam a aplicação do lado do servidor, o que significa que apenas impedem ou revertem alterações a campos especificados explicitamente na fonte de verdade. Os campos não especificados podem variar. Isto é necessário porque muitos controladores do Kubernetes atualizam os campos de metadados e de especificação no tempo de execução e não apenas os campos de estado.

Ative a prevenção de desvio

1. Se usou a Google Cloud consola ou a CLI gcloud para instalar o Config Sync, ative a prevenção de desvio através da CLI gcloud. Certifique-se de que atualiza a CLI gcloud para a versão mais recente. Defina o campo spec.configSync.preventDrift do ficheiro de configuração do gcloud como true e, em seguida, aplique o ficheiro de configuração do gcloud.

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

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

   Deverá ver uma saída semelhante ao seguinte exemplo:

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

3. Confirme uma nova alteração à fonte de verdade a sincronizar para que a implementação possa adicionar webhooks ao objeto ValidatingWebhookConfiguration do Config Sync.root-reconciler Em alternativa, pode eliminar a implementação para acionar uma conciliação.root-reconcilier A nova root-reconcilerimplementação atualizaria o objeto ValidatingWebhookConfiguration do Config Sync.

4. Aguarde até que o servidor de webhook esteja pronto. O webhook de admissão do Config Sync O registo de implementação deve incluir serving webhook server. Esta ação pode demorar vários minutos.

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

   Deverá ver uma saída semelhante ao seguinte exemplo:

   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
   

Desative a prevenção de desvio

Desative a prevenção de desvio através da CLI gcloud se tiver instalado o Config Sync através da Google Cloud consola ou da CLI gcloud. Certifique-se de que atualiza a CLI gcloud para a versão mais recente. Defina o campo spec.configSync.preventDrift do ficheiro de configuração do gcloud como false ou remova o campo e, em seguida, aplique o ficheiro de configuração do gcloud.

Esta ação elimina todos os recursos do webhook de admissão do Config Sync. Uma vez que o objeto ValidatingWebhookConfiguration do Config Sync já não existe, os reconciliadores do Config Sync já não geram as configurações de webhook para recursos geridos.

Ative o webhook de admissão em origens com âmbito de espaço de nomes

As origens de dados fidedignos com âmbito de espaço de nomes não estão totalmente protegidas pelo webhook. O reconciliador do Config Sync para cada origem do espaço de nomes não tem autorização para ler nem atualizar os objetos ValidatingWebhookConfiguration ao nível do cluster.

Esta falta de autorização resulta num erro nos registos dos reconciliadores do espaço de nomes semelhante ao seguinte exemplo:

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

Pode ignorar este erro se não quiser usar a proteção de webhook para a sua origem de dados fidedignos com âmbito do espaço de nomes. No entanto, se quiser usar o webhook, conceda autorização ao reconciliador para cada fonte prioritária ao nível do espaço de nomes depois de ter configurado a sincronização a partir de mais de uma fonte prioritária. Pode não ter de realizar estes passos se já existir uma RoleBinding para o ns-reconciler-NAMESPACE com autorizações de ClusterRole cluster-admin.

Aviso: conceder autorização para ler ou atualizar os objetos ValidatingWebhookConfiguration a uma origem de verdade ao nível do espaço de nomes significa que os proprietários da origem ao nível do espaço de nomes podem fazer alterações às configurações do webhook de admissão da sincronização de configuração no cluster.

1. Na origem de verdade raiz, declare uma nova configuração ClusterRole que conceda permissão ao webhook de admissão do Config Sync. Esta ClusterRole só tem de ser definida 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 âmbito de espaço de nomes onde a autorização do webhook de admissão tem de 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 espaço de nomes no qual criou a origem com âmbito do espaço de nomes.

3. Confirme as alterações na origem de dados principal. Por exemplo, se estiver a sincronizar a partir de um repositório Git:

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

4. Para validar, use kubectl get para se certificar de que o ClusterRole e o ClusterRoleBinding foram criados:

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

Desative a prevenção de desvio para recursos abandonados

Nota: a partir da versão 1.21.0, a prevenção de desvio da sincronização de configuração não rejeita alterações a recursos abandonados. Esta secção aplica-se apenas a versões anteriores a 1.21.0.

Quando elimina um objeto RootSync ou RepoSync, por predefinição, o Config Sync não modifica os recursos geridos anteriormente por esse objeto RootSync ou RepoSync. Isto pode deixar para trás várias etiquetas e anotações que o Config Sync usa para acompanhar estes objetos de recursos. Se a proteção contra desvio estiver ativada, isto pode fazer com que as alterações aos recursos geridos anteriormente sejam rejeitadas.

Se não usou a propagação da eliminação, os objetos de recursos restantes podem reter etiquetas e anotações adicionadas pelo Config Sync.

Se quiser manter estes recursos geridos, anule a gestão dos mesmos antes de eliminar os objetos RootSync ou RepoSync definindo a anotação configmanagement.gke.io/managed como disabled em todos os recursos geridos declarados na fonte de dados fidedignos. Isto indica ao Config Sync para remover as respetivas etiquetas e anotações dos recursos geridos, sem eliminar estes recursos. Após a conclusão da sincronização, pode remover o objeto RootSync ou RepoSync.

Se quiser eliminar estes recursos geridos, tem duas opções:

• Elimine os recursos geridos da fonte de informação fidedigna. Em seguida, o Config Sync elimina os objetos geridos do cluster. Após a conclusão da sincronização, pode remover o objeto RootSync ou RepoSync.
• Ative a propagação da eliminação no objeto RootSync ou RepoSync antes de o eliminar. Em seguida, o Config Sync elimina os objetos geridos do cluster.

Se o objeto RootSync ou RepoSync for eliminado antes de anular a gestão ou eliminar os respetivos recursos geridos, pode recriar o objeto RootSync ou RepoSync, e este adota os recursos no cluster que correspondem à fonte de verdade. Em seguida, pode anular a gestão ou eliminar os recursos, aguardar que as alterações sejam sincronizadas e eliminar novamente o objeto RootSync ou RepoSync.

O que se segue?

• Saiba como resolver problemas do webhook.