固定服务地址解决云环境的DNS失效

只有一个实例时，调用方靠 DNS 名字解析到那个唯一的 IP 地址就够了；但云环境里实例是可丢弃的，会因为扩缩容、故障替换而频繁创建和销毁，每个实例都有自己的 IP，用”DNS 轮询解析到多个实例 IP 之一”这种传统思路在云上会失灵——DNS 缓存和应用自身对 DNS 结果的缓存都可能比实例存活时间更长，导致解析结果指向一个已经不存在的实例。Kubernetes Service 对象的解法是引入一层间接：Service 本身有一个在其生命周期内固定不变的 IP 和 DNS 名字，调用方只需要认准这个不变的名字，Service 背后到底代理了哪些、多少个 Pod，由 kube-proxy 在流量到达 Service 之后才去做转发决策，这一步不涉及 DNS 解析，从根子上避开了”DNS 缓存指向失效地址”这个问题。发散：这是给”频繁变化的东西”套一层”几乎不变的稳定接口”的经典解法——稳定接口负责被外部依赖，接口背后的具体实现可以随意变化，这个思路和[[仓储抽象隔离领域与持久化]]是同一种模式在不同层面的复用。