Linkerd2: Linkerd CLI should default to current namespace from kubeconfig

Created on 24 Mar 2020  路  5Comments  路  Source: linkerd/linkerd2

Bug Report

What is the issue?

I'm using kubens to quickly switch the default namespace that kubectl uses. This works by rewriting the current context in ~/.kube/config. For example, executing kubens ingress-nginx means that kubectl get pod nginx-ingress-controller-84dd6b84fd-gcb6x picks up the pod from the ingress-nginx namespace without explicitly specifying it in every kubectl command.

The Linkerd CLI doesn't use this context namespace. For example, linkerd metrics requires the namespace to be explicitly specified:

> linkerd metrics pod/nginx-ingress-controller-84dd6b84fd-gcb6x
Error: pods "nginx-ingress-controller-84dd6b84fd-gcb6x" not found
[..]
> linkerd metrics pod/nginx-ingress-controller-84dd6b84fd-gcb6x -n ingress-nginx
#
# POD nginx-ingress-controller-84dd6b84fd-gcb6x (1 of 1)
#
[..]

Environment

  • Kubernetes Version: v1.17.2
  • Cluster Environment: kind
  • Host OS: Debian Bullseye
  • Linkerd version: edge-20.3.3

Possible solution

Use the namespace from the current context in ~/.kube/config as the default in the Linkerd CLI.

arecli good first issue help wanted

All 5 comments

I'd like to pick this up if nobody else is working on it.

@Matei207 Great! please proceed :+1:

Hi, I have started looking at this issue and would like to discuss a potential solution to see what the rest of the community thinks.

I've looked through the cli commands to see which commands accept a namespace passed as a flag, in total there should be 7 commands that would need to infer the namespace from the kubeConfig context.

We can get namespace of a context from a ClientConfig, e.g:

    rules := clientcmd.NewDefaultClientConfigLoadingRules()
    overrides := &clientcmd.ConfigOverrides{CurrentContext: kubeContext}
    kubeCfg := clientcmd.NewNonInteractiveDeferredLoadingClientConfig(rules, overrides)
    ns, _, err := kubeCfg.Namespace()
    return ns

For each individual command, we change its options from the hardcoded "default" to a call to the above function, e.g:

return &metricsOptions{
    namespace: "default",
    pod:       "",
}

becomes

return &metricsOptions{
    namespace: getNamespaceFromCfgContext(),
    pod:       "",
}

This is how I'd solve it a glance, I'm curious to see if there is an easier solution or a better way to infer the namespace from the context without using any client config loading rules.

Thanks @Matei207, that sounds solid to me :+1: Looking forward for the PR :wink:

Fixed in #4291.

Was this page helpful?
0 / 5 - 0 ratings