Istio Service Mesh: Core Concepts
Key Points
- Service meshes like Istio provide mutual TLS, dynamic traffic routing (e.g., canary releases), retries, circuit breaking, and fine‑grained access control, removing the need to embed these capabilities in application code.
- Istio injects an Envoy sidecar proxy next to each container in a Kubernetes pod, intercepting all inbound and outbound traffic to enforce policies and route requests.
- Configuration is expressed as Kubernetes CRDs (YAML) that Galley validates and Pilot translates into Envoy configurations, automatically distributing them to the sidecar proxies.
- By moving networking intelligence to the mesh, developers keep microservices small and business‑focused while gaining end‑to‑end observability, security, and flexible traffic management.
Sections
- Why Use an Istio Service Mesh - Ram Vennam outlines the key benefits of adopting a service mesh—mutual TLS security, dynamic traffic routing, resilience features, observability, and fine‑grained access control—using a UI‑to‑catalog‑to‑inventory example deployed on Kubernetes.
- Istio Architecture: Proxies, Citadel, and Resources - The passage outlines Istio’s proxy‑based policy, telemetry, and Citadel identity services, and introduces the three primary configuration objects—Gateway, VirtualService, and DestinationRule—used to route and manage traffic.
Full Transcript
# Istio Service Mesh: Core Concepts **Source:** [https://www.youtube.com/watch?v=6zDrLvpfCK4](https://www.youtube.com/watch?v=6zDrLvpfCK4) **Duration:** 00:05:07 ## Summary - Service meshes like Istio provide mutual TLS, dynamic traffic routing (e.g., canary releases), retries, circuit breaking, and fine‑grained access control, removing the need to embed these capabilities in application code. - Istio injects an Envoy sidecar proxy next to each container in a Kubernetes pod, intercepting all inbound and outbound traffic to enforce policies and route requests. - Configuration is expressed as Kubernetes CRDs (YAML) that Galley validates and Pilot translates into Envoy configurations, automatically distributing them to the sidecar proxies. - By moving networking intelligence to the mesh, developers keep microservices small and business‑focused while gaining end‑to‑end observability, security, and flexible traffic management. ## Sections - [00:00:00](https://www.youtube.com/watch?v=6zDrLvpfCK4&t=0s) **Why Use an Istio Service Mesh** - Ram Vennam outlines the key benefits of adopting a service mesh—mutual TLS security, dynamic traffic routing, resilience features, observability, and fine‑grained access control—using a UI‑to‑catalog‑to‑inventory example deployed on Kubernetes. - [00:03:07](https://www.youtube.com/watch?v=6zDrLvpfCK4&t=187s) **Istio Architecture: Proxies, Citadel, and Resources** - The passage outlines Istio’s proxy‑based policy, telemetry, and Citadel identity services, and introduces the three primary configuration objects—Gateway, VirtualService, and DestinationRule—used to route and manage traffic. ## Full Transcript
Hi I'm Ram Vennam, I'm from the IBM Cloud team
and today I want to talk to you about
why you might want to use a service mesh,
how the Istio service mesh works,
and some core concepts for you to get started quickly.
Let's use this example application:
I have a UI microservice
talking to two versions of catalog,
which talk to inventory.
All of these are services deployed inside of a Kubernetes cluster.
The number one reason why someone uses a service mesh
is because they want to secure their workload.
So, they want mutual TLS ("Transport Layer Security")
when one service is talking to another.
Next, they want to dynamically configure
how the services are connected to one another.
In this example there's version 1 and version 2.
So, I might want to send 90% of the traffic to version 1,
and then 10% of the traffic to version 2,
while I do testing and incremental rollouts.
I might also want to try
adding retry policies and circuit braking to harden my system.
Three, I want to observe how my application is doing end-to-end
- not just if a service is up or down
- but see where the bottlenecks are in the system
and how traffic is flowing.
And four, I want to control
who has access to talk to what.
In this example, UI is allowed to talk to catalog,
and catalog is allowed to talk to inventory.
But UI is not allowed to talk to inventory directly,
and rogue containers cannot talk to inventory service.
You can get more granular than that,
and say that UI is allowed to make an HTTP Git request,
and catalog is allowed to make a post request to inventory.
In the past, we used to have our developers
program all of these features directly into their application code.
That slowed down the dev cycle,
it made these microservices bigger,
and just generally made everything less flexible.
But now there's a better way,
and that's the service mesh.
You keep your application small and business-focused,
and instead, you dynamically program the intelligence into the network
- and that's exactly what Istio does.
So, when you have Istio installed,
the first thing it will do is automatically inject proxies
next to each one of your containers.
These proxies are Envoy proxies,
and the proxy itself runs in a container
next to your application container,
but it runs inside the same Kubernetes pod.
Now when UI wants to talk to catalog,
the proxy will actually intercept that request,
apply any policies,
and then route traffic to the proxy on the other side,
and then the catalog proxy will receive that request and then forward it down to the catalog.
Istio will configure each one of these proxies
with your desired configuration.
Istio extends Kubernetes using CRDs.
So, to apply an Istio configuration you just write your YAML,
and then apply it to Kubernetes.
The Istio Galley component will receive that YAML,
validate it, and then hand it over to Istio Pilot.
Pilot will convert that configuration
to envoy configuration,
and distribute it to each one of the proxies.
If you want the proxies to add additional policies and roles,
there is a policy component,
and then these proxies constantly report telemetry information about what's going
on in your system to the Istio telemetry component.
And last, but not least, there is Citadel.
Citadel is responsible for providing strong identity
to each one of the services in your system.
It also generates certificates
and rolls it out to each one of the proxies,
so that the proxies can do mutual TLS when they're talking to one another.
To get started with Istio
and to configure Istio,
there are 3 main resources that you need to learn about.
First there's a gateway.
Gateway is like a load balancer
that sits at the edge of your mesh,
and accepts incoming and outgoing HTTP and TCP connections.
Next, to direct traffic from Gateway to your services,
you create a virtual service.
A virtual service can be bound to a gateway and direct traffic to UI,
or it could be bound to a service and then direct traffic to your other services
where you can apply policies like 90% and 10% traffic split rules.
Once traffic is routed,
you can apply rules on top of that traffic,
such as TLS settings or circuit braking,
and those are done using destination rules.
And those are the 3 main resources you need to know about Istio.
I'm actually going to put "policy" and "telemetry" in asterisks
because there's some refactoring that's going on with these components.
The logic is being moved outside of this control plane
and into the proxies themselves
to avoid the additional network hop.
This translates to improved performance.
Thanks for watching this video.
If you want to see more videos like this
leave a comment below
and please "like" and subscribe.