Table of Contents
Managing ingress for multiple Kubernetes applications can quickly become complicated. Separate public endpoints, TLS certificates, routing rules, and security policies can increase operational overhead as an AKS environment grows.
Istio Service Mesh on AKS provides a centralized architecture for managing application ingress, traffic routing, TLS, and service-to-service security across Kubernetes workloads.
In this hands-on implementation, Istio was deployed on Azure Kubernetes Service (AKS) with Cloudflare, Azure Load Balancer, cert-manager, Let’s Encrypt, and Istio VirtualServices. The implementation was validated in a test environment with two applications behind a shared Istio Ingress Gateway.
What Is Istio Service Mesh on AKS?
Istio Service Mesh on AKS is an architecture that adds traffic management, secure ingress, TLS control, routing, and service-to-service security capabilities to applications running on Azure Kubernetes Service.
Instead of exposing each application through its own public ingress infrastructure, a shared Istio Ingress Gateway can receive external traffic and use VirtualServices to route requests to individual Kubernetes Services.
Implementation at a Glance
This implementation was designed as a practical Istio Service Mesh proof of concept rather than a theoretical deployment.
Environment
- Platform: Azure Kubernetes Service (AKS)
- Istio: 1.17.8
- Istio installation: Minimal control-plane profile
- Ingress: Istio Ingress Gateway
- External Load Balancer: Azure Load Balancer
- DNS/proxy: Cloudflare
- TLS: cert-manager + Let’s Encrypt
- Certificate validation: Cloudflare DNS-01
- Certificate: Wildcard *.deminine.online
- Applications: nginx and httpbin
- Status: Validated in a test environment
The implementation covered AKS validation, Istio control-plane installation, ingress gateway deployment, application routing, Cloudflare integration, wildcard TLS, and HTTP/HTTPS validation.
Architecture: How Istio Works with AKS
The complete request path implemented in the POC was:
Internet
   |
   v
Cloudflare DNS / Proxy
   |
   v
Azure Load Balancer
   |
   v
Istio Ingress Gateway
   |
   v
Shared Istio Gateway
   |
   v
VirtualService
   |
   v
Kubernetes Service
   |
   v
Application Pod
For example:
test-nginx.deminine.online
        |
        v
Azure Load Balancer
        |
        v
Istio Ingress Gateway
        |
        v
test-nginx VirtualService
        |
        v
test-nginx Service
        |
        v
nginx Pods
The second application followed the same architecture:
test-api.deminine.online
        |
        v
Azure Load Balancer
        |
        v
Istio Ingress Gateway
        |
        v
test-api VirtualService
        |
        v
test-api Service
        |
        v
httpbin Pods
This separation is important because the Gateway provides the shared ingress boundary, while VirtualServices provide application-specific routing.
Why Use a Shared Istio Gateway?
A common challenge in multi-application Kubernetes environments is deciding how external traffic should enter the cluster.
Creating a separate public ingress endpoint for every application can increase infrastructure complexity.
A shared Gateway provides a different model:
                 Shared Istio Gateway
                          |
             +————+————+
             |             |
             v             v
       test-nginx VS       test-api VS
             |             |
             v             v
      test-nginx Service    test-api Service
             |             |
             v             v
         nginx Pods       httpbin Pods
During this implementation, both applications used the same Istio Gateway and public IP. Adding the second application required a new workload and VirtualService rather than another Gateway or TLS certificate.
This model can be useful for SaaS platforms, API environments, development clusters, and organizations running multiple applications on a shared AKS platform.
How to Deploy Istio Service Mesh on Azure Kubernetes Service (AKS)
1. Validate the AKS Cluster
Before installing Istio, validate the existing cluster.
Important checks include:
- Kubernetes client and server versions
- Node readiness
- Existing Istio resources
- Existing Gateway API or Istio CRDs
- Existing ingress controllers
- Potential Load Balancer conflicts
In this implementation, the cluster was checked for existing ingress services such as NGINX before deploying the Istio gateway.
This step is particularly important when introducing Istio into an existing Kubernetes environment.
2. Install the Istio Control Plane
Istio 1.17.8 was installed using the minimal profile.
The minimal profile was intentionally used so that the Istio control plane could be installed separately from the ingress gateway. A dedicated ingress configuration was subsequently used for greater control over the gateway deployment.
The installation was then verified using Istio and Kubernetes commands, including validation of the Istio CRDs.
Istio Ingress Gateway Configuration on AKS
The Istio Ingress Gateway was deployed separately from the control plane.
Before applying the configuration, the generated manifest was reviewed to verify resources such as:
- Deployment
- Service
- HorizontalPodAutoscaler
- PodDisruptionBudget
This provides an additional validation step before changing the cluster.
The gateway was then exposed through an Azure Load Balancer.
At this point, an important troubleshooting condition appeared: Envoy initially reported RDS NOT SENT.
This was not a gateway failure. No VirtualService existed yet, so Envoy had no HTTP routing configuration to advertise. After the first VirtualService was created, RDS changed to SYNCED.
Application Routing with Istio VirtualService
The first application was an nginx deployment with two replicas exposed internally through a ClusterIP Service.
The shared Gateway accepted traffic for:
*.deminine.online
A VirtualService then defined the application-specific route:
test-nginx.deminine.online → test-nginx Service
This illustrates an important design principle:
Gateway defines the common ingress configuration; VirtualService defines how application traffic is routed.
A second VirtualService was later created for test-api.deminine.online, allowing both applications to use the same ingress infrastructure.
Secure TLS with Cloudflare and cert-manager
External DNS and proxying were configured through Cloudflare, pointing the application hostname toward the Azure Load Balancer.
The next step was HTTPS.
The implementation used cert-manager with Let’s Encrypt and the Cloudflare DNS-01 challenge to create a wildcard certificate for:
*.deminine.online
The existing letsencrypt-dns01 ClusterIssuer was used. DNS-01 was selected because wildcard certificate validation requires DNS-based validation rather than HTTP-01.
The resulting TLS Secret was created in the istio-ingress namespace, where the Gateway could reference it.
The Gateway was then updated with an HTTPS listener on port 443 using:
- HTTPS protocol
- SIMPLE TLS mode
- Wildcard TLS credential
- *.deminine.online hostname
Envoy subsequently exposed the HTTPS listener and loaded the certificate.
Istio Gateway vs Kubernetes Ingress
Traditional Kubernetes Ingress can handle common HTTP and HTTPS routing requirements, but Istio Service Mesh provides a broader traffic-management model.
| Capability | Kubernetes Ingress | Istio Gateway |
| HTTP/HTTPS ingress | Yes | Yes |
| Host-based routing | Yes | Yes |
| TLS configuration | Yes | Yes |
| Advanced traffic management | Controller-dependent | Istio-native |
| VirtualService integration | No | Yes |
| Service-mesh integration | No | Yes |
| mTLS | Not inherently | Istio capability |
| Workload identity | Limited | Supported through mesh security |
The important distinction is not that Kubernetes Ingress is obsolete. Instead, Istio becomes particularly valuable when ingress needs to integrate with broader traffic management and Kubernetes Security requirements.
What We Learned During the Implementation
Hands-on implementation exposed several issues that are easy to overlook in a theoretical architecture.
RDS NOT SENT Can Be Expected
Immediately after gateway installation, Envoy had no routes because no VirtualService had been created.
Once the first VirtualService was applied, the routing configuration synchronized automatically.
Cloudflare 522 Can Indicate an Origin Listener Problem
During the staged setup, Cloudflare returned HTTP 522 because the Istio Gateway did not yet have an HTTPS listener on port 443.
Adding the HTTPS server and TLS credential resolved the issue.
Validate the Load Balancer IP
The runbook also identified an incorrect IP in one test command. The documented troubleshooting step was to verify the actual external IP using Kubernetes rather than relying on a copied value.
These observations highlight an important operational principle: troubleshoot each layer independently-DNS, Cloudflare, Load Balancer, Gateway listener, certificate, VirtualService, Service, and Pod.
Kubernetes Security: What Comes Next?
Ingress and TLS were the primary security-related components validated in this POC.
Istio can also provide capabilities such as:
- mTLS for encrypted and authenticated service-to-service communication
- AuthorizationPolicy
- Workload identity
- Service-level access control
- Zero-trust security foundations
However, the deeper mTLS and AuthorizationPolicy implementation was identified as the next stage, rather than being presented as completed in this POC.
This distinction is important when evaluating an Istio deployment: secure external ingress is only one part of a broader service-mesh security strategy.
Production Considerations
A proof of concept should not be copied directly into production without additional design work.
Before production adoption, consider:
- High availability for ingress gateways
- TLS certificate renewal monitoring
- Restricted Gateway and VirtualService permissions
- mTLS between appropriate workloads
- AuthorizationPolicy
- Monitoring and observability
- Load Balancer failure scenarios
- Cloudflare-origin connectivity
- Disaster recovery
- Istio version lifecycle and upgrade planning
The goal should be to evolve the POC into a controlled platform architecture rather than simply reproducing the test configuration.
Real-World Use Cases
This architecture can support organizations running:
- Multiple APIs on AKS
- Microservices platforms
- SaaS applications
- Shared development and staging clusters
- Multi-tenant application environments
- Centralized TLS infrastructure
- Kubernetes environments moving toward zero-trust security
- Platforms requiring advanced traffic management
The shared Gateway model is particularly useful when multiple applications need consistent ingress and TLS without creating separate public ingress infrastructure for every workload.
The Future of Istio on AKS
The next evolution of this implementation is beyond basic ingress.
Potential improvements include:
mTLS → AuthorizationPolicy → traffic splitting → observability → progressive delivery → zero-trust service-to-service security
This progression turns Istio from an ingress component into a broader platform layer for controlling how Kubernetes workloads communicate, secure traffic, and manage application delivery.
Key Takeaway
The value of implementing Istio Service Mesh on AKS is not simply installing Istio. It is understanding how the individual components work together.
This implementation validated the complete flow:
Cloudflare → Azure Load Balancer → Istio Ingress Gateway → VirtualService → Kubernetes Service → Application
It demonstrated centralized ingress, wildcard TLS, Cloudflare DNS integration, cert-manager, and routing for multiple applications through a shared Gateway.
For organizations whose AKS environments are growing beyond basic ingress requirements, Istio provides a foundation for more advanced traffic management, security, and service-to-service communication.
Build a More Secure and Manageable AKS Platform
If your AKS environment has multiple applications, APIs, public endpoints, and increasingly complex traffic policies, adding more independent ingress configurations can create long-term operational overhead.
Geeks Solutions helps organizations design and implement Kubernetes, AKS, DevOps, cloud infrastructure, and service-mesh architectures—helping teams move from basic Kubernetes ingress toward centralized traffic management and stronger application security.
Start by evaluating your current AKS ingress architecture, TLS management, and service-to-service security requirements. The right Istio design can provide a scalable foundation for secure application delivery today and zero-trust Kubernetes architecture tomorrow.
Frequently Asked Questions
Deploying Istio Service Mesh on Azure Kubernetes Service (AKS) involves validating the AKS cluster, installing the Istio control plane, deploying an Istio Ingress Gateway, configuring VirtualServices, and securing traffic with TLS certificates. This approach provides centralized traffic management, ingress control, and a foundation for Kubernetes security.
An Istio Ingress Gateway acts as a centralized entry point for external traffic entering an AKS cluster. It receives requests from the Azure Load Balancer and routes them to the correct application using VirtualServices, allowing multiple applications to share the same ingress infrastructure.
To configure wildcard TLS certificates in Istio, cert-manager can be integrated with Let’s Encrypt using the Cloudflare DNS-01 challenge. The wildcard certificate is stored as a Kubernetes Secret and referenced by the Istio Gateway to provide secure HTTPS connectivity for multiple subdomains.
Istio enhances Kubernetes security by enabling mutual TLS (mTLS), which encrypts and authenticates service-to-service communication. Combined with AuthorizationPolicies and workload identities, mTLS helps organizations implement a zero-trust security model inside Kubernetes environments.
A shared Istio Gateway allows multiple applications to use the same public endpoint, TLS configuration, and ingress infrastructure. Instead of creating separate ingress resources for each application, teams can add new VirtualServices to route traffic, reducing operational complexity and improving scalability.
