CFN Cloud
Cloud Future New Life
en zh
2025-10-05 · 0 次浏览

Service: 稳定访问入口

用 Service 把动态 Pod 变成稳定的访问地址。

Pod 的 IP 会变,但 Service 提供稳定的访问入口,并通过标签选择器把流量转到正确的后端。

常见类型

  • ClusterIP:集群内访问
  • NodePort:节点端口暴露
  • LoadBalancer:云上负载均衡
  • Headless:不做负载均衡

示例 Service

apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api
  ports:
    - port: 80
      targetPort: 8080

排查要点

  • selector 是否匹配 Pod labels
  • kubectl get endpoints api 是否为空

实操要点

  • 先做快速盘点:kubectl get nodeskubectl get pods -Akubectl get events -A
  • 对比“期望状态”和“实际状态”,kubectl describe 往往能解释漂移或失败原因。
  • 名称、Label、Selector 要一致,避免 Service 或控制器找不到 Pod。

快速检查清单

  • 资源定义与业务意图一致。
  • Namespace、权限、镜像与环境匹配。
  • 上线前具备健康探针与可观测日志。

网络身份与服务发现

Kubernetes 网络强调“稳定名称”而不是“稳定 IP”。Service 提供稳定的虚拟 IP 和 DNS 名称,Endpoints 会追踪后端 Pod。Service 是在这个模型上构建网络访问与发现规则的关键环节。

Service 类型与路由选择

ClusterIP 适合内部访问,NodePort 与 LoadBalancer 用于对外暴露,Ingress 则负责 HTTP 路由与域名管理。选择何种类型取决于环境与流量路径,建议明确哪些入口是用户访问、哪些是内部调用、哪些仅用于调试。

Headless 与直连模式

Headless Service 不创建虚拟 IP,而是直接发布 Pod IP,适合需要固定地址或集群内 peer 发现的系统。此时客户端需要自行处理连接均衡与故障转移,但可以获得更直接的拓扑控制。

Port forward 的定位与限制

端口转发适合临时调试,不改变集群网络配置即可从本地访问 Pod 或 Service。它不应作为生产访问方式,也不适合长期自动化。需要常规访问时,应设计正式的 Service 或 Ingress。

DNS 命名习惯

Kubernetes DNS 支持短名称与完整名称,跨命名空间时建议使用 service.namespace 形式。稳定的命名规则可以减少配置混乱,提升团队协作效率。

外部流量路径

外部流量通常经过负载均衡、NodePort、kube-proxy 到达 Pod,每一跳都会引入超时与失败点。排障时应按路径逐段确认连接状态。

安全与策略

NetworkPolicy 可能阻断通信,即便 DNS 能解析也无法连通。若使用 mTLS 或服务网格策略,要确保策略与 Service 选择器一致,避免意外断流。

运维建议

统一命名规则便于 DNS 预测。上线时关注 endpoints 是否及时更新,尤其是在滚动更新期间。外部流量要设置健康检查与超时策略,避免负载均衡层把请求打到不可用实例。

kubectl get svc -n demo
kubectl get endpoints -n demo
kubectl get endpointslices -n demo
kubectl port-forward svc/demo-api 8080:80 -n demo

实战补充

把快速入门应用到真实业务时,建议固定一套检查项:资源 requests、就绪探针、日志覆盖、告警阈值、回滚步骤。清单要短小、可重复,并随仓库一起维护,这样每次发布都能快速对齐标准。

排障路径

从现象入手,不要先猜原因。先看事件,再看日志,最后验证流量路径和配置版本是否一致。若访问异常,先确认 readiness 和 endpoints,再逐段排查入口到后端的链路。记录每一步改动,方便回滚和复盘。

小练习

在测试环境做几次常见操作:扩缩容、重启单个 Pod、调整一项配置并验证效果。通过这些小练习,你能更直观地感受到系统收敛速度和异常时的行为。

维护与责任

明确服务归属、值班人和升级窗口,准备常见故障的处理步骤。依赖服务也需要纳入监控和备份计划,确保问题出现时能快速定位和恢复。

交付提醒

发布后用用户视角快速验证一次:访问核心接口、观察延迟和错误率,确认新旧 Pod 的状态稳定。如果涉及存储或网络,顺手核对磁盘用量、DNS 和 endpoints 是否正常。

回滚预案

写下最小可行的回滚步骤,包括需要恢复的配置、镜像版本和校验方式。这样在出现异常时可以迅速还原,而不是现场临时拼步骤。

参考链接