ks中nginx和headless服务搭配使用引发的小问题引言一个让人挠头的线上故障大家好我是你们的老朋友——一个踩坑无数的技术博主。今天要聊的话题源自一次让我差点把键盘摔了的线上事故。那天我们团队在 Kubernetes简称 ks上部署了一套微服务核心组件是 nginx 和 headless 服务。本以为一切顺利结果线上突然出现间歇性的 502 错误用户反馈说页面加载像蜗牛一样慢。排查了整整一天最后发现罪魁祸首竟是 nginx 和 headless 服务的“相爱相杀”。好废话不多说我们直接进入正题。## 问题背景nginx 和 headless 服务是什么在 Kubernetes 中nginx 通常作为反向代理或 Ingress Controller负责负载均衡和路由请求。而 headless 服务即spec.clusterIP: None的服务则用于 Pod 间的直接通信不分配虚拟 IP而是返回所有 Pod 的 DNS 记录。听起来很美好对吧但当你把 nginx 和 headless 服务搭配使用时麻烦就来了。为什么呢因为 headless 服务的 DNS 解析会返回所有 Pod 的 IP 列表而 nginx 默认的负载均衡策略是基于 DNS 的 round-robin。如果 nginx 的 DNS 缓存或解析行为不当就会导致请求被路由到错误的 Pod甚至出现连接超时。## 问题重现一个简单的示例为了让你亲身体验这个问题我们先模拟一个场景。假设我们有一个 headless 服务my-headless-svc它背后有 3 个 Pod分别运行着不同的应用实例。同时我们有一个 nginx 配置将其作为反向代理指向这个 headless 服务。### 示例 1headless 服务配置创建一个 headless 服务和一个简单的 Deployment。注意headless 服务的clusterIP要设置为None。yaml# headless-service.yamlapiVersion: v1kind: Servicemetadata: name: my-headless-svcspec: clusterIP: None # 关键headless 服务 selector: app: my-app ports: - port: 80 targetPort: 8080---# deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata: name: my-app-deploymentspec: replicas: 3 selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: my-app image: nginx:alpine # 这里用 nginx 模拟应用 ports: - containerPort: 8080### 示例 2nginx 配置问题版接下来我们部署一个 nginx Pod并将其配置为反向代理到 headless 服务。这里使用resolver指令来处理 DNS 解析。nginx# nginx.confevents { worker_connections 1024;}http { upstream backend { server my-headless-svc.default.svc.cluster.local:80; } server { listen 80; location / { proxy_pass http://backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }}然后我们创建一个 ConfigMap 来挂载这个配置并启动 nginx Pod。yaml# nginx-deployment.yamlapiVersion: v1kind: ConfigMapmetadata: name: nginx-configdata: nginx.conf: | events { worker_connections 1024; } http { upstream backend { server my-headless-svc.default.svc.cluster.local:80; } server { listen 80; location / { proxy_pass http://backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } } }---apiVersion: apps/v1kind: Deploymentmetadata: name: nginx-proxyspec: replicas: 1 selector: matchLabels: app: nginx-proxy template: metadata: labels: app: nginx-proxy spec: containers: - name: nginx image: nginx:alpine ports: - containerPort: 80 volumeMounts: - name: config mountPath: /etc/nginx/nginx.conf subPath: nginx.conf volumes: - name: config configMap: name: nginx-config## 问题分析为什么会有小问题当你运行上述配置后可能会遇到以下现象- 请求偶尔返回 502 Bad Gateway。- 部分 Pod 的日志显示连接被拒绝。- 负载均衡不均匀。根本原因nginx 默认的upstream模块在解析my-headless-svc.default.svc.cluster.local时会使用系统 DNS 解析。对于 headless 服务DNS 返回的是所有 Pod 的 IP 列表但 nginx 在第一次解析后会缓存这些 IP直到连接失败或超时。如果 Pod 被重新调度比如因滚动更新或故障其 IP 会变化但 nginx 的缓存不会立即更新导致请求被路由到已不存在的 Pod。更糟糕的是如果 nginx 的resolver指令没有正确配置它可能不会定期重新解析 DNS导致问题持续存在。## 解决方案如何避免### 方案 1使用 nginx 的 resolver 和动态上游nginx 支持resolver指令可以设置 DNS 解析的缓存时间和超时。通过结合valid参数我们可以让 nginx 定期重新解析 headless 服务的 DNS 记录。nginx# nginx-resolver.confevents { worker_connections 1024;}http { # 使用 kube-dns 服务进行解析并设置缓存时间 resolver kube-dns.kube-system.svc.cluster.local valid10s; upstream backend { # 使用变量来强制每次请求都进行 DNS 解析 server my-headless-svc.default.svc.cluster.local:80 resolve; } server { listen 80; location / { proxy_pass http://backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }}关键点-resolver指定了 DNS 服务器这里使用集群内的 kube-dns。-valid10s表示 DNS 缓存的有效期为 10 秒nginx 会每 10 秒重新解析一次。-server ... resolve告诉 nginx 使用 DNS 解析并动态更新上游列表。### 方案 2使用普通服务替代 headless 服务如果不需要 headless 服务的特性如直接访问 Pod IP可以改用普通 ClusterIP 服务。普通服务会有一个虚拟 IPnginx 只需连接到这个 VIP而不需要关心后端的 Pod 变化。yaml# normal-service.yamlapiVersion: v1kind: Servicemetadata: name: my-normal-svcspec: clusterIP: 10.96.0.100 # 可以显式指定或让 k8s 自动分配 selector: app: my-app ports: - port: 80 targetPort: 8080然后nginx 配置中直接使用server my-normal-svc.default.svc.cluster.local:80;即可。这样nginx 只需连接到服务的 VIP而 VIP 会由 kube-proxy 自动转发到健康的 Pod。### 方案 3使用 Ingress Controller如果 nginx 是作为 Ingress Controller 部署的可以考虑使用 Kubernetes 原生的 Ingress 资源或专门的 Ingress Controller如 nginx-ingress。这些组件已经内置了对 headless 服务的支持并自动处理 DNS 解析和 Pod 健康检查。## 总结今天这篇文章我们从一次线上故障出发深入探讨了在 Kubernetes 中 nginx 和 headless 服务搭配使用时可能引发的小问题。核心原因在于 nginx 对 headless 服务的 DNS 缓存机制与 Pod 的动态变化不匹配导致请求路由错误。解决方案包括1. 配置 nginx 的resolver指令和resolve参数强制动态 DNS 解析。2. 改用普通 ClusterIP 服务利用 VIP 的稳定性。3. 使用 Ingress Controller 等成熟方案。记住在 Kubernetes 环境中服务的动态性是常态。任何时候当你使用 nginx 跳转 headless 服务时都要警惕 DNS 缓存问题。希望这篇文章能帮你避免我踩过的坑。如果你有类似经历欢迎在评论区分享
