2

I was trying to measure pod startup time buy running the following:

% kubectl run --image busybox --attach test -- date
error: timed out waiting for the condition

At first it seems like this command takes a long time to start the pod. However if you run kubectl get pods while it is running you see something interesting.

At first the command succeeds:

% kubectl get pods
NAME   READY   STATUS      RESTARTS   AGE
test   0/1     Completed   0          2s

Then transitions to CrashLoopBackOff.

% kubectl get pods
NAME   READY   STATUS             RESTARTS   AGE
test   0/1     CrashLoopBackOff   1          7s

The logs show that the command ran successfully.

% kubectl logs test 
Thu Jan 27 15:02:36 UTC 2022

It is unclear to me why the pod is transitioning from Completed to CrashLoopBackOff. Is there a way to make kubectl do the right thing in this scenario?


The best work-around I have found so far is to use a slower command and subtract the delay from my testing.

% kubectl run --image busybox --attach test -- sleep 10

1 Answer 1

2

Ah, shortly after posting I found a clean solution. Adding --restart=Never makes the command work as expected.

% time kubectl run -n kcox-test --image busybox --attach test --restart=Never -- date
Thu Jan 27 15:10:41 UTC 2022
time Total: 9.449 (1%), User: 0.100, System: 0.034  - kubectl run -n kcox-test --image busybox --attach test --restart=Never -- date
1
  • 1
    Also add --rm to have the pod removed automatically Commented Feb 28, 2022 at 6:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.