Ultimate Istio Bootcamp by School of Devops®

See how Istio lets you roll out a new version to a small slice of users before it reaches everyone, the same idea as the canary in a coal mine. You'll learn how the Envoy proxy and the Pilot control plane route traffic by request headers, user, agent, or region, so you can run canary deployments and staged rollouts without touching your application code.

Using Flipkart's Big Billion Day outage as a real example, you'll learn how Istio keeps a service mesh working when one service fails. Walk away knowing how to add timeouts, retries, circuit breakers, and health-based load balancing at the infrastructure level, so a single slow or dead service doesn't take your whole site down, and none of it requires changing your application.

Like Netflix's Chaos Monkey, but built into your mesh: you'll learn how Istio's fault injection deliberately adds delays and errors between services so you can see how your application behaves under real-world trouble. Walk away able to inject faults through the Envoy proxy and Pilot to test resilience and confirm your services fail gracefully instead of cascading.

Learn how Istio's traffic mirroring copies your live production traffic to a new version running in staging, without your users ever noticing. You'll understand how to test a release against real production load and behaviour before you send any actual users to it, so you catch problems while the new version is still safely on the side.

Application-level troubleshooting is one of the hardest parts of ops, and this lecture shows how Istio makes it easier. You'll learn how distributed tracing with Jaeger, metrics collected by Envoy, and the mixer's adapters for Prometheus and Grafana let you pinpoint exactly which service added latency, so you can zoom straight to the problem instead of guessing across the whole request path.

Get a clear map of how Istio is put together. You'll learn how the Envoy sidecar proxy is injected into your pods to hijack traffic, and what each control plane component does: Mixer for policy and telemetry, Pilot for traffic routing rules, Citadel for security and mutual TLS, and Galley for configuration. This gives you the mental model to understand every feature that follows.

Here's what this Kubernetes section covers. You'll set up a cluster on Google Compute Engine, deploy a Node.js application, and get hands-on with deployments, services, pods, and service discovery. You'll also scale your app manually and with autoscaling, run a zero-downtime deployment, and get a quick look at kubectl, so you have the fundamentals you need before moving on.

Working from a real e-commerce microservices stack, you'll understand why Docker and Docker Compose stop being enough once you go beyond a single machine. Learn how Kubernetes turns a group of servers into one cluster and handles scheduling, deciding which container runs on which node based on resource needs and availability, plus scaling and load balancing out of the box. You'll walk away clear on what container orchestration actually solves.

Follow along to spin up a Kubernetes cluster on Google Cloud in about five minutes using Google Kubernetes Engine. You'll sign up for the free credit, create a managed cluster through the GKE console, and learn how to read the node pool, endpoints, and system services Google provisions for you, so you have a working multi-node cluster ready to deploy applications onto.

Take a ready container image and deploy the frontend service on your GKE cluster straight from the Google Cloud console. You will create a deployment that runs three replicas for high availability, then expose it to the world with a LoadBalancer service that maps port 80 to the container's port. By the end you can deploy a workload and reach it over a public IP, and you will see the YAML that Google generated behind the form.

Look behind the deployment you just created and understand what Kubernetes builds for you. You will see how a deployment keeps the desired number of replicas through a ReplicaSet, how the HorizontalPodAutoscaler scales pods up and down on CPU, and how labels and selectors let the controller heal pods when a node fails. You will also learn the rolling update and recreate strategies so you can upgrade from one version to another with or without downtime.

Understand the Kubernetes Service and why you need one to reach your pods. You will see how a service uses labels and selectors to pick pods and load balance traffic across them, and how a LoadBalancer type gives you an external IP while a ClusterIP stays internal. You will also compare NodePort, LoadBalancer, and Ingress so you can pick the right way to expose an app on cloud or on-prem, and set up service-to-service communication over internal DNS.

Learn why Kubernetes runs your containers inside pods instead of on their own. You will see why one container per image is the norm, and how a pod lets co-located containers share the same network namespace, hostname, and volumes while keeping separate filesystems and process IDs. By the end you can read a pod spec's apiVersion, kind, metadata, and spec, and explain how a pod maps to a single node as the basic unit of deployment.

Decide when a pod should hold more than one container using the sidecar, ambassador, and adapter patterns. You will work through the simple test for it: if the two containers could run on different nodes, keep them in separate pods; if they must share a volume, network, or lifecycle, put them together. Real examples include a git-sync sidecar, an ambassador proxy in front of shards, a log adapter feeding a monitoring system, and a service mesh proxy running in every pod.

Connect one app to another using Kubernetes internal service discovery instead of hardcoded pod IPs. You will deploy a catalog app and its MySQL database, expose both with ClusterIP services, and watch the frontend reach them just by their service name over DNS. You will see why the service name must match exactly, how environment variables configure the database container, and how the built-in DNS server keeps discovery working as pods come and go.

Put your deployment and service skills to work by adding the carts app and its database to the running sock shop stack. Your job is to create the deployment, expose it with a ClusterIP service named so the frontend can find it over DNS, and map service port 80 to the container's target port. You will know it works when the shopping cart button shows up in the top right corner of the app, and a solution video follows if you get stuck.

Walk through the full solution for deploying the carts application and wiring it into the stack. You will create the workload from the carts image, then add a ClusterIP service named carts on port 80 mapped to the container's target port so the frontend can discover it by name. Once the pods are running you validate the deploy by refreshing the app and seeing the shopping cart appear, confirming service discovery and high availability are working end to end.

Scale your Kubernetes apps two ways: by hand and automatically. You will edit a deployment's replica count to scale manually and watch pods spread across nodes, then let the HorizontalPodAutoscaler add and remove pods against a CPU threshold. Using a siege-based load generator container you will drive real traffic, tune the concurrent users and threshold until autoscaling triggers, and see pods scale out under load and scale back in once the load drops.

Upgrade an app from one version to the next without taking it offline using a rolling update. You will scale the frontend to several replicas, set maxSurge and maxUnavailable with a delay between batches, then roll from one image version to another while a refreshing browser shows the app stays live the whole time. By the end you can configure a rolling update strategy for zero downtime deployments and watch old pods retire as new ones come up.

Start managing your GKE cluster from the command line with kubectl instead of the GCP console. You'll set up Cloud Shell, pull cluster credentials, and run the everyday commands: get and describe for nodes, deployments, pods and services, cluster-info for control plane health, and manual scaling with kubectl scale. By the end you can read your cluster's state and make quick changes straight from the CLI.

Stand up an Istio-enabled Kubernetes cluster on GKE using the Cloud Deployment Manager template. You'll cover the prerequisites first: a GCP account with free credit, enabling the Kubernetes Engine API, and granting your account the cluster admin IAM role. Then you launch the template, which brings up the control plane, the Istio service mesh add-ons like Grafana and Jaeger, and a sample app. You'll finish able to spin up a working Istio cluster with almost no manual setup.

Install and configure the Google Cloud SDK so you can manage your GKE clusters from your own laptop instead of Cloud Shell. You'll check the Python prerequisite, run the installer, add gcloud to your shell path, then authenticate and pick your default project and region with gcloud init. By the end you can run gcloud and kubectl locally and list your clusters to confirm everything works.

Confirm your Istio control plane is healthy after installation. You'll pull cluster credentials with gcloud, then use kubectl to check nodes and inspect the istio-system namespace where the pods, services, deployments and gateways live. You'll deploy and explore the Bookinfo sample app, reach it through the ingress load balancer, and generate some traffic with a loop so there's data to examine later. You walk away knowing your mesh is wired up correctly.

Check that Istio's telemetry add-ons are up and collecting data. You'll reach Grafana, Prometheus, the service graph and the Jaeger tracing UI using kubectl port-forward, and see the dashboards fill with metrics from the load you generated earlier. You'll also learn how to switch a service to type LoadBalancer on GKE for an external endpoint when port forwarding isn't convenient. By the end you can open each observability tool and read live mesh traffic.

Get to know the Bookinfo sample app you'll use for the rest of the course. It's a polyglot microservices app: a Python product page, a Ruby details service, a Java reviews service with three versions, and a Node ratings backend. You'll see why reviews has three versions for traffic routing demos, and how Istio injects an Envoy sidecar proxy into every pod. Use kubectl describe pod to spot the two containers and understand how the proxy takes over networking.

See what Istio adds by running it side by side with plain Kubernetes. You'll build a second clean GKE cluster, deploy Bookinfo on it without sidecars, and switch between the two clusters using kubectl config contexts. This sets up a direct comparison so you can watch how routing behaves with and without the mesh. You'll be comfortable juggling multiple cluster contexts and ready to test canary routing against a baseline.

Do a live side-by-side test of intelligent routing on Istio versus plain Kubernetes. On Kubernetes a service selector can only round-robin across all reviews versions, so you can't send one specific user somewhere different. With Istio you apply a VirtualService and DestinationRule to match a request header and route user 'jason' to v2 while everyone else stays on v1. You'll finish able to write header-based routing rules for real canary testing in production.

Inject a fault into the mesh to test how your app holds up under failure. You'll add a seven-second delay between the reviews and ratings services, but only for requests from user 'jason', so the rest of your live traffic stays untouched. Logging in as that user, you'll watch the timeout surface a resiliency bug in reviews v2 while other users see no errors. You learn to run safe, targeted fault injection for resilience testing in production.

Compare traffic shifting on Istio against Kubernetes to see why routing and capacity should be separate. On Kubernetes a 60/40 split forces you to scale pod replicas to match, tying traffic to capacity. With Istio you just edit the VirtualService weights, so v1 can take 60% of traffic on 80% of the capacity. You'll shift traffic gradually to a fixed v3 and finish a full rollout with zero downtime, all decoupled from how many pods are running.

Tear down the lab so you stop paying for idle clusters. You'll delete both GKE clusters from the Google Cloud console and clean stale entries out of your local kubeconfig with kubectl config delete-context. The same idea applies if you built the cluster yourself: delete the resources with kubectl delete on the YAML files you applied. You end back at a clean slate.

Build a multi-node Kubernetes cluster from scratch with kubeadm on Ubuntu servers. You'll run kubeadm init on the master with an advertise address, join worker nodes with the token, set up kubectl and the admin config, and install a CNI plugin so pods can talk across nodes. You'll also deploy the Kubernetes dashboard and copy the kubeconfig to your laptop so you can drive the cluster remotely. By the end you have a working cluster ready for Istio.

Install the Istio control plane on your Kubernetes cluster. You'll download istioctl and add it to your PATH, apply the custom resource definitions, then install Istio with kubectl (with or without Helm). You'll verify the pods and services in the istio-system namespace and get real practice debugging a stuck Pilot pod by editing its memory resource requests. Covers the full istioctl setup plus the components Istio runs internally.

Deploy the Bookinfo sample app, the microservices demo you'll use for the rest of the course. You'll create a namespace, enable Istio sidecar injection with the istio-injection=enabled label, and apply the Bookinfo manifest so each pod comes up with its Envoy proxy alongside the app. You'll see how product page, details, reviews, and ratings connect, why reviews has three versions behind one service, and how to confirm the sidecars were injected.

Understand how traffic enters and leaves an Istio mesh before you configure it. You'll see how the ingress gateway pairs with a Gateway resource and a VirtualService to route outside requests to internal services, and why the VirtualService (not the gateway) holds the routing rules. On the outbound side you'll learn why the mesh blocks external calls by default and how the egress gateway plus a ServiceEntry open a controlled path out. Sets up the hands-on ingress and egress lessons that follow.

Expose the Bookinfo app to the outside world using an Istio Gateway and VirtualService. You'll apply the gateway manifest, inspect it with kubectl describe, and set the ingress host and port. Without a cloud load balancer you'll reach the app through a NodePort and one of your node IPs instead. You'll also deploy the httpbin sample and hit it with curl to test host- and path-based routing, seeing where a first attempt fails before the fix in the next lecture.

Let a service inside the mesh reach external endpoints by adding a ServiceEntry. You'll deploy a sleep pod, exec into it to test egress, and see that outbound calls to google.com are blocked by default while an already-configured host still works. You'll register external hosts on ports 80 and 443 with ServiceEntry and VirtualService, confirm access opens up, then add a timeout rule and watch a slow call return a 504. Controlled egress with Istio traffic policies.

See how services inside the mesh actually talk to each other through Envoy. You'll learn how Istio injects an Envoy sidecar into every pod and syncs it from Pilot, then use istioctl proxy-status to check that each proxy is in sync with the control plane. You'll diff a service's proxy config against Pilot and start reading Envoy listeners with istioctl proxy-config, discovering that port 15000 is where all the traffic gets funneled. Groundwork for the deeper Envoy dive next.

Look under the hood at how Envoy quietly captures every packet a service sends. You'll go to the node running the product page pod, use the nicolaka/netshoot container joined to the app container's network namespace, and inspect the iptables rules that redirect all TCP traffic to Envoy's port 15000. You'll come away understanding exactly how Istio's transparent sidecar interception works, without the app knowing anything about it.

Follow a single request from productpage to reviews and watch how Pilot programs Envoy to route it. You will use istioctl proxy-config to read listeners, routes, and clusters, see how each sidecar builds a listener per destination, and understand the black hole cluster for unmatched traffic. By the end you can trace service-to-service paths and read Envoy config to see exactly where traffic goes.

See why resilience matters through a real e-commerce example, then learn the three Istio features that keep services standing when things go wrong: timeouts, retries, and circuit breakers. You will understand how each one stops a slow or failing downstream service from dragging down the whole app, and why Istio lets you add fault tolerance at the mesh level without touching your application code.

Set a request timeout on a virtual service and watch it in action against a slow backend. You will inject a fixed delay into the ratings service, drop the reviews timeout below that delay, and see the call return gracefully instead of hanging. By the end you can configure timeouts to stop latency from cascading and keep a slow service from freezing the page.

Configure a circuit breaker in a destination rule using connection pool limits and outlier detection, then trip it on purpose. You will run load from inside the cluster with fortio, push past the max-connections threshold, and read the overflow counts that show requests being shed. By the end you can protect an overloaded upstream service and understand the small buffer Envoy allows before it trips.

Send 100% of live production traffic to v1 while shadowing a copy to v2, so you can test a new version against real requests without affecting users. You will set up two deployments, weight routing to v1, then add the mirror block to the virtual service and confirm both versions receive traffic in their logs. By the end you can use traffic mirroring to validate a release safely in a staging-like setup.

Wire up Istio telemetry by defining instances, handlers, and rules to collect a custom request-count metric and structured log entries. You will apply the YAML, send the metric to the Prometheus handler and the logs to stdout, then verify both are flowing. By the end you understand how Istio's mixer model maps generated data to handlers and can generate your own metrics and logs from mesh traffic.

Open the Prometheus UI through a port-forward and slice your mesh metrics with PromQL. You will query istio_request_total, then narrow results by fields like destination_service and destination_version to focus on a single service or a specific version of reviews. By the end you can filter and read the metrics Istio collects automatically and pull out exactly the service data you need.

Use Jaeger to follow a request as it hops across microservices and see where time is spent. You will read traces and spans for the Bookinfo app, drill into a single trace to spot latency and intermittent failures in reviews, and learn which tracing headers your app must forward for spans to connect. By the end you can use distributed tracing to debug latency and errors across a service mesh.

Explore the Grafana dashboards Istio ships with out of the box, backed by Prometheus as a data source. You will port-forward to Grafana, watch global request volume and success rate update with live traffic, then inject a 500 fault for a specific user and see the client success rate drop on the service dashboard. By the end you can monitor mesh health, read per-service graphs, and set alerts on request rates and errors.