6.2.2 Service和Endpoint对象
Service和Pod的匹配关系是通过Label筛选器和名为Endpoint对象的结构共同完成的。
每一个Service在被创建的时候,都会得到一个关联的Endpoint对象。整个Endpoint对象其实就是一个动态的列表,其中包含集群中所有的匹配Service Label筛选器的健康Pod。
Kubernetes会不断地检查Service的Label筛选器和当前集群中健康Pod的列表。如果有新的能够匹配Label筛选器的Pod出现,它就会被加入Endpoint对象,而消失的Pod则会被剔除。也就是说,Endpoint对象始终是保持更新的。这时,当Service需要将流量转发到Pod的时候,就会到Endpoint对象中最新的Pod的列表中进行查找。
当要通过Service转发流量到Pod时,通常会先在集群的内部DNS中查询Service的IP地址。流量被发送到该IP地址后,会被Service转发到其中一个Pod。不过,Kubernetes原生应用(知悉Kubernetes集群并且能够访问Kubernetes API的应用)是可以直接查询Endpoint API,而无须查找DNS和使用Service IP的。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· go语言实现终端里的倒计时
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· 周边上新:园子的第一款马克杯温暖上架
· 分享 3 个 .NET 开源的文件压缩处理库,助力快速实现文件压缩解压功能!
· Ollama——大语言模型本地部署的极速利器
· DeepSeek如何颠覆传统软件测试?测试工程师会被淘汰吗?
· 使用C#创建一个MCP客户端