ISTIO SERVICE MESH IMPLEMENTATION

Hey everyone!

I’m Mani, a DevOps/Cloud Engineer at an MNC. Let’s get straight to the point — recently, I ran into some frustrating packet loss issues in a GKE cluster on the way to solving that isses encounted service mesh concept and thought of sharing with you guys.I wanted to share my experience and some insights on how I tackled this issue — hopefully, it can help anyone facing similar challenges!

This cluster was running a file transfer application built with standard Kubernetes objects like deployments, PVCs, config maps, and load balancer services.

The application architecture, as implemented with Istio, is as follows:

Let’s dive straight into how the Istio implementation is done. Before that, let me briefly explain the four components involved:

1. Load Balancer
2. Istio Gateway
3. Istio Virtual Service
4. Kubernetes Service

Load balancer: it responsible for distributing incoming traffic across pods to ensure reliability, scalability, and optimal resource utilization. In an Istio setup, the load balancer typically directs traffic to the Istio Gateway, which then manages routing within the service mesh. in our case it is a GCP network LoadBalancer.

Istio Gateway: it is a critical component in Istio’s service mesh that manages external traffic entering the cluster. It operates at the edge of the mesh, handling Layer 4 and Layer 7 traffic. in our case it is routes just layer 4 traffic. The gateway allows you to define open ports, protocols, and secure connections (e.g., TLS termination). Once traffic passes through the gateway, it is routed to the appropriate Istio Virtual Services for finer-grained control.

Istio Virtual Service: it is a configuration resource that defines how traffic is routed within the service mesh. It provides fine-grained control over request routing, including traffic splitting, retries, timeouts, and fault injection. Virtual Services work in conjunction with Gateways and Kubernetes Services to direct traffic to specific versions of an application or across multiple services, enabling advanced use cases like canary deployments or blue-green deployments.

Kubernetes Service: It provides a stable network endpoint (ClusterIP, NodePort, or LoadBalancer) for communication between different components of an application. In an Istio-enabled cluster, Kubernetes Services are integrated into the service mesh, where Istio handles advanced routing, traffic management, and observability for the services.

Now, let’s look at how to install the Istio service mesh in Kubernetes:

Step 1: Install the istioctl CLI

Use the following command to download and install istioctl using curl:

curl -sL https://istio.io/downloadIstioctl | sh -

Step 2: Add istioctl to Your System Path (Linux)

Run the command below to add the istioctl binary to your system’s PATH:

export PATH=$HOME/.istioctl/bin:$PATH

Step 3: Install Istio Service Mesh on the Cluster

Install the Istio service mesh using the following command. Here, we’re using the demo profile, which automatically creates an Istio Ingress LoadBalancer and an Istio Egress LoadBalancer:

Get Manikanta’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

istioctl install — set profile=demo -y

Step 4: Verify the Istio Installation

After the installation, verify the setup using the command below:

istioctl verify-install

Once all the installations are complete, we can begin using Istio to route application traffic through the service mesh.

Before we proceed, it’s important to understand how Istio routes traffic. Istio uses Envoy Proxy, which functions as a sidecar attached to the application pod. The Envoy sidecar shares the same network interface as the original pod, enabling it to intercept, manage, and route all incoming and outgoing traffic. This sidecar proxy allows Istio to apply advanced traffic management, security, and observability features without requiring changes to the application code.

To enable Istio in your namespace, you need to label the namespace with istio-injection=enabled. You can do this by running the following command:

kubectl label namespace default istio-injection=enabled

Once the namespace is labeled, you can simply restart the pods. Istio will automatically attach an Envoy Proxy sidecar container to each pod, and you won’t need to make any changes to the application code, YAML files, or anything else.

Let’s begin configuring Istio to route traffic to our application.

The first step is to create an Istio Gateway, which serves as the entry point for traffic entering the Kubernetes cluster. istio gateways are namespace specific.

Sample Gateway yaml:

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: sftp-server-gw
spec:
  selector:
    istio: ingressgateway   # selecter for the istio ingressgateway 
  servers:
    - hosts:
      - '*'
      port:
        name: tcp
        number: 9001   #entry for our sftp application
        protocol: TCP

Make sure to provide the correct selector for the Ingress Gateway created by Istio in the istio-system namespace. When accessing the application, you must connect to the LoadBalancer IP of the Istio Ingress Gateway service. The host section in the gateway configuration acts like a firewall, allowing traffic to pass through only if it comes from the specified host mentioned in the gateway YAML.

Now that we have an entry point into our service mesh, the next step is to create a connection between the gateway and the application service using an Istio Virtual Service.

Sample VirtualService Yaml:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: sftp-vs
spec:
  gateways:
    - sftp-server-gw   # provide the gateway name to which it should be applied
  hosts:
    - "*"
  tcp:
    - match:
      - port: 9001    # should match with the port given in the gateway yaml
      route:
      - destination:
          host: server-sftp-service.server-namespace.svc.cluster.local   #provide the service host of the service used to expose teh actual application you wish to expose
          port:
            number: 4722   #provide the service port of the service used to expose the actual application you wish to expose

Specify the gateway name to apply the configuration to. The port in the match section should correspond to the port defined in the gateway. Additionally, in the destination section, provide the service host and port of the Kubernetes service used to expose your application.

Once the configuration is complete, you need to add the gateway port to the Istio Ingress LoadBalancer service to fully expose the application to users via Istio.

sample yaml snippet:

- name: tcp-server-sftp
  port: 4300       # port you wish to expose your gateway using istio ingress loadbalancer 
  protocol: TCP
  targetPort: 32001   # should be the port you  exposed mentioned in istio gateway service 

That’s it! You can now access the application using the Istio Ingress LoadBalancer on port 4300, for example, to perform a file transfer.

Hope this helps… thanks for reading..have a great day…