SPEAKER: Hi.
I'm Nikhil, and I'm going to talk
about Kubemci, a new command line tool
to manage multicluster ingresses.
I'm going to talk about what it does, why is it useful,
and how it works.
But before I get started, I do want
to point out that Kubemci is not an official supported product.
It's an exploration.
We want people to try it out and see if it's useful.
Secondly, as I talk about Kubemci,
I'm going to assume knowledge about Kubernetes and Kubernetes
Ingress.
If you've used Kubernetes Ingress with Google Cloud Load
Balancer to create L7 load balancers,
you can now use Kubemci to do the same
for multiple Kubernetes clusters.
Doesn't that sound awesome?
Let's see how it works.
Our top use cases for Kubemci are low latency and high
availability.
Let's look at this diagram on the right.
We have two clusters, cluster 1 in GCP zone US Central 1-A
and cluster 2 in GCP zone Europe West [INAUDIBLE]..
Service [INAUDIBLE] exists in both these clusters.
Now, if user Alice from California
wants to need service [INAUDIBLE],,
we want Google Cloud Load Balancer to send that request
to cluster 1.
Similarly, if user Bob from Berlin sends the same request,
we want that request to go to cluster 2.
This ensures low latency.
If cluster 2 goes down, we still want
user Bob to be able to read service [INAUDIBLE]..
In that case, Google Cloud Load Balancer
should send that request to cluster 1.
That ensures high availability.
Now, how Kubemci works is it has a Kubemci Create command,
where you can give it a name, your Kubernetes Ingress
definition as ingress.yaml and a list of clusters
in clusters.yaml.
If you run this command, Kubemci creates the ingress
in all the clusters, in this case in both cluster
1 and cluster 2, and then configures Google Cloud Load
Balancer to send the traffic appropriately.
To parse the list of clusters, you
can give your existing kubeconfig.
Or in future, we want to integrate with Kubernetes
Cluster Registry.
While this is a high-level overview,
you can also take a look at the code.
It's open sourced.
You can go to GitHub, and you'll see all the code there.
You can try it out and start contributing to the code
as well.
But let's take a look at a demo.
For this demo, I have two clusters, one in US
and one in Europe.
I have my zpkubeconfig file, which has information
about both these clusters.
So this is the kubeconfig file that I'm
going to use with Kubemci.
I'm using a zone printer app for this example.
What the app does is it prints the GCP zone
that it is running in.
I've created my zone printer app in US cluster.
And now I'm going to create the same app in my Europe cluster
so that the same app exists in both.
Once we have this setup ready, I am now
ready to use Kubemci to create my load balancer.
Let's look at Kubemci Help first.
Kubemci Help prints all the available commands.
There's Create, there's Delete, there's
getstatus to get the status of an existing ingress,
and Help and the version of the tool.
So let's look deeper at Kubemci Create.
We'll look at the Help for Kubemci Create.
This tells me I need to pass a load balancer
name and some flags.
GCP project is a required flag.
The ingress spec is a required flag.
And kubeconfig is required.
So let's try it out.
Let's run Kubemci Create.
I'm going to name my load balancer zoneprinter-lb.
I have an ingress spec, and I use zpkubeconfig.
It prints that it created the ingress in both those clusters,
then created health check, backend service, URL map,
target proxy, forwarding nodes.
It's creating all the resources required to configure
Google Cloud Load Balancer.
Once it's done, I can run getstatus command
to see the status of my load balancer.
To get the status, I pass the name and the GCP
project it is in.
And it tells me, yes, such a load balancer exists,
and this is the IP address.
The load balancer is spread across two clusters, cluster US
West and cluster EU West, as I want it.
GCLB, Google Cloud Load Balancer,
takes some time to configure.
Once it's done, we can hit this IP address to ensure
that it's working as expected.
To do that, let's hit that IP address from a VM
in my US cluster.
As expected, it returns that the request
was served from US West 1-A. Let's do the same for Europe
cluster.
And in this case, we expect it to be
served from the Europe zone.
It was served from Europe zone.
So this shows that our setup is working as expected.
This is great.
You should try it out.
And we'd love to get your feedback.
Positive or not, any feedback is appreciated.
Thank you.