Difficulty: advanced
Estimated Time: 60 minutes

As we transition our applications towards a distributed architecture with microservices deployed across a distributed network, many new challenges await us.

Technologies like containers and container orchestration platforms like OpenShift solve the deployment of our distributed applications quite well, but are still catching up to addressing the service communication necessary to fully take advantage of distributed applications, such as dealing with:

  • Unpredictable failure modes
  • Verifying end-to-end application correctness
  • Unexpected system degradation
  • Continuous topology changes
  • The use of elastic/ephemeral/transient resources

Today, developers are responsible for taking into account these challenges, and do things like:

  • Circuit breaking and Bulkheading (e.g. with Netflix Hystrix)
  • Timeouts/retries
  • Service discovery (e.g. with Eureka)
  • Client-side load balancing (e.g. with Netflix Ribbon)

Another challenge is each runtime and language addresses these with different libraries and frameworks, and in some cases there may be no implementation of a particular library for your chosen language or runtime.

In this scenario we'll explore how to use a new project called Istio to solve many of these challenges and result in a much more robust, reliable, and resilient application in the face of the new world of dynamic distributed applications.

What is Istio?


Istio is an open, platform-independent service mesh designed to manage communications between microservices and applications in a transparent way.It provides behavioral insights and operational control over the service mesh as a whole. It provides a number of key capabilities uniformly across a network of services:

  • Traffic Management - Control the flow of traffic and API calls between services, make calls more reliable, and make the network more robust in the face of adverse conditions.

  • Observability - Gain understanding of the dependencies between services and the nature and flow of traffic between them, providing the ability to quickly identify issues.

  • Policy Enforcement - Apply organizational policy to the interaction between services, ensure access policies are enforced and resources are fairly distributed among consumers. Policy changes are made by configuring the mesh, not by changing application code.

  • Service Identity and Security - Provide services in the mesh with a verifiable identity and provide the ability to protect service traffic as it flows over networks of varying degrees of trustability.

These capabilities greatly decrease the coupling between application code, the underlying platform, and policy. This decreased coupling not only makes services easier to implement, but also makes it simpler for operators to move application deployments between environments or to new policy schemes. Applications become inherently more portable as a result.

Sounds fun, right? Let's get started!

In this scenario you used Istio to implement many of the Istio provides an easy way to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, without requiring any changes in service code. You add Istio support to services by deploying a special sidecar proxy throughout your environment that intercepts all network communication between microservices, configured and managed using Istio’s control plane functionality.

Technologies like containers and container orchestration platforms like OpenShift solve the deployment of our distributed applications quite well, but are still catching up to addressing the service communication necessary to fully take advantage of distributed microservice applications. With Istio you can solve many of these issues outside of your business logic, freeing you as a developer from concerns that belong in the infrastructure. Congratulations!

Additional Resources:

Resilient Apps

Step 1 of 9

Install Istio

In this step, we'll install Istio into our OpenShift platform.

In order to install Istio, you must be logged in as admin. This is required as this user will need to run things in a privileged way, or even with containers as root.

To login as the admin user, run the following (click to execute it automatically):

oc login [[HOST_SUBDOMAIN]]-8443-[[KATACODA_HOST]].environments.katacoda.com -u admin -p admin --insecure-skip-tls-verify=true

WARNING: If you are unable to login as admin or get any failures in the above command, you'll need to reload and try again!

Next, run the following command to install Istio:


This command:

  • Creates the project istio-system as the location to deploy all the components
  • Adds necessary permissions
  • Deploys Istio components
  • Deploys additional add-ons, namely Prometheus, Grafana, Service Graph and Jaeger Tracing
  • Exposes routes for those add-ons and for Istio's Ingress component

We'll use the above components througout this scenario, so don't worry if you don't know what they do!

Istio consists of a number of components, and you should wait for it to be completely initialized before continuing. Execute the following commands to wait for the deployment to complete and result deployment xxxxxx successfully rolled out for each deployment:

TIP: If this command times out, simply click to run it again until it reports success!

oc rollout status -w deployment/istio-pilot && \ oc rollout status -w deployment/istio-mixer && \ oc rollout status -w deployment/istio-ca && \ oc rollout status -w deployment/istio-ingress && \ oc rollout status -w deployment/prometheus && \ oc rollout status -w deployment/grafana && \ oc rollout status -w deployment/servicegraph && \ oc rollout status -w deployment/jaeger-deployment

While you wait for the command to report success you can read a bit more about the Istio architecture below:

Istio Details

An Istio service mesh is logically split into a data plane and a control plane.

The data plane is composed of a set of intelligent proxies (Envoy proxies) deployed as sidecars to your application's pods in OpenShift that mediate and control all network communication between microservices.

The control plane is responsible for managing and configuring proxies to route traffic, as well as enforcing policies at runtime.

The following diagram shows the different components that make up each plane:

Istio Arch

Istio Components


Envoy is a high-performance proxy developed in C++ which handles all inbound and outbound traffic for all services in the service mesh. Istio leverages Envoy’s many built-in features such as dynamic service discovery, load balancing, TLS termination, HTTP/2 & gRPC proxying, circuit breakers, health checks, staged rollouts with %-based traffic split, fault injection, and rich metrics.

Envoy is deployed as a sidecar to application services in the same Kubernetes pod. This allows Istio to extract a wealth of signals about traffic behavior as attributes, which in turn it can use in Mixer to enforce policy decisions, and be sent to monitoring systems to provide information about the behavior of the entire mesh.


Mixer is a platform-independent component responsible for enforcing access control and usage policies across the service mesh and collecting telemetry data from the Envoy proxy and other services. The proxy extracts request level attributes, which are sent to Mixer for evaluation.


Pilot provides service discovery for the Envoy sidecars, traffic management capabilities for intelligent routing (e.g., A/B tests, canary deployments, etc.), and resiliency (timeouts, retries, circuit breakers, etc.). It converts a high level routing rules that control traffic behavior into Envoy-specific configurations, and propagates them to the sidecars at runtime. Pilot abstracts platform-specifc service discovery mechanisms and synthesizes them into a standard format consumable by any sidecar that conforms to the Envoy data plane APIs.


Istio-Auth provides strong service-to-service and end-user authentication using mutual TLS, with built-in identity and credential management. It can be used to upgrade unencrypted traffic in the service mesh, and provides operators the ability to enforce policy based on service identity rather than network controls.


Several components are used to provide additional visualizations, metrics, and tracing functions:

  • Prometheus - Systems monitoring and alerting toolkit
  • Grafana - Allows you to query, visualize, alert on and understand your metrics
  • Jaeger Tracing - Distributed tracing to gather timing data needed to troubleshoot latency problems in microservice architectures
  • Servicegraph - generates and visualizes a graph of services within a mesh

We will use these in future steps in this scenario!

Check out the Istio docs for more details.

Is your Istio deployment complete? If so, then you're ready to move on!