In this post, we will explore how to enable seamless multi-cluster gRPC Remote Procedure Calls communication using Istio on Azure Kubernetes Service (AKS) using Kubernetes service Fully Qualified Domain Name. With the rise of distributed systems and microservices architectures, Istio provides an advanced service mesh solution that simplifies traffic management, security, and observability for microservices running across multiple Kubernetes clusters. This guide will walk you through the step-by-step process of setting up Istio with gRPC for cross-cluster communication, leveraging AKS to scale and manage applications in a multi-cluster environment.

Why gRPC and Istio for Multi-Cluster Communication?

In cloud-native applications built with gRPC, cross-cluster communication is essential to ensure scalability and high availability. Whether you are deploying microservices across regions for redundancy or optimizing traffic routing, a service mesh like Istio streamlines these processes.

What is Multi-cluster gRPC with Istio?

Multi-cluster gRPC is a high-performance, open-source framework designed for efficient communication between microservices, but when services span multiple clusters, managing this communication becomes complex. Istio enables secure, efficient, and observable communication across multiple AKS clusters while seamlessly supporting gRPC traffic.

In this post, we will set up a multi-cluster Istio deployment with gRPC for inter-cluster communication, providing you with the tools to scale your application architecture with resilience and security.

Note: This scenario works fine over the Azure CNI network. It may work over the Azure Kubenet and Overlay but for that we must create the services over the Load Balancer so it can be communicated from the cross cluster.

Literature Review

Although HTTP/REST remains popular for service communication, gRPC is rapidly emerging as the preferred choice for microservices because of its speed, support for multiple programming languages, and features like streaming, multiplexing, and bidirectional communication. gRPC uses Protocol Buffers (Protobuf) for efficient serialization, making it an ideal fit for high-performance environments. Istio, when configured for multi-cluster communication, is fully compatible with gRPC. It enables:

• Traffic Routing: Directing gRPC requests between clusters based on defined rules.
• Security: gRPC requests can be encrypted with mutual TLS (mTLS), ensuring secure communication between services across clusters.
• Observability: Metrics, tracing, and logging for gRPC calls across clusters, making it easier to track service performance.

Istio facilitates the global traffic distribution and load balancing needed for gRPC-based communication across regions, ensuring services interact with minimal latency.

Why Use Istio and gRPC Across Multiple AKS Clusters?

How to Set It Up: Step-by-Step Process Overview

1. Initial Cleanup of Existing Istio Installations

Before starting with the new Istio setup, we uninstalled previous Istio configurations from both AKS clusters to ensure a clean slate.

2. Download and Install Istio

We downloaded the required Istio version and set it up on the local system:

3. Create Certificates

Certificates would require establishing secure communication between clusters.

4. Create Namespace

Create namespace for Istio in both clusters.

5. Create secrets

Secrets store certificate details that are used to establish communication between clusters.

6. Install Istio in clusters

• To Create a cluster1 yaml file
  cat < cluster1.yaml
  apiVersion: install.istio.io/v1alpha1
  kind: IstioOperator
  spec:
  values:
  global:
  meshID: mesh1
  multiCluster:
  clusterName: cluster1
  network: network1
  EOF
• To install Istio using the created cluster1 file
  istioctl install –context=”${CTX_CLUSTER1}” -f cluster1.yaml -y
• To Create a cluster2 yaml file
  cat < cluster2.yaml
  apiVersion: install.istio.io/v1alpha1
  kind: IstioOperator
  spec:
  values:
  global:
  meshID: mesh1
  multiCluster:
  clusterName: cluster2
  network: network1
  EOF
• To install Istio using the created cluster2 file
  istioctl install –context=”${CTX_CLUSTER2}” -f cluster2.yaml -y

7. Create Remote Secrets

Remote secrets are required to establish a sync/communication between both clusters.

• For Cluster 1
  istioctl create-remote-secret \
  –context=”${CTX_CLUSTER1}” \
  –name=cluster1 | \
  kubectl apply -f – –context=”${CTX_CLUSTER2}”
• For Cluster 2
  istioctl create-remote-secret \
  –context=”${CTX_CLUSTER2}” \
  –name=cluster2 | \
  kubectl apply -f – –context=”${CTX_CLUSTER1}”
• Verify sync is establish or not
  istioctl remote-clusters –context=”${CTX_CLUSTER1}”
  istioctl remote-clusters –context=”${CTX_CLUSTER2}”

8. Install Application in Both AKS Clusters

• Create namespace in both clusters
  kubectl create –context=”${CTX_CLUSTER1}” namespace grpcclient
  kubectl create –context=”${CTX_CLUSTER2}” namespace grpcclient
  kubectl create –context=”${CTX_CLUSTER1}” namespace grpcserver
  kubectl create –context=”${CTX_CLUSTER2}” namespace grpcserver
• Enable Istio in both namespaces by adding a label
  kubectl label –context=”${CTX_CLUSTER1}” namespace grpcclient istio-injection=enabled
  kubectl label –context=”${CTX_CLUSTER2}” namespace grpcclient istio-injection=enabled
  kubectl label –context=”${CTX_CLUSTER1}” namespace grpcserver istio-injection=enabled
  kubectl label –context=”${CTX_CLUSTER2}” namespace grpcserver istio-injection=enabled

9. Create gRPC Client Application

• Yaml
  apiVersion: apps/v1
  kind: Deployment
  metadata:
  name: grpc-client
  spec:
  replicas: 1
  selector:
  matchLabels:
  app: grpc-client
  template:
  metadata:
  labels:
  app: grpc-client
  spec:
  containers:
  – name: grpc-client
  image: :
  ports:
  – containerPort: —
  apiVersion: v1
  kind: Service
  metadata:
  name: grpc-client
  spec:
  selector:
  app: grpc-client
  ports:
  – port: targetPort:
  protocol: TCP
  type: LoadBalancer

Note: The service type can be set to ClusterIP for internal communication within the cluster, while an external LoadBalancer can be used to route traffic from outside the cluster to this service

• Create Application
  kubectl apply –context=”${CTX_CLUSTER1}” -f /grpcclient.yaml -l service= grpcclient -n sample
  kubectl apply –context=”${CTX_CLUSTER2}” -f /grpcclient.yaml -l service= grpcclient -n sample
• Validate service
  kubectl get pod –context=”${CTX_CLUSTER1}” -n grpcclient
  kubectl get pod –context=”${CTX_CLUSTER2}” -n grpcclient

10. Create gRPC Server Application

• Yaml: name à grpcserver.yaml
  apiVersion: apps/v1
  kind: Deployment
  metadata:
  name: grpc- server
  spec:
  replicas: 1
  selector:
  matchLabels:
  app: grpc- server
  template:
  metadata:
  labels:
  app: grpc- server
  spec:
  containers:
  – name: grpc-client
  image: :
  ports:
  – containerPort: —
  apiVersion: v1
  kind: Service
  metadata:
  name: grpc-server
  spec:
  selector:
  app: grpc- server
  ports:
  – port: targetPort:
  protocol: TCP
  type: ClusterIP
• Create Application
  kubectl apply –context=”${CTX_CLUSTER1}” -f /grpcserver.yaml -l service= grpcserver -n sample
  kubectl apply –context=”${CTX_CLUSTER2}” -f /grpcserver.yaml -l service= grpcserver -n sample
• Validate service
  kubectl get pod –context=”${CTX_CLUSTER1}” -n grpcserver
  kubectl get pod –context=”${CTX_CLUSTER2}” -n grpcserver

11. Check Connectivity Between Both Applications Using Curl

• Create a sample namespace
  kubectl create namespace sample
• Install curl utility inside the cluster
  kubectl apply –context=”${CTX_CLUSTER1}” -f $ISTIO_HOME/samples/curl/curl.yaml -n sample
• Execute command using curl services
  kubectl exec –context=”${CTX_CLUSTER1}” -n sample -c curl “$(kubectl get pod –context=”${CTX_CLUSTER1}” -n grpcserver -l service= grpcserver -o jsonpath='{. items [0]. metadata.name}’)” — curl -sS grpcserver. grpcserver:/

Conclusion

Implementing Istio for multi-cluster communication in Azure Kubernetes Service (AKS) provides a robust framework for building highly available, scalable, and secure applications. By enabling seamless service-to-service communication across clusters, it eliminates the complexities of manual networking configurations and ensures reliable connectivity, even in geographically distributed environments.

With Istio’s service mesh capabilities, applications relying on gRPC calls between microservices across clusters benefit from consistent service discovery, load balancing, and secure mTLS communication. This ensures that gRPC traffic—often used for low-latency, high-throughput workloads—remains reliable, encrypted, and observable regardless of cluster boundaries.

This approach significantly improves application elasticity by allowing workloads to be distributed across multiple clusters based on demand, disaster recovery requirements, or compliance needs. At the same time, it reduces operational overhead through centralized traffic management, uniform security policies, and Istio’s built-in observability features.

Moreover, the ability to monitor, trace, and log both HTTP and gRPC traffic from a unified control plane enhances visibility into system performance and simplifies troubleshooting. Development and operations teams can detect anomalies faster, enforce consistent policies across clusters, and ensure end-to-end security without compromising agility.

Overall, adopting multi-cluster Istio in AKS not only streamlines inter-cluster communication—including critical gRPC service interactions—but also strengthens reliability, optimizes resource utilization, and provides a single pane of glass for managing and securing modern cloud-native applications.

Authors

                                   
Harshil Patel                                Yaksh Rawal