[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-09-01 (世界標準時間)。"],[],[],null,["This 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\nFor information about pricing, see [GKE pricing](/kubernetes-engine/pricing).\n\nConfig Sync benefits\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, which provides you with a set of unique advantages:\n\n- **Integrated with Google Kubernetes Engine**: 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 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 version and upgrade support](/kubernetes-engine/versioning).\n\nHow Config Sync works\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\nConfiguring 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\nConfiguring 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- [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)"]]