> Hello, everyone. My name is Phill Gibson.
I'm a Senior Program Manager at Microsoft,
working with our upstream open source projects.
In this session, we're going to
talk about Open Service Mesh.
Open Service Mesh is
a lightweight extensible Cloud-native
service mesh that you can
utilize to quickly secure the communications of
your services running in the Kubernetes environment.
OSM takes the approach of providing
a simple way to get the core features and
functionality needed without overcomplicating
the operational experience to
secure your Cloud-native workloads.
In the following demo,
we're going to show you how you can easily
enable the OSM add-on to
an AKS cluster and configure it to protect
existing services running in the cluster.
We will first be deploying
a sample bookstore application to the cluster,
and that will deploy out two initial services shown
here as "Book Buyer" and "Bookstore V1 Service."
The "Bookstore V2 Service" will be deployed
later in the demo to
showcase the traffic split functionality.
The Book Buyer service will begin
communicating to the Bookstore V1 service once deployed.
Next, we will enable the AKS OSM add-on to
the cluster and it will
default to allow permissive traffic mode,
meaning no communication enforcement rules
will be deployed by default.
This is to ensure that your application
continues to run as is with no interruptions.
We will then onboard the Book Buyer and
bookstore namespaces for OSM to manage,
which will allow the envoy sidecar proxies to be
injected alongside
your application's container in the pod.
We will then verify that the Book Buyer can still
communicate to the Bookstore V1 Service.
Once we verify that,
we will then change the permissive mode
of OSM to be equal to false.
In return, we should see
from the logs that the Book Buyer will no
longer be able to communicate
to the Bookstore V1 service.
Next, we will deploy our SMI traffic target policies,
which will instruct OSM to allow traffic from
the Book Buyer service to resume
communications to the Bookstore V1 service.
Finally, we will deploy
an SMI traffic split policy
that will split and weigh the amount
of traffic from the Book Buyer to
both the Bookstore V1 service and Bookstore V2 service.
The first thing we'll do is, in Azure,
we'll go ahead and create our resource group that
will house our AKS cluster.
We'll create that in the eastus2 region.
Next, we will deploy
a brand new AKS cluster into that resource group,
and that will kick off the deployment.
We'll give it a second to complete.
Okay, we're completed.
Then simply, we're going to just get
our credentials to access
the cluster for our Kube control.
We already had this in,
the config file so we'll just simply overwrite it.
Then we will check our current contexts
to ensure we're on the brand new cluster which we are.
Next, what we'll do is,
we'll just list all of the AKS add-ons.
Again, this is a brand new cluster,
so we're not expecting
anything so this should come back as null.
Now, we're on to deploying the bookstore apps.
We got three manifests
or ymls that we're going to deploy.
The first one's going to be the "Book Buyer."
The second will be the "Bookstore" service.
The last one here is going to be
the "Book warehouse" service
where books are being retrieved from.
Next, we will just take a look at all of
the components in our bookstore namespace.
We're just verifying that we do have our pods up and
running with services here.
Then what we're going to do is we're going
to trail the logs of
the book buyer pod here.
We'll go ahead and query to get
it and then what we're going to do is just
tell the logs coming out of the book buyer to ensure
that it is talking to the bookstore service.
Here, we'll stop the login. You see that,
yes, we are connecting to
the bookstore service and we have
our 200 OK. You'll notice the server is in a,
so when we deploy the envoy sidecar proxy,
you'll see that change to envoy.
Next thing we'll do here is we'll go ahead and
enable the OSM AKS add-on.
That's been enabled.
What we'll do is we will just query
for that specific add-on to
ensure that it is installed on
to the cluster which we get a true back.
The next steps, what we're going to do
is do a light test just to
see and ensure that the OSM
add-on is correctly installed and functioning.
Also, we're going to take a look at
the pods for the OSM controller. It's up and running.
We'll then take a look at
the services here in the Kube system namespace.
You'll see that there are three.
We have an OSM config validator, an OSM controller,
as well as the OSM injector,
all part of the OSM add-on service.
Finally, here, we're going to query,
there's a configuration configmap.
One thing to notice here is
the permissive traffic policy mode setting.
We will be changing that settings showing how
the access works for the OSM service mesh.
Next thing we'll do is we will need
OSM to manage the namespaces,
so we're going to add
these namespaces to OSM to be able to manage.
Then what we'll do here is we will now
start the envoy proxy sidecar injection.
First thing we'll do is we'll take
a look at the pod for book buyer.
You'll notice that it's one-of-one ready-state,
meaning there's only one container in that pod.
What we'll need to do to get the envoy sidecar injection
is to restart all of the deployments in those namespaces.
We'll kick off the book buyer.
We got the bookstore being restarted.
Finally, we will restart the book warehouse deployment.
Since we have all of those restarted,
now what we can do is we can go back and look
at the book buyer pod.
Now you see that it has a ready state of two of two,
meaning that that envoys sidecar has been
injected next to our application container.
We can quickly view that.
Let's query to get the book buyer again,
and then we'll do a describe on it,
and we'll look at both of
the containers that make up that pod.
Let's scroll up and the first container we'll see
here in the manifest is our envoy container.
If we scroll up a little higher,
we'll see our book buyer application.
Again, since we are in permissive mode,
let's go ahead and
just check to see that the book buyer can still
communicate to the bookstore service, which it can.
We're seeing now the envoy setting here that
that communication is being transverse
through the envoy sidecar proxy.
Then we'll take a look at the configmap configuration.
We'll go ahead and actually change
the permissive traffic mode policy to false.
That's going to require
a specific policy for OSM to pass that traffic.
We'll just verify that that setting was set to false.
Now we're going to need a specific rule for OSM
to allow traffic in the mesh.
If we go back and we tell
the logs of that book buyer pod again,
we will see that communication has ceased.
The book buyer can no longer talk
to the bookstore service.
What we'll do is we will now enable
that communication and restore
it by deploying a SMI traffic access policy.
We have our policy now deployed.
If we go back
and take a look at our containers,
I'm sorry, our logs from the book buyer pod,
we now see that the book buyer
can now access the bookstore service
with the SMI traffic access policy.
Now, we're going to showcase the traffic split.
First thing that we're going to need
to do is actually deploy
that additional bookstore V2 service,
so there's just an additional service out there,
and that will automatically
contain the SMI traffic access policies as well.
Then we will deploy our traffic split.
What you're seeing here is we're going to
instruct the book buyer
to talk to both the bookstore
and the bookstore V2 service,
and we're going to weigh
those two communication channels,
One 25 percent to bookstore,
and then the other is
75 percent to the bookstore V2 service.
We will apply that SMI traffic split policy.
Now what we can do is,
we can tell the logs
specifically looking for the identity.
The identity property is going to
actually show us which service that we are talking to.
What you're seeing here is the output.
We should see more bookstore
V2 services since we do have it
weighted 75 percent more
than the normal bookstore service.
That was a quick demo showcasing Open Service Mesh,
providing some of the most common
functionality needs of a service mesh.
In summary, Open Service Mesh is
a robust service mesh utilizing the envoy proxy.
OSM provides a simplified operators experience
for the most common set of
service mesh features and functionality.
Finally, the AKS OSM add-on provides a convenient setup
that will provide a fully supported service mesh
as part of the AKS service.
If you are ready to try out OSM in your environment,
please visit the documentation regarding
the AKS OSM add-on preview.
There, you will see additional tutorials and scenarios.
You can try out such as ingress configurations,
as well as some observability and tracing options.
Thank you for your time viewing this session.
I hope you venture out and
try Open Service Mesh in your environment.