[Cross posted from the OpenShift blog]
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:
- learn.openshift.com: A 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 the 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 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 mechanics that run 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. The 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 Red Hat OpenShift Application Runtimes (RHOAR), which is 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:
Security Scenario
In a microservices 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 being controlled independently by constituent applications.
We 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 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 on 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.
Routing Scenario
As the number of services that participate in a microservices architecture increases, the likelihood 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 scenario.
Circuit Breaking Scenario
Modern cloud applications often consist of many smaller services that 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 alternate business functions when appropriate.
This scenario showcases how Istio can be used to implement the Circuit Breaker architectural pattern. Deploying an application in an Istio service mesh allows for some cross-cutting, application-wide concerns for protecting some of the services that comprise the application to be moved outside of the application itself. This scenario demonstrates 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 that 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
Run 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:
http://launcher-frontend-devex.127.0.0.1.nip.io/launch/filtered-wizard/all
The OpenShift Web Console for your local cluster will be available on
http://127.0.0.1:8443.
You can find more details in the documentation for user journeys here. We would love to get your feedback on this work, which you can provide via comments on this blog or by creating issues on GitHub.
Last updated: February 24, 2024