如何让Headless Service适配蓝绿或A/B部署并实现应用感知

蓝绿/AB部署时Headless Service的运行保障方案 #

• 标签与选择器的严格隔离：蓝、绿两个版本的 workload 必须设置独立的版本标签（比如app.kubernetes.io/version: blue/green），Headless Service的selector默认绑定当前对外提供服务的版本标签，切换时仅修改selector的版本取值即可，避免切换过程中两个版本的实例同时被Service选中导致流量混杂，千万不要用公共标签同时匹配两个版本的 workload，避免切换前就出现流量漏到新版本的问题。
• 提前完成新版本实例的就绪探测校验：切换前确保新版本所有Pod的readinessProbe返回成功，Headless Service的DNS记录默认不会纳入未就绪的Pod，可避免切换初期出现流量路由到不可用实例的问题。如果你的集群开启了publishNotReadyAddresses配置，请在切换前临时关闭，确认切换完成后再按需恢复。
• 保留历史版本的Service备份：切换前为当前运行的老版本创建一个临时的独立Headless Service，万一切换后出现异常，可直接将流量切回老版本对应的Service，不需要重新修改原有Service的selector，大幅降低回滚耗时。
• 避免切换过程中修改Service的其他配置：切换时仅调整selector的版本字段，不要同时修改端口配置、会话保持等其他参数，减少配置变更的冲突概率。

Service ID跨实例迁移时的应用感知方案 #

• 优先启用DNS客户端的短TTL配置：Headless Service默认的DNS TTL通常是30s，你可以修改CoreDNS的配置，将对应Headless Service的TTL调整到3~5s，降低应用缓存旧实例IP的时间。同时要检查应用本身的DNS缓存配置，比如禁用Java应用默认的永久DNS缓存，或者把应用侧的DNS缓存有效期和Service侧的TTL对齐。
• 采用订阅机制主动感知实例变化：如果你的应用对延迟敏感度较高，可以通过Kubernetes的API Server主动监听对应Headless Service关联的Endpoint/EndpointSlice资源变化，一旦监听到Endpoint的增减事件，立即更新应用内部的实例地址列表，不需要等待DNS缓存过期。
• 引入服务注册发现组件做二次校验：对于带状态的服务（比如分布式缓存、消息队列节点），可以在应用侧调用实例前，先向Consul、Etcd等注册中心查询当前有效service id对应的实例地址，避免请求到已经下线的旧实例。
• 配置合理的重试与连接超时：在应用的RPC/HTTP调用逻辑中加入对旧实例连接失败的重试逻辑，重试时强制重新解析DNS获取最新的实例地址，单次请求的连接超时不要超过1s，避免长时间挂在旧实例的无效连接上。

内容的提问来源于stack exchange，提问作者himanshu_mps