istioctl

Istio configuration command line utility.

Create, list, modify, and delete configuration resources in the Istio system.

Available routing and traffic management configuration types:

[virtualservice gateway destinationrule serviceentry httpapispec httpapispecbinding quotaspec quotaspecbinding servicerole servicerolebinding policy]

See https://istio.io/docs/reference/ for an overview of Istio routing.

istioctl authn

A group of commands used to interact with Istio authentication policies. tls-check

Examples

# Check whether TLS setting are matching between authentication policy and destination rules:
istioctl authn tls-check

istioctl authn tls-check

Requests Pilot to check for what authentication policy and destination rule it uses for each service in service registry, and check if TLS settings are compatible between them.

istioctl authn tls-check [<service>] [flags]

Examples

# Check settings for all known services in the service registry:
istioclt authn tls-check

# Check settings for a specific service
istioclt authn tls-check foo.bar.svc.cluster.local

istioctl context-create

Create a kubeconfig file suitable for use with istioctl in a non kubernetes environment

istioctl context-create --api-server http://<ip>:<port> [flags]

Examples

# Create a config file for the api server.
istioctl context-create --api-server http://127.0.0.1:8080

istioctl create

Create policies and rules

istioctl create [flags]

Examples

istioctl create -f example-routing.yaml

istioctl delete

Delete policies or rules

istioctl delete <type> <name> [<name2> ... <nameN>] [flags]

Examples

# Delete a rule using the definition in example-routing.yaml.
istioctl delete -f example-routing.yaml

# Delete the virtual service bookinfo
istioctl delete virtualservice bookinfo

istioctl deregister

De-registers a service instance

istioctl deregister <svcname> <ip> [flags]

istioctl experimental

Experimental commands that may be modified or deprecated

istioctl experimental convert-ingress

Converts Ingresses into VirtualService configuration on a best effort basis. The output should be considered a starting point for your Istio configuration and probably require some minor modification. Warnings will be generated where configs cannot be converted perfectly. The input must be a Kubernetes Ingress. The conversion of v1alpha1 Istio rules has been removed from istioctl.

istioctl experimental convert-ingress [flags]

Examples

istioctl experimental convert-ingress -f samples/bookinfo/platform/kube/bookinfo-ingress.yaml

istioctl experimental metrics

Prints the metrics for the specified service(s) when running in Kubernetes.

This command finds a Prometheus pod running in the specified istio system namespace. It then executes a series of queries per requested workload to find the following top-level workload metrics: total requests per second, error rate, and request latency at p50, p90, and p99 percentiles. The query results are printed to the console, organized by workload name.

All metrics returned are from server-side reports. This means that latencies and error rates are from the perspective of the service itself and not of an individual client (or aggregate set of clients). Rates and latencies are calculated over a time interval of 1 minute.

istioctl experimental metrics <workload name>...

Examples

# Retrieve workload metrics for productpage-v1 workload
istioctl experimental metrics productpage-v1

# Retrieve workload metrics for various services in the different namespaces
istioctl experimental metrics productpage-v1.foo reviews-v1.bar ratings-v1.baz

istioctl experimental rbac

A group of commands used to interact with Istio RBAC policies. For example, Query whether a specific request is allowed or denied under the current Istio RBAC policies.

Examples

# Query if user test is allowed to GET /v1/health of service rating.
istioctl experimental rbac can -u test GET rating /v1/health

istioctl experimental rbac can

This command lets you query whether a specific request will be allowed or denied under current Istio RBAC policies. It constructs a fake request with the custom subject and action specified in the command line to check if your Istio RBAC policies are working as expected. Note the fake request is only used locally to evaluate the effect of the Istio RBAC policies, no actual request will be issued.

METHOD is the HTTP method being taken, like GET, POST, etc. SERVICE is the short service name the action is being taken on. PATH is the HTTP path within the service.

istioctl experimental rbac can METHOD SERVICE PATH [flags]

Examples

# Query if user test is allowed to GET /v1/health of service rating.
istioctl experimental rbac can -u test GET rating /v1/health

# Query if service product-page is allowed to POST to /data of service rating with label version=dev.
istioctl experimental rbac can -s service=product-page POST rating /data -a version=dev

istioctl gen-deploy

istioctl gen-deploy produces deployment files to run the Istio.

istioctl gen-deploy [flags]

Examples

istioctl gen-deploy --values myvalues.yaml

istioctl get

Retrieve policies and rules

istioctl get <type> [<name>] [flags]

Examples

# List all virtual services
istioctl get virtualservices

# List all destination rules
istioctl get destinationrules

# Get a specific virtual service named bookinfo
istioctl get virtualservice bookinfo

istioctl kube-inject

kube-inject manually injects envoy sidecar into kubernetes workloads. Unsupported resources are left unmodified so it is safe to run kube-inject over a single file that contains multiple Service, ConfigMap, Deployment, etc. definitions for a complex application. Its best to do this when the resource is initially created.

k8s.io/docs/concepts/workloads/pods/pod-overview/#pod-templates is updated for Job, DaemonSet, ReplicaSet, Pod and Deployment YAML resource documents. Support for additional pod-based resource types can be added as necessary.

The Istio project is continually evolving so the Istio sidecar configuration may change unannounced. When in doubt re-run istioctl kube-inject on deployments to get the most up-to-date changes.

To override the sidecar injection template built into istioctl, the parameters --injectConfigFile or --injectConfigMapName can be used. Both options override any other template configuration parameters, eg. --hub and --tag. These options would typically be used with the file/configmap created with a new Istio release.

istioctl kube-inject [flags]

Examples

# Update resources on the fly before applying.
kubectl apply -f <(istioctl kube-inject -f <resource.yaml>)

# Create a persistent version of the deployment with Envoy sidecar
# injected.
istioctl kube-inject -f deployment.yaml -o deployment-injected.yaml

# Update an existing deployment.
kubectl get deployment -o yaml | istioctl kube-inject -f - | kubectl apply -f -

# Create a persistent version of the deployment with Envoy sidecar
# injected configuration from kubernetes configmap 'istio-inject'
istioctl kube-inject -f deployment.yaml -o deployment-injected.yaml --injectConfigMapName istio-inject

istioctl proxy-config

A group of commands used to retrieve information about proxy configuration from the Envoy config dump

Examples

  # Retrieve information about proxy configuration from an Envoy instance.
  istioctl proxy-config <clusters|listeners|routes|bootstap> <pod-name>

istioctl proxy-config bootstrap

Retrieve information about bootstrap configuration for the Envoy instance in the specified pod.

istioctl proxy-config bootstrap <pod-name> [flags]

Examples

  # Retrieve full bootstrap configuration for a given pod from Envoy.
  istioctl proxy-config bootstrap <pod-name>

istioctl proxy-config cluster

Retrieve information about cluster configuration for the Envoy instance in the specified pod.

istioctl proxy-config cluster <pod-name> [flags]

Examples

  # Retrieve summary about cluster configuration for a given pod from Envoy.
  istioctl proxy-config clusters <pod-name>

  # Retrieve cluster summary for clusters with port 9080.
  istioctl proxy-config clusters <pod-name> --port 9080

  # Retrieve full cluster dump for clusters that are inbound with a FQDN of details.default.svc.cluster.local.
  istioctl proxy-config clusters <pod-name> --fqdn details.default.svc.cluster.local --direction inbound -o json

istioctl proxy-config listener

Retrieve information about listener configuration for the Envoy instance in the specified pod.

istioctl proxy-config listener <pod-name> [flags]

Examples

  # Retrieve summary about listener configuration for a given pod from Envoy.
  istioctl proxy-config listeners <pod-name>

  # Retrieve listener summary for listeners with port 9080.
  istioctl proxy-config listeners <pod-name> --port 9080

  # Retrieve full listener dump for HTTP listeners with a wildcard address (0.0.0.0).
  istioctl proxy-config listeners <pod-name> --type HTTP --address 0.0.0.0 -o json

istioctl proxy-config route

Retrieve information about route configuration for the Envoy instance in the specified pod.

istioctl proxy-config route <pod-name> [flags]

Examples

  # Retrieve summary about route configuration for a given pod from Envoy.
  istioctl proxy-config routes <pod-name>

  # Retrieve route summary for route 9080.
  istioctl proxy-config route <pod-name> --name 9080

  # Retrieve full route dump for route 9080
  istioctl proxy-config route <pod-name> --name 9080 -o json

istioctl proxy-status

Retrieves last sent and last acknowledged xDS sync from Pilot to each Envoy in the mesh

istioctl proxy-status [<proxy-name>] [flags]

Examples

# Retrieve sync status for all Envoys in a mesh
	istioctl proxy-status

# Retrieve sync diff for a single Envoy and Pilot
	istioctl proxy-status istio-egressgateway-59585c5b9c-ndc59.istio-system

istioctl register

Registers a service instance (e.g. VM) joining the mesh

istioctl register <svcname> <ip> [name1:]port1 [name2:]port2 ... [flags]

istioctl replace

Replace existing policies and rules

istioctl replace [flags]

Examples

istioctl replace -f example-routing.yaml

istioctl version

Prints out build version information

istioctl version [flags]