Algumas ou todas as informações nesta página podem não se aplicar ao Cloud de Confiance da S3NS. Consulte Diferenças do Google Cloud para saber mais.

O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Evitar desvios na configuração

O Config Sync oferece duas maneiras de gerenciar o desvio:

Usar a autocorreção integrada do Config Sync (recomendado, sem necessidade de configuração): o Config Sync detecta e reverte automaticamente o desvio. Não é possível desativar a autocorreção do Config Sync. A autocorreção tem um impacto mínimo no desempenho.
Ativar o recurso de prevenção de desvio (esta página): a prevenção de desvio usa um webhook de admissão para bloquear mudanças conflitantes. Esse recurso pode causar alto uso de memória e erros de falta de memória (OOM), especialmente em clusters com muitas CustomResourceDefinitions (CRDs).

Por que a prevenção de desvio não é recomendada

O webhook de admissão exige que o Config Sync carregue o esquema OpenAPI do Kubernetes para validar solicitações. Em clusters com muitos recursos ou CRDs, esse processamento de esquema pode exceder os limites de memória, levando a falhas de componentes. Para a maioria dos casos de uso, a autocorreção integrada do Config Sync oferece proteção contra desvio sem os riscos de estabilidade do webhook.

Quando ativada, a prevenção de desvio protege objetos RootSync por padrão. É possível configurar o recurso para proteger objetos RepoSync. Para usar a prevenção de desvio, ative as RootSync e RepoSync APIs.

Antes de começar

Se você já instalou a Google Cloud CLI, instale a versão mais recente executando o comando gcloud components update.

Ativar a prevenção de deslocamento

É possível ativar a prevenção de desvio usando a CLI gcloud. Não é possível ativar a prevenção de desvio no Cloud de Confiance console.

Para ativar a prevenção de desvio, siga estas etapas:

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:
- MEMBERSHIP_NAME: o nome da assinatura da frota que você escolheu quando registrou o cluster. Receba o nome com o comando gcloud container fleet memberships list.
- MANIFEST_NAME: o nome do manifesto de especificação de aplicação, geralmente apply-spec.yaml.
- PROJECT_ID: o ID do projeto.

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

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.

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

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

Para desativar a prevenção de desvio, siga estas etapas:

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:
- MEMBERSHIP_NAME: o nome da assinatura da frota que você escolheu quando registrou o cluster. Receba o nome com o comando gcloud container fleet memberships list.
- MANIFEST_NAME: o nome do manifesto de especificação de aplicação, geralmente apply-spec.yaml.
- PROJECT_ID: o ID do projeto.

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.

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"]

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.

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

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

A seguir

Saiba como resolver problemas com o webhook.