Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2021, 29 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Service Mesh using Envoy on Windows - S. Nanopoulos, P. Balasubramanian, K. Subramanian, N Jackson

Description

Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.

Service Mesh using Envoy on Windows - Sotiris Nanopoulos & Praveen Balasubramanian & Kalya Subramanian, Microsoft; Nic Jackson, Hashicorp

Learn about the ongoing efforts to enable Service Mesh on the Windows platform, what it can do now, and what is coming next. Learn how to configure the Windows networking stack to redirect traffic to a sidecar proxy. Understand the differences between Windows and Linux platform support. Learn how to configure and deploy Envoy as a sidecar proxy. Finally, watch all the above working together on a live demo of Open Service Mesh (OSM) on Windows.

A

Hello, everyone uh welcome to our talk uh today we're going to describe our efforts to enable service mesh scenarios on the windows platform uh using the online proxy uh hi. My name is praveen balasubramanian. I currently work as an engineering manager at microsoft. I lead a development team that focuses on the core networking platform and the network stack for windows.

A

My recent work has focused on high performance, networking, internet protocol evolution and container. Networking with me here today is nick.

B

Hey, how are you doing so? I'm nick jackson, I'm a developer advocate at hashicorp and I'm also an smi maintainer service mesh interface. I'm also writing a book on service mesh patents with my good buddies liam paul- and I am incredibly excited about seeing service mesh absolutely everywhere, including on windows.

C

Hi everyone, I'm sothiris and I'm currently work as a software engineer at microsoft, I am maintainer of envoy proxy and a core member of the envoy windows development group on envoy. My work focuses on low-level networking and supporting the windows platform, abstraction layer, I'm also a contributor at open service mass.

D

Hi everyone, I'm kalia subramanian, I'm a software engineer at microsoft. So previously at microsoft, I worked on windows, container networking and I contributed to cube proxy flannel and cube adm for windows.

D

Now, I'm on the open service mesh team at microsoft, where I have been helping out getting windows in osm and also working on secured clusters for osm.

D

So now, let's get into our agenda.

A

So what is on the agenda today? We will start out by recapping what is a service mesh and we will make a case for windows platform support. We will then describe the four major components that are required for a service mesh deployment, including the platform, the proxy, the container orchestration system and the service mesh control plane.

A

We will then demo a service mesh powering both windows and linux containers. We will conclude with the summary and our future roadmap.

A

So what is a service mesh? In a nutshell? It's a solution that provides various enhancements to your application's service to service communication in the context of kubernetes, a service mesh will inject a proxy such as onward commonly called as a side car into selected workload, pods site or proxy intercepts incoming and outgoing traffic based on configured policies, as you can see in this diagram onward, is intercepting all the inbound and outbound traffic for two containers running a node.js application service mesh enables users to easily apply features that the proxy offers consistently and at scale.

A

Some of the prominent features of a service mesh include control traffic management, for example, load balancing traffic splitting applying policies, such as rate limiting or retries service mesh, also enables observability of various metrics like service to service, latency, request per second and number of http errors, etc.

A

And, finally, a service mesh also improves security by bringing encryption and authentication, for example, by enforcing mutual tls and encrypting all the network traffic in the cluster. Without any application code, changes.

A

So you may ask: why do we care about service mesh on the windows platform? As you can see here, a lot of users are asking for a service mesh that supports windows in the industry. Many organizations have a mixture of os platforms in their environments. Many customers are claiming that lack of service mess. Support for windows is one of the biggest blockers to containerize their applications or even to bring their enterprise workloads to the cloud.

A

Without a cross-platform service mesh they face really hard choices, either rewrite the applications to run on linux, which is very expensive or continue maintaining legacy applications and infrastructure.

A

There is also strong interest from many microsoft. First party applications which are containerizing. They are adopting a microservices architecture and desire a service mesh that supports the windows platform for all the benefits we talked about previously.

A

Observability security and traffic management.

A

Now, let's look at the four components that need to come together for a service mesh solution. First up is the operating system platform like linux or windows that supports containers and container networking.

A

Next up is the sidecar proxy that is used to redirect traffic and has the rich feature set for observability security and traffic management. Examples here include envoy and linkerd.

A

Next is the container orchestration solution, for example, kubernetes and finally, the service mesh control plane, which makes the solution scalable and examples here, are istio and open service, mesh or osm.

A

The focus of our talk today is the windows. Server operating system and kubernetes is used for container orchestration. Our service mesh solution will be completed by open service mesh, which uses envoy as the sidecar proxy.

A

First, let's begin by talking about the first component, which is the operating system platform windows. Server. 2022 is the most recent release of windows, which is now generally available in this release. We have added platform capabilities to windows, to support traffic redirection for containers.

A

The redirection works for both outbound and inbound traffic and utilizes the windows filtering platform capabilities. We have new host networking service or hns apis which support new policies for endpoints. These policies are applied on the container host and they require admin privileges.

A

Currently, these apis only support tcp over ipv4, but we do have future plans to add support for udp and ipv6. We will take a deeper look at this policy in a later slide windows. Server 2022 also includes new winsock socket apis that allow a sidecar proxy to query the original destination for a redirected connection.

A

These apis are available on the latest sdk and they've already been integrated with the onboard proxy.

A

This release also features smaller container images and extended support for nano server based images.

A

Now, let's compare and contrast the redirection policies between the linux and windows platforms. If you look at the left hand, side on linux, the ip table policy allows configuration of proxy redirect rule with specific port numbers for both outbound and inbound directions.

A

The rules also allow skipping redirection based on user id, ip prefixes or port numbers.

A

This allows exemption of envoy's own control traffic and prevents redirection loops on the right hand, side you can see that the new hms policies in the form of a powershell script, if you notice, there's a lot of similarities.

A

The hns endpoint commandlet, takes in redirection policy in the json format. Both outbound and inbound redirection are supported with specific proxy ports for the sidecar. This policy also supports exceptions which are again based on ip addresses and port numbers.

A

In the user set field, you can specify either a user or a user group that is exempt from this redirection policy for windows containers. One challenge is that user sets are generated randomly at runtime, so it becomes impossible to know in advance. The user said that envoy is going to run as in every part.

A

This is where specifying a group set is extremely useful. You can then run the proxy from a known user group.

A

Next up so theorists will describe the next component of the service mesh solution, which is the on y proxy.

C

Thank you profit for the summary of all the changes in windows server. Over the past one half year, the envoy windows development group has made substantial progress on porting on void windows.

C

We announced general availability support for envoy and windows in may and for the past 10 months, the envoy pipeline has been compiling and running tests for almost every feature. At every pull request. We strive to make envoy configurations cross-platform. We believe that this will help control plane developers want to apply the same configuration across their entire cluster.

C

An example of such control plane is service mass. With that goal in mind, we have a cross-platform implementation of the original destination listener that underpins service mesh on voice configurations.

C

The only notable difference is that on windows, you must also specify the traffic direction property of the listener. We use this information to ensure that proxied connections will have the same security properties as the original connection. This is important for security reasons as the proxy and the application might have different firewall rules.

C

We also have confirmed that the traffic direction property is already set on most service mass implementations.

C

Also, we have implemented cross-platform access loaders to standard output, so you can enjoy the observability that envoy offers on all platforms. Finally, we have been working on the envoy network data path. We improve the asynchronous event loop on windows to scale across multiple threads.

C

Also, we have introduced synthetic events that allow us to emulate equal behavior on windows.

C

The last piece of the puzzle is configuring kubernetes to apply the hns traffic redirection policy for you traditionally, on linux, redirection policy is configured by the init container. The init container is scheduled by the service mess to run before the application, and it applies the ip table rules on the board. This is not possible on windows. The reason why it is not possible stems from a core difference between hns pulses and ip tables.

C

Hns policies are a property of the host and not of the pod. As a result, these hns policies need to be configured by a cni plugin cni plugins are already supported by kubernetes for experimentation purposes. If you can add the redirection policy manually to the static configuration of your existing cnr plugin.

C

However, we accept that for production environments, you will need a cni plugin that will read these pulses from port annotations and have the options to have different policies on different ports.

C

Finally, you need to run envoy as envoy user envoy user is already set up for you in the envoy container inwards. The envoy user is already configured to be part of the network operators group. You can leverage the fact that envoy user is part of a well-known group to configure traffic redirection exemptions for envoy.

C

With this in place, envoy traffic will not be redirected and you will not have to deal with nasty infinite redirection bugs.

C

Open service mess or osm for short, is a lightweight and extensible cloud native service. Mask osm takes a simple approach for users to uniformly manage, secure and get out of the box of durability, features for highly dynamic microservices environments.

C

It leverages an architecture based on envoy, reverse proxy sidecar and works by injecting an envoy proxy as a sidecar container. Next to each instance of your application, osm is built to be simple to understand and contribute to. Users should be able to install, maintain and operate osm in their cluster with minimal effort.

C

It is easy to troubleshoot and it even comes with tooling that makes debugging as easy as running an app on the terminal. You can easily configure it with a service mesh interface, a standard for all service messages on kubernetes that provide a basic feature set for the most common use cases.

C

Now, for the exciting part, let's see a demo where windows, server, 2022 envoy to bernades and open service mess work together for the first cross-platform service mess. Demo: hey I'm here with kalia, who is a contributor at osm to give you a demo of the first cross-platform service mass implementation before we start with the demo, do you want to introduce yourself and tell us more about the osm project.

D

Thanks satiris hi, my name is kalya and I'm a developer on open service, mesh or osm, which is an open source service mesh. So people can use osm to secure and manage traffic between the services that they're running and for those who aren't familiar with service meshes generally. The way that it works is that there's a proxy running next to each application that manages incoming and outgoing traffic.

D

We call this the data plane and osm uses onboard proxy to implement the data plane. The data plane gets controlled by a control plane running in the mesh. The control plane makes sure that those proxies get set up properly and reflect the right traffic related rules for the application.

C

So, as a as a user, how do I configure the control plane.

D

So users can configure the osm control plane using the service, mesh interface or smi, so smi provides a set of apis for the most common features that people use service meshes for, for example, there's a traffic split api which allows users to define how they want to split traffic between different versions of an application.

D

There are several meshes that have built against smi already, so you might even be able to use your existing smi configurations with osm.

C

Awesome, I think we're gonna also see more about the smi on the demo as well, but before we get to that, uh do you want to walk us through about the demo that you have prepared on the osm repository.

D

Yeah, so the osm demo is comprised of the bookstore service, which is a top level service that load bounces across various bookstore application pods, and we have two versions of our bookstore bookstore v1 and bookstore b2, and each of those versions get their own service as well. So the v1 and v2 services act as back ends in our bookstore demo application.

D

We also have two clients book, buyer and book thief and those clients make requests to the top level bookstore application, and then we use the traffic split to serve those requests to the corresponding backend services.

D

We also have book warehouse and the bookstore makes requests to book warehouse to restock on books.

C

And I assume this is not the standard osm demo, but there's some services running on windows and some are running on linux. Right.

D

Yep exactly so, if we take a look at our cluster and we do cube, ctl get nodes dash o wide, we can see that we have two worker nodes that are windows: server, 2022, as well as a linux worker node.

C

And if I get all the codes, I can see that some of them are scheduled on windows and some of them are scheduled on linux.

D

Exactly so, if you take a look, you can see that we have our bookstore v1 pod running on linux and we have our bookstore v2 pod running on windows. We also have book buyer, which is running on windows as well.

C

And I see that the osm control plane is running on a linux node.

D

Exactly so, the osm control plane runs fully on linux, but it's still able to program the data plane, regardless of whether the envoy proxies are running for windows, applications or linux applications.

C

And how can we see the interaction between the book buyer and the bookstore now.

D

So for this demo we have installed an ingress gateway, so if you get the public ip, then you'll be able to access our book. Buyer ui.

D

So here you can see our book buyer ui that we're accessing via ingress. You can see that the book buyer is buying books from both bookstore v1 and bookstore v2, and it's buying pretty evenly between the two.

C

So there is an smi policy that configures this right.

D

Yes, we're using smi traffic split and if you go to our cluster, we can actually view the traffic split that we're using.

D

So here you can see that we have our traffic split spec and we have two back end: services for bookstore v1 and bookstore v2 and they're both assigned equal weights of 50.. We also see a service field sometimes referred to as a root service, and this root service just refers to bookstore, which is the top level service. That represents the two backends.

C

And I assume this is highly dynamic, so if I want to change the weight between the two services, I can just update this policy right.

D

Yep, so that's really easy: all you have to do is just update your traffic split and apply it, and then the osm control plane will take that new traffic split and use that to configure the data plane appropriately.

C

Okay, I think I have this new policy ready here. I just got it on the terminal, so people can see it and let me apply it right now.

D

So here you can see that, with this new traffic split we're going to be sending all of the traffic to bookstore v1, since it has a weight of 100 and no traffic will be going to bookstore v2.

D

And if you look at our book, buyer ui again, you can see that we are no longer buying books from bookstore v2. But we should see the bookstore v1 counter increment.

C

In this presentation we revisited the fourth verticals that underpin any service mass. We saw the hns policies and window socket options that allow you to configure the operating system to redirect traffic to a sidecar proxy.

C

We went through the progress that windows development group has made to make envoy proxy run seamlessly on windows. Then we went through the configurations needed to ensure that kubernetes applies the redirection policy for you. Finally, we showed the first demo of a cross-platform service mess running on osm.

C

With that, I will hold it back to pravin, to tell you what is now roadmap and how you can stay updated.

A

Thanks so uh that was a great demo on our future roadmap. We have work across the os platform osm as well as onward on the windows platform site. We would like to enhance hns policies to support ipv6 and udp traffic redirection on the service mesh side. We would like to upstream production grid support for the windows platform on osm and finally, we'd like to improve onward extensibility by adding web assembly support on windows and also publish windows, server, 2022, container images with onward.

A

We encourage you to join us and contribute to this effort and also provide us feedback for future improvements and our roadmap. All the work here on onward osm is being done upstream on github. You can look at known issues. Report new issues or feature asks on github prs are also very welcome.

A

In addition, we have slack channels where you can get support and answer to questions and help coordinate work.

A

This work would not have been possible without tireless effort across the industry. We would like to thank all contributors across windows, networking and the osm and onward communities to help make this a reality.

A

And with that, thank you, everyone for attending our presentation, we'd like to open it up for any questions. You may have.