kubectl: kubectl get all does not list all resources in a namespace

kubectl get all --namespace tmp is wrong, you may use kubectl get all --n tmp

Why is this closed? Some complex xargs stuff does not mitigate the fact at “all” is indeed a falsehood that does not return all objects.

@liggitt does kubectl api-resources replace the functionality as well or this just means kubectl get all is going to be deprecated and there will not be any support for searching labels in a namespace?

kubectl api-resources enumerates the resource types available in your cluster.

this means you can combine it with kubectl get to actually list every instance of every resource type in a namespace:

kubectl api-resources --verbs=list --namespaced -o name \
  | xargs -n 1 kubectl get --show-kind --ignore-not-found -l <label>=<value> -n <namespace>

/close

Try - kubectl get all --all-namespaces

I’d like to see a documentation improvement, as well as a new ‘type’ to use to actually show all resources in a namespace, as the current meaning of all is both unintuitive and not documented anywhere. Just fixing kubectl wouldn’t help users figure out what’s going on for older versions, so I think a new name (everything ?) would be helpful for retaining consistency with older client versions.

Currently I know that all doesn’t refer to the following types of resources:

• resources which are not namespace (this makes sense… though with --all-namespaces it might be useful to include these): clusterrolebindings, clusterroles, etc.
• configmaps
• rolebindings
• roles

all does refer to the following types of (namespaced) resources:

• pods (though completed pods are still omitted without --show-all
• services
• replicasets
• deployments

This is only a partial list, as I have no way of knowing what are kinds of resources are listed by all

I think there needs to be better documentation around resources in general, and a better explanation of the magic all resource pseudo-type.

its funny how you implement something sloppy and then you have an issue open for 3 years where you make all sorts of excuses why this should stay this way.

Some complex xargs stuff does not mitigate the fact at “all” is indeed a falsehood that does not return all objects.

all will not be extended because of compatibility concerns, and is not referenced in help any longer because it is misleading, as you point out

kubectl api-resources --verbs=list --namespaced -o name \
  | xargs -n 1 kubectl get --show-kind --ignore-not-found -l <label>=<value> -n <namespace>

This also has the disadvantages of not only being unintuitive, but also slow as hell …

Crazy… Instead of fixing the buggy command they removed it from documentation.

@fabianofranz: Yes, limits are covered there (Rule 2: No namespace admin level resources (limits, quota, policy, authorization rules)).

This leaves me frustrated though:

1. kubectl help get describes kubectl get all as List all resources with different types. so I think I am right to expect all resources to be listed.
2. It might be ok if adminstrative resources are hidden from a normal user. As a cluster admin I need an easy way to see everything in a namespace to decide if i can delete it or not.

kubectl get all --all-namespaces

will list the resources from all the namespace

This really has the capacity to trip-up new (and old) users alike in interesting and frustrating ways. If all isn’t all and never will be all again, surely it has to be deprecated? Is it actually a compatibility issue - is this command porcelain for scripting?

Example of getting caught:

kubectl get all --namespace ns1 (nothing) kubectl get pvc --namespace ns1 (1 pvc is listed)

Ah - so helm delete didn’t remove my persistent volumes … I wish all had told me that.

Meanwhile I worked around the problem by using ketall (it can be installed via krew).

kubectl krew install get-all
kubectl get-all

I know, this isn’t what you’re looking for but it’s not so bad. I hope you’ll find it useful anyway. 😃

/reopen

@stewart-yu: Double dash and short form (kubectl get all --n tmp) doesn’t work!

Both variants below do work: kubectl get all --namespace tmp kubectl get all -n tmp

You can look that up in kubectl options:

...
-n, --namespace='': If present, the namespace scope for this CLI request
...

/close

My current situation is that I have a cluster with some namespaces, I try to delete a namespace and it’s stuck in Terminating state. I know this situation is mentioned in other issues here, but unfortunately those are closed too. I’m not going to ask how to solve this problem, instead I want to invest time and understand what’s going on, if same problem happened with a resource in Linux operating system I could understand why exactly it’s happening by reading logs and running commands and reading their outputs and wouldn’t ask Linus Torvalds about it in Linux git repository. In order to decide that kubernetes is a reliable tool for my company I need to make sure same thing can happen in kubernetes too, I wanna make sure someone can reach to a point with kubernetes that he can solve the unknown problems by reading logs, seeing states of resources, etc instead of creating issues in kubernetes repository and waiting for someone to reply. I think for kubernetes to be considered mature it should be self diagnosable (like Linux with its logs and commands, Python with its shell and pdb, JS with devtools, etc).

So I think it should be in high priority to:

1. Add features like the one mentioned in this issue to the API as soon as possible.
2. Provide workarounds until such features are added, and for those who are using older versions.

For my mentioned problem I thought maybe something in the undeletable namespace is pending another resource in another namespace so I wanted to see all resources in the default namespace to see if my theory makes sense or not. Not being able to list all resources (including custom resources) is really annoying stopped me and a problem that could probably solved by myself by investing time is now only solvable by either opening an issue here and waiting unknown time for someone to answer or invest much more time reading the source code of kubernetes and compile it with debug directives and see what’s going on.

@davidbIQ there are plenty of different answers in this thread, if you can’t find a suitable one, then script one for your self.

@HartS When running kubectl get I’m shown a list of resource types.

That might be a decent place to start for documentation.

For reference I got the below against my v1.10.0 Kube setup.

  * all
  * certificatesigningrequests (aka 'csr')
  * clusterrolebindings
  * clusterroles
  * componentstatuses (aka 'cs')
  * configmaps (aka 'cm')
  * controllerrevisions
  * cronjobs
  * customresourcedefinition (aka 'crd')
  * daemonsets (aka 'ds')
  * deployments (aka 'deploy')
  * endpoints (aka 'ep')
  * events (aka 'ev')
  * horizontalpodautoscalers (aka 'hpa')
  * ingresses (aka 'ing')
  * jobs
  * limitranges (aka 'limits')
  * namespaces (aka 'ns')
  * networkpolicies (aka 'netpol')
  * nodes (aka 'no')
  * persistentvolumeclaims (aka 'pvc')
  * persistentvolumes (aka 'pv')
  * poddisruptionbudgets (aka 'pdb')
  * podpreset
  * pods (aka 'po')
  * podsecuritypolicies (aka 'psp')
  * podtemplates
  * replicasets (aka 'rs')
  * replicationcontrollers (aka 'rc')
  * resourcequotas (aka 'quota')
  * rolebindings
  * roles
  * secrets
  * serviceaccounts (aka 'sa')
  * services (aka 'svc')
  * statefulsets (aka 'sts')
  * storageclasses (aka 'sc')

that also doesn’t work:

error: unable to retrieve the complete list of server APIs: external.metrics.k8s.io/v1beta1: the server is currently unable to handle the request, metrics.k8s.io/v1beta1: the server is currently unable to handle the request

Is there some other literate way to “verb” all by label?

@smarterclayton can you provide a link to the issue?

I’m not concerned about kubernetes not deleting a namespace when I issue kubectl delete namespace <namespace>. I’ve never seen that happen.

I’m concerned about the user interface issue. I expect to be able to list everything (preferrably via kubectl get all, but an alternative command might be ok aswell), so I can make an informed decision.

To me this is the same as being the admin of a linux box without ls -a. On that box I might forget to backup everything that is hidden (including my .profile, and .ssh private keys). In both cases (kubectl and linux box) I’m setting myself up for desaster because it becomes very likely that I loose data at some point in the future.

@qgeffard the short answer is that the “all” special keyword was explicitly removed because it didn’t play well with the way kubectl interacts with CRD categories.

Long answer, read on:

kubectl get has essentially 2 modes:

• kubectl get <concrete kind> returns a list of all objects of a given kind (e.g. kubectl get pod)
• kubectl get <any word> is a fallback which returns all objects of a given category (documentation)

For example, consider that you install a Kubernetes-native solution such as Istio (example picked semi-randomly, simply because it is popular). Now imagine that Istio uses the mechanism of categories mentioned above to tag each of their CRD with the “istio” category. You can now list all Istio-related objects with kubectl get istio. Neat!

Now imagine that some of those category names, like “all”, are reserved. You end up in a situation where a given keyword can have not one, not two, but three (!) different meanings. This is likely to confuse users and CRD authors alike so, instead of reserving some special keywords, it was decided that no category should be treated differently (in other words, “all” is a perfectly valid category as well).

Thankfully, plugins are first-class citizens in kubectl, so special and opinionated features such as the defunct kubectl get all could be / were encouraged to be supported by community-maintained plugins instead. Using the official Krew plugin manager, it is even super easy to search and install such plugins, regardless of the platform you use.

I hope I helped better understand the “why” 🙏

I know it’s a old discussion, but why I arrived here is very simple: I was searching for a simple way to list all the objects created in a namespace, hence, I have found the existence of the all keyword.

This all keyword really makes sens for me. Then I discover that all isn’t listing all kind of objects… Hence my discovery of this ticket!

Honnestly, it’s hard to understand why this keyword was removed from the documentation and never implemented to fully return all kind of objects.

There is no simple alternative.

Agreed on the deprecation comment.

Perhaps instead of breaking backwards compatibility we could allow a glob syntax, so for example *role* would return role,rolebinding,clusterrole,clusterrolebinding and * would return everything. I’m glad that all is no longer a resource, so perhaps we can with this approach distinct between a resource type and syntax.

Soo, can we just close this for now, the answers are already answered through this thread. Thanks

On Wed, 22 Apr 2020, 22:20 Antoine Cotten, notifications@github.com wrote:

@rkand4 https://github.com/rkand4 this is a question for StackOverflow or discuss.kubernetes.io.

The short answer is no. You have to range over all the APIs returned by getAPIVersions https://github.com/kubernetes-client/java/blob/cbc1d385dfa02da38e07e4b22498971b7b464680/kubernetes/docs/ApisApi.md, list the resources inside each returned API (only the preferredVersion of each API), and finally get the objects for these resources in each namespace. There is no shortcut.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kubernetes/kubectl/issues/151#issuecomment-618018025, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH4NODJC44BOSEK7M6BHNKLRN5GSDANCNFSM4EFUKDAQ .

A much faster alternative to using xargs -n1 would be something like this:

kubectl get --show-kind --ignore-not-found $(kubectl api-resources --verbs=list --namespaced -o name | paste -s -d, -) $@

and if you put that into a file called kubectl-everything that has the execute bit and sits somewhere in your path, then you can even do kubectl everything -n mynamespace to list all resources in a specific namespace.

@soltysh: Closing this issue.

kubectl api-resources --verbs=list --namespaced -o name
| xargs -n 1 kubectl get --show-kind --ignore-not-found -l <label>=<value> -n <namespace>

A nifty trickery and all that I’d certainly go for, but api-resources doesn’t exist in kubectl < 1.11. I’m not sure why there’s a debate about the definition of all. All is all, save for any boundaries around security.

I will fix it ASAP

@liggitt does kubectl api-resources replace the functionality as well or this just means kubectl get all is going to be deprecated and there will not be any support for searching labels in a namespace?

kubectl api-resources enumerates the resource types available in your cluster.

this means you can combine it with kubectl get to actually list every instance of every resource type in a namespace:

kubectl api-resources --verbs=list --namespaced -o name \
  | xargs -n 1 kubectl get --show-kind --ignore-not-found -l <label>=<value> -n <namespace>

-Perfect!

I’m going to jump in here and provide feedback that while the xargs stuff is better than nothing, it’s not an option on Windows. And yes, I am aware there are other workaround with Powershell.

The fact this has been broken for several years and it’s just being punted from release to release is immensely frustrating. Replace or remove the all functionality but leaving it languish like this is a terrible user experience.

in 1.11, the help text no longer references all, and instead refers to a new kubectl api-resources command which lists all resources the server you are currently speaking to has:

$ kubectl get
You must specify the type of resource to get. Use "kubectl api-resources" for a complete list of supported resources.

or

$ kubectl get --help
Display one or many resources 

Prints a table of the most important information about the specified resources. You can filter the list using a label
selector and the --selector flag. If the desired resource type is namespaced you will only see results in your current
namespace unless you pass --all-namespaces. 

Uninitialized objects are not shown unless --include-uninitialized is passed. 

By specifying the output as 'template' and providing a Go template as the value of the --template flag, you can filter
the attributes of the fetched resources.

Use "kubectl api-resources" for a complete list of supported resources.

Is there a reason on why the kubectl get-all is not integrated to the native/vanilla kubectl and also documented?

Snippet listing all resources as in @oudream’s comment, with $() speedup from @bdowling’s comment, and with another simplification replacing tr|sed with paste:

kubectl get $(kubectl api-resources --verbs=list -o name | paste -sd, -) --ignore-not-found --all-namespaces

kubectl api-resources -o name | xargs -I {} kubectl get {} --show-kind --ignore-not-found

It’s not a 100% solution, but for me works the following

kgetall='kubectl get namespace,replicaset,secret,nodes,job,daemonset,statefulset,ingress,configmap,pv,pvc,service,deployment,pod --all-namespaces' and just call kgetall But obviously I expected that behavior from kubectl get all --all-namespaces in the first place.

Just to add a workaround for: Error: uninstallation completed with 1 error(s): could not get apiVersions from Kubernetes: could not get apiVersions from Kubernetes: unable to retrieve the complete list of server APIs: external.metrics.k8s.io/v1beta1: the server is currently unable to handle the request

run: kubectl delete apiservice v1beta1.external.metrics.k8s.io

Credits go to: https://twitter.com/abhi_tweeter

@liggitt

This works for me

kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get --show-kind -A 2>/dev/null

Ignore errors

It sounds like the most reasonable time to remove the “all” category would be when the horizontalpodautoscalers formally announce their intent for v2? That way it wouldn’t get blocked for an unknown amount of time with v2 resources, then blocked on v3, etc.

I guess in all of this, what is the end result realistically going to be? Would just ensuring “all” returns everything be easier than trying to get the category deprecated? This limbo area is miserable from a user experience standpoint.

@liggitt @seans3 any updates on getting this functionality removed?

kubectl get all is deceptive and could lead to issues with it’s use.

It should be deprecated and removed or it should be enhanced to actually list all resources in a namespace.

At the very least when the current implementation is used it should display a warning.

Replace or remove the all functionality but leaving it languish like this is a terrible user experience.

The all alias won’t be removed for compatibility reasons but has been removed from command help for several releases. I agree it should not be promoted as it is confusing.

The xargs based command resulted in multiple List resources. The following seems faster, and results in one List of resources.

kinds="$(
for namespaced in "true" "false"; do
  kubectl api-resources --verbs="list" -o name --no-headers --namespaced="${namespaced}"
done | sed -z 's/\n/,/g;s/,$/\n/'
)"

kubectl get "${kinds}" -A -o yaml > all_resources.yaml

This plugin seems to be nice and do the work! My question is more why this kind of tool isn’t integrated by default in kubectl?

@stewart-yu: Double dash and short form (kubectl get all --n tmp) doesn’t work!

Both variants below do work: kubectl get all --namespace tmp kubectl get all -n tmp

You can look that up in kubectl options:

...
-n, --namespace='': If present, the namespace scope for this CLI request
...

Yes, agreed. Doesn’t really matter where you put the -n arg

kubectl get -n tmp po,sts,svc,whatever also works

Not that it matters in here, but just a side-note, I think it’s easier to just add -A instead of –all-namespaces

kubectl get all -A

@seans3 @liggitt we should probably just start the deprecation process for this?

kubectl api-resources -o name | xargs -I {} kubectl get {} --show-kind --ignore-not-found

@oudream thanks for that. Slight improvement since most use cases of this is dealing with a particular NAMESPACE …

kubectl -n NAMESPACE api-resources –namespaced=true -o name | xargs --verbose -I {} kubectl -n NAMESPACE get {} --show-kind --ignore-not-found

or another variant:

kubectl get $(kubectl api-resources --namespaced=true -o name | tr '\n' ,| sed 's/,$//') --ignore-not-found

Same issue here. Its returning only deployments, replicasets and pods

@davidbIQ I’m not a Kubernetes contributor, but this issue is closed and most likely not monitored by anyone.

Is anything stopping you from using the kubectl get-all plugin, as suggested in https://github.com/kubernetes/kubectl/issues/151#issuecomment-594978672? What you are trying to achieve is the exact reason why those plugins exist.

@dene14 “Migrate releases from helm2 to helm3” sounds very much off topic to me.

@rkand4 this is a question for StackOverflow or discuss.kubernetes.io.

The short answer is no. You have to range over all the APIs returned by getAPIVersions, list the resources inside each returned API (only the preferredVersion of each API), and finally get the objects for these resources in each namespace. There is no shortcut.

Ref: https://github.com/kubernetes/community/blob/master/contributors/devel/kubectl-conventions.md#rules-for-extending-special-resource-alias---all

We may want to explain all in the help text.

upvote to fix

@cah-prakash-kalaiarasu01 and @micktg: that only lists a very small subset of resources.

To list all resources, like the issue’s title suggests, see https://github.com/kubernetes/kubectl/issues/151#issuecomment-594978672

As a user performing kubectl get all I expect to see all objects in the current context, including limits.

There are some rules about which resources must fall under “all”, take a look here. Are the resources you want covered there?

@davidbIQ I’m not a Kubernetes contributor, but this issue is closed and most likely not monitored by anyone.

Is anything stopping you from using the kubectl get-all plugin, as suggested in #151 (comment)? What you are trying to achieve is the exact reason why those plugins exist.

Because one cannot install anything on the CKAD exam.

@kesor Note however that under MacOS one has to add a - parameter to paste (or install the GNU version of paste), because defaulting to stdin isn’t implied in BSD paste.

If someone still suffers from that problem, please check this script: https://gist.github.com/dene14/7253685cdedde2b6d16e8fc1df450d4f

For some reason when I add a label selector that should not match anything to the command @akavel provided, it returns 3 ComponentStatus items

$kubectl get $(kubectl api-resources --verbs=list -o name | paste -sd, -) --ignore-not-found --all-namespaces -l random=label
NAME                                 AGE
componentstatus/controller-manager   <unknown>
componentstatus/scheduler            <unknown>
componentstatus/etcd-0               <unknown>

@sarunask that’s a terrible idea, this method bypasses finalizers so it leaves all the objects belonging to the namespace inside your cluster.

See kubernetes/kubernetes#73405 and https://github.com/kubernetes/kubernetes/issues/60807#issuecomment-429754733 instead.

@liggitt does kubectl api-resources replace the functionality as well or this just means kubectl get all is going to be deprecated and there will not be any support for searching labels in a namespace?

My use case is the same as the issue:

$ kubectl get all -l <label>=<value> -n <namespace>
NAME         DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deploy/...

NAME                DESIRED   CURRENT   READY     AGE
rs/...

NAME                      READY     STATUS    RESTARTS   AGE
po/...

NAME      TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                                      AGE
svc/...

which doesn’t return secrets, for example:

$ kubectl get secret -l <label>=<value> -n <namespace>
NAME                         TYPE      DATA      AGE
secret-1...

kubectl version:

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.7", GitCommit:"dd5e1a2978fd0b97d9b78e1564398aeea7e7fe92", GitTreeState:"clean", BuildDate:"2018-04-19T00:05:56Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"10+", GitVersion:"v1.10.2-gke.1", GitCommit:"75d2af854b1df023c7ce10a8795b85d3dd1f8d37", GitTreeState:"clean", BuildDate:"2018-05-10T17:23:18Z", GoVersion:"go1.9.3b4", Compiler:"gc", Platform:"linux/amd64"}```