Kubernetes 网络 — Broken Labs 与 事件响应
Source: Dev.to
当流量出现故障时，切勿猜测。
始终遵循以下顺序：
Ingress
↓
Service
↓
Endpoints
↓
Pod
↓
Container如果某一层出现故障，其上层的所有内容都会失效。
实验 1 — ClusterIP 服务（最常见的生产故障）
场景
- Pod 运行中
- Service 已存在
- 浏览器 /
curl没有返回 任何内容
错误的配置
Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
spec:
replicas: 2
selector:
matchLabels:
app: api
template:
metadata:
labels:
app: api-v1 # ❌ 错误的标签
spec:
containers:
- name: app
image: hashicorp/http-echo:0.2.3
args:
- "-listen=:8080"
- "-text=API OK"
ports:
- containerPort: 8080Service
apiVersion: v1
kind: Service
metadata:
name: api-svc
spec:
selector:
app: api # ❌ 不匹配
ports:
- port: 80
targetPort: 8080症状
kubectl get pods
kubectl get svc
kubectl get endpoints api-svc输出
ENDPOINTS: 根本原因
Service 的 selector 未匹配 Pod 的标签。
修复方法
kubectl edit deployment api将 Pod 的标签改为与 Service selector 匹配：
labels:
app: api验证：
kubectl get endpoints api-svcDevOps 面试答案
问： Service 已存在但没有流量，Pod 正在运行。你会检查什么？
答： 检查 Endpoints。空的 endpoints 表明 selector 不匹配或就绪状态有问题。
何时使用 ClusterIP
- 内部 API
- 后端服务
- 微服务
优缺点
优点
- 安全（不对外暴露）
- 在集群内部拥有稳定 IP
- 随 Pod 数量自动扩展
缺点
- 只能在集群内部访问
实验 2 — NodePort（为何它很危险）
场景
- NodePort 已暴露
- 有时可以工作
- 节点更换后失效
部署示例
apiVersion: v1
kind: Service
metadata:
name: node-svc
spec:
type: NodePort
selector:
app: api
ports:
- port: 80
targetPort: 8080
nodePort: 30080症状
- 通过 某个节点的 IP 访问服务时可用
- 使用其他节点的 IP 时失败
- 安全团队标记了这些开放端口
根本原因
NodePort 会在集群的 每个节点 上打开相同的端口，无法控制路由，导致服务依赖于你访问的节点 IP。
DevOps 解决方案
将 NodePort 替换为以下任意一种方式：
ClusterIP+ IngressLoadBalancer（如果云提供商支持）
面试答案
问： 为什么在生产环境中很少使用 NodePort？
答： 它会暴露所有节点，缺乏细粒度的安全和路由控制，且扩展性差。
NodePort 可接受的场景
- 调试 / 快速测试
- 临时的外部访问
- 学习或沙箱环境
Source: …
实验 3 — LoadBalancer 服务（云环境）
场景
LoadBalancer类型的 Service 会创建一个外部 IP- 应用仍然无法访问
部署清单
apiVersion: v1
kind: Service
metadata:
name: lb-svc
spec:
type: LoadBalancer
selector:
app: api
ports:
- port: 80
targetPort: 8080症状
kubectl get svc典型输出会显示已分配的外部 IP，但使用 curl 或浏览器仍然访问不到该服务。
常见根本原因
- 云提供商延迟 – 外部负载均衡器可能仍在创建中。
- 防火墙规则缺失 – 云防火墙阻止了对分配端口的流量。
- Pod 就绪状态 – Pod 未就绪，导致负载均衡器没有健康的后端节点。
修复检查清单
- 等待
EXTERNAL-IP列显示真实的 IP（而不是 “）。 - 确认云防火墙 / 安全组已放行服务端口的入站流量（通常是 80 或 443）。
- 确认 Pod 为
Ready状态（kubectl get pods），并且 Service 已有端点（kubectl get endpoints lb-svc）。 - 若使用私有 VPC，确保能够访问该 IP（VPN、跳板机等）。
DevOps 面试答案
问： LoadBalancer Service 显示外部 IP，但应用不可达。你会检查哪些方面？
答：
- 云提供商的负载均衡器创建/配置状态。
- 防火墙或安全组规则。
- Pod 的就绪情况以及 Service 的端点是否已填充。
额外的 LoadBalancer 故障排查
LoadBalancer 问题与排查
- External IP 已存在
- 浏览器超时
排查步骤
kubectl describe svc lb-svc
kubectl get endpoints lb-svc检查云端
- 健康检查
- 安全组
- 目标端口不匹配
根本原因
云端 LB 健康检查失败，原因可能是：
- 端口错误
- 应用未监听
- Readiness probe 失败
DevOps 解决方案
- 对齐端口
- 添加 readiness probe
- 验证安全组
面试答案
问： 为什么不对每个服务都使用 LoadBalancer？
答： 成本较高、缺乏路由功能，并且相较于 Ingress 灵活性受限。
LAB 4 — Ingress（最常被面试的话题）
场景
- 已创建 Ingress
- 返回 404 错误
损坏的 Ingress 清单
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-ingress
spec:
rules:
- http:
paths:
- path: /app
pathType: Prefix
backend:
service:
name: wrong-svc # ❌ wrong name
port:
number: 80症状
- Ingress IP 正常
- 总是返回 404
故障排除
kubectl describe ingress
kubectl get svc
kubectl get pods -n ingress-nginx根本原因
Ingress 路由指向了一个不存在的服务。
修复
在 Ingress 规范中纠正后端服务名称。
面试答案
Q: Ingress 返回 404 时，你首先检查什么？
A: 检查 Ingress 规则、服务名称、服务端口以及控制器日志。
Source:
实验 5 — DNS 故障（隐藏杀手）
场景
- 服务已存在
- DNS 名称解析失败
测试
kubectl run test --rm -it --image=busybox -- sh
nslookup api-svc根本原因
- CoreDNS 未运行
- 命名空间错误
- 服务被删除
解决办法
kubectl get pods -n kube-system | grep dns如有必要，重新启动 DNS Pod。
面试答案
问： Pod 如何发现服务？
答： 通过 Kubernetes DNS，将 Service 名称解析为其 ClusterIP。
事件响应手册 (Real DevOps)
步骤指南
- 检查 Ingress
- 检查 Service
- 检查 Endpoints
- 检查 Pod 就绪状态
- 检查容器日志
绝不要跳过步骤。
最终决策矩阵（非常重要）
| Requirement | Use |
|---|---|
| 内部流量 | ClusterIP |
| 外部生产流量 | Ingress |
| 云简易暴露 | LoadBalancer |
| 仅调试 | NodePort |
面试快速问答（必须记住）
-
Q: 空的端点意味着什么？
A: 选择器不匹配或就绪失败。 -
Q: 生产环境中最常用的服务是什么？
A:ClusterIP。 -
Q: 为什么使用 Ingress？
A: 路由、TLS、成本效益。 -
Q: 生产环境中使用 NodePort 吗？
A: 避免。
真正的 DevOps 真相
网络问题是：
- 可预测的
- 分层的
- 始终可观察的
在苦苦挣扎与快速解决之间的差异是 有条理的思考。