web-dev-qa-db-fra.com

Kubernetes imagePullSecrets ne fonctionne pas; obtenir "image introuvable"

J'ai un cluster Kubernetes prêt à l'emploi s'exécutant sur AWS, installé avec le kube-up script. Je voudrais exécuter certains conteneurs qui se trouvent dans un référentiel Docker Hub privé. Mais je reçois toujours une erreur "introuvable":

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

J'ai créé un secret contenant un .dockercfg fichier. J'ai confirmé que cela fonctionne en exécutant le script publié ici :

 > 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

J'ai confirmé que je n'utilise pas le nouveau format du script .dockercfg , le mien ressemble à ceci:

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

J'ai essayé exécuter l'encodage Base64 sur Debian au lieu d'OS X , pas de chance là-bas. (Il produit la même chaîne, comme on pourrait s'y attendre.)

Voici le YAML pour mon contrôleur de réplication:

---
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"}

Des idées?

dockerkubernetesdockerhub
15
iameli

Docker génère un config.json fichier dans ~/.docker/ On dirait:

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

ce que vous voulez réellement c'est:

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

noter 3 choses:

  • 1) il n'y a pas d'habillage auths
  • 2) il y a https:// devant l'URL
  • 3) c'est ne ligne

alors vous base64 encodez cela et utilisez comme données pour le .dockercfg Nom

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

Notez à nouveau le .dockercfg la ligne est ne ligne (base64 a tendance à générer une chaîne de plusieurs lignes)

15
MrE

Une autre raison possible pour laquelle vous pouvez voir "image introuvable" est que l'espace de noms de votre secret ne correspond pas à l'espace de noms du conteneur.

Par exemple, si votre yaml de déploiement ressemble à

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

Ensuite, vous devez vous assurer que le yaml secret utilise un espace de noms correspondant:

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

Si vous ne spécifiez pas d'espace de noms pour votre secret, il se retrouvera dans l'espace de noms par défaut et ne sera pas utilisé. Il n'y a aucun message d'avertissement. Je viens de passer des heures sur cette question, alors j'ai pensé que je la partagerais ici dans l'espoir de gagner du temps à quelqu'un d'autre.

11
amarillion

Une autre raison pour laquelle vous pouvez voir cette erreur est due à l'utilisation d'une version kubectl différente de la version du cluster (par exemple, en utilisant kubectl 1.9.x contre un cluster 1.8.x).

Le format du secret généré par la commande kubectl create secret docker-registry a changé entre les versions.

Un cluster 1.8.x attend un secret au format:

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

Mais le secret généré par le kubectl 1.9.x a ce format:

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

Donc, revérifiez la valeur des données .dockercfg de votre secret et vérifiez qu'elle correspond au format attendu par la version de votre cluster kubernetes.

4
eschnou

J'ai rencontré le même problème. Ce que j'ai remarqué, c'est que dans l'exemple ( https://kubernetes.io/docs/user-guide/images/#specifying-imagepullsecrets-on-a-pod ) .dockercfg a le format suivant :

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

Alors que celui généré par docker dans ma machine ressemble à ceci:

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

En vérifiant le code source, j'ai constaté qu'il existe en fait un test pour ce cas d'utilisation ( https://github.com/kubernetes/kubernetes/blob/6def707f9c8c6ead44d82ac8293f0115f0e47262/pkg/kubelet/dockertools/docker_test.go# L28 )

Je vous confirme que si vous prenez et encodez simplement des "auths", comme dans l'exemple, cela fonctionnera pour vous.

La documentation devrait probablement être mise à jour. Je vais lever un ticket sur github.

3
leonfs