Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

kubectl wait --all with --all-namespaces doesn't find resources #79121

Closed
nbwest opened this issue Jun 18, 2019 · 10 comments
Closed

kubectl wait --all with --all-namespaces doesn't find resources #79121

nbwest opened this issue Jun 18, 2019 · 10 comments
Labels
kind/bug Categorizes issue or PR as related to a bug. lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. sig/apps Categorizes an issue or PR as relevant to SIG Apps.

Comments

@nbwest
Copy link

nbwest commented Jun 18, 2019

Running the command
kubectl wait --for=condition=Ready pods --all --all-namespaces
results in
error: no matching resources foundWhat happened:
However, running
kubectl wait --for=condition=Ready pods --all -n kube-system
provides expected output with pods in namespace being enumerated.

What you expected to happen:
All pods in all namespaces would be checked against the Ready condition

How to reproduce it (as minimally and precisely as possible):
Run the following against a cluster containing pods.
kubectl wait --for=condition=Ready pods --all --all-namespaces

Anything else we need to know?:

Environment:

  • Kubernetes version (use kubectl version):
    Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.3", GitCommit:"5e53fd6bc17c0dec8434817e69b04a25d8ae0ff0", GitTreeState:"clean", BuildDate:"2019-06-06T01:44:30Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}
    Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.0", GitCommit:"641856db18352033a0d96dbc99153fa3b27298e5", GitTreeState:"clean", BuildDate:"2019-03-25T15:45:25Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"}

  • Cloud provider or hardware configuration:
    AWS

  • OS (e.g: cat /etc/os-release):
    NAME="Ubuntu"
    VERSION="18.04.2 LTS (Bionic Beaver)"

  • Kernel (e.g. uname -a):
    Linux ubuntu 4.18.0-18-generic Use Docker to host most server components #19~18.04.1-Ubuntu SMP Fri Apr 5 10:22:13 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

  • Install tools:

  • Network plugin and version (if this is a network-related bug):

  • Others:
@nbwest nbwest added the kind/bug Categorizes issue or PR as related to a bug. label Jun 18, 2019
@k8s-ci-robot k8s-ci-robot added the needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. label Jun 18, 2019
@nbwest
Copy link
Author

nbwest commented Jun 18, 2019

@kubernetes/sig-apps-bugs

@k8s-ci-robot k8s-ci-robot added sig/apps Categorizes an issue or PR as relevant to SIG Apps. and removed needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Jun 18, 2019
@k8s-ci-robot
Copy link
Contributor

@nbwest: Reiterating the mentions to trigger a notification:
@kubernetes/sig-apps-bugs

In response to this:

@kubernetes/sig-apps-bugs

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.

@pswica
Copy link
Contributor

pswica commented Jun 18, 2019

I could not replicate. I tested on minikube

kubectl wait --for=condition=Ready pods --all --all-namespaces
pod/annotationtest-7c65dbd89c-xnvxg condition met
pod/ctest-6c9b69f46c-qnkrw condition met

Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.2", GitCommit:"66049e3b21efe110454d67df4fa62b08ea79a19b", GitTreeState:"clean", BuildDate:"2019-05-16T16:23:09Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.2", GitCommit:"66049e3b21efe110454d67df4fa62b08ea79a19b", GitTreeState:"clean", BuildDate:"2019-05-16T16:14:56Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}

@nbwest
Copy link
Author

nbwest commented Jun 23, 2019

The cluster I see this behaviour on was stood up using kops.
Using another cluster stood up manually I get some results, but it then appears to hang timing out on a large number of completed pods.
When I can get some time I'll try and reproduce it on a manually built cluster

@fejta-bot
Copy link

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

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Sep 21, 2019
@fejta-bot
Copy link

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

@k8s-ci-robot k8s-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Oct 21, 2019
@fejta-bot
Copy link

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

@k8s-ci-robot
Copy link
Contributor

@fejta-bot: Closing this issue.

In response to this:

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

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.

@DavidWittman
Copy link

DavidWittman commented Jun 5, 2020 •
edited
Loading

I ran into this issue when executing kubectl (v1.15.0) from within a pod. It seems to always use the namespace defined in /var/run/secrets/kubernetes.io/serviceaccount/namespace even if -A is supplied on the command-line.

@DavidWittman
Copy link

Seems fixed in kubectl v1.18.3, but probably sooner than that release as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
kind/bug Categorizes issue or PR as related to a bug. lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. sig/apps Categorizes an issue or PR as relevant to SIG Apps.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@DavidWittman @pswica @nbwest @k8s-ci-robot @fejta-bot