I’m currently writing the book, Istio in Action for Manning Publications and the goal of the book is to help people understand and get the most benefit from Istio, which is an open-source service mesh. I am trying to bring together my learnings and experience from the community, as well as those of others who have embarked on their service-mesh adoption journey, to the rest of the service-mesh community.

An interesting observation that seems to be true among those successfully adopting Istio, regardless of organization, is that they tend to focus on solving a specific and focused set of problems before moving on to broader problems. In other words, they tend to adopt Istio incrementally and show value for a specific problem instead of going all-in and adopting everything Istio can do.

For example, an organization may have a requirement to encrypt traffic between an ingress gateway and an end service. Or, they may have a more pressing metric-collection and tracing effort underway. Adopting Istio incrementally can bring a lot of value to these use cases without getting bogged down in complexity and bringing a whole host of stakeholders to a process that may drag out for months if not years.

Getting started with a Service Mesh

At this point, if you’re looking to quickly get started with any service mesh ( Istio, Linkerd, AWS AppMesh, etc), you should check out an open-source project from Solo.io called SuperGloo. With SuperGloo, you can quickly bootstrap a mesh with a unified set of commands and explore and compare/contrast them as needed. A wonderful example of doing this is Shopify’s recent Istio vs Linkerd perf benchmarking writeup, facilitated with SuperGloo. For example, to install Istio with SuperGloo:

$ supergloo install istio --name istio

Or to install Linkerd:

$ supergloo install linkerd --name linkerd

Incremental Istio

To incrementally adopt Istio, we can use the following pre-defined Istio profiles. For example, to get started with a basic, minimal, install of Istio, run the following:

$ kubectl create ns istio-system

$ kubectl apply -f kubectl apply -f \

https://raw.githubusercontent.com/istioinaction/book-source-code/update-to-latest-istio/istio-1.1/install/10-istio-minimal.yaml

This minimal install will install only two components:

$ kubectl get pod -n istio-system NAME READY STATUS RESTARTS istio-ingressgateway-744b97db5b-wd55k 1/1 Running 0 istio-pilot-6f58c66f4d-9bsbd 1/1 Running 0

With just these two components, you can create a service mesh that collects important network metrics (requests/second, latency, error rate, etc), adds resilience like retries, timeouts, and circuit breakers, as well as gives you request-level control for traffic shaping. You can use the istioctl CLI to inject the appropriate sidecar proxies which form the mesh's data plane. For example, to bootstrap the hello-world sample from Istio

$ kubectl apply -f <(istioctl kube-inject -f \

samples/helloworld/helloworld.yaml)

With just these two Istio components, you get a lot of features out of the box.

When you’re ready, you can adopt a “medium” profile of Istio. For example, with the following profile, we can introduce the Istio Citadel for security:

$ kubectl apply -f \

https://raw.githubusercontent.com/istioinaction/book-source-code/update-to-latest-istio/istio-1.1/install/40-istio-medium.yaml

In this installation, you see we’ve added two new components: the Istio Citadel and the Istio sidecar injector.

$ kubectl get pod -n istio-system NAME READY STATUS RESTARTS istio-citadel-5589dfdf7b-k6jhl 1/1 Running 0 istio-ingressgateway-744b97db5b-wd55k 1/1 Running 0 istio-pilot-59f5795597-pdzqt 2/2 Running 0 istio-sidecar-injector-6f6f78645f-snpgn 1/1 Running 0

You can now take advantage of automatic sidecar injection, JWT validation, and transparent mTLS. With a slim control plane like this, we can take advantage of the features we need without getting mired in complexity.

Integrate Istio with your Environment

At this point you have a slim Istio control plane, and you may want to integrate (or gloo?) your real environment to an Istio service mesh. For example, you may want to integrate with your install of Prometheus (an example Prometheus comes out of the box with Istio, but you’ll have to reverse engineer its configuration to get the Job settings correct). At this point, we can leverage SuperGloo to help “gloo” our environment. For example, if we want to configure our own Prometheus server named prometheus-server living in prometheus-test namespace, we can leverage SuperGloo like this:

$ supergloo set mesh stats\

--target-mesh supergloo-system.istio \

--prometheus-configmap prometheus-test.prometheus-server

This will set up the correct Jobs in the Prometheus configmap to scrape your Istio’s data plane and control plane. No more trying to dig around for the correct configuration to set up your scrape Jobs for an Istio installation.

Another fairly common integration with Istio is to set up your own Root CA which Istio can use to sign the certificates it disseminates to sidecar proxies to establish mTLS. With SuperGloo, you can run the following command to automatically do that:

$ supergloo set mesh rootcert \

--target-mesh supergloo-system.istio \

--tls-secret supergloo-system.my-root-ca

Even if you didn’t use SuperGloo to install your Istio, SuperGloo can automatically discover an Istio installation and “do the right thing”. To install SuperGloo and get started with its tooling to simplifying integrating Istio with your environment ( like configuring your Prometheus servers), check out the SuperGloo docs.

For the Istio in Action book, I’m working on a set of profiles to use for adopting Istio. You can see the rest of them on GitHub. To generate them yourself, you can tweak these different settings in the stock Istio Helm charts:

helm template $ISTIO_RELEASE/install/kubernetes/helm/istio \

--name istio \

--namespace istio-system \

--set gateways.enabled=true \

--set security.enabled=false \

--set global.mtls.enabled=false \

--set galley.enabled=false \

--set global.useMCP=false \

--set sidecarInjectorWebhook.enabled=false \

--set mixer.enabled=false \

--set mixer.policy.enabled=false \

--set mixer.telemetry.enabled=false \

--set prometheus.enabled=false \

--set grafana.enabled=false \

--set tracing.enabled=false \

--set kiali.enabled=false \

--set pilot.sidecar=false

Follow up

In the next blogs, we’ll see how to adopt other service meshes in a similar fashion, such as Linkerd and AWS App Mesh. To learn more about Solo.io, visit our website or email Contact@solo.io with questions.