网站建设与维护招聘条件,百度站长平台官网登录入口,怎么在百度上发表文章,wordpress添加新浪微博一、前言 最近在进行OS国产化交流中#xff0c;了解到部分业务迁移到BClinux 8.2或Anolis 8.2时#xff0c;原有docker业务需要迁移到新的容器平台#xff1a;Podman#xff0c;来完成容器的新的管理。Podman#xff08;全称 Pod Manager#xff09;是一款用于在 Linux 系…一、前言 最近在进行OS国产化交流中了解到部分业务迁移到BClinux 8.2或Anolis 8.2时原有docker业务需要迁移到新的容器平台Podman来完成容器的新的管理。Podman全称 Pod Manager是一款用于在 Linux® 系统上开发、管理和运行容器的开源工具。Podman 最初由红帽® 工程师联合开源社区一同开发它可利用 lipod 库来管理整个容器生态系统。官方声称Podman - The next generation of Linux container tools它不仅可以管理 OCI 容器,还可以管理 pod 。
Podman 是一个 RedHat 公司发布的开源容器管理工具初衷就是 Docker 的替代品在使用上与 Docker 的相似但又有着很大的不同。它与 Docker 的最大区别是架构Docker 是以 C/S 架构运行的我们平时使用的 docker 命令只是一个命令行前端它需要调用 dockerd 来完成实际的操作而 dockerd 默认是一个有 root 权限的守护进程。而Podman 不需要守护进程直接通过 fork/exec 的形式启动容器不需要 root 权限。这也是Podman其中一个较大优势它采用了无守护进程的包容性架构可以更安全、更简单地对容器进行管理再加上 Buildah 和 Skopeo 等与之配套的工具和功能开发人员能够按照自身需求来量身定制容器环境。 它实际与Docker扮演相同的角色并且在很大程度上与 Docker 兼容提供几乎相同的命令。总之Podman是一个基于libpod库开发的容器运行时用于在Linux操作系统上管理和运行容器。与传统的Docker容器运行时不同Podman无需依赖Docker守护进程它可以在不同的Linux发行版中独立运行。它支持常见的容器管理功能如启动、停止、重启和删除容器以及构建、推送和拉取容器镜像等。Podman还支持容器的网络和存储管理可以使用CNI插件创建和管理容器的网络支持使用多种存储驱动程序如overlayfs、btrfs和zfs等。
Podman的一个显著特点是它使用的是rootless模式这意味着它可以在普通用户权限下运行而不需要root权限。这有助于提高容器运行的安全性和可移植性。同时Podman支持通过Pods来管理一组相关的容器这样可以方便地管理复杂的应用程序。
另外Podman还支持使用systemd来管理容器这使得它可以更好地集成到Linux系统中与其他系统服务一起运行和管理。但无论怎样它作为运行时Podman的底层主要也是基于Linux的Cgroup和Namespace等技术。
Podman 可以帮助我能实现如下 管理容器镜像和完整的容器生命周期包括运行、联网、检查和下线。 为无根容器和容器集运行和隔离资源。 支持 OCI 和 Docker 镜像以及与 Docker 兼容的 CLI。 打造一个无守护进程的环境提高安全性并减少闲置资源消耗。 部署 REST API 来支持 Podman 的高级功能。 借助 checkpoint/restore in userspaceCRIU实施面向 Linux 容器的检查点/恢复功能。CRIU 可以冻结正在运行的容器并将其内存内容和状态保存到磁盘以便容器化工作负载能够更快地重新启动。 自动更新容器。Podman 会检测更新的容器是否无法启动并自动回滚到上一个工作版本。这可以将应用的可靠性提升到新的水平。 相关资料containerd、Podman、Podman介绍、官网、Podman项目
二、架构和功能
2.1、运行时runtime
运行时就是程序运行的时候也就是指令加载到内存并由CPU执行的时候实际它就是一套比较底层的纯C语言API是1个C语言库包含了很多底层的C语言API从而更好与Linux内核通信。与之相对应的是“编译时”其指代码编译的时候也就是C代码编译成可执行文件的时候此时指令没有被CPU执行。对应的运行时库就是程序运行的时候所需要依赖的库。
每个环境都有自己的运行时这里我们主要回顾容器的运行时runtime就是运行和管理容器进程、镜像的工具可以把进程运行在容器中并可通过SDK或命令来调用Linux的内核功能从而创建出容器或其他关联容器底层的东西。runtime是在一个OCIOpen Container Initiative组织中被明确定义的。OCI 发布了两个规范runtime spec 和 image format spec这样不同组织和厂商依据该规范开发的容器能够在不同的 runtime 上运行保证了容器的可移植性和互操作性。 这个规范规定了容器之中应用被放到什么样的环境下、如何运行比如说容器的根文件系统上哪个可执行文件会被执行是用什么用户执行需要什么样的 CPU有什么样的内存资源、外置存储还有什么样的共享需求等等。正如前文所述runtime 就是容器可理解就是一个独立的进程真正运行的地方。整个过程中 需要跟操作系统 kernel 紧密协作为容器提供运行环境。比如那常见的Java环境举例Java 程序就可看做是个容器JVM 则好比是 runtime。JVM 为 Java 程序提供运行环境。同样的道理容器只有在 runtime 中才能运行。
OCI规范概览 镜像规范常被称为“OCI 1.0 images定义了容器镜像的内容 运行时规范 常被称为“CRIContainer Runntime Interface 1.0”或者容器运行时接口表述了容器的”配置运行环境和生命周期“。容器运行时接口(Container Runtime Interface, CRI)是指上层应用无需编译就可以支持多种容器运行时的插件接口通过插件的切换方式应用不同封装的容器。 容器网络接口CNI描述了如何在容器内部配置网络接口不过它是在CNCF下标准化的 而不是OCI。 目前主流的有三种容器 runtime LXC 是 Linux 上老牌的容器 runtime。Docker 最初也是用 lxc 作为 runtime。lxc 是 lxd 的管理工具。 runc 是 Docker 自己开发的容器 runtime符合 oci 规范也是现在 Docker 的默认 runtime。Docker公司把其容器核心技术libcontainer捐给OCIOpen Container Intiative后更名为runC。Runc 的管理工具是 docker enginedocker engine 包含后台 deamon 和 cli 两部分大家经常提到的 Docker 就是指的 docker engine。 rkt 是 CoreOS 开发的容器 runtime符合 oci 规范因而能够运行 Docker 的容器。Rkt 的管理工具是 rkt cli。 当前后来随着发展也出现了其他runtime比如Kata Container、CRI-O等最先Docker使用的是LXC但是层次隔离不太完整所以后来Docker开发了libcontainer最后演变为了runC。
Runtime 主 要 定 义 了 以 下 规 范 并 以 json 格 式 保 存 在/run/docker/runtime-runc/moby/容器 ID/state.json 文件此文件会根据容器的状态实时更新内容 版本信息存放 OCI 标准的具体版本号。 容器 ID通常是一个哈希值可以在所有 state.json 文件中提取出容器 ID 对容器进行 批量操作(关闭、删除等)此文件在容器关闭后会被删除容器启动后会自动生成。 PID在容器中运行的首个进程在宿主机上的进程号即将宿主机的那个进程设置为容 器的守护进程。 容器文件目录存放容器 rootfs 及相应配置的目录外部程序只需读取 state.json 就 可以定位到宿主机上的容器文件目录。 容器创建创建包括文件系统、namespaces、cgroups、用户权限在内的各项内容。 容器进程的启动运行容器启动进程该文件在 /run/containerd/io.containerd.runtime.v1.linux/moby/容器 ID/config.json。 容器生命周期容器进程可以被外部程序关停runtime 规范定义了对容器操作信号的 捕获并做相应资源回收的处理避免僵尸进程的出现。 OCI 容器镜像主要包含以下内容 文件系统:定义以 layer 保存的文件系统,在镜像里面是 layer.tar,每个 layer 保存了 和上层之间变化的部分,image format spec 定义了 layer 应该保存哪些文件,怎么表 示增加、修改和删除的文件等操作。 manifest 文件描述有哪些 layertag 标签及 config 文件名称。 config 文件是一个以 hash 命名的 json 文件保存了镜像平台容器运行时容 器运行时需要的一些信息比如环境变量、工作目录、命令参数等。 index 文件可选的文件,指向不同平台的 manifest 文件,这个文件能保证一个镜 像可以跨平台使用每个平台拥有不同的 manifest 文件使用 index 作为索引。 父镜像大多数层的元信息结构都包含一个 parent 字段指向该镜像的父镜像。 参数 ID镜像 ID每一层都有 ID tag 标签标签用于将用户指定的、具有描述性的名称对应到镜像 ID 仓库Repository 镜像仓库 os定义类型 architecture 定义 CPU 架构 author作者信息 create镜像创建日期 容器运行时具有掌控容器运行的整个生命周期包括镜像的构建和管理、容器的运行和管理等功能。容器运行时接口(Container Runtime Interface, CRI)是指上层应用无需编译就可以支持多种容器运行时的插件接口通过插件的切换方式应用不同封装的容器。容器运行时向上提供容器调用接口包括容器生成与销毁的全生命周期管理的功能向下提供调用接口负责具体的容器操作事项例如一个典型的Kubernetes集群中Kubernetes对具体的容器类型不感知而通过Kubernetes节点代理kubelet实现了 CRI客户端 API可以使用任何实现 CRI 服务器 API的容器运行时来管理其节点上的容器和 Pod。
根据容器运行时提供功能可以将容器运行时分为低层运行时和高层运行时。
1低层运行时主要负责与宿主机操作系统打交道根据指定的容器镜像在宿主机上运行容器的进程并对容器的整个生命周期进行管理。而这个低层运行时正是负责执行我们前面讲解过的设置容器 Namespace、Cgroups等基础操作的组件。常见的低层运行时种类有 RunC传统的运行时基于Linux Namespace和Cgroups技术实现代表实现Docker RunV基于虚拟机管理程序的运行时通过虚拟化 guest kernel将容器和主机隔离开来使得其边界更加清晰代表实现是Kata Container和Firecracker Runscrunc safety 通过拦截应用程序的所有系统调用提供安全隔离的轻量级容器运行时沙箱代表实现是谷歌的gVisor 2高层运行时主要负责镜像的管理、转化等工作为容器的运行做前提准备。主流的高层运行时主要containerd和CRI-O。
高层运行时与低层运行时各司其职容器运行时一般先由高层运行时将容器镜像下载下来并解压转换为容器运行需要的操作系统文件再由低层运行时启动和管理容器。
另外这里还要注意的一个容器引擎containerd2020年CNCF基金会宣布Kubernetes 1.20版本将不再仅支持Docker容器管理工具早前Docker 1.11的Docker Engine里就包含了containerd而现在则是把containerd从Docker Engine里彻底剥离出来作为一个独立的开源项目独立发展目标是提供一个更加开放、稳定的容器运行基础设施。在Docker Engine里containerd相比独立的containerd将具有更多的功能可以涵盖整个容器运行时管理的所有需求。另外独立之后containerd的特性演进可以和Docker Engine分开专注容器运行时管理可以更稳定。
Containerd是一个工业标准的容器运行时重点是它简洁健壮便携在Linux和window上可以作为一个守护进程运行它可以管理主机系统上容器的完整的生命周期镜像传输和存储容器的执行和监控低级别的存储和网络。每个containerd只负责一台机器Pull镜像对容器的操作启动、停止等网络存储都是由containerd完成。具体运行容器由runC负责实际上只要是符合OCI规范的容器都可以支持。
Containerd和docker不同containerd重点是集成在大规模的系统中例如kubernetes、Swarm、Mesos等【对于容器编排服务来说运行时只需要使用containerdrunC更加轻量容易管理。】。Containerd 被设计成嵌入到一个更大的系统中而不是直接由开发人员或终端用户使用。
2.2、Podman 是如何管理容器的
用户可以通过命令行调用 Podman从存储库拉取容器并运行它们。Podman 调用配置好的容器运行时来创建运行的容器。由于没有专门的守护进程Podman 使用 systemd一种用于 Linux 操作系统的系统和服务管理器来进行更新并让容器在后台保持运行。通过将 systemd 和 Podman 集成我们可以为容器生成控制单元并通过自动启用 systemd 的前提下运行它们。
用户可以在系统上管理自有的存储库也可通过 systemd 单元来控制自有容器的自动启动和管理。允许用户管理自己的资源并使容器以无根方式运行可以阻止诸如使 /var/lib/containers 目录可被写入等不良做法或防范可能会导致应用暴露于额外安全问题的其他系统管理做法。这样也可确保每一用户具有单独的容器和镜像集合并可在同一主机上同步使用 Podman而不会彼此干扰。用户完成自己的工作时可将变更推送到共有的镜像仓库将他们的镜像共享给其他人。
Podman 也可部署 RESTful APIREST API来管理容器。REST 是表述性状态传递的英文缩写。REST API 是遵循 REST 架构规范的应用编程接口支持与 RESTful Web 服务进行交互。借助 REST API您可以从 cURL、Postman 和 Google 的 Advanced REST 客户端等许多平台调用 Podman。
三、部署配置
四、工具应用
4.1
4.2、Podman 桌面管理工具
Podman Desktop 使你能够轻松地使用本地环境中的容器Podman Desktop 无守护进程它利用 Podman Engine 提供轻量级且无守护程序的容器工具。该工具允许浏览、管理容器的生命周期、检查容器、来自不同容器引擎的镜像等。另它专注于将 Podman 作为默认打包的容器引擎的同时还兼容了其他容器引擎。Podman Desktop 具有以下一些特性 管理容器列出、搜索、检查、连接、运行和停止容器。构建、拉取和推送镜像从该工具构建镜像通过管理仓库来拉取和推送镜像从这些镜像运行容器。管理 Podman 资源查看分配的内存、CPU 和存储如果需要创建新机器兼容Docker desktop扩展指定 Docker desktop扩展的 OCI 镜像以将其导入。Podman Desktop 能够通过添加包装器来拦截 API 调用来使用 Docker Desktop UI 插件。通过添加 Docker Desktop 扩展你可以扩展 Podman Desktop 的功能。还可以在后台使用插件来管理不同的容器引擎。通过添加新插件。 资源获取二进制包
五、附录
5.1、Containerd回顾 如上图所示docker为我们提供了抽象的容器调用接口而其内部功能的具体实现却是调用的contanierd2016年docker 把负责容器生命周期的模块 containerd拆分出来并将其捐赠给了社区。
Containerd的特点 简洁的基于 gRPC 的 API 和 client library。 完整的 OCI 支持(runtime 和 image spec)。 同时具备稳定性和高性能的定义良好的容器核心功能。 一个解耦的系统(让 image、filesystem、runtime 解耦合)实现插件式的扩展和重用。 Containerd的作用 管理容器的生命周期(从创建容器到销毁容器)。 拉取/推送容器镜像。 存储管理(管理镜像及容器数据的存储)。 调用 runC 运行容器(与 runC 等容器运行时交互)。 管理容器网络接口及网络。 使用 bucketbench 对 Docker、crio 和 Containerd 的性能测试结果包括启动、停止和删除容器以比较它们所耗的时间可以发现Containerd 在各个方面都表现良好总体性能优于 Docker 和 crio。 Containerd架构Containerd 采用标准的 C/S 架构服务端通过 GRPC 协议提供稳定的 API客户端通过调用服务端的 API 进行高级的操作。为了实现解耦Containerd 将不同的职责划分给不同的组件每个组件就相当于一个子系统subsystem。连接不同子系统的组件被称为模块。containerd 需要调用 runC所以在安装 containerd 之前请先安装 runC。
containerd 的技术架构
Containerd 被分为三个大块 Storage 、 Metadata 和 Runtime。
Containerd 两大子系统为 Bundle : 在 Containerd 中Bundle 包含了配置、元数据和根文件系统数据你可以理解为 容器的文件系统。而 Bundle 子系统允许用户从镜像中提取和打包 Bundles。 Runtime : Runtime 子系统用来执行 Bundles比如创建容器。其中每一个子系统的行为都由一个或多个模块协作完成。 【几个概念】
1containerd 是一个高级容器运行时又名容器管理器。简单来说它是一个守护进程在单个主机上管理完整的容器生命周期创建、启动、停止容器、拉取和存储镜像、配置挂载、网络等。
2ctr 是作为 containerd 项目的一部分提供的命令行客户端。该ctr界面 [显然] 与 Docker CLI不兼容乍一看可能看起来不太用户友好。因为它的主要受众是测试守护进程的容器开发人员。ctr containerd比docker dockerd更接近实际的容器。
3nerdctl 是一个相对较新的containerd命令行客户端。与ctr不同nerdctl的目标是用户友好和docker兼容。在某种程度上nerdctl containerd可以无缝地替代docker dockerd。
4crictl 是一个命令行客户端用于 [kubernetes] CRI兼容的容器运行时。引入 Kubernetes 容器运行时接口 (CRI)以使 Kubernetes 容器运行时不可知。Kubernetes节点代理kubelet实现了 CRI客户端 API可以使用任何实现 CRI 服务器 API的容器运行时来管理其节点上的容器和 Pod。
相关资源containerd官网、containerd官方安装步骤
5.2、Docker、containerd的关系
1就docker本身而言包括docker client和dockerd是一个客户端工具用来把用户的请求发送给docker daemondockerd。dockerddockerd是对容器相关操作的最上层封装直接面向操作用户。Docker daemon一般也会被称为docker engine。dockerd启动时会启动containerd 子进程。
containerd-shim是一个真实运行容器的载体为了能够支持多种OCI Runtimecontainerd内部使用containerd-shim每启动一个容器都会起一个新的containerd-shim的进程。它通常指定三个因素容器ID、bundle目录对应某个容器生成的目录一般位于/var/run/docker/containerd/containerID
2containerd囊括了单机运行一个容器时所需要的一切containerd是一个工业级别标准的容器运行时它强调简单性、健壮性和可移植性几乎囊括了单机运行一个容器运行时所需要的一切执行、分发、监控、网络、构建、日志等。主要作用是 1、管理容器的生命周期从创建容器到销毁容器 2、拉取/推送容器镜像 3、存储管理管理镜像及容器数据的存储 4、调用runC运行容器与runC等容器运行时交互 5、管理容器网络接口及网络 dockerd实际真实调用的还是containerd的api接口containerd是dockerd和runC之间的一个中间交流组件。runC是一个轻量级的工具用来运行容器的我们可以不用通过docker引擎直接运行容器。
