本文分享自华为云社区《深入理解K8s-Pod的意义和原理》,作者:breakDawn。
在Kubernetes概念中,有以下五种概念:
其中Pod的概念是随Kubernetes一起推出的。
Kubernetes项目是基于Borg系统的经验和设计理念创建的,其中Pod的概念就是一个关键部分。因此,可以说Pod是从2014年6月Kubernetes项目发布之初就存在的。当我们要理解Pod时,就需要先理解为什么需要Pod这个概念。
假设你有一个高流量的Web应用服务器,需要详细记录访问和错误日志。同时,你希望实时处理这些日志,例如进行分析、监控或立即警报异常情况。你会将应用服务器和日志代理服务作为两个进程, 但此时你需要思考,我能否将这2个进程放在一个容器中,例如写成下面这样的dockerfile:
FROM python:3.8 # 安装依赖 RUN pip install xxxxx # 复制文件 COPY web_service.py /web_service.py COPY log_processor.py /log_processor.py # 启动脚本,同时运行web服务和日志处理(不推荐) CMD python /web_service.py & python /log_processor.py
这是项目初期常见的方式,可能为了快速开发日志特性,直接就在一个dockefile里搞了。
但这是不推荐的实践。
首先,dockerfile只允许一个entrypoint。
这个“entrypoint”是一个指定的命令或脚本,这个命令或脚本在容器启动时运行,并且成为容器中的第一个进程(即PID为1的进程)。在Docker的设计中,每个容器通常运行一个主要的应用或服务,而这个应用或服务就是通过entrypoint启动的。
同时,容器中,PID为1的进程是当你运行一个容器时由Dockerfile中的ENTRYPOINT或CMD指令指定的进程。这个进程在容器的生命周期内扮演类似于init进程的角色。如果PID为1的进程终止,Docker知道容器已经完成了它的工作或因为某种原因失败了,然后Docker可以决定是重启容器还是简单地记录其退出状态。
基于以上两点,容器只能默认监控主进程(PID为1)的状态来决定是否需要重启容器。
此时如果第二个日志进程出问题了,在你未进行特制的健康处理时,是无法感知该状态,也无法让调度系统重新拉起这个容器。
因此为了容器监测的有效性,优选策略是始终保持单容器单应用的特点,一个应用做成一个容器。
上面那个例子的另一个问题在于,如果跨界点分配这2个容器, 会有什么后果?
一个是会产生网络延迟和带宽,因为两个节点之间的通信会经过网络,这会增加延迟。对于日志收集这样频繁的操作,即使是微小的延迟也会累积成显著的性能损失。
其次是数据一致性。网络问题可能导致日志数据在传输过程中丢失,特别是在没有适当可靠性保证的系统中。或者因为节点时间同步问题,导致日志记录与实际事件之间出现时间上的不一致。
所以我们必须要求这2个容器一定分配要在同一个节点
因此,POD的概念就出现了。他用于封装2个容器,并始终保证调度到同一个节点上。
除了数据文件的读取和写入,同POD内的2个容器也支持基于操作系统的信号通信(不经过网络),则需要这2个容器依赖相同的IPC名称空间。
总之pod能共享以下内容:
注:但POD中PID名称空间和文件名称空间仍然是隔离的。
上面提到的POD能供共享名称空间,其能力是通过pause容器实现的。
Pause容器通常是一个非常小的容器镜像。它的主要任务是执行一个永久“暂停”操作,因此它不会消耗很多资源,同时也是每个Pod的第一个启动的容器。
Pause容器作为持续运行的进程,为Pod中的其他容器提供了一个共同的父进程。这使得所有的容器都可以共享同一个网络命名空间(即它们都可以看到相同的网络接口和IP地址等)和IPC命名空间
虽然它大部分时间处于暂停状态,Pause容器在Pod的生命周期中充当了状态传递和协调的角色。比如,在重新启动或移除Pod时,它协助协调和维护状态一致性。
点击关注,第一时间了解华为云新鲜技术~