istio is an open source monitoring system and time series database keywords integration prometheus weight 30 owner istio wg environments maintainers How to integrate with Prometheus test n a title Prometheus

Answer:
---
title: Prometheus
description: How to integrate with Prometheus.
weight: 30
keywords: [integration,prometheus]
owner: istio/wg-environments-maintainers
test: n/a
---

[Prometheus](https://prometheus.io/) is an open source monitoring system and time series database.
You can use Prometheus with Istio to record metrics that track the health of Istio and of
applications within the service mesh. You can visualize metrics using tools like
[Grafana](/docs/ops/integrations/grafana/) and [Kiali](/docs/tasks/observability/kiali/).

## Installation

### Option 1: Quick start

Istio provides a basic sample installation to quickly get Prometheus up and running:

$ kubectl apply -f /samples/addons/prometheus.yaml

This will deploy Prometheus into your cluster. This is intended for demonstration only, and is not tuned for performance or security.

While the quick-start configuration is well-suited for small clusters and monitoring for short time horizons,
it is not suitable for large-scale meshes or monitoring over a period of days or weeks. In particular,
the introduced labels can increase metrics cardinality, requiring a large amount of storage. And, when trying
to identify trends and differences in traffic over time, access to historical data can be paramount.

### Option 2: Customizable install

Consult the [Prometheus documentation](https://www.prometheus.io/) to get started
deploying Prometheus into your environment. See [Configuration](#configuration)
for more information on configuring Prometheus to scrape Istio deployments.

## Configuration

In an Istio mesh, each component exposes an endpoint that emits metrics. Prometheus works
by scraping these endpoints and collecting the results. This is configured through the
[Prometheus configuration file](https://prometheus.io/docs/prometheus/latest/configuration/configuration/)
which controls settings for which endpoints to query, the port and path to query, TLS settings, and more.

To gather metrics for the entire mesh, configure Prometheus to scrape:

1. The control plane (`istiod` deployment)
1. Ingress and Egress gateways
1. The Envoy sidecar
1. The user applications (if they expose Prometheus metrics)

To simplify the configuration of metrics, Istio offers two modes of operation.

### Option 1: Metrics merging

To simplify configuration, Istio has the ability to control scraping entirely by
`prometheus.io` annotations. This allows Istio scraping to work out of the box with
standard configurations such as the ones provided by the
[Helm `stable/prometheus`](https://github.com/helm/charts/tree/master/stable/prometheus) charts.

While `prometheus.io` annotations are not a core part of Prometheus,
they have become the de facto standard to configure scraping.

This option is enabled by default but can be disabled by passing
`--set meshConfig.enablePrometheusMerge=false` during [installation](/docs/setup/install/istioctl/).
When enabled, appropriate `prometheus.io` annotations will be added to all data plane pods to set up scraping.
If these annotations already exist, they will be overwritten. With this option, the Envoy sidecar will
merge Istio's metrics with the application metrics. The merged metrics will be scraped from `:15020/stats/prometheus`.

This option exposes all the metrics in plain text.

This feature may not suit your needs in the following situations:

* You need to scrape metrics using TLS.
* Your application exposes metrics with the same names as Istio metrics. For example,
  your application metrics expose an `istio_requests_total` metric.
  This might happen if the application is itself running Envoy.
* Your Prometheus deployment is not configured to scrape based on standard `prometheus.io` annotations.

If required, this feature can be disabled per workload by adding a `prometheus.istio.io/merge-metrics: "false"` annotation on a pod.

### Option 2: Customized scraping configurations

To configure an existing Prometheus instance to scrape stats generated by Istio, several jobs need to be added.

* To scrape `Istiod` stats, the following example job can be added to scrape its `http-monitoring` port:

- job_name: 'istiod'
  kubernetes_sd_configs:
  - role: endpoints
    namespaces:
      names:
      - istio-system
  relabel_configs:
  - source_labels: [__meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
    action: keep
    regex: istiod;http-monitoring

* To scrape Envoy stats, including sidecar proxies and gateway proxies,
  the following job can be added to scrape ports that end with `-envoy-prom`:

    - job_name: 'envoy-stats'
      metrics_path: /stats/prometheus
      kubernetes_sd_configs:
      - role: pod

      relabel_configs:
      - source_labels: [__meta_kubernetes_pod_container_port_name]
        action: keep
        regex: '.*-envoy-prom'

* For application stats, if [Strict mTLS](/docs/tasks/security/authentication/authn-policy/#globally-enabling-istio-mutual-tls-in-strict-mode)
  is not enabled, your existing scraping configuration should still work. Otherwise,
  Prometheus needs to be configured to [scrape with Istio certs](#tls-settings).

#### TLS settings

The control plane, gateway, and Envoy sidecar metrics will all be scraped over cleartext.
However, the application metrics will follow whatever [Istio authentication policy](/docs/tasks/security/authentication/authn-policy) has been configured
for the workload.

* If you use `STRICT` mode, then Prometheus will need to be configured to scrape using Istio certificates as described below.
* If you use `PERMISSIVE` mode, the workload typically accepts TLS and cleartext. However, Prometheus cannot send the special variant of TLS Istio requires for `PERMISSIVE` mode. As a result, you must *not* configure TLS in Prometheus.
* If you use `DISABLE` mode, no TLS configuration is required for Prometheus.

Note this only applies to Istio-terminated TLS. If your application directly handles TLS:
* `STRICT` mode is not supported, as Prometheus would need to send two layers of TLS which it cannot do.
* `PERMISSIVE` mode and `DISABLE` mode should be configured the same as if Istio was not present.

See [Understanding TLS Configuration](/docs/ops/configuration/traffic-management/tls-configuration/) for more information.

One way to provision Istio certificates for Prometheus is by injecting a sidecar
which will rotate SDS certificates and output them to a volume that can be shared with Prometheus.
However, the sidecar should not intercept requests for Prometheus because Prometheus's
model of direct endpoint access is incompatible with Istio's sidecar proxy model.

To achieve this, configure a cert volume mount on the Prometheus server container:

containers:
  - name: prometheus-server
    ...
    volumeMounts:
      mountPath: /etc/prom-certs/
      name: istio-certs
volumes:
  - emptyDir:
      medium: Memory
    name: istio-certs

Then add the following annotations to the Prometheus deployment pod template,
and deploy it with [sidecar injection](/docs/setup/additional-setup/sidecar-injection/).
This configures the sidecar to write a certificate to the shared volume, but without configuring traffic redirection:

spec:
  template:
    metadata:
      annotations:
        traffic.sidecar.istio.io/includeInboundPorts: ""   # do not intercept any inbound ports
        traffic.sidecar.istio.io/includeOutboundIPRanges: ""  # do not intercept any outbound traffic
        proxy.istio.io/config: |  # configure an env variable `OUTPUT_CERTS` to write certificates to the given folder
          proxyMetadata:
            OUTPUT_CERTS: /etc/istio-output-certs
        sidecar.istio.io/userVolumeMount: '[{"name": "istio-certs", "mountPath": "/etc/istio-output-certs"}]' # mount the shared volume at sidecar proxy

Finally, set the scraping job TLS context as follows:

scheme: https
tls_config:
  ca_file: /etc/prom-certs/root-cert.pem
  cert_file: /etc/prom-certs/cert-chain.pem
  key_file: /etc/prom-certs/key.pem
  insecure_skip_verify: true  # Prometheus does not support Istio security naming, thus skip verifying target pod certificate

## Best practices

For larger meshes, advanced configuration might help Prometheus scale.
See [Using Prometheus for production-scale monitoring](/docs/ops/best-practices/observability/#using-prometheus-for-production-scale-monitoring)
for more information.

title  Prometheus description  How to integrate with Prometheus  weight  30 keywords   integration prometheus  owner  istio wg environments maintainers test  n a       Prometheus  https   prometheus io   is an open source monitoring system and time series database  You can use Prometheus with Istio to record metrics that track the health of Istio and of applications within the service mesh  You can visualize metrics using tools like  Grafana   docs ops integrations grafana   and  Kiali   docs tasks observability kiali        Installation      Option 1  Quick start  Istio provides a basic sample installation to quickly get Prometheus up and running      kubectl apply  f  samples addons prometheus yaml   This will deploy Prometheus into your cluster  This is intended for demonstration only  and is not tuned for performance or security    While the quick start configuration is well suited for small clusters and monitoring for short time horizons  it is not suitable for large scale meshes or monitoring over a period of days or weeks  In particular  the introduced labels can increase metrics cardinality  requiring a large amount of storage  And  when trying to identify trends and differences in traffic over time  access to historical data can be paramount        Option 2  Customizable install  Consult the  Prometheus documentation  https   www prometheus io   to get started deploying Prometheus into your environment  See  Configuration   configuration  for more information on configuring Prometheus to scrape Istio deployments      Configuration  In an Istio mesh  each component exposes an endpoint that emits metrics  Prometheus works by scraping these endpoints and collecting the results  This is configured through the  Prometheus configuration file  https   prometheus io docs prometheus latest configuration configuration   which controls settings for which endpoints to query  the port and path to query  TLS settings  and more   To gather metrics for the entire mesh  configure Prometheus to scrape   1  The control plane   istiod  deployment  1  Ingress and Egress gateways 1  The Envoy sidecar 1  The user applications  if they expose Prometheus metrics   To simplify the configuration of metrics  Istio offers two modes of operation       Option 1  Metrics merging  To simplify configuration  Istio has the ability to control scraping entirely by  prometheus io  annotations  This allows Istio scraping to work out of the box with standard configurations such as the ones provided by the  Helm  stable prometheus   https   github com helm charts tree master stable prometheus  charts    While  prometheus io  annotations are not a core part of Prometheus  they have become the de facto standard to configure scraping    This option is enabled by default but can be disabled by passing    set meshConfig enablePrometheusMerge false  during  installation   docs setup install istioctl    When enabled  appropriate  prometheus io  annotations will be added to all data plane pods to set up scraping  If these annotations already exist  they will be overwritten  With this option  the Envoy sidecar will merge Istio s metrics with the application metrics  The merged metrics will be scraped from   15020 stats prometheus    This option exposes all the metrics in plain text   This feature may not suit your needs in the following situations     You need to scrape metrics using TLS    Your application exposes metrics with the same names as Istio metrics  For example    your application metrics expose an  istio requests total  metric    This might happen if the application is itself running Envoy    Your Prometheus deployment is not configured to scrape based on standard  prometheus io  annotations   If required  this feature can be disabled per workload by adding a  prometheus istio io merge metrics   false   annotation on a pod       Option 2  Customized scraping configurations  To configure an existing Prometheus instance to scrape stats generated by Istio  several jobs need to be added     To scrape  Istiod  stats  the following example job can be added to scrape its  http monitoring  port      job name   istiod    kubernetes sd configs      role  endpoints     namespaces        names          istio system   relabel configs      source labels     meta kubernetes service name    meta kubernetes endpoint port name      action  keep     regex  istiod http monitoring     To scrape Envoy stats  including sidecar proxies and gateway proxies    the following job can be added to scrape ports that end with   envoy prom           job name   envoy stats        metrics path   stats prometheus       kubernetes sd configs          role  pod        relabel configs          source labels     meta kubernetes pod container port name          action  keep         regex      envoy prom      For application stats  if  Strict mTLS   docs tasks security authentication authn policy  globally enabling istio mutual tls in strict mode    is not enabled  your existing scraping configuration should still work  Otherwise    Prometheus needs to be configured to  scrape with Istio certs   tls settings         TLS settings  The control plane  gateway  and Envoy sidecar metrics will all be scraped over cleartext  However  the application metrics will follow whatever  Istio authentication policy   docs tasks security authentication authn policy  has been configured for the workload     If you use  STRICT  mode  then Prometheus will need to be configured to scrape using Istio certificates as described below    If you use  PERMISSIVE  mode  the workload typically accepts TLS and cleartext  However  Prometheus cannot send the special variant of TLS Istio requires for  PERMISSIVE  mode  As a result  you must  not  configure TLS in Prometheus    If you use  DISABLE  mode  no TLS configuration is required for Prometheus    Note this only applies to Istio terminated TLS  If your application directly handles TLS     STRICT  mode is not supported  as Prometheus would need to send two layers of TLS which it cannot do     PERMISSIVE  mode and  DISABLE  mode should be configured the same as if Istio was not present   See  Understanding TLS Configuration   docs ops configuration traffic management tls configuration   for more information    One way to provision Istio certificates for Prometheus is by injecting a sidecar which will rotate SDS certificates and output them to a volume that can be shared with Prometheus  However  the sidecar should not intercept requests for Prometheus because Prometheus s model of direct endpoint access is incompatible with Istio s sidecar proxy model   To achieve this  configure a cert volume mount on the Prometheus server container    containers      name  prometheus server             volumeMounts        mountPath   etc prom certs        name  istio certs volumes      emptyDir        medium  Memory     name  istio certs   Then add the following annotations to the Prometheus deployment pod template  and deploy it with  sidecar injection   docs setup additional setup sidecar injection    This configures the sidecar to write a certificate to the shared volume  but without configuring traffic redirection    spec    template      metadata        annotations          traffic sidecar istio io includeInboundPorts         do not intercept any inbound ports         traffic sidecar istio io includeOutboundIPRanges        do not intercept any outbound traffic         proxy istio io config       configure an env variable  OUTPUT CERTS  to write certificates to the given folder           proxyMetadata              OUTPUT CERTS   etc istio output certs         sidecar istio io userVolumeMount      name    istio certs    mountPath     etc istio output certs       mount the shared volume at sidecar proxy   Finally  set the scraping job TLS context as follows    scheme  https tls config    ca file   etc prom certs root cert pem   cert file   etc prom certs cert chain pem   key file   etc prom certs key pem   insecure skip verify  true    Prometheus does not support Istio security naming  thus skip verifying target pod certificate      Best practices  For larger meshes  advanced configuration might help Prometheus scale  See  Using Prometheus for production scale monitoring   docs ops best practices observability  using prometheus for production scale monitoring  for more information


istio virtual machine owner istio wg environments maintainers keywords Describes Istio s high level architecture for virtual machines title Virtual Machine Architecture weight 25 test n a

Answer:
---
title: Virtual Machine Architecture
description: Describes Istio's high-level architecture for virtual machines.
weight: 25
keywords:
- virtual-machine
test: n/a
owner: istio/wg-environments-maintainers
---

Before reading this document, be sure to review [Istio's architecture](/docs/ops/deployment/architecture/) and [deployment models](/docs/ops/deployment/deployment-models/).
This page builds on those documents to explain how Istio can be extended to support joining virtual machines into the mesh.

Istio's virtual machine support allows connecting workloads outside of a Kubernetes cluster to the mesh.
This enables legacy applications, or applications not suitable to run in a containerized environment, to get all the benefits that Istio provides to applications running inside Kubernetes.

For workloads running on Kubernetes, the Kubernetes platform itself provides various features like service discovery, DNS resolution, and health checks which are often missing in virtual machine environments.
Istio enables these features for workloads running on virtual machines, and in addition allows these workloads to utilize Istio functionality such as mutual TLS (mTLS), rich telemetry, and advanced traffic management capabilities.

The following diagram shows the architecture of a mesh with virtual machines:

In this mesh, there is a single [network](/docs/ops/deployment/deployment-models/#network-models), where pods and virtual machines can communicate directly with each other.

Control plane traffic, including XDS configuration and certificate signing, are sent through a Gateway in the cluster.
This ensures that the virtual machines have a stable address to connect to when they are bootstrapping. Pods and virtual machines can communicate directly with each other without requiring any intermediate Gateway.

In this mesh, there are multiple [networks](/docs/ops/deployment/deployment-models/#network-models), where pods and virtual machines are not able to communicate directly with each other.

Control plane traffic, including XDS configuration and certificate signing, are sent through a Gateway in the cluster.
Similarly, all communication between pods and virtual machines goes through the gateway, which acts as a bridge between the two networks.

## Service association

Istio provides two mechanisms to represent virtual machine workloads:

* [`WorkloadGroup`](/docs/reference/config/networking/workload-group/) represents a logical group of virtual machine workloads that share common properties. This is similar to a `Deployment` in Kubernetes.
* [`WorkloadEntry`](/docs/reference/config/networking/workload-entry/) represents a single instance of a virtual machine workload. This is similar to a `Pod` in Kubernetes.

Creating these resources (`WorkloadGroup` and `WorkloadEntry`) does not result in provisioning of any resources or running any virtual machine workloads.
Rather, these resources just reference these workloads and inform Istio how to configure the mesh appropriately.

When adding a virtual machine workload to the mesh, you will need to create a `WorkloadGroup` that acts as template for each `WorkloadEntry` instance:

apiVersion: networking.istio.io/v1
kind: WorkloadGroup
metadata:
  name: product-vm
spec:
  metadata:
    labels:
      app: product
  template:
    serviceAccount: default
  probe:
    httpGet:
      port: 8080

Once a virtual machine has been [configured and added to the mesh](/docs/setup/install/virtual-machine/#configure-the-virtual-machine), a corresponding `WorkloadEntry` will be automatically created by the Istio control plane.
For example:

apiVersion: networking.istio.io/v1
kind: WorkloadEntry
metadata:
  annotations:
    istio.io/autoRegistrationGroup: product-vm
  labels:
    app: product
  name: product-vm-1.2.3.4
spec:
  address: 1.2.3.4
  labels:
    app: product
  serviceAccount: default

This `WorkloadEntry` resource describes a single instance of a workload, similar to a pod in Kubernetes. When the workload is removed from the mesh, the `WorkloadEntry` resource will
be automatically removed.  Additionally, if any probes are configured in the `WorkloadGroup` resource, the Istio control plane automatically updates the health status of associated `WorkloadEntry` instances.

In order for consumers to reliably call your workload, it's recommended to declare a `Service` association. This allows clients to reach a stable hostname, like `product.default.svc.cluster.local`, rather than an ephemeral IP addresses. This also enables you to use advanced routing capabilities in Istio via the `DestinationRule` and `VirtualService` APIs.

Any Kubernetes service can transparently select workloads across both pods and virtual machines via the selector fields which are matched with pod and `WorkloadEntry` labels respectively.

For example, a `Service` named `product` is composed of a `Pod` and a `WorkloadEntry`:

With this configuration, requests to `product` would be load-balanced across both the pod and virtual machine workload instances.

## DNS

Kubernetes provides DNS resolution in pods for `Service` names allowing pods to easily communicate with one another by stable hostnames.

For virtual machine expansion, Istio provides similar functionality via a [DNS Proxy](/docs/ops/configuration/traffic-management/dns-proxy/).
This feature redirects all DNS queries from the virtual machine workload to the Istio proxy, which maintains a mapping of hostnames to IP addresses.

As a result, workloads running on virtual machines can transparently call `Service`s (similar to pods) without requiring any additional configuration.

title  Virtual Machine Architecture description  Describes Istio s high level architecture for virtual machines  weight  25 keywords    virtual machine test  n a owner  istio wg environments maintainers      Before reading this document  be sure to review  Istio s architecture   docs ops deployment architecture   and  deployment models   docs ops deployment deployment models    This page builds on those documents to explain how Istio can be extended to support joining virtual machines into the mesh   Istio s virtual machine support allows connecting workloads outside of a Kubernetes cluster to the mesh  This enables legacy applications  or applications not suitable to run in a containerized environment  to get all the benefits that Istio provides to applications running inside Kubernetes   For workloads running on Kubernetes  the Kubernetes platform itself provides various features like service discovery  DNS resolution  and health checks which are often missing in virtual machine environments  Istio enables these features for workloads running on virtual machines  and in addition allows these workloads to utilize Istio functionality such as mutual TLS  mTLS   rich telemetry  and advanced traffic management capabilities   The following diagram shows the architecture of a mesh with virtual machines       In this mesh  there is a single  network   docs ops deployment deployment models  network models   where pods and virtual machines can communicate directly with each other   Control plane traffic  including XDS configuration and certificate signing  are sent through a Gateway in the cluster  This ensures that the virtual machines have a stable address to connect to when they are bootstrapping  Pods and virtual machines can communicate directly with each other without requiring any intermediate Gateway         In this mesh  there are multiple  networks   docs ops deployment deployment models  network models   where pods and virtual machines are not able to communicate directly with each other   Control plane traffic  including XDS configuration and certificate signing  are sent through a Gateway in the cluster  Similarly  all communication between pods and virtual machines goes through the gateway  which acts as a bridge between the two networks            Service association  Istio provides two mechanisms to represent virtual machine workloads       WorkloadGroup    docs reference config networking workload group   represents a logical group of virtual machine workloads that share common properties  This is similar to a  Deployment  in Kubernetes      WorkloadEntry    docs reference config networking workload entry   represents a single instance of a virtual machine workload  This is similar to a  Pod  in Kubernetes   Creating these resources   WorkloadGroup  and  WorkloadEntry   does not result in provisioning of any resources or running any virtual machine workloads  Rather  these resources just reference these workloads and inform Istio how to configure the mesh appropriately   When adding a virtual machine workload to the mesh  you will need to create a  WorkloadGroup  that acts as template for each  WorkloadEntry  instance    apiVersion  networking istio io v1 kind  WorkloadGroup metadata    name  product vm spec    metadata      labels        app  product   template      serviceAccount  default   probe      httpGet        port  8080   Once a virtual machine has been  configured and added to the mesh   docs setup install virtual machine  configure the virtual machine   a corresponding  WorkloadEntry  will be automatically created by the Istio control plane  For example    apiVersion  networking istio io v1 kind  WorkloadEntry metadata    annotations      istio io autoRegistrationGroup  product vm   labels      app  product   name  product vm 1 2 3 4 spec    address  1 2 3 4   labels      app  product   serviceAccount  default   This  WorkloadEntry  resource describes a single instance of a workload  similar to a pod in Kubernetes  When the workload is removed from the mesh  the  WorkloadEntry  resource will be automatically removed   Additionally  if any probes are configured in the  WorkloadGroup  resource  the Istio control plane automatically updates the health status of associated  WorkloadEntry  instances   In order for consumers to reliably call your workload  it s recommended to declare a  Service  association  This allows clients to reach a stable hostname  like  product default svc cluster local   rather than an ephemeral IP addresses  This also enables you to use advanced routing capabilities in Istio via the  DestinationRule  and  VirtualService  APIs   Any Kubernetes service can transparently select workloads across both pods and virtual machines via the selector fields which are matched with pod and  WorkloadEntry  labels respectively   For example  a  Service  named  product  is composed of a  Pod  and a  WorkloadEntry      With this configuration  requests to  product  would be load balanced across both the pod and virtual machine workload instances      DNS  Kubernetes provides DNS resolution in pods for  Service  names allowing pods to easily communicate with one another by stable hostnames   For virtual machine expansion  Istio provides similar functionality via a  DNS Proxy   docs ops configuration traffic management dns proxy    This feature redirects all DNS queries from the virtual machine workload to the Istio proxy  which maintains a mapping of hostnames to IP addresses   As a result  workloads running on virtual machines can transparently call  Service s  similar to pods  without requiring any additional configuration


istio deployment models pods kubernetes weight 40 sidecar title Application Requirements keywords sidecar injection Requirements of applications deployed in an Istio enabled cluster

Answer:
---
title: Application Requirements
description: Requirements of applications deployed in an Istio-enabled cluster.
weight: 40
keywords:
  - kubernetes
  - sidecar
  - sidecar-injection
  - deployment-models
  - pods
  - setup
aliases:
  - /docs/setup/kubernetes/spec-requirements/
  - /docs/setup/kubernetes/prepare/spec-requirements/
  - /docs/setup/kubernetes/prepare/requirements/
  - /docs/setup/kubernetes/additional-setup/requirements/
  - /docs/setup/additional-setup/requirements
  - /docs/ops/setup/required-pod-capabilities
  - /help/ops/setup/required-pod-capabilities
  - /docs/ops/prep/requirements
  - /docs/ops/deployment/requirements
owner: istio/wg-environments-maintainers
test: n/a
---

Istio provides a great deal of functionality to applications with little or no impact on the application code itself.
Many Kubernetes applications can be deployed in an Istio-enabled cluster without any changes at all.
However, there are some implications of Istio's sidecar model that may need special consideration when deploying
an Istio-enabled application.
This document describes these application considerations and specific requirements of Istio enablement.

## Pod requirements

To be part of a mesh, Kubernetes pods must satisfy the following requirements:

- **Application UIDs**: Ensure your pods do **not** run applications as a user
  with the user ID (UID) value of `1337` because `1337` is reserved for the sidecar proxy.

- **`NET_ADMIN` and `NET_RAW` capabilities**: If [pod security policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/)
    are [enforced](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#enabling-pod-security-policies)
    in your cluster and unless you use the [Istio CNI Plugin](/docs/setup/additional-setup/cni/), your pods must have the
    `NET_ADMIN` and `NET_RAW` capabilities allowed. The initialization containers of the Envoy
    proxies require these capabilities.

    To check if the `NET_ADMIN` and `NET_RAW` capabilities are allowed for your pods, you need to check if their
    [service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)
    can use a pod security policy that allows the `NET_ADMIN` and `NET_RAW` capabilities.
    If you haven't specified a service account in your pods' deployment, the pods run using
    the `default` service account in their deployment's namespace.

    To list the capabilities for a service account, replace `<your namespace>` and `<your service account>`
    with your values in the following command:

    $ for psp in $(kubectl get psp -o jsonpath="{range .items[*]}{@.metadata.name}{'\n'}{end}"); do if [ $(kubectl auth can-i use psp/$psp --as=system:serviceaccount:<your namespace>:<your service account>) = yes ]; then kubectl get psp/$psp --no-headers -o=custom-columns=NAME:.metadata.name,CAPS:.spec.allowedCapabilities; fi; done

    For example, to check for the `default` service account in the `default` namespace, run the following command:

    $ for psp in $(kubectl get psp -o jsonpath="{range .items[*]}{@.metadata.name}{'\n'}{end}"); do if [ $(kubectl auth can-i use psp/$psp --as=system:serviceaccount:default:default) = yes ]; then kubectl get psp/$psp --no-headers -o=custom-columns=NAME:.metadata.name,CAPS:.spec.allowedCapabilities; fi; done

    If you see `NET_ADMIN` and `NET_RAW` or `*` in the list of capabilities of one of the allowed
    policies for your service account, your pods have permission to run the Istio init containers.
    Otherwise, you will need to [provide the permission](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#authorizing-policies).

- **Pod labels**: We recommend explicitly declaring pods with an application identifier and version by using a pod label.
  These labels add contextual information to the metrics and telemetry that Istio collects.
  Each of these values are read from multiple labels ordered from highest to lowest precedence:

    - Application name: `service.istio.io/canonical-name`, `app.kubernetes.io/name`, or `app`.
    - Application version: `service.istio.io/canonical-revision`, `app.kubernetes.io/version`, or `version`.

- **Named service ports**: Service ports may optionally be named to explicitly specify a protocol.
  See [Protocol Selection](/docs/ops/configuration/traffic-management/protocol-selection/) for
  more details. If a pod belongs to multiple [Kubernetes services](https://kubernetes.io/docs/concepts/services-networking/service/),
  the services cannot use the same port number for different protocols, for
  instance HTTP and TCP.

## Ports used by Istio

The following ports and protocols are used by the Istio sidecar proxy (Envoy).

To avoid port conflicts with sidecars, applications should not use any of the ports used by Envoy.

| Port | Protocol | Description | Pod-internal only |
|----|----|----|----|
| 15000 | TCP | Envoy admin port (commands/diagnostics) | Yes |
| 15001 | TCP | Envoy outbound | No |
| 15004 | HTTP | Debug port | Yes |
| 15006 | TCP | Envoy inbound | No |
| 15008 | HTTP2 | HBONE mTLS tunnel port | No |
| 15020 | HTTP | Merged Prometheus telemetry from Istio agent, Envoy, and application | No |
| 15021 | HTTP | Health checks | No |
| 15053 | DNS  | DNS port, if capture is enabled | Yes |
| 15090 | HTTP | Envoy Prometheus telemetry | No |

The following ports and protocols are used by the Istio control plane (istiod).

| Port | Protocol | Description | Local host only |
|----|----|----|----|
| 443 | HTTPS | Webhooks service port | No |
| 8080 | HTTP | Debug interface (deprecated, container port only) | No |
| 15010 | GRPC | XDS and CA services (Plaintext, only for secure networks) | No |
| 15012 | GRPC | XDS and CA services (TLS and mTLS, recommended for production use) | No |
| 15014 | HTTP | Control plane monitoring | No |
| 15017 | HTTPS | Webhook container port, forwarded from 443 | No |

## Server First Protocols

Some protocols are "Server First" protocols, which means the server will send the first bytes. This may have an impact on
[`PERMISSIVE`](/docs/reference/config/security/peer_authentication/#PeerAuthentication-MutualTLS-Mode) mTLS and [Automatic protocol selection](/docs/ops/configuration/traffic-management/protocol-selection/#automatic-protocol-selection).

Both of these features work by inspecting the initial bytes of a connection to determine the protocol, which is incompatible with server first protocols.

In order to support these cases, follow the [Explicit protocol selection](/docs/ops/configuration/traffic-management/protocol-selection/#explicit-protocol-selection) steps to declare the protocol of the application as `TCP`.

The following ports are known to commonly carry server first protocols, and are automatically assumed to be `TCP`:

|Protocol|Port|
|--------|----|
| SMTP   |25  |
| DNS    |53  |
| MySQL  |3306|
| MongoDB|27017|

Because TLS communication is not server first, TLS encrypted server first traffic will work with automatic protocol detection as long as you make sure that all traffic subjected to TLS sniffing is encrypted:

1. Configure `mTLS` mode `STRICT` for the server. This will enforce TLS encryption for all requests.
1. Configure `mTLS` mode `DISABLE` for the server. This will disable the TLS sniffing, allowing server first protocols to be used.
1. Configure all clients to send `TLS` traffic, generally through a [`DestinationRule`](/docs/reference/config/networking/destination-rule/#ClientTLSSettings) or by relying on auto mTLS.
1. Configure your application to send TLS traffic directly.

## Outbound traffic

In order to support Istio's traffic routing capabilities, traffic leaving a pod may be routed differently than
when a sidecar is not deployed.

For HTTP-based traffic, traffic is routed based on the `Host` header. This may lead to unexpected behavior if the destination IP
and `Host` header are not aligned. For example, a request like `curl 1.2.3.4 -H "Host: httpbin.default"` will be routed to the `httpbin` service,
rather than `1.2.3.4`.

For Non HTTP-based traffic (including HTTPS), Istio does not have access to an `Host` header, so routing decisions are based on the Service IP address.

One implication of this is that direct calls to pods (for example, `curl <POD_IP>`), rather than Services, will not be matched. While the traffic may
be [passed through](/docs/tasks/traffic-management/egress/egress-control/#envoy-passthrough-to-external-services), it will not get the full Istio functionality
including mTLS encryption, traffic routing, and telemetry.

See the [Traffic Routing](/docs/ops/configuration/traffic-management/traffic-routing) page for more information.

title  Application Requirements description  Requirements of applications deployed in an Istio enabled cluster  weight  40 keywords      kubernetes     sidecar     sidecar injection     deployment models     pods     setup aliases       docs setup kubernetes spec requirements       docs setup kubernetes prepare spec requirements       docs setup kubernetes prepare requirements       docs setup kubernetes additional setup requirements       docs setup additional setup requirements      docs ops setup required pod capabilities      help ops setup required pod capabilities      docs ops prep requirements      docs ops deployment requirements owner  istio wg environments maintainers test  n a      Istio provides a great deal of functionality to applications with little or no impact on the application code itself  Many Kubernetes applications can be deployed in an Istio enabled cluster without any changes at all  However  there are some implications of Istio s sidecar model that may need special consideration when deploying an Istio enabled application  This document describes these application considerations and specific requirements of Istio enablement      Pod requirements  To be part of a mesh  Kubernetes pods must satisfy the following requirements       Application UIDs    Ensure your pods do   not   run applications as a user   with the user ID  UID  value of  1337  because  1337  is reserved for the sidecar proxy        NET ADMIN  and  NET RAW  capabilities    If  pod security policies  https   kubernetes io docs concepts policy pod security policy       are  enforced  https   kubernetes io docs concepts policy pod security policy  enabling pod security policies      in your cluster and unless you use the  Istio CNI Plugin   docs setup additional setup cni    your pods must have the      NET ADMIN  and  NET RAW  capabilities allowed  The initialization containers of the Envoy     proxies require these capabilities       To check if the  NET ADMIN  and  NET RAW  capabilities are allowed for your pods  you need to check if their      service account  https   kubernetes io docs tasks configure pod container configure service account       can use a pod security policy that allows the  NET ADMIN  and  NET RAW  capabilities      If you haven t specified a service account in your pods  deployment  the pods run using     the  default  service account in their deployment s namespace       To list the capabilities for a service account  replace   your namespace   and   your service account       with your values in the following command              for psp in   kubectl get psp  o jsonpath   range  items       metadata name    n   end     do if     kubectl auth can i use psp  psp   as system serviceaccount  your namespace   your service account     yes    then kubectl get psp  psp   no headers  o custom columns NAME  metadata name CAPS  spec allowedCapabilities  fi  done           For example  to check for the  default  service account in the  default  namespace  run the following command              for psp in   kubectl get psp  o jsonpath   range  items       metadata name    n   end     do if     kubectl auth can i use psp  psp   as system serviceaccount default default    yes    then kubectl get psp  psp   no headers  o custom columns NAME  metadata name CAPS  spec allowedCapabilities  fi  done           If you see  NET ADMIN  and  NET RAW  or     in the list of capabilities of one of the allowed     policies for your service account  your pods have permission to run the Istio init containers      Otherwise  you will need to  provide the permission  https   kubernetes io docs concepts policy pod security policy  authorizing policies        Pod labels    We recommend explicitly declaring pods with an application identifier and version by using a pod label    These labels add contextual information to the metrics and telemetry that Istio collects    Each of these values are read from multiple labels ordered from highest to lowest precedence         Application name   service istio io canonical name    app kubernetes io name   or  app         Application version   service istio io canonical revision    app kubernetes io version   or  version        Named service ports    Service ports may optionally be named to explicitly specify a protocol    See  Protocol Selection   docs ops configuration traffic management protocol selection   for   more details  If a pod belongs to multiple  Kubernetes services  https   kubernetes io docs concepts services networking service      the services cannot use the same port number for different protocols  for   instance HTTP and TCP      Ports used by Istio  The following ports and protocols are used by the Istio sidecar proxy  Envoy     To avoid port conflicts with sidecars  applications should not use any of the ports used by Envoy      Port   Protocol   Description   Pod internal only                           15000   TCP   Envoy admin port  commands diagnostics    Yes     15001   TCP   Envoy outbound   No     15004   HTTP   Debug port   Yes     15006   TCP   Envoy inbound   No     15008   HTTP2   HBONE mTLS tunnel port   No     15020   HTTP   Merged Prometheus telemetry from Istio agent  Envoy  and application   No     15021   HTTP   Health checks   No     15053   DNS    DNS port  if capture is enabled   Yes     15090   HTTP   Envoy Prometheus telemetry   No    The following ports and protocols are used by the Istio control plane  istiod      Port   Protocol   Description   Local host only                           443   HTTPS   Webhooks service port   No     8080   HTTP   Debug interface  deprecated  container port only    No     15010   GRPC   XDS and CA services  Plaintext  only for secure networks    No     15012   GRPC   XDS and CA services  TLS and mTLS  recommended for production use    No     15014   HTTP   Control plane monitoring   No     15017   HTTPS   Webhook container port  forwarded from 443   No       Server First Protocols  Some protocols are  Server First  protocols  which means the server will send the first bytes  This may have an impact on   PERMISSIVE    docs reference config security peer authentication  PeerAuthentication MutualTLS Mode  mTLS and  Automatic protocol selection   docs ops configuration traffic management protocol selection  automatic protocol selection    Both of these features work by inspecting the initial bytes of a connection to determine the protocol  which is incompatible with server first protocols   In order to support these cases  follow the  Explicit protocol selection   docs ops configuration traffic management protocol selection  explicit protocol selection  steps to declare the protocol of the application as  TCP    The following ports are known to commonly carry server first protocols  and are automatically assumed to be  TCP     Protocol Port                    SMTP    25      DNS     53      MySQL   3306    MongoDB 27017   Because TLS communication is not server first  TLS encrypted server first traffic will work with automatic protocol detection as long as you make sure that all traffic subjected to TLS sniffing is encrypted   1  Configure  mTLS  mode  STRICT  for the server  This will enforce TLS encryption for all requests  1  Configure  mTLS  mode  DISABLE  for the server  This will disable the TLS sniffing  allowing server first protocols to be used  1  Configure all clients to send  TLS  traffic  generally through a   DestinationRule    docs reference config networking destination rule  ClientTLSSettings  or by relying on auto mTLS  1  Configure your application to send TLS traffic directly      Outbound traffic  In order to support Istio s traffic routing capabilities  traffic leaving a pod may be routed differently than when a sidecar is not deployed   For HTTP based traffic  traffic is routed based on the  Host  header  This may lead to unexpected behavior if the destination IP and  Host  header are not aligned  For example  a request like  curl 1 2 3 4  H  Host  httpbin default   will be routed to the  httpbin  service  rather than  1 2 3 4    For Non HTTP based traffic  including HTTPS   Istio does not have access to an  Host  header  so routing decisions are based on the Service IP address   One implication of this is that direct calls to pods  for example   curl  POD IP     rather than Services  will not be matched  While the traffic may be  passed through   docs tasks traffic management egress egress control  envoy passthrough to external services   it will not get the full Istio functionality including mTLS encryption  traffic routing  and telemetry   See the  Traffic Routing   docs ops configuration traffic management traffic routing  page for more information


istio docs ops architecture aliases weight 10 title Architecture owner istio wg environments maintainers Describes Istio s high level architecture and design goals docs concepts architecture test n a

Answer:
---
title: Architecture
description: Describes Istio's high-level architecture and design goals.
weight: 10
aliases:
  - /docs/concepts/architecture
  - /docs/ops/architecture
owner: istio/wg-environments-maintainers
test: n/a
---

An Istio service mesh is logically split into a **data plane** and a **control
plane**.

* The **data plane** is composed of a set of intelligent proxies
  ([Envoy](https://www.envoyproxy.io/)) deployed as sidecars. These proxies
  mediate and control all network communication between microservices. They
  also collect and report telemetry on all mesh traffic.

* The **control plane** manages and configures the proxies to route traffic.

The following diagram shows the different components that make up each plane:

## Components

The following sections provide a brief overview of each of Istio's core components.

### Envoy

Istio uses an extended version of the
[Envoy](https://www.envoyproxy.io/) proxy. Envoy is a high-performance
proxy developed in C++ to mediate all inbound and outbound traffic for all
services in the service mesh.
Envoy proxies are the only Istio components that interact with data plane
traffic.

Envoy proxies are deployed as sidecars to services, logically
augmenting the services with Envoy’s many built-in features,
for example:

* Dynamic service discovery
* Load balancing
* TLS termination
* HTTP/2 and gRPC proxies
* Circuit breakers
* Health checks
* Staged rollouts with %-based traffic split
* Fault injection
* Rich metrics

This sidecar deployment allows Istio to enforce policy decisions and extract
rich telemetry which can be sent to monitoring systems to provide information
about the behavior of the entire mesh.

The sidecar proxy model also allows you to add Istio capabilities to an
existing deployment without requiring you to rearchitect or rewrite code.

Some of the Istio features and tasks enabled by Envoy proxies include:

* Traffic control features: enforce fine-grained traffic control with rich
  routing rules for HTTP, gRPC, WebSocket, and TCP traffic.

* Network resiliency features: setup retries, failovers, circuit breakers, and
  fault injection.

* Security and authentication features: enforce security policies and enforce
  access control and rate limiting defined through the configuration API.

* Pluggable extensions model based on WebAssembly that allows for custom policy
  enforcement and telemetry generation for mesh traffic.

### Istiod

Istiod provides service discovery, configuration and certificate management.

Istiod converts high level routing rules that control traffic behavior into
Envoy-specific configurations, and propagates them to the sidecars at runtime.
It abstracts platform-specific service discovery mechanisms and synthesizes
them into a standard format that any sidecar conforming with the
[Envoy API](https://www.envoyproxy.io/docs/envoy/latest/api/api) can consume.

Istio can support discovery for multiple environments such as Kubernetes or VMs.

You can use Istio's
[Traffic Management API](/docs/concepts/traffic-management/#introducing-istio-traffic-management)
to instruct Istiod to refine the Envoy configuration to exercise more granular control
over the traffic in your service mesh.

Istiod [security](/docs/concepts/security/) enables strong service-to-service and
end-user authentication with built-in identity and credential management. You
can use Istio to upgrade unencrypted traffic in the service mesh. Using
Istio, operators can enforce policies based on service identity rather than
on relatively unstable layer 3 or layer 4 network identifiers.
Additionally, you can use [Istio's authorization feature](/docs/concepts/security/#authorization)
to control who can access your services.

Istiod acts as a Certificate Authority (CA) and generates certificates to allow
secure mTLS communication in the data plane.

title  Architecture description  Describes Istio s high level architecture and design goals  weight  10 aliases       docs concepts architecture      docs ops architecture owner  istio wg environments maintainers test  n a      An Istio service mesh is logically split into a   data plane   and a   control plane       The   data plane   is composed of a set of intelligent proxies     Envoy  https   www envoyproxy io    deployed as sidecars  These proxies   mediate and control all network communication between microservices  They   also collect and report telemetry on all mesh traffic     The   control plane   manages and configures the proxies to route traffic   The following diagram shows the different components that make up each plane        Components  The following sections provide a brief overview of each of Istio s core components       Envoy  Istio uses an extended version of the  Envoy  https   www envoyproxy io   proxy  Envoy is a high performance proxy developed in C   to mediate all inbound and outbound traffic for all services in the service mesh  Envoy proxies are the only Istio components that interact with data plane traffic   Envoy proxies are deployed as sidecars to services  logically augmenting the services with Envoy s many built in features  for example     Dynamic service discovery   Load balancing   TLS termination   HTTP 2 and gRPC proxies   Circuit breakers   Health checks   Staged rollouts with   based traffic split   Fault injection   Rich metrics  This sidecar deployment allows Istio to enforce policy decisions and extract rich telemetry which can be sent to monitoring systems to provide information about the behavior of the entire mesh   The sidecar proxy model also allows you to add Istio capabilities to an existing deployment without requiring you to rearchitect or rewrite code   Some of the Istio features and tasks enabled by Envoy proxies include     Traffic control features  enforce fine grained traffic control with rich   routing rules for HTTP  gRPC  WebSocket  and TCP traffic     Network resiliency features  setup retries  failovers  circuit breakers  and   fault injection     Security and authentication features  enforce security policies and enforce   access control and rate limiting defined through the configuration API     Pluggable extensions model based on WebAssembly that allows for custom policy   enforcement and telemetry generation for mesh traffic       Istiod  Istiod provides service discovery  configuration and certificate management   Istiod converts high level routing rules that control traffic behavior into Envoy specific configurations  and propagates them to the sidecars at runtime  It abstracts platform specific service discovery mechanisms and synthesizes them into a standard format that any sidecar conforming with the  Envoy API  https   www envoyproxy io docs envoy latest api api  can consume   Istio can support discovery for multiple environments such as Kubernetes or VMs   You can use Istio s  Traffic Management API   docs concepts traffic management  introducing istio traffic management  to instruct Istiod to refine the Envoy configuration to exercise more granular control over the traffic in your service mesh   Istiod  security   docs concepts security   enables strong service to service and end user authentication with built in identity and credential management  You can use Istio to upgrade unencrypted traffic in the service mesh  Using Istio  operators can enforce policies based on service identity rather than on relatively unstable layer 3 or layer 4 network identifiers  Additionally  you can use  Istio s authorization feature   docs concepts security  authorization  to control who can access your services   Istiod acts as a Certificate Authority  CA  and generates certificates to allow secure mTLS communication in the data plane


istio Istio performance and scalability summary performance title Performance and Scalability benchmarks weight 30 aliases scalability keywords scale

Answer:
---
title: Performance and Scalability
description: Istio performance and scalability summary.
weight: 30
keywords:
  - performance
  - scalability
  - scale
  - benchmarks
aliases:
  - /docs/performance-and-scalability/overview
  - /docs/performance-and-scalability/microbenchmarks
  - /docs/performance-and-scalability/performance-testing-automation
  - /docs/performance-and-scalability/realistic-app-benchmark
  - /docs/performance-and-scalability/scalability
  - /docs/performance-and-scalability/scenarios
  - /docs/performance-and-scalability/synthetic-benchmarks
  - /docs/concepts/performance-and-scalability
  - /docs/ops/performance-and-scalability
owner: istio/wg-environments-maintainers
test: n/a
---

Istio makes it easy to create a network of deployed services with rich routing,
load balancing, service-to-service authentication, monitoring, and more - all
without any changes to the application code. Istio strives to provide
these benefits with minimal resource overhead and aims to support very
large meshes with high request rates while adding minimal latency.

The Istio data plane components, the Envoy proxies, handle data flowing through
the system. The Istio control plane component, Istiod, configures
the data plane. The data plane and control plane have distinct performance concerns.

## Performance summary for Istio 1.24

The [Istio load tests](https://github.com/istio/tools/tree//perf/load) mesh consists
of **1000** services and **2000** pods in an Istio mesh with 70,000 mesh-wide requests per second.

## Control plane performance

Istiod configures sidecar proxies based on user authored configuration files and the current
state of the system. In a Kubernetes environment, Custom Resource Definitions (CRDs) and deployments
constitute the configuration and state of the system. The Istio configuration objects like gateways and virtual
services, provide the user-authored configuration.
To produce the configuration for the proxies, Istiod processes the combined configuration and system state
from the Kubernetes environment and the user-authored configuration.

The control plane supports thousands of services, spread across thousands of pods with a
similar number of user authored virtual services and other configuration objects.
Istiod's CPU and memory requirements scale with the amount of configurations and possible system states.
The CPU consumption scales with the following factors:

- The rate of deployment changes.
- The rate of configuration changes.
- The number of proxies connecting to Istiod.

However, this part is inherently horizontally scalable.

You can increase the number of Istiod instances to reduce the amount of time it takes for the configuration
to reach all proxies.

At large scale, [configuration scoping](/docs/ops/configuration/mesh/configuration-scoping) is highly recommended.

## Data plane performance

Data plane performance depends on many factors, for example:

- Number of client connections
- Target request rate
- Request size and Response size
- Number of proxy worker threads
- Protocol
- CPU cores
- Various proxy features. In particular, telemetry filters (logging, tracing, and metrics) are known to have a moderate impact.

The latency, throughput, and the proxies' CPU and memory consumption are measured as a function of said factors.

### Sidecar and ztunnel resource usage

Since the sidecar proxy performs additional work on the data path, it consumes CPU
and memory. In Istio 1.24, with 1000 http requests per second containing 1 KB of payload each
- a single sidecar proxy with 2 worker threads consumes about 0.20 vCPU and 60 MB of memory.
- a single waypoint proxy with 2 worker threads consumes about 0.25 vCPU and 60 MB of memory
- a single ztunnel proxy consumes about 0.06 vCPU and 12 MB of memory.

The memory consumption of the proxy depends on the total configuration state the proxy holds.
A large number of listeners, clusters, and routes can increase memory usage.

### Latency

Since Istio adds a sidecar proxy or ztunnel proxy on the data path, latency is an important
consideration.
Every feature Istio adds also adds to the path length inside the proxy and potentially affects latency.

The Envoy proxy collects raw telemetry data after a response is sent to the
client.
The time spent collecting raw telemetry for a request does not contribute to the total time taken to complete that request.
However, since the worker is busy handling the request, the worker won't start handling the next request immediately.
This process adds to the queue wait time of the next request and affects average and tail latencies.
The actual tail latency depends on the traffic pattern.

### Latency for Istio 1.24

In sidecar mode, a request will pass through the client sidecar proxy and then the server sidecar proxy before reaching the server, and vice versa.
In ambient mode, a request will pass through the client node ztunnel and then the server node ztunnel before reaching the server.
With waypoints configured, a request will go through a waypoint proxy between the ztunnels.
The following charts show the P90 and P99 latency of http/1.1 requests traveling through various dataplane modes.
To run the tests, we used a bare-metal cluster of 5 [M3 Large](https://deploy.equinix.com/product/servers/m3-large/) machines and [Flannel](https://github.com/flannel-io/flannel) as the primary CNI.
We obtained these results using the [Istio benchmarks](https://github.com/istio/tools/tree//perf/benchmark) for the `http/1.1` protocol with a 1 KB payload at 500, 750, 1000, 1250, and 1500 requests per second using 4 client connections, 2 proxy workers and mutual TLS enabled.

Note: This testing was performed on the [CNCF Community Infrastructure Lab](https://github.com/cncf/cluster).
Different hardware will give different values.

- `no mesh`: Client pod directly calls the server pod, no pods in Istio service mesh.
- `ambient: L4`: Default ambient mode with the secure L4 overlay
- `ambient: L4+L7` Default ambient mode with the secure L4 overlay and waypoints enabled for the namespace.
- `sidecar` Client and server sidecars.

### Benchmarking tools

Istio uses the following tools for benchmarking

- [`fortio.org`](https://fortio.org/) - a constant throughput load testing tool.
- [`nighthawk`](https://github.com/envoyproxy/nighthawk) - a load testing tool based on Envoy.
- [`isotope`](https://github.com/istio/tools/tree//isotope) - a synthetic application with configurable topology.

title  Performance and Scalability description  Istio performance and scalability summary  weight  30 keywords      performance     scalability     scale     benchmarks aliases       docs performance and scalability overview      docs performance and scalability microbenchmarks      docs performance and scalability performance testing automation      docs performance and scalability realistic app benchmark      docs performance and scalability scalability      docs performance and scalability scenarios      docs performance and scalability synthetic benchmarks      docs concepts performance and scalability      docs ops performance and scalability owner  istio wg environments maintainers test  n a      Istio makes it easy to create a network of deployed services with rich routing  load balancing  service to service authentication  monitoring  and more   all without any changes to the application code  Istio strives to provide these benefits with minimal resource overhead and aims to support very large meshes with high request rates while adding minimal latency   The Istio data plane components  the Envoy proxies  handle data flowing through the system  The Istio control plane component  Istiod  configures the data plane  The data plane and control plane have distinct performance concerns      Performance summary for Istio 1 24  The  Istio load tests  https   github com istio tools tree  perf load  mesh consists of   1000   services and   2000   pods in an Istio mesh with 70 000 mesh wide requests per second      Control plane performance  Istiod configures sidecar proxies based on user authored configuration files and the current state of the system  In a Kubernetes environment  Custom Resource Definitions  CRDs  and deployments constitute the configuration and state of the system  The Istio configuration objects like gateways and virtual services  provide the user authored configuration  To produce the configuration for the proxies  Istiod processes the combined configuration and system state from the Kubernetes environment and the user authored configuration   The control plane supports thousands of services  spread across thousands of pods with a similar number of user authored virtual services and other configuration objects  Istiod s CPU and memory requirements scale with the amount of configurations and possible system states  The CPU consumption scales with the following factors     The rate of deployment changes    The rate of configuration changes    The number of proxies connecting to Istiod   However  this part is inherently horizontally scalable   You can increase the number of Istiod instances to reduce the amount of time it takes for the configuration to reach all proxies   At large scale   configuration scoping   docs ops configuration mesh configuration scoping  is highly recommended      Data plane performance  Data plane performance depends on many factors  for example     Number of client connections   Target request rate   Request size and Response size   Number of proxy worker threads   Protocol   CPU cores   Various proxy features  In particular  telemetry filters  logging  tracing  and metrics  are known to have a moderate impact   The latency  throughput  and the proxies  CPU and memory consumption are measured as a function of said factors       Sidecar and ztunnel resource usage  Since the sidecar proxy performs additional work on the data path  it consumes CPU and memory  In Istio 1 24  with 1000 http requests per second containing 1 KB of payload each   a single sidecar proxy with 2 worker threads consumes about 0 20 vCPU and 60 MB of memory    a single waypoint proxy with 2 worker threads consumes about 0 25 vCPU and 60 MB of memory   a single ztunnel proxy consumes about 0 06 vCPU and 12 MB of memory   The memory consumption of the proxy depends on the total configuration state the proxy holds  A large number of listeners  clusters  and routes can increase memory usage       Latency  Since Istio adds a sidecar proxy or ztunnel proxy on the data path  latency is an important consideration  Every feature Istio adds also adds to the path length inside the proxy and potentially affects latency   The Envoy proxy collects raw telemetry data after a response is sent to the client  The time spent collecting raw telemetry for a request does not contribute to the total time taken to complete that request  However  since the worker is busy handling the request  the worker won t start handling the next request immediately  This process adds to the queue wait time of the next request and affects average and tail latencies  The actual tail latency depends on the traffic pattern       Latency for Istio 1 24  In sidecar mode  a request will pass through the client sidecar proxy and then the server sidecar proxy before reaching the server  and vice versa  In ambient mode  a request will pass through the client node ztunnel and then the server node ztunnel before reaching the server  With waypoints configured  a request will go through a waypoint proxy between the ztunnels  The following charts show the P90 and P99 latency of http 1 1 requests traveling through various dataplane modes  To run the tests  we used a bare metal cluster of 5  M3 Large  https   deploy equinix com product servers m3 large   machines and  Flannel  https   github com flannel io flannel  as the primary CNI  We obtained these results using the  Istio benchmarks  https   github com istio tools tree  perf benchmark  for the  http 1 1  protocol with a 1 KB payload at 500  750  1000  1250  and 1500 requests per second using 4 client connections  2 proxy workers and mutual TLS enabled   Note  This testing was performed on the  CNCF Community Infrastructure Lab  https   github com cncf cluster   Different hardware will give different values    img width  90   style  display  block  margin  auto       src  istio 1 24 0 fortio 90 png      alt  P90 latency vs client connections      caption  P90 latency vs client connections      br  br   img width  90   style  display  block  margin  auto       src  istio 1 24 0 fortio 99 png      alt  P99 latency vs client connections      caption  P99 latency vs client connections      br      no mesh   Client pod directly calls the server pod  no pods in Istio service mesh     ambient  L4   Default ambient mode with the secure L4 overlay    ambient  L4 L7  Default ambient mode with the secure L4 overlay and waypoints enabled for the namespace     sidecar  Client and server sidecars       Benchmarking tools  Istio uses the following tools for benchmarking      fortio org   https   fortio org     a constant throughput load testing tool      nighthawk   https   github com envoyproxy nighthawk    a load testing tool based on Envoy      isotope   https   github com istio tools tree  isotope    a synthetic application with configurable topology