Skip to article
Containers AKS networking

AKS service mesh

AKS service mesh is a service-to-service traffic layer for AKS workloads, commonly delivered through the Istio-based add-on for traffic management, mTLS, and telemetry.

Source: Microsoft Learn - Istio-based service mesh add-on for Azure Kubernetes Service Reviewed 2026-05-10

Exam trap
Enabling sidecar injection without measuring latency, resource overhead, or rollback behavior.
Production check
Show mesh add-on status and confirm the expected revision is active before onboarding workloads.
Practice this topic Microsoft Learn
Article details and learning context
Aliases
Azure Kubernetes Service service mesh, aks service mesh
Difficulty
Advanced
CLI mappings
5
Last verified
2026-05-10
Review level
top250-pre130-priority
Article depth
field-manual-complete
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

AKS service mesh is the traffic layer that helps services in an Azure Kubernetes Service cluster communicate more safely and observably. Instead of every application team writing its own retry, routing, mTLS, and telemetry logic, the mesh provides shared behavior through sidecars, gateways, policies, and control-plane components. It does not replace good application design, but it gives platform teams a governed way to manage service-to-service traffic. You usually see it in microservice platforms that need consistent security, rollout, and tracing controls.

Why it matters

AKS service mesh matters because microservice communication becomes hard to secure and troubleshoot as clusters grow. A mesh can standardize mTLS, retries, traffic splitting, canary release behavior, and telemetry, but it also adds moving parts that can break calls when misconfigured. Teams need shared language for sidecars, control plane, certificates, traffic policy, and namespace onboarding so incidents are not blamed blindly on Kubernetes or application code. The best designs use mesh features where they solve real service-to-service problems, measure overhead, and keep rollback plans ready before routing customer traffic through new policies. Reviewers should tie each decision to a named owner, approved scope, expected evidence, and rollback path.

Official wording and source

An AKS service mesh is a service-to-service traffic layer for AKS workloads, commonly implemented through the Istio-based service mesh add-on. It can provide traffic management, mutual TLS, telemetry, policy controls, and safer rollout patterns for microservices.

Open Microsoft Learn

Technical context

Technically, AKS service mesh commonly refers to the Istio-based service mesh add-on or a comparable mesh architecture in AKS. It uses mesh control-plane components, sidecar proxies, gateways, certificates, traffic policies, telemetry, and namespace onboarding rules. Operators validate revision, injection labels, proxy readiness, mTLS mode, virtual services, destination rules, gateway configuration, and monitoring output. The mesh sits between application code and Kubernetes networking, so reviews must include cluster version, ingress, egress, DNS, identity, certificates, and observability settings.

Exam context

Compare with

AKS cluster AKS control plane

Where it is used

Where you see it

  1. In AKS, AKS service mesh appears in Istio add-on settings, mesh revisions, namespace labels, sidecar injection status, gateways, and traffic policy resources for named production owners.
  2. In kubectl output, it appears as sidecar containers, Envoy proxy logs, virtual services, destination rules, authorization policies, certificates, and mesh control-plane pods for named production owners.
  3. In architecture diagrams and runbooks, it appears between microservices, ingress gateways, mTLS boundaries, observability pipelines, canary releases, and platform ownership decisions for named production owners.

Common situations

  • Apply mTLS and service identity controls across sensitive microservices in AKS.
  • Run canary or traffic-splitting releases without custom routing logic inside every service.
  • Collect consistent telemetry for service-to-service latency, errors, and dependency mapping.
  • Standardize retry, timeout, and circuit-breaking behavior through reviewed traffic policies.
  • Troubleshoot service calls by inspecting sidecars, proxy logs, certificates, and mesh routes.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 AKS service mesh in payments API operations Scenario, objectives, solution, measured impact, and takeaway.
Scenario

BluePeak Finance, a payments API team, had a concrete Azure challenge: microservices used inconsistent TLS and retry logic, making payment incidents hard to trace. Leaders needed a practical design that platform, security, operations, and business owners could validate with live Azure evidence.

Goals
  • Enable mTLS for critical services
  • Standardize retry behavior
  • Expose service latency telemetry
  • Keep rollback ready for routing rules
Approach using AKS service mesh

Platform engineers introduced AKS service mesh for payment namespaces first. They enabled sidecar injection in a pilot, configured mTLS and reviewed traffic policies, then compared proxy telemetry with application logs. Security approved certificate rotation and namespace onboarding controls, while operations wrote rollback commands for route and injection changes. The team measured latency and resource overhead before adding more services, so the mesh solved a specific communication problem instead of becoming a blanket mandate. Operators also kept a validation packet with command output, timestamped screenshots, affected scopes, owner names, business acceptance criteria, and rollback notes. That packet let later reviewers repeat the evidence trail instead of relying on memory, chat history, or portal views captured during the original incident.

Potential outcomes
  • mTLS covered all payment namespaces
  • Retry storms stopped during failure tests
  • Dependency maps became available
  • Canary rollback completed in 6 minutes
What to learn

AKS service mesh worked best when the team paired security goals with measured traffic behavior and rollback evidence.

Scenario 02 AKS service mesh in clinical scheduling operations Scenario, objectives, solution, measured impact, and takeaway.
Scenario

AsterCare Health, a clinical scheduling team, had a concrete Azure challenge: a canary release needed traffic splitting between appointment services without changing application code. Leaders needed a practical design that platform, security, operations, and business owners could validate with live Azure evidence.

Goals
  • Route 10 percent of traffic to canary
  • Measure p95 latency impact
  • Protect patient booking reliability
  • Document emergency traffic reversal
Approach using AKS service mesh

The AKS team used service mesh traffic rules to route a small percentage of calls to the canary version. They checked sidecar readiness, gateway configuration, destination rules, and telemetry before the release. Application owners watched appointment success rates while platform operators monitored proxy errors and latency. The change ticket included commands to reverse routing immediately. After success, the team added mesh policy validation to CI so future canaries could be reviewed before production. Operators also kept a validation packet with command output, timestamped screenshots, affected scopes, owner names, business acceptance criteria, and rollback notes. That packet let later reviewers repeat the evidence trail instead of relying on memory, chat history, or portal views captured during the original incident.

Potential outcomes
  • Canary routing finished without code changes
  • p95 latency stayed within target
  • Traffic returned to stable service in testing
  • Operations gained a repeatable release pattern
What to learn

Traffic splitting was safer because mesh configuration, telemetry, and rollback were planned as one release motion.

Scenario 03 AKS service mesh in factory telemetry operations Scenario, objectives, solution, measured impact, and takeaway.
Scenario

Northstar Robotics, a factory telemetry team, had a concrete Azure challenge: a strict mTLS change caused several telemetry collectors to lose access after namespace onboarding. Leaders needed a practical design that platform, security, operations, and business owners could validate with live Azure evidence.

Goals
  • Find the failed service path
  • Separate certificate issues from code bugs
  • Restore telemetry collection
  • Improve onboarding checks
Approach using AKS service mesh

Operators investigated AKS service mesh signals before restarting collectors. They checked namespace labels, sidecar injection, peer authentication policy, destination rules, and Envoy proxy logs. The evidence showed that one collector namespace was onboarded without the expected service account and certificate path. Platform engineers corrected the policy, then updated the runbook with pre-onboarding checks for identity, sidecar readiness, and mTLS mode. Application teams received a short guide for recognizing mesh-related rejection errors. Operators also kept a validation packet with command output, timestamped screenshots, affected scopes, owner names, business acceptance criteria, and rollback notes. That packet let later reviewers repeat the evidence trail instead of relying on memory, chat history, or portal views captured during the original incident.

Potential outcomes
  • Telemetry recovered within one hour
  • Certificate mismatch was identified quickly
  • Onboarding checklist gained four checks
  • No node scaling was needed
What to learn

Mesh incidents became manageable once operators knew which proxy, certificate, and policy evidence to collect.

Azure CLI

CLI checks make AKS service mesh understandable by showing add-on state, sidecar injection, traffic policy, proxy health, and mesh telemetry evidence.

Useful for

  • Confirm mesh add-on status, revision, and namespace onboarding before routing production traffic.
  • Inspect sidecars, gateways, traffic rules, and mTLS policy during service-to-service incidents.
  • Collect proxy logs and Kubernetes events when canary routing or certificate behavior is suspicious.

Before you run a command

  • Confirm the AKS cluster, namespace, mesh revision, and workload labels before inspecting mesh resources.
  • Use read-only kubectl commands first because traffic-policy changes can affect live service calls.
  • Know the approved rollback path for sidecar injection, mTLS policy, gateway routing, and canary rules.

What the output tells you

  • Add-on output shows whether the mesh control plane and selected revision are enabled for the cluster.
  • Pod output shows whether workloads received sidecars and whether proxies are ready.
  • Policy, gateway, and proxy logs show how traffic is routed, secured, retried, or rejected.

Mapped commands

Aks operations

direct 
az aks list --resource-group <resource-group>
az aksdiscoverContainers
read-only Microsoft Learn 
az aks show --name <cluster-name> --resource-group <resource-group>
az aksdiscoverContainers
read-only Microsoft Learn 
az aks get-credentials --name <cluster-name> --resource-group <resource-group>
az akssecureContainers
security-impacting Microsoft Learn 
az aks create --name <cluster-name> --resource-group <resource-group> --node-count 3
az aksprovisionContainers
cost-impacting Microsoft Learn 
az aks update --name <cluster-name> --resource-group <resource-group>
az aksconfigureContainers
mutating Microsoft Learn

Architecture context

Technically, an AKS service mesh injects or manages sidecar and control-plane components that influence traffic between participating workloads. Istio concepts such as gateways, virtual services, destination rules, mTLS, telemetry, and mesh configuration can be applied through supported add-on behavior. The mesh interacts with ingress, egress, namespaces, labels, certificates, network policy, and monitoring. It does not replace sound application design; it adds a controllable layer for traffic policy, identity, and observability across distributed services. The practical proof is a named owner, a saved command output, and a rollback note that an on-call engineer can understand during a real incident.

Security
Security for AKS service mesh centers on service identity, certificate handling, mTLS policy, gateway exposure, namespace onboarding, and proxy privileges. A mesh can reduce clear-text service traffic, but only if teams configure authentication and authorization policies intentionally. Review who can change mesh resources, inject sidecars, modify gateways, or disable mTLS. Protect certificates and telemetry outputs because they reveal service relationships. For production, document trusted namespaces, ingress and egress rules, exceptions, rotation behavior, audit logs, and emergency bypass procedures so the mesh improves security without becoming an unmanaged control plane. Reviewers should tie each decision to a named owner, approved scope, expected evidence, and rollback path.
Cost
Cost for AKS service mesh comes from proxy sidecars, control-plane pods, telemetry ingestion, gateway resources, certificate operations, and the engineering effort needed to support traffic policy. Every injected workload consumes extra CPU and memory, and detailed metrics or traces can increase monitoring bills. A mesh can save cost by simplifying platform features, but overusing it for simple workloads creates overhead. FinOps and platform teams should measure proxy resource requests, log volume, trace sampling, gateway capacity, and latency impact. Enable mesh features where they justify their operational and resource cost. Reviewers should tie each decision to a named owner, approved scope, expected evidence, and rollback path.
Reliability
Reliability for AKS service mesh depends on healthy control-plane components, sidecar injection, proxy readiness, certificate rotation, gateway availability, and safe traffic policies. A bad route, strict mTLS mismatch, or proxy resource limit can interrupt service calls even when pods look healthy. Test mesh behavior with realistic retries, timeouts, canaries, DNS failures, and node maintenance. Keep rollback steps for namespace onboarding and traffic rules. During incidents, compare application errors, Envoy proxy logs, mesh telemetry, Kubernetes events, certificate state, and recent policy changes before restarting workloads or scaling nodes. Reviewers should tie each decision to a named owner, approved scope, expected evidence, and rollback path.
Performance
Performance for AKS service mesh is shaped by proxy overhead, TLS handshakes, route rules, retries, telemetry, gateway hops, and sidecar resource limits. The mesh can improve resilience, but it can also add latency or amplify traffic when retries are poorly configured. Measure p50, p95, and p99 latency before and after onboarding services. Test under realistic concurrency, payload sizes, certificate rotation, failure injection, and canary routing. Tune timeouts, retry budgets, sampling, proxy resources, and gateway placement with evidence. Do not assume Kubernetes service health proves mesh performance is acceptable. Reviewers should tie each decision to a named owner, approved scope, expected evidence, and rollback path.
Operations
Operationally, AKS service mesh needs clear ownership between platform and application teams. Runbooks should cover add-on status, revision upgrades, sidecar injection labels, proxy health, traffic policy review, gateway configuration, telemetry dashboards, and certificate checks. Release pipelines should validate mesh resources before applying them, especially for canary routing or mTLS changes. Operators need commands that distinguish application bugs from proxy, certificate, route, or policy problems. After incidents, update namespace onboarding guidance, alert thresholds, and rollback steps so teams do not rediscover the same mesh behavior under pressure. Reviewers should tie each decision to a named owner, approved scope, expected evidence, and rollback path.

Common mistakes

  • Enabling sidecar injection without measuring latency, resource overhead, or rollback behavior.
  • Blaming Kubernetes networking before checking mesh routes, mTLS mode, certificates, and proxy logs.
  • Letting application teams create conflicting traffic rules without platform review.