In-Depth Istio Product Study: Service Mesh Capabilities, Governance Rules, Enterprise Adoption Cost, and Current Status

Overview

An in-depth study of Istio as a service mesh product, covering Envoy, Istiod, Kubernetes CRDs, xDS, traffic routing, authentication, authorization, circuit breaking, rate limiting, service discovery, VM and bare-metal adoption, gateway integration, observability, OpenTelemetry, ambient mesh, enterprise case studies, and the current Istio product direction.

1. Istio's Product Positioning

Istio officially positions itself as a service mesh. In Istio's official definition, a service mesh is an infrastructure layer used to provide zero-trust security, observability, and advanced traffic management for service-to-service communication, usually without requiring application code changes. CNCF's project description for Istio also emphasizes that Istio provides a uniform and efficient way to secure, connect, and monitor services in cloud-native applications. Istio entered CNCF Incubating in September 2022 and became a CNCF Graduated project in July 2023. (Istio)

The core problem Istio solves is not a single "gateway problem" or "registry problem." It is the governance problem of service-to-service communication. Istio's official architecture documentation divides an Istio mesh into a data plane and a control plane. The data plane consists of proxies that mediate and control communication between services and collect telemetry data. The control plane manages and configures these proxies, translating rules into configuration that proxies can execute. (Istio)

Based on its official capability descriptions, Istio mainly provides traffic routing, traffic splitting, canary release, fault injection, retries, timeouts, circuit breaking, load balancing, mTLS, service identity, authentication, authorization, auditing, metrics, logs, distributed tracing, and proxy behavior extension through mechanisms such as WebAssembly. Istio uses Envoy as its core data-plane proxy. Envoy itself supports dynamic service discovery, load balancing, TLS termination, HTTP/2 and gRPC proxying, circuit breaking, health checks, canary release, fault injection, and rich metrics. (Istio)

2. Istio Architecture and Key Technologies

Istio's key technologies can be summarized into four layers: the Envoy data plane, the Istiod control plane, the Kubernetes CRD configuration model, and the xDS dynamic configuration protocol.

In sidecar mode, an Envoy proxy runs next to each workload, and the application's inbound and outbound traffic is taken over by the proxy. The official documentation explains that Envoy is a high-performance proxy implemented in C++. Istio extends Envoy and uses it as a sidecar to add traffic governance, security, and telemetry capabilities to the service communication path, while the application itself usually does not need to be rewritten. (Istio)

The core control-plane component is Istiod. Istiod provides service discovery, configuration management, and certificate management. The official documentation states clearly that Istiod converts high-level routing rules into Envoy-specific configuration and propagates that configuration to sidecars at runtime. At the same time, Istiod abstracts platform-specific service discovery mechanisms into a standard format understood by Envoy and supports workloads on Kubernetes or VMs. (Istio)

Istio's rule model is mainly expressed through Kubernetes CRDs. Istio's traffic management documentation explains that its traffic management API uses Kubernetes custom resource definitions for declarative configuration. Kubernetes official documentation also explains that CRDs are used to define custom resources, while the Kubernetes API provides and stores those custom resources. (Istio)

Rule delivery depends on Envoy's xDS dynamic configuration mechanism. Envoy official documentation collectively refers to dynamic configuration APIs such as LDS, RDS, CDS, and EDS as xDS. In Istio, Istiod acts as the control plane: it converts Kubernetes CRDs, service discovery results, security policies, and other inputs into Envoy configuration, then distributes that configuration to data-plane proxies through xDS. (envoyproxy.io)

3. Design of Istio Routing, Authorization, Circuit-Breaking, and Rate-Limiting Rules

3.1 Routing Rules

Istio's routing capabilities are mainly described by resources such as VirtualService, DestinationRule, Gateway, ServiceEntry, and Sidecar. The official documentation describes VirtualService and DestinationRule as key building blocks for traffic routing. VirtualService defines "how requests are routed to a destination service." DestinationRule defines "what happens to traffic after it reaches the destination," including load balancing, connection pool, TLS, and circuit-breaking policies. (Istio)

VirtualService rules are matched in order, so earlier rules have higher priority. It can match on conditions such as port, header, and URI. Multiple conditions inside the same match block have an AND relationship, while multiple match blocks have an OR relationship. The destination host of a VirtualService must exist in Istio's service registry, or be introduced into the mesh through a ServiceEntry. (Istio)

DestinationRule is used to define subsets and traffic policies for a target service. Subsets are usually distinguished by Kubernetes labels, such as version: v1 and version: v2. The trafficPolicy in a DestinationRule can configure fields such as loadBalancer, connectionPool, and outlierDetection. The official documentation explains that subset policies only take effect after routing rules send traffic to that subset. (Istio)

The Gateway resource describes a load balancer at the mesh edge. It is used to receive inbound or outbound HTTP/TCP connections and configure ports, protocols, SNI, and similar settings. Istio also supports the Kubernetes Gateway API, and its official documentation states that Istio views the Gateway API as the future default API direction for traffic management. (Istio)

3.2 Authorization and Authentication Rules

Istio's security model includes service identity, certificate issuance, mTLS, authentication, authorization, and auditing. The official security documentation explains that Istio's goals include security by default, defense in depth, and zero-trust networks. Istio implements security capabilities through components such as a CA, configuration APIs, sidecar or edge proxies, and Envoy extensions. (Istio)

Service-to-service authentication is mainly controlled by PeerAuthentication. PeerAuthentication defines the mTLS requirements for inbound traffic received by a workload. In sidecar mode, it determines whether mTLS is allowed, required, or disabled. In ambient mode, ztunnel transparently enables security capabilities. The official documentation states that ambient mode does not support DISABLE; if bypassing must be prevented, STRICT should be used. (Istio)

End-user authentication is mainly controlled by RequestAuthentication. The official documentation explains that RequestAuthentication defines request authentication methods and is usually used for JWT. If a request carries invalid credentials, the request is rejected. If it carries no credentials, the request is allowed by default, but AuthorizationPolicy can be used together with it to require authentication. (Istio)

Authorization rules are expressed by AuthorizationPolicy. The official documentation explains that AuthorizationPolicy supports actions such as CUSTOM, DENY, ALLOW, and AUDIT. The execution order is CUSTOM first, then DENY, then ALLOW rules are evaluated to decide whether the request is allowed. AuthorizationPolicy can perform access control based on namespace, workload selector, targetRefs, source, operation, condition, and other dimensions. (Istio)

Istio also supports external authorization. The CUSTOM action in AuthorizationPolicy can delegate authorization decisions to an external authorization system, such as OPA, oauth2-proxy, or a custom authorization service. This mechanism is one of the official paths for enterprises to integrate existing authorization systems with Istio. (Istio)

3.3 Circuit-Breaking Rules

Istio's circuit-breaking capability is mainly implemented through connectionPool and outlierDetection in DestinationRule. The official DestinationRule documentation explains that trafficPolicy can set connection pool size, load balancing policy, and outlier detection. Istio's official circuit-breaking task also explains that circuit breaking can be configured for connections, requests, and outlier detection. (Istio)

From the rule model perspective, Istio's circuit breaking is not SDK-level circuit breaking inside the application. It is proxy-level capability such as connection pooling, request concurrency control, and outlier removal. It is executed by Envoy proxies, so it has low intrusion into application code, but its behavior occurs on the proxy traffic path. (Istio)

3.4 Rate-Limiting Rules

Istio official documentation presents two types of rate limiting: global rate limiting and local rate limiting. The official task documentation explains that Envoy supports both global and local rate limiting. Global rate limiting uses a global gRPC rate-limiting service to enforce limits across the mesh or gateway dimension. Local rate limiting executes inside each service instance's own proxy and does not call an external service. (Istio)

Therefore, Istio rate limiting is not limited to single-node rate limiting, but it also does not come with a complete distributed rate-limiting center by default. The official global rate-limiting example requires an additional gRPC rate-limit service, and the reference implementation uses Go and Redis. Local rate limiting is a token bucket inside each proxy instance. It is important to note that Istio's official rate-limiting task configures native Envoy filters through EnvoyFilter. The official documentation clearly warns that EnvoyFilter exposes internal implementation details and must be used very carefully during upgrades. (Istio)

4. Rule Storage, Rule Delivery, and Service Discovery Mechanisms

Istio rules are usually stored as Kubernetes CRDs, such as VirtualService, DestinationRule, Gateway, ServiceEntry, PeerAuthentication, RequestAuthentication, AuthorizationPolicy, and Telemetry. The Kubernetes API stores these custom resources. Istiod watches the configuration store, converts policy changes into proxy configuration, and asynchronously delivers that configuration to the proxies of target workloads. Istio's security documentation clearly explains that after policies are saved to the Istio configuration store, the controller watches configuration changes, converts policies into PEP configuration, and asynchronously sends the configuration to target endpoints. After the proxy receives the configuration, the policy takes effect immediately on that pod. (Kubernetes)

Here, the "client" is usually not the HTTP client or RPC SDK inside business code, but the data-plane proxy. In sidecar mode, the Envoy proxy next to the business process receives xDS configuration, and business traffic is transparently intercepted to Envoy. In ambient mode, node-level ztunnel and optional waypoint proxies take data-plane responsibility. In proxyless gRPC mode, gRPC workloads that support xDS can directly receive control-plane configuration without going through an Envoy sidecar. (Istio)

Istio service discovery is not a standalone "general-purpose registry product" that replaces all enterprise service registries. The official documentation explains that Istiod abstracts platform-specific service discovery mechanisms into a standard format. A DestinationRule host is looked up from the platform's service registry, such as Kubernetes or Consul, and external services can also be introduced with ServiceEntry. ServiceEntry adds entries to Istio's internal service registry to describe services outside the mesh or internal services that are not part of the platform registry. (Istio)

For non-Kubernetes workloads, Istio uses WorkloadEntry to describe a single VM or bare-metal workload, usually together with ServiceEntry. The official documentation explains that WorkloadEntry is used to describe non-Kubernetes workloads, such as VMs or bare metal. After a workload connects to Istiod, its state is updated in a way similar to Kubernetes pods. ServiceEntry can select both Kubernetes pods and VM workloads, allowing VM-to-Kubernetes migration to keep DNS behavior unchanged. (Istio)

This leads to a technical boundary: Istio is responsible for unifying information from existing platform registries, ServiceEntry, WorkloadEntry, and similar sources into service discovery configuration that the data plane can consume. In Kubernetes scenarios, however, service registration itself mainly comes from platform mechanisms such as Kubernetes Service and Endpoint. In VM scenarios, non-Kubernetes instances must be included in Istio's internal service registry through WorkloadEntry, ServiceEntry, or supporting automation. (Istio)

5. Bare VMs, Existing Gateways, and Enterprise Migration Cost

Istio officially supports VM and bare-metal workloads. The official VM architecture documentation explains that Istio supports onboarding workloads outside Kubernetes clusters into the mesh, allowing legacy or non-containerized workloads to obtain Istio capabilities. WorkloadEntry is also designed to support non-Pod endpoints and handle them in a way similar to Pods, enabling mTLS between containerized and non-containerized workloads. (Istio)

However, judging from the official process, onboarding bare VMs is not equivalent to the automatic sidecar injection experience of Kubernetes Pods. An official Istio blog once explicitly described that adding a single VM to the mesh used to involve many steps, including creating a Kubernetes service account, creating a WorkloadEntry, and generating configuration before workload onboarding. In autoscaling environments, automating this process is more complex, and it usually requires exposing Istiod outside the cluster. (Istio)

Therefore, the factual statement should be: Istio supports VM and bare-metal workloads, but compared with Kubernetes-native workloads, the onboarding process requires more external configuration, identity, bootstrap, and automation work. For enterprises that deploy microservices at large scale on bare VMs, if they do not already have automated registration, certificate bootstrap, configuration distribution, and lifecycle management systems, the cost of adopting Istio will be significantly higher than in Kubernetes Pod scenarios. This conclusion comes from the official VM onboarding mechanism itself, not from a subjective judgment. (Istio)

For enterprises that already have internal gateways, registries, authentication systems, circuit-breaking systems, and rate-limiting systems, migrating to Istio is not as simple as "replacing the gateway with Istio." The reason is that Istio governance rules are expressed as Kubernetes/Istio CRDs, service discovery is abstracted into Istiod and xDS, and the data plane depends on Envoy sidecars, ambient ztunnel/waypoint proxies, or proxyless gRPC. Existing enterprise models for routing, authorization, rate limiting, registration, and discovery must be mapped to resources such as VirtualService, DestinationRule, AuthorizationPolicy, ServiceEntry, WorkloadEntry, EnvoyFilter, and Telemetry, or integrated through mechanisms such as external authorization, custom EnvoyFilter, ServiceEntry, and Gateway API. (Istio)

There are also official case studies that show integration paths with existing gateways. ZOZO's Istio case study explains that it integrated Istio into an existing in-house API Gateway and performed a zero-downtime migration. This case shows that Istio can coexist with existing gateway systems, but it does not mean every enterprise can migrate at low cost, because the case itself also describes a migration and integration process. (Istio)

The cost and operational complexity of sidecar mode are also explicitly discussed in official materials. When Istio introduces sidecar mode, it explains that an Envoy proxy is injected next to every application instance. Istio ambient official materials describe sidecar-mode resource cost and operational overhead as problems that ambient is designed to solve. Istio's official blog on native sidecars also summarizes sidecar lifecycle problems, such as the application starting before the Istio container and therefore having no network available, Istio shutting down before the application and causing the application to lose network connectivity, and the sidecar keeping the Pod running after the application has exited. (Istio)

Istio's official direction for reducing sidecar cost is ambient mesh. Ambient mesh announced GA in November 2024, and its stable components include ztunnel, waypoint, and related APIs. Ambient provides sidecarless security, telemetry, and traffic management capabilities through node-level ztunnel and optional waypoint proxies. Official materials describe its goals as simplifying operations, improving application compatibility, and lowering infrastructure cost. One distinction matters: ambient mainly solves cost and lifecycle problems of sidecar mode in Kubernetes meshes. Bare-VM scenarios still need to handle identity, registration, and proxy onboarding according to the VM onboarding model. (Istio)

6. Istio Observability and OpenTelemetry Support

Istio official documentation explains that Istio generates telemetry data for all service communication inside the mesh, mainly including metrics, distributed traces, and access logs. Istio metrics include service-level metrics, control-plane metrics, and Envoy proxy-level metrics. The official documentation explains that service-level metrics cover dimensions such as latency, traffic, errors, and saturation. Standard metrics are exported to Prometheus by default, but this behavior is configurable. (Istio)

Istio uses the Telemetry API to configure metrics, logs, and tracing. Telemetry resources support workload-level, namespace-level, and root-namespace-level configuration. For gateways and waypoints, policies can also be bound through targetRefs. Telemetry can configure tracing enablement, disablement, sampling rate, and custom tags, and it can also configure metrics providers and metric override rules. (Istio)

Istio supports OpenTelemetry. The official OpenTelemetry task documentation explains that OpenTelemetry is a vendor-neutral standard, and Istio can export OTLP traces through OpenTelemetry Collector, using either gRPC or HTTP. Istio also supports exporting Envoy access logs in OpenTelemetry format to OpenTelemetry Collector. The Istio 1.30 release notes also mention that service attribute enhancements follow OpenTelemetry semantic conventions. (Istio)

Therefore, Istio observability is not implemented by application SDK collection alone. It is generated jointly by the Envoy data plane and Istio Telemetry configuration as unified proxy-layer telemetry data. If the application itself also integrates OpenTelemetry, it can be combined with Istio's proxy-layer tracing and metrics system. (Istio)

7. Enterprise Use Cases and Current Product Status

Istio's official case-study page lists many enterprises and organizations that use Istio, including Airbnb, Splunk, Salesforce, Cash App/Square, Bluecore, Rappi, WP Engine, ZOZO, Figma, GOV.UK, HSBC, Intuit, SAP, Spotify, U.S. Air Force, Walmart, IBM, Yahoo, and Zendesk. (Istio)

In specific cases, Splunk's official case study explains that it uses Istio as a baseline for network ingress, policy, and authentication, across more than 40 clusters in multiple regions and cloud providers. Salesforce's case study explains that Envoy and Kubernetes are the foundational building blocks of Salesforce Service Mesh, and that Salesforce later moved to Istio. Rappi's case study explains that it runs more than 50 Kubernetes clusters, 30,000 containers, and 1,500 developers, and uses Istio around capabilities such as custom rate limiting, circuit breaking, connection pools, and timeouts. (Istio)

In terms of current status, Istio is already a CNCF Graduated project. Istio's official release page shows that Istio 1.30.0 was released on May 18, 2026 and supports Kubernetes 1.32 to 1.36. Istio 1.30 release notes include Gateway API/TLSRoute improvements, ambient feature enhancements, experimental agentgateway for AI agent/MCP traffic, multiple CUSTOM auth providers, Telemetry alignment with OpenTelemetry semantic conventions, and the TrafficExtension API replacing WasmPlugin as the primary extension path. (CNCF)

Istio currently has three clear product directions. First, the traditional sidecar mesh remains mature and widely used. Second, ambient mesh is GA and is used to reduce the resource and operational burden brought by sidecars. Third, Istio is enhancing Gateway API, OpenTelemetry, AI agent/MCP traffic governance, extension APIs, and related areas. (Istio)

8. Factual Conclusions

Istio's product positioning is service mesh, not simply an API gateway, registry, SDK circuit breaker, or rate-limiting middleware. Through the Envoy data plane, Istiod control plane, Kubernetes CRDs, and xDS dynamic configuration, it unifies routing, security, observability, and part of resilience governance into the service communication path. (Istio)

Istio's routing, authentication, circuit-breaking, and rate-limiting capabilities are not expressed at the same abstraction layer. Routing is mainly expressed by resources such as VirtualService, DestinationRule, Gateway, and ServiceEntry. Authentication and authorization are expressed by PeerAuthentication, RequestAuthentication, and AuthorizationPolicy. Circuit breaking is mainly expressed through connection pools and outlier detection in DestinationRule. Rate limiting mainly depends on Envoy local or global rate-limiting capabilities. Official examples use EnvoyFilter to connect Envoy rate-limiting filters, so upgrades and production use require extra caution. (Istio)

Istio service discovery and service registration are not a completely self-contained registry suite. Istio consumes platform registries such as Kubernetes and Consul, and can also include external services, VMs, or bare-metal workloads in Istio's internal service registry through ServiceEntry and WorkloadEntry. In other words, Istio is closer to a "service discovery aggregation and proxy configuration control plane" than a general-purpose registry that replaces all existing enterprise registries. (Istio)

For large enterprises that already have internal gateways, registries, authentication systems, circuit-breaking systems, and rate-limiting systems, the cost of adopting Istio objectively exists. Cost sources include: governance rules need to be migrated to Istio CRDs or integrated with Istio; service discovery needs to connect to Kubernetes, ServiceEntry, WorkloadEntry, or existing registries; security capabilities require introducing Istio identity, certificates, and mTLS; sidecar mode adds proxy containers, resource consumption, lifecycle complexity, and troubleshooting complexity; and VM or bare-metal workloads require additional bootstrap and automation. Istio's official mitigation paths include external authorization, ServiceEntry/WorkloadEntry, Gateway API, configuration scoping, VM onboarding processes, proxyless gRPC, and ambient mesh. (Istio)

Based on official materials, the most accurate conclusion is: Istio is suitable for cloud-native systems that need unified service-to-service security, traffic governance, and observability. For platforms centered on Kubernetes, its capability loop is the most complete. For enterprises with many bare VMs and mature internal gateways and registries, it is not a "zero-cost replacement." A more realistic adoption method is phased coexistence, partial onboarding, gateway-side adoption first, service discovery bridging, external authorization integration, and evaluating the reduction of sidecar cost through ambient mesh in Kubernetes workloads.

Chinese Reference

• Read the original Chinese article