viz

viz manages the linkerd-viz extension of Linkerd service mesh.

Subcommands

check

Check the Linkerd Viz extension for potential problems.

The check command will perform a series of checks to validate that the Linkerd Viz extension is configured correctly. If the command encounters a failure it will print additional information about the failure and exit with a non-zero exit code.

Examples

# Check that the viz extension is up and running
linkerd viz check

Flags

dashboard

Open the Linkerd dashboard in a web browser

Check out the architecture docs for a more thorough explanation of what this command does.

Flags

(*) You’ll need to tweak the dashboard’s enforced-host parameter with this value, as explained in the DNS-rebinding protection docs

edges

Display connections between resources, and Linkerd proxy identities.

The RESOURCETYPE argument specifies the type of resource to display edges within.

Examples:

• cronjob
• deploy
• ds
• job
• po
• rc
• rs
• sts

Valid resource types include:

• cronjobs
• daemonsets
• deployments
• jobs
• pods
• replicasets
• replicationcontrollers
• statefulsets

Examples

# Get all edges between pods that either originate from or terminate in the test namespace.
linkerd viz edges po -n test

# Get all edges between pods that either originate from or terminate in the default namespace.
linkerd viz edges po

# Get all edges between pods in all namespaces.
linkerd viz edges po --all-namespaces

Flags

install

Output Kubernetes resources to install linkerd-viz extension.

Examples

# Default install.
linkerd viz install | kubectl apply -f -
 
The installation can be configured by using the --set, --values, --set-string and --set-file flags.
A full list of configurable values can be found at https://www.github.com/linkerd/linkerd2/tree/main/viz/charts/linkerd-viz/README.md

Flags

list

Lists which pods can be tapped

Flags

profile

Output service profile config for Kubernetes based off tap data.

Examples

# Generate a profile by watching live traffic.
linkerd viz profile -n emojivoto web-svc --tap deploy/web --tap-duration 10s --tap-route-limit 5

Flags

routes

The routes command displays per-route service metrics. In order for this information to be available, a service profile must be defined for the service that is receiving the requests. For more information about how to create a service profile, see service profiles. and the profile command reference.

Inbound Metrics

By default, routes displays inbound metrics for a target. In other words, it shows information about requests which are sent to the target and responses which are returned by the target. For example, the command:

linkerd viz routes deploy/webapp

Displays the request volume, success rate, and latency of requests to the webapp deployment. These metrics are from the webapp deployment’s perspective, which means that, for example, these latencies do not include the network latency between a client and the webapp deployment.

Outbound Metrics

If you specify the --to flag then linkerd viz routes displays outbound metrics from the target resource to the resource in the --to flag. In contrast to the inbound metrics, these metrics are from the perspective of the sender. This means that these latencies do include the network latency between the client and the server. For example, the command:

linkerd viz routes deploy/traffic --to deploy/webapp

Displays the request volume, success rate, and latency of requests from traffic to webapp from the perspective of the traffic deployment.

Effective and Actual Metrics

If you are looking at outbound metrics (by specifying the --to flag) you can also supply the -o wide flag to differentiate between effective and actual metrics.

Effective requests are requests which are sent by some client to the Linkerd proxy. Actual requests are requests which the Linkerd proxy sends to some server. If the Linkerd proxy is performing retries, one effective request can translate into more than one actual request. If the Linkerd proxy is not performing retries, effective requests and actual requests will always be equal. When enabling retries, you should expect to see the actual request rate increase and the effective success rate increase. See the retries and timeouts section for more information.

Because retries are only performed on the outbound (client) side, the -o wide flag can only be used when the --to flag is specified.

Examples

# Routes for the webapp service in the test namespace.
linkerd viz routes service/webapp -n test

# Routes for calls from the traffic deployment to the webapp service in the test namespace.
linkerd viz routes deploy/traffic -n test --to svc/webapp

Flags

stat

Display traffic stats about one or many resources.

The RESOURCES argument specifies the target resource(s) to aggregate stats over: (TYPE [NAME] | TYPE/NAME) or (TYPE [NAME1] [NAME2]…) or (TYPE1/NAME1 TYPE2/NAME2…)

Examples:

• cronjob/my-cronjob
• deploy
• deploy/my-deploy
• deploy/ po/
• ds/my-daemonset
• job/my-job
• ns/my-ns
• po/mypod1 rc/my-replication-controller
• po mypod1 mypod2
• rc/my-replication-controller
• rs
• rs/my-replicaset
• sts/my-statefulset
• ts/my-split
• authority
• au/my-authority
• all

Valid resource types include:

• cronjobs
• daemonsets
• deployments
• namespaces
• jobs
• pods
• replicasets
• replicationcontrollers
• statefulsets
• trafficsplits
• authorities (not supported in –from)
• services (not supported in –from)
• servers (not supported in –from)
• serverauthorizations (not supported in –from)
• all (all resource types, not supported in –from or –to)

This command will hide resources that have completed, such as pods that are in the Succeeded or Failed phases. If no resource name is specified, displays stats about all resources of the specified RESOURCETYPE

Examples

# Get all deployments in the test namespace.
linkerd viz stat deployments -n test

# Get the hello1 replication controller in the test namespace.
linkerd viz stat replicationcontrollers hello1 -n test

# Get all namespaces.
linkerd viz stat namespaces

# Get all inbound stats to the web deployment.
linkerd viz stat deploy/web

# Get all inbound stats to the pod1 and pod2 pods
linkerd viz stat po pod1 pod2

# Get all inbound stats to the pod1 pod and the web deployment
linkerd viz stat po/pod1 deploy/web

# Get all pods in all namespaces that call the hello1 deployment in the test namespace.
linkerd viz stat pods --to deploy/hello1 --to-namespace test --all-namespaces

# Get all pods in all namespaces that call the hello1 service in the test namespace.
linkerd viz stat pods --to svc/hello1 --to-namespace test --all-namespaces

# Get the web service. With Services, metrics are generated from the outbound metrics
# of clients, and thus will not include unmeshed client request metrics.
linkerd viz stat svc/web

# Get the web services and metrics for any traffic coming to the service from the hello1 deployment
# in the test namespace.
linkerd viz stat svc/web --from deploy/hello1 --from-namespace test

# Get the web services and metrics for all the traffic that reaches the web-pod1 pod
# in the test namespace exclusively.
linkerd viz stat svc/web --to pod/web-pod1 --to-namespace test

# Get all services in all namespaces that receive calls from hello1 deployment in the test namespace.
linkerd viz stat services --from deploy/hello1 --from-namespace test --all-namespaces

# Get all trafficsplits and their leaf services.
linkerd viz stat ts

# Get the hello-split trafficsplit and its leaf services.
linkerd viz stat ts/hello-split

# Get all trafficsplits and their leaf services, and metrics for any traffic coming to the leaf services from the hello1 deployment.
linkerd viz stat ts --from deploy/hello1

# Get all namespaces that receive traffic from the default namespace.
linkerd viz stat namespaces --from ns/default

# Get all inbound stats to the test namespace.
linkerd viz stat ns/test

# Get all inbound stats to the emoji-grpc server
linkerd viz stat server/emoji-grpc

# Get all inbound stats to the web-public server authorization resource
linkerd viz stat serverauthorization/web-public

Flags

tap

Listen to a traffic stream.

The RESOURCE argument specifies the target resource(s) to tap: (TYPE [NAME] | TYPE/NAME)

Examples:

• cronjob/my-cronjob
• deploy
• deploy/my-deploy
• deploy my-deploy
• ds/my-daemonset
• job/my-job
• ns/my-ns
• rs
• rs/my-replicaset
• sts
• sts/my-statefulset

Valid resource types include:

• cronjobs
• daemonsets
• deployments
• jobs
• namespaces
• pods
• replicasets
• replicationcontrollers
• statefulsets
• services (only supported as a –to resource)

Examples

# tap the web deployment in the default namespace
linkerd viz tap deploy/web

# tap the web-dlbvj pod in the default namespace
linkerd viz tap pod/web-dlbvj

# tap the test namespace, filter by request to prod namespace
linkerd viz tap ns/test --to ns/prod

Flags

top

Display sorted information about live traffic.

The RESOURCE argument specifies the target resource(s) to view traffic for: (TYPE [NAME] | TYPE/NAME)

Examples:

• cronjob/my-cronjob
• deploy
• deploy/my-deploy
• deploy my-deploy
• ds/my-daemonset
• job/my-job
• ns/my-ns
• rs
• rs/my-replicaset
• sts
• sts/my-statefulset

Valid resource types include:

• cronjobs
• daemonsets
• deployments
• jobs
• namespaces
• pods
• replicasets
• replicationcontrollers
• statefulsets
• services (only supported as a –to resource)

Examples

# display traffic for the web deployment in the default namespace
linkerd viz top deploy/web

# display traffic for the web-dlbvj pod in the default namespace
linkerd viz top pod/web-dlbvj

Flags

uninstall

Output Kubernetes resources to uninstall the linkerd-viz extension.

This command provides all Kubernetes namespace-scoped and cluster-scoped resources (e.g services, deployments, RBACs, etc.) necessary to uninstall the Linkerd-viz extension.

Examples

linkerd viz uninstall | kubectl delete -f -