Service Mesh Series Part 1/3 – Your First Istio Deployment

Service Meshes seem to be all the rage in the last year as several projects became more mature. What exactly is a Service Mesh?

By Ravi Lachhman
September 30, 2019

Istio has been gaining a lot of popularity in the last year. I am not 100% on what Istio is but what I do know is that I need two Istios; one to use and one for show to get on stage at a technology conference such as CNCF’s KubeCon.

All jokes aside, don’t worry if your knowledge of Service Meshes has some gaps. We are here to help at Harness. Service Mesh technology is blooming as our applications are becoming more distributed and embracing a more microservice architecture. 

Changing Landscape

Not too long ago, networking teams owned the connectivity and routing between your application and the inside/outside world. When we had a handful of predictable contexts to route to, the networking team could be given plenty of time to modify the rules (remember filing a ticket for a firewall rule or adding a new virtual IP?).  Take a look at the below requests for tacos that I gave in a presentation about application networking complexity. 

The traditional olden day taco request with virtual machines:

With the networking stack to support the olden days:

As applications started to become more distributed, our tickets to the networking teams became longer as a dynamic portion of endpoints started to creep in. 

Fast forward to today with the land of Kubernetes, Serverless, and the public cloud; resources are always being spun up and spun down. We certainly could not make a ticket for every endpoint as routes and endpoints change all the time as systems decide how much firepower we need e.g autoscaling. 

The modern-day taco request with Lambda and Redis:

With a networking stack to support the modern days:

With development teams and orchestrators cranking out more endpoints than ever, there needed to be technology in place to make sure communication was clear, thus welcome Service Meshes.

Hello Mesh

With the ever-changing and distributed architectures ushering us out of the monolith, Service Mesh technology is born. Solo.io, a leader in Service Mesh orchestration defines “Service Mesh abstracts the business logic of an application (what the service does) from the application network (how it should talk to each other)”.  Having your applications participate in a Service Mesh abstracts away the networking complexity (though this complexity has to go somewhere, stay tuned for part two). 

Like any rising in popularity technology, there are choices in Service Mesh. Like Kubernetes, the most popular one by the amount of press is Istio. Honorable mentions though are LinkerD, Hashi’s Consul, and even public cloud vendors such as AWS has AWS App Mesh. Let’s run through your first Istio deployment to see what the hoopla is all about.

Your First Istio

Deploying Istio and an application that leverages Istio is easy with just a few pieces. We can use our trusted friend, Minikube, and go through Istio’s example application, book info. Reading the Istio documentation on Minikube, we do need to allocate some more resources to Minikube. 

We will also be using istioctl, the command-line utility for Istio. 

Like always can watch the video or go through the rest of the blog post. 

Grab an Istio distribution, at the time of this blog the latest is 1.3.1:
curl -L https://git.io/getLatestIstio | ISTIO_VERSION=1.3.1 sh –

Once you download the files, you can follow the prompt to add istioctl to your path. Or can CD into the folder for istioctl and wire from there.
cd istio-1.3.1
export PATH=$PWD/bin:$PATH

Let’s get a Minikube instance started. If you have not used Minikube before, you can leverage Homebrew to install/upgrade.
brew cask install minikube or brew cask update minikube 

With Minikube installed:
minikube start –memory=8192 –cpus=4

Validate by launching the dashboard.
minikube dashboard

Verify with istioctl also.
istioctl verify-install

Once we validated with istioctl,  we can leverage install the Istio Demo that is included with the Istio Download.
kubectl apply -f install/kubernetes/istio-demo.yaml

We can validate the install by seeing if the appropriate services have started.
kubectl get svc -n istio-system

Now that Istio is running, configure the default namespace for automatic sidecar injection. Getting closer to the Istio-ing!
kubectl label namespace default istio-injection=enabled

Now install the book info app.
kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml

Let’s make the application accessible outside the Kubernetes cluster with an Istio Gateway.
kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml
kubectl get gateway

Getting closer, we now need to set the Ingress IP and Ports and set the Gateway URL. 

export INGRESS_HOST=$(minikube ip)

export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name==”http2″)].nodePort}’)

export SECURE_INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name==”https”)].nodePort}’)

export GATEWAY_URL=$INGRESS_HOST:$INGRESS_PORT

Finally, let’s get the Gateway URL.  Here I get 192.168.99.100:31380
printenv GATEWAY_URL

We can go to the <Gateway_URL> / productpage to see the application. Just like that, you are cooking with Istio!

An important feature of Istio is to allow Istio to handle destination rules. The book info sample application comes with a few handy ones for us to learn off of.
kubectl apply -f samples/bookinfo/networking/destination-rule-all.yaml
kubectl get destinationrules -o yaml

With that, you have an Istio environment and application to play with. Like any good net citizen, let’s clean up once we are done. The Istio project makes this easy by shipping a cleanup.sh.
/istio-1.3.1/samples/bookinfo/platform/kube/cleanup.sh

Can terminate minikube with minikube delete.

Mesh with Harness

Service Meshes continue to rise in popularity. At Harness, we are here to help. Service Meshes are democratizing networking rules to the development teams. Having the destination rules/traffic splits as part of your pipelines are import. 

Stay tuned for part two where we talk about the challenges with Service Meshes. I am not a networking engineer and a bulk share of challenges is bringing networking complexity to the app dev world. 

Cheers!

-Ravi

➞ Back to Blog

Leave a Reply

avatar
  Subscribe  
Notify of