Add a target pod flag for linkerd diagnostics endpoints

[mateiidavid]

What problem are you trying to solve?

In order to debug service discovery communication, we can use linkerd diagnostics endpoints. The command effectively queries the same endpoint as the proxy, and will return the endpoints associated with a service. To communicate with the destination service, an external (out-of-cluster) client is created; this is done through a port-forward.

linkerd2/controller/api/destination/client.go

Lines 31 to 52 in f2ff566

	func NewExternalClient(ctx context.Context, controlPlaneNamespace string, kubeAPI *k8s.KubernetesAPI) (pb.DestinationClient, *grpc.ClientConn, error) {
	portforward, err := k8s.NewPortForward(
	ctx,
	kubeAPI,
	controlPlaneNamespace,
	destinationDeployment,
	"localhost",
	0,
	destinationPort,
	false,
	)
	if err != nil {
	return nil, nil, err
	}
	destinationAddress := portforward.AddressAndPort()
	if err = portforward.Init(); err != nil {
	return nil, nil, err
	}
	return NewClient(destinationAddress)
	}

When dealing with multiple destination pods, however, it can be hard to target only a specific destination container. The port-forward will be random (and heavily dependent on the order of the pods as returned by the k8s api server).

linkerd2/pkg/k8s/portforward.go

Lines 84 to 97 in f2ff566

	for _, pod := range podList.Items {
	if pod.Status.Phase == corev1.PodRunning {
	grandparent, err := getDeploymentForPod(ctx, k8sAPI, pod)
	if err != nil {
	log.Warnf("Failed to get deploy for pod [%s]: %s", pod.Name, err)
	continue
	}
	if grandparent == deployName {
	podName = pod.Name
	break
	}
	}
	}

It would be useful to have a CLI flag that can target a specific pod; this way, multiple instances can be checked separately for errors.

How should the problem be solved?

Add a new flag to linkerd diagnostics endpoints (e.g --destination-pod). When a value is set for this flag, we can port-forward directly to the pod itself (if it exists), instead of fetching the list of pods under the deployment.

Any alternatives you've considered?

The alternative is to port-forward individual pods and use the destination client script. However, people that do not have access to the repository, or have not worked with it enough, may find this method more cumbersome to use.

How would users interact with this feature?

No response

Would you like to work on this feature?

No response