kubectl get all does not list all resources in a namespace

[tback]

Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see http://kubernetes.io/docs/troubleshooting/.):

What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.):
get all, get all resources

---

Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT

Kubernetes version (use kubectl version):
Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.2", GitCommit:"bdaeafa71f6c7c04636251031f93464384d54963", GitTreeState:"clean", BuildDate:"2017-10-24T19:48:57Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.2-gke.0", GitCommit:"52ea03646e64b35a5b092ab32bb529400c296aa6", GitTreeState:"clean", BuildDate:"2017-10-24T23:31:18Z", GoVersion:"go1.8.3b4", Compiler:"gc", Platform:"linux/amd64"}

Environment:

• Cloud provider or hardware configuration:
  gke
• OS (e.g. from /etc/os-release):
  macos 10.12.6

What happened:
kubectl get all does not list all resources in a namespace.

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

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

kubectl create namespace tmp
kubectl create -f https://k8s.io/docs/tasks/administer-cluster/memory-defaults.yaml --namespace=tmp
kubectl get all --namespace tmp
namespace "tmp" created
limitrange "mem-limit-range" created
No resources found.

[stewart-yu]

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

[tback]

@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
...

[stewart-yu]

/kind bug

[stewart-yu]

I will fix it ASAP

[stewart-yu]

cc @smarterclayton Described as above. We can not get limitRange for it is unknown objects?

[stewart-yu]

cc @fabianofranz

[fabianofranz]

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?

[tback]

@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.

[smarterclayton]

There's an open issue for that - I'd like to see it solved, but it requires some other work to happen because there are resources that exist, but aren't deletable.

…

On Thu, Nov 30, 2017 at 10:06 AM, Till Backhaus ***@***.***> wrote: 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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#151 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABG_pyQoDwAuOBgKu-aylMQzae2yPZZZks5s7sR1gaJpZM4QtFDB> .

[tback]

@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.

[HartS]

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.

[joaosousafranco]

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

[mengqiy]

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.

[DamonStamper]

@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')

[liggitt]

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.

[mohsenrezaeithe]

@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"}```

[roshankadasani]

Try - kubectl get all --all-namespaces

[liggitt]

@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>

[liggitt]

/close

[jeremyjjbrown]

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]

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

[jeremyjjbrown]

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

[Diaphteiros]

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 ...

[2rs2ts]

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

[antoineco]

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

[greatvovan]

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

[kesor]

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.

[bitti]

@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.

[davidbIQ]

upvote to fix

[antoineco]

@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.

[danmutblix]

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

[qgeffard]

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

[antoineco]

@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" 🙏

[bzub]

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

[scratchmex]

kubectl api-resources --verbs=list --namespaced -o name
| xargs -n 1 kubectl get --show-kind --ignore-not-found

Just to note that to truly list all resources you should remove the --namespaced. For example these 2 are not namespaced and does not show up with that command:

mutatingwebhookconfigurations.admissionregistration.k8s.io
validatingwebhookconfigurations.admissionregistration.k8s.io

[1dropaflame]

@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.

[davidbIQ]

I'm using powershell so I'm not sure that would work, & I don't really want to install a plugin.
I think part of it is all a lie; they should rename it to kubectl get some (and add ingress to it), or make all mean all...
as when I posted this I was new to kubernetes, I was confused why some things just weren't there that I thought should have been there. It looks like they removed it from the docs which is both a step forwards & backwards... but the functionality is still there; I'm still of the opinion though that all should mean all, and add some other catagory options like global (for global scoped resources only etc).

[Alestrix]

Just to note that to truly list all resources you should remove the --namespaced.

Have a look at the issue's title: "... list all resources in a namespace"