Cloud Native Computing Foundation ServiceMeshCon EU 2021, 14 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Keynote: Multi-Cloud and Multi-Cluster with CNCF’s Kuma on Kubernetes and VMs - Marco Palladino

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Keynote: Multi-Cloud and Multi-Cluster with CNCF’s Kuma on Kubernetes and VMs - Marco Palladino, Co-Founder + CTO, Kong Inc.

Organizations are well on their way to adopting microservice architectures, and as a result applications have grown to become decoupled and distributed - with connections spanning across geographies, clouds, and even workload platforms. Establishing service mesh as a “Day-0” solution for every team and application allows these organizations to deliver, livecycle, and troubleshoot applications faster and at global scale.

In this talk, Marco Palladino, Kuma maintainer and Kong CTO, will introduce you to Kuma, an open-source service mesh built on top of Envoy and a CNCF project focused on delivering simplicity and scalability to every application.

We’ll cover:

Kuma’s unique feature set designed for enterprise architects.
Give you a first look at Kuma’s unique multi zone deployment, including hybrid Kubernetes and VMs.
Walk you through a short demo to see Kuma in action across multiple clusters and clouds.

A

Welcome to servicemeshcon today we're going to be seeing how to run kuma in a multi-cloud and multi-cluster way. My name is marco palladino. I am the cto and co-founder of kong, but before we look into kuma, let's ask ourselves why service mesh became such a popular pattern.

A

We have learned many years ago that our monolithic applications once they grow. They become very hard to scale very hard to deploy in a reliable manner, they're hard to use hard to deploy hard to contribute to, therefore, we're going to be decoupling, our monolithic applications into separate services microservices.

A

Now, when we do that, we get speed, we get velocity, we get agility, we get a lower time to market because we can reuse some of these components when we create new applications, but on the other end we're also introducing more and more connectivity at the backbone of our modern systems.

A

When connectivity is down, our applications are done. Connectivity really glues together, all the services that we're creating and the more services we create. The more connectivity we generate.

A

Our application teams should not be in charge of managing that connectivity by themselves when they do it, they do it in a fragmented way and it's not their job. They should be instead getting that connectivity from the infrastructure that we, the enterprise architect, are provisioning them across kubernetes and virtual machines across multiple clouds and multiple clusters.

A

There is different connectivity types that our application teams are going to be asking us. They want connectivity at the edge when some of their applications must be consumed from outside of the organization by an ecosystem of partners and developers or mobile applications.

A

There is going to be connectivity across our applications when different teams are exposing apis that another team can consume, and then there is going to be more and more connectivity inside of our applications whenever our applications become microservice-oriented.

A

All of the services that make up the final applications, all of those services communicate with connections and those connections have to be secure, reliable and observable, and this is why, at kong, we originally created kuma in order to simplify how this connectivity can be offered by the enterprise architecture team to the application teams. No matter if they run on kubernetes or virtual machines, no matter if they run in a standalone or distributed way, we didn't stop there. We also donated kuma to the cncf foundation.

A

Therefore, hume is now available with the same neutrality in open governance as any other cncf project in the foundation like envoy proxy, for example, which, by the way kuma uses, and today it is a sandbox project over the next few months, we're going to be obviously climbing the cncf ladder into incubating and one day graduated because of the very unique set of features that kuma provides and it's ease of use.

A

Yet it's very powerful today is being used by over 900 organizations in very important and mission, critical use cases qma from a very high level standpoint. It is a control plane for service mesh. It supports envoy under the hood, but we don't require any envoy expertise to use.

A

Cuba is universal, it's a first class citizen for both kubernetes and vms, but really for any other containerized environment. As a matter of fact, you could be running kuma entirely on vms, with no kubernetes dependency whatsoever. We have created this universal support because we have a very clear understanding that we as enterprise architects. We must support the teams that are very far you know advanced in their kubernetes journey and the ones that are behind that curve, and so we want to support a service mesh that can run across the board on both vms and kubernetes.

A

As a matter of fact, we want that to be hybrid as well sometimes, and we're going to be seeing this in the demo, uh we can run in a multi-zone or single zone capacity. We can run in a multi-cloud multi-cluster capacity and we can easily scale upgrade and operate this service. Mesh simplicity is a feature. It's not a nice to have and we built kuma with that in mind.

A

Kuma comes with a lot out of the box. There is a gui out of the box. There is an http api out of the box on kubernetes. There are native kubernetes resources on vms. There is declarative config, uh there is an http api and a cli that allows us to effectively integrate huma with our ci cd workflows.

A

Kuma also comes with much more than that. It comes with observability charts and very easy to use, integrations with gateways and existing api management solutions. It supports any containerized environment, not just kubernetes, not just vms, but also environments like aws, fargate or ecs, and uh enabling features like zero trust security. Like fault injection, like traffic routing, it is one click away. We have native policies that allow us to do that.

A

Qma can be deployed in a multi-zone capacity. A zone can be a cloud, a cluster can be vms, can be containers, and we can create one deployment of human that spans across all the environments that we want to support, including private data centers, and then, on top of that one deployment of qma. We can create, as many virtual meshes as we want to compartmentalize how our teams and applications are setting up their mesh policies.

A

We obviously want to give a degree of freedom to the application teams to change the behavior of their applications without us, the architects always being the bottleneck of every request. Yet we want the underlying infrastructure to be provisioned for them, so they don't have to worry about it. We have automatic policy, storage and propagation with the concept of global control plane, which is the primary control plane and remote control plane, which is the secondary control plane.

A

All the policies we create can we can be created from the global and the global control plane will automatically reconcile and propagate these policies across all the zones that we want to support, not only. We can also enable connectivity from one zone to another in a very uh automated way. Therefore, if there is a service wanting to consume another service, none of these services have to know what zone they're running and how they're being built. As a matter of fact, we can also mix and match hybrid and kubernetes environments. It can be very, very complex.

A

The way we deploy it. Yet it is very easy to use and simple when we manage it so in the demo, I want to show you how we can run kuma in a multi-cloud and multi-cluster capacity on gcp and aws on three different kubernetes clusters on gcp and we're going to show. This is a demo about containers and vms hybrid, mixed together within the same mesh. So let me pull up my environment.

A

I do have my aws ec2 zone with the remote control plane and my demo application running in vms, and I do have my kubernetes clusters, the global and the east and the west uh that also have the demo application running every time. I increment a counter in redis from the demo app, depending on what radius instance we're incrementing, depending on which zone we're hitting we're going to be seeing different clusters. Now, if I connected to the global control plane, I can also expose the glue of kuma to understand.

A

What's the status of the current mesh and fetch all the um and you know all the status of my zones and my workloads, so I'm port forwarding the control plane uh in the cuba system namespace and once I do that we can go ahead and explore so, first and foremost, there is an api, an api that we can use to automate everything that the gui can do.

A

But if we go on slash gui, we can also see it, and we can see that this is running on three different zones: uh awsc two gkes, the gke west, and we do have a few services running inside of our systems as well as all the data plane proxies that are being connected to our service mesh, which is running in a distributed way. So, right now I can load my oops. I can load my demo application and that's probably the wrong address.

A

This is the right one. There we go. I can load my demo application and increment my radius counters now, because mutual tls is being disabled right now. In these uh current um setup, we need to enable neutral kls in order to allow for that cross zone. Connectivity so right now the default mesh has mutual, is disabled, so let's go ahead and implement mutual tls and enable it in one click.

A

uh Qmo will automatically generate the certificated authority for us, although we can provide our own and automatically, it will rotate the certificates for us so that the entire certificate management has been taken care of no matter if you have one service or 10 000 services.

A

So let's go ahead and create the um and create this zerotrust security policy uh in the global control plane. As soon as I create it, uh the global will propagate this to my uh other clusters. The certificates will be generated and as soon as they're being generated, we're going to be seeing cross zone connectivity from vms to containers across multiple clouds, multiple regions, multiple environments hybrid. This is how easy it is to enable zero trust security with service mesh.

A

Of course, there is much more to it that I want to show you, but there is not enough time. So if you want to get in touch with kuma, so first and foremost you can install kuma by going on cumulo as well as you can get in touch with our community and please do not miss the talk today about a federal use case and how we can support 10k transactions per second, with cuma by given by a user of hume itself. So thank you so much and enjoy the rest of your day.