Getting started with Istio

This entry is part 2 of 12 in the series Istio around everything else

To set up Istio you need a Kubernetes Cluster with at least 4 vCPU and 8 GB of RAM. This guide is tested with the following Kubernetes Implementations:

After creating the cluster and configuring access with the Kubernetes command line tool we are ready to install Istio using the Helm Package manager.

Installing Helm

Install the Helm client on your computer as explained in the official docs. Which we will use to generate the Istio installation templates in the next section.

Installing Istio

Download Istio’s resources from the latest release, extract the contents and add the directory [istio-resources]/bin to the PATH environment variable. Verify installation by executing the command:

$ istioctl version

To easily identify the Istio resources create a namespace istio-system in your Kubernetes Cluster:

$ kubectl create namespace istio-system

Complete the installation by navigating to [istio-resources] directory and executing the command below:

$ helm template install/kubernetes/helm/istio --name istio \ 
    --set global.mtls.enabled=false \
    --set tracing.enabled=true \ 
    --set kiali.enabled=true \
    --set grafana.enabled=true \
    --namespace istio-system > istio.yaml

The above command prints out the core components of Istio into the file istio.yaml. We customized the template using the following parameters:

  • mtls.enabled is set to false to keep the introduction focused.
  • enabled enables tracing of requests using jaeger.
  • enabled installs Kiali in our claster for Visualizing Services and Traffic
  • enabled installs Grafana to visualize the collected metrics.

Apply the generated resources by executing the command:

$ kubectl apply -f istio.yaml

This marks the completion of the Istio installation in our cluster! Wait until all pods in the istio-system namespace are in Running or Completed state by executing the command below:

$ kubectl get pods -n istio-system

Now you are ready to continue with the next section, where we will get the sample application up and running.

Sentiment Analysis Application Architecture

We will use the same microservice application used in the Kubernetes Introduction article, it is complex enough to showcase Istio’s features in practice.

The App is composed of four microservice:

  • SA-Frontend service: Serves the frontend Reactjs application.
  • SA-WebApp service: Handles requests for Sentiment Analysis.
  • SA-Logic service: Performs sentiment analysis.
  • SA-Feedback service: Receives feedbacks from the users about the accuracy of the analysis.
Fig. 4. Microservice Architecture in Kubernetes

In Fig. 1 besides the services we see the Ingress Controller which in Kubernetes routes incoming requests to the appropriate services, Istio uses a similar concept called Ingress Gateway, which will be a subject in the next article.

Running the Application with Istio Proxies

To follow up with this article clone the repository istio-mastery, containing the application, the Kubernetes and Istio resources.

Sidecar Injection

As mentioned to intercept all network traffic Istio injects sidecar containers in every pod, this is done Automatically or Manually. To enable automatic Sidecar injection, we need to label the namespace with istio-injection=enabled, done by executing the command below:

$ kubectl label namespace default istio-injection=enabled
namespace/default labeled

From now every pod that is deployed into the default namespace will get the Sidecar automatically injected. Navigate to the root folder of the [istio-mastery] repository and execute the following command:

$ kubectl apply -f resource-manifests/kube
persistentvolumeclaim/sqlite-pvc created
deployment.extensions/sa-feedback created
service/sa-feedback created
deployment.extensions/sa-frontend created
service/sa-frontend created
deployment.extensions/sa-logic created
service/sa-logic created
deployment.extensions/sa-web-app created
service/sa-web-app created

Execute the command and verify that under the Ready column we see “2/2” indicating that a second container is injected.

$ kubectl get pods
NAME                           READY     STATUS    RESTARTS   AGE
sa-feedback-55f5dc4d9c-c9wfv   2/2       Running   0          12m
sa-frontend-558f8986-hhkj9     2/2       Running   0          12m
sa-logic-568498cb4d-s9ngt      2/2       Running   0          12m
sa-web-app-599cf47c7c-s7cvd    2/2       Running   0          12m

Closing down into one of the containers we will see the result as shown in Fig. 5. where every pod has a sidecar container that will manage inbound and outbound traffic.


Figure 5. Envoy Proxy injected in the pod

The application is up and running but to access it we need to allow incoming traffic, for which we use the term ingress traffic, and will be the main topic of the next article.

Istio in Practice – Ingress Gateway >>
If you enjoyed the article, please share and comment below!
  • Rok Inroks

    Hi thank for the extra dope article serie. I might be wrong but seems like the link to the repository doesn’t relate to the sentiment analisys app ?

    • Rinor Maloku

      Thanks for letting me know. Updated to the correct repository 😉

      • Rok Inroks

        Thanks Rinor 😉

  • Arun Bharadwaj

    Hello Rinor ,

    Very Nice article . I have just started with kubernetes and istio .

    I would like to know is there any way to see whether the envoy proxy is associated to the services . Just like below command . Once we check the pods we could see that the envoy sidecar container will be associated with the pods

    kubectl get pods
    sa-feedback-55f5dc4d9c-c9wfv 2/2 Running 0 12m

    Likewise i need to know if we do kubectl get svc do we see any envoy proxy is working on top of it .

    Sorry if my understanding is not correct . I have understood the flow is from envoy proxy the traffic will be routed to services and from there it will hit the application pod .

    I think this would be bad question . suppose if i have one deployment.yaml file and one associated deploymentservice.yaml file .

    So to inject envoy proxy should i run twice

    1) kubectl apply -f <( istioctl kube-inject -f deployment.yaml)
    2) kubectl apply -f <( istioctl kube-inject -f deploymentservice.yaml)

    • Rinor Maloku

      Hi Arun,

      You need to inject the sidecar proxy only in the Pods (i.e. Deployments whose Pods you want to be part of the service mesh). So if the second is a Kubernetes resource manifest of Type: Service, then cannot inject the proxy there.

      After we set up the Istio components and we enter the service mesh (usually through Istios Ingress Gateway) the requests from one proxy to another go directly, the Kubernetes Service is used just as a source of information for Configuring the proxies (A process done by Istio’s Control Plane). In other words when the request has to be sent from sa-web-app to sa-logic, the service doesn’t effect anything, it’s entirely done by the Envoy Proxies, and using Istio’s CRDs we configure the proxies.

      If I wasn’t able to clear the points that you raised, please continue to ask, and let’s make it a conversation 😉