私のマシンにdockerがセットアップされており、内部にdockerがあるminikubeもあるので、おそらく2つのdockerインスタンスが異なるVMで実行されています
イメージを作成してタグを付けてから、ローカルレジストリにプッシュし、正常にプッシュしました。また、レジストリからプルすることもできます。また、curlを実行してタグリストを取得すると、結果が表示されます。
1- docker build -t 127.0.0.1:5000/eliza/console:0.0.1 .
2- docker run -d -p 5000:5000 --name registry registry:2
3- docker tag a3703d02a199 127.0.0.1:5000/eliza/console:0.0.1
4- docker Push 127.0.0.1:5000/eliza/console:0.0.1
5- curl -X GET http://127.0.0.1:5000/v2/eliza/console/tags/list
上記のすべての手順は、まったく問題なく正常に機能しています。
私の問題は、私がminikubeを実行し、その中のローカルレジストリでこのイメージにアクセスしようとするときです
次のコマンドを実行すると
1- Sudo minikube start --insecure-registry 127.0.0.1:5000
2- eval $(minikube docker-env)
3- minikube ssh
4- curl -X GET http://127.0.0.1:5000/v2/eliza/console/tags/list
最後のステップ(ポイント4)では、次のメッセージが表示されました
curl:(7)127.0.0.1ポート5000への接続に失敗:接続が拒否されました
そのため、マシンからイメージレジストリにアクセスできますが、minikubeからはアクセスできません。もちろん、kubernetesを使用してこのイメージをminikubeにデプロイし、接続できないためにデプロイに失敗すると、 http://127.0 .0.1:50
ローカルレジストリを表示するようにminikubeを構成して、問題を解決してから、kubernetesを使用してイメージをminikubeに正常にデプロイできますか?
[〜#〜]更新[〜#〜]
このyamlファイル(名前はConsolePre.yaml)を使用して、kubernetesを使用してイメージをデプロイしています
apiVersion: v1
kind: Service
metadata:
name: tripbru-console
labels:
app: tripbru-console
spec:
ports:
- port: 9080
targetPort: 9080
nodePort: 30181
selector:
app: tripbru-console
tier: frontend
type: NodePort
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: tripbru-console
labels:
app: tripbru-console
spec:
strategy:
type: Recreate
template:
metadata:
labels:
app: tripbru-console
tier: frontend
spec:
containers:
- image: docker.local:5000/eliza/console:0.0.1
name: tripbru-console
ports:
- containerPort: 9080
name: tripbru-console
変更を適用するために次のコマンドを実行すると
Sudo kubectl apply -f /PATH_TO_YAML_FILE/ConsolePre.yaml
結果は
NAME READY STATUS RESTARTS AGE
po/tripbru-console-1655054400-x3g87 0/1 ErrImagePull 0 1m
そして、私がdescribeコマンドを実行すると
Sudo kubectl describe pod tripbru-console-1655054400-x3g87
説明結果に次のメッセージが見つかりました
デーモンからのエラー応答:{"メッセージ": "Get https://docker.local:5000/v1/_ping :dial tcp:lookup docker.local on 10.0.2.3:53:read udp 10.0 .2.15:57792-\u003e10.0.2.3:53:i/oタイムアウト "}
そして、私はminikube/etc/hostsにdocker.local xxx.xxx.xx.4を設定したので、どこから10.0.2.3:53か分からないと10.0.2.15:57792が由来します。
だから私はこの問題もどのように解決できますか?.
ありがとう:)
問題は、どこでも127.0.0.1
を使用するという概念です。これは間違っています。
したがって、マシンのIPが192.168.0.101の場合。その後、以下の作品
1- docker build -t 127.0.0.1:5000/eliza/console:0.0.1 .
2- docker run -d -p 5000:5000 --name registry registry:2
3- docker tag a3703d02a199 127.0.0.1:5000/eliza/console:0.0.1
4- docker Push 127.0.0.1:5000/eliza/console:0.0.1
5- curl -X GET http://127.0.0.1:5000/v2/eliza/console/tags/list
Docker runはレジストリを127.0.0.1:5000および192.168.0.101:5000にマップするためです。これで、お使いのマシンではこれ127.0.0.1
のみが機能します。今あなたが使うとき
3- minikube ssh
Minikubeマシンの内部に入り、127.0.0.1:5000で実行されているレジストリがありません。だからエラー。マシンmachine IPを使用して、このマシン内でレジストリに到達できません。
私が通常これを解決する方法は、ローカルと他のVMの両方でホスト名を使用することです。
そのため、マシンで/etc/hosts
にエントリを作成します
docker.local 127.0.0.1
コマンドを次のように変更します
1- docker build -t docker.local:5000/eliza/console:0.0.1 .
2- docker run -d -p 5000:5000 --name registry registry:2
3- docker tag a3703d02a199 docker.local:5000/eliza/console:0.0.1
4- docker Push docker.local:5000/eliza/console:0.0.1
5- curl -X GET http://docker.local:5000/v2/eliza/console/tags/list
次に、minikube ssh
を使用する場合は、docker.local
に/etc/hosts
のエントリを作成します。
docker.local 192.168.0.101
次にcurl -X GET http://docker.local:5000/v2/eliza/console/tags/list
編集-1
TLSの問題については、minikube内のdockerサービスを停止する必要があります
systemctl stop docker
次に/etc/systemd/system/docker.service.d/10-machine.conf
を編集して変更します
ExecStart =/usr/bin/dockerデーモン-H tcp://0.0.0.0:2376 -H unix:///var/run/docker.sock --tlsverify --tlscacert /etc/docker/ca.pem- tlscert /etc/docker/server.pem --tlskey /etc/docker/server-key.pem --label provider = virtualbox --insecure-registry 10.0.0.0/24
に
ExecStart =/usr/bin/dockerデーモン-H tcp://0.0.0.0:2376 -H unix:///var/run/docker.sock --tlsverify --tlscacert /etc/docker/ca.pem- tlscert /etc/docker/server.pem --tlskey /etc/docker/server-key.pem --label provider = virtualbox --insecure-registry 10.0.0.0/24 --insecure-registry docker.local:5000-安全でないレジストリ192.168.1.4:5000
次に、デーモンをリロードして、Dockerサービスを開始します。
systemctl daemon-reload
systemctl start docker
その後引っ張ってみます
docker pull docker.local:5000/eliza/console:0.0.1
そしてコマンドはうまくいくはずです
それは港湾労働者の国で人気のある質問です。こちらをご覧ください。 https://stackoverflow.com/a/24326540/6785908 他の方法もあります。たとえば、Mac上のDockerの場合、docker.for.mac.localhost
DNS名はホストマシンに解決されます
https://docs.docker.com/docker-for-mac/networking/#i-cannot-ping-my-containers から
MacのIPアドレスは変化しています(ネットワークにアクセスできない場合は変化しません)。 17.06以降は、ホストで使用される内部IPアドレスに解決される、Mac専用の特別なDNS名であるdocker.for.mac.localhostに接続することをお勧めします。
このminikubeの主な目的がローカルテストであると仮定すると、Dockerコンテナーを展開する簡単な方法があります(これにはローカルのDockerレジストリも必要ありません)。
ここで最初に理解する必要があるのは、マシンにdockerをインストールすると、2つの部分、1)dockerデーモンと対話できるdocker cli、2)dockerデーモンです。このメソッドでは、ローカルのdocker cliをminikubeのdockerデーモンにポイントし、docker build
を実行します。
ここに関連する部分を引用する
単一のVM of Kubernetesを使用する場合、minikubeの組み込みDockerデーモンを再利用することは非常に便利です。これは、ホストマシンでDockerレジストリを構築し、画像をそこに挿入する-ローカルの実験を高速化するminikubeと同じdockerデーモン内に構築できます。Docker画像に「最新」以外のタグを付け、画像をプルするときにそのタグを使用することを確認してください。それ以外の場合は、イメージのバージョンを指定しないでください。それは:latestであると想定され、プルイメージポリシーは常に対応します。デフォルトのDockerレジストリにDockerイメージのバージョンがないため、最終的にErrImagePullになる可能性があります(通常、 DockerHub)まだです。
Mac/linuxホストでdockerデーモンを使用できるようにするには、シェルでdocker-envコマンドを使用します。
eval $(minikube docker-env)
これで、ホストmac/linuxマシンのコマンドラインでdockerを使用して、minikube VM内のdockerデーモンと通信できるようになります。
docker container listコマンドを実行します:docker ps
。 kubernetesシステムに関連するコンテナも表示されます(現在、cliはminikubeが実行されているDockerデーモンを指しているため)。
次に、Dockerイメージをビルドします。その後、minikubeで利用できるようになります。
次のコマンドを発行して、Docker CLIをminikubeに向けることができます:eval $(minikube docker-env)次に、そこでイメージをビルドするか、どこにいてもそれらをエクスポートしてインポートできます。