Istio sidecar proxies get their CPU and memory limits from the Kubernetes Pod spec, not directly from Istio configuration.
This is what a typical Pod spec looks like for a workload with an Istio sidecar, showing the resource limits for both the application container and the Istio proxy container:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
template:
spec:
containers:
- name: my-app-container
image: my-app-image:latest
resources:
limits:
cpu: "500m"
memory: "512Mi"
requests:
cpu: "200m"
memory: "256Mi"
- name: istio-proxy
image: docker.io/istio/proxyv2:1.19.0
resources:
limits:
cpu: "200m"
memory: "256Mi"
requests:
cpu: "100m"
memory: "128Mi"
The istio-proxy container in this example has limits of 200m CPU and 256Mi memory. These are the values Kubernetes will enforce.
The core problem Istio solves with sidecars is enabling advanced networking features like traffic management, observability, and security without modifying application code. The sidecar intercepts all inbound and outbound traffic for the application container.
Internally, the Istio sidecar is an Envoy proxy. Envoy is a high-performance C++ distributed proxy designed for cloud-native applications. When Istio injects the sidecar, it configures Envoy to perform specific tasks: routing traffic based on Istio’s control plane (Istiod), collecting telemetry, enforcing authorization policies, and more.
The resource limits you set directly impact Envoy’s ability to perform these functions. If the limits are too low, Envoy can become unstable, leading to increased latency, dropped connections, or even crashes. Conversely, excessively high limits waste cluster resources.
The exact levers you control are the resources.limits and resources.requests fields within the istio-proxy container’s definition in your Kubernetes Pod or Deployment spec. requests are used by the Kubernetes scheduler to decide which node to place the pod on, and they guarantee a minimum amount of resources. limits are the maximum amount of resources the container can consume; if it exceeds these, Kubernetes will throttle (CPU) or evict (memory) the container.
Most people don’t realize that the default resource requests and limits for the istio-proxy are often quite conservative, and may not be sufficient for production workloads, especially those with high traffic volumes or complex Istio configurations (like many virtual services, destination rules, or authorization policies). You will likely need to tune these based on your specific application’s traffic patterns and Istio feature usage.
The next concept you’ll likely grapple with is how to monitor the actual resource consumption of your sidecars to inform these tuning decisions.