Testing and Federation Capabilities

[![](https://1.bp.blogspot.com/-vDz5dEG_-yI/WAE81YPVlYI/AAAAAAAAAwM/jvt46qwIViQbsbftCqFenUocGfssuLbjwCLcB/s640/Copy%2Bof%2BFederation%2BBlog%2BDrawing%2B%25281%2529.png)](https://1.bp.blogspot.com/-vDz5dEG_-yI/WAE81YPVlYI/AAAAAAAAAwM/jvt46qwIViQbsbftCqFenUocGfssuLbjwCLcB/s1600/Copy%2Bof%2BFederation%2BBlog%2BDrawing%2B%25281%2529.png) To test this out, we’re going to spin up 2 Google Cloud Engine (GCE) instances, one in us-west1-b and the other in asia-east1-a. All client requests are automatically routed, via the shortest network path, to a healthy Pod in the closest cluster to the origin of the request. So for example, HTTP(S) requests from Asia will be routed directly to the closest cluster in Asia that has available capacity. If there are no such clusters in Asia, the request will be routed to the next closest cluster (in this case the U.S.). This works irrespective of whether the requests originate from a GCE instance or anywhere else on the internet. We only use a GCE instance for simplicity in the demo. ![](https://lh5.googleusercontent.com/GcJh6wsYfi8Kjb94g7tS1sOtWqDGohfcthfuEu1mqAkRe7zktmthFjkUke3jY_KqZi-T4wgENBkdZyrCYNV5PjaykF-a1f0io2RRaptBndrxY0qiFM1Q7O089B46JVeZwP__ImXg) We can SSH directly into the VMs using the Cloud Console or by issuing a gcloud SSH command. ``` $ gcloud compute ssh test-instance-asia --zone asia-east1-a ----- user@test-instance-asia:~$ curl 130.211.40.186 <!DOCTYPE html> <html> <head> <title>Welcome to the global site!</title> </head> <body> <h1>Welcome to the global site! You are being served from asia-east1-b</h1> <p>Congratulations!</p> user@test-instance-asia:~$ exit ---- $ gcloud compute ssh test-instance-us --zone us-west1-b ---- user@test-instance-us:~$ curl 130.211.40.186 <!DOCTYPE html> <html> <head> <title>Welcome to the global site!</title> </head> <body> <h1>Welcome to the global site! You are being served from us-central1-b</h1> <p>Congratulations!</p> ---- ``` Federations of Kubernetes Clusters can include clusters running in different cloud providers (e.g. GCP, AWS), and on-premises (e.g. on OpenStack). However, in Kubernetes 1.4, Federated Ingress is only supported across Google Cloud Platform clusters. In future versions we intend to support hybrid cloud Ingress-based deployments. To summarize, we walked through leveraging the Kubernetes 1.4 Federated Ingress alpha feature to deploy a multi-homed service behind a global load balancer. External clients point to a single IP address and are sent to the closest cluster with usable capacity in any region, zone of the Federation, providing higher levels of availability without sacrificing latency or ease of operation. We'd love to hear feedback on Kubernetes Cross Cluster Services. To join the community: - Post issues or feature requests on [GitHub](https://github.com/kubernetes/kubernetes/tree/master/federation) - Join us in the #federation channel on [Slack](https://kubernetes.slack.com/messages/sig-federation) - Participate in the [Cluster Federation SIG](https://groups.google.com/forum/#!forum/kubernetes-sig-federation) - [Download](http://get.k8s.io/) Kubernetes - Follow Kubernetes on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates

The text details how to test the global load balancing setup by spinning up two Google Cloud Engine instances in different regions (us-west1-b and asia-east1-a). It shows how `curl` commands from each instance hit the global VIP and are served by the closest available cluster. The text also discusses the possibility of including clusters from different cloud providers and on-premises environments in Kubernetes Federations, but notes that Federated Ingress is currently only supported across Google Cloud Platform clusters. Finally, it summarizes the process of deploying a multi-homed service behind a global load balancer using the Kubernetes 1.4 Federated Ingress feature and provides links for community engagement and further information.