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的。

posted @   ~技术小白  阅读(8)  评论(0编辑  收藏  举报
编辑推荐:
· go语言实现终端里的倒计时
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
阅读排行:
· 周边上新:园子的第一款马克杯温暖上架
· 分享 3 个 .NET 开源的文件压缩处理库,助力快速实现文件压缩解压功能!
· Ollama——大语言模型本地部署的极速利器
· DeepSeek如何颠覆传统软件测试?测试工程师会被淘汰吗?
· 使用C#创建一个MCP客户端
点击右上角即可分享
微信分享提示