【问题标题】:Kubernetes imagePullSecrets not working; getting "image not found"Kubernetes imagePullSecrets 不工作;得到“找不到图像”
【发布时间】:2015-09-10 19:40:12
【问题描述】:

我有一个在 AWS 上运行的现成 Kubernetes 集群,使用 kube-up 脚本安装。我想运行一些位于私有 Docker Hub 存储库中的容器。但我不断收到“未找到”错误:

 > kubectl get pod
NAME                      READY     STATUS                                        RESTARTS   AGE
maestro-kubetest-d37hr    0/1       Error: image csats/maestro:latest not found   0          22m

我创建了一个包含.dockercfg 文件的机密。我已经通过运行here 发布的脚本确认它可以工作:

 > kubectl get secrets docker-hub-csatsinternal -o yaml | grep dockercfg: | cut -f 2 -d : | base64 -D > ~/.dockercfg
 > docker pull csats/maestro
latest: Pulling from csats/maestro

我已经确认我没有使用the new format of .dockercfg script,我的看起来像这样:

> cat ~/.dockercfg
{"https://index.docker.io/v1/":{"auth":"REDACTED BASE64 STRING HERE","email":"eng@csats.com"}}

我试过running the Base64 encode on Debian instead of OS X,没有运气。 (正如预期的那样,它会产生相同的字符串。)

这是我的复制控制器的 YAML:

---
kind: "ReplicationController"
apiVersion: "v1"
metadata:
  name: "maestro-kubetest"
spec:
  replicas: 1
  selector:
    app: "maestro"
    ecosystem: "kubetest"
    version: "1"
  template:
    metadata:
      labels:
        app: "maestro"
        ecosystem: "kubetest"
        version: "1"
    spec:
      imagePullSecrets:
        - name: "docker-hub-csatsinternal"
      containers:
        - name: "maestro"
          image: "csats/maestro"
          imagePullPolicy: "Always"

      restartPolicy: "Always"
      dnsPolicy: "ClusterFirst"

kubectl version:

Client Version: version.Info{Major:"1", Minor:"0", GitVersion:"v1.0.3", GitCommit:"61c6ac5f350253a4dc002aee97b7db7ff01ee4ca", GitTreeState:"clean"}
Server Version: version.Info{Major:"1", Minor:"0", GitVersion:"v1.0.3", GitCommit:"61c6ac5f350253a4dc002aee97b7db7ff01ee4ca", GitTreeState:"clean"}

有什么想法吗?

【问题讨论】:

  • 在您的示例中,您正在拉动两个不同的图像 - 您是否尝试拉动大师?
  • 很好——用正确的图像重新运行命令。结果相同。
  • 我遇到了同样的问题..您找到解决方案了吗?
  • 如果两个月后它仍然对您有用,是的,我做到了。呵呵。

标签: docker kubernetes dockerhub


【解决方案1】:

您可能会看到“找不到图像”的另一个可能原因是您的密钥的命名空间与容器的命名空间不匹配。

例如,如果您的部署 yaml 看起来像

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: mydeployment
  namespace: kube-system

那么你必须确保 Secret yaml 使用匹配的命名空间:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
  namespace: kube-system
data:
  .dockerconfigjson: ****
type: kubernetes.io/dockerconfigjson

如果您没有为您的秘密指定命名空间,它将最终在默认命名空间中并且不会被使用。没有警告信息。我刚刚在这个问题上花了几个小时,所以我想我会在这里分享它,希望我可以节省其他人的时间。

【讨论】:

  • 我在这里遇到了完全相同的问题。唯一的区别是我实际上希望秘密位于默认命名空间中,因为我不想为所有命名空间创建它。有没有办法在命名空间内创建入口时引用默认命名空间的秘密?
【解决方案2】:

Docker 在~/.docker/ 中生成一个config.json 文件 它看起来像:

{
    "auths": {
        "index.docker.io/v1/": {
            "auth": "ZmFrZXBhc3N3b3JkMTIK",
            "email": "email@company.com"
        }
    }
}

你真正想要的是:

{"https://index.docker.io/v1/": {"auth": "XXXXXXXXXXXXXX", "email": "email@company.com"}}

注意三件事:

  • 1) 没有auths 包装
  • 2) 前面有https:// 网址
  • 3) 它是一行

然后您 base64 对其进行编码并用作.dockercfg 名称的数据

apiVersion: v1
kind: Secret
metadata: 
  name: registry
data:
  .dockercfg: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX==
type: kubernetes.io/dockercfg

再次注意.dockercfg 行是一行(base64 倾向于生成多行字符串)

【讨论】:

  • 你让我找到了解决方案——原来我的问题是我的秘密是type: Opaque,而不是type: kubernetes.io/dockercfg。干杯。
【解决方案3】:

您可能会看到此错误的另一个原因是由于使用了不同于集群版本的 kubectl 版本(例如,针对 1.8.x 集群使用 kubectl 1.9.x)。

kubectl create secret docker-registry 命令生成的 secret 格式在版本之间有所变化。

一个 1.8.x 集群需要一个格式为:

{  
   "https://registry.gitlab.com":{  
      "username":"...",
      "password":"...",
      "email":"...",
      "auth":"..."
   }
}

但是 1.9.x kubectl 生成的 secret 有这样的格式:

{  
   "auths":{  
      "https://registry.gitlab.com":{  
         "username":"...",
         "password":"...",
         "email":"...",
         "auth":"..."
      }
   }
}

因此,请仔细检查您的密钥的 .dockercfg 数据的值,并验证它是否与您的 kubernetes 集群版本所期望的格式匹配。

【讨论】:

  • 非常感谢,这确实解决了我的问题。我在 windows 上摆弄了 minikube,虽然 Chocolatey 默认安装 kubectl-cli 1.9 版,但适用于 windows 的 minikube 仍然是 1.8。始终运行 kubectl version 并仔细检查匹配的版本。
  • 这应该是公认的答案。 MrE 的答案是正确的,但它没有提到为什么格式不同。非常感谢 eschnou,你终于解决了让我头撞墙 2 天的问题。
  • 我不明白以前的版本/格式怎么也不能支持。两者都允许很容易,相反,互联网上到处都是苦苦挣扎的人
【解决方案4】:

我也遇到了同样的问题。我注意到的是,在示例中 (https://kubernetes.io/docs/user-guide/images/#specifying-imagepullsecrets-on-a-pod) .dockercfg 具有以下格式:

{ 
   "https://index.docker.io/v1/": { 
     "auth": "ZmFrZXBhc3N3b3JkMTIK", 
     "email": "jdoe@example.com" 
   } 
}

虽然 docker 在我的机器上生成的看起来像这样:

{
    "auths": {
        "https://index.docker.io/v1/": {
            "auth": "ZmFrZXBhc3N3b3JkMTIK",
            "email": "email@company.com"
        }
    }
}

通过查看源代码,我发现实际上有一个针对这个用例的测试(https://github.com/kubernetes/kubernetes/blob/6def707f9c8c6ead44d82ac8293f0115f0e47262/pkg/kubelet/dockertools/docker_test.go#L280

我向您确认,如果您只是采用并编码“auths”,如示例中所示,它将为您工作。

可能应该更新文档。我将在 github 上提出一张票。

【讨论】:

  • 嗯——没有解决我的问题。我相信我最初尝试了这两种格式。
猜你喜欢
  • 2021-05-28
  • 1970-01-01
  • 1970-01-01
  • 2020-11-13
  • 1970-01-01
  • 2016-05-17
  • 1970-01-01
  • 1970-01-01
  • 2018-06-26
相关资源
最近更新 更多