Google Cloud Hybrid and Multicloud: Manage Kubernetes Across Cloud and Data Centers (Part 3)

Many organizations operate applications in several locations. Customer-facing services may run in Google Cloud, sensitive processing may remain in a data center, and another team may use a different cloud provider.

The challenge is keeping access, configuration, security policies, and service communication consistent across these environments.

Approach	Meaning	Example
Hybrid cloud	Combines public cloud and on-premises infrastructure	GKE applications accessing a data-center system
Multicloud	Uses more than one cloud provider	Kubernetes workloads running in Google Cloud and Azure
Edge computing	Processes data close to where it originates	Local image analysis in a factory

A correction to the earlier service list: Google states that GKE Enterprise functionality was absorbed into GKE in September 2025. Treat GKE Enterprise as historical terminology, and document the current capabilities individually. This also avoids confusing GKE editions with the Autopilot and Standard operating modes.

The following examples are illustrative architectures, not claims about a particular organization’s production environment.

1. Google Distributed Cloud — Run workloads in data centers and at the edge

Google Distributed Cloud extends Google’s infrastructure capabilities to locations outside its public-cloud regions. Its offerings address requirements such as local processing, low latency, data residency, and disconnected operation.

Deployment options differ: connected deployments and air-gapped environments should not be described as having identical management or connectivity requirements. Air-gapped GDC does not require connectivity to Google Cloud or the public internet.

Practical example: factory quality inspection

A factory needs to detect defective products immediately. Sending every image to a distant cloud region could introduce unnecessary latency.

What to assess

• Required hardware and supported deployment option.
• Local availability and recovery requirements.
• Connectivity and update procedures.
• Data placement and permitted exports.
• Responsibilities shared with the provider and partners.

Interview question: Why use GDC instead of public-cloud GKE?

I consider GDC when workload requirements justify local execution, such as latency, connectivity, or data-location constraints. I first identify the appropriate GDC offering and its operational requirements.

Common mistake: Assuming on-premises deployment alone satisfies every regulatory requirement.

2. GKE Enterprise — Understand the historical platform concept

GKE Enterprise historically brought together capabilities for operating Kubernetes across multiple clusters, including fleet management, configuration management, governance, and service communication.

For current documentation, explain these capabilities under their present names rather than presenting GKE Enterprise as a separate edition to purchase. Check each feature’s current availability and pricing independently.

Practical example: an enterprise Kubernetes platform

A platform team manages several application clusters. It needs:

Requirement	Relevant capability
Group and organize clusters	Fleet Management
Provide administrative access	Connect Gateway
Reconcile approved configuration	Config Sync
Validate Kubernetes resources	Policy Controller
Manage service communication	Cloud Service Mesh

Interview question: Is GKE Enterprise the same as GKE Standard?

They describe different concepts historically. Standard is a GKE operating mode. Enterprise was an edition associated with enterprise platform capabilities; Google subsequently absorbed its functionality into GKE.

3. Fleet Management — Organize clusters as a group

A fleet is a logical grouping of Kubernetes clusters used for shared management and fleet-enabled capabilities. Clusters are represented by memberships in a fleet host project.

Registering clusters does not merge them into one Kubernetes cluster or automatically connect their application networks.

Practical example: a production application fleet

Suggested hands-on workflow

1. Identify the fleet host project.
2. Verify cluster eligibility and prerequisites.
3. Register the selected clusters.
4. Confirm membership status.
5. Enable required capabilities deliberately.
6. Validate configuration and access on each cluster.

A useful read-only command is:

gcloud container fleet memberships list --project=FLEET_PROJECT_ID

Interview question: Does fleet membership replicate workloads?

No. Membership organizes clusters for management. Workload deployment, data replication, networking, and failover require separate configuration.

Common mistake: Grouping unrelated clusters without considering shared trust and governance requirements.

4. Connect Gateway — Access registered cluster APIs

Connect Gateway lets authorized users and automation interact with registered clusters using their Google Cloud identity and tools such as kubectl.

Access requires appropriate gateway permissions and cluster authorization. It provides an administrative path to the Kubernetes API; it is not a gateway for customer application traffic.

Practical example: platform support access

Hands-on commands

After an administrator configures access:

gcloud container fleet memberships list --project=FLEET_PROJECT_ID

gcloud container fleet memberships get-credentials MEMBERSHIP_NAME \
  --project=FLEET_PROJECT_ID

kubectl get namespaces
kubectl get pods -n demo

Fetching credentials changes your local Kubernetes configuration. Check the active context before subsequent commands:

kubectl config current-context

Interview question: What would you check after a permission error?

I verify the active identity, target membership, gateway IAM permissions, cluster authorization, and the required connectivity components.

5. Cloud Service Mesh — Manage service-to-service communication

Cloud Service Mesh provides capabilities for traffic management, service security, and observability. Depending on deployment and configuration, these include mutual TLS, routing rules, and service communication telemetry.

A mesh complements application logic and networking; it does not automatically make all cross-cluster communication possible.

Practical example: gradually release a payment-service version

The percentages are illustrative rollout values.

Operational considerations

• Verify supported platform and mesh configuration.
• Configure workload identity and authorization.
• Define timeouts around dependency behavior.
• Monitor errors, latency, and request volume.
• Apply retries only where the operation is safe to repeat.

Interview question: What does mutual TLS provide?

Mutual TLS authenticates both communicating parties and encrypts the connection. Authorization policies determine which authenticated workloads may communicate.

Common mistake: Retrying a payment operation without idempotency controls, potentially creating duplicate processing.

6. Config Sync — Reconcile approved configuration across clusters

Config Sync is a GitOps service that synchronizes configuration and policies from a declared source of truth. It continuously reconciles managed resources to reduce configuration drift.

Practical example: consistent namespace configuration

A platform team stores namespaces, resource quotas, and RBAC definitions in Git.

Suggested exercise

1. Configure a repository and authentication.
2. Install and configure Config Sync on a demo cluster.
3. Commit a namespace and quota.
4. Verify synchronization.
5. Make a controlled manual change to a managed field.
6. Observe reconciliation and inspect status.

Interview question: How does Config Sync relate to Argo CD?

Both use declarative sources and reconciliation. I define clear resource ownership before using them together—for example, Config Sync for platform configuration and Argo CD for application resources.

Common mistake: Letting two controllers manage the same resource and overwrite each other’s changes.

7. Policy Controller — Validate Kubernetes resources against rules

Policy Controller provides Kubernetes policy enforcement and auditing based on Open Policy Agent Gatekeeper. Policies can detect existing violations or reject noncompliant requests, depending on their configuration.

Practical example: require ownership labels

Every application must identify its owner and environment:

metadata:
labels:
owner: payments-team
environment: production

A configured constraint checks these labels.

Suggested policy rollout

1. Identify the requirement and exception process.
2. Select or define a constraint template.
3. Configure a constraint.
4. Begin with audit or dry-run behavior.
5. Review existing violations.
6. Fix manifests before enabling enforcement.

Interview question: Will a policy automatically fix existing violations?

Generally, it reports violations or blocks requests. Resource owners must remediate them, often by correcting the Git source and letting reconciliation apply the change.

Common mistake: Enabling strict enforcement without checking its effect on deployments and operational workloads.

How these capabilities fit together

Layer	Capability	Responsibility
Execution location	GKE or an appropriate GDC offering	Run the workloads
Cluster organization	Fleet Management	Group eligible clusters
Administrative access	Connect Gateway	Reach cluster APIs with authorized identities
Desired configuration	Config Sync	Reconcile managed resources
Resource governance	Policy Controller	Audit or enforce requirements
Service communication	Cloud Service Mesh	Apply supported traffic and security controls

Not every environment supports every capability. In particular, a permanently air-gapped GDC deployment must not be illustrated as depending on public-cloud Connect Gateway or a public Git repository.

A useful interview answer

“For hybrid Kubernetes, I start with workload placement and supported platforms. I use fleets to organize eligible clusters, configure identity-based administrative access, reconcile approved configuration with Config Sync, and enforce Kubernetes requirements with Policy Controller. Where appropriate, I add Cloud Service Mesh for service communication. I design networking, data replication, and disaster recovery separately because fleet registration alone does not provide them.”