About a year ago Red Hat announced its participation as a launch partner of the Istio project, a service mesh technology that creates an application focused network that transparently protects the applications from abnormalities in environments. The main goals of Istio are enhancing overall application security and availability through many different capabilities such as intelligent routing, circuit breaking, mutual TLS, rating and limiting among others. Ultimately Istio is about helping organizations develop and deploy resilient, secure applications and services using advanced design and deployment patterns that are baked into the platform.
As part of our investments in making the technology easily consumable to Kubernetes and OpenShift users, Red Hat has created a ton of content, please see some examples below:
- learn.openshift.com – web based OpenShift and Kubernetes learning environment where users get to interact through the web-browser with a real running instance of OpenShift and Istio service mesh with zero install time and no sign-up required.
- Istio Tutorial – want to try the web based scenario yourself from scratch? This git repo contains instructions on how to set up an environment for yourself.
- Introducing Istio Service Mesh for Microservices book by Christian Posta and Burr Sutter
- Blog posts on OpenShift and Red Hat Developer blogs
What We Are Making Available Now
The above-mentioned resources have already helped many OpenShift users to ramp up on their understanding of Istio and Jaeger, and now we are introducing the
istiooc command-line tool and a set of pre-built Istio and Jaeger example scenarios that would make it even easier to get started with these technologies.
Through the modified OpenShift command line tool –
istiooc – you can spin up a local single-node OpenShift cluster on your laptop and have access to pre-built scenarios that teach you about Istio and Jaeger. The mechanics behind this work is the same that runs the popular Launcher to provide a hassle-free way of creating functional Istio and Jaeger example applications.
By using a set of Ansible scripts that run as Kube jobs we have made using Istio and Jaeger on OpenShift much easier, and because we’re Red Hat, everything covered here is naturally open source and available on GitHub.
You can download the
istiooc command-line too from the GitHub release page.
Understanding Istio and Jaeger – Pre-Built Scenarios
In order to make it easier to explore some of the key Istio and Jaeger capabilities we have built example scenarios, which we call missions, that are available through the Launcher. Launcher is already deployed when you spin up your local OpenShift cluster with
istiooc and it provides you with example scenarios that combine Istio and Jaeger functionality with technologies such as Spring Boot and Wildfly Swarm. Spring Boot and WildFly Swarm are part of the Red Hat OpenShift Application Runtimes (RHOAR) which are a set of cloud-native runtimes optimized for OpenShift. You can read more about the latest release of RHOAR in this blog post.
Once you execute any of the Launcher scenarios, the following will be created and made available:
- A GitHub repository with the example scenario you want to run and optionally modify
- OpenShift application definitions for the scenario
- The example Istio scenario deploying and running on OpenShift
- An OpenShift route that will allow you to try and learn the scenario
- Instructions on what to do next.
Let’s take a look at the individual scenarios and what each of them includes:
In a microservice topology, not all services are intended to be invoked by any user. In fact, opening access in this fashion may present potential security problems. It is therefore prudent to restrict invocations to known clients or dependent services.
This scenario showcases Istio security concepts whereby access to services is controlled by the platform rather than independently by constituent applications.
We’ll outline how to apply a security policy that allows clients to obtain a greeting from a Greeting Service while forbidding direct access to the underlying implementation. Further, we’ll explore different ways to change this policy on the fly.
Distributed Tracing Scenario
In a microservice topology, where an incoming HTTP call to the cluster / service-mesh could end up calling a host of other services, getting insights into the interactions of the individual services and performing debugging becomes complicated. Distributed tracing gives developers and operators the ability to gain insights on the potentially complex interactions between microservices by painting a picture of what they look like in a graph form.
This scenario showcases the interaction of Distributed Tracing capabilities of Jaeger and properly instrumented microservices running in the Service Mesh.
As the number of services that participate in microservices architecture increases, the likeliness that services will need to be independently upgraded and patched also increases. This results in parts of the system being unavailable unless traffic can be routed to alternate endpoints dynamically. Controlled rollout from a traffic perspective facilitates the introduction of new application versions and testing of new business functions.
This scenario showcases using Istio’s dynamic traffic routing capabilities with a set of example applications designed to simulate a real-world rollout scenarios scenario.
Circuit Breaking Scenario
Modern cloud applications are often comprised of many smaller services which interact with each other in a many-to-many manner. Understanding when a service is failing or unavailable is critically important. Increased application resiliency can be achieved by avoiding unnecessary calls to unresponsive services or by re-routing traffic to alternative business functions when appropriate.
This scenario showcases how Istio can be used to implement the Circuit Breaker architectural pattern. Deploying the application in an Istio service mesh allows for some cross-cutting, application-wide concerns to protect some of the services that comprise the application, to be moved outside of the application itself. This will demonstrate this functionality by showing how the Istio circuit breaker can be activated using only configuration files, without modifying the application.
How to Try It
If you have access to a docker engine, running the
cluster up command makes it really easy to start a local single-node OpenShift cluster on your laptop. With the sensible defaults which are in place, you only need to specify your GitHub username and your personalized GitHub authentication token and you’re good to go:
$ istiooc cluster up --istio --launcher \ --launcher-github-username='YOUR-GITHUB-USERNAME' \ --launcher-github-token='YOUR-GITHUB-TOKEN'
The above command performs the following steps:
- Starts a single-node local OpenShift cluster
- Provisions Istio and Jaeger components on OpenShift
- Configures automatic sidecar injection for the Istio proxy
- Provisions a customized Launcher to make example scenarios available for use on OpenShift
istiooc cluster up --help to get a complete list of customization options and flags.
Once the OpenShift cluster is ready, try out the Istio and Jaeger example scenarios using Launcher:
The OpenShift Web Console for your local cluster will be available on: