Podman

红球yyds

914人浏览 · 2025-11-27 21:38:48

红球yyds · 2025-11-27 21:38:48 发布

一.podman的介绍

podman是一个开源的容器管理工具开始就遵循30c1原则，可以直接运行docker镜像，同时，podman（可以从这里面构建镜像并推送到dockerHub上面）它也可以从docker Hub上面下载镜像

docker与podman的区别：

docker通常依赖由root用户启动的守护进程dockerd，当我们执行Docker CLI也就是Docker命令行工具会先把命令发送给守护进程dockerd.然后调用containerd（高级运行时），它在调用低语容器运行时runc；最后由runc与操作系统内核进行交互管理容器。

podman（本身是一个轻量级的命令行工具）没有守护进程。
①在执行Podman命令时，直接调用rmc，与操作内核进行交互，管理容器（更简单和轻量）大大降低系统的复杂复度

为什么会有警告呢？

因为当前系统都没有正在运行的Podman容器；普通用户模式下存在共享挂载的警告，root模式下该警告消失。
②不需要root权限守护，可以用普通用户执行和管理，体现了它更安全、更灵活的特性.。

在下方的操作中我们会用到wsl，podman是无守护的，与wsl是绝配的（是运行windows上的liunx 系统）

wsl安装在电脑的终端安装

wsl --set-default-version2(把wsl的默认版本设成2)

wsl --update --web-download

sudo apt install podman sudo snap install docker

如果无法安装：sudo apt update

二.下载pod并使用

2.1pod的特征：

Pod类似虚拟机，容器相当于虚拟机中的进程，一个Pod可以运行多个容器，只需声明多个image即可实现。
容器不仅仅是拥有实际功能的主容器，还有类似init初始化的容器。初始化容器就是配置好主容器的配置。
（网络）Pod是有IP地址的，加入pod不是共享物理机ip，由网络插件（calico、flannel、weave）划分的ip，每个pod都被分配唯一的IP地址。
（存储）创建Pod的试试可以指定挂载的存储卷，POD中的所有容器都可以访问共享卷volume，允许这些容器共享卷数据，Pod只要挂载持久化数据卷，pod重启之后数据还是会存在的。

2.2pod和容器的区别

pod是由一组紧耦合的容器组成的容器组，目前最流行的就是docker、containerd、podman容器，pod就可以作为1或者多个容器的载体。
pod中的所用容器会被一致调度、统计点部署，并且在一个“共享环境”中运行，这里就的"共享环境包括一下几点"：
所有容器共享一个IP地址和端口空间，意味着容器之间可以通过localhost高效访问，不能有端口冲突。
允许容器之间共享存储卷，通过文件系统交互信息。
有些容器需要紧密联系，需要一起工作。pod提供了比容器更高层次的抽象，pod中所有的容器使用同一个网络的namespace，即相同的IP地址和Port空间。他们可以直接用localhost通信，同样的，这些容器可以共享存储，当K8sVolume到pod上，本质上是将volume挂载到pod中的每个容器里。

2.3pod的实际应用：

代码的自动发行和更新
收集业务日志

总结：

pod 是一个从Kubernetes中延生的概念，pod是kubernetes的核心调度更元.
一个pod由一个或多个紧密来寓合的容器组成，同一个Pod的容等它们共享网络空间，IP、
IPC命名空间和挂载卷相同
通过podman 创建一个pod，然后把一个或多个容路添加进去，对pod的原生支持是 Podman的一个重要特性而Docker 没有。

2.4镜像下载

下载镜像：podman pull docker.io/library/mongo

如果下载失败解决方案：

1.打开 vim /etc/containers/registries.conf

2.在里面的最后加上：

[[registry]]
  location="docker.io"
   [[registry.mirror]]
   location="docker.m.daocloud.io"（表示给Docker Hub配置一个镜像站）

3.然后在重新输入：podman pull docker.io/library/mongo

创建容器并运行

1.mkdir -p /home/mongo-data创建一个目录

podman run -d \
  -p 27017:27017 \
  -v /home/mongo-data:/data/db \
  -e MONGO_INITDB_ROOT_USERNAME=xia \
  -e MONGO_INITDB_ROOT_PASSWORD=shrimp \
  docker.io/library/mongo

-d 创建并运行一个容器

-p 容器接口

3. podman ps 查看

root@LAPTOP-I8STD0PP:/home/xia# podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6b4d9bbc7ab8 docker.io/library/mongo:latest mongod 49 seconds ago Up 49 seconds ago 0.0.0.0:27017->27017/tcp distracted_jackson

可以通过 mongosh "mongodb://tech:shrimp@172.31.67.201:27017"这条命令可以让wsl连接

4.pod的仓库

root@LAPTOP-I8STD0PP:~# mkdir -p /home/ubuntu/mongo-data

root@LAPTOP-I8STD0PP:~# podman run -d --pod my-pod --name my_mongodb -v /home/ubuntu/mongo_data:/data/db -e MONGO_INITDB_ROOT_USERNAME=xia -e MONGO_INITDB_ROOT_PASSWORD=shrimp docker.io/library/mongo
5105997371e7ceeeb5174d870d20169a1c63fd84f7ad8afac2fb0593c8496495
root@LAPTOP-I8STD0PP:~# podman run -d --pod my-pod \
--name my_mongo-express \
-e ME_CONFIG_MONGODB_ADMINUSERNAME=xia \
-e ME_CONFIG_MONGODB_ADMINPASSWORD=shrimp \
-e ME_CONFIG_MONGODB_SERVER=my_mongodb \
mongo-express
9d6ab616f153fcc5d35882b4403281841f49e49a4fa7bd0eb2812df0ef977a11

root@LAPTOP-I8STD0PP:~# podman pod stop my-pod(停止)
df6a6efb71d1211db2a1c51cb80a08e8e1bd8dda807fd90c67d1b44a22daafbc
root@LAPTOP-I8STD0PP:~# podman ps --pod
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES POD ID PODNAME
root@LAPTOP-I8STD0PP:~# podman pod start my-pod（启动）
df6a6efb71d1211db2a1c51cb80a08e8e1bd8dda807fd90c67d1b44a22daafbc
root@LAPTOP-I8STD0PP:~# podman ps --pod
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES POD ID PODNAME
6ee6dea411aa registry.aliyuncs.com/google_containers/pause:3.5 10 minutes ago Up 3 seconds ago 0.0.0.0:8081->8081/tcp, 0.0.0.0:8082->27017/tcp df6a6efb71d1-infra df6a6efb71d1 my-pod
5105997371e7 docker.io/library/mongo:latest mongod About a minute ago Up 3 seconds ago 0.0.0.0:8081->8081/tcp, 0.0.0.0:8082->27017/tcp my_mongodb df6a6efb71d1 my-pod
9d6ab616f153 docker.io/library/mongo-express:latest mongo-express About a minute ago Up 3 seconds ago 0.0.0.0:8081->8081/tcp, 0.0.0.0:8082->27017/tcp

（如果有问题可以通过 podman ps --pod --all | grep my-pod查看接口

podman logs 9d6ab616f153查看仓库的日志）

podman run -d --pod my-pod \
  --name my_mongo_express \
  -e ME_CONFIG_MONGODB_SERVER=localhost \  # 用localhost替代my_mongodb，避免DNS解析
  -e ME_CONFIG_MONGODB_PORT=27017 \
  -e ME_CONFIG_MONGODB_ADMINUSERNAME=xia \  # 与MongoDB用户名一致
  -e ME_CONFIG_MONGODB_ADMINPASSWORD=shrimp \  # 与MongoDB密码一致
  -e ME_CONFIG_BASICAUTH=false \  # 临时关闭基础认证，直接访问
  mongo-express

root@LAPTOP-I8STD0PP:~# podman ps --pod | grep my_mongo_express（查看接口）
dfc190ddd022 docker.io/library/mongo-express:latest mongo-express 44 seconds ago Up 45 seconds ago 0.0.0.0:8081->8081/tcp, 0.0.0.0:8082->27017/tcp my_mongo_express df6a6efb71d1 my-pod

接下来分为这几步完成：

打开 Microsoft Edge，地址栏输入：http://localhost:8081；
无需登录（已关闭基础认证），直接进入 Mongo-express 管理界面；
左侧点击 admin 数据库，即可开始操作（创建集合、插入数据等）。

三.k8s

3.1 Docker、Containerd、RunC的关系

三者关系，见下图：

3.2、CRI

容器运行时是 Kubernetes（K8S）最重要的组件之一，负责管理镜像和容器的生命周期。Kubelet 通过 Container Runtime Interface (CRI) 与容器运行时交互，以管理镜像和容器。

CRI即容器运行时接口，主要用来定义K8S与容器运行时的API调用，kubelet通过CRI来调用容器运行时，只要实现了CRI接口的容器运行时就可以对接到K8S的kubelet组件。

3.3、Docker和K8S的关系

Docker和K8S本质上都是创建容器的工具，Docker作用与单机，K8S作用与集群。

在单机的容器解决方案，首选Docker。随着时代的发展，对系统的性能有了更高的要求，高可用、高并发都是基本要求。随着要求变高的的同时，单机显然性能就跟不上了，服务器集群管理就是发展趋势，所以 Kubernetes 为代表的云原生技术强势发展。

3.3.1、容器创建调用链路

Docker、Kubernetes、OCI、CRI-O、containerd、runc，他们是如何一起协作的呢，见下图。

上图所示为容器的调用链路。如图我们看到的，只要是实现了CRI的容器运行时就能够被K8S采用。Containerd是通过CRI Plugin 来适配CRI的，而CRI-O则是为CRI量生打造。

我们还可以看到包括了Docker和K8S两条主线，其中Docker主要是在面向单体应用，K8S是用于集群。

3.3.2、关系

从上面的容器调用链路可以看到，对于Containerd 和 CRI-O我们非常清楚他们是干嘛的，但是对于Docker和K8S间的联系我们还需要再来理一下。

如图为K8S与Docker之间的联系（包含K8S1.23版本在内以及之前的版本），从K8S-1.24版本开始将移除docker-shim模块。下面继续看看他们之间的小故事。

3.4、Dockershim的小故事

3.4.1、dockershim的由来

自 K8S - v1.24 起，Dockershim 已被删除，这对K8S项目来说是一个积极的举措。

在 K8S 的早期，只支持一个容器运行时，那个容器运行时就是 Docker Engine。那时并没有其他的选择。

随着时间推移，我们开始添加更多的容器运行时，比如 rkt 和 hypernetes，很明显 K8S 用户希望选择最适合他们的运行时。因此，K8S 需要一种方法来允许K8S集群灵活地使用任何容器运行时。

于是有了容器运行时接口 (CRI) 的发布，CRI 的引入对K8S项目和K8S用户来说都很棒，但它引入了一个问题：Docker Engine 作为容器运行时的使用早于 CRI，所以Docker Engine 不兼容 CRI。

为了解决这个问题，在 kubelet 组件中引入了一个小型软件 shim (dockershim)，专门用于填补 Docker Engine 和 CRI 之间的空白，允许集群继续使用 Docker Engine 作为容器运行时。

3.4.2、dockershim的宿命

然而，这个小软件 shim 从来没有打算成为一个永久的解决方案。多年来，它的存在给 kubelet 本身带来了许多不必要的复杂性。由于这个 shim，Docker 的一些集成实现不一致，导致维护人员的负担增加。

总之，这样的方式不但带来了更高的复杂度，而且由于部件的增加也增加了不稳定的因素，同时还增加了维护负担，所以弃用dockershim是迟早的事。

总结：dockershim 一直都是 K8S 社区为了能让 Docker 成为其支持的容器运行时，所维护的一个兼容程序。现在所谓的废弃，也仅仅是 K8S 要放弃对现在代码仓库中的 dockershim 的维护支持。以便K8S可以像刚开始时计划的那样，仅负责维护其 CRI ，任何兼容 CRI 的容器运行时，都可以作为 K8S 的 runtime。

3.4.3、流转图：

2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

SynaCore AM-DT：重新定义液压歧管3D打印的价值创造

2048 AI社区

告别报表搬运工：数据分析师如何靠权限与日志构建智能分析Agent

2048 AI社区

2026年AI论文助手怎么选？从开题到答辩的全流程选购指南

论文写到一半卡住了」「开题报告改了五版还是过不了」「答辩前一周PPT还没做」——如果你正在经历这些，一款合适的AI论文助手可能是你今年最值得的投资。但市面上从通用大模型到垂直工具不下几十款，功能宣传天花乱坠，到底该怎么选？一句话答案：选AI论文助手，别看模型参数看「场景闭环」——能否覆盖开题、写作、查重、降重、AIGC检测、排版这条完整链路，像毕业之家ai（www.biye.com）这样的全流程平