记一次k8s服务部署之后，访问返回503
·
前言
最近有个同事在开发联调环境部署一个python服务，python服务通过uvicorn构建web服务，通过k8s部署，部署完成之后通过ingress访问报错，报错信息如下
<html>
<head><title>503 Service Temporarily Unavailable</title></head>
<body>
<center><h1>503 Service Temporarily Unavailable</h1></center>
<hr><center>nginx</center>
</body>
</html>检查下ingress配置
- path: /PythonAssistService
pathType: Prefix
backend:
service:
name: python-assist-creation-service
port:
number: 80
- path: /TestService
pathType: Prefix
backend:
service:
name: test-service
port:
number: 80同样的配置TestService访问是正常的，但是访问PythonAssistService确报错，但是针对此问题，有一下排查思路
确认pod是否启动成功
先通过kubectl get pods命令查看pod的运行状态
[devinteg@node1-198 /]$ kubectl get pods python-assist-creation-service-65c77c966b-pfhq8
NAME READY STATUS RESTARTS AGE
python-assist-creation-service-65c77c966b-pfhq8 1/1 Running 0 37m
上面的结果表示Pod是运行正常的，接着再看下服务的启动日志
kubectl logs python-assist-creation-service-65c77c966b-pfhq8 --tail=1000
服务启动是成功的
INFO: Started server process [1]
INFO: Waiting for application startup.
2025-10-25 06:47:49.624 PythonAssistCreationService 1 [uvicorn-MainThread] INFO [PythonAssistCreationService,f4bc91b806c54ecd,9f184bd6,true] main 50: Starting PythonAssistCreationService...
2025-10-25 06:47:49.624 PythonAssistCreationService 1 [uvicorn-MainThread] INFO [PythonAssistCreationService,3bb72fcd4a224ae9,860c9894,true] core.storage 380: Initializing MongoDB storage
2025-10-25 06:47:50.092 PythonAssistCreationService 1 [uvicorn-MainThread] INFO [PythonAssistCreationService,2e672e9727a14de8,5e525f0d,true] main 56: Using mongodb storage backend
INFO: Application startup complete.
INFO: Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)
确认Service是否配置成功
可以通过以下命令确认service是否存在
[devinteg@node1-198 /]$ kubectl get service python-assist-creation-service
Error from server (NotFound): services "python-assist-creation-service" not found
看到这里显然大家都知道了，这个service不存在所以访问的时候报错返回503就可以解释了，让我们看看service是如何配置
apiVersion: v1
kind: Service
metadata:
name: {{.SERVICE_NAME}}-service
labels:
app: {{.SERVICE_NAME}}
annotations:
version: v1.0
releasedBy: test
spec:
selector:
app: {{.SERVICE_NAME}}
type: ClusterIP
ports:
- protocol: TCP
port: 80
targetPort: 8000可以看到service的name配置 name: {{.SERVICE_NAME}}-service，这里的-service是不需要的，这里加了-service,就会导致service的name最终定义为python-assist-creation-service-service，但是service是用来做pod路由的抽象层，其name应该和pod的label保持一致，问题概况大致如下图
探寻问题的本质
完整的关系架构图如下
问题本质是ServiceName命令不正确，所以导致ingress路由到service找不到service，所以报错503了
所以正确的排查思路如下
Kubernetes相关概念总结
在 Kubernetes 中，Service 的实现原理涉及多个组件，包括 Deployment、Service、Pod 和 Container。下面详细介绍这些组件之间的关系和工作原理，并附上逻辑示意图。
组件关系和工作原理
- Deployment
- 定义了应用程序的期望状态，如 Pod 的数量、镜像版本、更新策略等。
- 管理 Pod 的创建、更新和删除，确保实际状态与期望状态一致。
- Service
- 抽象了后台的一组 Pod，提供了一种稳定的网络访问方式。
- 通过标签选择器选择与之关联的 Pod。
- 提供负载均衡和服务发现功能。
- Pod
- Kubernetes 中的最小可调度单元，包含一个或多个容器。
- 每个 Pod 有一个唯一的 IP 地址，并共享网络和存储资源。
- Container
- 运行在 Pod 内的实际应用实例。
- 通过容器运行时（如 Docker）来管理其生命周期。
Service 的实现原理
- 定义和注册 Service
- 用户创建一个 Service 对象，API 服务器接收该请求并存储在 etcd 中。
- Service 对象包含服务名称、选择器、类型、端口等信息。
- Endpoints 对象
- Kubernetes 自动创建并维护 Endpoints 对象，包含与 Service 关联的 Pod 的 IP 地址和端口。
- 通过标签选择器选择符合条件的 Pod。
- kube-proxy 组件
- 运行在每个节点上，负责实现 Service 的网络代理功能。
- 通过 iptables、ipvs 或用户空间模式来处理流量并进行负载均衡。
- 负载均衡和服务发现
- kube-proxy 根据 Endpoints 对象的 IP 地址和端口进行流量转发。
- 内置 DNS 服务为每个 Service 创建 DNS 记录，应用程序通过 DNS 名称访问 Service。
更多推荐
9
0- 0
已为社区贡献2条内容
所有评论(0)