时间戳

首页 > 解决方案 > Kubernetes pod 偶尔会抛出“ImagePullBackOff”或“ErrImagePull”

kubernetes - Kubernetes pod 偶尔会抛出“ImagePullBackOff”或“ErrImagePull”

问题描述

我了解 ImagePullBackOff 或 ErrImagePull 在 K8 无法拉取容器时发生，但我认为这里不是这种情况。我这样说是因为只有一些Pod 在我的服务扩展时随机抛出此错误，而其他一些则非常好，状态良好。

例如，请在此处参考此副本集。

我从一个这样的失败 pod 中检索了事件。

Events:
  Type     Reason     Age                   From                                                          Message
  ----     ------     ----                  ----                                                          -------
  Normal   Scheduled  3m45s                 default-scheduler                                             Successfully assigned default/storefront-jtonline-prod-6dfbbd6bd8-jp5k5 to gke-square1-prod-clu-nap-n1-highcpu-2-82b95c00-p5gl
  Normal   Pulling    2m8s (x4 over 3m44s)  kubelet, gke-square1-prod-clu-nap-n1-highcpu-2-82b95c00-p5gl  pulling image "gcr.io/square1-2019/storefront-jtonline-prod:latest"
  Warning  Failed     2m7s (x4 over 3m43s)  kubelet, gke-square1-prod-clu-nap-n1-highcpu-2-82b95c00-p5gl  Failed to pull image "gcr.io/square1-2019/storefront-jtonline-prod:latest": rpc error: code = Unknown desc = Error response from daemon: unauthorized: You don't have the needed permissions to perform this operation, and you may have invalid credentials. To authenticate your request, follow the steps in: https://cloud.google.com/container-registry/docs/advanced-authentication
  Warning  Failed     2m7s (x4 over 3m43s)  kubelet, gke-square1-prod-clu-nap-n1-highcpu-2-82b95c00-p5gl  Error: ErrImagePull
  Normal   BackOff    113s (x6 over 3m42s)  kubelet, gke-square1-prod-clu-nap-n1-highcpu-2-82b95c00-p5gl  Back-off pulling image "gcr.io/square1-2019/storefront-jtonline-prod:latest"
  Warning  Failed     99s (x7 over 3m42s)   kubelet, gke-square1-prod-clu-nap-n1-highcpu-2-82b95c00-p5gl  Error: ImagePullBackOff

日志告诉我，由于凭据不正确，它未能拉出容器，这似乎......令人困惑？这个 pod 是在自动缩放时自动创建的，就像其他 pod 一样。

我有一种感觉，这可能与资源分配有关。当集群由于流量激增而非常快地启动新节点时，或者当我在部署配置中设置较低的资源请求时，我发现这些错误的发生率要高得多。

我该如何调试此错误，发生这种情况的可能原因是什么？

这是我的配置：

apiVersion: "extensions/v1beta1"
kind: "Deployment"
metadata:
  name: "storefront-_STOREFRONT-_ENV"
  namespace: "default"
  labels:
    app: "storefront-_STOREFRONT-_ENV"
spec:
  replicas: 10
  selector:
    matchLabels:
      app: "storefront-_STOREFRONT-_ENV"
  template:
    metadata:
      labels:
        app: "storefront-_STOREFRONT-_ENV"
    spec:
      containers:
      - name: "storefront-_STOREFRONT-_ENV"
        image: "gcr.io/square1-2019/storefront-_STOREFRONT-_ENV"
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /?healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 1
        imagePullPolicy: Always

apiVersion: "autoscaling/v2beta1"
kind: "HorizontalPodAutoscaler"
metadata:
  name: "storefront-_STOREFRONT-hpa"
  namespace: "default"
  labels:
    app: "storefront-_STOREFRONT-_ENV"
spec:
  scaleTargetRef:
    kind: "Deployment"
    name: "storefront-_STOREFRONT-_ENV"
    apiVersion: "apps/v1beta1"
  minReplicas: 10
  maxReplicas: 1000
  metrics:
  - type: "Resource"
    resource:
      name: "cpu"
      targetAverageUtilization: 75

编辑：我已经能够验证这实际上是一个身份验证问题。这仅发生在“某些”pod 上，因为它仅发生在调度在由于垂直扩展而自动创建的节点上的 pod 上。不过，我还不知道如何解决这个问题。

标签： kubernetes

解决方案

正如我们可以在Kubernetes 文档中看到的有关图像的内容，如果您在 GKE 上运行集群，则无需执行任何操作。

注意：如果您在 Google Kubernetes Engine 上运行，则.dockercfg每个节点上都已经有一个带有 Google Container Registry 凭据的节点。您不能使用这种方法。

但它也指出：

注意：如果您可以控制节点配置，则此方法适用。它不能在 GCE 和任何其他自动更换节点的云提供商上可靠地工作。

同样在“在 Pod 上指定 ImagePullSecrets”部分中。

注意：此方法目前是 Google Kubernetes Engine、GCE 和任何 自动创建节点的云提供商的推荐方法。

建议使用 Docker Config 创建 Secret。

这可以通过以下方式完成：

kubectl create secret docker-registry <name> --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL

推荐阅读