Federated resources allow us to deploy across multiple clusters and/or regions. Currently, version 1.5 of Kubernetes support a number of core resource types in the federation API, including ConfigMap, DaemonSets, Deployment, Events, Ingress, Namespaces, ReplicaSets, Secrets, and Services.

Let's take a look at a federated deployment that will allow us to schedule pods across both AWS and GCE. Save the following file as node-js-deploy-fed.yaml:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: node-js-deploy
  labels:
    name: node-js-deploy
spec:
  replicas: 3
  template:
    metadata:
      labels:
        name: node-js-deploy
    spec: 
      containers: 
      - name: node-js-deploy 
        image: jonbaier/pod-scaling:latest 
        ports: 
        - containerPort: 80

Create this deployment with the following command:

$ kubectl create -f node-js-deploy-fed.yaml

Now, let's try listing the pods from this deployment:

$ kubectl get pods

We should see a message like the preceding one depicted. This is because we are still using master-control or federation context, which does not itself run pods. We will, however, see the deployment in the federation plane and, if we inspect the events, we will see that the deployment was in fact created on both of our federated clusters:

$ kubectl get deployments
$ kubectl describe deployments node-js-deploy

We should see something like the following. Notice that the Events: section shows deployments in both our GCE and AWS contexts:

We can also see the federated events using the following command:

$ kubectl get events

It may take a moment for all three pods to run. Once that happens, we can switch to each cluster context and see some of the pods on each. Note that we can now use get pods since we are on the individual clusters and not on the control plane:

$ kubectl config use-context awsk8s
$ kubectl get pods

$ kubectl config use-context gcek8s
$ kubectl get pods

We should see the three pods spread across the clusters with two on one and a third on the other. Kubernetes has spread them across the cluster without any manual intervention. Any pods that fail will be restarted, but now we have the added redundancy of two cloud providers.