Question

当启动Kubernetes集群时，我加载etcd加上核心kubernetes进程 - kube-proxy，kube-apiserver，kube-controller-manager，kube-scheduler - 作为来自私有注册表的静态pod。这通过以下方式起作用：确保将$ HOME环境变量设置为kubelet的“/ root”，然后使用私有docker注册表的凭据定义/root/.docker/config.json。

当尝试运行Kubernetes 1.6时，启用了CRI，我在kubelet日志中收到错误，说它无法从我的私有docker注册表中拉出暂停：3.0容器，因为没有身份验证。

在kubelet命令行上设置--enable-cri = false可以正常工作，但是当启用CRI时，它似乎不会使用/root/.docker/config文件进行身份验证。

在启用CRI的情况下运行时，是否有一些新方法可以提供加载静态pod所需的docker凭据？

Answer 1

在1.6中，我设法使用https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod

中的以下配方

$ kubectl create secret docker-registry myregistrykey --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL

您需要在pod规范中的 imagePullSecrets 字段下指定新创建的 myregistrykey 作为凭据。

apiVersion: v1
kind: Pod
metadata:
  name: foo
  namespace: awesomeapps
spec:
  containers:
    - name: foo
      image: janedoe/awesomeapp:v1
  imagePullSecrets:
    - name: myregistrykey

Answer 2

事实证明，Kubernetes 1.6中的CRI功能存在缺陷。使用CRI，“暂停”容器 - 现在称为“Pod Sandbox Image”被视为一种特殊情况 - 因为它是容器运行时的“实现细节”，无论您是否需要它。在1.6版本中，例如，在尝试提取Pod Sandbox Image时，不会使用从/root/.docker/config.json应用于其他容器的凭据。

因此，如果您尝试从私有注册表中提取此映像，则CRI逻辑不会将凭据与拉取请求相关联。现在有一个Kubernetes问题（#45738）来解决这个问题，针对1.7。

与此同时，一个简单的解决方法是在启动kubelet进程之前将“Pause”容器预拉到节点的本地docker镜像缓存中。

如何在启用CRI的情况下为Kubernetes静态pod指定docker凭据？

2 个答案: