运维随笔-k8s-pod介绍

pod概念

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

为啥要这么设计呢，让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： 一次性工作