1.cri��ȡ����Դ��
2.再见Docker，拉令Podman、取镜取镜Skopeo和Buildah下一代容器新架构强势出击！像源像命
3.图解kubernetes Pod创建流程大揭秘
4.kubeadm搭建Kubernetes集群问题汇总
5.官方镜像加速
6.K8s：一文认知 CRI，码拉OCI，拉令容器运行时，取镜取镜共享干衣机源码Pod 之间的像源像命关系
cri��ȡ����Դ��
容器生态系统的复杂性往往源自众多工具和标准的并存，以及大型公司之间的码拉合作与竞争。本文旨在澄清与容器化技术相关的拉令几个关键术语，包括 Docker、取镜取镜containerd、像源像命CRI、码拉CRI-O、拉令OCI 和 runc。取镜取镜通过理解这些术语以及它们在容器生态系统中的像源像命角色，可以更清晰地看到容器化技术如何在不同的平台和操作系统之间实现互操作性，同时减少对单一公司或项目的依赖。 容器生态系统是一个充满活力的领域，包括多种令人兴奋的技术、专业术语和来自不同大型公司的激烈竞争。尽管如此，有时这些公司会在短暂的休战中合作，共同制定标准，以促进不同平台和操作系统之间的互操作性，并减少对特定公司或项目的依赖。下图展示了 Docker、Kubernetes、CRI、OCI、containerd 和 runc 在容器生态系统中的协作方式。 容器生态系统中的工作流程大致如下： 以下是图中提及术语和规范的介绍。 Docker 作为容器化技术的先驱，Docker 成为了管理容器的最流行工具。它不仅改变了容器的面貌，也经常被误认为是容器的代名词。实际上，Docker 是容器工具中的一个，还有其他知名工具如 Podman、LXC、containerd 和 Buildah 等。 尽管许多人认为容器仅与 Docker 相关，这种观点是片面的。Docker 的功能由 Docker 守护程序、containerd 和 runc 实现，它们在 Docker 的容器生命周期中发挥着关键作用。 Docker 组成 Docker 通过轻松构建容器镜像、从 Docker Hub 拉取镜像、创建、启动和管理容器等功能，简化了容器化流程。实际上，当你使用 Docker 运行容器时，背后是 Docker 守护程序、containerd 和 runc 的协作。 Docker 由多个项目组成，包括但不限于这些关键组件。 Docker 镜像 人们常提及的 Docker 镜像是以 Open Container Initiative（OCI）格式打包的镜像。因此，93gs源码从 Docker Hub 或其他注册中心拉取的镜像可以在使用 docker 命令时，或在 Kubernetes 集群上运行，甚至可以用 podman 等工具，只要这些工具支持 OCI 镜像格式规范。 Dockershim 在 Kubernetes 中，存在名为 dockershim 的组件，以支持 Docker。由于 Docker 比 Kubernetes 更早出现，并且没有实现 CRI，因此 dockershim 的存在是为了支持将 Docker 硬编码到 Kubernetes 中。随着容器化成为行业标准，Kubernetes 项目增加了对额外运行时的支持，比如通过 Container Runtime Interface (CRI) 来支持运行容器。这导致代码脆弱性，因为 Kubernetes 依赖于 Docker 和 dockershim。预计到 年 4 月，Kubernetes 将从 1. 版本开始完全移除 dockershim，并倾向于使用实现 CRI 规范的容器运行时，如 containerd 或 CRI-O。 Container Runtime Interface (CRI) CRI（容器运行时接口）是 Kubernetes 用来控制创建和管理容器的不同运行时的 API。它使 Kubernetes 能够轻松使用不同的容器运行时，同时也简化了添加对每个运行时的支持的过程。任何符合 CRI 标准的实现都可被 Kubernetes 使用，因为 Kubernetes 通过 CRI 描述了如何与每个运行时交互，而运行时负责具体管理容器的实现。 你可以使用 containerd 或 CRI-O 等容器运行时运行容器，因为它们都实现了 CRI 规范。 containerd containerd 是由 Docker 开发的高级容器运行时，它实现了 CRI 规范。containerd 从 Docker 项目中独立出来，并捐赠给了云原生计算基金会（CNCF），以支持容器社区开发新的容器解决方案。Docker 内部使用 containerd，因此安装 Docker 时也会安装 containerd。containerd 通过 CRI 插件实现 Kubernetes 容器运行时接口（CRI），管理容器的整个生命周期，包括镜像传输、存储、容器执行、监控和网络管理。 CRI-O CRI-O 是另一个实现了容器运行时接口（CRI）的高级别容器运行时，专门针对 Kubernetes 设计，用于启动、停止和重启容器，类似于 containerd。CRI-O 由多家公司如 RedHat、IBM、英特尔、SUSE、Hyper 等共同开发。 Open Container Initiative (OCI) Open Container Initiative（OCI）是一个由科技公司组成的团体，旨在围绕容器镜像和运行时创建开放标准。OCI 维护容器镜像格式的规范，并定义容器应该如何运行。 OCI 标准化思想是允许选择符合规范的不同运行时，这些运行时具有不同的底层实现。例如，贷超免费源码Linux 主机上可以使用符合 OCI 的运行时，Windows 主机上则使用不同的实现。 runc runc 是用于在 Linux 上运行容器的轻量级通用运行时。它遵循 OCI 规范，作为实现 OCI 接口的最低级别组件，与内核交互以创建和运行容器。 runc 提供了容器所需的全部低级功能，与现有的低级 Linux 功能（如命名空间和控制组）交互，通过这些功能创建和运行容器进程。 总结 本文澄清了 Docker、containerd、CRI-O 和 runc 之间的区别，并强调了容器生态系统中开放标准的重要性。这些标准和不同实现的互换性使得容器化技术能够在各种平台和操作系统之间实现互操作性，同时减少对特定公司或项目的依赖。再见Docker，Podman、Skopeo和Buildah下一代容器新架构强势出击！
在探讨新一代容器工具之前，我们先回顾一下Docker在实践中的局限性。Docker守护进程在占用多核CPU时达到%使用率，导致所有容器无法正常工作，服务停止运行。在遇到VPS机器重启时，这个问题尤为突出，因为Docker守护进程的高负载阻止了容器的启动，进而导致网站无法访问。为了解决这一问题，业界提出了一套新标准，即容器运行接口（CRI）等规范，由谷歌、Redhat、微软、IBM、Intel、思科等巨头联合推动成立的开放容器倡议（OCI）组织负责制定。Docker虽在初期不情愿，但最终也适应了这一新架构。
基于这些标准，新一代容器工具Podman、Skopeo和Buildah应运而生。这些工具符合OCI计划的要求，由RedHat等机构推动，旨在改进Docker的运行方式并提供更安全、高效的功能。它们使用用户命名空间模拟容器中的root权限，无需守护进程或root访问，基于fork/exec模型创建容器，确保安全性和稳定性。
Podman作为核心工具，用于替代Docker中的大部分命令，如RUN、PUSH和PULL，提供类似Docker的界面，但无需守护进程且支持更安全的操作。Buildah作为构建工具，用于创建OCI镜像，dmi指标源码参数提供更快的构建速度和更高效的存储解决方案。Skopeo则专注于镜像管理，支持镜像的推送、拉取和复制，兼容Docker和OCI镜像格式。
与Docker相比，Podman和Buildah采用更简洁的fork-exec模型，运行更快且无需root权限。Buildah主要用于构建容器，而Podman用于容器的管理和运行，Skopeo则专注于镜像的传输。这些工具在GitHub容器组织中开源维护，提供了无守护进程、无root访问权限的解决方案，为用户提供了更灵活、安全的容器管理方式。
在进行容器迁移时，安装Podman、Skopeo和Buildah后，可以通过替换脚本中的docker命令、停止和删除原有docker实例、使用sysdig检查系统引用docker情况、删除docker组等步骤实现迁移。这不仅简化了迁移过程，还提高了系统的安全性和效率。
综上所述，新一代容器工具Podman、Skopeo和Buildah通过遵循CRI等标准、改进了Docker架构，提供了更安全、高效且易于管理的容器解决方案。从实践角度来看，这些工具的引入不仅能够解决Docker在高负载和安全方面的局限，还为用户提供了更便捷的迁移路径，促进了容器技术的持续发展。
图解kubernetes Pod创建流程大揭秘
探索Kubernetes Pod创建的深入剖析 在Kubernetes的世界里，创建容器并非易事，它涉及众多组件的协同工作和外部CRI运行时的交互。本文旨在揭示这一过程中的微妙细节，以帮助我们更好地理解组件间的协作逻辑，为后续问题排查提供线索。基础构建
Kubelet的职责
Kubelet运行在一个master-wroker模型中，通过单个master监听事件源，为每个Pod创建goroutine处理业务逻辑。master与worker通过状态管道保持通信。状态一致性
创建Pod后，Kubernetes通过事件和Pod状态调整，直至达到最终一致状态。Kubelet创建流程
准入检查
新Pod加入PodManager管理，检查资源容忍度和预选条件，包括资源抢占和QoS等级。事件管道与管理
创建事件管道，启动主线程处理事件，等待同步最新状态。状态同步与控制
融合状态信息，进行准入控制检查，更新容器状态，ins网页版源码并同步给apiserver。Cgroup配置与环境准备
配置Cgroup，创建Pod所需目录，获取镜像秘钥，等待volume挂载。ContainerRuntime的角色
计算变更与处理
对比目标状态，管理容器创建、kill和启动，分为初始化和业务阶段。镜像拉取与容器配置
确保镜像拉取正确，创建包含所有必要配置的容器实例。Sandbox容器与网络设置
Sandbox的管理
拉取并创建Sandbox容器，设置SecurityContext和基础配置。启动与网络
启动Sandbox，配置网络，最终调用CNI插件。 Kubelet作为核心管理，负责资源调度和状态反馈，Runtime重组资源并执行操作，而CRI则执行具体的容器创建。这只是基础版本，后续将更深入地探讨各个环节。kubeadm搭建Kubernetes集群问题汇总
在运行kubeadm init过程中，可能遇到多种问题。本篇内容汇总了解决这些问题的方法。以下是详细的步骤和解决步骤。
问题一：在执行kubeadm config images pull时，报错“pulling image: rpc error: cng dial unix /var/run/containerd/containerd.sock: connect: permission denied”。原因可能是kubernetes使用了crictl命令管理CRI，但在配置文件/etc/crictl.yaml中未添加相应的配置，导致无法正常拉取镜像。解决方法是首先验证网络配置，确保无HTTP_PROXY设置，然后在配置文件中添加crictl的配置。若/etc/containerd/config.toml中存在disabled_plugins = ["cri"]这一行，需要注释掉此行，然后重启containerd服务。
问题二：运行kubeadm init时报错“failed to run Kubelet: running with swap on is not supported, please disable swap!”。解决方法是先查看kubelet状态，确保服务正在运行，然后在系统中禁用swap。
问题三：kubeadm init过程中遇到一些配置文件存在问题。由于此前kubeadm运行报错导致init命令中断，导致部分配置文件已生成。这时需要执行kubeadm reset命令撤销之前的操作。
问题四：遇到kubeadm init时报ipv4相关错误。解决方法是加载ipvs模块。
问题五：kubeadm init时报错“crictl --runtime-endpoint配置不对”。查看日志，发现unix:///var/run/containerd/containerd.sock文件不存在。需要修改crictl配置文件，将crictl下载镜像时使用的默认端点更改为containerd.sock。
问题六：在kubeadm init时，报错“pause镜像获取失败”。通过日志提示，执行crictl --runtime-endpoint unix:///var/run/containerd/containerd.sock ps -a，发现没有容器在运行。查看containerd日志，得知其在拉取镜像时失败。解决方法是修改containerd配置，确保pause镜像的repo与本地镜像名称一致，然后重启containerd服务。
问题七：在执行kubeadm init或kubeadm join前，kubelet日志报错“/var/lib/kubelet/config.yaml文件不存在”。这是正常现象，执行完相关命令后，配置文件将自动生成。
官方镜像加速
当使用Docker下载官方镜像时，可能会遇到网络延迟或下载失败的问题。为解决这一难题，阿里云的容器镜像服务ACR提供了官方镜像加速功能，特别针对个人开发者设计，适用于非商业和个人开发场景。
需要注意的是，由于Docker Hub的限制，使用镜像加速器可能无法获取最新官方镜像，此时建议暂时关闭加速器配置，直接连接Docker Hub获取。镜像加速器的配置步骤会因操作系统不同而有所差异。
对于Docker版本较高的用户（1.及以上），推荐在daemon config中进行配置，如在/etc/docker/daemon.json文件中添加相关信息，重启Docker Daemon即可启用加速。而对于较旧版本的Docker，需要针对具体操作系统调整相关配置文件。
如果使用Containerd作为ACK的运行时，需要在/etc/containerd/config.toml中对CRI配置进行相应的修改。镜像加速器的具体地址，可以在容器镜像服务控制台找到，登录后在镜像工具 > 镜像加速器页面获取。
K8s：一文认知 CRI，OCI，容器运行时，Pod 之间的关系
不必过于忧虑当下或过于憧憬未来，当你经历了生活中的某些事情，眼前的风景自然会与以往大不相同。 ——村上春树
Kubernetes生态系统中，kubelet服务通过CRI接口与容器运行时交互，从而实现容器的管理。CRI，即容器运行时接口，是Kubernetes与不同容器运行时交互的标准化规范。选择或编写CRI实现，可以确保兼容性与灵活性。
CRI接口是Kubernetes与容器运行时之间的桥梁，通过此接口，kubelet可以调用容器运行时的gRPC接口来管理容器。它类似于面向接口编程的概念，类似于Java中通过JDBC接口连接不同数据库进行数据操作，CRI接口允许与不同的容器运行时进行交互。
在Kubernetes生态中，CRI接口通过kubelet与容器运行时进行交互，实现对容器镜像的管理。具体操作通过容器运行时提供的gRPC接口完成。CRI接口有多种实现方式，如dockershim、CRI-containerd和CRI-O。
其中，dockershim最初用于适配Docker API与CRI接口的兼容性问题，但由于性能和可靠性方面的限制，已被废弃。CRI-containerd作为基于containerd的CRI兼容插件，通过实现CRI接口，为Kubernetes提供了强大的容器管理能力。CRI-O则是基于Open Container Initiative(OCI)标准的轻量级CRI接口实现，适用于注重兼容性和移植性的场景。
CRI接口由两部分组成：容器运行时接口和镜像接口。在早期实现中，Shimv1是常见的容器运行时接口实现，它通过代理进程管理容器生命周期。然而，Shimv2的引入，利用了ttrpc作为通信协议，改进了性能和稳定性。
OCI（Open Container Initiative）组织成立于年，旨在制定容器格式和运行时的开放工业标准。目前主要有容器运行时标准（runtime spec）和容器镜像标准（image spec）两个文档。runtime spec定义了容器状态、配置文件、生命周期管理命令等格式，image spec包则定义了容器镜像的文件系统、config文件、manifest文件、index文件等。
容器命令包括创建、启动、停止、删除等生命周期管理操作。config.json文件作为OCI规范定义的容器配置文件，包含所有容器运行时需要了解和使用的配置信息。
容器运行时分为低级和高级两种。低级运行时，如runc、lxc、gVisor、Kata容器等，负责与内核交互，创建和管理内核级别的资源，如cgroups和namespaces。而高级运行时，如Docker引擎、Podman、containerd等，基于低级运行时提供更高层次的管理能力，能够直接调用低级运行时，管理容器生命周期并内置镜像管理。
runc是docker捐赠给OCI社区的runtime spec参考实现，用于创建docker容器。利用Linux内核特性实现进程隔离。Kata-runtime基于虚拟化实现安全隔离的容器运行时，使用系统调用拦截技术实现容器安全隔离。gVisor则是一款由Google开源的安全容器运行时，通过轻量级的系统调用过滤技术，在不影响性能的情况下有效提升容器安全性。
RuntimeClass是Kubernetes中的对象类型，用于定义特定运行时的资源和调度行为。它允许指定开销和节点选择器，将容器运行时与Pod关联起来。通过RuntimeClass，可以针对不同场景优化资源与调度，例如将CPU密集型任务调度至具备较高CPU资源的节点。
Runtime Plugin是containerd中的runtime插件配置，定义了运行时名称、二进制路径、传递的注解、特权容器模式等。在了解了CRI、OCI与容器运行时机制原理后，我们对容器引擎和运行时机制有了更深入的认识。
Kubernetes1..6部署文档 使用cri-docker部署K8s1..6
Kubernetes 1..6部署指南: 使用cri-docker部署K8s集群
要通过cri-docker部署K8s 1..6，首先需要在3台服务器（或虚拟机）上进行环境准备，每台服务器需要至少2个核心CPU和2GB RAM，以确保初始化过程顺利。环境搭建
所有节点同时进行以下步骤：配置主机名并更新Hosts文件
关闭SELINUX，禁用swap，调整内核参数以支持二层通讯
设置时区并使用NTP进行时间同步
配置Iptables防火墙
开启ipvs以提高效率
安装Docker和cri-docker
安装最新版本的Docker CE，然后从GitHub获取cri-docker rpm包（由于速度问题，已将镜像包存储在本地服务器）。 编辑cri-docker的service文件进行配置。部署Master节点
按照部署日志的指示，创建文件夹，复制配置文件，并输入相关命令以安装CNI插件。Node节点部署
将Node节点加入到Master节点集群，确保在命令中添加`--cri-socket unix:///var/run/cri-dockerd.sock`参数，成功后会看到提示"This node has joined the cluster"。Containerd 入门基础操作
Containerd被广泛应用于Docker、Kubernetes CRI以及其他项目，旨在简化系统集成。它作为后台运行容器的引擎，同时支持多种操作。
配置方面，通过生成默认配置文件实现基本设置。此外，使用配置镜像加速器可提升下载速度。
通过`ctr`插件命令，如`ctr plugins ls`，用户可以查看当前加载的插件及其支持的操作。例如，通过插件`content`，可以执行相关命令操作。
使用`ctr images ls`查看本地镜像，执行`ctr images pull`来拉取外部镜像。需要注意，只有通过`crictl`或Kubernetes调用`mirror`功能才有效，直接使用`ctr`拉取镜像可能不会生效。
对于镜像管理，`ctr images rm`用于删除镜像，`ctr images mount`和`ctr images unmount`分别实现镜像挂载与卸载，`ctr images export`和`ctr images import`则用于镜像导出与导入。
在容器生命周期管理中，`ctr`提供了丰富命令。例如，`ctr containers ls`列出所有容器，`ctr containers create`创建容器，`ctr containers rm`删除容器，`ctr containers info`查看容器详细信息。一个容器实例化为`containers`，提供虚拟环境；运行容器使用`ctr tasks start -d`命令，通过`ctr task exec`进入容器，执行`ctr task pause`暂停或`ctr task resume`恢复容器，使用`ctr task kill`结束容器运行，`ctr task metrics`获取容器性能数据，最后，`ctr tasks rm`删除容器。
本文旨在介绍Containerd基础操作，涵盖配置、镜像管理、容器生命周期管理等关键功能。
浅谈 Containerd、 Docker 和 CRI-O 三种容器运行时工作原理
运行时指的是程序的生命周期阶段或使用特定语言来执行程序。容器运行时的功能与它类似——它是运行和管理容器所需组件的软件。这些工具可以更轻松地安全执行和高效部署容器，是容器管理的关键组成部分。在容器化架构中，容器运行时负责从存储库加载容器镜像、监控本地系统资源、隔离系统资源以供容器使用以及管理容器生命周期。
容器运行时的常见示例是 runC、containerd 和 Docker。容器运行时主要分为三种类型——低级运行时、高级运行时以及沙盒或虚拟化运行时。
在容器技术中，容器运行时可以分为三种类型：低级运行时、高级运行时以及沙盒或虚拟化运行时。
总的来说，容器运行时的不同类型具有各自的优缺点和适用场景。在选择容器运行时时，需要根据实际需求和限制进行权衡和选择。
低级容器运行时 (Low level Container Runtime)，一般指按照 OCI 规范实现的、能够接收可运行文件系统（rootfs） 和 配置文件（config.json）并运行隔离进程的实现。
这种运行时只负责将进程运行在相对隔离的资源空间里，不提供存储实现和网络实现。但是其他实现可以在系统中预设好相关资源，低级容器运行时可通过 config.json 声明加载对应资源。
低级运行时的特点是底层、轻量、灵活，限制也很明显：
解决了这些限制中一项或者多项的容器运行时，就叫做高级容器运行时 (High level Container Runtime)。
高级容器运行时首先要做的是打通 OCI image spec 和 runtime spec，直白来说就是高效处理 image 到 rootfs 和 config.json 的转换。config.json 的生成比较简单，运行时可以结合 image config 和请求方需求直接生成；较为复杂的部分是 image 到 rootfs 的转换，这涉及镜像拉取、镜像存储、镜像 layer 解压、解压 layer 文件系统（fs layer) 的存储、合并 fs layer 为 rootfs。
镜像拉取模块先从 image registry 获取清单（manifest）文件，处理过程不仅需要兼容 OCI image 规范，考虑到 Docker 生态，也需兼容 Docker image 规范（所幸两者区别并不大）。运行时实现先从 manifest 获取 layer list，先检查对应 layer 在本地是否存在，如果不存在则下载对应 layer。下载的 layer tar 或者 tar.gz 一般直接存储磁盘，为实现快速处理，需要建立索引，比如从 reference:tag （如 docker.io/library/redis...) 到 manifest 存储路径的映射；当然，layer 的访问比 image 高频，layer sha 值到对应存储路径也会被索引。因此 ，运行时一般会围绕 image 索引和 image layer 存储组织独立模块对其他模块提供服务。
如果要转换 image layers 到 rootfs，就要逐层解压 layers 为 filesystem layer（fs layer) 再做合并。这带来了几个问题，首先是 fs layer 同样需要存储磁盘多次复用，那么就需要有一个方式从 image 映射到对应 fs layers；接着类似 image layer，需要建立索引维系 fs layers 之间的父子关系，尽可能复用里层文件，避免重复工作；最后是层次复用带来的烦恼，隔离进程运行之后会发生 rootfs 写入，需要以某种方式避免更改发生到共享的 fs layers。
最后，高级运行时需要充当隔离进程管理者角色，而一个低级运行时（如 runC ）可能同时被多个高级运行时使用。同时试想，如果隔离进程退出，如何以最快的方式恢复运行？高级运行时实现一般都会引入 container 抽象（或者说 container meta），meta 存储了 ID、 image 信息、低级运行时描述、OCI spec (json config）、 work layer id 以及 K-V 结构的 label 信息。因此只要创建出 container meta，后续所有与隔离进程相关操作，如进程运行、进程信息获取、进程 attach、进程日志获取，均可通过 container ID 进行。
