通俗理解 Kubernetes 中的服务,搞懂后真“有趣”

马哥Linux运维

共 2191字,需浏览 5分钟

 · 2021-11-24

1. 复习 pod 相关核心结构

1.1 pod 结构

  • pod 相当于一个容器,pod 有独立的 ip 地址,也有自己的 hostname,利用 namespace 进行资源隔离,相当于一个独立沙箱环境。
  • pod 内部封装的是容器,可以封装一个,或者多个容器(通常是一组相关的容器)

1.2 pod 网络

  • pod 有自己独立的 IP 地址

  • pod 内部的容器之间是通过 localhost 进行访问

2. pod 如何对外提供访问

首先 pod 有自己的 IP 和 hostname,但 pod 是虚拟的资源对象 (在计算机中表现为进程),没有对应实体 (物理机,物理网卡) 与之对应,所以是无法直接对外提供服务访问的。
因此如果 pod 想对外提供服务,必须绑定物理机端口 (即在物理机上开启端口,让这个端口和 pod 的端口进行映射),这样就可以通过物理机进行数据包的转发。
下面以一台 Linux 系统的机器为例子( logstash 是做日志收集用的)

3. pod 的负载均衡

很关键的一个问题:一组相关的 pod 副本,如何实现访问负载均衡?就如当请求达到,请求转发给哪个 pod 比较好?
一个想法就是用 pod 再部署一个 Nginx。
举例:如下图,注意下图右边的 Node 里面有两个是 支付 服务,与订单服务的是不同类型的 pod。如果一个请求订单的服务发来上面那个 Nginx,那这个 pod 可以有 4 条转发路线,可以想到用 hash 呀什么的把不同请求映射到不同的 pod 去转发。但能不能这么做呢?

思考:pod 是一个进程,是有生命周期的,一旦宕机、版本更新都会创建新的 pod( IP 地址会变化,hostname 会变化),此时再使用 Nginx 做负载均衡不太合适,因为它不知道 pod 发生了改变,那请求就不能被接受了。所以服务发生了变化它根本不知道,Nginx 无法发现服务,不能用 Nginx 做负载均衡。那该如何实现呢?使用 Service 资源对象。

3.1 什么是 Service 资源对象

  • POD IP:pod 的 IP 地址
  • NODE IP:物理机的 IP 地址
  • cluster IP:虚拟 IP,是由 kubernetes 抽象出的 service 对象,这个 service 对象就是一个 VIP (virtual IP, VIP) 的资源对象

3.2 service 如何实现负载均衡

例如现在要负载均衡地访问一组相同的服务副本——订单,这时就要去做一个 service,对外表现出是一个进程或资源对象,有虚拟的 IP (VIP) 和端口。请求会访问 service,然后 service 自己会 负载均衡 地发送给相应服务的 POD,也就是下图中 4 个相同的 pod。

3.3 深入 service VIP

  • service 和 pod 都是一个进程,都是虚拟的,因此实际上 service 也不能对外网提供服务
  • service 和 pod 之间可以直接进行通信,它们的通信属于局域网通信
  • 负载策略:把请求交给 service 后,service 使用 iptables,ipvs 来实现数据包的分发
而要对外网提供服务,首先需要和之前一样 在物理机上也绑定一个端口 来接受访问请求,然后把请求转发给 service,service 再把数据包分发给相应的 POD。访问流程如下图所示:

思考1:那 service 对象是如何和 pod 进行关联的呢?
它们之间的关联利用的 还是标签选择器 selector。且service 只能对 一组相同的副本 提供服务,不能跨组提供服务。如果有另一组,需要再创建一个 service。因此不同的业务会有不同的 service。
举例:service 和 一组 pod 副本是通过标签选择器进行关联的,相同的副本的标签是一样的。
selector:app = x 选择一组订单的服务的 pod,创建一个 service;app = y 选择了一组支付的服务的 pod。通过一个 endpoints 属性存储这组 pod 的 IP 地址,这样就有了映射关系了 (关联起来)。

思考2:pod 宕机或发布新版本了,service 是如何发现 pod 已经发生变化的?
通过 k8s 中的一个组件 —— kube-proxy (第 1 篇有提到过),每个 NODE 里都运行着这个服务。它需要做的工作如下图右侧:

service 实现服务的发现:kube-proxy 监控 pod,一旦发现 pod 服务变化,将会把新的 ip 地址更新到 service。
注意:endpoints 那些都是存储在 etcd 里的 (也是第 1 篇提到过的),所以 kube-proxy 更新的存储在 etcd 里的映射关系。
来源:https://blog.csdn.net/qq_43280818/article/details/107164860
文章转载:高效运维
(版权归原作者所有,侵删)


点击下方“阅读原文”查看更多

浏览 9
点赞
评论
收藏
分享

手机扫一扫分享

举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

举报