Kubernetes同一Service下的Pod如何实现无额外配置的互相通信？

无第三方Kubernetes客户端的轻量实现方案 #

完全不依赖Kubernetes客户端库的方案可以基于Kubernetes原生提供的能力实现，所有能力都是集群默认自带的，无需用户额外配置集群参数：

• Pod身份与集群信息获取：Kubernetes会默认给每个Pod挂载ServiceAccount凭证到/var/run/secrets/kubernetes.io/serviceaccount/目录，直接读取该目录下的namespace文件即可获取当前Pod所在命名空间，读取token文件获取API访问凭证，ca.crt文件用于APIServer的TLS认证；同时通过系统默认注入的HOSTNAME环境变量即可获取当前Pod的名称。
• 同Service Pod列表查询：直接调用Kubernetes APIServer的原生REST接口即可，默认服务地址为https://kubernetes.default.svc，接口路径为/api/v1/namespaces/{当前命名空间}/pods?labelSelector={Service对应的标签选择器}，你可以在库中约定Service的标签规则，或者提供简单的配置项让用户传入自己Service的标签键值对即可过滤出同属一个Service的所有Pod实例。
• Pod生命周期感知：在上述查询接口的参数中增加watch=true即可建立长连接监听Pod的增、删、改事件，你只需要自行解析返回的JSON流数据，即可实时维护本地存活Pod列表，不需要依赖第三方封装的监听器能力。
• Pod间事件通信：每个Pod启动时内置一个轻量化的HTTP/WebSocket服务端，端口可通过配置项自定义，发现新Pod实例时主动和对方建立连接，当本Pod触发事件时，直接遍历本地存活Pod列表，将事件异步广播给所有其他实例即可，全程不需要依赖外部存储。

注意：使用该方案仅需要用户为Pod绑定的ServiceAccount配置最小RBAC权限，允许对pods资源执行get、list、watch操作，你可以在库的配套文档中提供现成的RBAC配置文件，用户仅需首次部署时执行kubectl apply即可，无额外操作成本。

最优实现路径 #

优先选择：基于官方Kubernetes Java客户端实现 #

如果你的开源库对依赖数量没有极致要求，该方案是综合开发成本、稳定性、接入门槛最优的选择：

• 官方客户端已经封装了APIServer认证、请求重试、watch长连接重连、异常处理等底层逻辑，不需要你自行实现容错能力，开发量可降低60%以上
• 内置了所有Kubernetes资源的POJO模型，不需要自行解析JSON格式的Pod数据，出错概率大幅降低
• 接入门槛极低，客户端会自动读取默认挂载的ServiceAccount凭证，用户引入依赖后不需要做任何额外的Kubernetes相关配置
• 封装好的监听器接口直接提供Pod增删改事件的回调，你只需要聚焦业务逻辑开发即可，不需要处理底层流数据解析

次选方案：自研原生APIServer对接（无第三方依赖） #

如果你的开源库需要尽可能减少第三方依赖，就选择上述无第三方客户端的方案，按以下步骤实现即可：

1. 读取ServiceAccount目录下的凭证文件，获取APIServer访问所需的认证信息和当前命名空间
2. 封装HTTP请求，调用Pod列表查询接口，根据Service标签过滤出同组Pod的IP与端口信息
3. 调用watch接口建立长连接，监听Pod变更事件，实时更新本地存活Pod列表
4. 内置HTTP/WebSocket服务端，提供事件接收接口，收到事件后直接更新本地状态
5. 本Pod触发事件时，遍历本地存活Pod列表异步广播事件，可增加重试、超时逻辑避免单个实例异常影响整体流程

可选优化：如果不需要强一致性，可以引入Gossip协议做事件扩散，不需要全量广播，每个Pod收到事件后仅转发给少量相邻节点，即可实现最终一致性，大幅降低网络开销。

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