Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Config Sync ist ein GitOps-Dienst, der als Teil der Google Kubernetes Engine (GKE) Enterprise-Version angeboten wird. Config Sync basiert auf einem Open-Source-Kern und ermöglicht Clusteroperatoren und Plattformadministratoren, Konfigurationen aus einer „Source of Truth“ bereitzustellen. Der Dienst bietet die Flexibilität, einen oder mehrere Cluster und eine beliebige Anzahl von Repositories pro Cluster oder Namespace zu unterstützen. Die Cluster können sich in einer Hybrid- oder Multi-Cloud-Umgebung befinden.
Config Sync ist mit einer Google Kubernetes Engine (GKE) Enterprise-Lizenz verfügbar.
Vorteile von Config Sync
GitOps gilt als universelle Best Practice für Organisationen, die die Kubernetes-Konfiguration in großem Maßstab verwalten. Die Vorteile einer verbesserten Stabilität, besserer Lesbarkeit, Konsistenz, Prüfung und Sicherheit sind alle GitOps-Tools gemeinsam. Config Sync ist Teil der Google Kubernetes Engine (GKE) Enterprise-Version, die eine Reihe einzigartiger Vorteile bietet:
Eingebunden in Google Kubernetes Engine (GKE) Enterprise: Plattformadministratoren können Config Sync mit wenigen Klicks in der Google Cloud Console, mit Terraform oder mithilfe der Google Cloud CLI auf jedem mit Ihrer Flotte verbundenen Cluster installieren. Der Dienst ist für die Verwendung mit anderen Google Kubernetes Engine (GKE) Enterprise- und Google Cloud-Diensten vorkonfiguriert, z. B. Policy Controller, Workload Identity Federation for GKE und Cloud Monitoring.
Integrierte Beobachtbarkeit: Config Sync hat ein Dashboard zur Beobachtbarkeit, das in die Google Cloud Console eingebunden ist und keine zusätzliche Einrichtung erfordert. Plattformadministratoren können den Status ihrer Synchronisierung und des Abgleichs in der Google Cloud Console oder mithilfe der Google Cloud CLI ansehen.
Das folgende Diagramm bietet einen Überblick darüber, wie Teams ihre Cluster mit einem einzelnen Stamm-Repository (von einem Administrator verwaltet) und mehreren Namespace-Repositories (von Anwendungsoperatoren verwaltet) synchronisieren können:
Ein zentraler Administrator verwaltet die zentralisierte Infrastruktur für die Organisation und erzwingt Richtlinien auf dem Cluster und für alle Namespaces in der Organisation. Die Anwendungsoperatoren, die für die Verwaltung von Live-Bereitstellungen zuständig sind, wenden configurations auf die Anwendungen in den Namespaces an, mit denen sie arbeiten.
Cluster konfigurieren
Mit Config Sync können Sie gemeinsame Konfigurationen und Richtlinien wie Policy Controller-Einschränkungen erstellen und einheitlich auf registrierte und verbundene Cluster in einer Flotte aus einer Single Source of Truth anwenden.
Anstatt den kubectl apply-Befehl wiederholt auszuführen, können Sie die Bereitstellung von Konfigurationsänderungen auf Clustern über GitOps-ähnliche Tools organisieren. Weitere Informationen finden Sie unter Sichere Rollouts mit Config Sync.
In dieser und anderen Anleitungen wird ein Git-Repository als "Source of Truth" verwendet. Sie können aber auch ein OCI-Image oder ein Helm-Diagramm verwenden.
Namespaces konfigurieren
Das Konfigurieren von Namespaces mit Config Sync bietet folgende Funktionen:
Sie können Kubernetes-Namespaces kontinuierlich mit Namespace-bezogenen Richtlinien wie RBAC-Rollen über registrierte und verbundene Cluster hinweg bereitstellen. Namespace-bezogene Richtlinien vereinfachen die Implementierung und Verwaltung der Mehrmandantenfähigkeit in Ihren Clustern.
Sie können Richtlinien auf mehrere verwandte Namespaces anwenden, ohne Konfigurationen duplizieren zu müssen. Außerdem können Sie eine Konfiguration für einen bestimmten Namespace oder eine Gruppe von Namespaces überschreiben oder erweitern, was die Durchsetzung einheitlicher Richtlinien für alle Mandanten erleichtert.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2024-12-20 (UTC)."],[],[],null,["# Config Sync overview\n\nThis page provides a high-level explanation of Config Sync and its benefits.\n\nConfig Sync can help you to simplify management of Kubernetes configuration objects.\nYou can use Config Sync to centralize your configuration files in a single\n, such as a Git repository, which helps to ensure consistency and eliminate\nconfiguration drift.\n\nThis page is for Operators who want to\nimplement [GitOps](https://opengitops.dev/) tools to centralize configuration management for their teams.\nTo learn more about common roles and\nexample tasks that we reference in Google Cloud content, see\n[Common GKE user roles and tasks](/kubernetes-engine/enterprise/docs/concepts/roles-tasks).\n\nPricing\n-------\n\nConfig Sync requires a Google Kubernetes Engine (GKE) Enterprise edition license.\n\nConfig Sync benefits\n--------------------\n\nConfig Sync is a GitOps service for platform administrators that\ncentralizes configuration management by letting teams sync resources across\nclusters or namespaces from a single source of truth.\n\nGitOps is considered a universal best\npractice for organizations managing Kubernetes configuration at scale. The\nbenefits of improved stability, better readability, consistency, audit and\nsecurity are common to all GitOps tools. Config Sync is a part of\nGoogle Kubernetes Engine (GKE) Enterprise edition, which provides you with a set of unique advantages:\n\n- **Integrated with Google Kubernetes Engine (GKE) Enterprise edition**: platform admins can install Config Sync using a few clicks in the Google Cloud console, using Terraform, or by using Google Cloud CLI on any cluster connected to your fleet. The service is pre-configured to work with other Google Kubernetes Engine (GKE) Enterprise edition and Google Cloud services like Policy Controller, Workload Identity Federation for GKE and Cloud Monitoring.\n- **Built-in observability**: Config Sync has an observability dashboard that is built into the Google Cloud console, requiring no additional setup. Platform administrators can view the state of their synchronization and reconciliation by visiting the Google Cloud console or by using the Google Cloud CLI.\n- **Multi-cloud and hybrid support** : Config Sync is tested across several cloud providers and in hybrid environments prior to every GA release. To view the support matrix, see [Google Kubernetes Engine (GKE) Enterprise edition version and upgrade support](/anthos/docs/version-and-upgrade-support).\n\nHow Config Sync works\n---------------------\n\nThe following diagram shows you an overview of how teams might sync their\nclusters to a single root repository (managed by an admin) and multiple\nnamespace repositories (managed by application operators):\n\nA central administrator manages the centralized\ninfrastructure for the organization and enforces policies on the cluster and on\nall namespaces in the organization. The application operators, who are\nresponsible for managing live deployments, apply\n[configurations](/kubernetes-engine/enterprise/config-sync/docs/concepts/configs) to the applications in the\nnamespaces that they work on.\n\n### Configuring clusters\n\nConfig Sync lets you create a common set of configuration and policies, such as\n[Policy Controller constraints](/kubernetes-engine/enterprise/policy-controller/docs/overview#constraints),\nand consistently apply them across [registered](/anthos/multicluster-management/connect/registering-a-cluster) and\n[connected](/anthos/multicluster-management/connect/overview)\nclusters from a single source of truth.\n\nInstead of repeatedly running the `kubectl apply` command manually, you can\norchestrate deployment of configuration changes to fleets of clusters through\nGitOps-style tools. For more information, see\n[Safe rollouts with Config Sync](/kubernetes-engine/enterprise/config-sync/docs/tutorials/safe-rollouts-with-config-sync).\nWhile this and other tutorials use a Git repository as the source of truth, it's\nalso possible to use an\n[OCI image](/kubernetes-engine/enterprise/config-sync/docs/how-to/sync-oci-artifacts-from-artifact-registry)\nor [Helm chart](/kubernetes-engine/enterprise/config-sync/docs/how-to/sync-helm-charts-from-artifact-registry).\n\n### Configuring namespaces\n\nConfiguring namespaces with Config Sync provides you with the following\ncapabilities:\n\n- You can consistently provision Kubernetes namespaces with namespace-scoped policies, such as [RBAC roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), across registered and connected clusters. Namespace-scoped policies make it easier to implement and manage [multi-tenancy](/kubernetes-engine/docs/best-practices/enterprise-multitenancy) within your clusters.\n- Apply policies to multiple related namespaces, without duplicating configs, and with the ability to override or extend a config for a given namespace or set of namespaces, making it easier to apply consistent policies across tenants.\n\nWhat's next\n-----------\n\n- [Get started with Config Sync](/kubernetes-engine/enterprise/config-sync/docs/tutorials/config-sync-multi-repo)\n- [Review GitOps best practices](/kubernetes-engine/enterprise/config-sync/docs/concepts/gitops-best-practices)"]]
