Service Mesh(Getting Hands-On with Istio)(Part 2)

This is a seven part series on service mesh. Starting with fundamentals, then hands-on with istio, resilience dynamic-routing and canary rollouts, API-Gateway, Security, obserability/tracing, and finally service-mesh at scale

In this article, we will use GKE and Istio’s Bookinfo Service Example as our microservices and install Istio Service Mesh on our cluster. We will go through the installation procedure in detail, verify our install and lastly add microservices to our mesh.

Istio Greek for “Sail” was started as an open-source effort by google back in 2016 learning from the service mesh that they developed for google’s internal services. The project intended to create a service-mesh that can simultaneously work services deployed in various environments. Currently, Istio can work with kubernetes, consul, and virtual machines deployed on the cloud or on-premises. Like other service meshes available, Istio’s structure consists of two parts. A data plane and a control plane.

The control plane in Istio consists of istiod.

istiod unifies the following services in itself:

  1. Citadel that does authentication and certificate rotation for (mtls).
  2. Galley that provides configuration management.
  3. Pilot responsible for service-discovery.
  4. Side-car injector whose job is to inject sidecars alongside our services.

The data-plane of istio uses a version of Envoy Proxy that was developed by Lyft. Envoy is installed as sidecar to all services, and the job of the envoy is to mediate all the incoming and outgoing traffic. Istio uses envoy’s built-in feature for dynamic routing, circuit breaking, tls termination, and metrics to implement the administrator's configuration.

Pre-requisites:

  1. A Kubernetes cluster on GKE, with RBAC access.

Download istio on your system, and set the env variable to access bin/istioctl in your terminal. Or navigate to the directory where istio is installed.

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

Out of the two ways available, we will be using istio-operator to install istio on our cluster. Istio-Operator is an effort by banzaicloud. It is essentially a controller, that reads a Kubernetes CRD of type Istio-Operator and creates istio-system namespace according to specs.

# Initialize istio-operator on your clusteristioctl operator init# Create namespace istio-systemkubectl create ns istio-system# Apply the following manifest from this gist: kubectl apply -f istio-manifest.yaml# To check wether manifest was deployed correctly or for validation errors. View logs of istio-operator podkubectl logs -f --selector=name=istio-operator -n istio-operatorA succesfull deployment should display the following info at the end2020-11-02T02:56:33.842590Z info end reconciling resources

I have made further comments about the spec in the gist.

Since our mesh was deployed and stabilized, we will now start adding microservices to our mesh. In Kubernetes, it's as easy as labeling a namespace. We will label all the namespaces that we want in our mesh and sidecar injector will automatically start to inject proxies into them.

# Label bookinfo namespacekubectl label namespace bookinfo istio-injection=enabled# Restart all pods in the namespaceKubectl delete pods --all -n bookinfo# Checking one of the pod to see if the side car is injected. kubectl get pods --selector=app=productpage -n bookinfo -o jsonpath="{.items[*].spec.containers[*].image}" 
|\ tr -s '[[:space:]]' '\n'
# And you should see two containers in the pod. docker.io/istio/examples-bookinfo-productpage-v1:1.16.2
docker.io/istio/proxyv2:1.5.3
# The proxyv2 is the envoy proxy and hence it is verified that sidecars are injected.

Now we have successfully added services to our mesh.

All traffic inside mesh will come from ingress gateway. We will now expose our productpage service to traffic coming from ingress gateway.

# Create gateway and virtualservice that redirects traffic to product service kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml# Determine Host Ip and Port
export INGRESS_HOST=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].port}')# Create firewall rule for GCP
gcloud compute firewall-rules create allow-gateway-http --allow "tcp:$INGRESS_PORT"
# Now you can verify external at
echo "http://$INGRESS_HOST:INGRESS_PORT/productpage" TaDa!!

Summary

We have seen how istio is architectured with a data plane and control plane. Using istio-operator we have installed istio in our cluster and exposed our mesh to outside traffic.

From here we go to adding resilience and dynamic routing to our mesh.

Bikes, Tea, Sunset, IndieMusic in that order. Software Engineer who fell in love with cloud-native infrastructure.