41. Kubernetes深入Service-Service资源介绍

释放双眼,带上耳机,听听看~!

运行于Pod中的部分容器应用是向客户提供服务的守护进程,例如Nginx、Tomcat和etcd等,控制器所管控着这些Pod中的容器,它们存在生命周期,这类Pod在自愿或者非自愿中断后只能被重构和新的Pod对象所取代,属于不可再生类的组件,它们每次被重构或者被新的Pod对象取代,就意味着它们的IP地址发生变化,所以直接通过Pod IP无法为客户端提供一个稳定的访问入口,于是有了Service的出现,Service为这类Pod提供一个固定、统一的访问入口及负载均衡的能力,并借助于CoreDNS系统的服务发现功能,解决客户端发现并访问容器应用的难题。

Service资源介绍

Service是Kubernetes的核心资源类型之一,事实上它是一种抽象;通过规则定义出由多个Pod对象组合而成的逻辑集合,以及访问这组Pod的策略。Service关联Pod资源的规则要借助于标签选择器来完成。

Service资源概述

在我们的传统模式中,一般把Nginx或者HAProxy等应用去代理后端的应用服务器,我们只需要在代理配置文件中写入后端应用的IP地址以及Port即可,因为后端应用服务器的IP地址和端口通常不会发生变化。
但我们由Kubernetes所编排的Pod IP可是会经常发生变化,如Pod对象中断后控制器会为其新建资源对象所取代,Pod被取代之后Pod IP就会发生变化;Pod扩缩容后也会发生变动,那么Kubernetes则是通过Service资源来解决此类问题。

Service资源基于标签选择器将一组Pod定义成一个逻辑组合,并通过自己的IP地址和端口转发请求到组内的Pod对象之上,这一切对客户端来说都是透明的。

Service对象的IP地址被称为Cluster IP,是Kubernetes集群配置所指定的专用IP地址范围之内,而且是一种虚拟IP地址,它在Service对象创建后则保持不变,还能够被同一个集群中的Pod资源访问,Service端口用于接收客户端请求并将请求转发至后端Pod相应端口之上,因此,这种代理机制也被称为“端口代理” (port proxy)或者四层代理,Service资源工作于TCP/IP协议栈的传输层。

当Service代理的一组逻辑组合Pod对象有多个时,Service资源能够以负载均衡的方式进行流量调度。Service资源会通过API Server持续watch着标签选择器匹配到的后端Pod对象,并且实时跟中Pod对象的变动,例如,IP地址变动,Pod对象增加或者减少等。

Service并不直接连接到Pod对象,它们之间还有一个中间层Endpoints资源对象,它是一个由IP地址和端口组成的列表,这些IP地址和端口则来自于由Service的标签选择器匹配到的Pod资源。这也是很多场景中会使用"Service的后端端点"(Endpoints)这一术语的原因。默认情况下,创建Service资源对象时,其关联的Endpoints对象会自动创建。

Ops工具

40. Kubernetes深入Pod控制器-CronJob控制器

2020-6-16 11:50:40

Ops工具

42. Kubernetes深入Service-Service代理模式

2020-6-22 10:25:44

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索