名称

podman-pod-clone - 创建现有 Pod 的副本

概要

podman pod clone [选项] pod 名称

描述

podman pod clone 创建 Pod 的副本,重新创建 Pod 及其所有容器的相同配置。用户可以修改 Pod 的新名称,并选择基础设施容器内的 Pod 详细信息

选项

--blkio-weight=权重

块 IO 相对权重。权重是一个介于 101000 之间的数值。

此选项在 cgroups V1 无根系统上不受支持。

--blkio-weight-device=设备:权重

块 IO 相对设备权重。

--cgroup-parent=路径

在该路径下创建 Pod 的 cgroup。如果路径不是绝对路径,则该路径被认为相对于 init 进程的 cgroups 路径。如果 cgroups 不存在,则会创建它们。

--cpu-shares, -c=份额

CPU 份额(相对权重)。

默认情况下,所有容器都获得相同比例的 CPU 周期。可以通过更改容器的 CPU 份额权重来修改此比例,该权重相对于所有正在运行的容器的组合权重。默认权重为 1024

该比例仅在 CPU 密集型进程运行时适用。当一个容器中的任务处于空闲状态时,其他容器可以使用剩余的 CPU 时间。实际的 CPU 时间量取决于系统上运行的容器数量。

例如,考虑三个容器,其中一个的 cpu-share 为 1024,另外两个的 cpu-share 设置为 512。当所有三个容器中的进程尝试使用 100% 的 CPU 时,第一个容器接收总 CPU 时间的 50%。如果添加第四个容器,其 cpu-share 为 1024,则第一个容器仅获得 33% 的 CPU。其余容器分别接收 16.5%、16.5% 和 33% 的 CPU。

在多核系统上,CPU 时间份额分布在所有 CPU 核心上。即使容器被限制在低于 100% 的 CPU 时间内,它也可以使用每个单独 CPU 核心的 100%。

例如,考虑一个具有三个以上核心的系统。如果容器 C0--cpu-shares=512 启动并运行一个进程,另一个容器 C1--cpu-shares=1024 启动并运行两个进程,这可能会导致以下 CPU 份额分配

PID

容器

CPU

CPU 份额

100

C0

0

CPU0 的 100%

101

C1

1

CPU1 的 100%

102

C1

2

CPU2 的 100%

在某些系统上,可能不允许非 root 用户更改资源限制。有关更多详细信息,请参阅 https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

此选项在 cgroups V1 无根系统上不受支持。

--cpus

为 Pod 设置 CPU 数量,以覆盖原始 Pod 的 CPU 限制。如果没有指定,则使用原始 Pod 的纳米 CPU。

--cpuset-cpus=数字

允许执行的 CPU。可以指定为逗号分隔列表(例如 0,1)、范围(例如 0-3)或任何组合(例如 0-3,7,11-15)。

在某些系统上,可能不允许非 root 用户更改资源限制。有关更多详细信息,请参阅 https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

此选项在 cgroups V1 无根系统上不受支持。

如果没有指定,则使用原始 Pod 的 CPUset。

--cpuset-mems=节点

允许执行的内存节点 (MEM) (0-3, 0,1)。仅在 NUMA 系统上有效。

如果系统上有四个内存节点 (0-3),使用 --cpuset-mems=0,1,则容器中的进程仅使用来自前两个内存节点的内存。

在某些系统上,可能不允许非 root 用户更改资源限制。有关更多详细信息,请参阅 https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

此选项在 cgroups V1 无根系统上不受支持。

--destroy

删除我们克隆的原始 Pod,以便在用于模拟配置后删除。

--device=主机设备[:容器设备][:权限]

将主机设备添加到 Pod。可选的 权限参数可用于通过组合 r(读)、w(写)和 mmknod(2))来指定设备权限。

示例:--device=/dev/sdc:/dev/xvdc:rwm

注意:如果 主机设备是符号链接,则首先解析它。Pod 仅存储主机设备的主次设备号。

Podman 可能会加载使用指定设备所需的内核模块。Podman 在必要时加载模块的设备是:/dev/fuse。

在无根模式下,新的设备在容器中从主机绑定挂载,而不是 Podman 在容器空间中创建它。由于绑定挂载在 SELinux 系统上保留其 SELinux 标签,因此容器在访问挂载的设备时可能会获得权限被拒绝。通过以下命令修改 SELinux 设置,以允许容器使用所有设备标签

$ sudo setsebool -P container_use_devices=true

注意:Pod 通过存储用户传递的初始配置并在添加到 Pod 的每个容器上重新创建设备来实现设备。

--device-read-bps=路径:速率

限制从设备读取的速率(以每秒字节数计)(例如 --device-read-bps=/dev/sda:1mb)。

在某些系统上,可能不允许非 root 用户更改资源限制。有关更多详细信息,请参阅 https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

此选项在 cgroups V1 无根系统上不受支持。

--device-write-bps=路径:速率

限制写入设备的速率(以每秒字节数计)(例如 --device-write-bps=/dev/sda:1mb)。

在某些系统上,可能不允许非 root 用户更改资源限制。有关更多详细信息,请参阅 https://github.com/containers/podman/blob/main/troubleshooting.md#26-running-containers-with-resource-limits-fails-with-a-permissions-error

此选项在 cgroups V1 无根系统上不受支持。

--gidmap=pod_gid:host_gid:数量

用户命名空间的 GID 映射。使用此标志将在 Pod 中运行所有容器,并启用用户命名空间。它与 --userns--subgidname 标志冲突。

--gpus=ENTRY

要添加到容器的 GPU 设备(“all” 表示传递所有 GPU)。目前仅支持 Nvidia 设备。

--help, -h

打印使用说明。

--hostname=名称

设置所有容器中 Pod 的主机名。

给定的主机名也会使用容器的主 IP 地址添加到 /etc/hosts 文件中(另请参见 --add-host 选项)。

--infra-command=命令

用于启动基础设施容器的命令。默认值:“/pause”。

--infra-conmon-pidfile=文件

将基础设施容器 conmon 进程的 pid 写入文件。由于 conmon 在与 Podman 不同的进程中运行,因此在使用 systemd 管理 Podman 容器和 Pod 时,这是必要的。

--infra-name=名称

用于 Pod 的基础设施容器的名称。

--label, -l=键=值

向 Pod 添加元数据。

--label-file=文件

读取一个以换行符分隔的标签文件。

--memory, -m=数字[单位]

内存限制。单位可以是 b(字节)、k(Kibibytes)、m(Mebibytes)或 g(Gibibytes)。

允许限制容器可用的内存。如果主机支持交换内存,则 -m 内存设置可以大于物理 RAM。如果指定了 0 的限制(不使用 -m),则容器的内存不受限制。实际限制可能会向上取整到操作系统页面大小的倍数(该值非常大,即百万兆字节)。

此选项在 cgroups V1 无根系统上不受支持。

--memory-swap=数字[单位]

等于内存加交换的限制值。单位可以是 b(字节)、k(Kibibytes)、m(Mebibytes)或 g(Gibibytes)。

必须与 -m (--memory) 标志一起使用。参数值必须大于 -m (--memory) 的值。默认情况下,它设置为 --memory 值的两倍。

数字 设置为 -1 以启用无限交换。

此选项在 cgroups V1 无根系统上不受支持。

--name, -n

为克隆的 Pod 设置自定义名称。如果未指定,则默认名称为以下语法:<ORIGINAL_NAME>-clone

--pid=pid

设置 Pod 的 PID 模式。默认情况下是为 Pod 创建一个私有的 PID 命名空间。需要通过 --share 共享 PID 命名空间。

host: use the host’s PID namespace for the pod
ns: join the specified PID namespace
private: create a new namespace for the pod (default)

--restart=策略

容器退出时要遵循的重启策略。如果容器通过 podman killpodman stop 命令停止,则重启策略不会生效。

有效的 策略 值是

  • no : 退出时不重启容器

  • never : no 的同义词;退出时不重启容器

  • on-failure[:max_retries] : 当容器以非零退出代码退出时重启容器,无限次重试或直到达到可选的 max_retries 次数

  • always : 当容器退出时重启容器,无论状态如何,无限次重试

  • unless-stopped : 与 always 相同

Podman 提供一个 systemd unit 文件 podman-restart.service,该文件在系统重启后重启容器。

在 systemd 服务中运行容器时,请使用 systemd 提供的重启功能。换句话说,不要在容器单元中使用此选项,而是在 [Service] 部分设置 Restart= systemd 指令。请参阅 podman-systemd.unit(5) 和 systemd.service(5)。

Pod 中所有容器的默认重启策略。

--security-opt=选项

安全选项

  • apparmor=unconfined : 关闭容器的 AppArmor 限制

  • apparmor=alternate-profile : 设置容器的 AppArmor 限制配置文件

  • label=user:USER: 设置容器进程的用户标签

  • label=role:ROLE: 设置容器进程的角色标签

  • label=type:TYPE: 设置容器进程的类型标签

  • label=level:LEVEL: 设置容器进程的安全级别标签

  • label=filetype:TYPE: 设置容器文件的类型标签

  • label=disable: 关闭容器的标签隔离功能

注意: 可以通过在 containers.conf (/etc/containers/containers.conf$HOME/.config/containers/containers.conf) 文件中设置 label=false 来禁用所有容器的标签功能。

  • label=nested: 允许容器内修改 SELinux 标签。 容器可以修改文件和进程的 SELinux 标签,只要 SELinux 策略允许。 如果没有 nested,即使在主机上启用了 SELinux,容器也会将其视为已禁用。 容器被禁止设置任何标签。

  • mask=/path/1:/path/2: 用冒号分隔的要屏蔽的路径。 容器内无法访问屏蔽的路径。

  • no-new-privileges: 禁用容器进程获取额外权限。

  • seccomp=unconfined: 关闭容器的 Seccomp 限制

  • seccomp=profile.json: 用作 Seccomp 过滤器的 JSON 文件。 注意,io.podman.annotations.seccomp 注解将设置为指定的值,如 podman inspect 中所示。

  • proc-opts=OPTIONS : 用于 /proc 挂载点的选项的逗号分隔列表。 有关可能的挂载选项的更多详细信息,请参见 proc(5) 手册页。

  • unmask=ALL/path/1:/path/2,或 shell 展开的路径 (/proc/*): 用冒号分隔的要取消屏蔽的路径。 如果设置为 ALL,它会取消屏蔽默认情况下被屏蔽或设置为只读的所有路径。 默认屏蔽的路径是 /proc/acpi, /proc/kcore, /proc/keys, /proc/latency_stats, /proc/sched_debug, /proc/scsi, /proc/timer_list, /proc/timer_stats, /sys/firmware, 和 /sys/fs/selinux, /sys/devices/virtual/powercap。 默认只读的路径是 /proc/asound, /proc/bus, /proc/fs, /proc/irq, /proc/sys, /proc/sysrq-trigger, /sys/fs/cgroup

注意: 可以通过在 containers.conf(5) 文件中设置 label=false 来禁用所有容器的标签功能。

--shm-size=number[unit]

/dev/shm 的大小。 unit 可以是 b (字节), k (Kibibytes), m (Mebibytes), 或 g (Gibibytes)。 如果省略了单位,系统将使用字节。 如果省略了大小,默认值为 64m。 当 size0 时,容器使用 IPC 的内存大小不受限制。 此选项与 --ipc=host 冲突。

--shm-size-systemd=number[unit]

systemd 特定 tmpfs 挂载点的大小,例如 /run, /run/lock, /var/log/journal 和 /tmp。 unit 可以是 b (字节), k (Kibibytes), m (Mebibytes), 或 g (Gibibytes)。 如果省略了单位,系统将使用字节。 如果省略了大小,默认值为 64m。 当 size0 时,使用量将限制为主机可用内存的 50%。

--start

设置为 true 时,此标志将在克隆过程完成后启动新创建的容器。 容器内的所有容器都将启动。

--subgidname=name

在新的用户命名空间中运行容器,使用 /etc/subgid 文件中 name 对应的映射。 如果以非特权用户运行,则用户需要有权使用该映射。 请参见 subgid(5)。 此标志与 --userns--gidmap 冲突。

--subuidname=name

在新的用户命名空间中运行容器,使用 /etc/subuid 文件中 name 对应的映射。 如果以非特权用户运行,则用户需要有权使用该映射。 请参见 subuid(5)。 此标志与 --userns--uidmap 冲突。

--sysctl=name=value

为容器配置命名空间内核参数。

对于 IPC 命名空间,允许以下 sysctls

  • kernel.msgmax

  • kernel.msgmnb

  • kernel.msgmni

  • kernel.sem

  • kernel.shmall

  • kernel.shmmax

  • kernel.shmmni

  • kernel.shm_rmid_forced

  • 以 fs.mqueue.* 开头的 Sysctls

注意: 如果 IPC 命名空间在容器内没有共享,则不允许使用上述 sysctls。

对于网络命名空间,只允许以 net.* 开头的 sysctls。

注意: 如果网络命名空间在容器内没有共享,则不允许使用上述 sysctls。

--uidmap=container_uid:from_uid:amount

在新的用户命名空间中运行容器,使用提供的映射。 此选项与 --userns--subuidname 选项冲突。 此选项提供了一种将主机 UID 映射到容器 UID 的方法。 可以多次传递此选项来映射不同的范围。

--userns=mode

设置容器的用户命名空间模式。 它默认为 PODMAN_USERNS 环境变量。 空值 (“”) 表示禁用用户命名空间。

非特权用户 --userns=键映射

主机用户

容器用户

“”

$UID

0 (默认用户帐户映射到容器中的 root 用户。)

host

$UID

0 (默认用户帐户映射到容器中的 root 用户。)

keep-id

$UID

$UID (将用户帐户映射到容器内的相同 UID。)

auto

$UID

nil (主机用户 UID 未映射到容器中。)

nomap

$UID

nil (主机用户 UID 未映射到容器中。)

有效的 mode 值为

  • auto[:OPTIONS,…]: 自动创建一个命名空间。 可以将这些选项指定给 auto

    • gidmapping=CONTAINER_GID:HOST_GID:SIZE 强制在用户命名空间中存在 GID 映射。

    • size=SIZE: 为自动用户命名空间指定一个明确的大小。 例如 --userns=auto:size=8192。 如果没有指定 sizeauto 会估计用户命名空间的大小。

    • uidmapping=CONTAINER_UID:HOST_UID:SIZE 强制在用户命名空间中存在 UID 映射。

  • host: 在调用者的用户命名空间中运行。 在容器中运行的进程在主机上的权限与调用者启动的任何其他进程相同(默认)。

  • keep-id: 创建一个用户命名空间,其中当前非特权用户的 UID:GID 映射到容器中的相同值。 此选项不允许用于由 root 用户创建的容器。

  • nomap: 创建一个用户命名空间,其中当前非特权用户的 UID:GID 未映射到容器中。 此选项不允许用于由 root 用户创建的容器。

--uts=mode

设置容器的 UTS 命名空间模式。 支持以下值

  • host: 在容器内使用主机的 UTS 命名空间。

  • private: 为容器创建一个新的命名空间(默认)。

  • ns:[path]: 在给定的现有 UTS 命名空间中运行容器。

--volume, -v=[[SOURCE-VOLUME|HOST-DIR:]CONTAINER-DIR[:OPTIONS]]

创建一个绑定挂载点。 如果指定了 -v /HOST-DIR:/CONTAINER-DIR,Podman 会将主机上的 /HOST-DIR 绑定挂载到容器中的 /CONTAINER-DIR。 同样,-v SOURCE-VOLUME:/CONTAINER-DIR 会将主机上的命名卷挂载到容器中。 如果不存在这样的命名卷,Podman 会创建一个。 如果没有提供源,则会创建匿名命名卷,其名称是随机生成的,并在容器通过 --rm 标志或 podman rm --volumes 命令删除时被删除。

(注意,当使用远程客户端(包括 Mac 和 Windows (不包括 WSL2) 机器)时,卷是从远程服务器挂载的,而不是从客户端机器挂载的。)

OPTIONS 是一个逗号分隔的列表,可以是以下一个或多个

  • rw|ro

  • z|Z

  • [O]

  • [U]

  • [no]copy

  • [no]dev

  • [no]exec

  • [no]suid

  • [r]bind

  • [r]shared|[r]slave|[r]private[r]unbindable [1]

  • idmap[=options]

CONTAINER-DIR 必须是绝对路径,例如 /src/docs。 卷挂载到容器中的这个目录。

如果指定了卷源,它必须是主机上的路径或命名卷的名称。 主机路径可以是绝对的或相对的;相对路径相对于运行 Podman 的目录解析。 如果源不存在,Podman 会返回错误。 用户必须预先创建源文件或目录。

任何不以 ./ 开头的源都被视为命名卷的名称。如果不存在具有该名称的卷,则会创建它。使用名称创建的卷不是匿名的,并且不会被 --rm 选项和 podman rm --volumes 命令删除。

指定多个 -v 选项以将一个或多个卷挂载到 Pod 中。

写入 保护 挂载

添加 :ro:rw 选项以分别以只读或读写模式挂载卷。默认情况下,卷以读写模式挂载。请参阅示例。

更改所有权 挂载

默认情况下,Podman 不会更改挂载到容器中的源卷目录的所有者和组。如果在一个新的用户命名空间中创建了一个 Pod,则容器中的 UID 和 GID 可能对应于主机上的另一个 UID 和 GID。

:U 后缀告诉 Podman 根据 Pod 中的 UID 和 GID 使用正确的宿主 UID 和 GID,以递归地更改源卷的所有者和组。更改所有权会遍历卷下的文件系统,并更改每个文件的 UID/GID。如果卷有数千个 inode,此过程需要很长时间,从而延迟 Pod 的启动。

警告 请谨慎使用,因为这会修改宿主文件系统。

标记 挂载

像 SELinux 这样的标记系统要求在挂载到 Pod 中的卷内容上放置适当的标签。没有标签,安全系统可能会阻止 Pod 中运行的进程使用该内容。默认情况下,Podman 不会更改操作系统设置的标签。

要在 Pod 上下文中更改标签,请在卷挂载中添加以下两个后缀之一::z:Z。这些后缀告诉 Podman 重新标记共享卷上的文件对象。z 选项告诉 Podman 两个或多个 Pod 共享卷内容。因此,Podman 使用共享内容标签对内容进行标记。共享卷标签允许所有容器读写内容。Z 选项告诉 Podman 使用私有未共享标签对内容进行标记,只有当前 Pod 可以使用私有卷。注意:pod 中的所有容器共享相同的 SELinux 标签。这意味着该 Pod 中的所有容器都可以读写使用 :Z 在任何一个容器上创建的容器中共享的卷。重新标记会遍历卷下的文件系统,并更改每个文件的标签,如果卷有数千个 inode,此过程需要很长时间,从而延迟 Pod 的启动。如果卷之前使用 z 选项进行了重新标记,则 Podman 进行了优化,不会再次重新标记。如果将文件移动到卷中,则可以使用 chcon -Rt container_file_t PATH 命令手动更改标签。

注意:不要重新标记系统文件和目录。重新标记系统内容可能会导致机器上的其他受限服务失败。对于这些类型的容器,我们建议禁用 SELinux 隔离。选项 --security-opt label=disable 为 Pod 禁用 SELinux 隔离。例如,如果用户想要将整个主目录挂载到 Pod 中,则需要禁用 SELinux 隔离。

$ podman pod clone --security-opt label=disable -v $HOME:/home/user fedora touch /home/user/file

覆盖 挂载

:O 标志告诉 Podman 使用 overlay file system 将宿主中的目录挂载为临时存储。Pod 进程可以修改挂载点内的内容,这些内容存储在容器存储中的一个单独目录中。用覆盖术语来说,源目录是底层目录,容器存储目录是顶层目录。对挂载点的修改在 Pod 完成执行时会被销毁,类似于 tmpfs 挂载点被卸载。

对于高级用户,overlay 选项还支持覆盖挂载的自定义非易失性 upperdirworkdir。用户可以完全管理自定义 upperdirworkdir,Podman 不会在生命周期完成时将其删除。示例::O,upperdir=/some/upper,workdir=/some/work

容器的后续执行将看到原始源目录内容,前一次 Pod 执行的任何更改都不复存在。

覆盖挂载的一个用例是将宿主的包缓存共享到容器中,以加快构建速度。

注意:O 标志与上面列出的其他选项冲突。

挂载到容器中的内容使用私有标签进行标记。在 SELinux 系统上,源目录中的标签必须可供 Pod 基础设施容器标签读取。通常,容器可以读取/执行 container_share_t,并且可以读写 container_file_t。如果无法更改源卷上的标签,则必须为 Pod 或基础设施容器禁用 SELinux 容器隔离才能使其正常工作。

不要修改使用覆盖挂载挂载到 Pod 中的源目录,这会导致意外故障。只有在容器运行完成后才能修改该目录。

挂载 传播

默认情况下,绑定挂载的卷是 private。这意味着在 Pod 内完成的任何挂载都不会在主机上可见,反之亦然。可以通过指定卷挂载传播属性来更改此行为。当卷是 shared 时,在 Pod 内该卷下完成的挂载会在主机上可见,反之亦然。将卷设置为 slave[1] 仅启用单向挂载传播:在主机上该卷下完成的挂载在容器内可见,但反之亦然。

要控制卷的挂载传播属性,可以使用 [r]shared、[r]slave、[r]private 或 [r]unbindable 传播标志。仅对绑定挂载的卷指定传播属性,不适用于内部卷或命名卷。为了使挂载传播正常工作,源挂载点(源目录在该挂载点上挂载)必须具有正确的传播属性。对于共享卷,源挂载点必须是共享的。对于从属卷,源挂载点必须是共享的或从属的。[1]

要递归地将卷及其所有子挂载挂载到 Pod 中,请使用 rbind 选项。默认情况下使用 bind 选项,源目录的子挂载不会挂载到 Pod 中。

使用 copy 选项挂载卷会告诉 Podman 将内容从底层目标目录复制到新创建的内部卷上。copy 仅在卷的初始创建时发生。当卷随后在不同的容器上使用时,内容不会被复制。copy 选项在绑定挂载上被忽略,并且没有效果。

使用 nosuid 选项挂载卷意味着卷上的 SUID 可执行文件不能被应用程序用来更改其权限。默认情况下,卷使用 nosuid 挂载。

使用 noexec 选项挂载卷意味着卷上的任何可执行文件都不能在 Pod 中执行。

使用 nodev 选项挂载卷意味着卷上的任何设备都不能被 Pod 中的进程使用。默认情况下,卷使用 nodev 挂载。

如果 HOST-DIR 是一个挂载点,则内核会忽略 devsuidexec 选项。

使用 df HOST-DIR 找出源挂载,然后使用 findmnt -o TARGET,PROPAGATION source-mount-dir 找出源挂载的传播属性。如果 findmnt(1) 实用程序不可用,则可以在 /proc/self/mountinfo 中查看源挂载点的挂载条目。查看“可选字段”,看看是否指定了任何传播属性。其中,shared:N 表示挂载是共享的,master:N 表示挂载是从属的,如果没有任何内容,则挂载是私有的。[1]

要更改挂载点的传播属性,请使用 mount(8) 命令。例如,如果要绑定挂载源目录 /foo,则可以执行 mount --bind /foo /foomount --make-private --make-shared /foo。这会将 /foo 转换为共享挂载点。或者,可以直接更改源挂载的传播属性。假设 //foo 的源挂载,则使用 mount --make-shared // 转换为共享挂载。

注意:如果用户只能通过组访问权限,则从无根 Pod 内部访问卷将会失败。

ID映射 挂载

如果指定了 idmap,则会创建一个 ID 映射挂载到容器中的目标用户命名空间。idmap 选项支持与容器使用的用户命名空间不同的自定义映射。映射可以在 idmap 选项之后指定,例如:idmap=uids=0-1-10#10-11-10;gids=0-100-10。对于每个三元组,第一个值是映射到宿主上的第二个值的备份文件系统 ID 的起始位置。此映射的长度在第三个值中给出。多个范围用 # 分隔。

--volumes-from=CONTAINER[:OPTIONS]

从指定的容器挂载卷。用于在容器和 Pod 之间共享卷。options 是一个逗号分隔的列表,包含以下可用元素

  • rw|ro

  • z

将已挂载的源容器卷挂载到另一个 Pod 上。CONTAINER 可以是名称或 ID。要共享卷,请在运行目标容器时使用 --volumes-from 选项。即使源容器未运行,也可以共享卷。

默认情况下,Podman 会以与源容器中挂载相同的模式(读写或只读)挂载卷。可以通过添加 rorw 选项来更改此设置。

像 SELinux 这样的标签系统要求将适当的标签放置在挂载到 Pod 中的卷内容上。如果没有标签,安全系统可能会阻止容器内部运行的进程使用该内容。默认情况下,Podman 不会更改操作系统设置的标签。

要更改 Pod 上下文中的标签,请在卷挂载中添加 z。此后缀告诉 Podman 重新标记共享卷上的文件对象。 z 选项告诉 Podman 两个实体共享卷内容。因此,Podman 会使用共享内容标签标记该内容。共享卷标签允许所有容器读写内容。

如果源容器的卷位置与目标 Pod 上驻留的数据重叠,则该卷将隐藏目标上的该数据。

示例

将指定的 Pod 克隆到一个新的 Pod。

# podman pod clone pod-name
6b2c73ff8a1982828c9ae2092954bcd59836a131960f7e05221af9df5939c584

将指定的 Pod 克隆到一个新的 Pod,并使用一个新的名称。

# podman pod clone pod-name --name=cloned-pod
d0cf1f782e2ed67e8c0050ff92df865a039186237a4df24d7acba5b1fa8cc6e7
6b2c73ff8a1982828c9ae2092954bcd59836a131960f7e05221af9df5939c584

将指定的 Pod 克隆到一个新的 Pod,并删除该 Pod,同时修改其 CPU。

# podman pod clone --destroy --cpus=5 d0cf1
6b2c73ff8a1982828c9ae2092954bcd59836a131960f7e05221af9df5939c584

将指定的 Pod 克隆到一个新的命名 Pod。

# podman pod clone 2d4d4fca7219b4437e0d74fcdc272c4f031426a6eacd207372691207079551de new_name
5a9b7851013d326aa4ac4565726765901b3ecc01fcbc0f237bc7fd95588a24f9

另请参阅

podman-pod-create(1)

历史

2022 年 5 月,由 Charlie Doern 撰写 cdoern@redhat.com

脚注

1: Podman 项目致力于包容性,这是开源的核心价值观。这里使用的 masterslave 挂载传播术语存在问题,而且具有争议性,需要更改。但是,这些术语目前在 Linux 内核中使用,并且目前必须按原样使用。当内核维护人员纠正这种用法时,Podman 将立即随之更改。