Master Kubernetes Federation: Multi-Cluster Management

Managing a single Kubernetes cluster can be a complex endeavor, but what happens when your organization scales beyond a single cluster? Perhaps you have clusters spread across different cloud providers, geographical regions, or even on-premises data centers for high availability, disaster recovery, or regulatory compliance. The challenge then shifts from managing one cluster to orchestrating an entire fleet of them – a task that quickly becomes unwieldy without the right tools and strategies.

Enter Kubernetes Federation, a powerful concept designed to simplify the deployment and management of applications across multiple Kubernetes clusters. While the original Kubernetes Federation v1 had its limitations and eventually became deprecated, the principles and the need for multi-cluster management persist, evolving into more robust, decentralized solutions. This guide will explore the modern approach to Kubernetes Federation, focusing on tools and patterns that enable you to treat multiple clusters as a cohesive unit, streamlining operations and enhancing resilience.

By the end of this tutorial, you’ll understand the core concepts behind multi-cluster management, learn how to set up a basic federated environment using modern tools, and gain insights into deploying and managing resources across your distributed Kubernetes infrastructure. Whether you’re aiming for global load balancing, active-active disaster recovery, or just better resource isolation, mastering Kubernetes Federation is a critical step towards a truly resilient and scalable cloud-native architecture.

TL;DR: Kubernetes Federation for Multi-Cluster Management

Kubernetes Federation allows you to manage applications and resources across multiple Kubernetes clusters as a single logical unit. Modern federation focuses on decentralized approaches, often using GitOps-driven tools like Argo CD or specialized multi-cluster schedulers, rather than a centralized control plane. This guide walks through setting up two clusters, registering them, and deploying a federated application using a representative tool like Kubefed (for demonstrating concepts, though often replaced by GitOps for production).

Problem: Managing applications across disparate Kubernetes clusters.
Solution: Modern Kubernetes Federation via GitOps or specialized multi-cluster tools.
Key Concepts: Cluster registration, cross-cluster deployment, policy enforcement.

Key Commands:

# Install `kubefedctl`
curl -sL https://github.com/kubernetes-sigs/kubefed/releases/download/v0.9.0/kubefedctl-v0.9.0-linux-amd64.tgz | tar -xz && sudo mv kubefedctl /usr/local/bin/

# Install Kubefed control plane on a host cluster
kubefedctl install --host-cluster-context host-cluster --kubeconfig ~/.kube/config

# Join a member cluster to the federation
kubefedctl join cluster1 --cluster-context cluster1 --host-cluster-context host-cluster --kubeconfig ~/.kube/config

# Create a federated Deployment
kubectl apply -f my-federated-deployment.yaml

# Verify federated resources
kubectl describe federateddeployment my-app -n default
kubectl get deployments -n default --context cluster1
kubectl get deployments -n default --context cluster2

Prerequisites

Before diving into Kubernetes Federation, ensure you have the following tools and knowledge:

Kubernetes Fundamentals: A solid understanding of Kubernetes concepts such as Pods, Deployments, Services, Namespaces, and kubectl. If you’re new to Kubernetes, consider reviewing the official Kubernetes documentation.
Two or More Kubernetes Clusters: You’ll need at least two operational Kubernetes clusters. These can be local (e.g., Kind, Minikube, K3s) or cloud-based (e.g., EKS, GKE, AKS). For this guide, we’ll assume two clusters named cluster1 and cluster2.
- Ensure you have kubeconfig entries for each cluster, and that kubectl can switch between them.
- For cloud clusters, make sure their respective Kubernetes API servers are accessible from where you’re running kubectl.
kubectl: The Kubernetes command-line tool. Make sure it’s installed and configured correctly. Refer to the kubectl installation guide if needed.
helm: While not strictly required for every federation approach, Helm is a common package manager for Kubernetes and is often used to deploy control planes or federated applications. Install it from the official Helm website.
Administrative Access: You’ll need administrative privileges on your Kubernetes clusters to install CRDs and deploy control planes.
Network Connectivity: Ensure that your clusters can communicate with each other’s API servers. For private clusters, this might involve VPC peering, VPNs, or other network configurations. For simpler local setups, this is often handled automatically. For advanced cross-cluster networking, tools like Cilium WireGuard Encryption can provide secure and efficient pod-to-pod communication across cluster boundaries.

Step-by-Step Guide: Modern Kubernetes Federation with Kubefed

While the original Kubernetes Federation v1 is deprecated, the concept of managing multiple clusters persists with tools like Kubefed v2 (now part of Kubernetes SIGs). Kubefed v2 offers a more decentralized approach, allowing you to define Kubernetes resources that are then propagated and reconciled across multiple member clusters. This section will guide you through setting up Kubefed and federating resources.

Note: While Kubefed is a great tool to *demonstrate* federation concepts, in production, many organizations opt for GitOps-driven multi-cluster deployments using tools like Argo CD or Flux CD, often combined with custom controllers or cluster API for provisioning. Kubefed serves as an excellent pedagogical tool for understanding the underlying mechanisms.

Step 1: Set Up Your Kubernetes Clusters

First, ensure you have two Kubernetes clusters running and accessible via kubectl. We’ll name them cluster1 and cluster2. For simplicity, we’ll use Kind to create local clusters. If you’re using cloud clusters, skip this Kind setup and ensure your kubeconfig is correctly pointing to your clusters.

This step creates two local Kind clusters. It’s crucial that kubectl can switch contexts between these clusters. We’ll use these clusters as our federation members. If you already have existing clusters, ensure their contexts are correctly configured in your ~/.kube/config file.

# Create cluster1
kind create cluster --name cluster1

# Create cluster2
kind create cluster --name cluster2

# Verify contexts
kubectl config get-contexts

# Expected Output (truncated):
# CURRENT   NAME                 CLUSTER      AUTHINFO             NAMESPACE
#           kind-cluster1        kind-cluster1  kind-cluster1
# *         kind-cluster2        kind-cluster2  kind-cluster2

Now, let’s rename the contexts for clarity, as Kind often prefixes them with kind-. This makes it easier to refer to them as cluster1 and cluster2 directly.

# Rename contexts for convenience
kubectl config rename-context kind-cluster1 cluster1
kubectl config rename-context kind-cluster2 cluster2

# Verify renamed contexts
kubectl config get-contexts

# Expected Output (truncated):
# CURRENT   NAME         CLUSTER      AUTHINFO             NAMESPACE
#           cluster1     kind-cluster1  kind-cluster1
# *         cluster2     kind-cluster2  kind-cluster2

Step 2: Install `kubefedctl` CLI

kubefedctl is the command-line tool for interacting with Kubefed. It’s used to install the Kubefed control plane, join clusters, and manage federated resources. Download and install it on your local machine.

This command fetches the latest stable release of kubefedctl, extracts it, and moves it into your system’s path, making it globally accessible. Always ensure you’re downloading from the official Kubernetes SIGs repository for security.

# Download and install kubefedctl (adjust version as needed from GitHub releases)
curl -sL https://github.com/kubernetes-sigs/kubefed/releases/download/v0.9.0/kubefedctl-v0.9.0-linux-amd64.tgz | tar -xz && sudo mv kubefedctl /usr/local/bin/

# Verify installation
kubefedctl version

# Expected Output:
# Client Version: version.Info{GitVersion:"v0.9.0", GitCommit:"f472251a37c87c714c000e3188544d6736485802", GitTreeState:"clean", BuildDate:"2022-07-28T09:41:20Z", GoVersion:"go1.17.11", Compiler:"gc", Platform:"linux/amd64"}

Step 3: Install the Kubefed Control Plane

The Kubefed control plane needs to be installed in one of your clusters, which will act as the “host cluster.” This host cluster will manage the federation of resources across all member clusters. We’ll use cluster1 as our host cluster.

The kubefedctl install command deploys the necessary Custom Resource Definitions (CRDs), controllers, and other components that form the Kubefed control plane into the specified host cluster. This includes resources like FederatedDeployment, FederatedService, etc. It’s important to choose a stable and reliable cluster for your host, as its availability affects the entire federation.

# Set cluster1 as the host cluster and install Kubefed
kubefedctl install --host-cluster-context cluster1 --kubeconfig ~/.kube/config

# Verify the Kubefed control plane is running on cluster1
kubectl get pods -n kube-federation-system --context cluster1

# Expected Output:
# NAME                                      READY   STATUS    RESTARTS   AGE
# kubefed-controller-manager-5d4c8f77d4-abcde   1/1     Running   0          2m

Step 4: Join Member Clusters to the Federation

Once the Kubefed control plane is running, you need to “join” your other clusters to the federation. Each joined cluster becomes a “member cluster” and can receive federated resources.

The kubefedctl join command registers a member cluster with the host cluster’s Kubefed control plane. This involves creating a KubeFedCluster resource on the host cluster and deploying a service account, role, and role binding on the member cluster to allow the host cluster to manage resources within it. Repeat this for all clusters you wish to federate.

# Join cluster1 (itself, as it's also a member) to the federation
kubefedctl join cluster1 --cluster-context cluster1 --host-cluster-context cluster1 --kubeconfig ~/.kube/config

# Join cluster2 to the federation
kubefedctl join cluster2 --cluster-context cluster2 --host-cluster-context cluster1 --kubeconfig ~/.kube/config

# Verify that both clusters are joined by checking the KubeFedCluster resources on the host cluster
kubectl get kubefedclusters -n kube-federation-system --context cluster1

# Expected Output:
# NAME         AGE   READY
# cluster1     1m    True
# cluster2     1m    True

Step 5: Deploy a Federated Namespace

Before deploying applications, it’s often useful to federate namespaces. This ensures that a specific namespace exists across all joined clusters, providing a consistent environment for your federated applications.

Creating a FederatedNamespace resource on the host cluster tells Kubefed to ensure that a corresponding Namespace resource exists in all joined member clusters. This is a foundational step for deploying other federated resources into a consistent target scope.

# federated-namespace.yaml
apiVersion: types.kubefed.io/v1beta1
kind: FederatedNamespace
metadata:
  name: my-federated-namespace
spec:
  placement:
    clusters:
    - name: cluster1
    - name: cluster2

# Apply the federated namespace on the host cluster
kubectl apply -f federated-namespace.yaml --context cluster1

# Verify the namespace exists on both member clusters
echo "Checking cluster1:"
kubectl get namespace my-federated-namespace --context cluster1
echo "Checking cluster2:"
kubectl get namespace my-federated-namespace --context cluster2

# Expected Output (for both clusters):
# NAME                     STATUS   AGE
# my-federated-namespace   Active   Xs

Step 6: Deploy a Federated Deployment

Now, let’s deploy an application using a federated deployment. This will ensure our application pods are scheduled across both cluster1 and cluster2, providing high availability.

A FederatedDeployment is a Custom Resource that defines a standard Kubernetes Deployment and specifies how it should be distributed among member clusters. Kubefed’s controller observes this resource on the host cluster and creates actual Deployment resources in the specified member clusters. The placement field determines which clusters receive the deployment, and overrides can customize cluster-specific settings.

# federated-deployment.yaml
apiVersion: types.kubefed.io/v1beta1
kind: FederatedDeployment
metadata:
  name: my-federated-app
  namespace: my-federated-namespace
spec:
  template:
    spec:
      selector:
        matchLabels:
          app: my-federated-app
      replicas: 2 # Total replicas across ALL clusters where it's placed
      template:
        metadata:
          labels:
            app: my-federated-app
        spec:
          containers:
          - name: nginx
            image: nginx:latest
            ports:
            - containerPort: 80
  placement:
    clusters:
    - name: cluster1
    - name: cluster2
  # Optional: Customize replicas per cluster
  # If you want 1 replica in cluster1 and 1 in cluster2, use propagation preferences
  # Or, if you want 2 in cluster1 and 0 in cluster2:
  # overrides:
  # - clusterName: cluster1
  #   clusterOverrides:
  #   - path: "/spec/replicas"
  #     value: 2
  # - clusterName: cluster2
  #   clusterOverrides:
  #   - path: "/spec/replicas"
  #     value: 0

# Apply the federated deployment on the host cluster
kubectl apply -f federated-deployment.yaml --context cluster1

# Verify the federated deployment status on the host cluster
kubectl describe federateddeployment my-federated-app -n my-federated-namespace --context cluster1

# Expected Output (look for status and cluster readiness):
# ...
# Status:
#   Clusters:
#     Name:  cluster1
#     Status:
#       Ready:  true
#     Name:  cluster2
#     Status:
#       Ready:  true
# ...

# Verify deployments and pods on cluster1
echo "Checking cluster1:"
kubectl get deployment my-federated-app -n my-federated-namespace --context cluster1
kubectl get pods -n my-federated-namespace --context cluster1 -o wide

# Verify deployments and pods on cluster2
echo "Checking cluster2:"
kubectl get deployment my-federated-app -n my-federated-namespace --context cluster2
kubectl get pods -n my-federated-namespace --context cluster2 -o wide

# Expected Output (for each cluster, you should see the deployment and pods):
# For deployments:
# NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
# my-federated-app     2/2     2            2           Xs
#
# For pods (example, note node IP will vary):
# NAME                                  READY   STATUS    RESTARTS   AGE   IP           NODE                 NOMINATED NODE   READINESS GATES
# my-federated-app-766b4c95d9-abcde     1/1     Running   0          Xs    10.244.0.5   cluster1-control-plane   <none>           <none>
# my-federated-app-766b4c95d9-fghij     1/1     Running   0          Xs    10.244.0.6   cluster1-control-plane   <none>           <none>

In this example, we set replicas: 2 in the FederatedDeployment template. By default, Kubefed will try to distribute these replicas across the placed clusters. If you need more granular control over replica distribution (e.g., 1 replica in cluster1 and 1 in cluster2, or 2 in cluster1 and 0 in cluster2), you would use FederatedReplicaSet or more advanced PropagationPreference resources. For simple deployments, the default behavior often works sufficiently.

Step 7: Deploy a Federated Service

To make your federated application accessible, you’ll likely need a federated service. This allows clients to access your application regardless of which cluster its pods are running in.

A FederatedService ensures that a standard Kubernetes Service resource is created in each member cluster where the corresponding application is deployed. This allows for local load balancing within each cluster. For global load balancing across clusters, you would typically combine this with an external DNS service or a global load balancer that can direct traffic to the services in different clusters. Consider using the Kubernetes Gateway API for more advanced traffic management across clusters and environments.

# federated-service.yaml
apiVersion: types.kubefed.io/v1beta1
kind: FederatedService
metadata:
  name: my-federated-app-service
  namespace: my-federated-namespace
spec:
  template:
    spec:
      selector:
        app: my-federated-app
      ports:
        - protocol: TCP
          port: 80
          targetPort: 80
      type: ClusterIP # Or NodePort/LoadBalancer depending on your needs
  placement:
    clusters:
    - name: cluster1
    - name: cluster2

# Apply the federated service on the host cluster
kubectl apply -f federated-service.yaml --context cluster1

# Verify the federated service status on the host cluster
kubectl describe federatedservice my-federated-app-service -n my-federated-namespace --context cluster1

# Expected Output (look for status and cluster readiness):
# ...
# Status:
#   Clusters:
#     Name:  cluster1
#     Status:
#       Ready:  true
#     Name:  cluster2
#     Status:
#       Ready:  true
# ...

# Verify services on cluster1
echo "Checking cluster1:"
kubectl get service my-federated-app-service -n my-federated-namespace --context cluster1

# Verify services on cluster2
echo "Checking cluster2:"
kubectl get service my-federated-app-service -n my-federated-namespace --context cluster2

# Expected Output (for both clusters):
# NAME                       TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
# my-federated-app-service   ClusterIP   10.xx.xx.xx     <none>        80/TCP    Xs

At this point, you have successfully deployed a federated namespace, deployment, and service across two Kubernetes clusters using Kubefed. This demonstrates the core capability of distributing and managing resources from a single control point.

Production Considerations

While Kubefed provides a great way to understand federation, production multi-cluster management often involves more sophisticated patterns and tools. Here are critical considerations for real-world deployments:

GitOps for Multi-Cluster Management:

For true scalability, resilience, and auditability, GitOps is the preferred pattern for multi-cluster deployments. Tools like Argo CD or Flux CD allow you to define the desired state of your applications and infrastructure in Git. Each cluster runs its own GitOps agent, which pulls configurations from Git and applies them, ensuring consistency and declarative management. This approach avoids a single point of failure inherent in a centralized federation control plane and naturally handles cluster-specific configurations through overlays (e.g., Kustomize) or templating (e.g., Helm).
Networking and Connectivity:

Cross-cluster communication is paramount. This involves not only API server access but also potentially pod-to-pod communication across clusters. Solutions include:
- VPNs/VPC Peering: For private network connectivity between clusters.
- Service Mesh: Tools like Istio Ambient Mesh or Linkerd can provide secure, observable, and routable communication between services running in different clusters, often leveraging multi-cluster gateways.
- Global Load Balancers: Cloud provider global load balancers (e.g., AWS Global Accelerator, GCP Global External Load Balancing) can route traffic to services exposed in different regions/clusters.
- DNS Federation: Using a global DNS service to provide a single entry point for applications spread across clusters.
- CNIs with Multi-Cluster Capabilities: Some Container Network Interface (CNI) plugins, like Cilium, offer advanced multi-cluster networking features, including WireGuard encryption for pod-to-pod traffic between clusters.
Identity and Access Management (IAM):

Consistent IAM across clusters is crucial. This could involve integrating with a central identity provider (e.g., Okta, Azure AD) and using tools like AWS IAM Authenticator or GCP’s Kubernetes Engine RBAC integration. Ensure that your federation control plane or GitOps agents have appropriate permissions in all member clusters, following the principle of least privilege.
Observability:

Monitoring and logging across multiple clusters require aggregation. Centralized Prometheus for metrics, Loki/Fluentd for logs, and Jaeger/OpenTelemetry for tracing are common solutions. Tools leveraging eBPF for observability, like Hubble with Cilium, can provide deep insights across your distributed network.
Resource Scheduling and Placement:

Beyond simple propagation, advanced scheduling ensures efficient resource utilization and adherence to policies. Consider:
- Policy-based Placement: Using labels, annotations, or custom resources to define where applications should run based on criteria like region, cost, or resource availability.
- Workload Shifting: The ability to move workloads between clusters for maintenance, upgrades, or disaster recovery.
- Autoscaling: Implementing cluster autoscalers like Karpenter or the Kubernetes Cluster Autoscaler for individual clusters, alongside multi-cluster Horizontal Pod Autoscalers (HPA) if your federation tool supports it.
Security and Compliance:

Implementing consistent Kubernetes Network Policies across all clusters is vital for isolation. Tools like Sigstore and Kyverno can enforce supply chain security by ensuring only signed images are deployed and that configurations adhere to organizational policies. Consider policies for secrets management, pod security standards, and role-based access control (RBAC) consistency.
Disaster Recovery and High Availability:

A key driver for multi-cluster setups. Design your applications for active-passive or active-active deployments. Ensure your data layer (databases, object storage) is also replicated or highly available across regions/clusters. Regular backup and restore strategies for cluster configurations and application data are essential.
Hybrid/Multi-Cloud Challenges:

When federating across different cloud providers or on-premises environments, expect increased complexity in networking, IAM, and resource consistency. Abstracting these differences with tools like Crossplane or leveraging cloud-agnostic services becomes more critical.

Troubleshooting

Multi-cluster environments introduce new layers of complexity. Here are common issues and their solutions:

1. Cluster Context Issues

Problem: kubectl or kubefedctl commands fail with “no such host” or “connection refused,” or operate on the wrong cluster.

Solution: Ensure your kubeconfig is correctly configured and you’re specifying the correct context. Verify network connectivity to the API server.

# List all contexts
kubectl config get-contexts

# Switch to a specific context
kubectl config use-context cluster1

# Test connectivity to the API server
kubectl cluster-info --context cluster1

# If using Kind, ensure Docker is running and Kind containers are healthy
docker ps -a

2. Kubefed Control Plane Not Running

Problem: The kubefed-controller-manager pod in kube-federation-system namespace on the host cluster is not running or is in a CrashLoopBackOff state.

Solution: Check the logs of the controller manager pod to identify the root cause. This often points to RBAC issues or incorrect installation parameters.

# Check pod status
kubectl get pods -n kube-federation-system --context cluster1

# Get logs of the controller manager
kubectl logs -f deployment/kubefed-controller-manager -n kube-federation-system --context cluster1

3. Member Cluster Not Joining

Problem: A member cluster fails to join the federation, or its status in KubeFedCluster remains “False”.

Solution: Verify that the host cluster has appropriate permissions to access the member cluster’s API server. Check network connectivity between the host and member clusters. Also, ensure the service account created on the member cluster by the kubefedctl join command has the necessary permissions.

# Check KubeFedCluster status on the host cluster
kubectl get kubefedclusters -n kube-federation-system --context cluster1

# Check the logs of the kubefed-controller-manager on the host cluster for join errors
kubectl logs -f deployment/kubefed-controller-manager -n kube-federation-system --context cluster1

# On the *member cluster*, check for the kubefed-controller-manager service account and its roles/rolebindings
# (Note: Kubefed creates a service account and role/rolebinding in the member cluster for the host to use)
kubectl get sa -n kube-federation-system --context cluster2
kubectl get clusterrolebinding kubefed-controller-manager:federation-member-cluster-clusterrolebinding --context cluster2

4. Federated Resources Not Propagating

Problem: A FederatedDeployment or FederatedService is created on the host cluster, but the corresponding resource doesn’t appear in the member clusters.

Solution:

Check KubeFedCluster status: Ensure all target member clusters are “Ready” in the host cluster.
Verify placement: Double-check the spec.placement.clusters in your federated resource YAML to ensure the correct clusters are listed.
Inspect federated resource status: Use kubectl describe on the federated resource on the host cluster. Look for any errors or warnings in the status section.
Check controller logs: The kubefed-controller-manager logs on the host cluster will show why a resource might not be propagating.

# Describe the federated resource on the host cluster
kubectl describe federateddeployment my-federated-app -n my-federated-namespace --context cluster1

# Check controller logs again
kubectl logs -f deployment/kubefed-controller-manager -n kube-federation-system --context cluster1

5. Network Policy Conflicts

Problem: Pods in different clusters cannot communicate, even though services are federated.

Solution: This is often a network policy issue or a CNI configuration problem. Review your Kubernetes Network Policies in each cluster. If you’re using a CNI like Cilium, ensure its multi-cluster features are correctly configured. Check firewall rules between your cluster nodes.

# Check network policies in each cluster
kubectl get networkpolicy -n my-federated-namespace --context cluster1
kubectl get networkpolicy -n my-federated-namespace --context cluster2

# Use kubectl exec to test connectivity between pods in different clusters if possible
# (This requires cross-cluster pod IP routing, which might not be enabled by default)

6. Resource Version Conflicts / Stale Data

Problem: Updates to federated resources are not consistently applied, or older versions persist.

Solution: Ensure that only the Kubefed controller (or your GitOps tool) is managing the federated resources. Direct modifications to the underlying resources in member clusters can lead to conflicts. If using GitOps, ensure your Git repository is the single source of truth and that reconciliation loops are healthy.

7. Certificate Expiry

Problem: Communication between Kubefed components or between the host and member clusters fails due to expired certificates.

Solution: Kubernetes clusters require certificate rotation. Ensure your cluster’s certificate authority (CA) and API server certificates are valid. For kubefedctl, ensure its kubeconfig entries use valid client certificates. For cloud providers, this is often managed automatically, but for self-managed clusters, you might need to manually rotate them.

FAQ Section

1. What is the difference between Kubernetes Federation v1 and modern Federation (like Kubefed v2 or GitOps)?

Kubernetes Federation v1 (also known as “Federation”) was a centralized approach where a single “federation control plane” managed resources across all clusters. It faced challenges with scalability, reliability (single point of failure), and complexity, leading to its deprecation. Modern federation, exemplified by Kubefed v2 (now part of Kubernetes SIGs) and especially GitOps-driven solutions (like Argo CD, Flux CD), adopts a more decentralized model. Instead of a single control plane, each cluster often runs its own agent (e.g., GitOps operator) that pulls configurations from a common source of truth (Git) or responds to higher-level federated resources defined on a host cluster. This offers better resilience, scalability, and integration with existing CI/CD pipelines.

2. When should I use Kubernetes Federation?

You should consider Kubernetes Federation or multi-cluster management strategies when you need:

High Availability/Disaster Recovery: Distributing applications across multiple clusters (e.g., different regions or cloud providers) to ensure services remain available even if one cluster fails.
Geographical Distribution/Low Latency: Deploying applications closer to users in different regions to reduce latency.
Regulatory Compliance: Meeting data residency requirements by deploying workloads in specific geographical locations.
Resource Isolation/Multi-Tenancy: Providing separate clusters for different teams, environments (dev, staging, prod), or customers.
Hybrid/Multi-Cloud Strategy: Operating workloads across on-premises and cloud environments or across multiple cloud providers.
Cost Optimization: Leveraging different