一文带你深入理解K8s-Pod的意义和原理
本文分享自华为云社区《深入理解K8s-Pod的意义和原理》,作者:breakDawn。
在Kubernetes概念中,有以下五种概念:
- 容器container:镜像管理的最小单位
- 生产任务Pod:容器组,资源调度最小单位
- 节点Node:对应集群中的单台机器,是硬件单元的最小单位
- 集群Cluster:对应整个集 群,是处理元数据的最小单位
- 集群联邦Federation:对应多个集群,是满足跨可用区域多活、跨地域容灾的要求
其中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能共享以下内容:
- UTS名称空间:所有容器都有相同的主机名和域名
- 网络名称空间:所有容器都共享一样的网卡、网络栈、IP地址等。同一个Pod中容器占用的端口不能冲突
- IPC名称空间:可以用信号量或者POSIX共享内存
- 时间名称空间: 共享相同的系统时间
注:但POD中PID名称空间和文件名称空间仍然是隔离的。
POD共享空间的原理
上面提到的POD能供共享名称空间,其能力是通过pause容器实现的。
Pause容器通常是一个非常小的容器镜像。它的主要任务是执行一个永久“暂停”操作,因此它不会消耗很多资源,同时也是每个Pod的第一个启动的容器。
Pause容器作为持续运行的进程,为Pod中的其他容器提供了一个共同的父进程。这使得所有的容器都可以共享同一个网络命名空间(即它们都可以看到相同的网络接口和IP地址等)和IPC命名空间
虽然它大部分时间处于暂停状态,Pause容器在Pod的生命周期中充当了状态传递和协调的角色。比如,在重新启动或移除Pod时,它协助协调和维护状态一致性。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
华为云CCE集群健康中心:一个有专家运维经验的云原生可观测平台
本文分享自华为云社区《新一代云原生可观测平台之华为云CCE集群健康中心》,作者:云容器大未来。 "Kubernetes运维确实复杂,这不仅需要深入理解各种概念、原理和最佳实践,还需要对集群的健康状态、资源利用率、容器的稳定性等多个方面进行风险评估。当集群出现故障时,我们通常需要花费大量时间来分析各种日志和监控信息,以找出问题的根本原因。"一位IT公司运维总监如此说道。 近年来,越来越多的公司转向了基于Kubernetes的云原生架构。随着微服务和云原生架构的变得越来越复杂,我们也收到不少客户反馈在生产中进行监控和故障排除变得越来越困难。虽然CCE云原生可观测平台提供了监控、告警、日志等功能,能够让用户更加方便的定位问题,但是同样也无形中提高了运维人员的技术门槛。为了让运维和开发人员能够从繁重的故障定位排查中解脱出来,CCE服务提供了集群健康诊断能力。 CCE集群健康诊断集合了容器运维专家的经验,为您提供了集群级别的健康诊断最佳实践。可对集群健康状况进行全面检查,帮助您及时发现集群故障与潜在风险,并给出对应的修复建议供您参考。 开箱即用:免开通零依赖,一键健康诊断 集群健康诊断功能作为C...
- 下一篇
只有大厂才可以有 DevOps 平台?
无论公司规模大小,都由一个个业务单元组成,每个业务单元通常包含约 15 名成员左右。面对项目规模达 30-50 个微服务不等的挑战,开发者在处理工具和流程时面临巨大的困扰。工程师不仅需要专注于代码编写,还需要处理大量繁琐的集成测试、配置数据变更、发布验证等事务,平均一个工程师可能涉及到 5-10 个不同的工具和平台。相较于过去的开发模式,运维人员也需要应对更复杂的环境治理、业务和配置变更、数据变更等全场景的工程复杂性,任何一个环节出现问题都可能引发事故并损害业务。 01-团队应对之道 为了解决这一挑战,大型企业通常会专门招聘 DevOps 工程师,投入高达 500-2000 万元的费用用于建设内部平台,服务于业务开发工程师。然而,对于规模较小的企业研发团队来说,由于生存和业务发展为主,很难投入如此庞大的成本。目前,这些团队只能勉力组建工具链,这个过程中产生了大量的切换负担,并伴随着工程师协同过程中的浪费和损耗。 02-Zadig 如何帮助到你 Zadig 并非专为大企业设计,主要面向复杂的现代化应用交付的复杂度治理,为广义的企业开发者提供简单易用的协同平台。无需从零开始,站在 Za...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- CentOS8编译安装MySQL8.0.19
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS7,8上快速安装Gitea,搭建Git服务器
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- Red5直播服务器,属于Java语言的直播服务器
- CentOS6,7,8上安装Nginx,支持https2.0的开启