Kubernetes 笔记 06 豌豆荚之旅(一)

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

本文首发于我的公众号 CloudDeveloper(ID: cloud_dev),专注于干货分享,号内有大量书籍和视频资源,后台回复「1024」即可领取,欢迎大家关注,二维码文末可以扫。

Hi,大家好,我是 CloudDeveloper,欢迎大家和我一起学习 K8S,这是系列第 6 篇。

Pod 中文译为豌豆荚,很形象,豌豆荚里面包裹的多颗小豌豆就是容器,小豌豆和亲密无间的老伙计壳荚子自出生之日起就得面对各种各样的人生大事:

  • 容器、Pod、Node 之间的关系
  • Pod 的生命周期管理
  • Pod 的调度管理
  • Pod 的监控
  • Pod 的升级与回滚
  • Pod 的扩容与缩容
  • Pod 的存储管理
  • Pod 的网络管理
  • ......

为什么需要 Pod?

我们假设没有 Pod,应用部署的最小单元就是容器,会有什么问题?首先,应用调度粒度太细,不便于管理。想象一下淘宝网站运行着海量应用,每个应用又拆分成多个服务,每个服务部署在一个容器里,一个集群管理系统要管理庞大的容器集群,既要顾忌不同应用之间的隔离性,又要考虑相同应用之间的关联性,这在管理上将会是灾难性的难题。

其次,资源利用率低。有很多应用之间存在某种强关联关系,它们需要彼此能共享对方的资源,双方的交互需要快捷有效,如果把它们部署到单独的容器中,资源利用和通信将成为最主要的系统瓶颈。

Pod 的提出改变了这种局面,它将强关联的应用整合在一起,作为一个整体对外提供服务,既简化了管理的难度,又提高了资源的利用率。

那哪些应用是强关联,适合放到一个 Pod 中呢?举个例子,比如下面这个 Pod 包含两个容器,一个 File Puller,一个是 Web Server。

File Puller 会定期从外部的 Content Manager 中拉取最新的文件,将其存放在 Volume 中。然后 Web Server 从 Volume 中读取文件,来响应 Consumer 的请求。

这两个容器通过 Volume 来共享实时的数据,协作处理一个 Consumer 的请求,把它们放到同一个 Pod 中就是合适的。

如果有应用和任何应用之间都不存在联系,那么它们就单独部署在一个 Pod 中,称为one-container-per-pod。即便只有一个容器,K8S 管理的也是 Pod 而不是直接管理容器。

综上,Pod 在设计的时候,主要动机有以下两点:

  1. 方便管理

Pod 提供了比容器更高一层的抽象,K8S以 Pod 为最小单元进行应用的部署、调度、扩展、共享资源和管理周期。

  1. 资源共享和通信

Pod 内的所有容器共享同一个网络空间,它们之间可以通过 localhost 相互通信。同样,所有容器共享 Volume,一个容器挂载一个 Volume,其余容器都可以访问这个 Volume。

容器、Pod、Node 之间的关系

容器是 Pod 的一个属性,定义了应用的类型及共享的资源。每个容器会分配一个 Port,Pod 内的容器通过 localhost:Port 的形式来通信。

一个 Pod 包含一个或多个容器,每个 Pod 会分配一个唯一的 IP 地址,Pod 内的多个容器共享这个 IP 地址,每个容器的 Port 加上 Pod IP 共同组成一个 Endpoint,共同对外提供服务。

在部署应用的时候,Pod 会被 Master 作为一个整体调度到一个 Node 上。如果开启多副本管理,则多个 Pod 会根据调度策略调度到不同的 Node 上。如果 Node 宕机,则该 Node 上的所有 Pod 会被自动调度到其他 Node 上。

下面是容器、Pod、Node 三者之间的关系图:

Pod 根容器

Pod 中有一个特殊的容器,叫 Pod 的根容器——Pause 容器,这是一个很小的容器,镜像大小大概为 200KB。

Pause 容器存在的意义是: 维护 Pod 的状态信息

由于 Pod 是作为一个整体进行调度,我们难以对这个整体的信息进行简单的判断和有效地进行行动。

想象一下,假如 Pod 内一个容器死亡了,是算整体死亡呢还是 N/M 死亡率,如果 Pod 内所有容器都死亡了,那是不是该 Pod 也就死亡了,如果加入新的容器或原有容器故障恢复呢,如何让新成员快速融入环境?

理论上,虽然 Pod 是由一组容器组成的,但 Pod 和容器是彼此独立的,也就是容器的故障不应该影响 Pod 的存在,Pod 有相应的手段来保证容器的健康状况。

引入与业务无关的,并且不易死亡的 Pause 容器就可以很好的解决这个问题,Pause 容器的状态就代表了 Pod 的状态,只要 Pause 不死,那么不管应用容器发生什么变化,Pod 的状态信息都不会改变。

这样,Pod 内的多个应用容器共享 Pause 容器的 IP 和 Volume,当加入新的容器或者原有的容器因故障重启后就可以根据 Pause 保存的状态快速学习到当前 Pod 的状态。

总结

本文简单学习了 Pod 的初级知识,包括 Pod 的设计动机,容器、Pod 和 Node 之间的关系,以及 Pod 的守护者——Pause 容器。

容器的 Port + Pod IP = Endpoint,构成一个 Pod 的通信实体,Pod 中的容器共享网络和存储,这些共享信息是由 Pause 容器来维护的。

下文继续豌豆荚之旅的第二个部分,学习 Pod 的管理哲学。

为了给大家更多的福利,这个系列的每一篇文章我都会送一些电子书,可能有重的,也有一些新书,之前送了《K8S 指南》和《容器与容器云》,这次送一本由 K8S 中文社区主编的《K8S 中文手册》,大家有需要的后台回复“K8S2”

10T 技术资源大放送!包括但不限于:云计算、虚拟化、微服务、大数据、网络、Docker容器、Kubernetes、Linux、Python、Go、C/C++、Shell、等等。在公众号内回复 「1024」,即可免费获取!!

人已赞赏
随笔日记

我眼中的 Nginx(三):Nginx 变量和变量插值

2020-11-9 3:52:36

随笔日记

CLR Via读书笔记第一章(2)程序集和CLR的启动

2020-11-9 3:52:38

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