>> Today we're going to talk about Open Service Mesh.
My name is Michelle Noorali,
I'm a Software Engineer at Microsoft.
I contribute to and work on Open Source Cloud Native Technologies.
A Service Mesh is a dedicated layer of infrastructure
for managing and securing service to service communication.
OSM is an open source, envoyed based,
SMI compliant, and Kubernetes native service mesh.
Let's break that down just a little bit more.
With OSM, a sidecar envoy proxy
is injected into each application pod.
The proxy then manages all incoming and outgoing traffic.
A control plane, which is a set
of OSM components running in Kubernetes,
manages this set of envoy proxies,
which we'll refer to as the data plane.
If you're not already familiar,
SMI stands for Service Mesh Interface,
which is a set of portable APIs for
configuring the most common Service Mesh capabilities.
Key features of OSM.
You can use OSM to configure
traffic shifting for common deployment scenarios,
secure service-to-service communication with automatic mTLS,
enforce fine grained access control policies for your services,
observe metrics for debugging and monitoring of your services,
integrate with native or
external certificate management solutions,
and you can onboard applications onto
the mesh with our automatic sidecar injection feature.
The following is a set of demos to help you get
started and set up with using OSM.
First, we'll see how to install OSM,
thus setting up a control plane.
Then we'll set up our applications and our data plane,
then we'll define some access control policies,
and then we'll see how we can do traffic shifting.
Let's take a look at how to install
open Service Mesh into your Kubernetes cluster.
The first step is to download the OSM CLI Binary.
Once you have that set up,
run the OSM install command to
install an open Service Mesh control plane.
The control plane is the brains of the Service Mesh,
as it's the piece that bootstraps
and manages the data plane that is
the set of envoy proxy's running
inside application pods as sidecars.
The control plane has several other features
we'll get into later in the demo.
You can have multiple control planes in a given cluster.
Each control plane will be installed into
a specific namespace and just needs
a unique identifier we call mesh name.
These can be configured with flags on the command line,
or you can use the defaults provided.
The install command will first perform
a set of checks to ensure that your cluster is ready
for installation and that you have
the necessary permissions for a successful install.
It will then install,
the OSM control plane components as
Kubernetes resources into the specified namespace.
The bulk of the logic of
OSMs control plane lives in the OSM controller pod,
as you can see here.
The other pods are used for observability features.
Now that we have our control plane installed,
let's go ahead and get our data plane setup.
So, our sidecar envoy proxies.
OSM allows you to enable automatic sidecar injection
on namespaces and we're going to walk through how to
do that. First, let me show you what I have set up so far.
So, I have these applications set up
already and notice that they
have one container running in each pod.
So, I have a bookstore application.
I have version one and version 2 of a bookstore.
I have a book buyer that talks to the bookstore
and basically requests to buy books.
I have a book thief that tries to steal books from
the bookstore. So, it's also talking to the bookstore,
and I have a book warehouse.
So, whenever the bookstore loses inventory,
it'll restock by talking to the book warehouse application.
Now to add these namespaces for automatic sidecar
injection, all I need to do is add a label on the namespace.
But I'm a little bit lazy, and I don't want to do that.
So, I'm going to use the OSM namespace add command,
and I'm just going to and all of the namespaces
where my applications are currently running.
Now the way this works is that every time a
pod gets started in this namespace,
OSM is just going through and check
the envoy proxy as a sidecar into those pods.
But in order for us to be able to do
that in a situation where we already have pods
running as we're going to need to just restart the pod.
So, I'm going to use the kubectl
rollout restart command to do that.
And I'm just going to restart each of these applications.
Bear with me as I do it for these five applications running.
If you haven't already seen this command, it's pretty handy.
No, this one will be book warehouse.
Now let's go ahead and check out what's going
on in our application set up here.
So as you can see, these pods have just been restarted,
and they now have two containers running in them.
So, let's just go ahead and see what
the book buyer pod looks like to get
an example of what actually happened.
So I'm going to describe this pod.
As you can see here,
if you go up to containers,
you'll see two containers are running.
The book buyer container,
which is your application and the envoy proxy container.
So just like that, it's pretty simple to
get automatic sidecar injection.
So, we currently have an OSM control
plane running and some applications have been
added to the mesh and configured with sidecar proxies.
Let's take a look now at how we can
implement access control between these services.
OSM has a native SMI support,
so you can use traffic target and traffic specs SMI
resources to get granular about which services can talk to
each other on which routes and even match on HTTP headers.
By default, if you add an application to the mesh,
know other services will be able to
communicate with it, unless allowed.
Communication is deny all by default.
As you can see, by the current state of our applications,
no books are being bought by the book buyer,
no books are being sold by the bookstore,
and no books are being stolen by the book thief.
To actually enable services to communicate with each other,
you need to deploy SMI traffic target
and traffic specs resources.
And on the right, you'll see what a traffic target
for the bookstore actually looks like.
So, here we're saying that the book buyer can talk to
the bookstore on some specific route group configurations.
And below down here, you can
actually see what that configuration looks like.
And here you can get very granular about what paths
you allow, what methods, and even headers.
So let's go ahead and apply this configuration
and see what happens.
Alright, so we're going to wait a few seconds for this
to kind of all propagate and traffic to start flowing.
And, during that time, let me talk to you about
permissive mode on OSM.
So, if you're new to Service Mesh,
you may not be in a place where you want to enable
this deny all by default, service configuration.
You may actually want all your services to
be able to communicate with each other at first.
And for that, we have a flag called
Enable Permissive Traffic Policy on the install command.
So, take a look at that.
If you want to just kind of observe your traffic patterns at
first before actually applying any access control policies.
Alright, so coming back here,
we can see now that we've added this access control policy,
that books are being bought and the bookstore is
selling books because we've
actually enabled it with our configuration.
Down here, if we wanted to actually
allow the book thief to talk with the bookstore,
we would just go ahead and
change the configuration like I just did there,
and then we would just apply the manifest.
Right, so that has been configured.
In just a few seconds,
we should see the book thief being able to buy books
from the bookstore or steal books from the bookstore.
In this situation, we're actually just
assuming the book thief has changed its ways
and promised not to steal books and
will actually buy books instead of stealing them.
And here we see that books are coming in.
The books are being stolen by the book thief
from the bookstore.
Let's take a look at how you might do traffic splitting with
OSM for rolling out different versions of your applications.
You can use the SMI traffic split resource
to define what your traffic split should look like.
Currently we're routing all of our traffic
to bookstore V1 and none of our traffic to bookstore V2.
If I were carrying out a canary deployment,
I'd want to maybe start out with rerouting 10 percent of
my traffic to V2 and leaving 90 percent at the V1.
After observing some metrics around how that traffic is doing,
I'd probably decide whether I want to increment
more of my traffic to V2 or not.
I can also automate this process with
progressive delivery tools on top of the mesh.
If I want to be less manual about the whole thing.
For this example though,
we're going to route 50 percent of our traffic to
the V1 and 50 percent of our traffic to V2.
Then we're going to go ahead and apply this configuration.
So, that's going to take a minute to reconfigure.
Let's go ahead and reset these counters,
so we can get a better idea of how the traffic looks right now.
And while we're waiting for those changes to propagate,
you can also do A/B testing scenarios with traffic split,
as SMI now supports matching on HTTP headers,
even on the traffic split resource.
Alright, so now we can see that the counters are
incrementing and roughly half of the traffic is going to be
one and half of the traffic is going to be two.
That concludes our set of demos.
In this section, we set up the control plane and the data plane.
We installed applications into our Service Mesh.
We also defined access control policies
and saw how we could configure traffic shifting.
Here are some resources that you can use to learn more about OSM.
Thank you so much for joining us today.