[MUSIC PLAYING]
[WHISTLE]
JONATHAN KOLA: Hello, Mr. Kubernetes.
ELIAS PINTO: Oh, hi there.
JONATHAN KOLA: I have a new pod version for you to deploy.
ELIAS PINTO: Oh, um, just leave it right there.
I need to rebalance this network traffic between these two pods.
JONATHAN KOLA: Wow, it looks like you have
your hands full over there.
ELIAS PINTO: Just trying to do my job.
It would be really nice to get some help with all
of this network traffic.
JONATHAN KOLA: You know what?
I think I have just the thing.
It's called Istio.
ELIAS PINTO: Can you please show it to me?
[MUSIC PLAYING]
JONATHAN KOLA: Istio helps you manage and understand
the interactions and network communication
between microservices in your environment.
It is completely open source, can
be deployed in and across multiple environments,
whether you're working with virtual machines or containers
with an orchestrator like Kubernetes,
and consists of a number of components
that when deployed in your environment,
transparently layer on top of your distributed application
to allow you to do things like monitoring and load balancing
without any code changes.
In this short walk-through, we'll
see how we can use Istio to do very fine-grained traffic
routing in a distributed application deployed
on Kubernetes.
This becomes useful when deploying updates
to your application with patterns like Canary
or blue-green deployments.
I have a cluster running on Google Kubernetes Engine.
And I've already configured it to ensure
that any pod I deploy into my cluster uses Istio.
So I'm going to be able to monitor and control
the traffic to and from these pods for free without any code
changes.
Currently running on this cluster,
I have a very simple application that consists of two services.
The first service is the UI service.
This service is responsible for rendering and serving
the user interface upon request from the outside world.
I have another service called the color service,
which specifies the color of particular UI components.
So before the UI service can render and serve the page,
it has to consult the color service
to know what colors to use.
Taking a look at the pods, we should
see that I only have one pod serving the UI service
and four pods serving the color service.
Now suppose you want to roll out a newer version of the color
service, but you don't want to go all in,
but want to roll it out gradually in controlled stages.
For example, here I have a second version of my color
service that I want to deploy.
You could use Kubernetes deployments for that.
You create another deployment.
You label it appropriately, so that it's
included in the same load balanced group
as the v1 service.
Then gradually change the ratio of v2 pods to v1 pods to route
the desired amount of traffic to either version.
So let's go ahead and deploy that v2 service.
And we can verify that it was deployed successfully.
And here, we can see we have one v2 pod and four v1 pods.
Now when I go to my application, I
see my UI is displaying a blue button.
The color is coming from a v1 service.
But as I refresh the button multiple times,
I see a green button on occasion,
which is coming from my v2 color service.
And this happens about roughly 20% of the time.
Now, the limitation of this approach
is that the only way to control the percentage of traffic that
goes to either pod is by directly scaling
each version up or down.
So if you only want 10% traffic to hit your v2 pod,
you have to have nine v1 pods and one v2 pod.
Istio allows us to decouple this and shift traffic
from one version to another independently of the number
of replicas for either service.
Istio introduces a resource called a virtual service, which
allows me to do that.
To deploy a virtual service, I specify
how much traffic I want to go to each service
and the virtual service resource will ensure these proportions
are honored irrespective of how many pods of each service
is actually present.
So taking a look here, I have a virtual service defined
that is configured to send 100% of traffic
to my v1 pod and none to the v2 service.
Now, we can deploy this configuration
and actually test that this is the case.
And when I switch to my application,
I can see that no matter how many times I refresh, I always
get served the blue button.
That's my v1 service.
Now if I go back to my configuration,
I can switch this.
I can route 90% of my traffic to my v1 service
and 10% of the traffic to the v2 service.
And if I deploy this again, we should see a predictable
result. Roughly 10% of requests will get served a green button,
and the rest-- the 90%--
will get served a blue button.
Taking this further, I can switch the weights to 50/50--
so 50% of traffic to the v1 service,
50% of traffic to the v2 service--
and deploy this change.
And if I go back to the application,
I should see roughly every other time,
the button is either blue or green.
And then finally, I can route 100% of my traffic
to the v2 service and 0% of traffic to the v1 service.
Apply that change, and if I go back to my application,
I should always get served the green button.
And going back to our deployments
just to verify that the ratios are still the same,
we should still see only one v2 pod and four v1 pods.
So using Istio, you really get a deep level of control
over how your traffic is routed across your microservices.
Hey, Mr. Kubernetes.
You're looking a little better.
ELIAS PINTO: Thank you, Jonathan,
so much for showing me Istio.
I now spend my day making sure my services are up
and I don't have to play traffic cop anymore.
JONATHAN KOLA: That's right.
Using Istio gives you a lot of control over the traffic
with a lot more ease.
ELIAS PINTO: Exactly.
Don't forget to like, comment, and subscribe.
And if you're working on a cool project
and would like to get in contact with us,
please click on the link in the description.
Thanks for watching.
[MUSIC PLAYING]