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

相关文章

通过Docker容器部署Python环境的全流程

《通过Docker容器部署Python环境的全流程》在现代化开发流程中,Docker因其轻量化、环境隔离和跨平台一致性的特性,已成为部署Python应用的标准工具,本文将详细演示如何通过Docker容... 目录引言一、docker与python的协同优势二、核心步骤详解三、进阶配置技巧四、生产环境最佳实践

java.sql.SQLTransientConnectionException连接超时异常原因及解决方案

《java.sql.SQLTransientConnectionException连接超时异常原因及解决方案》:本文主要介绍java.sql.SQLTransientConnectionExcep... 目录一、引言二、异常信息分析三、可能的原因3.1 连接池配置不合理3.2 数据库负载过高3.3 连接泄漏

javacv依赖太大导致jar包也大的解决办法

《javacv依赖太大导致jar包也大的解决办法》随着项目的复杂度和依赖关系的增加,打包后的JAR包可能会变得很大,:本文主要介绍javacv依赖太大导致jar包也大的解决办法,文中通过代码介绍的... 目录前言1.检查依赖2.更改依赖3.检查副依赖总结 前言最近在写项目时,用到了Javacv里的获取视频

使用docker搭建嵌入式Linux开发环境

《使用docker搭建嵌入式Linux开发环境》本文主要介绍了使用docker搭建嵌入式Linux开发环境,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面... 目录1、前言2、安装docker3、编写容器管理脚本4、创建容器1、前言在日常开发全志、rk等不同

深度剖析SpringBoot日志性能提升的原因与解决

《深度剖析SpringBoot日志性能提升的原因与解决》日志记录本该是辅助工具,却为何成了性能瓶颈,SpringBoot如何用代码彻底破解日志导致的高延迟问题,感兴趣的小伙伴可以跟随小编一起学习一下... 目录前言第一章:日志性能陷阱的底层原理1.1 日志级别的“双刃剑”效应1.2 同步日志的“吞吐量杀手”

SysMain服务可以关吗? 解决SysMain服务导致的高CPU使用率问题

《SysMain服务可以关吗?解决SysMain服务导致的高CPU使用率问题》SysMain服务是超级预读取,该服务会记录您打开应用程序的模式,并预先将它们加载到内存中以节省时间,但它可能占用大量... 在使用电脑的过程中,CPU使用率居高不下是许多用户都遇到过的问题,其中名为SysMain的服务往往是罪魁

Linux之UDP和TCP报头管理方式

《Linux之UDP和TCP报头管理方式》文章系统讲解了传输层协议UDP与TCP的核心区别:UDP无连接、不可靠,适合实时传输(如视频),通过端口号标识应用;TCP有连接、可靠,通过确认应答、序号、窗... 目录一、关于端口号1.1 端口号的理解1.2 端口号范围的划分1.3 认识知名端口号1.4 一个进程

使用IDEA部署Docker应用指南分享

《使用IDEA部署Docker应用指南分享》本文介绍了使用IDEA部署Docker应用的四步流程:创建Dockerfile、配置IDEADocker连接、设置运行调试环境、构建运行镜像,并强调需准备本... 目录一、创建 dockerfile 配置文件二、配置 IDEA 的 Docker 连接三、配置 Do

Java.lang.InterruptedException被中止异常的原因及解决方案

《Java.lang.InterruptedException被中止异常的原因及解决方案》Java.lang.InterruptedException是线程被中断时抛出的异常,用于协作停止执行,常见于... 目录报错问题报错原因解决方法Java.lang.InterruptedException 是 Jav

解决1093 - You can‘t specify target table报错问题及原因分析

《解决1093-Youcan‘tspecifytargettable报错问题及原因分析》MySQL1093错误因UPDATE/DELETE语句的FROM子句直接引用目标表或嵌套子查询导致,... 目录报js错原因分析具体原因解决办法方法一:使用临时表方法二:使用JOIN方法三:使用EXISTS示例总结报错原