Closed carterjfulcher closed 2 months ago
This issue is currently awaiting triage.
SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted
label.
The triage/accepted
label can be added by org members by writing /triage accepted
in a comment.
Does something like this work for what you need?
kubectl wait --for=condition=Ready pod/foo && kubectl logs -f pod/foo
You could even turn this into a simple plugin by putting it into a file called kubectl-waitlogs
somewhere in your path:
#!/bin/sh
kubectl wait --for=condition=Ready pod/$1 && kubectl logs -f pod/$1
And then chmod +x kubectl-waitlogs
and now you can:
kubectl waitlogs foo
https://github.com/kubernetes/kubernetes/pull/125868 brings about new for condition just for creation.
$ kubectl wait --for=create pod/test-1
$ kubectl logs -f pod/test-1
I'd prefer closing this issue.
/close
This has been solved by a few options.
@mpuckett159: Closing this issue.
As Kubernetes developers, we often find ourselves repeatedly hitting the UpArrow + Enter combo in the terminal while waiting for a pod to start, to ensure we don’t miss any log output.
I am recommending a change which enhances the -f flag to wait until the pod is fully initialized during
ContainerCreating
status instead of erroring, making the development process smoother and more efficient.The error in particular I'm referring to is the following, when
kubectl logs -f [POD_ID]
is invoked on a pod with statusContainerCreating
:Error from server (BadRequest): container "pod-name" in pod "pod-id" is waiting to start: ContainerCreating
I am happy to submit a PR for this change, if approved.