Istio and Google Kubernetes Engine: From 0 to 1

Published in

intelligentmachines

5 min readApr 16, 2020

You have some experience with Kubernetes and have deployed basic applications on Kubernetes. You have heard of Istio and all the wonderful features that it brings to your Kubernetes application like Canary Deployment, Circuit Breaking, JWT authentication, mTLS. And now you just want to get some hands-on experience on how you can introduce Istio in the very minimum level possible just to test the waters. This story will help you out with that.

This story does not give you any explanation of what Istio is. It just lists down the steps that you will need to get from Step 0 to step 1.

Will explain Istio’s other features in subsequent stories.

Prerequisite

Setup a GKE cluster with node auto-scale enabled. If you create a basic GKE cluster with just 3 n1-standard-1 nodes, then sometimes it gives OutOfCPU error as Istio itself uses up some CPU. Follow this link to get a better understanding https://istio.io/docs/ops/deployment/performance-and-scalability
First, check if your cluster is a private cluster or it’s protected by firewall rules. Just connect to your cluster using gcloud CLI and run
kubectl get pods If you get a Timeout error then

white list your IP address so you can access the cluster using kubectl
By following this guide https://istio.io/docs/setup/platform-setup/gke, you need to open the port 15017 by updating the firewall rule.

gcloud commands to update firewall rules

Note: If the cluster is not private, then you don’t need to go through these previous steps.

3. Istio installed in your GKE cluster. If you want to explore all the features Istio gives out of the box, then install Istio with the Demo profile. It comes with all the addon component Istio has to offer.

istioctl manifest apply --set profile=demo

Note: I encourage you to use the latest version of Istio. Google also gives a way to add Istio with your cluster at cluster creation time. But it’s normally several versions outdated.

4. You need to have your Deployment and Service manifest YAMLs and add a label to these manifests.

Sidecar Injection

Istio uses Envoy as a sidecar proxy to introduce all its cool features. Before you deploy your application you need to manually inject sidecar proxy or enable automatic sidecar injection to a namespace. If you are completely new on the block and don’t know how Istio works at least from a birds-eye view, all these Envoy proxy, Sidecar, and many other terms might confuse you. Not might it definitely will. If you just want to get Istio up and running, then follow the steps as-is. If you want to get a better understanding of what these jargons mean then you can read the Istio documentation. It’s good.

Manual sidecar injection

You can choose to inject sidecars on a per-workload basis using the following command.
istioctl kube-inject -f samples/sleep/sleep.yaml | kubectl apply -f -

Automatic Sidecar Injection

If you want to inject sidecar proxies automatically to your pods then you can run the command below and enable automatic sidecar injection.

kubectl label namespace <NAMESPACE_NAME> istio-injection=enabled

This enables sidecar injection for the namespace you specified.

Sample Kubernetes manifests

A good thing about Istio is that you can use it’s functionality on top of your existing Kubernetes application. You don’t need to modify your native Kubernetes manifests(Deployment, Service) apart from some labels. And if at some point in the future you decide not to use Istio, you can just uninstall Istio and all the services in your GKE cluster should work as usual.

Kubernetes native manifest files and the modifications you need

Assuming you already have a Kubernetes application deployed on GKE with a very basic Deployment and a Service, the only thing that you need to check is that you have added a label: app:<APP_NAME> in the metadata section

Note: If you don’t add this label then Kiali does not treat these components as part of the same application and you can’t see the traffic flow properly.

Istio native manifest files

If you have the kubernetes Deployment and a Service file ready, to integrate Istio, you will need two things.

Gateway
Virtualservice

There are some other CRDs like DestinationRule, PeerAuthentication, AuthorizationPolicy. But those are for some other cool feature of Istio. To introduce basic Istio in your cluster Gateway and Virtualservice is good enough. Let me give you a short intro on what these two types of CRDs(Custom Resource Definition) are.

Gateway

Gateway just sits at the edge of your GKE cluster and defines the Port and Protocol for the incoming traffic. It basically works as a door at the edge of your cluster. It only lets the traffic in. But it does not tell the traffic which service it should hit. That’s where the Virtualservice comes in.

Virtualservice

Virtualservice is the component that takes the incoming traffic from the Gateway and delivers to the right micro-service. You may ask that what’s the difference between a Service and a Virtualservice? Virtualservice basically extends the capability of a Kubernetes service and brings in cool features like Canary Deployments, Traffic Mirroring, Fault Injection, and many more things. Here is a sample of a Gateway and a Virtualservice

Sample Gateway Manifest

Sample Virtualservice Manifest

<GATEWAY_NAME>: It has to match with the gateway you have defined.
<NAME_OF_THE_KUBERNETES_NATIVE_SERVICE>: It’s the name of the service where you want your traffic delivered to.
<SAME_PORT_USED_IN_SERVICE_MANIFEST_FILE>: It’s the PORT(not the TARGETPORT) number that was defined in your Kubernetes service manifest.

Sample Manifest for Virtualservice with Routes

If you want to route your traffic based on a path then you can use the following sample Virtualservice

Virtualservice with routes

Applying Istio configurations

Make sure you have

Your Kubernetes Deployment and Service ready with the right label added
Your Gateway and Virtualservice is configured right
You have automatic sidecar injection enabled for the namespace you want to deploy your app to. You can also use manual sidecar injection if you want

Then simply deploy your config files with a standard kubectl command.
kubectl apply -f <FILENAME>

List your deployed Istio CRDs

After you have deployed your Gateway and Virtualservice, you can see the list of your deployed resources using these commands.

List Gateways

kubectl get gw

List Virtualservices

kubectl get vs

See the results

After you have deployed all your YAML configurations, the Istio Gateway connects with the Istio Ingress and routes traffic. You can use the IP address of the Istio Ingress to test out your Istio setup.

kubectl get svc istio-ingressgateway -n istio-system

It will give you a public address. Put it in a browser and if everything goes well you should see your applications landing page.

Accessing the Dashboards

If you have istioctl installed in your laptop, you can easily access the dashboard that Istio gives you out of the box.

istioctl dashboard kiali
istioctl dashboard jaeger
istioctl dashboard grafana
istioctl dashboard prometheus

Troubleshooting

In your kiali graph, you may see some sources named unknown. It doesn’t necessarily mean your settings are wrong. There are several reasons for that. Read through this to understand the pattern of traffic.

Useful Links

If you want to learn more about istio refer to these links