Kubernetes服务治理通过Service、Ingress、ConfigMap/Secret、服务网格及健康探针协同实现：Service提供稳定入口与负载均衡，Ingress实现七层路由，ConfigMap/Secret统一管理配置与凭证，服务网格增强流量控制，探针保障自愈能力。
Service 与 Endpoint：稳定服务入口与动态端点映射
Service 是服务治理的基石。它为一组带相同标签（selector）的 Pod 提供固定虚拟 IP（ClusterIP）和 DNS 名称，屏蔽底层 Pod 的动态变化。当 Pod 启动、销毁或扩缩容时，kube-proxy 会监听 Endpoint 对象的变化，实时更新 iptables 或 IPVS 规则，确保请求始终转发到健康实例。
Endpoint 不是手动维护的，而是由 Kubernetes 控制器根据 Pod 的 readiness probe 状态自动填充。只有通过就绪探针检查的 Pod 才会被加入 Endpoint 列表——这是实现精准流量控制的前提。
- Service 类型决定访问范围：ClusterIP（集群内）、NodePort（节点端口暴露）、LoadBalancer（云厂商 LB）、ExternalName（映射外部域名）
- 可通过
kubectl get endpoints <service-name>查看当前实际后端地址 - SessionAffinity 可启用基于 ClientIP 的会话保持，适用于有状态轻量场景
Ingress：面向外部的七层路由与灰度控制
Ingress 是集群南北向流量的统一入口，配合 Ingress Controller（如 Nginx、Traefik）实现 HTTP/HTTPS 层路由、TLS 终止、路径匹配等能力。它本身不处理流量，而是定义规则，由控制器解析并落地为具体代理配置。
生产中常用它做灰度发布：例如通过 annotation 控制流量权重，将 5% 请求导向新版本 Service；或结合请求头（如 canary: true）做 Header 匹配路由。
- 支持 path、host、method、header 多维度匹配
- 可集成 WAF、限流插件（取决于所选 Ingress Controller 能力）
- 需搭配 Service 使用——Ingress 指向的是 Service，不是 Pod
ConfigMap 与 Secret：统一配置与安全凭证管理
配置与代码分离是服务治理的基础原则。ConfigMap 存储非敏感配置（如日志级别、超时参数），Secret 存储密码、Token、TLS 证书等敏感信息。二者均可通过环境变量或 Volume 方式注入 Pod。
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
挂载为文件时，ConfigMap/Secret 内容会自动热更新（应用需监听文件变更或使用 inotify）；挂载为环境变量则只在 Pod 启动时注入，变更需重启。
- 建议按环境（dev/staging/prod）创建不同命名空间下的 ConfigMap
- Secret 默认 base64 编码，但不加密存储，应配合 RBAC 严格限制读取权限
- Helm Chart 或 Kustomize 可帮助管理多环境差异化配置
服务网格（如 Istio）：精细化流量管控与可观测性增强
Kubernetes 原生能力适合基础治理，复杂场景需服务网格补充。Istio 通过 Sidecar 注入 Envoy 代理，在数据平面实现无侵入的高级治理：
- VirtualService 定义路由规则（按 header、path、权重分流）
- DestinationRule 定义目标子集（subset）及连接池、熔断、重试策略
- 自动收集指标、日志、链路追踪，打通全链路可观测性
- 支持故障注入（延迟、错误）、流量镜像、金丝雀发布等实战能力
它不替代 Service，而是叠加在其之上——Service 仍负责集群内发现与基本负载均衡，Istio 在此基础上做更细粒度的流量编排。
健康检查与自愈机制：保障服务持续可用
治理效果最终依赖于系统能否识别并响应异常。Kubernetes 通过两类探针构建闭环：
- Liveness Probe：判定容器是否存活，失败则重启容器
- Readiness Probe：判定容器是否就绪，失败则从 Endpoint 中剔除，不再接收新流量
两者配合，既避免“假活”Pod 持续接收请求，也防止“未就绪”Pod 过早参与负载。合理设置初始延迟（initialDelaySeconds）和探测间隔（periodSeconds），能显著降低发布抖动。
