名称

podman-container-clone - 创建现有容器的副本

简介

podman container clone [options] container name image

描述

podman container clone 创建容器的副本，使用相同的配置重新创建原始容器。此命令需要三个参数：第一个是要克隆的容器 ID 或名称；此命令中的第二个参数可以更改克隆容器的名称（默认为 $ORIGINAL_NAME-clone）；第三个是克隆容器中要使用的新镜像。

选项

--blkio-weight=weight

块 IO 相对权重。weight 是介于 10 和 1000 之间的值。

在 cgroups V1 的无根（rootless）系统上不支持此选项。

--blkio-weight-device=device:weight

块 IO 相对设备权重。

--cpu-period=limit

为完全公平调度器（CFS）设置 CPU 周期，这是一个以微秒为单位的时长。一旦容器的 CPU 配额用尽，它将不会被调度运行，直到当前周期结束。默认为 100000 微秒。

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

在 cgroups V1 的无根（rootless）系统上不支持此选项。

如果未指定，则使用原始容器的 CPU 周期。

--cpu-quota=limit

限制 CPU 完全公平调度器（CFS）的配额。

限制容器的 CPU 使用。默认情况下，容器以全部 CPU 资源运行。限制是一个以微秒为单位的数字。如果提供了一个数字，则允许容器使用该 CPU 时间，直到 CPU 周期结束（可通过 --cpu-period 控制）。

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

在 cgroups V1 的无根（rootless）系统上不支持此选项。

如果未指定，则使用原始容器的 CPU 配额。

--cpu-rt-period=microseconds

限制 CPU 实时周期（微秒）。

限制容器的实时 CPU 使用。此选项告诉内核将容器的实时 CPU 使用限制在指定的时间段内。

此选项仅在 cgroups V1 rootful 系统上受支持。

如果未指定，则使用原始容器的 CPU 运行时周期。

--cpu-rt-runtime=microseconds

限制 CPU 实时运行时间（微秒）。

限制容器的实时 CPU 使用。此选项告诉内核限制在给定 CPU 周期内实时任务可能消耗的时间。例如：周期为 1,000,000 微秒，运行时为 950,000 微秒，这意味着此容器可以消耗 95% 的可用 CPU，并将剩余的 5% 留给普通优先级任务。

所有容器的运行时总和不能超过分配给父 cgroup 的量。

此选项仅在 cgroups V1 rootful 系统上受支持。

--cpu-shares, -c=shares

CPU 份额（相对权重）。

默认情况下，所有容器获得相同比例的 CPU 周期。可以通过更改容器的 CPU 份额权重相对于所有运行中容器的总权重来修改此比例。默认权重为 1024。

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

例如，考虑三个容器，一个的 CPU 份额为 1024，另外两个的 CPU 份额设置为 512。当所有三个容器中的进程都尝试使用 100% 的 CPU 时，第一个容器获得总 CPU 时间的 50%。如果添加一个 CPU 份额为 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 的无根（rootless）系统上不支持此选项。

如果未指定，则使用原始容器的 CPU 份额。

--cpus

为容器设置 CPU 数量，这将覆盖原始容器的 CPU 限制。如果未指定，则使用原始容器的 Nano CPU。

这是 --cpu-period 和 --cpu-quota 的简写，因此只能设置 --cpus 或 --cpu-period 和 --cpu-quota 选项中的两者。

在 cgroups V1 的无根（rootless）系统上不支持此选项。

--cpuset-cpus=number

允许执行的 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 的无根（rootless）系统上不支持此选项。

如果未指定，则使用原始容器的 CPUset。

--cpuset-mems=nodes

允许执行的内存节点（MEMs）（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 的无根（rootless）系统上不支持此选项。

如果未指定，则使用原始容器的 CPU 内存节点。

--destroy

克隆后移除用于模拟配置的原始容器。

--device-read-bps=path:rate

限制从设备读取速率（每秒字节数）（例如 --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 的无根（rootless）系统上不支持此选项。

--device-write-bps=path:rate

限制写入设备速率（每秒字节数）（例如 --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 的无根（rootless）系统上不支持此选项。

--force, -f

强制移除正在克隆的原始容器。只能与 --destroy 结合使用。

--memory, -m=number[unit]

内存限制。unit 可以是 b (字节)，k (千字节)，m (兆字节)，或 g (吉字节)。

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

在 cgroups V1 的无根（rootless）系统上不支持此选项。

如果未指定内存限制，则使用原始容器的内存限制。

--memory-reservation=number[unit]

内存软限制。unit 可以是 b（字节）、k（千字节）、m（兆字节）或 g（千兆字节）。

设置内存预留后，当系统检测到内存争用或内存不足时，容器将被强制将其消耗限制在其预留范围内。因此，始终将该值设置在 --memory 以下，否则硬限制将优先。默认情况下，内存预留与内存限制相同。

在 cgroups V1 的无根（rootless）系统上不支持此选项。

如果未指定，内存预留与正在克隆的容器的内存限制相同。

--memory-swap=number[unit]

一个等于内存加交换空间的限制值。unit 可以是 b (字节)，k (千字节)，m (兆字节)，或 g (吉字节)。

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

将 number 设置为 -1 以启用无限制的交换空间。

在 cgroups V1 的无根（rootless）系统上不支持此选项。

如果未指定，则使用正在克隆的容器来推导交换值。

--memory-swappiness=number

调整容器的内存交换行为。接受介于 0 和 100 之间的整数。

此标志仅在 cgroups V1 rootful 系统上受支持。

--name

为克隆的容器设置自定义名称。如果未指定，默认语法为：<ORIGINAL_NAME>-clone

--pod=name

将容器克隆到现有 Pod 中。这有助于将容器移动到现有 Pod。容器会加入 Pod 共享的命名空间，并丢失与共享命名空间冲突的配置。

--run

如果设置为 true，此标志在克隆过程完成后运行新创建的容器，这指定了分离运行模式。

示例

将指定容器克隆到新容器中

# podman container clone d0cf1f782e2ed67e8c0050ff92df865a039186237a4df24d7acba5b1fa8cc6e7
6b2c73ff8a1982828c9ae2092954bcd59836a131960f7e05221af9df5939c584

将指定容器克隆到新命名的容器中

# podman container clone --name=clone d0cf1f782e2ed67e8c0050ff92df865a039186237a4df24d7acba5b1fa8cc6e7
6b2c73ff8a1982828c9ae2092954bcd59836a131960f7e05221af9df5939c584

将具有选定资源约束的指定容器替换到新容器中，并移除原始容器

# podman container clone --destroy --cpus=5 d0cf1f782e2ed67e8c0050ff92df865a039186237a4df24d7acba5b1fa8cc6e7
6b2c73ff8a1982828c9ae2092954bcd59836a131960f7e05221af9df5939c584

克隆指定容器，赋予新名称，然后将原始容器的镜像替换为指定的镜像名称

# podman container clone 2d4d4fca7219b4437e0d74fcdc272c4f031426a6eacd207372691207079551de new_name fedora
Resolved "fedora" as an alias (/etc/containers/registries.conf.d/shortnames.conf)
Trying to pull registry.fedoraproject.org/fedora:latest...
Getting image source signatures
Copying blob c6183d119aa8 done
Copying config e417cd49a8 done
Writing manifest to image destination
Storing signatures
5a9b7851013d326aa4ac4565726765901b3ecc01fcbc0f237bc7fd95588a24f9

另请参阅

podman-create(1), cgroups(7)

历史

2022 年 1 月，最初由 Charlie Doern cdoern@redhat.com 撰写