Tigera Logo

Guides: Istio Proxy

Istio Envoy Proxy: How It Works, Pros/Cons, and Best Practices

What Is the Istio Envoy Proxy?

The Istio Proxy is a data plane proxy, built on the Envoy proxy, that handles network traffic for services in a mesh. It is deployed as a sidecar container in each application pod, or as a node-level proxy in ambient mode. The Istio proxy enables features like traffic management, security through mutual TLS, and observability through rich metrics and logging for all services.

How it works:

  • Traffic interception: The Istio proxy intercepts all network traffic to and from the application’s container.
  • Proxy deployment: The proxy is deployed as a sidecar in the same pod as the application. In “ambient mode,” the proxy is deployed on the node level as a DaemonSet.
  • Control plane communication: The proxy communicates with the Istio control plane, specifically istiod, to receive configuration and updates.
  • Traffic management: The proxy enforces traffic rules defined by the user, such as routing, retries, timeouts, and circuit breaking.
  • Security: The proxy enables secure service-to-service communication using mutual TLS (mTLS) and enforces access control policies.
  • Observability: The proxy collects detailed telemetry on all network traffic, which can be used for monitoring and tracing.

In this article:

Traditional K8s Networking with CNI vs. Service Mesh: What Is the Difference?

Traditional networking in Kubernetes relies on the container network interface (CNI) to handle connectivity between pods. CNIs like Calico, Cilium, or Flannel provide IP address management and routing at layers 3 and 4 (IP and TCP/UDP). They focus on basic connectivity, NAT rules, and network policies for access control but do not manage higher-level behaviors like retries, failover, or observability.

CNI plugins are foundational for pod-to-pod communication but are not aware of application-level protocols. For example, a CNI can block or allow traffic between services but cannot enforce HTTP-level routing rules or retry failed requests based on status codes.

Service meshes operate at a higher level in the stack, focusing on application-layer (L7) concerns. Istio, using the Envoy proxy, provides traffic routing, security (e.g., mTLS), retries, timeouts, observability, and policy enforcement. It overlays the existing network and works in coordination with CNI but does not replace it.

The Role of Envoy in Istio’s Data Plane

In Istio, Envoy proxies form the core of the data plane. Each application instance in the mesh is paired with an Envoy sidecar proxy. These proxies intercept all inbound and outbound traffic to and from the service, allowing Istio to control and observe communication without modifying application code.

Envoy sidecars enforce traffic policies defined by the Istio control plane. These policies include routing rules, retries, timeouts, and fault injection. Envoy also handles service discovery, automatically updating its routing table based on changes in the mesh.

For security, Envoy manages mutual TLS connections between services. It handles certificate management and enforces authentication and authorization policies. This ensures encrypted communication and consistent identity verification across the mesh.

Envoy collects telemetry data such as request logs, metrics, and traces and exports it to observability tools. By offloading these responsibilities to Envoy, Istio decouples operational concerns from application logic and standardizes behavior across services.

Benefits of Using Envoy

Envoy plays a central role in Istio’s data plane by handling all network traffic between services. By operating at the application layer, it enables advanced traffic control, built-in security, and deep observability—without requiring changes to application code. Key benefits include:

  • Layer-7 Traffic Management:Envoy operates at the application layer (L7), enabling fine-grained control over HTTP and gRPC traffic. It supports advanced routing strategies, including traffic splitting, retries, failover, canary releases, and blue-green deployments. Developers can define rules for fault injection, circuit breaking, and timeout handling without modifying application code.
  • Secure Service-to-Service Communication with mTLS: Envoy handles mutual TLS (mTLS) for all service-to-service traffic, providing encryption in transit and identity-based authentication. It automates certificate management, including rotation and revocation, and enforces authorization policies at the proxy level to ensure consistent, secure communication.
  • Built-In Observability: Envoy generates metrics, logs, and distributed traces for all traffic passing through it. This includes latency, error rates, request volumes, and success/failure ratios. These signals feed into observability tools like Prometheus, Grafana, and Jaeger, giving operators service-level visibility without manual instrumentation.
  • Separation of Concerns: By shifting traffic management, security, and observability responsibilities to the proxy, Envoy decouples networking logic from application code. This allows developers to focus on core business logic while platform teams manage policies and behavior consistently across environments.
  • Support for Complex Environments: Envoy supports heterogeneous environments, including hybrid and multi-cluster Kubernetes, on-prem and cloud workloads, and legacy applications. It enables consistent traffic control and policy enforcement across diverse deployment models, making it suitable for gradual modernization and complex microservice topologies.

How Istio Envoy Proxy Works

Traffic Interception

Envoy intercepts traffic using a technique called transparent proxying. When a pod is started, Istio injects an Envoy sidecar and sets up iptables rules to redirect all ingress and egress TCP traffic through the proxy. This redirection is done at the kernel level, ensuring that the application remains unaware of the proxy’s presence.

Inbound traffic destined for the application is routed to Envoy first, which applies policies like authentication and rate limiting before passing it to the application container. Similarly, outbound traffic from the application is captured and routed through Envoy, where routing rules and security checks are enforced before the request leaves the pod. This mechanism works without requiring any modification to application code or configuration.

Proxy Deployment

The deployment of Envoy as a sidecar is handled automatically by Istio’s sidecar injector webhook. When a pod is created in a namespace with Istio injection enabled, the webhook modifies the pod’s spec to include an additional container running Envoy, as well as necessary initialization containers and environment variables.

This sidecar proxy runs in the same pod and network namespace as the application container. It shares the loopback interface, allowing it to proxy traffic without altering service DNS resolution or client configurations. Envoy configuration is mounted via volumes and kept up-to-date through the xDS protocol.

Control Plane Communication

Envoy proxies communicate with the Istio control plane via the xDS (Extensible Discovery Service) APIs. Istiod acts as the control plane component and serves various xDS services like LDS (Listener Discovery Service), CDS (Cluster Discovery Service), RDS (Route Discovery Service), and SDS (Secret Discovery Service).

These APIs allow Istiod to dynamically configure Envoy’s listeners, clusters, routes, and TLS settings. When configuration in the mesh changes, such as updates to traffic policies, service endpoints, or certificates, Istiod pushes updates to the affected Envoy proxies in real time.

Traffic Management

Envoy applies Istio-defined traffic policies that control how requests are routed between services. These include:

  • Routing rules: Direct traffic based on headers, URIs, or other attributes
  • Weighted routing: Split traffic between multiple versions of a service for canary deployments or A/B testing
  • Timeouts and retries: Automatically retry failed requests or fail fast after a timeout
  • Fault injection: Simulate delays or failures for resilience testing
  • Circuit breakers: Prevent cascading failures by limiting the number of concurrent connections or pending requests

These policies are configured using custom Istio resources like VirtualService, DestinationRule, and ServiceEntry, and enforced at the Envoy level for each request.

Security

Security is a key role of the Envoy proxy in Istio. Envoy establishes mutual TLS connections between services by handling certificate negotiation and verification. Certificates are issued and rotated automatically by Istiod, using either Istio’s built-in CA or an external provider.

Envoy enforces authentication policies defined by PeerAuthentication and RequestAuthentication resources. It also applies authorization rules via AuthorizationPolicy, which control access based on identities, source/destination, and request attributes.

Observability

Envoy generates rich telemetry data for all traffic that passes through it. This includes:

  • Metrics: Request counts, latencies, error rates, and resource usage, exported via Prometheus endpoints
  • Logs: Access logs with request and response details
  • Traces: Distributed tracing information via Zipkin, Jaeger, or OpenTelemetry, using B3 or W3C trace context propagation

These telemetry outputs are integrated with Istio’s telemetry stack and can be customized using Telemetry and EnvoyFilter resources.

Tips from the Expert

In my experience, here are tips that can help you better manage and optimize Istio’s Envoy proxy across diverse Kubernetes environments:

  1. Pin Envoy versions during upgrades to avoid incompatibility with custom filters:

    When using EnvoyFilter CRDs or Wasm modules, even minor Envoy upgrades can break behavior. Explicitly set the Envoy image tag in the IstioOperator manifest during upgrades to test compatibility before promoting cluster-wide changes.

  2. Use Envoy’s tap filter for live traffic debugging in production:

    Deploy the envoy.filters.http.tap filter selectively for short periods to inspect live requests/responses without full tracing overhead. It's ideal for debugging authentication issues or malformed headers in production.

  3. Pre-warm Envoy clusters to prevent cold-start connection delays:

    Envoy lazily initializes upstream clusters. This can delay the first requests to new services. Use preconnect_ratio or initial health checks (via DestinationRule + outlierDetection) to pre-warm clusters during deployments.

  4. Enforce limits on headers and URI sizes to mitigate layer 7 DoS attacks:

    Set max_request_headers_kb, max_headers_count, and URI size limits in Envoy configuration to prevent abuse from oversized requests, which can be used in HTTP-based DoS attacks. Tune these based on your known workloads.

  5. Avoid shared SNI domains across unrelated services to limit blast radius:

    Group services with common TLS credentials into distinct Gateways. Avoid wildcard SNI matches across high-risk and low-risk services; this reduces the chance of a single misconfigured VirtualService exposing sensitive endpoints.

Profile Picture

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.

Use Cases and Scenarios of Istio Envoy Proxy

Service Mesh Data Plane

Envoy’s primary use case in Istio is as the data plane component of a service mesh. It manages all east-west (service-to-service) traffic, allowing for reliable and secure communication across microservices. Envoy handles features like dynamic service discovery, traffic shaping, health checking, fault injection, and retries out-of-the-box. The Envoy sidecar model provides a consistent and scalable approach to enforcing networking policies enterprise-wide.

Edge / API Gateway

Envoy can function as an edge proxy or API gateway, mediating ingress traffic from external clients into the service mesh. As an ingress controller, Envoy supports L7 routing, TLS termination, authentication, and rate limiting. It ensures incoming requests are processed according to organizational policy before entering the mesh. Features like Web Application Firewall (WAF) integration, DDoS mitigation, and custom authentication (OAuth, JWT) can be implemented at the edge proxy.

Internal Traffic Routing and Control

Istio and Envoy make it easy to implement internal traffic management strategies. Operators can set up blue-green or canary deployments, direct traffic based on user identity or geo-location, and manage graceful failovers, all through configuration. Fine-grained control over traffic also enables policies like restricting access between specific services or enforcing quotas and rate limits.

Hybrid / Legacy Environments

Not all systems within an organization are cloud-native or built on Kubernetes. Envoy’s flexibility allows it to be deployed alongside legacy workloads, serving as a bridge between hybrid environments. It can proxy traffic to and from VM-based applications, on-premises systems, or third-party APIs, offering a unified policy layer via Istio. This approach enables gradual modernization.

Challenges and Tradeoffs with Envoy Proxy and Service Mesh Deployments

While Envoy and Istio bring powerful capabilities to service-to-service communication, they introduce several operational and performance tradeoffs that must be carefully considered:

Performance Overhead
Deploying a sidecar proxy like Envoy with every pod increases resource consumption. Each proxy adds CPU and memory overhead, which compounds at scale, especially in large clusters. In addition, the processing of each request through an extra hop in the sidecar can introduce latency. Though generally small, this latency can impact performance-sensitive workloads.

Operational Complexity
Managing a large number of sidecar proxies introduces operational challenges. Each proxy must stay in sync with the control plane and be properly configured. Over time, version drift between proxies can occur, leading to inconsistent behavior. Coordinating rollouts and upgrades across hundreds or thousands of proxies can also be error-prone and requires careful orchestration.

Configuration Complexity and Risk
Istio’s flexibility in defining routing rules, policies, and security configurations can lead to complexity. Misconfigured routing logic, incorrect TLS settings, or overly permissive access control policies can break traffic flow or create security gaps. Declarative configuration makes management easier, but the surface area for misconfiguration remains significant.

Visibility Gaps
While Envoy offers extensive observability for HTTP and TCP traffic, visibility for non-standard protocols or non-mesh traffic may require additional tooling. Traffic that bypasses the mesh—intentionally or due to configuration issues—can lead to blind spots in monitoring, making it harder to troubleshoot issues.

Migration and Integration Complexity
Introducing Envoy into an existing environment is not always straightforward. Migrating workloads into the mesh may require changes to deployment manifests, service naming, or security settings. Compatibility with existing CNI plugins, legacy workloads (e.g., VMs or bare metal), and non-Kubernetes services may require the use of additional Istio features like VM onboarding or ambient mesh, which bring their own complexities.

These challenges do not necessarily outweigh the benefits but must be accounted for during planning, especially in production environments. Teams adopting Envoy and Istio need to invest in automation, monitoring, and ongoing education to effectively manage the complexity.

Migration Traffic Flows: What to Watch For When Adopting a Proxy or Service-Mesh-based Approach

Mixed Cluster Traffic

During migration, traffic flows will involve a mix of workloads—some in the mesh, some not. For example:

  • Pod-to-pod (in-mesh → in-mesh): Handled entirely by Envoy, with full policy enforcement and observability.
  • Pod-to-VM/bare metal (in-mesh → external): Requires configuration using ServiceEntry and possibly workload entries to represent external services inside the mesh.
  • External-to-mesh (north-south): Managed via ingress gateways; ensure they are configured to terminate TLS and apply mesh policies.
  • East-west traffic (internal): Gradually transitions from direct pod-to-pod via CNI to sidecar or ambient-proxied traffic. During this hybrid state, careful routing and DNS setup are needed to avoid asymmetric routing or policy gaps.

Ingress/Egress Behavior

Plan for both north-south (user → service) and east-west (service ↔ service) traffic patterns. Ensure that:

  • Ingress gateways are configured to forward traffic into the mesh correctly, with security policies applied.
  • Egress traffic from mesh services to external systems is allowed and secured using EgressGateways or ServiceEntry configurations.
  • Existing firewall or DNS policies don’t unintentionally block traffic from sidecars or ambient proxies.

Rollout Strategies

Gradual rollout minimizes risk:

  • Namespace-by-namespace: Enable sidecar injection incrementally. Monitor traffic and behavior in each namespace before proceeding.
  • Side-by-side deployment: Deploy the same service in mesh and non-mesh modes. Shift traffic gradually using DNS or weighted routing.
  • Canary / Blue-green: Use VirtualService to split traffic between service versions. Observe behavior and gradually shift 100% traffic when validated.
  • Ambient mesh options: Consider using ztunnel and waypoint proxies for lightweight onboarding, especially for environments where sidecars are too intrusive.

Policy Migration

Translating CNI or firewall policies to Istio’s model requires attention:

  • Start with permissive mode to observe traffic without blocking.
  • Use AuthorizationPolicy and PeerAuthentication to mirror existing allow/deny rules.
  • Validate TLS and authentication settings before enforcing mTLS.
  • Ensure that traffic visibility tools (e.g., Kiali, Prometheus) are in place to observe effects of new policies.

Observability During Transition

Partial mesh deployments often create visibility gaps:

  • Non-mesh traffic won’t appear in mesh telemetry. Use fallback logging and flow monitoring for non-mesh paths.
  • Ensure telemetry from proxies is sent to Prometheus, Grafana, Jaeger, or other tools for traffic inside the mesh.
  • Use tap filters or access logs to debug specific flows.
  • Verify that fallback and failover behaviors (e.g., retry logic) are configured identically in and out of mesh.

A phased migration plan with clear observability checkpoints, controlled policy rollout, and dual-stack traffic handling is essential for reducing disruption and ensuring a smooth adoption of Istio and Envoy-based architectures.

Best Practices for Managing Istio Envoy Proxy

Organizations should consider the following best practices when using the Istio proxy.

1. Start Small: Deploy Envoy in a Limited Context Before Full Mesh

Before enabling Istio across an entire cluster, begin by deploying Envoy in a controlled, limited environment such as a staging namespace or a subset of low-risk services. This approach lets you assess the operational impact of introducing a sidecar proxy, including changes to network latency, CPU and memory overhead, and the behavior of policies like routing and authentication, without affecting critical workloads.

Use namespace labels (istio-injection=enabled) to enable sidecar injection selectively. Start with stateless services that are easy to redeploy and monitor how traffic is intercepted, how policies are enforced, and how telemetry is generated. Confirm that application behavior remains unchanged, connectivity is stable, and observability pipelines (Prometheus, Grafana, Jaeger, etc.) are receiving expected data.

2. Use Consistent Naming/Metrics Policies Across Proxies for Observability

Observability in a service mesh hinges on consistent labeling and naming across proxies. Envoy produces detailed metrics, logs, and traces, but their usefulness is directly tied to how metadata, such as service names, namespaces, versions, and response codes, is structured. Inconsistent naming leads to fragmented dashboards and difficult-to-understand telemetry.

Establish and enforce a naming convention for Kubernetes resources (e.g., app, version, environment labels), and ensure these propagate to telemetry outputs. For example, the destination_service label in Prometheus metrics should reflect a predictable pattern like service.namespace.svc.cluster.local. Use Telemetry resources to customize metric generation and EnvoyFilter resources to inject or rewrite metadata when needed.

3. Version Control Your Configurations, Use Automated Rollout Strategies

All Istio-related configuration should be treated as code and stored in version control systems such as Git. This includes routing rules (VirtualService), resiliency policies (DestinationRule), security policies (AuthorizationPolicy, PeerAuthentication), and observability settings (Telemetry, EnvoyFilter). Versioning configurations enables traceability, auditability, and rollback in case of errors.

Use templating tools like Helm or Kustomize to manage configuration variants across environments (dev, staging, prod). Automate deployment pipelines using GitOps tools like Argo CD or Flux, which ensure the actual cluster state matches your declared configuration.

4. Monitor Resource Usage (Threads, Memory) and Tune Appropriately

Envoy, as a full-featured L7 proxy, consumes compute and memory resources. Under high traffic volumes or with complex policies (e.g., heavy use of filters, mTLS, large headers), proxies may become bottlenecks if not properly tuned. Continuous resource monitoring is essential to ensure stability and performance.

Expose and scrape Envoy admin metrics (via /stats endpoint) using Prometheus. Key metrics include envoy_server_memory_allocated, envoy_http_downstream_rq_active, envoy_cluster_upstream_rq_pending, and thread pool statistics. Review metrics regularly to detect resource saturation or abnormal patterns.

5. Keep Security in Mind: TLS/mTLS, Authentication Filters, Ensure Your Filters Are Well Reviewed

Security enforcement should be embedded into the mesh from the beginning. Start by enabling strict mTLS mode (PeerAuthentication with mode STRICT) to ensure all service-to-service traffic is encrypted and authenticated. This prevents plaintext communication and enables service identity verification through certificates issued by Istio’s internal CA or an external certificate authority.

Use RequestAuthentication policies to validate end-user credentials, such as JWTs issued by identity providers. Combine this with AuthorizationPolicy to restrict access based on authenticated identities, request paths, methods, or other attributes. Adopt a default-deny model and only allow known-good traffic paths.

Evaluation Criteria: What to Look For When Selecting a Traffic and Security Platform

When selecting a proxy-based or service mesh platform, evaluate the following criteria to ensure alignment with your environment’s needs and constraints:

Networking Coverage

  • Kubernetes compatibility: Ensure the platform works across major Kubernetes distributions (e.g., GKE, EKS, AKS, OpenShift, upstream Kubernetes). Look for support without requiring custom kernels or unsupported CRI runtimes.
  • CNI and overlay integration: Confirm that the solution supports a hybrid model—working alongside existing CNI plugins (e.g., Calico, Cilium) while layering L7 capabilities on top.
  • Cross-node and cross-cluster networking: Validate that service-to-service traffic can traverse node and cluster boundaries securely and efficiently, with consistent identity and routing policies.
  • VM and bare-metal support: For hybrid environments, the platform should allow onboarding of non-Kubernetes workloads using workload entries or gateway bridging mechanisms.

Performance and Scalability

  • Resource overhead: Assess the CPU and memory footprint of sidecar or node-level proxies. Consider ambient mesh mode if sidecar resource cost is prohibitive.
  • Latency and throughput: Evaluate request latency introduced by proxy interception and the throughput capacity under real-world load. Avoid platforms that introduce unpredictable delays at scale.
  • Scale limits: Confirm tested or proven support for thousands of pods, services, or endpoints. Review architectural documentation for control plane scaling strategies and proxy optimization.

Security Capabilities

  • mTLS and encryption in transit: Look for automatic certificate management (issuance, rotation), strong cipher support, and transparent encryption of all east-west traffic.
  • Identity and authentication: Platforms should issue cryptographic identities to workloads and support workload identity federation (e.g., SPIFFE, JWT, or OIDC integration).
  • Authorization: Evaluate support for fine-grained L7 policy enforcement (e.g., path-based, method-based), along with support for policy templates and context-aware access controls.
  • Zero-trust model support: Confirm the ability to enforce strict deny-by-default policies, validate source identity on every request, and audit all traffic.

Observability and Diagnostics

  • Telemetry: Out-of-the-box metrics (latency, request volume, error rates) should be available and exportable to Prometheus, Grafana, etc.
  • Tracing and logs: The platform should support distributed tracing (e.g., OpenTelemetry, Jaeger, Zipkin) and detailed access logs. Look for built-in context propagation and correlation.
  • Policy visibility: Evaluate tooling for real-time inspection of effective policies and access decisions. Ability to visualize service graphs, flow paths, and security posture is key.
  • Troubleshooting tools: Features like tap filters, live traffic capture, and debug endpoints simplify root-cause analysis during incidents.

Manageability and Operational Complexity

  • Deployment model: Sidecar-based meshes offer granular control but require more resources and updates. Ambient meshes reduce sidecar overhead but may have feature trade-offs. Choose based on environment constraints.
  • Configuration management: Look for support for GitOps, declarative APIs (CRDs), and consistency across environments. Configuration previews, dry-runs, or shadow policies help reduce error risk.
  • Upgrades and versioning: Rolling updates, canary deployments of control plane components, and version pinning for proxies help reduce disruption.
  • CI/CD integration: Ability to validate and test traffic/security policies during app deployment pipelines is essential for enforcing governance.

Flexibility, Extensibility, and Interoperability

  • Hybrid workload support: Must support containers, VMs, bare metal, and cloud-native plus legacy systems.
  • Multi-cluster and multi-cloud: Validate support for cross-cluster service discovery, traffic routing, and identity management across cloud providers.
  • Egress/ingress integration: Ability to integrate with existing ingress controllers, cloud load balancers, firewalls, and custom gateway implementations.
  • Tool compatibility: The platform should interoperate with monitoring (e.g., Prometheus), logging (e.g., Fluent Bit), CI/CD tools, and policy engines (e.g., OPA/Gatekeeper).

Compliance, Auditing, and Regulatory Controls

  • Audit logging: Look for support for logging all access decisions, certificate usage, and administrative changes.
  • Policy enforcement: Ability to enforce policies consistently across workloads and prevent configuration drift.
  • Reporting: Tools should enable generation of compliance reports (e.g., service-to-service encryption, policy coverage) for internal or external audits.

Cost and Vendor Lock-In

  • Open source vs commercial: Determine the licensing model. Open source platforms (e.g., Istio, Linkerd) offer flexibility, but may require more in-house expertise. Commercial offerings may bundle support, dashboards, and compliance features.
  • Portability: Prefer platforms that are CNCF-aligned and not tied to a single cloud provider’s networking stack.
  • Community and ecosystem: Assess activity and maturity of the platform’s ecosystem—availability of documentation, community support, third-party integrations, and long-term roadmap alignment.

Bringing It All Together: Tigera’s Calico with Istio Ambient Mode

Calico’s integration with Istio Ambient Mode pairs the sidecarless mesh data plane — a per-node zTunnel proxy for L4 identity and mTLS, and an optional per-namespace Waypoint proxy for L7 routing and authorization — with Calico’s existing network policy enforcement and flow telemetry. A modified zTunnel preserves the original destination port so existing Kubernetes and Calico policies continue to work without rewrites, and L7 telemetry from the Waypoint proxy can be correlated with Calico’s L3/L4 flow logs for end-to-end visibility across the stack.

Specifically, this combined model provides:

  • Mesh-wide mTLS by default, with automatic certificate issuance and rotation, and identity bound to the workload rather than to transient pod IPs.
  • Policy compatibility without rewrites, since the modified zTunnel preserves the original destination port so existing Kubernetes NetworkPolicy and Calico GlobalNetworkPolicy resources continue to enforce on the real application port.
  • Layered L4 and L7 enforcement, combining Calico L3/L4 policy with Istio AuthorizationPolicy rules that can match on workload identity, HTTP method and path, headers, and JWT claims at the Waypoint proxy.
  • L7 traffic control including canary rollouts, A/B testing, blue/green cutovers, traffic mirroring, retries, timeouts, circuit breakers, and outlier detection.
  • Unified L4 + L7 observability, with OpenTelemetry-based metrics, traces, and logs from the Waypoint proxy correlated with Calico’s flow data to expose request paths, mTLS status per hop, latency distributions, and authorization denials.
  • Operator-managed lifecycle, where mesh components are installed, upgraded, and patched through the Tigera Operator, and namespaces are onboarded with a single label rather than sidecar injection.

Next steps:

X