istio title Managing In Mesh Certificates linktitle Managing In Mesh Certificates weight 30 keywords traffic management proxy owner istio wg networking maintainers istio wg environments maintainers How to configure certificates within your mesh test n a

Answer:
---
title: Managing In-Mesh Certificates
linktitle: Managing In-Mesh Certificates
description: How to configure certificates within your mesh.
weight: 30
keywords: [traffic-management,proxy]
owner: istio/wg-networking-maintainers,istio/wg-environments-maintainers
test: n/a
---

Many users need to manage the types of the certificates used within their environment. For example,
some users require the use of Elliptical Curve Cryptography (ECC) while others may need to use a
stronger bit length for RSA certificates. Configuring certificates within your environment can be
a daunting task for most users.

This document is only intended to be used for in-mesh communication. For managing certificates at
your Gateway, see the [Secure Gateways](/docs/tasks/traffic-management/ingress/secure-ingress/) document.
For managing the CA used by istiod to generate workload certificates, see
the [Plugin CA Certificates](/docs/tasks/security/cert-management/plugin-ca-cert/) document.

## istiod

When Istio is installed without a root CA certificate, istiod will generate a self-signed
CA certificate using RSA 2048.

To change the self-signed CA certificate's bit length, you will need to modify either the IstioOperator manifest provided to
`istioctl` or the values file used during the Helm installation of the [istio-discovery](/manifests/charts/istio-control/istio-discovery) chart.

While there are many environment variables that can be changed for
[pilot-discovery](/docs/reference/commands/pilot-discovery/), this document will only
outline some of them.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    pilot:
      env:
        CITADEL_SELF_SIGNED_CA_RSA_KEY_SIZE: 4096

pilot:
  env:
    CITADEL_SELF_SIGNED_CA_RSA_KEY_SIZE: 4096

## Sidecars

Since sidecars manage their own certificates for in-mesh communication, the sidecars
are responsible for managing their private keys and generated Certificate Signing Request (CSRs). The sidecar
injector needs to be modified to inject the environment variables to be used for
this purpose.

While there are many environment variables that can be changed for
[pilot-agent](/docs/reference/commands/pilot-agent/), this document will only
outline some of them.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    defaultConfig:
      proxyMetadata:
        CITADEL_SELF_SIGNED_CA_RSA_KEY_SIZE: 4096

meshConfig:
  defaultConfig:
    proxyMetadata:
      CITADEL_SELF_SIGNED_CA_RSA_KEY_SIZE: 4096

apiVersion: apps/v1
kind: Deployment
metadata:
  name: curl
spec:
  ...
  template:
    metadata:
      ...
      annotations:
        ...
        proxy.istio.io/config: |
          CITADEL_SELF_SIGNED_CA_RSA_KEY_SIZE: 4096
    spec:
      ...

### Signature Algorithm

By default, the sidecars will create RSA certificates. If you want to change it to
ECC, you need to set `ECC_SIGNATURE_ALGORITHM` to `ECDSA`.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    defaultConfig:
      proxyMetadata:
        ECC_SIGNATURE_ALGORITHM: "ECDSA"

meshConfig:
  defaultConfig:
    proxyMetadata:
      ECC_SIGNATURE_ALGORITHM: "ECDSA"

Only P256 and P384 are supported via `ECC_CURVE`.

If you prefer to retain RSA signature algorithms and want to modify the RSA key size,
you can change the value of `WORKLOAD_RSA_KEY_SIZE`.

title  Managing In Mesh Certificates linktitle  Managing In Mesh Certificates description  How to configure certificates within your mesh  weight  30 keywords   traffic management proxy  owner  istio wg networking maintainers istio wg environments maintainers test  n a        Many users need to manage the types of the certificates used within their environment  For example  some users require the use of Elliptical Curve Cryptography  ECC  while others may need to use a stronger bit length for RSA certificates  Configuring certificates within your environment can be a daunting task for most users   This document is only intended to be used for in mesh communication  For managing certificates at your Gateway  see the  Secure Gateways   docs tasks traffic management ingress secure ingress   document  For managing the CA used by istiod to generate workload certificates  see the  Plugin CA Certificates   docs tasks security cert management plugin ca cert   document      istiod  When Istio is installed without a root CA certificate  istiod will generate a self signed CA certificate using RSA 2048   To change the self signed CA certificate s bit length  you will need to modify either the IstioOperator manifest provided to  istioctl  or the values file used during the Helm installation of the  istio discovery   manifests charts istio control istio discovery  chart    While there are many environment variables that can be changed for  pilot discovery   docs reference commands pilot discovery    this document will only outline some of them         apiVersion  install istio io v1alpha1 kind  IstioOperator spec    values      pilot        env          CITADEL SELF SIGNED CA RSA KEY SIZE  4096        pilot    env      CITADEL SELF SIGNED CA RSA KEY SIZE  4096          Sidecars  Since sidecars manage their own certificates for in mesh communication  the sidecars are responsible for managing their private keys and generated Certificate Signing Request  CSRs   The sidecar injector needs to be modified to inject the environment variables to be used for this purpose    While there are many environment variables that can be changed for  pilot agent   docs reference commands pilot agent    this document will only outline some of them         apiVersion  install istio io v1alpha1 kind  IstioOperator spec    meshConfig      defaultConfig        proxyMetadata          CITADEL SELF SIGNED CA RSA KEY SIZE  4096        meshConfig    defaultConfig      proxyMetadata        CITADEL SELF SIGNED CA RSA KEY SIZE  4096        apiVersion  apps v1 kind  Deployment metadata    name  curl spec          template      metadata                  annotations                      proxy istio io config              CITADEL SELF SIGNED CA RSA KEY SIZE  4096     spec                      Signature Algorithm  By default  the sidecars will create RSA certificates  If you want to change it to ECC  you need to set  ECC SIGNATURE ALGORITHM  to  ECDSA         apiVersion  install istio io v1alpha1 kind  IstioOperator spec    meshConfig      defaultConfig        proxyMetadata          ECC SIGNATURE ALGORITHM   ECDSA         meshConfig    defaultConfig      proxyMetadata        ECC SIGNATURE ALGORITHM   ECDSA        Only P256 and P384 are supported via  ECC CURVE    If you prefer to retain RSA signature algorithms and want to modify the RSA key size  you can change the value of  WORKLOAD RSA KEY SIZE


istio is a diagnostic tool that can detect potential issues with your owner istio wg user experience maintainers weight 40 title Diagnose your Configuration with Istioctl Analyze keywords istioctl debugging kubernetes Shows you how to use istioctl analyze to identify potential issues with your configuration test yes

Answer:
---
title: Diagnose your Configuration with Istioctl Analyze
description: Shows you how to use istioctl analyze to identify potential issues with your configuration.
weight: 40
keywords: [istioctl, debugging, kubernetes]
owner: istio/wg-user-experience-maintainers
test: yes
---

`istioctl analyze` is a diagnostic tool that can detect potential issues with your
Istio configuration. It can run against a live cluster or a set of local configuration files.
It can also run against a combination of the two, allowing you to catch problems before you
apply changes to a cluster.

## Getting started in under a minute

You can analyze your current live Kubernetes cluster by running:

$ istioctl analyze --all-namespaces

And that’s it! It’ll give you any recommendations that apply.

For example, if you forgot to enable Istio injection (a very common issue), you would get the following 'Info' message:

Info [IST0102] (Namespace default) The namespace is not enabled for Istio injection. Run 'kubectl label namespace default istio-injection=enabled' to enable it, or 'kubectl label namespace default istio-injection=disabled' to explicitly mark it as not needing injection.

Fix the issue:

$ kubectl label namespace default istio-injection=enabled

Then try again:

$ istioctl analyze --namespace default
✔ No validation issues found when analyzing namespace: default.

## Analyzing live clusters, local files, or both

Analyze the current live cluster, simulating the effect of applying additional yaml files
like `bookinfo-gateway.yaml` and `destination-rule-all.yaml` in the `samples/bookinfo/networking` directory:

$ istioctl analyze @samples/bookinfo/networking/bookinfo-gateway.yaml@ @samples/bookinfo/networking/destination-rule-all.yaml@
Error [IST0101] (Gateway default/bookinfo-gateway samples/bookinfo/networking/bookinfo-gateway.yaml:9) Referenced selector not found: "istio=ingressgateway"
Error [IST0101] (VirtualService default/bookinfo samples/bookinfo/networking/bookinfo-gateway.yaml:41) Referenced host not found: "productpage"
Error: Analyzers found issues when analyzing namespace: default.
See https://istio.io/v/docs/reference/config/analysis for more information about causes and resolutions.

Analyze the entire `networking` folder:

$ istioctl analyze samples/bookinfo/networking/

Analyze all yaml files in the `networking` folder:

$ istioctl analyze samples/bookinfo/networking/*.yaml

The above examples are doing analysis on a live cluster. The tool also supports performing analysis
of a set of local Kubernetes yaml configuration files, or on a combination of local files and a
live cluster. When analyzing a set of local files, the file-set is expected to be fully self-contained.
Typically, this is used to analyze the entire set of configuration files that are intended to be deployed
to a cluster. To use this feature, simply add the `--use-kube=false` flag.

Analyze all yaml files in the `networking` folder:

$ istioctl analyze --use-kube=false samples/bookinfo/networking/*.yaml

You can run `istioctl analyze --help` to see the full set of options.

## Advanced

### Enabling validation messages for resource status

Starting with v1.5, Istio can be set up to perform configuration analysis alongside
the configuration distribution that it is primarily responsible for, via the `istiod.enableAnalysis` flag.
This analysis uses the same logic and error messages as when using `istioctl analyze`.
Validation messages from the analysis are written to the status subresource of the affected Istio resource.

For example. if you have a misconfigured gateway on your "ratings" virtual service,
running `kubectl get virtualservice ratings` would give you something like:

apiVersion: networking.istio.io/v1
kind: VirtualService
...
spec:
  gateways:
  - bogus-gateway
  hosts:
  - ratings
...
status:
  observedGeneration: "1"
  validationMessages:
  - documentationUrl: https://istio.io/v/docs/reference/config/analysis/ist0101/
    level: ERROR
    type:
      code: IST0101

`enableAnalysis` runs in the background, and will keep the status field of a resource up to date
with its current validation status. Note that this isn't a replacement for `istioctl analyze`:

- Not all resources have a custom status field (e.g. Kubernetes `namespace` resources),
  so messages attached to those resources won't show validation messages.
- `enableAnalysis` only works on Istio versions starting with 1.5, while
  `istioctl analyze` can be used with older versions.
- While it makes it easy to see what's wrong with a particular resource,
  it's harder to get a holistic view of validation status in the mesh.

You can enable this feature with:

$ istioctl install --set values.global.istiod.enableAnalysis=true

### Ignoring specific analyzer messages via CLI

Sometimes you might find it useful to hide or ignore analyzer messages in certain cases.
For example, imagine a situation where a message is emitted about a resource you don't have permissions to update:

$ istioctl analyze -k --namespace frod
Info [IST0102] (Namespace frod) The namespace is not enabled for Istio injection. Run 'kubectl label namespace frod istio-injection=enabled' to enable it, or 'kubectl label namespace frod istio-injection=disabled' to explicitly mark it as not needing injection.

Because you don't have permissions to update the namespace, you cannot resolve the message
by annotating the namespace. Instead, you can direct `istioctl analyze` to suppress the above message on the resource:

$ istioctl analyze -k --namespace frod --suppress "IST0102=Namespace frod"
✔ No validation issues found when analyzing namespace: frod.

The syntax used for suppression is the same syntax used throughout `istioctl` when referring to
resources: `<kind> <name>.<namespace>`, or just `<kind> <name>` for cluster-scoped resources like
`Namespace`. If you want to suppress multiple objects, you can either repeat the `--suppress` argument or use wildcards:

$ # Suppress code IST0102 on namespace frod and IST0107 on all pods in namespace baz
$ istioctl analyze -k --all-namespaces --suppress "IST0102=Namespace frod" --suppress "IST0107=Pod *.baz"

### Ignoring specific analyzer messages via annotations

You can also ignore specific analyzer messages using an annotation on the resource.
For example, to ignore code IST0107 (`MisplacedAnnotation`) on resource `deployment/my-deployment`:

$ kubectl annotate deployment my-deployment galley.istio.io/analyze-suppress=IST0107

To ignore multiple codes for a resource, separate each code with a comma:

$ kubectl annotate deployment my-deployment galley.istio.io/analyze-suppress=IST0107,IST0002

## Helping us improve this tool

We're continuing to add more analysis capability and we'd love your help in identifying more use cases.
If you've discovered some Istio configuration "gotcha", some tricky situation that caused you some
problems, open an issue and let us know. We might be able to automatically flag this problem so that
others can discover and avoid the problem in the first place.

To do this, [open an issue](https://github.com/istio/istio/issues) describing your scenario. For example:

- Look at all the virtual services
- For each, look at their list of gateways
- If some of the gateways don’t exist, produce an error

We already have an analyzer for this specific scenario, so this is just an example to illustrate what
kind of information you should provide.

## Q&A

- **What Istio release does this tool target?**

    Like other `istioctl` tools, we generally recommend using a downloaded version
    that matches the version deployed in your cluster.

    For the time being, analysis is generally backwards compatible, so that you can,
    for example, run the  version of `istioctl analyze` against
    a cluster running an older Istio 1.x version and expect to get useful feedback.
    Analysis rules that are not meaningful with an older Istio release will be skipped.

    If you decide to use the latest `istioctl` for analysis purposes on a cluster
    running an older Istio version, we suggest that you keep it in a separate folder
    from the version of the binary used to manage your deployed Istio release.

- **What analyzers are supported today?**

    We're still working to documenting the analyzers. In the meantime, you can see
    all the analyzers in the [Istio source](/pkg/config/analysis/analyzers).

    You can also see what [configuration analysis messages](/docs/reference/config/analysis/)
    are supported to get an idea of what is currently covered.

- **Can analysis do anything harmful to my cluster?**

    Analysis never changes configuration state. It is a completely read-only operation
    that will never alter the state of a cluster.

- **What about analysis that goes beyond configuration?**

    Today, the analysis is purely based on Kubernetes configuration, but in the future
    we’d like to expand beyond that. For example, we could allow analyzers to also look
    at logs to generate recommendations.

- **Where can I find out how to fix the errors I'm getting?**

    The set of [configuration analysis messages](/docs/reference/config/analysis/)
    contains descriptions of each message along with suggested fixes.

title  Diagnose your Configuration with Istioctl Analyze description  Shows you how to use istioctl analyze to identify potential issues with your configuration  weight  40 keywords   istioctl  debugging  kubernetes  owner  istio wg user experience maintainers test  yes       istioctl analyze  is a diagnostic tool that can detect potential issues with your Istio configuration  It can run against a live cluster or a set of local configuration files  It can also run against a combination of the two  allowing you to catch problems before you apply changes to a cluster      Getting started in under a minute  You can analyze your current live Kubernetes cluster by running      istioctl analyze   all namespaces   And that s it  It ll give you any recommendations that apply   For example  if you forgot to enable Istio injection  a very common issue   you would get the following  Info  message    Info  IST0102   Namespace default  The namespace is not enabled for Istio injection  Run  kubectl label namespace default istio injection enabled  to enable it  or  kubectl label namespace default istio injection disabled  to explicitly mark it as not needing injection    Fix the issue      kubectl label namespace default istio injection enabled   Then try again      istioctl analyze   namespace default   No validation issues found when analyzing namespace  default       Analyzing live clusters  local files  or both  Analyze the current live cluster  simulating the effect of applying additional yaml files like  bookinfo gateway yaml  and  destination rule all yaml  in the  samples bookinfo networking  directory      istioctl analyze  samples bookinfo networking bookinfo gateway yaml   samples bookinfo networking destination rule all yaml  Error  IST0101   Gateway default bookinfo gateway samples bookinfo networking bookinfo gateway yaml 9  Referenced selector not found   istio ingressgateway  Error  IST0101   VirtualService default bookinfo samples bookinfo networking bookinfo gateway yaml 41  Referenced host not found   productpage  Error  Analyzers found issues when analyzing namespace  default  See https   istio io v docs reference config analysis for more information about causes and resolutions    Analyze the entire  networking  folder      istioctl analyze samples bookinfo networking    Analyze all yaml files in the  networking  folder      istioctl analyze samples bookinfo networking   yaml   The above examples are doing analysis on a live cluster  The tool also supports performing analysis of a set of local Kubernetes yaml configuration files  or on a combination of local files and a live cluster  When analyzing a set of local files  the file set is expected to be fully self contained  Typically  this is used to analyze the entire set of configuration files that are intended to be deployed to a cluster  To use this feature  simply add the    use kube false  flag   Analyze all yaml files in the  networking  folder      istioctl analyze   use kube false samples bookinfo networking   yaml   You can run  istioctl analyze   help  to see the full set of options      Advanced      Enabling validation messages for resource status    Starting with v1 5  Istio can be set up to perform configuration analysis alongside the configuration distribution that it is primarily responsible for  via the  istiod enableAnalysis  flag  This analysis uses the same logic and error messages as when using  istioctl analyze   Validation messages from the analysis are written to the status subresource of the affected Istio resource   For example  if you have a misconfigured gateway on your  ratings  virtual service  running  kubectl get virtualservice ratings  would give you something like    apiVersion  networking istio io v1 kind  VirtualService     spec    gateways      bogus gateway   hosts      ratings     status    observedGeneration   1    validationMessages      documentationUrl  https   istio io v docs reference config analysis ist0101      level  ERROR     type        code  IST0101    enableAnalysis  runs in the background  and will keep the status field of a resource up to date with its current validation status  Note that this isn t a replacement for  istioctl analyze      Not all resources have a custom status field  e g  Kubernetes  namespace  resources     so messages attached to those resources won t show validation messages     enableAnalysis  only works on Istio versions starting with 1 5  while    istioctl analyze  can be used with older versions    While it makes it easy to see what s wrong with a particular resource    it s harder to get a holistic view of validation status in the mesh   You can enable this feature with      istioctl install   set values global istiod enableAnalysis true       Ignoring specific analyzer messages via CLI  Sometimes you might find it useful to hide or ignore analyzer messages in certain cases  For example  imagine a situation where a message is emitted about a resource you don t have permissions to update      istioctl analyze  k   namespace frod Info  IST0102   Namespace frod  The namespace is not enabled for Istio injection  Run  kubectl label namespace frod istio injection enabled  to enable it  or  kubectl label namespace frod istio injection disabled  to explicitly mark it as not needing injection    Because you don t have permissions to update the namespace  you cannot resolve the message by annotating the namespace  Instead  you can direct  istioctl analyze  to suppress the above message on the resource      istioctl analyze  k   namespace frod   suppress  IST0102 Namespace frod    No validation issues found when analyzing namespace  frod    The syntax used for suppression is the same syntax used throughout  istioctl  when referring to resources    kind   name   namespace    or just   kind   name   for cluster scoped resources like  Namespace   If you want to suppress multiple objects  you can either repeat the    suppress  argument or use wildcards        Suppress code IST0102 on namespace frod and IST0107 on all pods in namespace baz   istioctl analyze  k   all namespaces   suppress  IST0102 Namespace frod    suppress  IST0107 Pod   baz        Ignoring specific analyzer messages via annotations  You can also ignore specific analyzer messages using an annotation on the resource  For example  to ignore code IST0107   MisplacedAnnotation   on resource  deployment my deployment       kubectl annotate deployment my deployment galley istio io analyze suppress IST0107   To ignore multiple codes for a resource  separate each code with a comma      kubectl annotate deployment my deployment galley istio io analyze suppress IST0107 IST0002      Helping us improve this tool  We re continuing to add more analysis capability and we d love your help in identifying more use cases  If you ve discovered some Istio configuration  gotcha   some tricky situation that caused you some problems  open an issue and let us know  We might be able to automatically flag this problem so that others can discover and avoid the problem in the first place   To do this   open an issue  https   github com istio istio issues  describing your scenario  For example     Look at all the virtual services   For each  look at their list of gateways   If some of the gateways don t exist  produce an error  We already have an analyzer for this specific scenario  so this is just an example to illustrate what kind of information you should provide      Q A      What Istio release does this tool target         Like other  istioctl  tools  we generally recommend using a downloaded version     that matches the version deployed in your cluster       For the time being  analysis is generally backwards compatible  so that you can      for example  run the  version of  istioctl analyze  against     a cluster running an older Istio 1 x version and expect to get useful feedback      Analysis rules that are not meaningful with an older Istio release will be skipped       If you decide to use the latest  istioctl  for analysis purposes on a cluster     running an older Istio version  we suggest that you keep it in a separate folder     from the version of the binary used to manage your deployed Istio release       What analyzers are supported today         We re still working to documenting the analyzers  In the meantime  you can see     all the analyzers in the  Istio source   pkg config analysis analyzers        You can also see what  configuration analysis messages   docs reference config analysis       are supported to get an idea of what is currently covered       Can analysis do anything harmful to my cluster         Analysis never changes configuration state  It is a completely read only operation     that will never alter the state of a cluster       What about analysis that goes beyond configuration         Today  the analysis is purely based on Kubernetes configuration  but in the future     we d like to expand beyond that  For example  we could allow analyzers to also look     at logs to generate recommendations       Where can I find out how to fix the errors I m getting         The set of  configuration analysis messages   docs reference config analysis       contains descriptions of each message along with suggested fixes


istio weight 20 keywords debug proxy status config pilot envoy aliases owner istio wg user experience maintainers Describes tools and techniques to diagnose Envoy configuration issues related to traffic management title Debugging Envoy and Istiod help ops misc help ops troubleshooting proxy cmd help ops traffic management proxy cmd

Answer:
---
title: Debugging Envoy and Istiod
description: Describes tools and techniques to diagnose Envoy configuration issues related to traffic management.
weight: 20
keywords: [debug,proxy,status,config,pilot,envoy]
aliases:
    - /help/ops/traffic-management/proxy-cmd
    - /help/ops/misc
    - /help/ops/troubleshooting/proxy-cmd
owner: istio/wg-user-experience-maintainers
test: no
---

Istio provides two very valuable commands to help diagnose traffic management configuration problems,
the [`proxy-status`](/docs/reference/commands/istioctl/#istioctl-proxy-status)
and [`proxy-config`](/docs/reference/commands/istioctl/#istioctl-proxy-config) commands. The `proxy-status` command
allows you to get an overview of your mesh and identify the proxy causing the problem. Then `proxy-config` can be used
to inspect Envoy configuration and diagnose the issue.

If you want to try the commands described below, you can either:

* Have a Kubernetes cluster with Istio and Bookinfo installed (as described in
[installation steps](/docs/setup/getting-started/) and
[Bookinfo installation steps](/docs/examples/bookinfo/#deploying-the-application)).

OR

* Use similar commands against your own application running in a Kubernetes cluster.

## Get an overview of your mesh

The `proxy-status` command allows you to get an overview of your mesh. If you suspect one of your sidecars isn't
receiving configuration or is out of sync then `proxy-status` will tell you this.

$ istioctl proxy-status
NAME                                                   CDS        LDS        EDS        RDS          ISTIOD                      VERSION
details-v1-558b8b4b76-qzqsg.default                    SYNCED     SYNCED     SYNCED     SYNCED       istiod-6cf8d4f9cb-wm7x6     1.7.0
istio-ingressgateway-66c994c45c-cmb7x.istio-system     SYNCED     SYNCED     SYNCED     NOT SENT     istiod-6cf8d4f9cb-wm7x6     1.7.0
productpage-v1-6987489c74-nc7tj.default                SYNCED     SYNCED     SYNCED     SYNCED       istiod-6cf8d4f9cb-wm7x6     1.7.0
prometheus-7bdc59c94d-hcp59.istio-system               SYNCED     SYNCED     SYNCED     SYNCED       istiod-6cf8d4f9cb-wm7x6     1.7.0
ratings-v1-7dc98c7588-5m6xj.default                    SYNCED     SYNCED     SYNCED     SYNCED       istiod-6cf8d4f9cb-wm7x6     1.7.0
reviews-v1-7f99cc4496-rtsqn.default                    SYNCED     SYNCED     SYNCED     SYNCED       istiod-6cf8d4f9cb-wm7x6     1.7.0
reviews-v2-7d79d5bd5d-tj6kf.default                    SYNCED     SYNCED     SYNCED     SYNCED       istiod-6cf8d4f9cb-wm7x6     1.7.0
reviews-v3-7dbcdcbc56-t8wrx.default                    SYNCED     SYNCED     SYNCED     SYNCED       istiod-6cf8d4f9cb-wm7x6     1.7.0

If a proxy is missing from this list it means that it is not currently connected to a Istiod instance so will not be
receiving any configuration.

* `SYNCED` means that Envoy has acknowledged the last configuration Istiod has sent to it.
* `NOT SENT` means that Istiod hasn't sent anything to Envoy. This usually is because Istiod has nothing to send.
* `STALE` means that Istiod has sent an update to Envoy but has not received an acknowledgement. This usually indicates
a networking issue between Envoy and Istiod or a bug with Istio itself.

## Retrieve diffs between Envoy and Istiod

The `proxy-status` command can also be used to retrieve a diff between the configuration Envoy has loaded and the
configuration Istiod would send, by providing a proxy ID. This can help you determine exactly what is out of sync and
where the issue may lie.

$ istioctl proxy-status details-v1-6dcc6fbb9d-wsjz4.default
--- Istiod Clusters
+++ Envoy Clusters
@@ -374,36 +374,14 @@
             "edsClusterConfig": {
                "edsConfig": {
                   "ads": {

                   }
                },
                "serviceName": "outbound|443||public-cr0bdc785ce3f14722918080a97e1f26be-alb1.kube-system.svc.cluster.local"
-            },
-            "connectTimeout": "1.000s",
-            "circuitBreakers": {
-               "thresholds": [
-                  {
-
-                  }
-               ]
-            }
-         }
-      },
-      {
-         "cluster": {
-            "name": "outbound|53||kube-dns.kube-system.svc.cluster.local",
-            "type": "EDS",
-            "edsClusterConfig": {
-               "edsConfig": {
-                  "ads": {
-
-                  }
-               },
-               "serviceName": "outbound|53||kube-dns.kube-system.svc.cluster.local"
             },
             "connectTimeout": "1.000s",
             "circuitBreakers": {
                "thresholds": [
                   {

                   }

Listeners Match
Routes Match (RDS last loaded at Tue, 04 Aug 2020 11:52:54 IST)

Here you can see that the listeners and routes match but the clusters are out of sync.

## Deep dive into Envoy configuration

The `proxy-config` command can be used to see how a given Envoy instance is configured. This can then be used to
pinpoint any issues you are unable to detect by just looking through your Istio configuration and custom resources.
To get a basic summary of clusters, listeners or routes for a given pod use the command as follows (changing clusters
for listeners or routes when required):

$ istioctl proxy-config cluster -n istio-system istio-ingressgateway-7d6874b48f-qxhn5
SERVICE FQDN                                                               PORT      SUBSET     DIRECTION     TYPE           DESTINATION RULE
BlackHoleCluster                                                           -         -          -             STATIC
agent                                                                      -         -          -             STATIC
details.default.svc.cluster.local                                          9080      -          outbound      EDS            details.default
istio-ingressgateway.istio-system.svc.cluster.local                        80        -          outbound      EDS
istio-ingressgateway.istio-system.svc.cluster.local                        443       -          outbound      EDS
istio-ingressgateway.istio-system.svc.cluster.local                        15021     -          outbound      EDS
istio-ingressgateway.istio-system.svc.cluster.local                        15443     -          outbound      EDS
istiod.istio-system.svc.cluster.local                                      443       -          outbound      EDS
istiod.istio-system.svc.cluster.local                                      853       -          outbound      EDS
istiod.istio-system.svc.cluster.local                                      15010     -          outbound      EDS
istiod.istio-system.svc.cluster.local                                      15012     -          outbound      EDS
istiod.istio-system.svc.cluster.local                                      15014     -          outbound      EDS
kube-dns.kube-system.svc.cluster.local                                     53        -          outbound      EDS
kube-dns.kube-system.svc.cluster.local                                     9153      -          outbound      EDS
kubernetes.default.svc.cluster.local                                       443       -          outbound      EDS
...
productpage.default.svc.cluster.local                                      9080      -          outbound      EDS
prometheus_stats                                                           -         -          -             STATIC
ratings.default.svc.cluster.local                                          9080      -          outbound      EDS
reviews.default.svc.cluster.local                                          9080      -          outbound      EDS
sds-grpc                                                                   -         -          -             STATIC
xds-grpc                                                                   -         -          -             STRICT_DNS
zipkin                                                                     -         -          -             STRICT_DNS

In order to debug Envoy you need to understand Envoy clusters/listeners/routes/endpoints and how they all interact.
We will use the `proxy-config` command with the `-o json` and filtering flags to follow Envoy as it determines where
to send a request from the `productpage` pod to the `reviews` pod at `reviews:9080`.

1. If you query the listener summary on a pod you will notice Istio generates the following listeners:
    * A listener on `0.0.0.0:15006` that receives all inbound traffic to the pod and a listener on `0.0.0.0:15001` that receives all outbound traffic to the pod, then hands the request over to a virtual listener.
    * A virtual listener per service IP, per each non-HTTP for outbound TCP/HTTPS traffic.
    * A virtual listener on the pod IP for each exposed port for inbound traffic.
    * A virtual listener on `0.0.0.0` per each HTTP port for outbound HTTP traffic.

    $ istioctl proxy-config listeners productpage-v1-6c886ff494-7vxhs
    ADDRESS       PORT  MATCH                                            DESTINATION
    10.96.0.10    53    ALL                                              Cluster: outbound|53||kube-dns.kube-system.svc.cluster.local
    0.0.0.0       80    App: HTTP                                        Route: 80
    0.0.0.0       80    ALL                                              PassthroughCluster
    10.100.93.102 443   ALL                                              Cluster: outbound|443||istiod.istio-system.svc.cluster.local
    10.111.121.13 443   ALL                                              Cluster: outbound|443||istio-ingressgateway.istio-system.svc.cluster.local
    10.96.0.1     443   ALL                                              Cluster: outbound|443||kubernetes.default.svc.cluster.local
    10.100.93.102 853   App: HTTP                                        Route: istiod.istio-system.svc.cluster.local:853
    10.100.93.102 853   ALL                                              Cluster: outbound|853||istiod.istio-system.svc.cluster.local
    0.0.0.0       9080  App: HTTP                                        Route: 9080
    0.0.0.0       9080  ALL                                              PassthroughCluster
    0.0.0.0       9090  App: HTTP                                        Route: 9090
    0.0.0.0       9090  ALL                                              PassthroughCluster
    10.96.0.10    9153  App: HTTP                                        Route: kube-dns.kube-system.svc.cluster.local:9153
    10.96.0.10    9153  ALL                                              Cluster: outbound|9153||kube-dns.kube-system.svc.cluster.local
    0.0.0.0       15001 ALL                                              PassthroughCluster
    0.0.0.0       15006 Addr: 10.244.0.22/32:15021                       inbound|15021|mgmt-15021|mgmtCluster
    0.0.0.0       15006 Addr: 10.244.0.22/32:9080                        Inline Route: /*
    0.0.0.0       15006 Trans: tls; App: HTTP TLS; Addr: 0.0.0.0/0       Inline Route: /*
    0.0.0.0       15006 App: HTTP; Addr: 0.0.0.0/0                       Inline Route: /*
    0.0.0.0       15006 App: Istio HTTP Plain; Addr: 10.244.0.22/32:9080 Inline Route: /*
    0.0.0.0       15006 Addr: 0.0.0.0/0                                  InboundPassthroughClusterIpv4
    0.0.0.0       15006 Trans: tls; App: TCP TLS; Addr: 0.0.0.0/0        InboundPassthroughClusterIpv4
    0.0.0.0       15010 App: HTTP                                        Route: 15010
    0.0.0.0       15010 ALL                                              PassthroughCluster
    10.100.93.102 15012 ALL                                              Cluster: outbound|15012||istiod.istio-system.svc.cluster.local
    0.0.0.0       15014 App: HTTP                                        Route: 15014
    0.0.0.0       15014 ALL                                              PassthroughCluster
    0.0.0.0       15021 ALL                                              Inline Route: /healthz/ready*
    10.111.121.13 15021 App: HTTP                                        Route: istio-ingressgateway.istio-system.svc.cluster.local:15021
    10.111.121.13 15021 ALL                                              Cluster: outbound|15021||istio-ingressgateway.istio-system.svc.cluster.local
    0.0.0.0       15090 ALL                                              Inline Route: /stats/prometheus*
    10.111.121.13 15443 ALL                                              Cluster: outbound|15443||istio-ingressgateway.istio-system.svc.cluster.local

1. From the above summary you can see that every sidecar has a listener bound to `0.0.0.0:15006` which is where IP tables routes all inbound pod traffic to and a listener bound to `0.0.0.0:15001` which is where IP tables routes all outbound pod traffic to. The `0.0.0.0:15001` listener hands the request over to the virtual listener that best matches the original destination of the request, if it can find a matching one. Otherwise, it sends the request to the `PassthroughCluster` which connects to the destination directly.

    $ istioctl proxy-config listeners productpage-v1-6c886ff494-7vxhs --port 15001 -o json
    [
        {
            "name": "virtualOutbound",
            "address": {
                "socketAddress": {
                    "address": "0.0.0.0",
                    "portValue": 15001
                }
            },
            "filterChains": [
                {
                    "filters": [
                        {
                            "name": "istio.stats",
                            "typedConfig": {
                                "@type": "type.googleapis.com/udpa.type.v1.TypedStruct",
                                "typeUrl": "type.googleapis.com/envoy.extensions.filters.network.wasm.v3.Wasm",
                                "value": {
                                    "config": {
                                        "configuration": "{\n  \"debug\": \"false\",\n  \"stat_prefix\": \"istio\"\n}\n",
                                        "root_id": "stats_outbound",
                                        "vm_config": {
                                            "code": {
                                                "local": {
                                                    "inline_string": "envoy.wasm.stats"
                                                }
                                            },
                                            "runtime": "envoy.wasm.runtime.null",
                                            "vm_id": "tcp_stats_outbound"
                                        }
                                    }
                                }
                            }
                        },
                        {
                            "name": "envoy.tcp_proxy",
                            "typedConfig": {
                                "@type": "type.googleapis.com/envoy.config.filter.network.tcp_proxy.v2.TcpProxy",
                                "statPrefix": "PassthroughCluster",
                                "cluster": "PassthroughCluster"
                            }
                        }
                    ],
                    "name": "virtualOutbound-catchall-tcp"
                }
            ],
            "trafficDirection": "OUTBOUND",
            "hiddenEnvoyDeprecatedUseOriginalDst": true
        }
    ]

1. Our request is an outbound HTTP request to port `9080` this means it gets handed off to the `0.0.0.0:9080` virtual
listener. This listener then looks up the route configuration in its configured RDS. In this case it will be looking
up route `9080` in RDS configured by Istiod (via ADS).

    $ istioctl proxy-config listeners productpage-v1-6c886ff494-7vxhs -o json --address 0.0.0.0 --port 9080
    ...
    "rds": {
        "configSource": {
            "ads": {},
            "resourceApiVersion": "V3"
        },
        "routeConfigName": "9080"
    }
    ...

1. The `9080` route configuration only has a virtual host for each service. Our request is heading to the reviews
service so Envoy will select the virtual host to which our request matches a domain. Once matched on domain Envoy
looks for the first route that matches the request. In this case we don't have any advanced routing so there is only
one route that matches on everything. This route tells Envoy to send the request to the
`outbound|9080||reviews.default.svc.cluster.local` cluster.

    $ istioctl proxy-config routes productpage-v1-6c886ff494-7vxhs --name 9080 -o json
    [
        {
            "name": "9080",
            "virtualHosts": [
                {
                    "name": "reviews.default.svc.cluster.local:9080",
                    "domains": [
                        "reviews.default.svc.cluster.local",
                        "reviews",
                        "reviews.default.svc",
                        "reviews.default",
                        "10.98.88.0",
                    ],
                    "routes": [
                        {
                            "name": "default",
                            "match": {
                                "prefix": "/"
                            },
                            "route": {
                                "cluster": "outbound|9080||reviews.default.svc.cluster.local",
                                "timeout": "0s",
                            }
                        }
                    ]
    ...

1. This cluster is configured to retrieve the associated endpoints from Istiod (via ADS). So Envoy will then use the
`serviceName` field as a key to look up the list of Endpoints and proxy the request to one of them.

    $ istioctl proxy-config cluster productpage-v1-6c886ff494-7vxhs --fqdn reviews.default.svc.cluster.local -o json
    [
        {
            "name": "outbound|9080||reviews.default.svc.cluster.local",
            "type": "EDS",
            "edsClusterConfig": {
                "edsConfig": {
                    "ads": {},
                    "resourceApiVersion": "V3"
                },
                "serviceName": "outbound|9080||reviews.default.svc.cluster.local"
            },
            "connectTimeout": "10s",
            "circuitBreakers": {
                "thresholds": [
                    {
                        "maxConnections": 4294967295,
                        "maxPendingRequests": 4294967295,
                        "maxRequests": 4294967295,
                        "maxRetries": 4294967295
                    }
                ]
            },
        }
    ]

1. To see the endpoints currently available for this cluster use the `proxy-config` endpoints command.

    $ istioctl proxy-config endpoints productpage-v1-6c886ff494-7vxhs --cluster "outbound|9080||reviews.default.svc.cluster.local"
    ENDPOINT            STATUS      OUTLIER CHECK     CLUSTER
    172.17.0.7:9080     HEALTHY     OK                outbound|9080||reviews.default.svc.cluster.local
    172.17.0.8:9080     HEALTHY     OK                outbound|9080||reviews.default.svc.cluster.local
    172.17.0.9:9080     HEALTHY     OK                outbound|9080||reviews.default.svc.cluster.local

## Inspecting bootstrap configuration

So far we have looked at configuration retrieved (mostly) from Istiod, however Envoy requires some bootstrap configuration that
includes information like where Istiod can be found. To view this use the following command:

$ istioctl proxy-config bootstrap -n istio-system istio-ingressgateway-7d6874b48f-qxhn5
{
    "bootstrap": {
        "node": {
            "id": "router~172.30.86.14~istio-ingressgateway-7d6874b48f-qxhn5.istio-system~istio-system.svc.cluster.local",
            "cluster": "istio-ingressgateway",
            "metadata": {
                    "CLUSTER_ID": "Kubernetes",
                    "EXCHANGE_KEYS": "NAME,NAMESPACE,INSTANCE_IPS,LABELS,OWNER,PLATFORM_METADATA,WORKLOAD_NAME,MESH_ID,SERVICE_ACCOUNT,CLUSTER_ID",
                    "INSTANCE_IPS": "10.244.0.7",
                    "ISTIO_PROXY_SHA": "istio-proxy:f98b7e538920abc408fbc91c22a3b32bc854d9dc",
                    "ISTIO_VERSION": "1.7.0",
                    "LABELS": {
                                "app": "istio-ingressgateway",
                                "chart": "gateways",
                                "heritage": "Tiller",
                                "istio": "ingressgateway",
                                "pod-template-hash": "68bf7d7f94",
                                "release": "istio",
                                "service.istio.io/canonical-name": "istio-ingressgateway",
                                "service.istio.io/canonical-revision": "latest"
                            },
                    "MESH_ID": "cluster.local",
                    "NAME": "istio-ingressgateway-68bf7d7f94-sp226",
                    "NAMESPACE": "istio-system",
                    "OWNER": "kubernetes://apis/apps/v1/namespaces/istio-system/deployments/istio-ingressgateway",
                    "ROUTER_MODE": "sni-dnat",
                    "SDS": "true",
                    "SERVICE_ACCOUNT": "istio-ingressgateway-service-account",
                    "WORKLOAD_NAME": "istio-ingressgateway"
                },
            "userAgentBuildVersion": {
                "version": {
                    "majorNumber": 1,
                    "minorNumber": 15
                },
                "metadata": {
                        "build.type": "RELEASE",
                        "revision.sha": "f98b7e538920abc408fbc91c22a3b32bc854d9dc",
                        "revision.status": "Clean",
                        "ssl.version": "BoringSSL"
                    }
            },
        },
...

## Verifying connectivity to Istiod

Verifying connectivity to Istiod is a useful troubleshooting step. Every proxy container in the service mesh should be able to communicate with Istiod. This can be accomplished in a few simple steps:

1.  Create a `curl` pod:

    $ kubectl create namespace foo
    $ kubectl apply -f <(istioctl kube-inject -f samples/curl/curl.yaml) -n foo

1.  Test connectivity to Istiod using `curl`. The following example invokes the v1 registration API using default Istiod configuration parameters and mutual TLS enabled:

    $ kubectl exec $(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name}) -c curl -n foo -- curl -sS istiod.istio-system:15014/version

You should receive a response listing the version of Istiod.

## What Envoy version is Istio using?

To find out the Envoy version used in deployment, you can `exec` into the container and query the `server_info` endpoint:

$ kubectl exec -it productpage-v1-6b746f74dc-9stvs -c istio-proxy -n default  -- pilot-agent request GET server_info --log_as_json | jq {version}
{
 "version": "2d4ec97f3ac7b3256d060e1bb8aa6c415f5cef63/1.17.0/Clean/RELEASE/BoringSSL"
}

title  Debugging Envoy and Istiod description  Describes tools and techniques to diagnose Envoy configuration issues related to traffic management  weight  20 keywords   debug proxy status config pilot envoy  aliases         help ops traffic management proxy cmd        help ops misc        help ops troubleshooting proxy cmd owner  istio wg user experience maintainers test  no      Istio provides two very valuable commands to help diagnose traffic management configuration problems  the   proxy status    docs reference commands istioctl  istioctl proxy status  and   proxy config    docs reference commands istioctl  istioctl proxy config  commands  The  proxy status  command allows you to get an overview of your mesh and identify the proxy causing the problem  Then  proxy config  can be used to inspect Envoy configuration and diagnose the issue   If you want to try the commands described below  you can either     Have a Kubernetes cluster with Istio and Bookinfo installed  as described in  installation steps   docs setup getting started   and  Bookinfo installation steps   docs examples bookinfo  deploying the application     OR    Use similar commands against your own application running in a Kubernetes cluster      Get an overview of your mesh  The  proxy status  command allows you to get an overview of your mesh  If you suspect one of your sidecars isn t receiving configuration or is out of sync then  proxy status  will tell you this      istioctl proxy status NAME                                                   CDS        LDS        EDS        RDS          ISTIOD                      VERSION details v1 558b8b4b76 qzqsg default                    SYNCED     SYNCED     SYNCED     SYNCED       istiod 6cf8d4f9cb wm7x6     1 7 0 istio ingressgateway 66c994c45c cmb7x istio system     SYNCED     SYNCED     SYNCED     NOT SENT     istiod 6cf8d4f9cb wm7x6     1 7 0 productpage v1 6987489c74 nc7tj default                SYNCED     SYNCED     SYNCED     SYNCED       istiod 6cf8d4f9cb wm7x6     1 7 0 prometheus 7bdc59c94d hcp59 istio system               SYNCED     SYNCED     SYNCED     SYNCED       istiod 6cf8d4f9cb wm7x6     1 7 0 ratings v1 7dc98c7588 5m6xj default                    SYNCED     SYNCED     SYNCED     SYNCED       istiod 6cf8d4f9cb wm7x6     1 7 0 reviews v1 7f99cc4496 rtsqn default                    SYNCED     SYNCED     SYNCED     SYNCED       istiod 6cf8d4f9cb wm7x6     1 7 0 reviews v2 7d79d5bd5d tj6kf default                    SYNCED     SYNCED     SYNCED     SYNCED       istiod 6cf8d4f9cb wm7x6     1 7 0 reviews v3 7dbcdcbc56 t8wrx default                    SYNCED     SYNCED     SYNCED     SYNCED       istiod 6cf8d4f9cb wm7x6     1 7 0   If a proxy is missing from this list it means that it is not currently connected to a Istiod instance so will not be receiving any configuration      SYNCED  means that Envoy has acknowledged the last configuration Istiod has sent to it     NOT SENT  means that Istiod hasn t sent anything to Envoy  This usually is because Istiod has nothing to send     STALE  means that Istiod has sent an update to Envoy but has not received an acknowledgement  This usually indicates a networking issue between Envoy and Istiod or a bug with Istio itself      Retrieve diffs between Envoy and Istiod  The  proxy status  command can also be used to retrieve a diff between the configuration Envoy has loaded and the configuration Istiod would send  by providing a proxy ID  This can help you determine exactly what is out of sync and where the issue may lie      istioctl proxy status details v1 6dcc6fbb9d wsjz4 default     Istiod Clusters     Envoy Clusters     374 36  374 14                  edsClusterConfig                      edsConfig                         ads                                                               serviceName    outbound 443  public cr0bdc785ce3f14722918080a97e1f26be alb1 kube system svc cluster local                                connectTimeout    1 000s                 circuitBreakers                      thresholds                                                                                cluster                   name    outbound 53  kube dns kube system svc cluster local                 type    EDS                 edsClusterConfig                      edsConfig                         ads                                                                serviceName    outbound 53  kube dns kube system svc cluster local                                connectTimeout    1 000s                 circuitBreakers                      thresholds                                                 Listeners Match Routes Match  RDS last loaded at Tue  04 Aug 2020 11 52 54 IST    Here you can see that the listeners and routes match but the clusters are out of sync      Deep dive into Envoy configuration  The  proxy config  command can be used to see how a given Envoy instance is configured  This can then be used to pinpoint any issues you are unable to detect by just looking through your Istio configuration and custom resources  To get a basic summary of clusters  listeners or routes for a given pod use the command as follows  changing clusters for listeners or routes when required       istioctl proxy config cluster  n istio system istio ingressgateway 7d6874b48f qxhn5 SERVICE FQDN                                                               PORT      SUBSET     DIRECTION     TYPE           DESTINATION RULE BlackHoleCluster                                                                                STATIC agent                                                                                STATIC details default svc cluster local                                          9080                 outbound      EDS            details default istio ingressgateway istio system svc cluster local                        80                   outbound      EDS istio ingressgateway istio system svc cluster local                        443                  outbound      EDS istio ingressgateway istio system svc cluster local                        15021                outbound      EDS istio ingressgateway istio system svc cluster local                        15443                outbound      EDS istiod istio system svc cluster local                                      443                  outbound      EDS istiod istio system svc cluster local                                      853                  outbound      EDS istiod istio system svc cluster local                                      15010                outbound      EDS istiod istio system svc cluster local                                      15012                outbound      EDS istiod istio system svc cluster local                                      15014                outbound      EDS kube dns kube system svc cluster local                                     53                   outbound      EDS kube dns kube system svc cluster local                                     9153                 outbound      EDS kubernetes default svc cluster local                                       443                  outbound      EDS     productpage default svc cluster local                                      9080                 outbound      EDS prometheus stats                                                                                STATIC ratings default svc cluster local                                          9080                 outbound      EDS reviews default svc cluster local                                          9080                 outbound      EDS sds grpc                                                                                STATIC xds grpc                                                                                STRICT DNS zipkin                                                                                STRICT DNS   In order to debug Envoy you need to understand Envoy clusters listeners routes endpoints and how they all interact  We will use the  proxy config  command with the   o json  and filtering flags to follow Envoy as it determines where to send a request from the  productpage  pod to the  reviews  pod at  reviews 9080    1  If you query the listener summary on a pod you will notice Istio generates the following listeners        A listener on  0 0 0 0 15006  that receives all inbound traffic to the pod and a listener on  0 0 0 0 15001  that receives all outbound traffic to the pod  then hands the request over to a virtual listener        A virtual listener per service IP  per each non HTTP for outbound TCP HTTPS traffic        A virtual listener on the pod IP for each exposed port for inbound traffic        A virtual listener on  0 0 0 0  per each HTTP port for outbound HTTP traffic              istioctl proxy config listeners productpage v1 6c886ff494 7vxhs     ADDRESS       PORT  MATCH                                            DESTINATION     10 96 0 10    53    ALL                                              Cluster  outbound 53  kube dns kube system svc cluster local     0 0 0 0       80    App  HTTP                                        Route  80     0 0 0 0       80    ALL                                              PassthroughCluster     10 100 93 102 443   ALL                                              Cluster  outbound 443  istiod istio system svc cluster local     10 111 121 13 443   ALL                                              Cluster  outbound 443  istio ingressgateway istio system svc cluster local     10 96 0 1     443   ALL                                              Cluster  outbound 443  kubernetes default svc cluster local     10 100 93 102 853   App  HTTP                                        Route  istiod istio system svc cluster local 853     10 100 93 102 853   ALL                                              Cluster  outbound 853  istiod istio system svc cluster local     0 0 0 0       9080  App  HTTP                                        Route  9080     0 0 0 0       9080  ALL                                              PassthroughCluster     0 0 0 0       9090  App  HTTP                                        Route  9090     0 0 0 0       9090  ALL                                              PassthroughCluster     10 96 0 10    9153  App  HTTP                                        Route  kube dns kube system svc cluster local 9153     10 96 0 10    9153  ALL                                              Cluster  outbound 9153  kube dns kube system svc cluster local     0 0 0 0       15001 ALL                                              PassthroughCluster     0 0 0 0       15006 Addr  10 244 0 22 32 15021                       inbound 15021 mgmt 15021 mgmtCluster     0 0 0 0       15006 Addr  10 244 0 22 32 9080                        Inline Route         0 0 0 0       15006 Trans  tls  App  HTTP TLS  Addr  0 0 0 0 0       Inline Route         0 0 0 0       15006 App  HTTP  Addr  0 0 0 0 0                       Inline Route         0 0 0 0       15006 App  Istio HTTP Plain  Addr  10 244 0 22 32 9080 Inline Route         0 0 0 0       15006 Addr  0 0 0 0 0                                  InboundPassthroughClusterIpv4     0 0 0 0       15006 Trans  tls  App  TCP TLS  Addr  0 0 0 0 0        InboundPassthroughClusterIpv4     0 0 0 0       15010 App  HTTP                                        Route  15010     0 0 0 0       15010 ALL                                              PassthroughCluster     10 100 93 102 15012 ALL                                              Cluster  outbound 15012  istiod istio system svc cluster local     0 0 0 0       15014 App  HTTP                                        Route  15014     0 0 0 0       15014 ALL                                              PassthroughCluster     0 0 0 0       15021 ALL                                              Inline Route   healthz ready      10 111 121 13 15021 App  HTTP                                        Route  istio ingressgateway istio system svc cluster local 15021     10 111 121 13 15021 ALL                                              Cluster  outbound 15021  istio ingressgateway istio system svc cluster local     0 0 0 0       15090 ALL                                              Inline Route   stats prometheus      10 111 121 13 15443 ALL                                              Cluster  outbound 15443  istio ingressgateway istio system svc cluster local       1  From the above summary you can see that every sidecar has a listener bound to  0 0 0 0 15006  which is where IP tables routes all inbound pod traffic to and a listener bound to  0 0 0 0 15001  which is where IP tables routes all outbound pod traffic to  The  0 0 0 0 15001  listener hands the request over to the virtual listener that best matches the original destination of the request  if it can find a matching one  Otherwise  it sends the request to the  PassthroughCluster  which connects to the destination directly              istioctl proxy config listeners productpage v1 6c886ff494 7vxhs   port 15001  o json                              name    virtualOutbound                address                      socketAddress                          address    0 0 0 0                        portValue   15001                                               filterChains                                            filters                                                            name    istio stats                                typedConfig                                       type    type googleapis com udpa type v1 TypedStruct                                    typeUrl    type googleapis com envoy extensions filters network wasm v3 Wasm                                    value                                          config                                              configuration      n    debug      false    n    stat prefix      istio   n  n                                            root id    stats outbound                                            vm config                                                  code                                                      local                                                          inline string    envoy wasm stats                                                                                runtime    envoy wasm runtime null                                                vm id    tcp stats outbound                                                                                name    envoy tcp proxy                                typedConfig                                       type    type googleapis com envoy config filter network tcp proxy v2 TcpProxy                                    statPrefix    PassthroughCluster                                    cluster    PassthroughCluster                                                                                name    virtualOutbound catchall tcp                                                trafficDirection    OUTBOUND                hiddenEnvoyDeprecatedUseOriginalDst   true                       1  Our request is an outbound HTTP request to port  9080  this means it gets handed off to the  0 0 0 0 9080  virtual listener  This listener then looks up the route configuration in its configured RDS  In this case it will be looking up route  9080  in RDS configured by Istiod  via ADS               istioctl proxy config listeners productpage v1 6c886ff494 7vxhs  o json   address 0 0 0 0   port 9080              rds              configSource                  ads                    resourceApiVersion    V3                      routeConfigName    9080                      1  The  9080  route configuration only has a virtual host for each service  Our request is heading to the reviews service so Envoy will select the virtual host to which our request matches a domain  Once matched on domain Envoy looks for the first route that matches the request  In this case we don t have any advanced routing so there is only one route that matches on everything  This route tells Envoy to send the request to the  outbound 9080  reviews default svc cluster local  cluster              istioctl proxy config routes productpage v1 6c886ff494 7vxhs   name 9080  o json                              name    9080                virtualHosts                                            name    reviews default svc cluster local 9080                        domains                              reviews default svc cluster local                            reviews                            reviews default svc                            reviews default                            10 98 88 0                                               routes                                                            name    default                                match                                      prefix                                                                   route                                      cluster    outbound 9080  reviews default svc cluster local                                    timeout    0s                                                                                1  This cluster is configured to retrieve the associated endpoints from Istiod  via ADS   So Envoy will then use the  serviceName  field as a key to look up the list of Endpoints and proxy the request to one of them              istioctl proxy config cluster productpage v1 6c886ff494 7vxhs   fqdn reviews default svc cluster local  o json                              name    outbound 9080  reviews default svc cluster local                type    EDS                edsClusterConfig                      edsConfig                          ads                            resourceApiVersion    V3                                      serviceName    outbound 9080  reviews default svc cluster local                              connectTimeout    10s                circuitBreakers                      thresholds                                                    maxConnections   4294967295                           maxPendingRequests   4294967295                           maxRequests   4294967295                           maxRetries   4294967295                                                                              1  To see the endpoints currently available for this cluster use the  proxy config  endpoints command              istioctl proxy config endpoints productpage v1 6c886ff494 7vxhs   cluster  outbound 9080  reviews default svc cluster local      ENDPOINT            STATUS      OUTLIER CHECK     CLUSTER     172 17 0 7 9080     HEALTHY     OK                outbound 9080  reviews default svc cluster local     172 17 0 8 9080     HEALTHY     OK                outbound 9080  reviews default svc cluster local     172 17 0 9 9080     HEALTHY     OK                outbound 9080  reviews default svc cluster local          Inspecting bootstrap configuration  So far we have looked at configuration retrieved  mostly  from Istiod  however Envoy requires some bootstrap configuration that includes information like where Istiod can be found  To view this use the following command      istioctl proxy config bootstrap  n istio system istio ingressgateway 7d6874b48f qxhn5        bootstrap              node                  id    router 172 30 86 14 istio ingressgateway 7d6874b48f qxhn5 istio system istio system svc cluster local                cluster    istio ingressgateway                metadata                          CLUSTER ID    Kubernetes                        EXCHANGE KEYS    NAME NAMESPACE INSTANCE IPS LABELS OWNER PLATFORM METADATA WORKLOAD NAME MESH ID SERVICE ACCOUNT CLUSTER ID                        INSTANCE IPS    10 244 0 7                        ISTIO PROXY SHA    istio proxy f98b7e538920abc408fbc91c22a3b32bc854d9dc                        ISTIO VERSION    1 7 0                        LABELS                                      app    istio ingressgateway                                    chart    gateways                                    heritage    Tiller                                    istio    ingressgateway                                    pod template hash    68bf7d7f94                                    release    istio                                    service istio io canonical name    istio ingressgateway                                    service istio io canonical revision    latest                                                      MESH ID    cluster local                        NAME    istio ingressgateway 68bf7d7f94 sp226                        NAMESPACE    istio system                        OWNER    kubernetes   apis apps v1 namespaces istio system deployments istio ingressgateway                        ROUTER MODE    sni dnat                        SDS    true                        SERVICE ACCOUNT    istio ingressgateway service account                        WORKLOAD NAME    istio ingressgateway                                  userAgentBuildVersion                      version                          majorNumber   1                       minorNumber   15                                     metadata                              build type    RELEASE                            revision sha    f98b7e538920abc408fbc91c22a3b32bc854d9dc                            revision status    Clean                            ssl version    BoringSSL                                                           Verifying connectivity to Istiod  Verifying connectivity to Istiod is a useful troubleshooting step  Every proxy container in the service mesh should be able to communicate with Istiod  This can be accomplished in a few simple steps   1   Create a  curl  pod              kubectl create namespace foo       kubectl apply  f   istioctl kube inject  f samples curl curl yaml   n foo       1   Test connectivity to Istiod using  curl   The following example invokes the v1 registration API using default Istiod configuration parameters and mutual TLS enabled              kubectl exec   kubectl get pod  l app curl  n foo  o jsonpath   items  metadata name    c curl  n foo    curl  sS istiod istio system 15014 version       You should receive a response listing the version of Istiod      What Envoy version is Istio using   To find out the Envoy version used in deployment  you can  exec  into the container and query the  server info  endpoint      kubectl exec  it productpage v1 6b746f74dc 9stvs  c istio proxy  n default     pilot agent request GET server info   log as json   jq  version      version    2d4ec97f3ac7b3256d060e1bb8aa6c415f5cef63 1 17 0 Clean RELEASE BoringSSL


istio title Understand your Mesh with Istioctl Describe test no weight 30 aliases keywords traffic management istioctl debugging kubernetes docs ops troubleshooting istioctl describe owner istio wg user experience maintainers Shows you how to use istioctl describe to verify the configurations of a pod in your mesh

Answer:
---
title: Understand your Mesh with Istioctl Describe
description: Shows you how to use istioctl describe to verify the configurations of a pod in your mesh.
weight: 30
keywords: [traffic-management, istioctl, debugging, kubernetes]
aliases:
  - /docs/ops/troubleshooting/istioctl-describe
owner: istio/wg-user-experience-maintainers
test: no
---

In Istio 1.3, we included the [`istioctl experimental describe`](/docs/reference/commands/istioctl/#istioctl-experimental-describe-pod)
command. This CLI command provides you with the information needed to understand
the configuration impacting a pod. This guide shows
you how to use this experimental sub-command to see if a pod is in the mesh and
verify its configuration.

The basic usage of the command is as follows:

$ istioctl experimental describe pod <pod-name>[.<namespace>]

Appending a namespace to the pod name has the same affect as using the `-n` option
of `istioctl` to specify a non-default namespace.

Just like all other `istioctl` commands, you can replace `experimental`
with `x` for convenience.

This guide assumes you have deployed the [Bookinfo](/docs/examples/bookinfo/)
sample in your mesh. If you haven't already done so,
[start the application's services](/docs/examples/bookinfo/#start-the-application-services)
and [determine the IP and port of the ingress](/docs/examples/bookinfo/#determine-the-ingress-ip-and-port)
before continuing.

## Verify a pod is in the mesh

The `istioctl describe` command returns a warning if the Envoy
proxy is not present in a pod or if the proxy has not started. Additionally, the command warns
if some of the [Istio requirements for pods](/docs/ops/deployment/application-requirements/)
are not met.

For example, the following command produces a warning indicating a `kube-dns`
pod is not part of the service mesh because it has no sidecar:

$ export KUBE_POD=$(kubectl -n kube-system get pod -l k8s-app=kube-dns -o jsonpath='{.items[0].metadata.name}')
$ istioctl x describe pod -n kube-system $KUBE_POD
Pod: coredns-f9fd979d6-2zsxk
   Pod Ports: 53/UDP (coredns), 53 (coredns), 9153 (coredns)
WARNING: coredns-f9fd979d6-2zsxk is not part of mesh; no Istio sidecar
--------------------
2021-01-22T16:10:14.080091Z     error   klog    an error occurred forwarding 42785 -> 15000: error forwarding port 15000 to pod 692362a4fe313005439a873a1019a62f52ecd02c3de9a0957cd0af8f947866e5, uid : failed to execute portforward in network namespace "/var/run/netns/cni-3c000d0a-fb1c-d9df-8af8-1403e6803c22": failed to dial 15000: dial tcp4 127.0.0.1:15000: connect: connection refused[]
Error: failed to execute command on sidecar: failure running port forward process: Get "http://localhost:42785/config_dump": EOF

The command will not produce such a warning for a pod that is part of the mesh,
the Bookinfo `ratings` service for example, but instead will output the Istio configuration applied to the pod:

$ export RATINGS_POD=$(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}')
$ istioctl experimental describe pod $RATINGS_POD
Pod: ratings-v1-7dc98c7588-8jsbw
   Pod Ports: 9080 (ratings), 15090 (istio-proxy)
--------------------
Service: ratings
   Port: http 9080/HTTP targets pod port 9080

The output shows the following information:

- The ports of the service container in the pod, `9080` for the `ratings` container in this example.
- The ports of the `istio-proxy` container in the pod, `15090` in this example.
- The protocol used by the service in the pod, `HTTP` over port `9080` in this example.

## Verify destination rule configurations

You can use `istioctl describe` to see what
[destination rules](/docs/concepts/traffic-management/#destination-rules) apply to requests
to a pod. For example, apply the Bookinfo
[mutual TLS destination rules](/samples/bookinfo/networking/destination-rule-all-mtls.yaml):

$ kubectl apply -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@

Now describe the `ratings` pod again:

$ istioctl x describe pod $RATINGS_POD
Pod: ratings-v1-f745cf57b-qrxl2
   Pod Ports: 9080 (ratings), 15090 (istio-proxy)
--------------------
Service: ratings
   Port: http 9080/HTTP
DestinationRule: ratings for "ratings"
   Matching subsets: v1
      (Non-matching subsets v2,v2-mysql,v2-mysql-vm)
   Traffic Policy TLS Mode: ISTIO_MUTUAL

The command now shows additional output:

- The `ratings` destination rule applies to request to the `ratings` service.
- The subset of the `ratings` destination rule that matches the pod, `v1` in this example.
- The other subsets defined by the destination rule.
- The pod accepts either HTTP or mutual TLS requests but clients use mutual TLS.

## Verify virtual service configurations

When [virtual services](/docs/concepts/traffic-management/#virtual-services) configure
routes to a pod, `istioctl describe` will also include the routes in its output.
For example, apply the
[Bookinfo virtual services](/samples/bookinfo/networking/virtual-service-all-v1.yaml)
that route all requests to `v1` pods:

$ kubectl apply -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@

Then, describe a pod implementing `v1` of the `reviews` service:

$ export REVIEWS_V1_POD=$(kubectl get pod -l app=reviews,version=v1 -o jsonpath='{.items[0].metadata.name}')
$ istioctl x describe pod $REVIEWS_V1_POD
...
VirtualService: reviews
   1 HTTP route(s)

The output contains similar information to that shown previously for the `ratings` pod,
but it also includes the virtual service's routes to the pod.

The `istioctl describe` command doesn't just show the virtual services impacting the pod.
If a virtual service configures the service host of a pod but no traffic will reach it,
the command's output includes a warning. This case can occur if the virtual service
actually blocks traffic by never routing traffic to the pod's subset. For
example:

$ export REVIEWS_V2_POD=$(kubectl get pod -l app=reviews,version=v2 -o jsonpath='{.items[0].metadata.name}')
$ istioctl x describe pod $REVIEWS_V2_POD
...
VirtualService: reviews
   WARNING: No destinations match pod subsets (checked 1 HTTP routes)
      Route to non-matching subset v1 for (everything)

The warning includes the cause of the problem, how many routes were checked, and
even gives you information about the other routes in place. In this example,
no traffic arrives at the `v2` pod because the route in the virtual service directs all
traffic to the `v1` subset.

If you now delete the Bookinfo destination rules:

$ kubectl delete -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@

You can see another useful feature of `istioctl describe`:

$ istioctl x describe pod $REVIEWS_V1_POD
...
VirtualService: reviews
   WARNING: No destinations match pod subsets (checked 1 HTTP routes)
      Warning: Route to subset v1 but NO DESTINATION RULE defining subsets!

The output shows you that you deleted the destination rule but not the virtual
service that depends on it. The virtual service routes traffic to the `v1`
subset, but there is no destination rule defining the `v1` subset.
Thus, traffic destined for version `v1` can't flow to the pod.

If you refresh the browser to send a new request to Bookinfo at this
point, you would see the following message: `Error fetching product reviews`.
To fix the problem, reapply the destination rule:

$ kubectl apply -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@

Reloading the browser shows the app working again and
running `istioctl experimental describe pod $REVIEWS_V1_POD` no longer produces
warnings.

## Verifying traffic routes

The `istioctl describe` command shows split traffic weights too.
For example, run the following command to route 90% of traffic to the `v1` subset
and 10% to the `v2` subset of the `reviews` service:

$ kubectl apply -f @samples/bookinfo/networking/virtual-service-reviews-90-10.yaml@

Now describe the `reviews v1` pod:

$ istioctl x describe pod $REVIEWS_V1_POD
...
VirtualService: reviews
   Weight 90%

The output shows that the `reviews` virtual service has a weight of 90% for the
`v1` subset.

This function is also helpful for other types of routing. For example, you can deploy
header-specific routing:

$ kubectl apply -f @samples/bookinfo/networking/virtual-service-reviews-jason-v2-v3.yaml@

Then, describe the pod again:

$ istioctl x describe pod $REVIEWS_V1_POD
...
VirtualService: reviews
   WARNING: No destinations match pod subsets (checked 2 HTTP routes)
      Route to non-matching subset v2 for (when headers are end-user=jason)
      Route to non-matching subset v3 for (everything)

The output produces a warning since you are describing a pod in the `v1` subset.
However, the virtual service configuration you applied routes traffic to the `v2`
subset if the header contains `end-user=jason` and to the `v3` subset in all
other cases.

## Verifying strict mutual TLS

Following the [mutual TLS migration](/docs/tasks/security/authentication/mtls-migration/)
instructions, you can enable strict mutual TLS for the `ratings` service:

$ kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: ratings-strict
spec:
  selector:
    matchLabels:
      app: ratings
  mtls:
    mode: STRICT
EOF

Run the following command to describe the `ratings` pod:

$ istioctl x describe pod $RATINGS_POD
Pilot reports that pod enforces mTLS and clients speak mTLS

The output reports that requests to the `ratings` pod are now locked down and secure.

Sometimes, however, a deployment breaks when switching mutual TLS to `STRICT`.
The likely cause is that the destination rule didn't match the new configuration.
For example, if you configure the Bookinfo clients to not use mutual TLS using the
[plain HTTP destination rules](/samples/bookinfo/networking/destination-rule-all.yaml):

$ kubectl apply -f @samples/bookinfo/networking/destination-rule-all.yaml@

If you open Bookinfo in your browser, you see `Ratings service is currently unavailable`.
To learn why, run the following command:

$ istioctl x describe pod $RATINGS_POD
...
WARNING Pilot predicts TLS Conflict on ratings-v1-f745cf57b-qrxl2 port 9080 (pod enforces mTLS, clients speak HTTP)
  Check DestinationRule ratings/default and AuthenticationPolicy ratings-strict/default

The output includes a warning describing the conflict
between the destination rule and the authentication policy.

You can restore correct behavior by applying a destination rule that uses
mutual TLS:

$ kubectl apply -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@

## Conclusion and cleanup

Our goal with the `istioctl x describe` command is to help you understand the
traffic and security configurations in your Istio mesh.

We would love to hear your ideas for improvements!
Please join us at [https://discuss.istio.io](https://discuss.istio.io).

To remove the Bookinfo pods and configurations used in this guide, run the
following commands:

$ kubectl delete -f @samples/bookinfo/platform/kube/bookinfo.yaml@
$ kubectl delete -f @samples/bookinfo/networking/bookinfo-gateway.yaml@
$ kubectl delete -f @samples/bookinfo/networking/destination-rule-all-mtls.yaml@
$ kubectl delete -f @samples/bookinfo/networking/virtual-service-all-v1.yaml@

title  Understand your Mesh with Istioctl Describe description  Shows you how to use istioctl describe to verify the configurations of a pod in your mesh  weight  30 keywords   traffic management  istioctl  debugging  kubernetes  aliases       docs ops troubleshooting istioctl describe owner  istio wg user experience maintainers test  no        In Istio 1 3  we included the   istioctl experimental describe    docs reference commands istioctl  istioctl experimental describe pod  command  This CLI command provides you with the information needed to understand the configuration impacting a pod  This guide shows you how to use this experimental sub command to see if a pod is in the mesh and verify its configuration   The basic usage of the command is as follows      istioctl experimental describe pod  pod name    namespace     Appending a namespace to the pod name has the same affect as using the   n  option of  istioctl  to specify a non default namespace    Just like all other  istioctl  commands  you can replace  experimental  with  x  for convenience    This guide assumes you have deployed the  Bookinfo   docs examples bookinfo   sample in your mesh  If you haven t already done so   start the application s services   docs examples bookinfo  start the application services  and  determine the IP and port of the ingress   docs examples bookinfo  determine the ingress ip and port  before continuing      Verify a pod is in the mesh  The  istioctl describe  command returns a warning if the Envoy proxy is not present in a pod or if the proxy has not started  Additionally  the command warns if some of the  Istio requirements for pods   docs ops deployment application requirements   are not met   For example  the following command produces a warning indicating a  kube dns  pod is not part of the service mesh because it has no sidecar      export KUBE POD   kubectl  n kube system get pod  l k8s app kube dns  o jsonpath    items 0  metadata name      istioctl x describe pod  n kube system  KUBE POD Pod  coredns f9fd979d6 2zsxk    Pod Ports  53 UDP  coredns   53  coredns   9153  coredns  WARNING  coredns f9fd979d6 2zsxk is not part of mesh  no Istio sidecar                      2021 01 22T16 10 14 080091Z     error   klog    an error occurred forwarding 42785    15000  error forwarding port 15000 to pod 692362a4fe313005439a873a1019a62f52ecd02c3de9a0957cd0af8f947866e5  uid   failed to execute portforward in network namespace   var run netns cni 3c000d0a fb1c d9df 8af8 1403e6803c22   failed to dial 15000  dial tcp4 127 0 0 1 15000  connect  connection refused   Error  failed to execute command on sidecar  failure running port forward process  Get  http   localhost 42785 config dump   EOF   The command will not produce such a warning for a pod that is part of the mesh  the Bookinfo  ratings  service for example  but instead will output the Istio configuration applied to the pod      export RATINGS POD   kubectl get pod  l app ratings  o jsonpath    items 0  metadata name      istioctl experimental describe pod  RATINGS POD Pod  ratings v1 7dc98c7588 8jsbw    Pod Ports  9080  ratings   15090  istio proxy                       Service  ratings    Port  http 9080 HTTP targets pod port 9080   The output shows the following information     The ports of the service container in the pod   9080  for the  ratings  container in this example    The ports of the  istio proxy  container in the pod   15090  in this example    The protocol used by the service in the pod   HTTP  over port  9080  in this example      Verify destination rule configurations  You can use  istioctl describe  to see what  destination rules   docs concepts traffic management  destination rules  apply to requests to a pod  For example  apply the Bookinfo  mutual TLS destination rules   samples bookinfo networking destination rule all mtls yaml       kubectl apply  f  samples bookinfo networking destination rule all mtls yaml    Now describe the  ratings  pod again      istioctl x describe pod  RATINGS POD Pod  ratings v1 f745cf57b qrxl2    Pod Ports  9080  ratings   15090  istio proxy                       Service  ratings    Port  http 9080 HTTP DestinationRule  ratings for  ratings     Matching subsets  v1        Non matching subsets v2 v2 mysql v2 mysql vm     Traffic Policy TLS Mode  ISTIO MUTUAL   The command now shows additional output     The  ratings  destination rule applies to request to the  ratings  service    The subset of the  ratings  destination rule that matches the pod   v1  in this example    The other subsets defined by the destination rule    The pod accepts either HTTP or mutual TLS requests but clients use mutual TLS      Verify virtual service configurations  When  virtual services   docs concepts traffic management  virtual services  configure routes to a pod   istioctl describe  will also include the routes in its output  For example  apply the  Bookinfo virtual services   samples bookinfo networking virtual service all v1 yaml  that route all requests to  v1  pods      kubectl apply  f  samples bookinfo networking virtual service all v1 yaml    Then  describe a pod implementing  v1  of the  reviews  service      export REVIEWS V1 POD   kubectl get pod  l app reviews version v1  o jsonpath    items 0  metadata name      istioctl x describe pod  REVIEWS V1 POD     VirtualService  reviews    1 HTTP route s    The output contains similar information to that shown previously for the  ratings  pod  but it also includes the virtual service s routes to the pod   The  istioctl describe  command doesn t just show the virtual services impacting the pod  If a virtual service configures the service host of a pod but no traffic will reach it  the command s output includes a warning  This case can occur if the virtual service actually blocks traffic by never routing traffic to the pod s subset  For example      export REVIEWS V2 POD   kubectl get pod  l app reviews version v2  o jsonpath    items 0  metadata name      istioctl x describe pod  REVIEWS V2 POD     VirtualService  reviews    WARNING  No destinations match pod subsets  checked 1 HTTP routes        Route to non matching subset v1 for  everything    The warning includes the cause of the problem  how many routes were checked  and even gives you information about the other routes in place  In this example  no traffic arrives at the  v2  pod because the route in the virtual service directs all traffic to the  v1  subset   If you now delete the Bookinfo destination rules      kubectl delete  f  samples bookinfo networking destination rule all mtls yaml    You can see another useful feature of  istioctl describe       istioctl x describe pod  REVIEWS V1 POD     VirtualService  reviews    WARNING  No destinations match pod subsets  checked 1 HTTP routes        Warning  Route to subset v1 but NO DESTINATION RULE defining subsets    The output shows you that you deleted the destination rule but not the virtual service that depends on it  The virtual service routes traffic to the  v1  subset  but there is no destination rule defining the  v1  subset  Thus  traffic destined for version  v1  can t flow to the pod   If you refresh the browser to send a new request to Bookinfo at this point  you would see the following message   Error fetching product reviews   To fix the problem  reapply the destination rule      kubectl apply  f  samples bookinfo networking destination rule all mtls yaml    Reloading the browser shows the app working again and running  istioctl experimental describe pod  REVIEWS V1 POD  no longer produces warnings      Verifying traffic routes  The  istioctl describe  command shows split traffic weights too  For example  run the following command to route 90  of traffic to the  v1  subset and 10  to the  v2  subset of the  reviews  service      kubectl apply  f  samples bookinfo networking virtual service reviews 90 10 yaml    Now describe the  reviews v1  pod      istioctl x describe pod  REVIEWS V1 POD     VirtualService  reviews    Weight 90    The output shows that the  reviews  virtual service has a weight of 90  for the  v1  subset   This function is also helpful for other types of routing  For example  you can deploy header specific routing      kubectl apply  f  samples bookinfo networking virtual service reviews jason v2 v3 yaml    Then  describe the pod again      istioctl x describe pod  REVIEWS V1 POD     VirtualService  reviews    WARNING  No destinations match pod subsets  checked 2 HTTP routes        Route to non matching subset v2 for  when headers are end user jason        Route to non matching subset v3 for  everything    The output produces a warning since you are describing a pod in the  v1  subset  However  the virtual service configuration you applied routes traffic to the  v2  subset if the header contains  end user jason  and to the  v3  subset in all other cases      Verifying strict mutual TLS  Following the  mutual TLS migration   docs tasks security authentication mtls migration   instructions  you can enable strict mutual TLS for the  ratings  service      kubectl apply  f     EOF apiVersion  security istio io v1 kind  PeerAuthentication metadata    name  ratings strict spec    selector      matchLabels        app  ratings   mtls      mode  STRICT EOF   Run the following command to describe the  ratings  pod      istioctl x describe pod  RATINGS POD Pilot reports that pod enforces mTLS and clients speak mTLS   The output reports that requests to the  ratings  pod are now locked down and secure   Sometimes  however  a deployment breaks when switching mutual TLS to  STRICT   The likely cause is that the destination rule didn t match the new configuration  For example  if you configure the Bookinfo clients to not use mutual TLS using the  plain HTTP destination rules   samples bookinfo networking destination rule all yaml       kubectl apply  f  samples bookinfo networking destination rule all yaml    If you open Bookinfo in your browser  you see  Ratings service is currently unavailable   To learn why  run the following command      istioctl x describe pod  RATINGS POD     WARNING Pilot predicts TLS Conflict on ratings v1 f745cf57b qrxl2 port 9080  pod enforces mTLS  clients speak HTTP    Check DestinationRule ratings default and AuthenticationPolicy ratings strict default   The output includes a warning describing the conflict between the destination rule and the authentication policy   You can restore correct behavior by applying a destination rule that uses mutual TLS      kubectl apply  f  samples bookinfo networking destination rule all mtls yaml       Conclusion and cleanup  Our goal with the  istioctl x describe  command is to help you understand the traffic and security configurations in your Istio mesh   We would love to hear your ideas for improvements  Please join us at  https   discuss istio io  https   discuss istio io    To remove the Bookinfo pods and configurations used in this guide  run the following commands      kubectl delete  f  samples bookinfo platform kube bookinfo yaml    kubectl delete  f  samples bookinfo networking bookinfo gateway yaml    kubectl delete  f  samples bookinfo networking destination rule all mtls yaml    kubectl delete  f  samples bookinfo networking virtual service all v1 yaml