If you’re implementing a Service Mesh in your Kubernetes environment, chances are it’s for the following:

1. Encryption for service-to-service communication.
2. The ability to see network traffic and performance.
3. Network resilience and scale (blue/green, circuit breakers, fault injection, retires, AB testing)

What Service Mesh you see in an environment will differ based on organization, but there’s a high likelihood that you’ll see Istio implemented. Even if Istio is not implemented in the environment you’re working in or going to work in, once you know one Service Mesh, you can confidently figure out the rest.

In this blog post, you’ll learn how to not only install Istio, but configure mTLS and ensure that the Istio Sidecar is injected into Pods.

Installation

The first step to getting started with a Service Mesh is the installation. There are two primary ways to install Istio:

1. Helm
2. The Istio CTL

From a production perspective, you’ll most likely see Istio installed with Helm as it allows you to manage installation, upgrades, and removal like any other package.

💡

Installing Istio does NOT mean Istio will work throughout your environment within each Pod. For Istio to send policies to Pods of your choosing, you need to enable the sidecar container. You’ll see a few different ways to do that in the sections after this section.

First, add the Istio repository.

helm repo add istio https://istio-release.storage.googleapis.com/charts

Next, install the Istio base configurations. The base configuration is a set of CRDs and are separate from the Istio installation itself.

helm install istio-base istio/base -n istio-system --create-namespace

Lastly, install the Istio workloads. You’ll see the Pod and Service in the istio-system Namespace once complete.

helm install istiod istio/istiod -n istio-system

Now that Istio is installed, let’s see a few different ways to ensure that the Istio Sidecar container is implemented in the Pods that need Istio.

💡

Without the Sidecar Container within a Pod, the Pod cannot receive any policies from Istio or utilize mTLS.

Namespace Injection

The first method of injecting the Istio Sidecar container is via a Namespace label. With the istio-injection Namespace Label, all Pods that are deployed after the Label is set will retrieve the Sidecar container.

Remember - Pods that are already deployed will not receive the Sidecar container. For example, if I have two Pods already running and then create the Istio Injection Label, the Pods won’t get the Istio Sidecar. You’ll have to remove the Pods and have them re-deploy via self-healing. Once they re-deploy, they’ll obtain the Istio Sidecar.

To add the Label, run the following:

kubectl label namespace default istio-injection=enabled --overwrite

You can check and confirm that the Label was added successfully.

kubectl get namespace -L istio-injection

If you want to remove the Label, run the following:

kubectl label namespaces default istio-injection-

Deployment YAML Injection

A good way to ensure that the Istio Sidecar is installed as soon as a Pod is deployed is by adding the inject label into the Kubernetes Manifest.

For example, the below Manifest has a label that is set to true for injecting the Istio sidecar.

kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginxdeployment
  replicas: 2
  template:
    metadata:
      labels:
        app: nginxdeployment
        sidecar.istio.io/inject: "true"
    spec:
      containers:
      - name: nginxdeployment
        image: nginx:latest
        ports:
        - containerPort: 80
EOF

istioctl Injection

If you already have a Deployment that’s running but want the Pods that are running to have an Istio Sidecar container, you can inject Istio via the Istio CLI.

First, install the CLI.

curl -L https://istio.io/downloadIstio | sh -

Next, use the following command to inject the Sidecar into the Deployment. For example, the Deployment that Istio is injecting the Sidecar into is from the nginx.yaml Deployment Manifest. You’ll need to change that name to whatever name your Kubernetes Manifest is.

istioctl kube-inject -f nginx.yaml | kubectl apply -f -

If you take a look at the Pods running within that Deployment, you’ll notice that the kube-inject command deletes the Pods that are currently running and new Pods come up with the Sidecar Container.

Enabling mTLS

In the previous sections, you learned how to install Istio and ensure that the Istio Sidecar exists so that the Pods you’re running can pull down policies from Istio.

However, by default, Istio does not enable mTLS for service-to-service encryption. To implement that level of encryption, you’ll need to use the PeerAuthentication object/resource via the Istio CRDs.

The below configuration adds mTLS to the default Namespace as it’s not specifying a Namespace.

kubectl apply -n default -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: "default"
spec:
  mtls:
    mode: STRICT
EOF

Istio Dashboard

By default, Istio doesn’t come with a way to view any Kubernetes resources that are using Istio via a GUI. If you want to use a GUI, you can use Kiali.

To install Kiali, run the following:

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.15/samples/addons/kiali.yaml

The Kiali Dashboard Service will be deployed under the istio-system Namespace.

To access the Kiali dashboard, run the following:

kubectl port-forward -n istio-system svc/kiali 8080:20001

You’ll see an output similar to the below screenshot below.