Are DockerHub rate limits going to be a problem for the busybox container

[jlewi]

Docker announced new rate limits: See https://docs.docker.com/docker-hub/download-rate-limit/

When using skaffold to fire off a kaniko job I hit this rate limit.

  Normal   Pulling           20s (x2 over 35s)  kubelet            Pulling image "busybox"
  Warning  Failed            19s (x2 over 34s)  kubelet            Failed to pull image "busybox": rpc error: code = Unknown desc = Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit

It looks like the Kaniko pod that skaffold is firing off includes a busybox container which is hosted in DockerHub.

Would it make sense to use a container hosted in GCR instead to avoid any potential issue with DockerHub rate limits?

Name:         kaniko-bztqs
Namespace:    emojichat
Priority:     0
Node:         ip-172-23-103-252.us-west-2.compute.internal/172.23.103.252
Start Time:   Thu, 19 Nov 2020 20:15:27 -0800
Labels:       skaffold-kaniko=skaffold-kaniko
Annotations:  kubernetes.io/psp: csp-psp
Status:       Pending
IP:           172.23.103.3
IPs:
  IP:  172.23.103.3
Init Containers:
  kaniko-init-container:
    Container ID:  
    Image:         busybox
    Image ID:      
    Port:          <none>
    Host Port:     <none>
    Command:
      sh
      -c
      while [ ! -f /tmp/complete ]; do sleep 1; done
    State:          Waiting
      Reason:       ErrImagePull
    Ready:          False
    Restart Count:  0
    Requests:
      cpu:        8
      memory:     16Gi
    Environment:  <none>
    Mounts:
      /kaniko/.docker/ from docker-config (rw)
      /kaniko/buildcontext from kaniko-emptydir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-p4kvq (ro)
Containers:
  kaniko:
    Container ID:  
    Image:         gcr.io/kaniko-project/executor:latest
    Image ID:      
    Port:          <none>
    Host Port:     <none>
    Args:
      --destination
      963188529772.dkr.ecr.us-west-2.amazonaws.com/emojichat/chatroom:267b30d-dirty
      --dockerfile
      Dockerfile
      --context
      dir:///kaniko/buildcontext
      --cache
    State:          Waiting
      Reason:       PodInitializing
    Ready:          False
    Restart Count:  0
    Requests:
      cpu:     8
      memory:  16Gi
    Environment:
      GOOGLE_APPLICATION_CREDENTIALS:  /secret/
      UPSTREAM_CLIENT_TYPE:            UpstreamClient(skaffold-)
      AWS_REGION:                      us-west-2
      IMAGE_REPO:                      ...
      IMAGE_NAME:                      chatroom
      IMAGE_TAG:                       267b30d-dirty
    Mounts:
      /kaniko/.docker/ from docker-config (rw)
      /kaniko/buildcontext from kaniko-emptydir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-p4kvq (ro)
Conditions:
  Type              Status
  Initialized       False 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Volumes:
  kaniko-emptydir:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:     
    SizeLimit:  <unset>
  docker-config:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      docker-config
    Optional:  false
  default-token-p4kvq:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-p4kvq
    Optional:    false
QoS Class:       Burstable
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300s

[gsquared94]

We've updated this default image to gcr.io/k8s-skaffold/skaffold-helpers/busybox in the latest release v1.17.1. Thanks!

If using a previous version of Skaffold you can override the default by setting it in the skaffold.yaml:

build:
  artifacts:
    - image: skaffold-example
      kaniko:
        initImage: gcr.io/k8s-skaffold/skaffold-helpers/busybox
        cache: {}