Konfigurationsabweichungen verhindern

Mit Config Sync können Sie Konfigurationsabweichungen verhindern, damit Clusterressourcen mit Ihrer zentralen Source of Truth übereinstimmen. Standardmäßig erkennt die integrierte Selbstreparatur in Config Sync Abweichungen automatisch und macht sie rückgängig, wobei die Auswirkungen auf die Clusterleistung minimal sind.

Wenn in Ihrer Umgebung Änderungskonflikte blockiert werden müssen, bevor sie vom Cluster angewendet werden, können Sie den Config Sync-Zulassungs-Webhook zur Drift-Prävention aktivieren. Da dieser Webhook den Arbeitsspeicherbedarf erhöht und zu Fehlern aufgrund von unzureichendem Arbeitsspeicher führen kann, sollten Sie sich in den meisten Anwendungsfällen auf die integrierte Selbstheilung verlassen.

Warum die Drift-Prävention nicht empfohlen wird

Für den Zulassungs-Webhook muss Config Sync das Kubernetes OpenAPI-Schema laden, um Anfragen zu validieren. In Clustern mit vielen Ressourcen oder CustomResourceDefinitions kann diese Schemaverarbeitung die Arbeitsspeicherlimits überschreiten, was zu Komponentenausfällen führt. In den meisten Anwendungsfällen bietet die integrierte Selbstheilung in Config Sync Schutz vor Abweichungen ohne die Stabilitätsrisiken des Webhooks. Die integrierte Selbstheilung kann nicht deaktiviert werden.

Wenn diese Option aktiviert ist, schützt die Drift-Prävention standardmäßig RootSync-Objekte. Sie können die Funktion so konfigurieren, dass RepoSync-Objekte geschützt werden. Wenn Sie die Drift-Prävention verwenden möchten, müssen Sie die APIs RootSync und RepoSync aktivieren. Weitere Informationen finden Sie unter RootSync- und RepoSync-Felder.

Hinweis: Sowohl die Selbstheilung als auch die Driftprävention verwenden serverseitiges Anwenden. Das bedeutet, dass sie nur Änderungen an Feldern verhindern oder rückgängig machen, die explizit in der „Source of Truth“ angegeben sind. Config Sync lässt Abweichungen bei nicht angegebenen Feldern zu, da viele Kubernetes-Controller Metadaten- und Spezifikationsfelder zur Laufzeit aktualisieren, nicht nur Statusfelder.

Hinweis

Wenn Sie die Google Cloud CLI bereits installiert haben, rufen Sie die aktuelle Version mit dem Befehl gcloud components update ab.

Drift-Prävention aktivieren

Sie können die Drift-Prävention mit der gcloud CLI aktivieren. Sie können die Drift-Prävention nicht in der Google Cloud Console aktivieren.

Führen Sie die folgenden Schritte aus, um die Drift-Prävention zu aktivieren:

1. Aktualisieren Sie das applySpec-Manifest, um das Feld spec.configSync.preventDrift auf true festzulegen:

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

2. Wenden Sie das aktualisierte Manifest an:

   gcloud beta container fleet config-management apply \
       --membership=MEMBERSHIP_NAME \
       --config=MANIFEST_NAME  \
       --project=PROJECT_ID
   

   Ersetzen Sie Folgendes:

   • MEMBERSHIP_NAME: Name der Flottenmitgliedschaft, den Sie bei der Registrierung Ihres Clusters ausgewählt haben. Rufen Sie den Namen mit dem Befehl gcloud container fleet memberships list ab.
   • MANIFEST_NAME: der Name Ihres Anwendungsspezifikationsmanifests, normalerweise apply-spec.yaml.
   • PROJECT_ID: Ihre Projekt-ID.

3. Warten Sie, bis das Config Sync-ValidateWebhookConfiguration-Objekt vom Config Management Operator erstellt wurde:

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

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

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

4. Übernehmen Sie eine neue Änderung in die zu synchronisierende Source of Truth, damit das root-reconciler-Deployment Webhooks in das Config Sync-ValidatingWebhookConfiguration-Objekt einfügen kann. Alternativ können Sie das root-reconcilier-Deployment löschen, um einen Abgleich auszulösen. Das neue root-reconciler-Deployment würde das Config Sync-ValidatingWebhookConfiguration-Objekt aktualisieren.

5. Warten Sie, bis der Webhook-Server bereit ist. Das Deployment-Log für den Config Sync-Zulassungs-Webhook sollte serving webhook server enthalten. Dieser Vorgang kann einige Minuten dauern.

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

   Die Ausgabe sollte in etwa wie im folgenden Beispiel aussehen:

   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
   

Drift-Prävention deaktivieren

Wenn Sie die Drift-Prävention deaktivieren, löscht Config Sync alle Config Sync-Zulassungs-Webhook-Ressourcen. Da das Config Sync-ValidatingWebhookConfiguration-Objekt nicht mehr vorhanden ist, generieren die Config Sync-Reconciler keine Webhook-Konfigurationen für verwaltete Ressourcen mehr.

Führen Sie die folgenden Schritte aus, um die Drift-Prävention zu deaktivieren:

1. Aktualisieren Sie das applySpec-Manifest, um das Feld spec.configSync.preventDrift auf false festzulegen:

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

2. Wenden Sie das aktualisierte Manifest an:

   gcloud beta container fleet config-management apply \
       --membership=MEMBERSHIP_NAME \
       --config=MANIFEST_NAME  \
       --project=PROJECT_ID
   

   Ersetzen Sie Folgendes:

   • MEMBERSHIP_NAME: Name der Flottenmitgliedschaft, den Sie bei der Registrierung Ihres Clusters ausgewählt haben. Rufen Sie den Namen mit dem Befehl gcloud container fleet memberships list ab.
   • MANIFEST_NAME: der Name Ihres Anwendungsspezifikationsmanifests, normalerweise apply-spec.yaml.
   • PROJECT_ID: Ihre Projekt-ID.

Zulassungs-Webhook in Namespace-bezogenen Quellen aktivieren

Namespace-bezogene „Sources of Truth“ sind nicht vollständig durch den Webhook geschützt. Der Config Sync-Reconciler für jede Namespace-Quelle hat nicht die Berechtigung, die ValidatingWebhookConfiguration-Objekte auf Clusterebene zu lesen oder zu aktualisieren.

Diese fehlende Berechtigung führt zu einem Fehler für die Namespace-Abgleicher-logs, ähnlich dem folgenden Beispiel:

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

Sie können diesen Fehler ignorieren, wenn Sie den Webhook-Schutz für Ihre Namespace-bezogene „Source of Truth“ nicht verwenden möchten. Wenn Sie jedoch den Webhook verwenden möchten, erteilen Sie dem Abgleicher für jede Namespace-bezogene "Source of Truth" die Berechtigung, nachdem Sie die Synchronisierung aus mehreren Sources of Truth konfiguriert haben. Diese Schritte sind möglicherweise nicht erforderlich, wenn bereits ein RoleBinding für ns-reconciler-NAMESPACE mit den ClusterRole-Berechtigungen cluster-admin vorhanden ist.

Achtung: Wenn Sie die Berechtigung zum Lesen oder Aktualisieren der ValidatingWebhookConfiguration-Objekten einer Namespace-bezogenen "Source of Truth" haben, können die Namespace-bezogenen Quelleninhaber Änderungen an den Config Sync-Zulassungs-Webhook-Konfigurationen im Cluster vornehmen.

1. Deklarieren Sie in der Root-Source of Truth eine neue ClusterRole-Konfiguration, die dem Config Sync-Zulassungs-Webhook Berechtigungen gewährt. Diese ClusterRole muss nur einmal pro Cluster definiert werden:

   # 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. Deklarieren Sie für jede Namespace-Quelle, für die die Zulassungs-Webhook-Berechtigung gewährt werden muss, eine ClusterRoleBinding-Konfiguration, um Zugriff auf den Zulassungs-Webhook zu gewähren:

   # 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
   

   Ersetzen Sie NAMESPACE durch den Namespace, in dem Sie Ihre Namespace-bezogene Quelle erstellt haben.

3. Übernehmen Sie die Änderungen an der Root-Source of Truth, z. B. bei der Synchronisierung aus einem Git-Repository:

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

4. Prüfen Sie zur Bestätigung mit kubectl get, ob ClusterRole und ClusterRoleBinding erstellt wurden:

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

Nächste Schritte

• Weitere Informationen zur Fehlerbehebung für Webhook.