Kubernetes imagePullSecrets не работает; получение изображения не найдено

У меня есть готовый кластер Kubernetes, работающий на AWS, установленный с помощью скрипта 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 файл. Я подтвердил, что это работает, запустив сценарий, опубликованный здесь:

 > 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

Я подтвердил, что не использую новый формат скрипта .dockercfg, на мой взгляд нравится:

> cat ~/.dockercfg
{"https://index.docker.io/v1/":{"auth":"REDACTED BASE64 STRING HERE","email":"[email protected]"}}

Я пробовал запустить кодировку Base64 в Debian вместо 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"}

Любые идеи?


kubernetes docker dockerhub
person iameli    schedule 10.09.2015    source источник
comment
В вашем примере вы тянете два разных изображения - вы пробовали тянуть маэстро?   -  person Clayton    schedule 11.09.2015
comment
Хороший улов - перезапустите команду с правильным изображением. Тот же результат.   -  person iameli    schedule 17.09.2015
comment
У меня такая же проблема .. Вы нашли решение?   -  person leonfs    schedule 19.09.2015
comment
Если через два месяца это все еще полезно для вас, да, я это сделал. Хех.   -  person iameli    schedule 14.11.2015

Ответы (4)


arrow_upward
17
arrow_downward

Docker генерирует config.json файл в ~/.docker/ Он выглядит так:

{
    "auths": {
        "index.docker.io/v1/": {
            "auth": "ZmFrZXBhc3N3b3JkMTIK",
            "email": "[email protected]"
        }
    }
}

на самом деле вы хотите:

{"https://index.docker.io/v1/": {"auth": "XXXXXXXXXXXXXX", "email": "[email protected]"}}

обратите внимание на 3 вещи:

  • 1) нет auths накрутки
  • 2) перед URL стоит https://
  • 3) это одна строка

затем вы base64 кодируете это и используете в качестве данных для имени .dockercfg

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

Обратите внимание, что строка .dockercfg - это одна строка (base64 имеет тенденцию генерировать многострочную строку)

person MrE    schedule 27.09.2015
comment
Вы привели меня к решению - моя проблема заключалась в том, что мой секрет был type: Opaque вместо type: kubernetes.io/dockercfg. Ваше здоровье. - person iameli; 14.11.2015

arrow_upward
18
arrow_downward

Другая возможная причина, по которой вы можете увидеть «изображение не найдено», заключается в том, что пространство имен вашего секрета не совпадает с пространством имен контейнера.

Например, если yaml вашего развертывания выглядит как

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

Затем вы должны убедиться, что секретный yaml использует соответствующее пространство имен:

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

Если вы не укажете пространство имен для своего секрета, он окажется в пространстве имен по умолчанию и не будет использоваться. Предупреждающего сообщения нет. Я просто потратил несколько часов на эту проблему, поэтому решил поделиться ею здесь в надежде, что смогу сэкономить время кому-то еще.

person amarillion    schedule 06.12.2016
comment
У меня здесь точно такая же проблема. Единственная разница в том, что я действительно ХОЧУ, чтобы секрет был в пространстве имен по умолчанию, поскольку я не хочу создавать его для всех пространств имен. Есть ли способ ссылаться на секрет в пространстве имен по умолчанию, когда вход создается внутри пространства имен? - person Randy; 18.01.2018

arrow_upward
6
arrow_downward

Другая причина, по которой вы можете увидеть эту ошибку, связана с использованием версии kubectl, отличной от версии кластера (например, использование kubectl 1.9.x против кластера 1.8.x).

Формат секрета, сгенерированного командой kubectl create secret docker-registry, изменялся между версиями.

Кластер 1.8.x ожидает секрет в формате:

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

Но секрет, сгенерированный kubectl 1.9.x, имеет следующий формат:

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

Итак, дважды проверьте значение данных .dockercfg вашего секрета и убедитесь, что оно соответствует формату, ожидаемому вашей версией кластера kubernetes.

person eschnou    schedule 04.01.2018
comment
Большое спасибо, это действительно решило мою проблему. Я возился с minikube на Windows, и хотя шоколадный устанавливает kubectl-cli версии 1.9, по умолчанию minikube для Windows по-прежнему 1.8. Всегда запускайте kubectl version и дважды проверяйте соответствие версий. - person schrom; 18.01.2018
comment
Это должен быть принятый ответ. Ответ MrE находится на правильном пути, но не упоминает, почему формат отличается. Большое спасибо, вы наконец решили проблему, из-за которой я бился головой о стену в течение 2 дней. - person PeterH; 09.03.2018

arrow_upward
3
arrow_downward

У меня такая же проблема. Я заметил, что в примере (https://kubernetes.io/docs/user-guide/images/#specifying-imagepullsecrets-on-a-pod) .dockercfg имеет следующий формат:

{ 
   "https://index.docker.io/v1/": { 
     "auth": "ZmFrZXBhc3N3b3JkMTIK", 
     "email": "[email protected]" 
   } 
}

В то время как тот, который сгенерирован докером на моей машине, выглядит примерно так:

{
    "auths": {
        "https://index.docker.io/v1/": {
            "auth": "ZmFrZXBhc3N3b3JkMTIK",
            "email": "[email protected]"
        }
    }
}

Проверив исходный код, я обнаружил, что на самом деле существует тест для этого варианта использования (https://github.com/kubernetes/kubernetes/blob/6def707f9c8c6ead44d82ac8293f0115f0e47262/pkg/kubelet/dockertools/dockertools/dockertools/dockertools/dockertools/dockertools/dockertools/#L280)

Подтверждаю, что если вы просто возьмете и закодируете «auths», как в примере, это сработает для вас.

Наверное, документацию надо обновить. Подниму тикет на гитхабе.

person leonfs    schedule 18.09.2015
comment
Хм - не решила мою проблему. Думаю, изначально я пробовал оба формата. - person iameli; 22.09.2015