Konfigurationsabweichungen verhindern
Config Sync reduziert das Risiko von „Schattenoperationen“ durch automatische Selbstreparatur, regelmäßige Neusynchronisierung und den optionalen Driftverhinderung. Wenn Config Sync eine Drift zwischen dem Cluster und der Datenquelle erkennt, kann dies entweder zugelassen und schnell rückgängig gemacht oder vollständig abgelehnt werden.
Mit der Selbstreparatur werden verwaltete Ressourcen überwacht, eine Abweichung von der „Source of Truth“ erkannt und diese Abweichung rückgängig gemacht. Die Selbstreparatur ist immer aktiviert.
Die regelmäßige erneute Synchronisierung wird automatisch eine Stunde nach der letzten erfolgreichen Synchronisierung synchronisiert, auch wenn keine Änderung an der „Source of Truth“ vorgenommen wurde. Die regelmäßige erneute Synchronisierung ist immer aktiviert.
Während die Selbstheilung und regelmäßige Neusynchronisierungen helfen, Driften auszugleichen, fängt die Driftprävention Anfragen zum Ändern verwalteter Objekte ab und prüft, ob die Änderung zulässig sein sollte. Wenn die Änderung nicht mit der Source of Truth übereinstimmt, wird sie abgelehnt. Der Driftschutz ist standardmäßig deaktiviert. Wenn diese Option aktiviert ist, schützt die Driftverhinderung RootSync
-Objekte standardmäßig und kann auch zum Schutz von RepoSync
-Objekten konfiguriert werden.
Wenn Sie den Driftschutz verwenden möchten, müssen Sie die RootSync
und die RepoSync
API aktivieren.
Drift-Prävention aktivieren
Setzen Sie das Feld
preventDrift
in der Konfigurationsdatei auftrue
und wenden Sie die Konfigurationsdatei an:gcloud
Aktivieren Sie die Drift-Prävention mit der gcloud CLI, wenn Sie Config Sync mit der Google Cloud Console oder der gcloud CLI installiert haben. Aktualisieren Sie gcloud CLI auf die neueste Version. Setzen Sie das Feld
spec.configSync.preventDrift
der gcloud-Konfigurationsdatei auftrue
und wenden Sie dann die gcloud-Konfigurationsdatei an.kubectl
Aktivieren Sie die Drift-Prävention mit
kubectl
, wenn Sie Config Sync manuell mitkubectl
installiert haben. Setzen Sie das Feldspec.preventDrift
desConfigManagement
-Objekts auftrue
und wenden Sie dasConfigManagement
-Objekt an.Warten Sie, bis das Config Sync-Objekt
ValidateWebhookConfiguration
vom ConfigManagement 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
Führen Sie für die Synchronisierung eine neue Änderung an der „Source of Truth“ durch, damit das
root-reconciler
-Deployment dem Config Sync-ValidierungsWebhookConfiguration-Objekt Webhooks hinzufügen kann. Alternativ können Sie dasroot-reconcilier
-Deployment löschen, um einen Abgleich auszulösen. Das neueroot-reconciler
-Deployment würde das Config Sync-Objekt „ValidatingWebhookConfiguration“ aktualisieren.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
gcloud
Deaktivieren Sie die Drift-Prävention mit der gcloud CLI, wenn Sie Config Sync mithilfe der Google Cloud Console oder gcloud CLI installiert haben.
Aktualisieren Sie gcloud CLI auf die neueste Version.
Setzen Sie das Feld spec.configSync.preventDrift
der gcloud-Konfigurationsdatei auf false
oder entfernen Sie das Feld und wenden Sie dann die gcloud-Konfigurationsdatei an.
kubectl
Deaktivieren Sie die Drift-Prävention mit kubectl
, wenn Sie Config Sync manuell mit kubectl
installiert haben.
Setzen Sie das Feld spec.preventDrift
des ConfigManagement
-Objekts auf false
oder entfernen Sie das Feld und wenden Sie dann das ConfigManagement
-Objekt an.
Dadurch werden alle Zulassungs-Webhooks von Config Sync gelöscht.
Da das Config Sync-Objekt ValidatingWebhookConfiguration
nicht mehr vorhanden ist, generieren die Config Sync-Abgleiche keine Webhook-Konfigurationen für verwaltete Ressourcen mehr.
Zulassungs-Webhook in Namespace-bezogenen Quellen aktivieren
Namespace-bezogene Datenquellen der Wahrheit sind nicht vollständig durch den Webhook geschützt. Der Config Sync-Abgleich für jede Namespace-Quelle hat keine Berechtigung zum Lesen oder Aktualisieren der ValidatingWebhookConfiguration
-Objekte auf Clusterebene.
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 den Webhook verwenden möchten, müssen Sie dem Abgleich jedoch für jede Namespace-bezogene „Source of Truth“ die Berechtigung erteilen, nachdem Sie die Synchronisierung von mehreren „Source of Truth“ aus konfiguriert haben.
Sie müssen diese Schritte möglicherweise nicht ausführen, wenn bereits eine RoleBinding für den ns-reconciler-NAMESPACE
mit ClusterRole-cluster-admin
-Berechtigungen vorhanden ist.
Geben Sie in der Root-Datenquelle eine neue ClusterRole-Konfiguration an, die dem Config Sync-Zulassungs-Webhook die Berechtigung 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"]
Deklarieren Sie für jede Namespace-bezogene Quelle, für die die Berechtigung für den Zulassungs-Webhook 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 die Namespace-bezogene Quelle erstellt haben.Übernehmen Sie die Änderungen in der Root-Quelle, 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
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
Driftverhinderung für verlassene Ressourcen deaktivieren
Wenn Sie ein RootSync
- oder RepoSync
-Objekt löschen, ändert Config Sync standardmäßig nicht die Ressourcen, die zuvor von diesem RootSync
- oder RepoSync
-Objekt verwaltet wurden. Dadurch können mehrere Labels und Annotationen hinterlassen werden, mit denen Config Sync diese Ressourcenobjekte verfolgt. Wenn der Driftschutz aktiviert ist, können Änderungen an den zuvor verwalteten Ressourcen abgelehnt werden.
Wenn Sie die Löschweitergabe nicht verwendet haben, behalten die übrig gebliebenen Ressourcenobjekte möglicherweise weiterhin Labels und Annotationen, die von Config Sync hinzugefügt wurden.
Wenn Sie diese verwalteten Ressourcen behalten möchten, heben Sie die Verwaltung dieser Ressourcen auf, bevor Sie die Objekte RootSync
oder RepoSync
löschen. Dazu setzen Sie die Annotation configmanagement.gke.io/managed
für jede verwaltete Ressource, die in der „Source of Truth“ deklariert ist, auf disabled
. Dadurch wird Config Sync angewiesen, die Labels und Annotationen aus den verwalteten Ressourcen zu entfernen, ohne diese Ressourcen zu löschen. Nach Abschluss der Synchronisierung können Sie das RootSync
- oder RepoSync
-Objekt entfernen.
Wenn Sie diese verwalteten Ressourcen löschen möchten, haben Sie zwei Möglichkeiten:
- Löschen Sie die verwalteten Ressourcen aus der „Source of Truth“. Anschließend löscht Config Sync die verwalteten Objekte aus dem Cluster. Nach Abschluss der Synchronisierung können Sie das
RootSync
- oderRepoSync
-Objekt entfernen. - Aktivieren Sie die Weitergabe von Daten für das Objekt
RootSync
oderRepoSync
, bevor Sie es löschen. Anschließend löscht Config Sync die verwalteten Objekte aus dem Cluster.
Wenn das RootSync
- oder RepoSync
-Objekt gelöscht wird, bevor die Verwaltung der verwalteten Ressourcen aufgehoben oder gelöscht wird, können Sie das RootSync
- oder RepoSync
-Objekt neu erstellen. Dadurch werden die Ressourcen im Cluster übernommen, die der „Source of Truth“ entsprechen. Anschließend können Sie die Verwaltung der Ressourcen aufheben oder sie löschen, warten, bis die Änderungen synchronisiert wurden, und das RootSync
- oder RepoSync
-Objekt noch einmal löschen.