{"id":688,"date":"2026-04-15T00:43:44","date_gmt":"2026-04-15T00:43:44","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-config-sync-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-distributed-hybrid-and-multicloud\/"},"modified":"2026-04-15T00:43:44","modified_gmt":"2026-04-15T00:43:44","slug":"google-cloud-config-sync-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-distributed-hybrid-and-multicloud","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-config-sync-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-distributed-hybrid-and-multicloud\/","title":{"rendered":"Google Cloud Config Sync Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Distributed, hybrid, and multicloud"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Distributed, hybrid, and multicloud<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Config Sync is a Google Cloud service for Kubernetes GitOps: it continuously applies configuration stored in a source repository (typically Git) to one or more Kubernetes clusters and keeps those clusters aligned with the repository over time.<\/p>\n\n\n\n<p>In simple terms: you store your \u201cdesired state\u201d Kubernetes YAML in a repo, and Config Sync makes your clusters match it\u2014automatically and repeatedly.<\/p>\n\n\n\n<p>Technically, Config Sync installs reconcilers (controllers) in your clusters. Those reconcilers authenticate to a supported source (such as a Git repository or an OCI image), fetch declared Kubernetes objects, validate them, and then reconcile them into the cluster. If someone changes a synced object manually, Config Sync detects drift and reconciles it back (depending on object type and reconciliation rules).<\/p>\n\n\n\n<p>The problem it solves is configuration sprawl and drift across clusters\u2014especially in distributed, hybrid, and multicloud environments where platform teams must operate many clusters consistently, safely, and audibly.<\/p>\n\n\n\n<blockquote>\n<p>Naming note (important): Historically, Config Sync functionality was delivered under <strong>Anthos Config Management (ACM)<\/strong>. Google Cloud documentation now focuses on <strong>Config Sync<\/strong> (GitOps synchronization) and <strong>Policy Controller<\/strong> (policy enforcement) as distinct but related capabilities. If you encounter \u201cAnthos Config Management\u201d in older guides, treat it as legacy naming and verify the current workflow in official docs.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Config Sync?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p>Config Sync is Google Cloud\u2019s GitOps-style configuration synchronization solution for Kubernetes fleets. Its purpose is to <strong>keep cluster configuration consistent with a declared source of truth<\/strong> (usually Git), across one or many clusters.<\/p>\n\n\n\n<p>Official docs entry point (verify current structure here):<br\/>\nhttps:\/\/cloud.google.com\/anthos-config-management\/docs\/config-sync-overview<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<p>Config Sync commonly supports:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Continuous reconciliation<\/strong> of Kubernetes objects from a repository into a cluster.<\/li>\n<li><strong>Multi-cluster consistency<\/strong> when used with Fleet \/ GKE Enterprise across many clusters.<\/li>\n<li><strong>Status and health reporting<\/strong> so you can see sync success, errors, and drift.<\/li>\n<li><strong>Separation of duties<\/strong> (developers propose changes in Git; clusters reconcile automatically).<\/li>\n<li><strong>Multi-tenancy patterns<\/strong> using separate sync scopes (for example, namespace-scoped sync).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components (conceptual)<\/h3>\n\n\n\n<p>While exact component names can evolve, expect these building blocks:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Source of truth<\/strong>: Git repository (or supported alternative source).<\/li>\n<li><strong>Config Sync reconcilers<\/strong>: controllers running in-cluster that pull config and apply it.<\/li>\n<li><strong>Sync custom resources<\/strong>:<\/li>\n<li><strong>Root-scoped sync<\/strong> (cluster\/admin scope)<\/li>\n<li><strong>Namespace-scoped sync<\/strong> (delegated per namespace)<\/li>\n<li><strong>Fleet integration (optional but common)<\/strong>: manage\/observe sync across many clusters using Google Cloud\u2019s Fleet (GKE Hub).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<p>Config Sync is not a standalone managed service like Cloud Storage. It is an <strong>add-on capability for Kubernetes clusters<\/strong> (GKE and supported attached\/registered clusters) that deploys controllers into clusters and integrates with Google Cloud Fleet tooling and telemetry.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Scope (how it\u2019s \u201cscoped\u201d)<\/h3>\n\n\n\n<p>Config Sync is effectively:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cluster-scoped<\/strong> (installed per cluster), and often<\/li>\n<li><strong>Fleet-managed<\/strong> (configured and observed centrally per Fleet membership), when you use it with Google Cloud Fleet\/GKE Enterprise.<\/li>\n<\/ul>\n\n\n\n<p>Your sync configuration is applied to each target cluster (directly or via fleet), and reconciliations happen inside the cluster.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Google Cloud ecosystem<\/h3>\n\n\n\n<p>Config Sync typically sits in the platform layer of Google Cloud\u2019s Kubernetes story:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>GKE (Google Kubernetes Engine)<\/strong>: the primary runtime.<\/li>\n<li><strong>Fleet (GKE Hub)<\/strong>: central registration, multi-cluster features, and management.<\/li>\n<li><strong>GKE Enterprise (formerly Anthos packaging)<\/strong>: commercial bundle that includes fleet features such as Config Sync for hybrid and multicloud operations (verify edition requirements).<\/li>\n<li><strong>Cloud Logging \/ Cloud Monitoring<\/strong>: operational telemetry for reconcilers and cluster events.<\/li>\n<li><strong>IAM<\/strong>: controls who can configure sync and who can change cluster state.<\/li>\n<li><strong>Config Connector (optional)<\/strong>: manage Google Cloud resources via Kubernetes CRDs, which can also be delivered via Config Sync (use carefully).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Config Sync?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Faster, safer change delivery<\/strong>: changes are reviewed and versioned in Git, then rolled out consistently.<\/li>\n<li><strong>Auditability<\/strong>: Git history + Kubernetes audit logs provide traceability for \u201cwho changed what and why\u201d.<\/li>\n<li><strong>Standardization<\/strong> across business units: consistent baseline controls (namespaces, RBAC, network policies, resource quotas).<\/li>\n<li><strong>Reduced operational incidents<\/strong> from drift and one-off manual changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Continuous reconciliation<\/strong>: prevents configuration drift.<\/li>\n<li><strong>Declarative management<\/strong>: aligns with Kubernetes best practices.<\/li>\n<li><strong>Multi-cluster management<\/strong>: apply shared configuration patterns across clusters.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Repeatable environments<\/strong>: dev\/test\/prod clusters can share baselines with controlled differences.<\/li>\n<li><strong>Simplified rollbacks<\/strong>: revert a Git commit to revert configuration (subject to object lifecycle rules).<\/li>\n<li><strong>Fleet-wide visibility<\/strong> (where integrated): easier troubleshooting across many clusters.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Change control via Git<\/strong>: enforce PR review, signed commits\/tags (where your SCM supports it), and controlled merges.<\/li>\n<li><strong>Least privilege<\/strong>: restrict cluster-admin access; allow teams to propose changes in Git instead.<\/li>\n<li><strong>Policy synergy<\/strong>: Config Sync is commonly paired with Policy Controller to enforce guardrails (admission control).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Scales operationally<\/strong>: managing 50 clusters with GitOps is often simpler than manual scripts.<\/li>\n<li><strong>Consistent drift correction<\/strong>: reduces human load and error rates.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose Config Sync when you need:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Multi-cluster Kubernetes configuration consistency.<\/li>\n<li>Git as the authoritative source for cluster configuration.<\/li>\n<li>Strong separation between \u201cchange authoring\u201d and \u201cchange application\u201d.<\/li>\n<li>A Google Cloud-aligned approach for distributed, hybrid, and multicloud Kubernetes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Consider alternatives or delay adoption if:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Your organization cannot adopt Git-based workflows yet.<\/li>\n<li>You primarily need <strong>application delivery<\/strong> features (progressive delivery, canaries) rather than cluster configuration. (Tools like Argo CD, Flux, or Cloud Deploy may be more app-delivery oriented; verify fit.)<\/li>\n<li>You have heavy customization needs that are better addressed by a different GitOps controller ecosystem already standard in your org.<\/li>\n<li>You\u2019re not prepared to operationalize GitOps (branching strategy, environment overlays, secret handling, repo governance).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Config Sync used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<p>Common in industries with compliance and multi-environment needs:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Financial services (audit trails, standardization)<\/li>\n<li>Healthcare (change control, compliance)<\/li>\n<li>Retail\/e-commerce (rapid but controlled scaling)<\/li>\n<li>SaaS providers (multi-tenant platform operations)<\/li>\n<li>Manufacturing and edge (hybrid clusters, consistent baselines)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering teams<\/li>\n<li>SRE \/ production operations teams<\/li>\n<li>Security engineering teams (guardrails + baselines)<\/li>\n<li>DevOps teams (GitOps adoption)<\/li>\n<li>Cloud Center of Excellence (CCoE)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Microservices on GKE<\/li>\n<li>Multi-tenant namespaces (quotas\/RBAC per tenant)<\/li>\n<li>Service mesh configurations (baseline policies)<\/li>\n<li>Logging\/monitoring agents as cluster add-ons<\/li>\n<li>Ingress and gateway resources<\/li>\n<li>Policy and security baselines<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Single-cluster production (with strong governance)<\/li>\n<li>Multi-cluster regional\/geo setups<\/li>\n<li>Hybrid architectures (on-prem + cloud)<\/li>\n<li>Multicloud architectures (clusters outside Google Cloud registered to Fleet, where supported)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Baseline \u201cplatform\u201d repos that define shared cluster configuration.<\/li>\n<li>Per-team repos for namespace-scoped resources.<\/li>\n<li>\u201cEnvironment promotion\u201d patterns: dev \u2192 staging \u2192 prod via Git PRs and protected branches.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Dev\/test<\/strong>: start with a single cluster and a limited set of objects (namespaces, RBAC, network policies).<\/li>\n<li><strong>Production<\/strong>: adopt structured repos, protected branches, CI checks, and (often) policy enforcement before scaling cluster count.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic Config Sync use cases (10+), each with a problem, why Config Sync fits, and a short scenario.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Fleet-wide namespace and RBAC baseline<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Teams create namespaces and RBAC manually across multiple clusters; drift and misconfiguration accumulate.<\/li>\n<li><strong>Why Config Sync fits:<\/strong> Declaratively enforces a consistent baseline everywhere.<\/li>\n<li><strong>Scenario:<\/strong> A platform team maintains <code>namespaces\/<\/code>, <code>rbac\/<\/code>, <code>resourcequotas\/<\/code> in Git; every cluster in the fleet receives the same baseline.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Enforcing NetworkPolicy defaults per namespace<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Some namespaces accidentally allow unrestricted east-west traffic.<\/li>\n<li><strong>Why Config Sync fits:<\/strong> NetworkPolicy objects can be synced and kept consistent.<\/li>\n<li><strong>Scenario:<\/strong> Every namespace gets a default deny policy plus specific allow rules managed in Git.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Managing ingress\/gateway configuration consistently<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Ingress annotations and TLS settings differ per cluster, causing outages.<\/li>\n<li><strong>Why Config Sync fits:<\/strong> Ingress\/Gateway API resources can be standardized.<\/li>\n<li><strong>Scenario:<\/strong> Platform team defines a standard IngressClass and common annotations; clusters reconcile to the standard.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Standardizing observability agents (DaemonSets, ConfigMaps)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Logging\/monitoring agents differ across clusters; debugging becomes hard.<\/li>\n<li><strong>Why Config Sync fits:<\/strong> Baseline add-ons can be deployed declaratively.<\/li>\n<li><strong>Scenario:<\/strong> Sync Fluent Bit\/OTel collector manifests and standardized dashboards\/config.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Multi-cluster environment separation with Git branches\/directories<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Dev and prod should differ in a controlled way; manual changes cause drift.<\/li>\n<li><strong>Why Config Sync fits:<\/strong> Repo structures and promotion workflows can model environments.<\/li>\n<li><strong>Scenario:<\/strong> <code>clusters\/dev\/<\/code> and <code>clusters\/prod\/<\/code> directories are synced to different clusters, with PR-based promotion.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Delegated namespace admin via namespace-scoped sync<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Platform team becomes a bottleneck for every config change.<\/li>\n<li><strong>Why Config Sync fits:<\/strong> Namespace-scoped sync patterns allow teams to manage their namespace resources while the platform controls cluster-wide resources.<\/li>\n<li><strong>Scenario:<\/strong> Platform enforces cluster baselines; each team gets a namespace sync that only applies within their namespace.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) GitOps for Kubernetes CRDs and platform operators<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Operator configuration differs across clusters and breaks platform behavior.<\/li>\n<li><strong>Why Config Sync fits:<\/strong> Operators and their custom resources can be treated as configuration.<\/li>\n<li><strong>Scenario:<\/strong> Sync cert-manager configuration or gateway\/controller custom resources consistently (validate compatibility and ordering).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Managing Google Cloud resources via Config Connector (advanced)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Cloud resources (Pub\/Sub, IAM, SQL, etc.) are created inconsistently.<\/li>\n<li><strong>Why Config Sync fits:<\/strong> If you use Config Connector CRDs, Config Sync can deliver them to clusters in a controlled way.<\/li>\n<li><strong>Scenario:<\/strong> A \u201cplatform resources\u201d repo defines Pub\/Sub topics and IAM policies through Config Connector objects; changes go through PR review.<\/li>\n<li><strong>Caveat:<\/strong> Treat this as advanced; ensure strong guardrails and least-privilege.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Compliance baselines and audit readiness<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Auditors require evidence of standard controls across environments.<\/li>\n<li><strong>Why Config Sync fits:<\/strong> Git history + consistent state + logs help prove baselines.<\/li>\n<li><strong>Scenario:<\/strong> Baseline includes Pod Security settings (where applicable), restricted RBAC, and mandatory labels\/annotations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Rapid rebuild of clusters (disaster recovery \/ immutability)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Recreating clusters is slow; configuration is tribal knowledge.<\/li>\n<li><strong>Why Config Sync fits:<\/strong> Clusters \u201cre-hydrate\u201d from Git quickly after bootstrap.<\/li>\n<li><strong>Scenario:<\/strong> After a cluster recreation, register it and enable Config Sync; baseline config is applied automatically.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Controlling \u201cbreak-glass\u201d changes and drift remediation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Engineers hotfix resources directly in production, leaving undocumented drift.<\/li>\n<li><strong>Why Config Sync fits:<\/strong> Config Sync continuously reconciles; Git becomes the durable record.<\/li>\n<li><strong>Scenario:<\/strong> Break-glass changes are allowed temporarily, but must be backported into Git or will be reverted.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Multi-team platform with shared and isolated layers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Shared platform components must be stable, while teams move quickly in isolated scopes.<\/li>\n<li><strong>Why Config Sync fits:<\/strong> Supports layered config approaches (cluster baseline + namespace\/team overlays).<\/li>\n<li><strong>Scenario:<\/strong> Platform repo manages core add-ons; team repos manage app namespace resources.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>The exact feature set can evolve; verify details in official docs. The following are core, commonly documented Config Sync capabilities.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Continuous reconciliation (GitOps loop)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Periodically fetches desired state from the configured source and reconciles it into the cluster.<\/li>\n<li><strong>Why it matters:<\/strong> Prevents long-lived drift and \u201csnowflake clusters.\u201d<\/li>\n<li><strong>Practical benefit:<\/strong> A manual change to a managed object is detected and corrected.<\/li>\n<li><strong>Caveats:<\/strong> Reconciliation behavior can differ by object type and cluster policies. Some resources may be intentionally excluded or handled carefully; verify.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cluster-scoped and namespace-scoped synchronization<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Supports applying configuration at different scopes (cluster-wide vs namespace-only).<\/li>\n<li><strong>Why it matters:<\/strong> Enables multi-tenancy and delegation.<\/li>\n<li><strong>Practical benefit:<\/strong> Platform team controls cluster resources while app teams control their namespace resources.<\/li>\n<li><strong>Caveats:<\/strong> Requires careful RBAC and repo governance to avoid privilege escalation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Multiple repositories \/ multiple sync definitions (where supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Allows different repositories or paths to map to different scopes.<\/li>\n<li><strong>Why it matters:<\/strong> Separates concerns and reduces repo blast radius.<\/li>\n<li><strong>Practical benefit:<\/strong> A change in one team repo doesn\u2019t require touching the platform baseline repo.<\/li>\n<li><strong>Caveats:<\/strong> Complexity increases; establish naming conventions and ownership.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Source support (Git and\/or OCI, depending on current release)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Pulls configuration from supported sources.<\/li>\n<li><strong>Why it matters:<\/strong> Git is standard; OCI sources can align with artifact promotion pipelines.<\/li>\n<li><strong>Practical benefit:<\/strong> You can promote immutable config bundles through environments.<\/li>\n<li><strong>Caveats:<\/strong> Supported auth methods and registries vary; verify in docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Config validation and status reporting<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Reports sync status (healthy\/unhealthy), errors, and last sync time.<\/li>\n<li><strong>Why it matters:<\/strong> You need operational confidence that GitOps is working.<\/li>\n<li><strong>Practical benefit:<\/strong> Faster troubleshooting when a commit breaks reconciliation.<\/li>\n<li><strong>Caveats:<\/strong> You still need alerting\/monitoring integration and runbooks.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Drift detection and correction<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Identifies divergence from declared state and attempts to converge.<\/li>\n<li><strong>Why it matters:<\/strong> Detects unauthorized or accidental changes.<\/li>\n<li><strong>Practical benefit:<\/strong> Reduces \u201cworks in cluster A but not B\u201d incidents.<\/li>\n<li><strong>Caveats:<\/strong> Some fields are mutated by controllers; ensure your manifests align with server-side behavior.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integration with Fleet \/ GKE Enterprise (common pattern)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Centralized enablement, configuration, and visibility across multiple clusters.<\/li>\n<li><strong>Why it matters:<\/strong> At scale, you want consistent management of features across a fleet.<\/li>\n<li><strong>Practical benefit:<\/strong> Turn on Config Sync for many clusters in a controlled way.<\/li>\n<li><strong>Caveats:<\/strong> Edition\/billing requirements may apply (see Pricing section).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Works with policy guardrails (often paired with Policy Controller)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Config Sync applies config; policy guardrails can block unsafe resources.<\/li>\n<li><strong>Why it matters:<\/strong> GitOps without guardrails can still propagate mistakes rapidly.<\/li>\n<li><strong>Practical benefit:<\/strong> Enforce security posture (e.g., disallow privileged pods).<\/li>\n<li><strong>Caveats:<\/strong> Policy design requires care to avoid blocking critical workloads.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>At a high level:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Engineers commit Kubernetes configuration to a repository (the desired state).<\/li>\n<li>Config Sync reconcilers in the cluster authenticate to the repo.<\/li>\n<li>Reconcilers fetch configuration on an interval and reconcile objects into the Kubernetes API server.<\/li>\n<li>Status is reported via Kubernetes resources and (often) surfaced in Google Cloud Fleet views.<\/li>\n<li>Logging and metrics flow to Cloud Logging\/Monitoring via standard GKE telemetry.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane:<\/strong> You configure Config Sync (directly on cluster or via fleet feature).<\/li>\n<li><strong>Data plane:<\/strong> Reconcilers pull manifests from repo and apply them to the cluster API.<\/li>\n<li><strong>Feedback loop:<\/strong> Reconcilers report health; errors appear in logs\/events and status conditions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<p>Common integrations in Google Cloud:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>GKE<\/strong>: the runtime clusters.<\/li>\n<li><strong>Fleet (GKE Hub)<\/strong>: multi-cluster registration and feature management.<\/li>\n<li><strong>Cloud Logging<\/strong>: reconciler logs, Kubernetes events.<\/li>\n<li><strong>Cloud Monitoring<\/strong>: metrics (cluster + workloads); set alerts on sync failures.<\/li>\n<li><strong>IAM<\/strong>: control who can enable\/configure fleet features and who can administer clusters.<\/li>\n<li><strong>Secret Manager \/ KMS (indirect)<\/strong>: if your GitOps approach includes encrypted secrets tooling (not Config Sync itself), you may use KMS\/Secret Manager (verify supported patterns).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Kubernetes API server availability.<\/li>\n<li>Repository availability (Git hosting\/registry).<\/li>\n<li>DNS and egress from clusters to the repo endpoint (unless mirrored internally).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model (typical)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>To configure Config Sync:<\/strong> admins need Google Cloud IAM permissions (fleet feature enablement) and Kubernetes admin privileges (depending on setup).<\/li>\n<li><strong>To pull from repo:<\/strong> reconcilers use configured credentials:<\/li>\n<li>For public Git repos: no credentials required (lab-friendly).<\/li>\n<li>For private repos: credentials are usually stored as Kubernetes secrets in a system namespace (verify recommended methods in docs).<\/li>\n<li><strong>In-cluster RBAC:<\/strong> reconcilers need permissions to apply the objects they manage.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Reconcilers typically require <strong>outbound (egress)<\/strong> access to your Git\/OCI source.<\/li>\n<li>In restrictive environments:<\/li>\n<li>Allowlist egress to Git host endpoints.<\/li>\n<li>Consider private connectivity patterns (for example, internal Git hosting) if required by compliance.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Treat Config Sync as production control-plane software:<\/li>\n<li>Monitor reconciler pod health.<\/li>\n<li>Alert on sync failures and stale sync.<\/li>\n<li>Capture audit logs for changes to cluster resources.<\/li>\n<li>Use Git branch protections and PR reviews as governance gates.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  Dev[Engineer] --&gt;|PR\/Merge| Git[(Git Repository)]\n  Git --&gt;|Pull desired state| CS[Config Sync Reconciler&lt;br\/&gt;in Cluster]\n  CS --&gt;|Apply\/Update| K8s[Kubernetes API Server]\n  K8s --&gt; Workloads[Namespaces, RBAC,&lt;br\/&gt;Policies, Add-ons]\n  CS --&gt; Status[Sync Status\/Events]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph SCM[Source Control + Governance]\n    Git[(Git Repo)]\n    CI[CI Checks&lt;br\/&gt;lint\/validate\/tests]\n    PR[Pull Requests&lt;br\/&gt;approvals]\n    PR --&gt; CI --&gt; Git\n  end\n\n  subgraph GCP[Google Cloud]\n    Fleet[Fleet \/ GKE Hub&lt;br\/&gt;Feature Mgmt]\n    Logging[Cloud Logging]\n    Monitoring[Cloud Monitoring]\n  end\n\n  subgraph Clusters[Fleet Clusters (Hybrid\/Multicloud)]\n    subgraph C1[Cluster A]\n      R1[Config Sync Reconcilers]\n      API1[K8s API]\n      R1 --&gt; API1\n    end\n    subgraph C2[Cluster B]\n      R2[Config Sync Reconcilers]\n      API2[K8s API]\n      R2 --&gt; API2\n    end\n    subgraph C3[Cluster C]\n      R3[Config Sync Reconcilers]\n      API3[K8s API]\n      R3 --&gt; API3\n    end\n  end\n\n  Git --&gt; R1\n  Git --&gt; R2\n  Git --&gt; R3\n\n  Fleet --- C1\n  Fleet --- C2\n  Fleet --- C3\n\n  R1 --&gt; Logging\n  R2 --&gt; Logging\n  R3 --&gt; Logging\n\n  Monitoring --- C1\n  Monitoring --- C2\n  Monitoring --- C3\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/project requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A Google Cloud project with billing enabled.<\/li>\n<li>Permission to create and manage a GKE cluster (or access to an existing cluster).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM roles (typical; follow least privilege)<\/h3>\n\n\n\n<p>Exact roles depend on your environment and whether you use Fleet:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>For GKE cluster creation: roles like <strong>Kubernetes Engine Admin<\/strong> may be used in labs.<\/li>\n<li>For Fleet registration and feature management: roles tied to <strong>GKE Hub \/ Fleet<\/strong> administration.<\/li>\n<li>For day-to-day GitOps operations: separate roles for repo access vs cluster admin access.<\/li>\n<\/ul>\n\n\n\n<p>Because IAM role names and recommended combinations can change, <strong>verify the current required roles in official docs<\/strong> for:\n&#8211; Fleet membership registration\n&#8211; Enabling\/configuring Config Sync<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You pay for:<\/li>\n<li>The underlying GKE cluster (nodes or Autopilot resources).<\/li>\n<li>Potentially <strong>GKE Enterprise<\/strong> (or equivalent edition licensing) if required for Config Sync features in your scenario.<\/li>\n<li>You also pay for logging\/monitoring ingestion depending on volume.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools needed<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud CLI (<code>gcloud<\/code>)<\/li>\n<li><code>kubectl<\/code><\/li>\n<li><code>git<\/code><\/li>\n<li>Optional: GitHub CLI (<code>gh<\/code>) if using GitHub for the lab<\/li>\n<\/ul>\n\n\n\n<p>In Cloud Shell, these are typically preinstalled.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Config Sync runs inside clusters; availability depends on where your clusters run and where Fleet features are supported.<\/li>\n<li>For hybrid and multicloud, validate supported attached cluster types and regions in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<p>You may hit:\n&#8211; GKE cluster quotas (nodes, CPUs).\n&#8211; API enablement limits.\n&#8211; Logging ingestion volume.\n&#8211; Reconciler resource requests consuming some cluster capacity.<\/p>\n\n\n\n<p>Always check:\n&#8211; GKE quotas: https:\/\/cloud.google.com\/kubernetes-engine\/quotas\n&#8211; Relevant Fleet\/Hub quotas in documentation (verify current references).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services\/APIs (commonly needed)<\/h3>\n\n\n\n<p>Depending on your configuration method, you may need to enable:\n&#8211; Kubernetes Engine API\n&#8211; Fleet \/ GKE Hub API\n&#8211; Config management related APIs (names can evolve; verify in docs)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">The current pricing model (how to think about it)<\/h3>\n\n\n\n<p>Config Sync is typically priced <strong>indirectly<\/strong> as part of a broader Kubernetes management offering in Google Cloud (commonly associated with <strong>GKE Enterprise \/ fleet features<\/strong>), plus the underlying compute\/networking costs of your clusters.<\/p>\n\n\n\n<p>Because Google Cloud packaging and editions can change, treat pricing as:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Base Kubernetes runtime cost<\/strong>\n   &#8211; GKE Standard: pay for nodes (Compute Engine VMs) and related resources.\n   &#8211; GKE Autopilot: pay for requested pod CPU\/memory, plus some platform fees (verify).<\/p>\n<\/li>\n<li>\n<p><strong>Enterprise \/ fleet feature cost (if applicable)<\/strong>\n   &#8211; If Config Sync requires GKE Enterprise in your scenario, you may pay a <strong>management fee<\/strong> (often vCPU-based) for enrolled clusters (including attached\/on-prem clusters).\n   &#8211; Verify the exact edition requirements and SKUs.<\/p>\n<\/li>\n<li>\n<p><strong>Operational telemetry<\/strong>\n   &#8211; Cloud Logging\/Monitoring costs can be meaningful at scale.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Official pricing references (start here)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>GKE pricing: https:\/\/cloud.google.com\/kubernetes-engine\/pricing  <\/li>\n<li>GKE Enterprise pricing (verify current page structure): https:\/\/cloud.google.com\/kubernetes-engine\/enterprise\/pricing  <\/li>\n<li>Google Cloud Pricing Calculator: https:\/\/cloud.google.com\/products\/calculator<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions to consider<\/h3>\n\n\n\n<p>You typically pay for:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cluster compute<\/strong>:<\/li>\n<li>Nodes (Standard) or pod resources (Autopilot)<\/li>\n<li>Additional system pods for Config Sync consume CPU\/memory<\/li>\n<li><strong>Enterprise management fee<\/strong> (if applicable):<\/li>\n<li>Often based on vCPU-hours across enrolled clusters<\/li>\n<li><strong>Networking<\/strong>:<\/li>\n<li>Egress from clusters to external Git hosts (GitHub, GitLab, etc.)<\/li>\n<li>NAT gateway costs if using Cloud NAT for private nodes<\/li>\n<li><strong>Storage<\/strong>:<\/li>\n<li>Container images for controllers are pulled; Artifact Registry egress\/ingress costs may apply if mirrored<\/li>\n<li><strong>Logging\/Monitoring<\/strong>:<\/li>\n<li>Log volume from reconcilers, Kubernetes audit logs, and events<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<p>There is no universally \u201cfree\u201d Config Sync tier that applies to all use cases. Some components may be usable in small-scale scenarios with minimal incremental cost beyond the cluster itself, but <strong>verify<\/strong> whether your edition\/licensing requires paid SKUs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud NAT<\/strong> if you use private clusters and need outbound access to Git hosting.<\/li>\n<li><strong>Egress charges<\/strong> if syncing from repositories outside Google Cloud.<\/li>\n<li><strong>Developer productivity cost<\/strong> if repo structure and governance are not standardized (operational overhead).<\/li>\n<li><strong>Incident cost<\/strong> if GitOps pushes misconfigurations fleet-wide without guardrails.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost optimization tips<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Start with <strong>one small cluster<\/strong> and a <strong>public repo<\/strong> for proof-of-concept.<\/li>\n<li>Keep reconciler logging at reasonable verbosity (avoid excessive debug logs in production).<\/li>\n<li>Prefer <strong>regional locality<\/strong> where possible (repo hosting near clusters, or internal mirrors).<\/li>\n<li>Use a structured repo and CI validation to prevent \u201cbad commits\u201d from causing broad impact.<\/li>\n<li>If using many clusters, evaluate whether fleet\/enterprise licensing is cost-effective relative to your operational overhead savings.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (conceptual, no fabricated numbers)<\/h3>\n\n\n\n<p>A starter lab often includes:\n&#8211; 1 zonal GKE Standard cluster with 1 small node\n&#8211; Config Sync enabled\n&#8211; Public Git repo\n&#8211; Minimal logging volume<\/p>\n\n\n\n<p>Your incremental cost is mostly:\n&#8211; The node VM cost (Compute Engine)\n&#8211; Any cluster management fee (if applicable to your edition)\n&#8211; Minor egress (Git pulls) and log ingestion<\/p>\n\n\n\n<p>Use the Pricing Calculator to model:\n&#8211; VM type + hours\n&#8211; Cloud NAT (if used)\n&#8211; Logging volume (GB\/day)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production, cost planning should account for:\n&#8211; 10\u2013200+ clusters (distributed, hybrid, and multicloud)\n&#8211; Enterprise licensing\/fees (often dominant for large fleets)\n&#8211; Higher logging\/audit requirements\n&#8211; Private networking controls (NAT, firewalls, possibly repo mirroring)\n&#8211; CI pipelines and artifact storage if using OCI-based config bundles<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Enable <strong>Config Sync<\/strong> on a GKE cluster in Google Cloud and synchronize a small set of Kubernetes objects from a Git repository. You will verify that Config Sync applies the objects and keeps them reconciled.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Create (or use) a Google Cloud project and a small GKE cluster.<\/li>\n<li>Register the cluster to a Fleet (common in distributed, hybrid, and multicloud operations).<\/li>\n<li>Enable Config Sync and point it to a Git repository path.<\/li>\n<li>Commit Kubernetes manifests to Git and watch them appear in the cluster.<\/li>\n<li>Validate sync status and troubleshoot common issues.<\/li>\n<li>Clean up resources to avoid ongoing costs.<\/li>\n<\/ol>\n\n\n\n<blockquote>\n<p>This lab uses a <strong>public GitHub repository<\/strong> to avoid credentials handling. For production, you will typically use private repos with controlled access.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Set up your environment (project, tools, variables)<\/h3>\n\n\n\n<p>1) Open <strong>Cloud Shell<\/strong> in the Google Cloud console.<\/p>\n\n\n\n<p>2) Set variables:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export PROJECT_ID=\"YOUR_PROJECT_ID\"\nexport REGION=\"us-central1\"\nexport ZONE=\"us-central1-a\"\nexport CLUSTER_NAME=\"gke-config-sync-lab\"\n<\/code><\/pre>\n\n\n\n<p>3) Set your project:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud config set project \"$PROJECT_ID\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> <code>gcloud<\/code> now targets your project.<\/p>\n\n\n\n<p>4) Enable required APIs.<\/p>\n\n\n\n<p>The exact APIs can vary by current product packaging, but you typically need at least:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Kubernetes Engine API<\/li>\n<li>Fleet\/GKE Hub API<\/li>\n<\/ul>\n\n\n\n<p>Run:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable container.googleapis.com gkehub.googleapis.com\n<\/code><\/pre>\n\n\n\n<p>If official docs require additional APIs for Config Sync in your environment, enable them as well (<strong>verify in official docs<\/strong>).<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> APIs enable successfully.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create a small GKE cluster (low-cost starter)<\/h3>\n\n\n\n<p>Create a <strong>zonal<\/strong> GKE Standard cluster with a small node pool (adjust to your quota and preferences):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container clusters create \"$CLUSTER_NAME\" \\\n  --zone \"$ZONE\" \\\n  --num-nodes 1 \\\n  --machine-type \"e2-medium\" \\\n  --release-channel \"regular\"\n<\/code><\/pre>\n\n\n\n<p>Get cluster credentials:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container clusters get-credentials \"$CLUSTER_NAME\" --zone \"$ZONE\"\n<\/code><\/pre>\n\n\n\n<p>Check access:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl get nodes\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You see 1 node in <code>Ready<\/code> state.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Register the cluster to a Fleet (recommended for multi-cluster operations)<\/h3>\n\n\n\n<p>Register your cluster as a Fleet membership.<\/p>\n\n\n\n<blockquote>\n<p>The exact flags can change. If the following command doesn\u2019t match your installed <code>gcloud<\/code> version, run <code>gcloud container fleet memberships register --help<\/code> and adapt, or follow the current official docs.<\/p>\n<\/blockquote>\n\n\n\n<p>A common pattern looks like:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container fleet memberships register \"${CLUSTER_NAME}-membership\" \\\n  --gke-cluster=\"${ZONE}\/${CLUSTER_NAME}\" \\\n  --enable-workload-identity\n<\/code><\/pre>\n\n\n\n<p>Confirm memberships:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container fleet memberships list\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Your membership appears in the list.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create a public GitHub repo with Kubernetes manifests<\/h3>\n\n\n\n<p>You need a repository that Config Sync can read.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Option A: Use GitHub CLI (<code>gh<\/code>) (fastest)<\/h4>\n\n\n\n<p>1) Authenticate:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gh auth login\n<\/code><\/pre>\n\n\n\n<p>2) Create a public repo:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export GH_REPO_NAME=\"config-sync-lab\"\ngh repo create \"$GH_REPO_NAME\" --public --clone\ncd \"$GH_REPO_NAME\"\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">Option B: Create a repo in the GitHub UI<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create a new <strong>public<\/strong> repo named <code>config-sync-lab<\/code>.<\/li>\n<li>Clone it in Cloud Shell:<\/li>\n<\/ul>\n\n\n\n<pre><code class=\"language-bash\">git clone https:\/\/github.com\/YOUR_GITHUB_USERNAME\/config-sync-lab.git\ncd config-sync-lab\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">Add manifests<\/h4>\n\n\n\n<p>Create a directory that represents your cluster policy directory:<\/p>\n\n\n\n<pre><code class=\"language-bash\">mkdir -p clusters\/$CLUSTER_NAME\n<\/code><\/pre>\n\n\n\n<p>Create a namespace manifest:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; clusters\/$CLUSTER_NAME\/namespace.yaml &lt;&lt;'EOF'\napiVersion: v1\nkind: Namespace\nmetadata:\n  name: team-a\nEOF\n<\/code><\/pre>\n\n\n\n<p>Create a ConfigMap manifest:<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; clusters\/$CLUSTER_NAME\/configmap.yaml &lt;&lt;'EOF'\napiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: team-a-demo\n  namespace: team-a\ndata:\n  message: \"Hello from Config Sync\"\nEOF\n<\/code><\/pre>\n\n\n\n<p>Commit and push:<\/p>\n\n\n\n<pre><code class=\"language-bash\">git add clusters\/$CLUSTER_NAME\ngit commit -m \"Add initial config for Config Sync lab\"\ngit push -u origin main\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Your Git repository contains two manifests under <code>clusters\/&lt;cluster-name&gt;\/<\/code>.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Enable Config Sync and point it to your repository<\/h3>\n\n\n\n<p>There are multiple supported ways to configure Config Sync (cluster-local vs fleet-managed). This lab uses a <strong>fleet-managed<\/strong> approach because it aligns with distributed, hybrid, and multicloud operations.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">5.1 Enable the Config Sync feature in your Fleet<\/h4>\n\n\n\n<p>Run (command group may vary slightly by <code>gcloud<\/code> version; verify with <code>--help<\/code>):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container fleet config-management enable\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Config management feature is enabled for the Fleet.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">5.2 Apply Config Sync configuration for your membership<\/h4>\n\n\n\n<p>Create a fleet configuration file. The schema can evolve; use this as a baseline and <strong>verify against current official docs<\/strong> if fields differ.<\/p>\n\n\n\n<pre><code class=\"language-bash\">cat &gt; config-sync-fleet-config.yaml &lt;&lt;EOF\nmembershipSpecs:\n  ${CLUSTER_NAME}-membership:\n    configmanagement:\n      configSync:\n        enabled: true\n        sourceFormat: unstructured\n        git:\n          syncRepo: https:\/\/github.com\/YOUR_GITHUB_USERNAME\/config-sync-lab.git\n          syncBranch: main\n          policyDir: clusters\/${CLUSTER_NAME}\n          secretType: none\nEOF\n<\/code><\/pre>\n\n\n\n<p>Apply it:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container fleet config-management apply \\\n  --config config-sync-fleet-config.yaml\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Config Sync components begin installing into the cluster, and the cluster starts syncing from the repo.<\/p>\n\n\n\n<blockquote>\n<p>If your environment uses a different command (for example, <code>gcloud beta ...<\/code>), follow the current official documentation for Config Sync + Fleet. Avoid relying on outdated ACM-era commands unless the docs explicitly direct you there.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Observe installation and sync progress<\/h3>\n\n\n\n<p>Config Sync typically installs components into a system namespace (commonly <code>config-management-system<\/code>). Check namespaces:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl get ns | grep -E \"config|management\" || true\n<\/code><\/pre>\n\n\n\n<p>Check pods (adjust namespace if your installation uses a different one\u2014verify in docs):<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n config-management-system get pods\n<\/code><\/pre>\n\n\n\n<p>Look for reconciler pods and confirm they are <code>Running<\/code>.<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> Several pods in <code>config-management-system<\/code> are running.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Validate that objects from Git appear in the cluster<\/h3>\n\n\n\n<p>Check that your namespace exists:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl get ns team-a\n<\/code><\/pre>\n\n\n\n<p>Check the ConfigMap:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n team-a get configmap team-a-demo -o yaml\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> <code>team-a<\/code> namespace and <code>team-a-demo<\/code> ConfigMap exist, with the <code>message<\/code> value from Git.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Demonstrate drift correction (optional but recommended)<\/h3>\n\n\n\n<p>1) Manually edit the ConfigMap in the cluster:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n team-a patch configmap team-a-demo \\\n  --type merge \\\n  -p '{\"data\":{\"message\":\"I changed this manually\"}}'\n<\/code><\/pre>\n\n\n\n<p>2) Confirm the change took effect:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n team-a get configmap team-a-demo -o jsonpath='{.data.message}'; echo\n<\/code><\/pre>\n\n\n\n<p>3) Wait a short period (Config Sync sync interval varies; verify in docs), then re-check:<\/p>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n team-a get configmap team-a-demo -o jsonpath='{.data.message}'; echo\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> After reconciliation, the value returns to <code>Hello from Config Sync<\/code> (the Git declared state), assuming the object is managed and reconciliation is functioning normally.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Fleet membership exists:<\/li>\n<\/ul>\n\n\n\n<pre><code class=\"language-bash\">gcloud container fleet memberships list\n<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Config Sync pods are running:<\/li>\n<\/ul>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n config-management-system get pods\n<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Synced resources exist:<\/li>\n<\/ul>\n\n\n\n<pre><code class=\"language-bash\">kubectl get ns team-a\nkubectl -n team-a get configmap team-a-demo\n<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Logs show successful sync (example; pod name will differ):<\/li>\n<\/ul>\n\n\n\n<pre><code class=\"language-bash\">kubectl -n config-management-system logs -l app=reconciler --tail=100\n<\/code><\/pre>\n\n\n\n<p>If label selectors differ in your version, list pods first and then pick the reconciler pod to inspect logs.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues and practical fixes:<\/p>\n\n\n\n<p>1) <strong>Pods not installing<\/strong>\n&#8211; <strong>Symptoms:<\/strong> <code>config-management-system<\/code> namespace doesn\u2019t exist, or pods never appear.\n&#8211; <strong>Fixes:<\/strong>\n  &#8211; Confirm Fleet feature enabled:\n    <code>bash\n    gcloud container fleet config-management status<\/code>\n    (If this command differs, use <code>--help<\/code>.)\n  &#8211; Confirm membership is registered and healthy:\n    <code>bash\n    gcloud container fleet memberships describe ${CLUSTER_NAME}-membership<\/code>\n  &#8211; Check cluster events:\n    <code>bash\n    kubectl get events -A --sort-by=.lastTimestamp | tail -n 50<\/code><\/p>\n\n\n\n<p>2) <strong>Repo sync fails (authentication\/404)<\/strong>\n&#8211; <strong>Symptoms:<\/strong> Reconciler logs show Git clone errors, 404, or auth failures.\n&#8211; <strong>Fixes:<\/strong>\n  &#8211; Ensure repo URL is correct and accessible from the cluster.\n  &#8211; If using a private repo, configure the correct secret type and credentials (follow official docs).\n  &#8211; Ensure branch and directory exist (<code>main<\/code>, <code>clusters\/&lt;cluster-name&gt;<\/code>).<\/p>\n\n\n\n<p>3) <strong>Resources not applied<\/strong>\n&#8211; <strong>Symptoms:<\/strong> Pods are running, but namespace\/configmap not created.\n&#8211; <strong>Fixes:<\/strong>\n  &#8211; Verify <code>policyDir<\/code> matches repo path exactly (case-sensitive).\n  &#8211; Validate manifests in the repo are valid Kubernetes objects.\n  &#8211; Check reconciler logs for validation errors.<\/p>\n\n\n\n<p>4) <strong>Network egress blocked<\/strong>\n&#8211; <strong>Symptoms:<\/strong> Timeouts connecting to GitHub.\n&#8211; <strong>Fixes:<\/strong>\n  &#8211; If using private nodes, ensure Cloud NAT is configured and firewall rules allow egress.\n  &#8211; Ensure corporate egress policies allow Git host endpoints.<\/p>\n\n\n\n<p>5) <strong>Conflicts with other deployers<\/strong>\n&#8211; <strong>Symptoms:<\/strong> Another tool (Helm, Terraform, Argo CD) is also managing the same objects, causing churn.\n&#8211; <strong>Fixes:<\/strong>\n  &#8211; Establish ownership boundaries: one tool per object set.\n  &#8211; Use separate namespaces and clear labeling\/ownership rules.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing charges, delete the cluster and (optionally) remove Fleet membership.<\/p>\n\n\n\n<p>1) Delete the GKE cluster:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container clusters delete \"$CLUSTER_NAME\" --zone \"$ZONE\" --quiet\n<\/code><\/pre>\n\n\n\n<p>2) Unregister Fleet membership (command may vary; verify with <code>--help<\/code>):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container fleet memberships delete \"${CLUSTER_NAME}-membership\" --quiet\n<\/code><\/pre>\n\n\n\n<p>3) Optionally disable the feature:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud container fleet config-management disable\n<\/code><\/pre>\n\n\n\n<p>4) Delete the GitHub repo if you created it for the lab:\n&#8211; In GitHub UI: Settings \u2192 Danger Zone \u2192 Delete this repository<br\/>\n  or with <code>gh<\/code>:\n  <code>bash\n  gh repo delete YOUR_GITHUB_USERNAME\/config-sync-lab --yes<\/code><\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Start with baselines<\/strong>: namespaces, RBAC, quotas, and network policies are great initial targets.<\/li>\n<li><strong>Layer your configuration<\/strong>:<\/li>\n<li>Cluster baseline (platform-owned)<\/li>\n<li>Namespace\/team layer (team-owned)<\/li>\n<li>App layer (app team-owned) \u2014 consider whether Config Sync is the right tool vs an app-focused GitOps controller.<\/li>\n<li><strong>Prefer multiple sync scopes<\/strong> (where supported) to reduce blast radius.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Separate repo write access from cluster-admin<\/strong> access.<\/li>\n<li>Use <strong>protected branches<\/strong> and required approvals for production directories.<\/li>\n<li>Restrict who can modify Config Sync configuration itself (repo URL, branch, directory).<\/li>\n<li>Use least-privilege Kubernetes RBAC for namespaces and team-level sync.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep clusters right-sized; reconcilers consume capacity.<\/li>\n<li>Reduce unnecessary log volume; create targeted alerts rather than logging everything at debug level.<\/li>\n<li>Be aware of egress to external Git providers; consider hosting repos in locations that reduce egress costs and latency.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep repo structure clean and avoid extremely large directories per cluster.<\/li>\n<li>Use CI to validate manifests before merge (schema validation, policy checks).<\/li>\n<li>Consider the operational impact of syncing large numbers of objects frequently.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Treat Git hosting as a critical dependency.<\/li>\n<li>Use redundant Git hosting or high-availability SCM plans if your GitOps loop is mission-critical.<\/li>\n<li>Establish rollback procedures (revert commits; ensure sync catches up predictably).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create alerts on:<\/li>\n<li>Sync failures<\/li>\n<li>Stale sync (no successful sync in X minutes)<\/li>\n<li>Reconciler pod crash loops<\/li>\n<li>Establish runbooks for:<\/li>\n<li>Broken commit handling<\/li>\n<li>Emergency pause procedures (if supported) or branch rollback strategy<\/li>\n<li>Use consistent labeling\/annotation standards across synced objects.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use consistent directory naming: <code>clusters\/&lt;cluster-name&gt;<\/code> or <code>environments\/&lt;env&gt;\/clusters\/&lt;cluster&gt;<\/code>.<\/li>\n<li>Document ownership in <code>CODEOWNERS<\/code> and repo README.<\/li>\n<li>Use naming conventions for namespaces, service accounts, and roles.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Google Cloud IAM<\/strong> controls who can:<\/li>\n<li>Create clusters<\/li>\n<li>Register memberships to Fleet<\/li>\n<li>Enable\/configure Config Sync feature<\/li>\n<li><strong>Kubernetes RBAC<\/strong> controls what reconcilers can apply and what users can do in-cluster.<\/li>\n<\/ul>\n\n\n\n<p>Key security goal: engineers should not need cluster-admin to make standard configuration changes\u2014Git PRs should be the primary path.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Data in transit:<\/li>\n<li>Repo access uses HTTPS\/SSH (depending on your setup).<\/li>\n<li>Data at rest:<\/li>\n<li>Kubernetes secrets and etcd encryption depend on cluster configuration.<\/li>\n<li>Git repo encryption depends on your SCM provider.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Reconcilers require egress to the repo host.<\/li>\n<li>In restricted environments:<\/li>\n<li>Use private clusters + NAT + strict firewall egress rules.<\/li>\n<li>Consider internal Git hosting.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<p>Config Sync is for syncing Kubernetes objects; storing plaintext secrets in Git is a common anti-pattern.<\/p>\n\n\n\n<p>Safer approaches include:\n&#8211; Use external secret systems (Secret Manager + external secrets operators) and sync only references.\n&#8211; Use encryption workflows (for example, SOPS) if your platform supports it\u2014<strong>verify compatibility and operational maturity<\/strong>.\n&#8211; Restrict which namespaces and objects teams can manage.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable and retain:<\/li>\n<li>Git repo audit logs (SCM-side)<\/li>\n<li>Kubernetes audit logs (cluster-side)<\/li>\n<li>Config Sync reconciler logs (operational debugging)<\/li>\n<li>Centralize logs and define retention per compliance needs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Demonstrate change control:<\/li>\n<li>PR reviews<\/li>\n<li>required CI checks<\/li>\n<li>traceability from incident \u2192 commit \u2192 applied resources<\/li>\n<li>Ensure secrets and regulated data are not stored in Git.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Allowing broad write access to the repo paths that define cluster-admin resources.<\/li>\n<li>Syncing overly privileged RBAC into many clusters without review.<\/li>\n<li>Managing secrets in plaintext in Git.<\/li>\n<li>Not restricting who can alter the Config Sync source (repo\/branch), enabling supply-chain attacks.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use branch protections and code owners for critical directories.<\/li>\n<li>Consider signed commits\/tags (SCM feature) for production config repos.<\/li>\n<li>Pair with policy enforcement to block risky resources from being applied fleet-wide.<\/li>\n<li>Limit reconcilers to only needed permissions; avoid \u201capply-anything\u201d patterns.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Because Config Sync evolves, verify the latest constraints in official docs. Common limitations\/gotchas include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Not an application delivery system by itself<\/strong>: Config Sync is best for configuration\/state, not advanced progressive delivery.<\/li>\n<li><strong>Conflicting managers<\/strong>: If multiple tools manage the same resource fields, you can get reconciliation loops.<\/li>\n<li><strong>Repo dependency<\/strong>: If repo access is down, clusters may not receive updates; they typically continue running with last applied config.<\/li>\n<li><strong>Egress\/network constraints<\/strong>: Private clusters require NAT\/egress setup to reach external Git providers.<\/li>\n<li><strong>Large repos can slow troubleshooting<\/strong>: Without structure, it\u2019s hard to isolate failures.<\/li>\n<li><strong>Secret management complexity<\/strong>: GitOps + secrets requires a secure pattern; don\u2019t improvise.<\/li>\n<li><strong>Field mutations by controllers<\/strong>: Some Kubernetes controllers mutate resources; ensure your Git definitions align with actual state and your GitOps tool\u2019s comparison approach.<\/li>\n<li><strong>CRD ordering<\/strong>: Applying CRDs and CRs requires careful ordering; changes can fail if CRDs aren\u2019t present yet.<\/li>\n<li><strong>RBAC self-lockout<\/strong>: A misconfigured RBAC commit can lock you out; keep break-glass access and tested rollback procedures.<\/li>\n<li><strong>Edition\/licensing requirements<\/strong>: In some environments, Config Sync use is tied to GKE Enterprise\/fleet feature licensing\u2014confirm before large rollouts.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Config Sync is one option in the Kubernetes configuration management space. Here\u2019s how it commonly compares.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Key alternatives (Google Cloud, other clouds, open source)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Google Cloud alternatives\/adjacent<\/strong><\/li>\n<li>Cloud Deploy (application delivery pipeline; different goal)<\/li>\n<li>Terraform (infrastructure provisioning; not continuous in-cluster reconciliation unless engineered)<\/li>\n<li>Helm (packaging; not inherently continuous reconciliation unless combined with an operator)<\/li>\n<li><strong>Other clouds<\/strong><\/li>\n<li>Azure Arc GitOps (Flux-based) for multi-cluster GitOps in Azure ecosystems<\/li>\n<li>AWS EKS GitOps patterns (commonly Argo CD\/Flux; AWS-specific integrations)<\/li>\n<li><strong>Open-source \/ self-managed<\/strong><\/li>\n<li>Argo CD<\/li>\n<li>Flux CD<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Config Sync (Google Cloud)<\/strong><\/td>\n<td>Fleet-wide Kubernetes config consistency in Google Cloud ecosystems<\/td>\n<td>Deep integration with GKE\/Fleet; strong for baselines and multi-cluster ops; continuous reconciliation<\/td>\n<td>Edition\/licensing considerations; less \u201capp delivery\u201d focused than some tools<\/td>\n<td>You run GKE\/fleet at scale and want Google Cloud-aligned GitOps for cluster configuration<\/td>\n<\/tr>\n<tr>\n<td><strong>Argo CD (self-managed)<\/strong><\/td>\n<td>Application delivery + GitOps dashboards and multi-tenant app management<\/td>\n<td>Rich UI; app-centric model; broad ecosystem<\/td>\n<td>You operate and secure it yourself; multi-cluster governance is on you<\/td>\n<td>You want a popular app-focused GitOps controller and can operate it reliably<\/td>\n<\/tr>\n<tr>\n<td><strong>Flux CD (self-managed)<\/strong><\/td>\n<td>GitOps with Kubernetes-native APIs and strong Git\/OCI integration<\/td>\n<td>Kubernetes-native; flexible; strong ecosystem<\/td>\n<td>You operate it; troubleshooting can be complex<\/td>\n<td>You prefer CNCF GitOps tooling and want maximum portability across clouds<\/td>\n<\/tr>\n<tr>\n<td><strong>Terraform<\/strong><\/td>\n<td>Provisioning cloud infrastructure + some Kubernetes resources<\/td>\n<td>Great for infra lifecycle; state management<\/td>\n<td>Not inherently continuous drift correction inside cluster; can conflict with GitOps controllers<\/td>\n<td>You primarily need infrastructure provisioning and controlled applies, not continuous reconciliation<\/td>\n<\/tr>\n<tr>\n<td><strong>Cloud Deploy (Google Cloud)<\/strong><\/td>\n<td>Progressive delivery pipelines for apps on GKE<\/td>\n<td>Release orchestration, promotions, delivery strategies<\/td>\n<td>Not a cluster baseline GitOps system<\/td>\n<td>You need application release pipelines, not fleet baseline configuration<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: regulated company with hybrid fleet<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A financial institution runs dozens of clusters across Google Cloud and on-prem. Auditors require proof of consistent security controls (RBAC, network segmentation, logging).<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Fleet registers all clusters (cloud + on-prem\/attached where supported).<\/li>\n<li>Config Sync applies:<ul>\n<li>namespace baselines<\/li>\n<li>RBAC roles\/bindings<\/li>\n<li>NetworkPolicy templates<\/li>\n<li>observability agent configuration<\/li>\n<\/ul>\n<\/li>\n<li>Separate repos\/paths for:<ul>\n<li>global baseline controls (platform-owned)<\/li>\n<li>business-unit namespaces (delegated)<\/li>\n<\/ul>\n<\/li>\n<li>Central logging\/monitoring alerts on sync failures and drift.<\/li>\n<li><strong>Why Config Sync was chosen:<\/strong><\/li>\n<li>Aligns with Google Cloud fleet management.<\/li>\n<li>Standardizes configuration across distributed, hybrid, and multicloud clusters.<\/li>\n<li>Improves auditability through Git history and consistent enforcement.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Reduced drift-related incidents.<\/li>\n<li>Faster audit evidence generation.<\/li>\n<li>Clear ownership boundaries between platform and app teams.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: fast-moving SaaS on GKE<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A startup has one production cluster and one staging cluster. Manual <code>kubectl apply<\/code> changes are frequent; staging diverges from production.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Config Sync on both clusters, each pointing to environment-specific directories in the same repo.<\/li>\n<li>PR-based changes with lightweight CI validation.<\/li>\n<li>Minimal baseline: namespaces, resource quotas, a few shared configmaps, and ingress defaults.<\/li>\n<li><strong>Why Config Sync was chosen:<\/strong><\/li>\n<li>Low operational overhead compared to running a full GitOps UI\/controller stack.<\/li>\n<li>Enables repeatable environments and easy rollback by reverting commits.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Staging and prod stay aligned by design.<\/li>\n<li>Faster onboarding for new engineers (Git as documentation).<\/li>\n<li>Fewer \u201cworks on staging only\u201d outages.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Config Sync the same as Anthos Config Management?<\/strong><br\/>\nConfig Sync functionality historically lived under Anthos Config Management (ACM). Google Cloud now commonly documents <strong>Config Sync<\/strong> as the GitOps sync component. You may still find ACM references in older content\u2014verify current naming and workflows in official docs.<\/p>\n\n\n\n<p>2) <strong>Does Config Sync deploy applications?<\/strong><br\/>\nIt can apply Kubernetes manifests, including app resources, but it is typically used for <strong>cluster and platform configuration<\/strong>. For advanced app delivery (progressive rollouts, promotions), consider app-delivery tools and evaluate how they integrate.<\/p>\n\n\n\n<p>3) <strong>How does Config Sync prevent configuration drift?<\/strong><br\/>\nReconcilers continuously compare desired state (repo) to cluster state and reconcile differences by applying the declared configuration.<\/p>\n\n\n\n<p>4) <strong>Can I use Config Sync with multiple clusters?<\/strong><br\/>\nYes. It is commonly used with Fleet to apply consistent configuration across many clusters\u2014especially in distributed, hybrid, and multicloud setups.<\/p>\n\n\n\n<p>5) <strong>Can different teams manage their own namespaces without cluster-admin access?<\/strong><br\/>\nOften yes, using namespace-scoped sync patterns plus Kubernetes RBAC and repo governance. Design carefully to prevent privilege escalation.<\/p>\n\n\n\n<p>6) <strong>Where do Config Sync controllers run?<\/strong><br\/>\nIn the cluster, as Kubernetes workloads (controllers\/reconcilers) in a system namespace.<\/p>\n\n\n\n<p>7) <strong>What repository types are supported?<\/strong><br\/>\nGit is common; some versions also support OCI sources. Supported auth methods and endpoints vary\u2014verify in official docs for your release.<\/p>\n\n\n\n<p>8) <strong>How do I handle secrets with Config Sync?<\/strong><br\/>\nAvoid plaintext secrets in Git. Use external secret managers\/operators or encryption workflows. Validate your approach with security requirements and official recommendations.<\/p>\n\n\n\n<p>9) <strong>Does Config Sync work with private clusters (no public nodes)?<\/strong><br\/>\nYes, but you must provide outbound access to the repo (often via Cloud NAT) and allow necessary egress.<\/p>\n\n\n\n<p>10) <strong>What happens if the repo is down?<\/strong><br\/>\nClusters generally continue running with the last applied configuration. Updates can\u2019t be pulled until connectivity is restored. Plan repo availability accordingly.<\/p>\n\n\n\n<p>11) <strong>Can Config Sync break my cluster if I commit a bad change?<\/strong><br\/>\nIt can apply misconfigurations if they pass validation and admission controls. Use PR reviews, CI checks, and policy guardrails to reduce risk.<\/p>\n\n\n\n<p>12) <strong>How do I see if a cluster is in sync?<\/strong><br\/>\nYou can inspect reconciler status in-cluster (custom resource status\/conditions) and, when integrated, use Fleet views. Check logs\/events for errors.<\/p>\n\n\n\n<p>13) <strong>Can I pause Config Sync?<\/strong><br\/>\nMechanisms vary by version and configuration approach. Some organizations use branch strategies (stop merging) or feature disablement in emergencies. Verify supported \u201cpause\u201d approaches in official docs.<\/p>\n\n\n\n<p>14) <strong>How is Config Sync different from Terraform?<\/strong><br\/>\nTerraform is typically used for provisioning infrastructure with explicit apply cycles and state. Config Sync continuously reconciles Kubernetes objects from a repo.<\/p>\n\n\n\n<p>15) <strong>Does Config Sync replace Helm?<\/strong><br\/>\nNot necessarily. Helm is a packaging tool; Config Sync is a reconciliation system. You may use Helm to generate manifests and store outputs in Git, but ensure you have a clear workflow and ownership model.<\/p>\n\n\n\n<p>16) <strong>What\u2019s the first thing to sync in a new organization?<\/strong><br\/>\nStart with low-risk, high-value baselines: namespaces, RBAC, resource quotas, and network policies.<\/p>\n\n\n\n<p>17) <strong>Do I need GKE Enterprise to use Config Sync?<\/strong><br\/>\nOften Config Sync is positioned within GKE Enterprise \/ fleet feature sets, especially for hybrid and multicloud fleets. Requirements can change\u2014verify current edition requirements and pricing pages.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Config Sync<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Config Sync overview<\/td>\n<td>Best starting point for current concepts, components, and supported patterns: https:\/\/cloud.google.com\/anthos-config-management\/docs\/config-sync-overview<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Config Sync installation\/configuration guides<\/td>\n<td>Step-by-step procedures for enabling Config Sync (cluster\/fleet methods). Navigate from the overview to current setup guides.<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Fleet \/ GKE Hub documentation<\/td>\n<td>Essential for multi-cluster enablement and visibility: https:\/\/cloud.google.com\/kubernetes-engine\/fleet-management\/docs\/fleet-concepts (verify exact URL structure)<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>GKE pricing<\/td>\n<td>Understand cluster runtime cost: https:\/\/cloud.google.com\/kubernetes-engine\/pricing<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>GKE Enterprise pricing<\/td>\n<td>Understand enterprise\/fleet feature fees (verify edition requirements): https:\/\/cloud.google.com\/kubernetes-engine\/enterprise\/pricing<\/td>\n<\/tr>\n<tr>\n<td>Pricing tool<\/td>\n<td>Google Cloud Pricing Calculator<\/td>\n<td>Model node\/Autopilot, NAT, and logging costs: https:\/\/cloud.google.com\/products\/calculator<\/td>\n<\/tr>\n<tr>\n<td>Official docs (adjacent)<\/td>\n<td>Cloud Logging for GKE<\/td>\n<td>Plan log ingestion, retention, and alerting: https:\/\/cloud.google.com\/logging\/docs<\/td>\n<\/tr>\n<tr>\n<td>Official docs (adjacent)<\/td>\n<td>Cloud Monitoring for GKE<\/td>\n<td>Build dashboards\/alerts for sync health and cluster signals: https:\/\/cloud.google.com\/monitoring\/docs<\/td>\n<\/tr>\n<tr>\n<td>Official docs (adjacent)<\/td>\n<td>Kubernetes Engine quotas<\/td>\n<td>Avoid quota surprises: https:\/\/cloud.google.com\/kubernetes-engine\/quotas<\/td>\n<\/tr>\n<tr>\n<td>Community (highly trusted)<\/td>\n<td>CNCF GitOps (general learning)<\/td>\n<td>Helpful GitOps concepts that complement Config Sync usage: https:\/\/www.cncf.io\/ (search GitOps resources)<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<p>The following providers are listed as training resources. Verify course availability, syllabus depth, and trainer credentials directly on each website.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, platform teams<\/td>\n<td>DevOps, Kubernetes, GitOps, CI\/CD foundations that support Config Sync adoption<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate DevOps learners<\/td>\n<td>SCM, DevOps fundamentals, process and tooling overview<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud ops engineers, cloud beginners<\/td>\n<td>Cloud operations, monitoring, operational readiness<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, operations teams<\/td>\n<td>Reliability engineering practices, monitoring, incident response<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops teams exploring AIOps<\/td>\n<td>AIOps concepts, automation and operations analytics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<p>These sites are provided as trainer\/platform directories. Validate specific Config Sync or Google Cloud Kubernetes coverage on the respective sites.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/Kubernetes training and guidance (verify offerings)<\/td>\n<td>Individuals and teams seeking coaching<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps tooling and practices (verify offerings)<\/td>\n<td>Beginners to intermediate DevOps engineers<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps support\/training (verify offerings)<\/td>\n<td>Teams needing short-term help or mentoring<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and enablement (verify offerings)<\/td>\n<td>Ops teams needing implementation support<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<p>These companies are listed as consulting resources. Confirm service scope, references, and statements of work directly with the providers.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company Name<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify scope)<\/td>\n<td>Kubernetes operations, platform engineering, CI\/CD<\/td>\n<td>GitOps adoption planning, cluster baseline standardization, operational runbooks<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps consulting and enablement (verify scope)<\/td>\n<td>Training + implementation support for DevOps\/Kubernetes<\/td>\n<td>Config Sync rollout guidance, GitOps repo design workshops, platform team upskilling<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify scope)<\/td>\n<td>DevOps process\/tooling and automation<\/td>\n<td>GitOps operating model setup, CI validation pipelines, multi-cluster governance approach<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Config Sync<\/h3>\n\n\n\n<p>To use Config Sync effectively, learn:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Kubernetes fundamentals<\/strong><\/li>\n<li>Objects: Namespace, Deployment, Service, ConfigMap, Secret<\/li>\n<li>RBAC: Role\/ClusterRole + bindings<\/li>\n<li>Admission control concepts<\/li>\n<li><strong>Git fundamentals<\/strong><\/li>\n<li>Branching, PRs, merges, revert<\/li>\n<li>Code review workflows<\/li>\n<li><strong>GKE fundamentals<\/strong><\/li>\n<li>Cluster types, node pools, networking, identities<\/li>\n<li><strong>Operational basics<\/strong><\/li>\n<li>Logging, monitoring, alerts, incident response basics<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Config Sync<\/h3>\n\n\n\n<p>Once you have GitOps synchronization working, expand into:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Policy and guardrails<\/strong><\/li>\n<li>Policy Controller \/ admission controls (verify current Google Cloud offering)<\/li>\n<li>Organization policy and IAM governance<\/li>\n<li><strong>Progressive delivery<\/strong><\/li>\n<li>Cloud Deploy or Argo Rollouts style concepts<\/li>\n<li><strong>Multi-cluster networking and service connectivity<\/strong><\/li>\n<li>Service mesh, gateway patterns, cross-cluster communication<\/li>\n<li><strong>Security posture<\/strong><\/li>\n<li>Workload Identity, secret management patterns, supply chain security<\/li>\n<li><strong>Platform engineering<\/strong><\/li>\n<li>Golden paths, templates, developer portals<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform Engineer<\/li>\n<li>DevOps Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Cloud Engineer<\/li>\n<li>Security Engineer (cloud\/k8s)<\/li>\n<li>Solutions Architect (cloud-native)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<p>There is no \u201cConfig Sync certification\u201d by itself. Commonly relevant certifications include:\n&#8211; Google Cloud professional certifications (Cloud Architect, DevOps Engineer, etc.)\n&#8211; Kubernetes certifications (CKA\/CKAD\/CKS)<\/p>\n\n\n\n<p>Verify current Google Cloud certification catalog: https:\/\/cloud.google.com\/learn\/certification<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a \u201ccluster baseline\u201d repo: namespaces, quotas, RBAC, network policies.<\/li>\n<li>Implement environment promotion: dev \u2192 staging \u2192 prod via PRs and protected branches.<\/li>\n<li>Add CI validation: <code>kubeval<\/code>\/schema validation, policy checks (tooling choice depends on your stack).<\/li>\n<li>Implement break-glass procedures and rollback runbooks.<\/li>\n<li>Measure drift: intentionally change cluster resources and confirm reconciliation behavior.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>GitOps:<\/strong> Operational model where Git is the source of truth for system configuration and automation reconciles runtime state to Git.<\/li>\n<li><strong>Reconciliation:<\/strong> The control loop that continuously drives actual state toward desired state.<\/li>\n<li><strong>Desired state:<\/strong> The configuration you want, typically declared in Git as manifests.<\/li>\n<li><strong>Drift:<\/strong> Divergence between declared desired state and actual runtime state.<\/li>\n<li><strong>Fleet (GKE Hub):<\/strong> Google Cloud\u2019s multi-cluster registration and feature management layer.<\/li>\n<li><strong>GKE (Google Kubernetes Engine):<\/strong> Managed Kubernetes on Google Cloud.<\/li>\n<li><strong>Namespace:<\/strong> Kubernetes isolation boundary for names and (often) access control.<\/li>\n<li><strong>RBAC:<\/strong> Role-Based Access Control for Kubernetes API permissions.<\/li>\n<li><strong>ConfigMap:<\/strong> Kubernetes object for non-secret configuration data.<\/li>\n<li><strong>Admission control:<\/strong> Kubernetes mechanism to validate\/mutate\/deny API requests.<\/li>\n<li><strong>Egress:<\/strong> Outbound network traffic leaving a cluster to external services.<\/li>\n<li><strong>Cloud NAT:<\/strong> Google Cloud service that provides outbound internet access for private resources.<\/li>\n<li><strong>Source of truth:<\/strong> The authoritative system where configuration is defined (typically Git).<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Config Sync is Google Cloud\u2019s GitOps synchronization capability for Kubernetes, designed to keep cluster configuration continuously aligned with a repository-based source of truth. It matters because it reduces drift, improves auditability, and enables consistent operations across distributed, hybrid, and multicloud Kubernetes fleets.<\/p>\n\n\n\n<p>From an architecture perspective, Config Sync runs reconcilers in-cluster and integrates well with Fleet for centralized multi-cluster operations. From a cost perspective, you pay primarily for the underlying clusters plus any applicable GKE Enterprise\/fleet feature fees, along with indirect costs like egress and logging. From a security perspective, the biggest wins come from PR-based change control and least-privilege access\u2014while the biggest risks come from poor repo governance and unsafe secret handling.<\/p>\n\n\n\n<p>Use Config Sync when you need repeatable, controlled, multi-cluster Kubernetes configuration management in Google Cloud. Next, deepen your implementation by adding CI validation, clear ownership boundaries, and (where appropriate) policy guardrails for safe fleet-wide changes.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Distributed, hybrid, and multicloud<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[60,51],"tags":[],"class_list":["post-688","post","type-post","status-publish","format-standard","hentry","category-distributed-hybrid-and-multicloud","category-google-cloud"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/688","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=688"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/688\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=688"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=688"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=688"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}