O Config Sync permite evitar desvios de configuração para que os recursos do cluster permaneçam alinhados com sua fonte de verdade central. Por padrão, a recuperação automática integrada do Config Sync detecta e reverte automaticamente o desvio com impacto mínimo no desempenho do cluster.
Quando o ambiente exige o bloqueio de alterações conflitantes antes que o cluster as aplique, é possível ativar o webhook de admissão do Config Sync para prevenção de desvios. Como esse webhook aumenta a sobrecarga de memória e pode causar erros de falta de memória (OOM, na sigla em inglês), use a autorrecuperação integrada na maioria dos casos de uso.
Por que a prevenção de desvios não é recomendada
O webhook de admissão exige que o Config Sync carregue o esquema OpenAPI do Kubernetes para validar as solicitações. Em clusters com muitos recursos ou CustomResourceDefinitions, esse processamento de esquema pode exceder os limites de memória, levando a falhas de componentes. Na maioria dos casos de uso, a autocorreção integrada no Config Sync oferece proteção contra desvios sem os riscos de estabilidade do webhook. Não é possível desativar a recuperação automática integrada.
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 APIs RootSync e RepoSync. Para mais informações, consulte
Campos RootSync e RepoSync.
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 desvios usando a CLI gcloud. Não é possível ativar a prevenção de desvios no console do Google Cloud .
Para ativar a prevenção de desvios, siga estas etapas:
Atualize o manifesto de especificação de aplicação para definir o campo
spec.configSync.preventDriftcomotrue:applySpecVersion: 1 spec: configSync: enabled: true ... existing content ... preventDrift: trueAplique o manifesto atualizado:
gcloud beta container fleet config-management apply \ --membership=MEMBERSHIP_NAME \ --config=MANIFEST_NAME \ --project=PROJECT_IDSubstitua:
MEMBERSHIP_NAME: o nome da assinatura da frota que você escolheu quando registrou o cluster. Encontre o nome com o comandogcloud container fleet memberships list.MANIFEST_NAME: o nome do manifesto de especificação de aplicação, geralmenteapply-spec.yaml.PROJECT_ID: o ID do projeto.
Aguarde até que o objeto
ValidateWebhookConfigurationdo Config Sync seja criado pelo ConfigManagement Operator:kubectl get validatingwebhookconfiguration admission-webhook.configsync.gke.ioO resultado será semelhante a:
NAME WEBHOOKS AGE admission-webhook.configsync.gke.io 0 2m15sConfirme uma nova alteração na fonte de verdade a ser sincronizada para que a implantação
root-reconcilerpossa adicionar webhooks ao objeto Config Sync ValidatingWebhookConfiguration. Uma alternativa é excluir a Implantaçãoroot-reconcilierpara acionar uma reconciliação. A nova Implantaçãoroot-reconcileratualizará 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 desvios, 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 desvios, siga estas etapas:
Atualize o manifesto de especificação de aplicação para definir o campo
spec.configSync.preventDriftcomofalse:applySpecVersion: 1 spec: configSync: enabled: false ... existing content ... preventDrift: falseAplique o manifesto atualizado:
gcloud beta container fleet config-management apply \ --membership=MEMBERSHIP_NAME \ --config=MANIFEST_NAME \ --project=PROJECT_IDSubstitua:
MEMBERSHIP_NAME: o nome da assinatura da frota que você escolheu quando registrou o cluster. Encontre o nome com o comandogcloud container fleet memberships list.MANIFEST_NAME: o nome do manifesto de especificação de aplicação, geralmenteapply-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.ioSubstitua
NAMESPACEpelo 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 pushPara verificar, use
kubectl getpara 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.