Algumas ou todas as informações nesta página podem não se aplicar ao Cloud de Confiance by S3NS. Consulte o artigo Diferenças em relação ao Google Cloud para mais detalhes.

Esta página foi traduzida pela API Cloud Translation.

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 autocorreção e as resincronizações periódicas ajudem a corrigir a divergência, a prevenção da divergência 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.

Antes de começar

Se instalou anteriormente a CLI gcloud, obtenha a versão mais recente executando o comando gcloud components update.

Ative a prevenção de desvio

Pode ativar a prevenção de desvio através da CLI gcloud. Não pode ativar a prevenção de desvio na consola Cloud de Confiance .

Para ativar a prevenção de desvio, conclua os seguintes passos:

Atualize o manifesto de especificação de aplicação para definir o campo spec.configSync.preventDrift como true:

applySpecVersion: 1
spec:
  configSync:
    enabled: true
    ... existing content ...
    preventDrift: true

Aplique o manifesto atualizado:
```
gcloud beta container fleet config-management apply \
    --membership=MEMBERSHIP_NAME \
    --config=MANIFEST_NAME  \
    --project=PROJECT_ID
```
Substitua o seguinte:
- MEMBERSHIP_NAME: o nome da subscrição da frota que escolheu quando registou o cluster. Obtenha o nome com o comando gcloud container fleet memberships list.
- MANIFEST_NAME: o nome do manifesto de especificação de aplicação, normalmente apply-spec.yaml.
- PROJECT_ID: o ID do projeto.

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

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 root-reconcilier implementação para acionar uma conciliação. A nova root-reconcilerimplementação atualizaria o objeto ValidatingWebhookConfiguration do Config Sync.

Aguarde até que o servidor de webhook esteja pronto. O registo de implementação do webhook de admissão do Config Sync 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

Quando desativa a prevenção de desvio, o Config Sync 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.

Para desativar a prevenção de desvio, conclua os seguintes passos:

Atualize o manifesto de especificação de aplicação para definir o campo spec.configSync.preventDrift como false:

applySpecVersion: 1
spec:
  configSync:
    enabled: false
    ... existing content ...
    preventDrift: false

Aplique o manifesto atualizado:
```
gcloud beta container fleet config-management apply \
    --membership=MEMBERSHIP_NAME \
    --config=MANIFEST_NAME  \
    --project=PROJECT_ID
```
Substitua o seguinte:
- MEMBERSHIP_NAME: o nome da subscrição da frota que escolheu quando registou o cluster. Obtenha o nome com o comando gcloud container fleet memberships list.
- MANIFEST_NAME: o nome do manifesto de especificação de aplicação, normalmente apply-spec.yaml.
- PROJECT_ID: o ID do projeto.

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 de â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.

Na origem de verdade raiz, declare uma nova configuração ClusterRole que conceda autorização ao webhook de admissão do Config Sync. Este ClusterRole só tem de 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"]

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.

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
```
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

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 a sincronização das alterações e eliminar novamente o objeto RootSync ou RepoSync.

O que se segue?

Saiba como resolver problemas do webhook.