kubectl get all does not list all resources in a namespace

Created on 28 Nov 2017 · 82Comments · Source: kubernetes/kubectl

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.

arekubectl kinbug prioritP2 sicli

Source

tback

👍79

Most helpful comment

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.

jeremyjjbrown on 3 Aug 2018

👍146 ❤16

All 82 comments

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

stewart-yu on 29 Nov 2017

👎290 😄30 👀21 😕18

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

tback on 29 Nov 2017

👍15 🚀2

/kind bug

stewart-yu on 29 Nov 2017

I will fix it ASAP

stewart-yu on 29 Nov 2017

😄3

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

stewart-yu on 30 Nov 2017

cc @fabianofranz

stewart-yu on 30 Nov 2017

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?

fabianofranz on 30 Nov 2017

👍2

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

This leaves me frustrated though:

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

tback on 30 Nov 2017

👍28

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 notifications@github.com
wrote:

Yes, limits are covered there (Rule 2: No namespace admin level resources
(limits, quota, policy, authorization rules)).
This leaves me frustrated though:

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.

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
https://github.com/kubernetes/kubectl/issues/151#issuecomment-348215149,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABG_pyQoDwAuOBgKu-aylMQzae2yPZZZks5s7sR1gaJpZM4QtFDB
.

smarterclayton on 30 Nov 2017

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

tback on 4 Dec 2017

👍12

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.

HartS on 19 Dec 2017

👍57

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

joaosousafranco on 5 Mar 2018

👍3

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.

mengqiy on 5 Mar 2018

👍2

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

DamonStamper on 10 May 2018

👍14 ❤2

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.

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

liggitt on 10 May 2018

❤3 👍3

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

mohsenrezaeithe on 1 Jun 2018

Try - kubectl get all --all-namespaces

roshankadasani on 3 Jul 2018

👎57 😄3 👍3 👀1

@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 on 3 Jul 2018

👍113 🎉12 👎9 🚀5 ❤4

/close

liggitt on 3 Jul 2018

👎99

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.

jeremyjjbrown on 3 Aug 2018

👍146 ❤16

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

liggitt on 3 Aug 2018

👎41 👍3 😕2

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

jeremyjjbrown on 3 Aug 2018

👍15

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

Diaphteiros on 15 Nov 2018

👍38

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

2rs2ts on 15 Nov 2018

👍14

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

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.

staranto on 30 Nov 2018

👍9

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

Do we know why this happens? I'm seeing the same issue.

pirtoo on 29 Jan 2019

Do we know why this happens? I'm seeing the same issue.

Error handling for that command was recently improved in https://github.com/kubernetes/kubernetes/pull/73035. It no longer fails on a single error

juanvallejo on 29 Jan 2019

/reopen

dims on 5 Mar 2019

👍26

@dims: Reopened this issue.

In response to this:

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

k8s-ci-robot on 5 Mar 2019

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:

Add features like the one mentioned in this issue to the API as soon as possible.
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.

sassanh on 5 Mar 2019

👍17 🚀2 ❤1

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.

javabrett on 9 Apr 2019

👍27 ❤2

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.

ghost on 9 Apr 2019

👍13

This post really helps:
https://github.com/kubernetes/kubernetes/issues/60807#issuecomment-401039268
So you need to delete finalizers from your NS and all CRD's or resources you have - and NS would be deleted

sarunask on 9 May 2019

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

antoineco on 6 Jun 2019

👍1

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

#

oudream on 10 Jul 2019

👍6

master $ kubectl api-resources -o name
bindings
componentstatuses
configmaps
endpoints
events
limitranges
namespaces
nodes
persistentvolumeclaims
persistentvolumes
pods
podtemplates
replicationcontrollers
resourcequotas
secrets
serviceaccounts
services
mutatingwebhookconfigurations.admissionregistration.k8s.io
validatingwebhookconfigurations.admissionregistration.k8s.io
customresourcedefinitions.apiextensions.k8s.io
apiservices.apiregistration.k8s.io
controllerrevisions.apps
daemonsets.apps
deployments.apps
replicasets.apps
statefulsets.apps
tokenreviews.authentication.k8s.io
localsubjectaccessreviews.authorization.k8s.io
selfsubjectaccessreviews.authorization.k8s.io
selfsubjectrulesreviews.authorization.k8s.io
subjectaccessreviews.authorization.k8s.io
horizontalpodautoscalers.autoscaling
cronjobs.batch
jobs.batch
certificatesigningrequests.certificates.k8s.io
leases.coordination.k8s.io
events.events.k8s.io
daemonsets.extensions
deployments.extensions
ingresses.extensions
networkpolicies.extensions
podsecuritypolicies.extensions
replicasets.extensions
ingresses.networking.k8s.io
networkpolicies.networking.k8s.io
runtimeclasses.node.k8s.io
poddisruptionbudgets.policy
podsecuritypolicies.policy
clusterrolebindings.rbac.authorization.k8s.io
clusterroles.rbac.authorization.k8s.io
rolebindings.rbac.authorization.k8s.io
roles.rbac.authorization.k8s.io
priorityclasses.scheduling.k8s.io
csidrivers.storage.k8s.io
csinodes.storage.k8s.io
storageclasses.storage.k8s.io
volumeattachments.storage.k8s.io

oudream on 10 Jul 2019

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

bdowling on 11 Jul 2019

👍4

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 on 9 Oct 2019

/remove-lifecycle stale

/sig cli
/area kubectl
/priority P2

seans3 on 9 Oct 2019

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.

mxplusb on 14 Oct 2019

👍7

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.

liggitt on 14 Oct 2019

👎4

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.

ukiahsmith on 20 Oct 2019

👍5

There's discussion from way back in 2016 on what items should be in all : https://github.com/kubernetes/kubernetes/pull/28955#issuecomment-232737113

Agree with @liggitt that we should not promote its use

dims on 20 Oct 2019

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

dims on 20 Oct 2019

👍4

The all category is entirely specified server-side in discovery docs, and resolved generically client-side like any other category. It's unclear how we would communicate it was deprecated to users of that feature without adding special case logic specific to "all" client-side, which we do not want to do.

liggitt on 20 Oct 2019

@liggitt @seans3 is there a compelling reason the deprecation process cannot be started?

mxplusb on 21 Oct 2019

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

akavel on 8 Nov 2019

👍6

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

mxplusb on 13 Nov 2019

👍5

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>

bnason on 6 Dec 2019

👍1

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

ComponentStatus is an unusual API with a custom list implementation, and did not pay any attention to label selectors until https://github.com/kubernetes/kubernetes/pull/78438 fixed that in 1.17

liggitt on 6 Dec 2019

Thanks @liggitt for the fast response, for now I can simply filter it out using grep.
kubectl get $(kubectl api-resources --verbs=list -o name | grep -v componentstatus | paste -sd, -) --ignore-not-found --all-namespaces -l random=label

bnason on 6 Dec 2019

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

mxplusb on 10 Dec 2019

Not really. Removing it from documentation, help, and examples was the first step to reducing confusion for new users. Like I said, it's not clear how we would communicate effectively that the category was deprecated (we don't have API documentation for those like we do API types)

liggitt on 10 Dec 2019

may be silly question but still ... may the output be filter based:

kubectl get all - list all resources of all types
kubectl get [resourceTypes] - list all resources of required types
kubectl get -l [label]=[value] - list all resources of all types with label filtering
kubectl get [resourceTypes] -l [label]=[value] - list all resources of required types with label filtering
kubectl get [resourceTypes] -l [label]=[value] -n [nameSpaces] - list all resources of required types with label and namespace filtering

etc ...

intelligent002 on 10 Dec 2019

it's not clear how we would communicate effectively that the category was deprecated (we don't have API documentation for those like we do API types)

The deprecation policy has a set of rules that could be applied to start Occam's Razor on deprecating this.

_Rule 1: API elements may only be removed by incrementing the version of the API group._
- It's not an API type, just a category, so it wouldn't apply, correct?
_Rule 2: API objects must be able to round-trip between API versions in a given release without information loss, with the exception of whole REST resources that do not exist in some versions._
- It's not an API object, just a category, so this wouldn't apply, correct?
_Rule 3: An API version in a given track may not be deprecated until a new API version at least as stable is released._
- It's neither a type nor an object, so this wouldn't apply, correct?
_Rule 4a: Other than the most recent API versions in each track, older API versions must be supported after their announced deprecation for a duration_
- It's neither a type nor object, so this wouldn't apply, correct?
_Rule 4b: The “preferred” API version and the “storage version” for a given group may not advance until after a release has been made that supports both the new version and the previous version_
- It's not a storage type, so this doesn't apply.
_Rule 5a: CLI elements of user-facing components (e.g. kubectl) must function after their announced deprecation_
- It's already been removed in client-side references, and since it's not client-side code, this wouldn't apply, correct?
_Rule 5b: CLI elements of admin-facing components (e.g. kubelet) must function after their announced deprecation_
- It's already been removed in client-side references, and since it's not client-side code, this wouldn't apply, correct?
_Rule 7: Deprecated behaviors must function for no less than 1 year after their announced deprecation_
- Okay, so after it's been removed in a release, it has to keep functioning for a year.
_Rule 8: Feature gates must be deprecated when the corresponding feature they control transitions a lifecycle stage as follows._
- Would this need a feature gate?
_Rule 9: Deprecated feature gates must respond with a warning when used._
- Depends on the answer to Rule 8

Based off my understanding of the policy and the internals of this feature (without diving into the code), here are the core requirements which would have to be applied:

After it's been deprecated, it has to keep functioning for a year.
Will likely need a feature flag.

It could also be argued this falls under the Exception section of the policy, as well:

No policy can cover every possible situation. This policy is a living document, and will evolve over time. In practice, there will be situations that do not fit neatly into this policy, or for which this policy becomes a serious impediment. Such situations should be discussed with SIGs and project leaders to find the best solutions for those specific cases, always bearing in mind that Kubernetes is committed to being a stable system that, as much as possible, never breaks users. Exceptions will always be announced in all relevant release notes.

To me, it sounds more like this is an exception to the core policy since it's mostly internal, server-side code handling a category with no objects or types associated with it. The exception section's second sentence starts with _[t]his policy is a living document_, maybe it's time to dive into what that looks like, and understand the aspect of deprecating a category, and how that will work? I suggest that knowing it's not a fast process, and that it can take time to have discusses and get feedback.

@liggitt which SIG would this fall under? I'm thinking it'd be API Machinery since it's API functionality, or do you think it would fall under a different one?

mxplusb on 11 Dec 2019

To me, it sounds more like this is an exception to the core policy since it's mostly internal, server-side code handling a category with no objects or types associated with it.

That is not accurate. The "all" category is associated with particular group/version/resources, and is returned in discovery API responses by the server. The closest rule in the deprecation policy that applies is:

Rule 1: API elements may only be removed by incrementing the version of the API group.

That would mean the "all" category would continue to be associated with all existing group/version/resources, and could be removed on a per-resource basis as those resources reached a new version. For example:

v2 pods, replicationcontrollers, services,
batch/v2 jobs, cronjobs
autoscaling/v2 horizontalpodautoscalers
apps/v2 daemonsets, deployments, replicasets, statefulsets

Given there are no plans in progress to begin work on v2 versions of most of those resources (only horizontalpodautoscalers have a v2 in progress), an announced deprecation would have no planned timeline it would take effect.

liggitt on 11 Dec 2019

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.

mxplusb on 12 Dec 2019

👍5

Movement in either direction (to make it include all resources, or to make it stop including some and eventually any resources) has potential to break callers.

With the limited visibility of the existence of the "all" category, and removal from all documentation and user guides we control, I'm curious whether its continued existence to satisfy compatibility concerns is actually impacting users that much.

liggitt on 12 Dec 2019

Just write a simple script to get all the resources...



!/usr/bin/perl

my $k8sResources = kubectl api-resources | awk '{print \$1}';

my @resources = split("n", $k8sResources);

shift @resources;

foreach $resource (@resources) { my $command = 'kubectl get ' . $resource . ' --all-namespaces'; print "############################################################################n"; print "Getting resources of type: " . uc($resource) . "nss -with command: $command"; system($command); print "############################################################################nnnnn"; }

jfekete1 on 17 Dec 2019

@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

danmutblix on 30 Jan 2020

👎4

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

danmutblix on 30 Jan 2020

👎7

@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

danmutblix on 30 Jan 2020

👎4

The kubectl-conventions.md doc linked to above still exists at a different location (permalink),
and still has the section titled Rules for extending special resource alias - "all".

Should that section be updated to make that clear that the "all" alias is obsolete / is only being kept for backwards-compatibility?

david-in-perth on 4 Mar 2020

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

moebius87 on 5 Mar 2020

👍19

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

Is there an equivalent of this in Client Java SDK ? I cannot figure it out at all.

rkand4 on 21 Apr 2020

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.

sraillard on 22 Apr 2020

👍12

@sraillard see the answer from @moebius87 https://github.com/kubernetes/kubectl/issues/151#issuecomment-594978672

ketall output

image source

antoineco on 22 Apr 2020

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?

sraillard on 22 Apr 2020

👍3

Is there an equivalent of listing all kubernetes objects matching a label like below using Kuberentes java client SDK? (https://github.com/kubernetes-client/java)

The goal is to list all .yml files this particular application has an example is the below label can match DaemonSet, Deployment, Service

kubectl get all -l app=RatingsService

rkand4 on 22 Apr 2020

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

antoineco on 22 Apr 2020

👍2 👎1

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
.

danmutblix on 22 Apr 2020

👎8 👍2 😕1

/close

soltysh on 30 Apr 2020

👎16 😕5

@soltysh: Closing this issue.

In response to this:

/close

k8s-ci-robot on 30 Apr 2020

👎9

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

gothrek22 on 29 Jul 2020

🚀1 ❤1 🎉1 👍1

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.

4c74356b41 on 13 Aug 2020

👍29 😄5 👎3 😕2

_kubectl get all --all-namespaces_

will list the resources from all the namespace

cah-prakash-kalaiarasu01 on 20 Sep 2020

👎16

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.

micktg on 23 Sep 2020

👍1

@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

antoineco on 23 Sep 2020

👍2

@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 #151 (comment)

Of course, I am aware of that. It is suitable for me personally in most cases and miles better than kubectl get all --all-namespaces That's what I wanted to say.

micktg on 23 Sep 2020

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