pod概念

pod是k8s集群管理的最小业务承载单位。我们所有的业务都是运行在pod里的,一个k8s集群可能有成千上万个pod。 pod中文翻译是豌豆荚,如下图所示。豆荚里面的豆子代表一个个的container(容器),pod是一个逻辑上的组织概念。豆荚的作用是把这些豆子全部包裹在了一起,而pod则是把一组容器捆绑在了一起。这组容器便拥有相同的生命周期和生存环境,同生共死。

image.png
为啥要这么设计呢,让k8s直接管理具体的容器不行吗,何必要再创造出pod这样一个中间层对象?

1.提升管理效率
在实际生产中,有很多模块或组件的耦合度非常高,需要同时部署。例如我们要部署一个wordpress博客网站,这个是php语言写的,部署架构是LNMP。即一个nginx容器同时要搭配一个php容器和一个mysql容器,这三个容器配合非常紧密,除此之外不需要和其他任何容器通信。假设K8S只能管理容器,那就要分别部署三次。有了pod这个概念,我们可以在pod的描述文件中同时添加三个容器的信息,然后部署一个pod即可。pod在使用时可以理解为一个容器集合

2.提升容器性能
前文说过,pod包含的所有容器拥有共同的生存环境,这个环境包含网络环境(同一个网络栈),数据卷挂载环境,物理机环境。简单的说就是pod中的各个容器可以通过localhost这个环回地址通信,以上面的博客网站为例,当nginx容器要访问php容器时,直接使用localhost:9000即可。这种通信效率是极高的。如果k8s直接管理容器,那么nginx和php容器很有可能会部署到不同的物理主机上,两者通信时不仅需要本机网桥转发,还需要物理机网络路由转发,效率自然会很差。

3.功能拓展需求
当我们需要增加一些额外功能时,例如我们希望监控nginx访问日志并清洗转化数据,同时将异常信息发送到监控中心。如果要让nginx容器实现该功能,我们可能需要修改nginx。但有了pod这个概念后,我们可以直接在pod描述文件中新增一个日志容器,而不需要修改其他任何容器。 日志容器和nginx容器共享挂载卷,所以可以读取到nginx容器的日志。这种方式的好处是通过在pod内部新增容器来拓展功能,不改变原有容器,它被称为sidecar(边车模式)

pod分类

1.自主pod
不受控制器管理的pod,缺乏自愈机制

2.控制器管理的pod
由一些控制器管理的pod,这些控制器会始终监控pod,并让pod保持在我们所期望的运行状态。例如pod意外挂了,控制器会自动重启这个pod

控制器种类:
deployment:
无状态服务,确保pod的运行数量始终保持在用户期望的数量

HPA:
自动扩缩容控制器,根据pod的cpu,内存等使用情况自动伸缩pod数量动态适应负载

statefulSet:有状态服务

daemonset: 守护控制器,确保每个节点有且只有一个pod

job: 一次性工作


千里之行
1 声望2 粉丝

SRE体系践行者