--- title: "Istio Service Mesh" source: "https://www.tigera.io/learn/guides/istio/istio-service-mesh/" description: "Istio is an open-source service mesh that provides a way to control how microservices share data with one another. It is designed to manage, secure, and observe service-to-service communication without requiring changes to application code." --- ## Guides: Istio Service Mesh # Istio Service Mesh: Architecture, Traffic Flow, and Operational Challenges - [Istio](https://www.tigera.io/learn/guides/istio/) - [Istio Network Policy](https://www.tigera.io/learn/guides/istio/istio-network-policy/) - [Istio Gateway](https://www.tigera.io/learn/guides/istio/istio-gateway/) - [Istio Dashboard](https://www.tigera.io/learn/guides/istio/istio-dashboard/) - [Istio vs Linkerd](https://www.tigera.io/learn/guides/istio/istio-vs-linkerd/) - [Istio Multi Cluster](https://www.tigera.io/learn/guides/istio/istio-multi-cluster/) - [Istio Kubernetes](https://www.tigera.io/learn/guides/istio/istio-kubernetes/) - [Istio Proxy](https://www.tigera.io/learn/guides/istio/istio-proxy/) - [Istio Security](https://www.tigera.io/learn/guides/istio/istio-security/) - [Istio Service Mesh](https://www.tigera.io/learn/guides/istio/istio-service-mesh/) - [Istio Ingress](https://www.tigera.io/learn/guides/istio/istio-ingress/) - [Istio Ambient](https://www.tigera.io/learn/guides/istio/istio-ambient/) ## What Is Istio Service Mesh? [Istio](https://www.tigera.io/learn/guides/istio/) is an open-source service mesh that provides a way to control how microservices share data with one another. It is designed to manage, secure, and observe service-to-service communication without requiring changes to application code. Istio uses a sidecar proxy model, typically deployed with Envoy, which intercepts all network traffic between microservices. This allows Istio to offer key features like traffic routing, load balancing, failure recovery, and fine-grained observability. It also supports policy enforcement and service identity and authentication using mutual TLS. Istio integrates with Kubernetes but can also run in other environments. It helps platform teams reduce operational complexity, improve security, and gain visibility across distributed applications. **In this article:** - Benefits of Using Istio Service Mesh - Key Features of Istio Service Mesh - Istio Architecture Explained - Istio Service Mesh Workflow - How Does Istio Handle Service-to-Service Traffic? - Challenges of Operating Istio Service Mesh - Istio Service Mesh Alternatives ## Benefits of Using Istio Service Mesh Istio provides a unified way to secure, monitor, and manage service-to-service communication, especially in Kubernetes environments. Its architecture enables organizations to adopt zero-trust networking principles, gain deep visibility into service behavior, and enforce consistent policies across large, distributed applications. Key benefits include: - **Zero-trust security for inter-service communication**: Istio enforces strict identity-based authentication and encrypted communication between services, ensuring that only verified workloads can exchange data. - **mTLS and identity-based communication**: Mutual TLS is enabled by default, with automated certificate issuance and rotation. This allows services to authenticate each other using strong cryptographic identities rather than relying on network boundaries. - **Advanced traffic shaping and resiliency**: Istio allows precise control over traffic flows using rules for retries, failovers, circuit breakers, and staged deployments (e.g., canary releases and traffic mirroring). - **Uniform telemetry and observability**: The sidecar model collects metrics, logs, and traces consistently across all services without requiring code changes, supporting system-wide observability with tools like Prometheus and Jaeger. - **Policy enforcement across services**: Istio enables centralized enforcement of access control, rate limiting, and usage quotas using Kubernetes-native resources and external authorization providers. - **Better control over east-west traffic**: Through sidecars or ambient proxies, Istio gives operators full visibility and control over internal service communication across namespaces, zones, or clusters. ## Key Features of Istio Service Mesh Istio provides a rich set of features that support secure, reliable, and observable service-to-service communication in modern microservice architectures. These capabilities are built on a modular architecture that separates concerns and simplifies service management across environments. Key features include: - **Traffic routing and control**: Istio allows fine-grained control of traffic with routing rules based on headers, weights, and other attributes. This supports use cases like canary deployments, traffic mirroring, and staged rollouts. - **Secure communication**: Istio enables mutual TLS for service-to-service authentication and encryption by default, helping ensure that only trusted workloads can communicate. - **Policy enforcement**: Administrators can define rules for access control, rate limiting, and quotas using external policy engines or built-in configurations. - **Telemetry and observability**: Istio automatically collects metrics, logs, and traces without code changes. This includes request-level metrics, service dependencies, and latency tracking. - **Fault injection and resilience**: Developers can test failure scenarios using fault injection and improve system stability with features like retries, timeouts, and circuit breakers. - **Multi-cluster and multi-network support**: Istio can span multiple Kubernetes clusters or connect workloads across different network topologies, offering a unified mesh. ## Istio Architecture Explained Let’s review the key components of the Istio architecture. ### Data Plane The Istio data plane is composed primarily of Envoy proxies deployed as sidecars alongside application workloads. These sidecars intercept and manage all inbound and outbound traffic to the service, operating at the L4 and L7 layers of the network stack. The sidecar proxies enforce routing rules, handle retries and timeouts, collect telemetry data, and perform security functions such as mTLS termination and policy enforcement. In ambient mode, the data plane can also use a node-level “zTunnel” and waypoint proxies to handle traffic without injecting sidecars into each pod. This reduces resource usage and simplifies proxy lifecycle management while maintaining traffic control and observability features. ### Control Plane The Istio control plane is responsible for managing configuration, security policies, and service discovery information, and distributing these to the proxies. The main component of the control plane is Istiod, which consolidates several earlier components including Pilot, Citadel, and Galley. Istiod configures Envoy proxies through xDS APIs, distributes security credentials such as certificates for mTLS, and validates configuration for consistency. It also monitors the mesh state and helps ensure high availability and responsiveness through push-based updates. ### How xDS Configuration Is Delivered Istio uses the Envoy xDS (Discovery Service) APIs to dynamically configure the sidecar proxies. Istiod acts as the xDS control server, pushing route, cluster, endpoint, and listener configurations to proxies as services are added, removed, or updated. The xDS protocol supports incremental updates, reducing overhead and latency compared to full configuration reloads. This enables rapid propagation of routing changes, policy updates, and service discovery data across the mesh. ### Service Discovery Integrations Istio integrates tightly with Kubernetes for service discovery, automatically detecting services, endpoints, and labels. It maps Kubernetes services and pods to its internal service registry and uses this to configure proxy routing and load balancing. Outside of Kubernetes, Istio can integrate with other registries like Consul or static service entries for non-Kubernetes workloads. These integrations allow Istio to form a consistent mesh across heterogeneous environments. ### How Istio Interacts with the Underlying Network Layer Istio proxies operate at the network and application layers, intercepting TCP and HTTP traffic through iptables (in sidecar mode) or eBPF and routing layers (in ambient mode). In Kubernetes, these hooks are applied via init containers or CNI plugins to capture traffic at the pod level. At this layer, Istio enforces security policies, applies routing rules, and logs traffic metadata. It also handles protocol-specific functions like HTTP header manipulation, connection pooling, and TLS termination, bridging the network and application concerns. ## Istio Service Mesh Workflow Here are the key steps involved in Istio service mesh processing of network traffic. ### 1. Request Interception Istio intercepts requests using Envoy sidecar proxies injected into application pods. These proxies capture all inbound and outbound traffic by rerouting packets through iptables rules configured during pod startup. The interception is transparent to the application and enables Istio to enforce policies, collect telemetry, and apply routing logic without code changes. In ambient mode, interception happens at the node level using a zTunnel proxy, eliminating the need for sidecars and reducing overhead in large deployments. ### 2. Traffic Routing Rules Istio applies traffic routing rules defined in Kubernetes custom resources like VirtualService and DestinationRule. These rules allow fine-grained control over how traffic is directed based on request attributes such as path, headers, or source identity. Operators can define routing logic for use cases like canary deployments, version-based routing, traffic mirroring, and header-based sharding. The control plane translates these rules into xDS configurations and pushes them to the appropriate proxies. ### 3. Retries and Circuit Breaking Envoy proxies enforce resiliency policies such as retries, timeouts, and circuit breaking using configurations derived from Istio resources. Retries can be configured with limits and backoff policies, enabling services to automatically recover from transient failures. Circuit breakers monitor upstream health and prevent cascading failures by ejecting unresponsive or slow endpoints based on thresholds for errors, timeouts, or outlier detection. These policies improve fault tolerance and system stability without requiring application-level logic. ### 4. Load Balancing Istio supports multiple load balancing strategies, including round robin, random, and least requests. These are defined via DestinationRule and can be tailored per service or endpoint subset. Envoy also performs locality-aware load balancing to prioritize endpoints in the same zone or region. Endpoint health status, outlier detection, and connection metrics are factored into load balancing decisions to ensure efficient and resilient request distribution. ### 5. Telemetry Generation Envoy proxies automatically generate metrics, logs, and tracing data for all proxied traffic. These telemetry signals are emitted in a consistent format and exported to tools like Prometheus, Grafana, Jaeger, or Fluent Bit. Metrics cover request counts, response codes, latencies, and resource usage. Tracing data includes span context and timing for distributed requests, enabling visualization of end-to-end call graphs. Logs can be enriched with request metadata for audit and debugging. ### 6. Security/Auth Flows Istio secures service communication using mutual TLS, issued and managed by Istiod. When two services communicate, their sidecar proxies authenticate each other using their X.509 certificates. Upon successful identity verification, traffic is encrypted in transit. Istio also supports authorization policies to restrict access based on source identity, request attributes, or paths. JWT validation and integration with external identity providers enable flexible, identity-based access control and federation across trust domains. ## How Does Istio Handle Service-to-Service Traffic? ### East-West Traffic Flow Path East-west traffic in Istio refers to communication between services within the same mesh, typically across pods or namespaces. In sidecar mode, this traffic is intercepted by the source and destination Envoy proxies, which apply routing rules, mTLS encryption, and telemetry collection. The source proxy forwards the request according to service discovery data and destination rules, while the destination proxy terminates the mTLS session and delivers the request to the local service. In ambient mode, traffic is redirected to a zTunnel proxy at the node level and then passed through a waypoint proxy if policy enforcement or mTLS is required. This model allows Istio to manage east-west traffic without deploying a proxy alongside every service. ### Sidecar Interception In sidecar mode, Istio uses iptables rules to redirect all ingress and egress traffic from the application container to the Envoy proxy. This ensures that the proxy can inspect, route, and secure all service-to-service communication. The interception is transparent to the application, which continues to bind to local interfaces as usual. This model enables centralized enforcement of traffic policies and observability without requiring developers to modify application logic or network configurations. ### mTLS Handshake and Certificate Rotation Istio automates mutual TLS between services using workload identities and short-lived X.509 certificates. Istiod acts as the certificate authority, issuing and rotating certificates for each service proxy. During the mTLS handshake, the Envoy proxies exchange certificates to authenticate each other, then establish an encrypted channel for communication. Certificate rotation happens automatically before expiration, typically every 24 hours, ensuring secure and up-to-date credentials without manual intervention. ### Identity-Based Routing Istio supports routing decisions based on the identity of the source workload, extracted from the mTLS certificate presented during the connection. This allows policies and traffic rules to target specific service accounts, namespaces, or trust domains, enabling fine-grained control over service behavior. For example, traffic from a service in one namespace can be routed to a different version of a backend based on its authenticated identity, enabling scenarios like team-based routing or tenant isolation. ### Policy Checks Before forwarding a request, Istio evaluates any applicable authorization and rate-limiting policies. These are defined using AuthorizationPolicy and RateLimit configurations and enforced at the proxy level. Policy decisions can be based on source identity, request headers, paths, or methods. Istio applies these checks locally at the proxy to minimize latency and ensure consistency, even under high load. Violations result in immediate rejection of the request with appropriate error codes. ### Traffic Logging and Measurement Envoy proxies automatically emit detailed metrics, logs, and distributed tracing spans for all traffic they handle. Metrics include request counts, latencies, response codes, and TCP connection stats. Logs can include full request and response metadata for auditing or debugging. Tracing spans are propagated using headers like x-request-id and b3, and integrated with tracing systems such as Jaeger or Zipkin. This allows developers and operators to track request flows across services and identify latency bottlenecks or failures. ### Tips from the Expert In my experience, here are tips that can help you better operate and scale Istio service mesh in production: #### Use ambient mode to reduce sidecar overhead: Istio’s ambient mode (in preview or beta in newer versions) allows traffic management without sidecar injection, using node-level and waypoint proxies instead. This cuts resource consumption and simplifies operations in large clusters. #### Run multiple control planes for high availability: In multi-cluster or large-scale environments, deploy multiple Istiod instances across availability zones or clusters. Use east-west gateways for inter-cluster communication and failover, reducing single points of control failure. #### Apply per-service mTLS mode gradually: Avoid cluster-wide mTLS flips during rollout. Use PeerAuthentication policies to incrementally enable mTLS per namespace or workload, allowing staged rollout and faster troubleshooting in case of certificate or policy misconfiguration. #### Use DestinationRule outlier detection to auto-eject bad endpoints: Enable Envoy’s outlier detection to automatically remove failing instances from load balancing pools based on HTTP failure codes or timeouts. This improves resiliency without requiring app-level health probes. #### Segment meshes by trust domain for cross-org or multi-team boundaries: If operating Istio in a multi-tenant or multi-org setup, use trust domain aliases and federation to separate workloads cryptographically. This limits blast radius and enforces strict identity validation between mesh partitions. ![Profile Picture](https://www.tigera.io/app/uploads/2026/04/Dillon-Barry-150x150.jpeg) #### Dillon Barry Technical Marketing Engineer (TME) Dillon Barry is a Technical Marketing Engineer at Tigera. He has worked with Kubernetes and Cloud Native technologies for over 8 years at some of the largest and most forward thinking companies in the industry. Based in Ireland, Dillon has a wealth of experience across different roles and industries as a consultant and solutions architect, with a background at companies like Pivotal and VMware. Dillon has a Bachelor's degree in Computer Science and an interest in everything modern computing. ## Challenges of Operating Istio Service Mesh While Istio offers robust features for securing and managing microservices, it introduces a number of operational challenges that teams must address for successful production use: - **Operational complexity:** Istio adds several layers to the application stack, including the control plane, sidecar proxies, CRDs, and policy engines. Managing these components requires deep understanding of service mesh behavior and Kubernetes internals. Configuration errors or version mismatches can lead to unexpected routing, degraded performance, or security gaps. - **Increased resource consumption:** Each sidecar proxy consumes CPU and memory, which multiplies across services and scales with the number of pods. In large clusters, this can significantly increase infrastructure costs and lead to resource contention, especially for memory-bound workloads. - **Debugging issues across sidecars:** Traffic flows are no longer direct between services; instead, they pass through multiple proxies. This makes it harder to trace issues, especially when latency or failures are introduced by proxy configuration, routing logic, or policy enforcement. Troubleshooting often requires logs and metrics from multiple layers. - **Limited visibility into underlying network flows**: Istio abstracts service communication, but this abstraction can hide low-level network behavior such as packet drops, DNS issues, or node-level bottlenecks. Without integrating with CNI or network monitoring tools, operators may miss critical root causes of service degradation. - **Multi-tenant and multi-cluster challenges:** Operating Istio across multiple clusters or in multi-tenant environments involves managing separate control planes, synchronizing trust domains, and configuring gateways for east-west traffic. Each layer adds operational burden and increases the risk of misconfiguration or downtime. - **Hard to manage mesh-wide policies across large environments:** As service count grows, so does the number of routing rules, security policies, and destination configurations. Keeping these consistent and auditable across environments is difficult without strong automation, version control, and policy testing. - **Difficulty isolating traffic or enforcing zero-trust rules without strong underlying CNI:** Istio assumes the CNI layer correctly isolates workloads and enforces network segmentation. Without a secure, policy-aware CNI, service-to-service communication can still be exploited despite mTLS. Fine-grained control often requires integration with tools like Calico or Cilium. - **Limited ability to observe pod-level or network-level compromises:** Istio focuses on service-level telemetry and doesn’t provide native insight into pod compromises, sidecar tampering, or node-level attacks. Detecting lateral movement or intrusion attempts requires supplemental observability and security tooling at the host or container runtime level. - **Managing encryption overhead and certificate rotation:** mTLS improves security but adds CPU overhead due to encryption and decryption. Large volumes of short-lived connections can tax proxies, and certificate mismanagement can lead to outages. Proper tuning and alerting around certificate expiry and proxy resource usage are essential for stable operations. ## Istio Service Mesh Alternatives ### 1. Calico Cluster Mesh ![Calico Logo](https://www.tigera.io/app/uploads/2026/01/Calico-logo-2026-black-text.svg) Calico enables a single-pane-of-glass unified control to address the three most popular service mesh use cases—security, observability, and control—with an operationally simpler approach, while avoiding the complexities associated with deploying a separate, standalone service mesh. With Calico, you can easily achieve full-stack observability and security, deploy highly performant encryption, and tightly integrate with existing security infrastructure like firewalls. **License:** Commercial **Key features include:** - **Encryption for data in transit –** Calico leverages the latest in crypto technology, using open-source WireGuard. As a result, Calico’s encryption is highly performant while still allowing visibility into all traffic flows. - **Dynamic Service and Threat Graph –** Kubernetes-native visualization of all collected data that allows the user to visualize communication flows across services and team spaces, to facilitate troubleshooting. - **Operational simplicity with Envoy integrated into the data plane –** Calico provides observability, traffic flow management, and control by deploying a single instance of Envoy as a daemon set on each node of your cluster, instead of a sidecar approach, thus making it more resource efficient and cost effective. - **Zero-trust workload access controls –** Integrate with firewalls or other kinds of controls where you might want to understand the origin of egress traffic. Identify the origin of egress traffic, to the point where you have visibility into the specific application or namespace from which egress traffic seen outside the cluster came. ![Calico dashboard](https://www.tigera.io/app/uploads/2026/08/Calico-dashboard-view.png) Source: [Tigera](https://www.tigera.io/app/uploads/2022/09/service-graph-06.png) ### 2. Linkerd ![Linkerd logo](https://miro.medium.com/v2/1*ucVyafNXDIRbJKbHClK4hw.png) Linkerd is a lightweight, open-source service mesh designed specifically for Kubernetes. It simplifies the operation and security of microservices by automatically managing traffic between services through ultralight, transparent proxies. These proxies are written in Rust and injected alongside services to handle network traffic without requiring changes to application code. **Key features include:** - **Automatic mTLS:** All traffic between services is encrypted and authenticated by default using mutual TLS - **Protocol support:** Full support for HTTP, HTTP/2, gRPC, and TCP proxying with automatic protocol detection - **Observability:** Built-in metrics collection, CLI tools, dashboards, and support for distributed tracing - **Traffic control:** Supports retries, timeouts, dynamic request routing, and fault injection for robust traffic management - **Ingress and egress:** Works with any ingress controller and offers egress traffic monitoring and policy enforcement ![Linkerd screenshot](https://linkerd.io/2018/09/18/announcing-linkerd-2-0/cover.png) Source: [Linkerd](https://linkerd.io/2018/09/18/announcing-linkerd-2-0/cover.png) ### 3. Kong Mesh ![Kong Mesh logo](https://kong.github.io/kong-mesh-charts/artifacts/kong-mesh.png) Kong Mesh is a service mesh that supports both Kubernetes and traditional virtual machine environments, making it suitable for hybrid and multi-cloud architectures. It simplifies secure, observable, and resilient service-to-service communication using sidecar proxies and a centralized control plane. Kong Mesh enforces policies for traffic routing, access control, and reliability without requiring changes to application code. **Key features include:** - **Built-in mTLS:** Automatically encrypts service-to-service traffic and assigns identities to each data plane proxy - **Multi-zone deployment:** Run service meshes across multiple clusters, regions, or environments with a single control plane - **Multi-tenant support:** Operate multiple isolated meshes within the same infrastructure for better separation of concerns - **Traffic control:** Fine-grained policies for L4/L7 routing, mutual TLS enforcement, and access permissions - **Service reliability:** Built-in features like health checks, retries, circuit breakers, timeouts, and outlier detection ![Kong Mesh screenshot](https://assets.prd.mktg.konghq.com/images/2023/10/6520962a-ui-mesh-manager-overview-20230927.png) Source: [Kong Mesh](https://assets.prd.mktg.konghq.com/images/2023/10/6520962a-ui-mesh-manager-overview-20230927.png) ### 4. HashiCorp Consul ![HashiCorp Consul logo](https://hashiqube.com/consul/images/consul-logo.png) HashiCorp Consul is a service networking platform to manage secure service-to-service communication across Kubernetes, virtual machines, and multi-cloud environments. It offers a centralized service registry, a control plane for service discovery and configuration, and an optional service mesh enabled by sidecar proxies. **Key features include:** - **Service discovery:** Automatically registers and locates healthy services using a centralized catalog accessible via DNS or API - **Multi-environment support:** Works across Kubernetes, VMs, bare metal, and multi-cloud regions for consistent service networking - **Service mesh capabilities:** Enables encrypted communication, access control, and traffic routing using sidecar proxies - **Zero-trust security:** Enforces mutual TLS, ACLs, and service intentions to authenticate, authorize, and encrypt service communication - **Infrastructure automation:** Integrates with Consul-Terraform-Sync to dynamically update firewalls, load balancers, and network devices ![HashiCorp Consul screenshot](https://www.datocms-assets.com/2885/1529713598-intentionsui.png) Source: [HashiCorp](https://www.datocms-assets.com/2885/1529713598-intentionsui.png) ### 5. Traefik Mesh ![Traefik Mesh logo](https://images.g2crowd.com/uploads/product/image/social_landscape/social_landscape_a40af2b66009dc040d58bb84f026ac64/traefik-mesh.png) Traefik Mesh is a lightweight service mesh for Kubernetes environments. Built on top of the Traefik Proxy, it simplifies service-to-service communication by enabling traffic management, observability, and security without the complexity of sidecar injection. Traefik Mesh routes and monitors internal traffic in a cluster, helping teams optimize performance and enforce access controls. **Key features include:** - **Non-invasive architecture:** Operates without sidecars or pod injection, reducing resource overhead and simplifying operations - **Simple installation:** One-line install delivers a functional mesh with minimal setup - **Traffic management:** Supports weighted load balancing, canary deployments, retries, failovers, circuit breakers, and rate limiting - **Observability:** Integrated with Prometheus and Grafana; supports OpenTracing for distributed tracing - **Protocol support:** Handles HTTP, HTTP/2, gRPC, WebSockets, and raw TCP traffic ![Traefik Mesh screenshot](https://doc.traefik.io/traefik-enterprise/assets/img/dashboard-overview.png) Source: [Traefik](https://doc.traefik.io/traefik-enterprise/assets/img/dashboard-overview.png) ## Strengthening Istio: How Tigera Calico Enhances Service Mesh Security and Visibility While Istio provides an exceptional application-layer service mesh, a production-grade **microservices architecture** requires security and observability that extend deeper into the network. **Calico** provides the high-performance foundation and defense-in-depth required to turn a service mesh into a complete zero-trust environment. ### Strengthening the Zero-Trust Foundation By utilizing Calico alongside Istio, organizations move beyond simple service-to-service encryption toward a comprehensive security model: - **Unified Policy Enforcement:** Calico enables platform teams to write security policies that apply to both the network layer (IPs, ports, protocols) and the service mesh layer. This ensures that even if a high-level proxy is bypassed or misconfigured, your **east-west** traffic is still protected by kernel-level enforcement. - **Sidecarless Efficiency with Ambient Mode:** Calico is natively engineered to support **Istio Ambient Mode**. By moving away from the “sidecar tax,” Calico helps you achieve mTLS and L7 control with less overhead, leveraging a high-performance data plane that simplifies the operational complexity of the mesh. - **High-Performance Load Balancing:** Calico’s **eBPF data plane** provides ultra-fast **load balancing** and routing. This ensures that packets reach their destination with minimum latency, optimizing the underlying fabric before traffic even reaches the Istio proxies. - **Granular Egress Control:** While Istio manages traffic inside the mesh, Calico provides granular control over traffic leaving the cluster. You can enforce DNS-based policies to ensure workloads only communicate with approved external APIs or databases, preventing data exfiltration at the network perimeter. ### Full-Stack Observability from Layer 3 to Layer 7 The combination of Calico and Istio provides a single pane of glass for troubleshooting. While Istio provides application-level traces, Calico provides the flow logs and raw network data needed to identify whether a performance bottleneck is occurring within the application code or the underlying Kubernetes network fabric. With Tigera’s management console, you gain a holistic view of every connection. This allows you to audit security posture and tune performance using a complete dataset—from the kernel up to the application layer. **Next steps:** To see how Calico and Istio work together to secure modern environments, explore these resources: - **Sidecarless Mesh:** Read [An In-Depth Look at Istio Ambient Mode with Calico](https://www.tigera.io/blog/an-in-depth-look-at-istio-ambient-mode-with-calico/) to learn how to eliminate the sidecar tax. - **Innovation at the Edge:** Check out the [Tigera News from KubeCon 2025](https://www.tigera.io/blog/tigera-news-kubecon-2025/) to see how **Calico** is simplifying service mesh troubleshooting. - **eBPF Integration:** Discover how [Service Mesh with eBPF](https://www.tigera.io/learn/guides/ebpf/ebpf-service-mesh/) provides a more secure and performant data plane for your microservices.