3 votes

Le registre docker d'OpenShift ne peut pas extraire une image de registry-1.docker.io

Je travaille avec la version d'OpenShift :

oc v3.10.0+dd10d17
kubernetes v1.10.0+b81c8f8
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://127.0.0.1:8443
openshift v3.10.0+e3465d0-44
kubernetes v1.10.0+b81c8f8

Ma version de docker est :

Client:
  Version:           18.06.1-ce
  API version:       1.38
  Go version:        go1.10.3
  Git commit:        e68fc7a
  Built:             Tue Aug 21 17:24:56 2018
  OS/Arch:           linux/amd64
  Experimental:      false

Server:
  Engine:
  Version:          18.06.1-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       e68fc7a
  Built:            Tue Aug 21 17:23:21 2018
  OS/Arch:          linux/amd64
  Experimental:     false

Pour démarrer le cluster local OpenShift sur mon ordinateur, j'ai suivi les étapes suivantes : https://github.com/openshift/origin/blob/master/docs/cluster_up_down.md#linux

Je voulais déployer une instance Redis et comme il n'y a pas de modèle Redis par défaut (il y a 20 modèles par défaut), je l'ai chargé en tant que modèle JSON à partir de l'URL : https://github.com/openshift/origin/blob/master/examples/db-templates/redis-ephemeral-template.json

Lors de la création de l'application à partir de ce modèle, le pod Redis ne peut pas démarrer et signale l'erreur suivante :

Échec de l'extraction de l'image "172.30.1.1:5000/openshift/redis@sha256:0cf7163e0589baab918b1d70cd1ed4c711e2430c618c672b9121f1fd35cf562a" : erreur rpc : code = Unknown desc = Error response from daemon : unknown : unable to pull manifest from docker.io/centos/redis-32-centos7:latest : Obtenir https://registry-1.docker.io/v2/ : net/http : requête annulée en attente de connexion (Client.Timeout exceeded while awaiting headers)

Lorsque je déploie l'application en fournissant une image docker openshiftroadshow/parksmap-katacoda:1.0.0 - il est tiré et déployé avec succès.

Je me suis connecté au conteneur publié à l'adresse 172.30.1.1:5000 qui héberge un registre docker pour OpenShift et il y a clairement un problème avec la résolution de registry-1.docker.io domaine :

bash-4.2$ nslookup registry-1.docker.io
;; connection timed out; no servers could be reached

Si je précise 8.8.8.8 DNS, tout va bien :

bash-4.2$ nslookup registry-1.docker.io 8.8.8.8
Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
Name:   registry-1.docker.io
Address: 52.22.67.152
....

J'ai donc cherché à savoir /etc/resolv.conf et voici son contenu :

bash-4.2$ cat /etc/resolv.conf 
nameserver 172.30.0.2
search default.svc.cluster.local svc.cluster.local cluster.local home
options ndots:5

Mes questions sont les suivantes :

  1. OpenShift utilise-t-il une solution DNS interne ? Si c'est le cas, dois-je modifier sa configuration ?
  2. Qui (et où) est responsable de la configuration du contenu de l'application resolv.conf fichier ?
  3. Y a-t-il un problème avec le modèle Redis que j'utilise ?
  4. Est-ce une bonne pratique d'ajouter les modèles manquants un par un et est-il possible d'ajouter tout un tas de modèles utiles manquants en une seule fois ?
  5. Que dois-je faire pour que mon exemple fonctionne ?

Je vous serais très reconnaissant de votre aide et de votre temps !

1voto

Graham Dumpleton Points 23711

Le modèle à la ligne :

a :

    {
        "description": "The OpenShift Namespace where the ImageStream resides.",
        "displayName": "Namespace",
        "name": "NAMESPACE",
        "value": "openshift"
    },

et utilise le NAMESPACE valeur à :

avec :

                        "from": {
                            "kind": "ImageStreamTag",
                            "name": "redis:${REDIS_VERSION}",
                            "namespace": "${NAMESPACE}"
                        },

Le modèle s'attend donc par défaut à ce que le flux d'images (ImageStream) corresponde à l'élément redis pour figurer dans le openshift projet. Ce modèle est lui-même généralement chargé dans le fichier openshift par le biais d'un projet :

ayant été chargé dans le openshift lors de sa création.

Vérifiez donc si les définitions des flux d'images pour le redis sont en fait chargées dans le openshift en utilisant :

oc get is/redis -n openshift --as system:admin

ou :

oc login -u system:admin
oc get is/redis -n openshift

Ce qui dépend de la façon dont oc cluster up est mis en place. Par défaut, la première peut ne pas fonctionner.

Il faut donc vérifier si ce flux d'images pour redis existe en premier.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X