Specify multiple namespaces while querying the cluster

[Miyurz]

Is this a BUG REPORT or FEATURE REQUEST?:
FEATURE REQUEST

/kind feature

What happened:
I want to be able to query multiple namespaces while querying the cluster just like we have the flexibility to add multiple labels to kubectl.

What you expected to happen:
Return resource list running in multiple namespaces

How to reproduce it (as minimally and precisely as possible):

kubectl top pods -n production,kube-system --context ap.k8s.saltside.net

error: invalid namespace: production,kube-system - [a DNS-1123 label must consist of lower case alphanumeric characters or '-', and must start and end with an alphanumeric character (e.g. 'my-name', or '123-abc', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?')]

Anything else we need to know?:

Environment:

• Kubernetes version (use kubectl version):
  $ kubectl version
  Client Version: version.Info{Major:"1", Minor:"9+", GitVersion:"v1.9.0-alpha.0.503+24ad0d211bf97c", GitCommit:"24ad0d211bf97cd5d49a63337a35997fcc943412", GitTreeState:"clean", BuildDate:"2017-09-09T09:18:22Z", GoVersion:"go1.9", Compiler:"gc", Platform:"darwin/amd64"}
  Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.7", GitCommit:"8eb75a5810cba92ccad845ca360cf924f2385881", GitTreeState:"clean", BuildDate:"2017-04-27T09:42:05Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

• Cloud provider or hardware configuration**:
  AWS

• OS (e.g. from /etc/os-release):
  MacOS is the client and the cluster consists of debian jessie machins

[Miyurz]

/sig kubectl

[dixudx]

@Miyurz Currently this is not supported, since all the resources are namspaced.

I don't think we really need this feature. @liggitt WDYT?

[liggitt]

getting individual items across multiple namespaces is unusual, and the impact of making the namespace flag inconsistent across kubectl commands doesn't seem worth it to me

cc @kubernetes/sig-cli-feature-requests

[zatricky]

@liggitt: From a programmatic point of view, true. This is unusual. You can just make two (or more) separate queries. However, from an ops pov, it makes sense that this is something that should "just work".

I was disappointed to realise it wouldn't work as-is. :-/

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[zatricky]

I wouldn't narrow the scope to say that the request is to change the addressability in only certain commands. I cannot imagine any commands where it should be treated differently.

[liggitt]

allowing --namespace to arbitrarily contain multiple namespaces turns every command into needing to run in a loop, and handle partial success. rather than pushing that complexity into every command, I think it is better to invoke kubectl multiple times.

[alahijani]

Bash brace expansion can do it to some degree. Unfortunately you have to use quotes or escape special characters.

eval 'kubectl --context='{context1,context2}' --namespace='{ns1,ns2}' get pod;'
eval kubectl\ --context={context1,context2}\ --namespace={ns1,ns2}\ get\ pod\;

Edit:
A more practical workaround is to use xargs -n1:

echo ns1 ns2 | xargs -n1 kubectl get pod --namespace

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[christianh814]

I'm wondering if we can provide --namespace multiple times. Wouldn't that get rid of the issue of turns every command into needing to run in a loop?

[stefanlasiewski]

@christianh814 No, this isn't possible for reasons stated in #71032. It's an oft-requested feature. For the last 2 years, I do a search about every 6 months to see if it was supported yet, and just happened to see your comment from yesterday.

If you use kubectl --namespace=ns1 --namespace=ns2 ... it will only show you the resources in ns2.

[andrew-ryan-cr]

Looks like this type of behavior is possible, depending on the use case, with field-selectors:
https://kubernetes.io/docs/concepts/overview/working-with-objects/field-selectors/

For example, the command below gets pods from all namespaces, but then excludes pods with the field 'metadata.namespace' equal to kube-system or longhorn-system:
watch kubectl get pods -A --field-selector metadata.namespace!=kube-system,metadata.namespace!=longhorn-system

It is also possible to use multiple includes rather than excludes. It works for my "ops" use-case. Figured I would post this here in case anyone saw this thread and thought it was a dead end.

[stefanlasiewski]

@andrew-ryan-cr That's an great solution, actually.

Would you know how to use multiple includes? This doesn't work for me, for example:

$ kubectl get pods -A --field-selector metadata.namespace==kube-system,metadata.namespace==cattle-system
No resources found

But selecting one does work:

$ kubectl get pods -A --field-selector metadata.namespace==kube-system
kube-system   coredns-1234-abcd                   1/1     Running     0          16h
kube-system   coredns-5678-efgh                   1/1     Running     0          16h
...

[zatricky]

@stefanlasiewski multiple includes don't work because it requires the result to match with both conditions instead of either condition. There have been other requests to allow selectors to specify a regular expression, which would resolve this problem, but that was also rejected.

[Scorito-Dev]

This would be a handy feature, please revisit for 1.23 :)

[mihica123]

I support this request.

[mikedizzle]

This would be a nice to have.

[JakeReise]

Would be helpful to have a call for essentially all-namespaces I have access to. That way I don't need cluster permissions to get resources across multiple namespaces. Can currently cycle through each namespace and gather resource information and store but that does not scale. A single API call to gather these resources would significantly reduce the time it takes to gather resource information. Example being: get routes --all-namespace-with-access would get all routes in namespaces I have access to instead of attempting to get them at the cluster level which is reserved.

[bibin-sebastian]

Yeap . It would be great to apply commands across multiple namespaces without having to do one by one.

[AdamMAtWork]

@liggitt @zatricky The ability to operate on multiple namespaces doesn't need to work for all commands - it'd be sufficient for just "get", since "get" already supports either one namespace or all namespaces.

/reopen

[k8s-ci-robot]

@AdamMAtWork: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

@liggitt @zatricky The ability to operate on multiple namespaces doesn't need to work for all commands - it'd be sufficient for just "get", since "get" already supports either one namespace or all namespaces.

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[Hubro]

My use case for this is that I have deployments across 3 namespaces, and I want to show all deployments, services or pods across these 3 namespaces. If I specify --all-namespaces then I also get a ton of noise from cert-manager, ingress-nginx and kube-system, which I don't want.

A nice workaround would be if I could specify --all-namespaces, then filter by namespace afterwards with a regular expression or pattern, something like:

kubectl get pods --all-namespaces --field-selector "metadata.namespace~*my-project*"

But sadly that's not possible either 😕

[karthik25]

I was also looking for commands to do this, but since I found none, I resorted to this (windows terminal) -

kubectl get po -n namepsace1; echo ""; kubectl get po -n namespace2

[christianh814]

FWIW, I did this with a plugin (so all client side)

#!/bin/bash
#
if [[ ${#*} -eq 0 ]] || [[ ${#3} -eq 0 ]]; then
	echo "Usage: kubectl space -n foo,bar,bazz pods"
	exit 2
fi

#
## toptions
while getopts "n:(namespace)" opts
do
	case "${opts}" in
		n)
			ns="${OPTARG}"
		;;
	esac
done

namespaces=(${ns//,/ })

for namespace in ${namespaces[*]}
do
	echo "------------"
	echo "${namespace}"
	echo "------------"
	kubectl get $3 -n ${namespace}
done
##
##

Saved it as kubectl-space and now I run kubectl space -n foo,bar pods

It's crude (probably will write a better one in go) but it works for what I need now.

[KyleSanderson]

This is incredibly silly to not have in the core product. I constantly try to reference multiple namespaces when scaling a deployment and it doesn't work.

[gamba47]

This is incredibly silly to not have in the core product. I constantly try to reference multiple namespaces when scaling a deployment and it doesn't work.

It's opensource dude.
Can you can share your knowledge and make a PR ?

[Jeansen]

In principle, I have the same wish. But with respect to a uniform CLI and keeping it rock solid, simple and manageable, I agree with #71032 (comment). Only being able to select multiple namespaces in 'get' would make the CLI "unstable". Yes, it is a nice feature. On the other hand, writing a little shell function, creating an alias for it and calling that one instead of kubectl get, isn't really that hard. And with some help of shell scripting one can create all sorts of little helper commands.

[paololazzari]

getting individual items across multiple namespaces is unusual

I don't see why this means a user shouldn't be able to do it

[heover1cks]

As --all-namespaces is supported, I think allowing multiple namespaces for a query also makes sense.