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
β
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
@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. :-/
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
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
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.
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.
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\;
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
Closed #52326.
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
?
β
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
@christianh814 No, this isn't possible for reasons stated in #71032. It's an oft-requested feature. I came here to see if it was supported yet, and just happened to see your comment.
If you use kubectl --namespace=ns1 --namespace=ns2 ...
it will only show you the resources in ns2
.
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.
@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
...
@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.
This would be a handy feature, please revisit for 1.23 :)
β
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
I support this request.
β
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are on a team that was mentioned.
This would be a nice to have.
β
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are on a team that was mentioned.
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.
β
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are on a team that was mentioned.
Yeap . It would be great to apply commands across multiple namespaces without having to do one by one.
β
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are on a team that was mentioned.
@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
β
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
@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.
β
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
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 π
β
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
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
β
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
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.
β
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
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.
β
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
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, you can share your knowledge and make a PR ?
β
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
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.
β
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
getting individual items across multiple namespaces is unusual
I don't see why this means a user shouldn't be able to do it
β
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
As --all-namespaces
is supported, I think allowing multiple namespaces for a query also makes sense.
β
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
A shame this request is closed it would have been handy.
β
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
Absolutely a useful feature that I've been missing for a few years now.
β
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
I don't think this is an unusual request. I manage many multi-tenant kubernetes clusters. Teams would like to list pods across the namespaces they own. Without the ability to get resources against a slice of namespaces, teams would have to be given the ability to list pods across all namespaces. One team shouldn't be able to list the pods of another team.
If kubectl get pods -A
functioned in a way that it would only list pods in the namespaces a config had access to, that would be great.
β
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
+1
β
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
+1
β
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
Very useful feature when using multi-tenant clusters.
β
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.
+1
β
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are on a team that was mentioned.