docker registry罕见原因导致的故障dial tcp 127.0.0.1:5000: connect: connection refused

本文主要是介绍docker registry罕见原因导致的故障dial tcp 127.0.0.1:5000: connect: connection refused,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

背景

系统环境:k8s+docker+cri-dockerd
因为我不想把镜像通过Docker hub公开,以及将来在不联网的生产环境部署,自己运行一个docker存储库,在k8s部署工作负载时从中拉取镜像。

相关命令形如:

docker run -d -p 5000:5000 --restart=always --name registry registry:2docker push localhost:5000/user/user-image

问题

没有修改环境配置,进行了一些k8s和docker相关操作后,再推送镜像时突然发生错误。

Get "http://localhost:5000/v2/": dial tcp 127.0.0.1:5000: connect: connection refused

解决

一开始我按一般排查故障的方法,检查 registry 容器日志,docker 服务日志,重启docker服务,重新部署 registry 容器等等,均未解决问题,百思不得其解。

后续我进行k8s操作,部署时发现问题,大概是在k8s部署的容器可以分配一个Node端口,同一个Node的同一个端口只能分配一次,导致只有一个Node时不能部署第二份。表现如下:

root@vmi1640551:~# kubectl -n test-cinema-2 get po
NAME                            READY   STATUS    RESTARTS   AGE
a-bookings-1-756694bb6b-sdqbg   0/1     Pending   0          8m4s
a-movies-1-66785d95ff-6jp27     0/1     Pending   0          8m4s
a-showtimes-1-fcb9d8bc6-9txh5   0/1     Pending   0          8m4s
a-users-1-59bb6845cf-zb7xw      0/1     Pending   0          8m4s
proxy                           1/1     Running   0          8m14s
root@vmi1640551:~# kubectl -n test-cinema-2 describe po a-bookings-1-756694bb6b-sdqbg  
Name:             a-bookings-1-756694bb6b-sdqbg
Namespace:        test-cinema-2
Priority:         0
Service Account:  default
Node:             <none>
Labels:           app=a-bookings-1pod-template-hash=756694bb6b
Annotations:      kompose.cmd: kompose --file docker-compose.yml convertkompose.version: 1.32.0 (HEAD)
Status:           Pending
IP:               
IPs:              <none>
Controlled By:    ReplicaSet/a-bookings-1-756694bb6b
Containers:bookings:Image:      localhost:5050/cinema-2/bookingsPort:       5003/TCPHost Port:  5003/TCPLimits:cpu:  100mRequests:cpu:        100mReadiness:    http-get http://:5003/health-check delay=0s timeout=1s period=3s #success=1 #failure=2Environment:  <none>Mounts:/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-pmx4b (ro)
Conditions:Type           StatusPodScheduled   False 
Volumes:kube-api-access-pmx4b:Type:                    Projected (a volume that contains injected data from multiple sources)TokenExpirationSeconds:  3607ConfigMapName:           kube-root-ca.crtConfigMapOptional:       <nil>DownwardAPI:             true
QoS Class:                   Burstable
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300snode.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:Type     Reason            Age                   From               Message----     ------            ----                  ----               -------Warning  FailedScheduling  3m9s (x2 over 8m20s)  default-scheduler  0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports. preemption: 0/1 nodes are available: 1 No preemption victims found for incoming pod.
root@vmi1640551:~# 

我猜测可能是有k8s中容器占用了5000端口。修改 registry 绑定的本地端口后(比如改为5050),推送成功了。
检查确实如此,有一个工作负载的配置如下:

apiVersion: apps/v1
kind: Deployment
metadata:annotations:kompose.cmd: kompose --file docker-compose.yml convertkompose.version: 1.32.0 (HEAD)labels:io.kompose.service: usersname: users
spec:replicas: 1selector:matchLabels:io.kompose.service: userstemplate:metadata:annotations:kompose.cmd: kompose --file docker-compose.yml convertkompose.version: 1.32.0 (HEAD)labels:io.kompose.network/cinema-2-default: "true"io.kompose.service: usersspec:containers:- image: localhost:5000/cinema-2/usersname: usersports:- containerPort: 5000hostPort: 5000 # ! 注意这里 !protocol: TCPreadinessProbe:httpGet:path: /health-checkport: 5000periodSeconds: 3 # 默认 10failureThreshold: 2 # 默认 3successThreshold: 1timeoutSeconds: 1restartPolicy: Always

删除实际未使用的 hostPort 后恢复正常。

后续疑问

有些疑问还没来得及解决:

  • k8s、docker的网络原理是怎样的?
  • 特别的,由k8s pull镜像、从主机docker push镜像和curl localhost:5000 的请求会被如何路由?是否有区别?
  • registry 和 k8s中部署的工作负载应该只有一个能监听唯一Node的5000端口,为什么看起来似乎都部署成功了,看不到错误?

这篇关于docker registry罕见原因导致的故障dial tcp 127.0.0.1:5000: connect: connection refused的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/719452

相关文章

Linux samba共享慢的原因及解决方案

《Linuxsamba共享慢的原因及解决方案》:本文主要介绍Linuxsamba共享慢的原因及解决方案,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录linux samba共享慢原因及解决问题表现原因解决办法总结Linandroidux samba共享慢原因及解决

Spring事务中@Transactional注解不生效的原因分析与解决

《Spring事务中@Transactional注解不生效的原因分析与解决》在Spring框架中,@Transactional注解是管理数据库事务的核心方式,本文将深入分析事务自调用的底层原理,解释为... 目录1. 引言2. 事务自调用问题重现2.1 示例代码2.2 问题现象3. 为什么事务自调用会失效3

mysql出现ERROR 2003 (HY000): Can‘t connect to MySQL server on ‘localhost‘ (10061)的解决方法

《mysql出现ERROR2003(HY000):Can‘tconnecttoMySQLserveron‘localhost‘(10061)的解决方法》本文主要介绍了mysql出现... 目录前言:第一步:第二步:第三步:总结:前言:当你想通过命令窗口想打开mysql时候发现提http://www.cpp

Docker镜像pull失败两种解决办法小结

《Docker镜像pull失败两种解决办法小结》有时候我们在拉取Docker镜像的过程中会遇到一些问题,:本文主要介绍Docker镜像pull失败两种解决办法的相关资料,文中通过代码介绍的非常详细... 目录docker 镜像 pull 失败解决办法1DrQwWCocker 镜像 pull 失败解决方法2总

找不到Anaconda prompt终端的原因分析及解决方案

《找不到Anacondaprompt终端的原因分析及解决方案》因为anaconda还没有初始化,在安装anaconda的过程中,有一行是否要添加anaconda到菜单目录中,由于没有勾选,导致没有菜... 目录问题原因问http://www.chinasem.cn题解决安装了 Anaconda 却找不到 An

Spring定时任务只执行一次的原因分析与解决方案

《Spring定时任务只执行一次的原因分析与解决方案》在使用Spring的@Scheduled定时任务时,你是否遇到过任务只执行一次,后续不再触发的情况?这种情况可能由多种原因导致,如未启用调度、线程... 目录1. 问题背景2. Spring定时任务的基本用法3. 为什么定时任务只执行一次?3.1 未启用

通过Docker Compose部署MySQL的详细教程

《通过DockerCompose部署MySQL的详细教程》DockerCompose作为Docker官方的容器编排工具,为MySQL数据库部署带来了显著优势,下面小编就来为大家详细介绍一... 目录一、docker Compose 部署 mysql 的优势二、环境准备与基础配置2.1 项目目录结构2.2 基

Java报NoClassDefFoundError异常的原因及解决

《Java报NoClassDefFoundError异常的原因及解决》在Java开发过程中,java.lang.NoClassDefFoundError是一个令人头疼的运行时错误,本文将深入探讨这一问... 目录一、问题分析二、报错原因三、解决思路四、常见场景及原因五、深入解决思路六、预http://www

关于Docker Desktop的WSL报错问题解决办法

《关于DockerDesktop的WSL报错问题解决办法》:本文主要介绍关于DockerDesktop的WSL报错问题解决办法的相关资料,排查发现是因清理%temp%文件夹误删关键WSL文件,... 目录发现问题排查过程:解决方法其实很简单:重装之后再看就能够查到了:最后分享几个排查这类问题的小www.cp

如何使用Docker部署FTP和Nginx并通过HTTP访问FTP里的文件

《如何使用Docker部署FTP和Nginx并通过HTTP访问FTP里的文件》本文介绍了如何使用Docker部署FTP服务器和Nginx,并通过HTTP访问FTP中的文件,通过将FTP数据目录挂载到N... 目录docker部署FTP和Nginx并通过HTTP访问FTP里的文件1. 部署 FTP 服务器 (