kubernetes: restartPolicy Never does not fail pod if init container fails to pull image
What happened:
A pod with a restartPolicy: Never
has an init container with an invalid image. Instead of being marked Failed
, it is marked Pending
indefinitely.
What you expected to happen:
The pod to be marked Failed
after the image was unsuccessfully pulled
How to reproduce it (as minimally and precisely as possible):
apiVersion: v1
kind: Pod
metadata:
name: test
spec:
restartPolicy: Never
initContainers:
- name: init
image: some-nonexistent-image
containers:
- name: main
image: ubuntu
kubectl describe pod test
Name: test
Namespace: <redacted>
Priority: 0
Node: <redacted>
Start Time: Tue, 08 Oct 2019 11:54:24 -0500
Labels: <none>
Annotations: cni.projectcalico.org/podIP: 10.8.1.254/32
kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"name":"test","namespace":"<redacted>"},"spec":{"containers":[{"image...
Status: Pending
IP: 10.8.1.254
Init Containers:
init:
Container ID:
Image: some-nonexistent-image
Image ID:
Port: <none>
Host Port: <none>
State: Waiting
Reason: ImagePullBackOff
Ready: False
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-b5zn2 (ro)
Containers:
main:
Container ID:
Image: ubuntu
Image ID:
Port: <none>
Host Port: <none>
State: Waiting
Reason: PodInitializing
Ready: False
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-b5zn2 (ro)
Conditions:
Type Status
Initialized False
Ready False
ContainersReady False
PodScheduled True
Volumes:
default-token-b5zn2:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-b5zn2
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 25m default-scheduler Successfully assigned <redacted>
Normal SandboxChanged 25m kubelet, <redacted> Pod sandbox changed, it will be killed and re-created.
Normal Pulling 23m (x4 over 25m) kubelet, <redacted> Pulling image "some-nonexistent-image"
Warning Failed 23m (x4 over 25m) <redacted> Failed to pull image "some-nonexistent-image": rpc error: code = Unknown desc = Error response from daemon: pull access denied for some-nonexistent-image, repository does not exist or may require 'docker login'
Warning Failed 23m (x4 over 25m) kubelet, <redacted> Error: ErrImagePull
Normal BackOff 10m (x67 over 25m) kubelet, <redacted> Back-off pulling image "some-nonexistent-image"
Warning Failed 2s (x112 over 25m) kubelet, <redacted> Error: ImagePullBackOff
Anything else we need to know?:
Environment:
- Kubernetes version (use
kubectl version
):
Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.2", GitCommit:"f6278300bebbb750328ac16ee6dd3aa7d3549568", GitTreeState:"archive", BuildDate:"2019-08-29T18:43:18Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14+", GitVersion:"v1.14.6-gke.1", GitCommit:"61c30f98599ad5309185df308962054d9670bafa", GitTreeState:"clean", BuildDate:"2019-08-28T11:06:42Z", GoVersion:"go1.12.9b4", Compiler:"gc", Platform:"linux/amd64"}
- Cloud provider or hardware configuration: GKE
- OS (e.g:
cat /etc/os-release
): - Kernel (e.g.
uname -a
): - Install tools:
- Network plugin and version (if this is a network-related bug):
- Others:
@kubernetes/sig-api-machinery-bugs
/sig api-machinery
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 2
- Comments: 20 (11 by maintainers)
/remove-sig api-machinery /sig node