Cloud Native Computing Foundation ServiceMeshCon EU 2022, 19 May 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: Multi-cluster Istio Mesh – Complex or Piece of Cake? - Laszlo Bence Nagy, Cisco

Description

Lightning Talk: Multi-cluster Istio Mesh – Complex or Piece of Cake? - Laszlo Bence Nagy, Cisco

Setting up and then preserving a multi-cluster Istio mesh is cumbersome today, as it involves several manual steps. Those steps are not automatic, because there is no continuous synchronization mechanism between the participating clusters. With the open-source Cisco (formerly Banzai Cloud) Istio operator, forming and then sustaining a multi-cluster Istio mesh is almost fully automated. It is made possible by utilizing a cluster registry controller component, which provides continuous synchronization for the necessary resources between the clusters. In this session, you will learn: - How to form a multi-cluster mesh with ease - Learn how the necessary resources are synced between the clusters - Understand how the system recovers even when network endpoints are changed.

A

Hello, everybody good news, uh I'm the last one uh before lunch, my name is lastobansanaj. I'm a software engineer at cisco. I previously worked at the startup called banzai cloud, which was acquired by cisco and I've been working with istio for like three and a half years now, so I will talk about this. Still uh it's more specifically multi-clustery steel. Today. Is it complex or maybe a piece of cake?

A

Let's dive in today, I will focus on the single mesh multicluster multi primary on different networks, steel setup, which means that we have only one single steel mesh. The istio control plane is installed on each cluster and they are communicating over dedicated ingress gateways to install this setup.

A

Today, according to the official steel documentation, what you need to do is several manual steps. These are essentially cube. Ctl apply, commands still ctrl commands even running some best scripts, getting some resources from one cluster and applying to the other.

A

If you do all this in the right order, then you have this smart primary on different networks, setup ready.

A

If you need to do this once that might be fun, but if you, if you need to do this a couple of times, actually it can be pretty cumbersome also, even after you have all this setup specific to the multi-primary topology, you should have these two configurations. Synchronized between the clusters.

A

There is no out of the box support support that for istio. Today, you can only achieve that with external tools. So could all this be better in sto? Could we automate this somehow for our users? How let me introduce you to a possible solution by first dividing all these manual steps uh in the official docs into two categories. The first category is easy. It involves only one cluster like installing this to your control plane on a cluster or installing the eastwood gateways.

A

The second category is the one which involves some kind of configurations between the clusters.

A

Like configuring, the trust relationship between the clusters or enabling uh cross cluster and point discovery actually to solve the first category is, is not that hard. It could be done many ways we opted to go with the kubernetes operator based solution. More specifically, we use the open source, cisco, sd operator.

A

I will highlight here that this is not the official sd operator that most of you are probably probably familiar with. This is a completely different iste operator implementation.

A

um Actually, this was implemented and open sourced before the official alarm back at banzai clouds. Now it is usually referred as cisco st operator. What this operator does is that it automates all those single cluster steps, so it installs this still control, plane, installs, these gateways configures those etc. This is the easier part. The second part is, is more challenging to solve, which involves multiple clusters, uh because they were searching for the right ways to solve solve that problem, and we couldn't find the right one.

A

So we ended up implementing our own solution, and this is called cluster registry. We have recently open source trust registry. You can find it on github as well. So cluster cluster registry has yet another kubernetes operator based implementation, called the cluster registry controller.

A

I guess you can see a theme here we kind of like operators, so cluster registry is a fully generic tool for any multicluster kubernetes use case, because what it does it is able to synchronize kubernetes resources between multiple clusters.

A

Now, in conjunction with the ist operator, these two tools can make sure to automate all those steps to to have the multi-primary on different networks set up ready like, for example, the cluster registry can sync kubernetes secrets between the clusters containing the cube api server access to the other clusters, and this way they can enable for cross cross cluster and point discovery, or we implemented an automated federated trust based solution as well.

A

I will call out here that this is the only main difference between the official steel setup and compared to our solution, because by default they recommend the common trust-based approach. We rather use this federated trust-based approach and automated it also. I mentioned that these two configurations should be in synced after everything is set up. Cluster registry is able to help us with that as well.

A

What I'm stating so far, if you listen carefully, is that the istio operator can automate all the single cluster related steps and with the cluster registry, we can actually automate all the multi-cluster related steps as well, which means that it should be easy enough to set all this up right now. Let me try to do that.

A

A

Okay, it was not that bad, so it's really hard like this okay. So what I have here is that I have I have two kubernetes clusters. I have these two operator and cluster registry controller installed on both, and I have also made sure that the cluster registry controller is able to synchronize the resources between these two clusters. That's the only manual step. I don't have time to show in this in this demo right here. What I'm gonna do is that it's gonna be bad.

A

Let me apply two crs first real quickly and then show you the content of those okay.

A

Okay, so I applied the istio control planes. These is still control planes cs to both clusters. These are custom resources for rsd operator and they install in steel control planes on these two clusters.

A

These two crs are almost identical. We are using steel 13 for these. We are installing an active steel control plane, which is the same as the primary term in the multi-primary setup. We just use the active term. Instead, we are installing the east-west gateways and we have some additional setups for this config for the multi-primary setup. The only difference between these two crs is that the first one is using uh a different network than the second one, and that is because we don't have port to put connectivity configured between these two clusters.

A

They will instead communicate over the dedicated east test gateways. So all I did is apply these two crs and believe me or not. The single mesh multicluster multi-primary on different networks setup should already be configured automatically on these two clusters. That's it!

A

Actually. I will need you somewhat to believe me, because I won't have time to show everything, but let's see a thing or two, of course we have these two control planes running on both of these clusters. We also have the east-west is running as well. These are the easier part.

A

Let's see something more interesting as well.

A

Yeah, so from from the stod logs on the first cluster, we can also already see that the first cluster can already reach the second clusters uh cube api server address for endpoint discovery and the other way around. That's where the second cluster can reach the first one, even though we didn't do any manual secret copying or anything like that. Between between these two clusters, it was all done automatically.

A

I think this is pretty neat already, but let me show you one more thing which is, which is the instill config synchronization. So, as you can see, there is no uh steel configurations on these two clusters.

A

So let me be strict here and apply this strict streak through to the first cluster.

A

As you can see it's already here and in this setup, what we get for free as well, that it's already copied and synchronized to the second cluster as well with this open source solutions. This comes out of the box without any external tools as well. So I think this is pretty neat.

A

Let's go for takeaways.

A

Yeah, so with these two open source tools, these two operator and plus registry, we can almost fully automate the single mesh setups. Today I was concentrating and talking about the multi-primary setup, but it actually works very similarly with the primary demod setup as well, and actually you can very easily combine the two, so you can have any number of primaries and reboots in the same mesh and configured automatically, also partly why we like operators is that they sit very well with the declarative and github-based workflows.

A

So mostly all you need is installing the controllers, the operators and some custom resources that I showed, and you should have this setup. Setting setup ready as well, and also as I mentioned, we have out of the box in steel, config synchronization as well, and that's worth mentioning here- is that this comes without a single point of failure, because there is no uh one single control plane uh to track all this. This comes with a fully distributed manner.

A

So at this point I will ask you and let you decide if multi-cluster is complex or piece of cake.

A

If you want even more than a piece of cake- and you you want it for free, then you should try cisco's product called kalisti, um which, using these open source tools, gives you a fully automatic multi-cluster experience. It comes with a nice ui and much more if you are interested either in our product or any of these open source tools mentioned today. Please visit the cisco booths at kubecon, or I think I'll be right here for a few more minutes.

A

So if, if you interested how we bake this cake or have any questions feel free to come here, I'm happy to chat. Thank you very much for listening.