How to migrate from vanilla Kubernetes to Istio service mesh?

Souradeep Nanda
Oct 14, 2019 · 5 min read

The goal of this guide is to give the reader the most concise and non-intimidating introduction to istio while simultaneously providing further reading material if it piques his interest.

Before we start with the installation, let us compare it with vanilla Kubernetes.

Template flow vanilla vs istio

Instead of ingress, we have gateways which connect to virtual services. Everything else downstream remains the same.

Why virtual services?

Virtual services provide many features like infra level AB testing, fault injection, circuit breaking and a lot more.

Packet flow

Out to in

Whenever a new deployment is created in an istio-injected namespace an envoy container is inserted into the pod. It is widely referred to as sidecar. It automatically intercepts all incoming and outgoing requests. The application does not need to worry about this abstraction.

TIP: Reading the logs of the envoy is useful for debugging

Intra cluster

One of the benefits of having the envoy is that we can have mutual TLS secured connections inside the cluster. It helps in the realization of zero-trust networks.

One of the functions of the pilot is being a service discovery service.


This guide was written during istio 1.3.x, if things have changed too much in the future, consider consulting the official documentation.

We will be installing istio for Kubernetes cluster using helm charts.

You can find the detailed process in istio official website, but here is a quick version.

First, make sure helm and helm tiler is installed. For more details on helm, refer to the official guide.

brew install helm
helm init

In case you are unable to install helm tiler for some reason, you can just export the helm charts as k8s templates.

Next, we install istio

# First we create the namespace for istio
kubectl create namespace istio-system

In order for deployments in your namespace to use istio, we need to enable istio injection.

IMPORTANT: You have to delete and recreate your existing deployments.

IMPORTANT: You don’t have to inject istio-system.

# The following command enables injection in the potato namespace
kubectl label namespace potato istio-injection=enabled

Next, you need to create a gateway. Use this one as a sample.

kind: Gateway
name: my-gateway
namespace: istio-system
istio: ingressgateway # use Istio default gateway implementation
- port:
number: 80
name: http
protocol: HTTP
# -
- '*' # Allow everything
# Uncomment next two lines if you dont want any insecure connections
# to your website
# tls:
# httpsRedirect: true # sends 301 redirect for http requests

You would also need virtual services to bridge gateways to services. Use this one as a sample.

kind: VirtualService
name: tomato-virtual-service
namespace: potato
- istio-system/my-gateway # namespace-where-gateway-is/gateway-name
# -
- '*' # Allow everything
- match:
- uri:
prefix: /tomato
uri: /
- destination:
# Name of the service we want to connect to
host: tomato.potato.svc.cluster.local # service-name.namespace.svc.cluster.local
number: 8080 # Port forwarded by the service
weight: 100

Everything from service and below is the same as vanilla Kubernetes.

TROUBLESHOOTING: The ingress-gateway in istio-system pod is the load balancer. If you are unable to find the external IP of the cluster, try the external IP of the node running this pod. You can read more here.

Installing istioctl (optional)

cd ~/
curl -L
export PATH="$PATH:~/istio-1.3.0-rc.3/bin" # Assuming the version is 1.3.0


  1. Read the pod logs (Start with ingress-gateway, pilot, envoys). Further reading.
  2. Kill all the pods in istio-system
  3. Delete and create the gateway again
  4. Install kiali bash <(curl -L --accessible-namespaces '**'
  5. Run this to get a dump of all routes connected to the gateway. (requires istioctl)
  6. Watch these two videos. #1 #2

If all fails you can helm delete — purge istio, then kubectl delete namespace istio-system and start over again.

Good luck.


  • Envoy — Proxy inside your pods which intercepts all network traffic
  • Sidecar — The injected envoy container in your pods
  • Mixer — Collects telemetry and enforces usage policies.
  • Pilot — Service discovery service
  • Citadel — Key management service
  • Galley — Configuration validation

Follow us on Twitter 🐦 and Facebook 👥 and join our Facebook Group 💬.

To join our community Slack 🗣️ and read our weekly Faun topics 🗞️, click here⬇

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author! ⬇


The Must-Read Publication for Aspiring Developers & DevOps Enthusiasts. Medium’s largest DevOps publication.

Souradeep Nanda

Written by



The Must-Read Publication for Aspiring Developers & DevOps Enthusiasts. Medium’s largest DevOps publication.

More From Medium

More from Faun

More from Faun

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade