Kubernetes imagePullSecrets funktioniert nicht; Meldung "Bild nicht gefunden"

Habe ich ein off-the-shelf-Kubernetes-cluster, die in AWS ausgeführt, installiert mit der kube-up Skript. Ich würde gerne einige Container, die in eine private Docker-Hub-repository. Aber ich erhalte den Fehler "nicht gefunden":

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

Habe ich ein Geheimnis mit einem .dockercfg - Datei. Ich habe bestätigt, es funktioniert durch ausführen des Skripts geschrieben hier:

 > 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

Ich habe bestätigt, ich bin nicht mit das neue format des .dockercfg Skript, meins sieht so aus:

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

Habe ich versucht,läuft die Base64-Codierung auf Debian statt auf OS X, kein Glück gibt. (Es erzeugt die gleiche Zeichenfolge, wie erwartet werden könnte.)

Hier ist die YAML für meine Replikations-Controller:

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

Irgendwelche Ideen?

In deinem Beispiel sind Sie ziehen zwei unterschiedliche Bilder - haben Sie versucht, ziehen maestro?
Guter Fang -- reran den Befehl mit dem richtigen Bild. Gleichen Ergebnis.
Ich bin mit dem gleichen problem.. hast du eine Lösung finden?
Wenn es immer noch nützlich, um Sie zwei Monate später, ja, habe ich. Heh.

InformationsquelleAutor iameli | 2015-09-10

15

Andockfenster erzeugt eine config.json Datei in ~/.docker/
Es sieht so aus:
```
{
    "auths": {
        "index.docker.io/v1/": {
            "auth": "ZmFrZXBhc3N3b3JkMTIK",
            "email": "[email protected]"
        }
    }
}
```
was Sie eigentlich wollen, ist:
```
{"https://index.docker.io/v1/": {"auth": "XXXXXXXXXXXXXX", "email": "[email protected]"}}
```
Anmerkung 3 Dinge:
- 1) es gibt keine auths Verpackung
- 2) es ist https:// vor dem
  URL
- 3) es ist eine Zeile
dann base64 Kodieren, und die Verwendung als Daten für die .dockercfg Namen
```
apiVersion: v1
kind: Secret
metadata: 
  name: registry
data:
  .dockercfg: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX==
type: kubernetes.io/dockercfg
```
Beachten Sie wieder die .dockercfg Linie ist eine Zeile (base64 neigt dazu, erzeugen eine multi-line string)
- Du hast mich auf die Lösung -- stellt sich raus, mein problem war, dass mein Geheimnis war type: Opaque statt type: kubernetes.io/dockercfg. Cheers.
InformationsquelleAutor MrE
11

Ein weiterer möglicher Grund, warum Sie sehen könnte "Bild nicht gefunden", wenn der namespace-dein Geheimnis nicht mit dem namespace des Containers.

Zum Beispiel, wenn Ihre Bereitstellung yaml aussieht
```
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: mydeployment
  namespace: kube-system
```
Dann müssen Sie sicherstellen, dass das Geheimnis yaml verwendet ein matching-namespace:
```
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
  namespace: kube-system
data:
  .dockerconfigjson: ****
type: kubernetes.io/dockerconfigjson
```
Wenn Sie nicht geben Sie einen namespace für dein Geheimnis, es wird am Ende in den Standard-namespace und wird nicht verwendet. Es wird keine Warnung angezeigt. Ich verbrachte Stunden an diesem Problem, so dass ich dachte, ich Teile es hier in der Hoffnung ich kann Sie retten, jemand anderen die Zeit.
- Ich habe genau das gleiche Problem hier. Der einzige Unterschied ist, dass ich WILL, dass das Geheimnis in der Standard-namespace, wie ich nicht wollen, um es zu schaffen, die für alle namespaces verwendet wird. Gibt es eine Möglichkeit zum verweisen auf ein Geheimnis, dass die Standard-namespace, während das eindringen innerhalb eines namespace?
- ich danke Ihnen, sir. Du hast mich gerettet Stunden..
InformationsquelleAutor amarillion
4

Ein weiterer Grund könnten Sie sehen, dieser Fehler durch verwenden eines kubectl version anders als die, die cluster-version (z.B. mit kubectl 1.9.x gegen ein 1.8.x-cluster).

Dem format, der das Geheimnis erzeugt durch die kubectl erstellen Sie geheime docker-registry Befehl hat sich geändert zwischen den Versionen.

1,8.x-cluster erwarten, dass ein Geheimnis mit das format:
```
{  
   "https://registry.gitlab.com":{  
      "username":"...",
      "password":"...",
      "email":"...",
      "auth":"..."
   }
}
```
Aber das Geheimnis ist, erzeugt durch das 1.9.x kubectl hat dieses format:
```
{  
   "auths":{  
      "https://registry.gitlab.com":{  
         "username":"...",
         "password":"...",
         "email":"...",
         "auth":"..."
      }
   }
}
```
So, überprüfen Sie der Wert der .dockercfg Daten von Ihrem Geheimnis und stellen Sie sicher, dass es entspricht die erwartete format von Ihrem kubernetes-cluster version.
- Vielen Dank, das ist wirklich mein problem gelöst. Ich fummelte, um mit minikube auf windows, und zwar schokoladig installiert kubectl-cli version 1.9 standardmäßig minikube für windows noch ist 1,8. Führen Sie immer kubectl version und überprüfen Sie, für die passenden Versionen.
- Dies sollte die akzeptierte Antwort. MrE ' s Antwort ist auf dem richtigen Weg, aber es erwähnt nicht, dass warum das format anders ist. Vielen Dank eschnou Sie endlich das problem gelöst, die mich hatten, schlug meinen Kopf gegen die Wand für 2 Tage.
InformationsquelleAutor eschnou
3

Ich habe das gleiche problem. Was ich bemerkte ist, dass im Beispiel (https://kubernetes.io/docs/user-guide/images/#specifying-imagepullsecrets-on-a-pod) .dockercfg hat das folgende format:
```
{ 
   "https://index.docker.io/v1/": { 
     "auth": "ZmFrZXBhc3N3b3JkMTIK", 
     "email": "[email protected]" 
   } 
}
```
Während der eine generiert von docker in meinem Rechner sieht wie folgt aus:
```
{
    "auths": {
        "https://index.docker.io/v1/": {
            "auth": "ZmFrZXBhc3N3b3JkMTIK",
            "email": "[email protected]"
        }
    }
}
```
Durch überprüfung des Quellcodes habe ich festgestellt, dass es eigentlich ein test für diesen Anwendungsfall (https://github.com/kubernetes/kubernetes/blob/6def707f9c8c6ead44d82ac8293f0115f0e47262/pkg/kubelet/dockertools/docker_test.go#L280)

Bestätige ich Ihnen, dass, wenn Sie nehmen Sie einfach und encode "auths", wie im Beispiel, es wird für Sie arbeiten.

Wohl die Dokumentation aktualisiert werden soll. Ich will ein ticket auf github.
- Hmm-nicht mein problem lösen. Ich glaube, ich habe versucht, sowohl die Formate, die ursprünglich.
InformationsquelleAutor leonfs

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.