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)

Most upvoted comments

/remove-sig api-machinery /sig node