Podman 5.0 已发布,并且还包含一些重大变更,但无需害怕;除非您使用的是 podman machine,否则您可能根本不会注意到它们。
Podman Machine
最大的重大变更是对 podman machine 配置文件进行了重大重构。从旧格式到新格式没有迁移。在 macOS 上,对 qemu 提供程序的支持也已被删除,转而使用性能更高的 Apple hypervisor。有关机器更改的更多详细信息,请参阅 Brent Baude 的 这篇博文。
CNI 删除
在 Podman 4.0 中,我们引入了新的网络后端 netavark 来配置容器网络,从那时起,我们将 netavark 设为默认选项,而不是 CNI。但是,从 3.X 及更早版本升级的用户没有迁移到 netavark,因此他们继续使用 CNI。在 5.0 中,我们将只支持 netavark,因为尝试使用两种工具会导致支持负担增加。CNI 支持仍然受构建标签 (cni
) 保护,并在我们仍然需要它的发行版(如 RHEL 9 和 FreeBSD)上启用,但如果 CNI 集成出现问题,请不要指望上游维护人员提供任何帮助。
用户可以使用 podman info --format {{.Host.NetworkBackend}}
命令检查他们使用的是什么后端,它将打印 netavark 或 cni。如果是 netavark,则无需担心任何事。一切将继续像以前一样工作。对于 cni,可能需要手动干预。如果您不关心您的容器,您可以运行 podman system reset,它将删除所有内容。否则,使用 podman network ls
检查您是否定义了任何自定义网络。如果没有,则更新应该不会造成太多问题,尽管强烈建议重新启动以防止任何旧的临时网络接口/防火墙规则干扰 netavark。如果您确实有自定义网络,它们都将在升级时丢失,因此需要手动迁移。
假设网络只是通过 podman network create
创建的,那么一种迁移方法是使用此单行命令将所有旧的 cni 配置保存在新的 netavark 格式中
for name in $(podman network ls -q); do podman network inspect --format "{{json .}}" "$name" > "$name.json"; done
此命令必须在仍然使用 Podman 4.* 时执行。它将在您的当前目录中创建一堆 .json 文件,一旦您更新到 Podman 5.0,您只需将这些文件移动到网络配置文件目录即可。作为 root 的默认位置是 /etc/containers/networks/
,作为 rootless 的默认位置是 ~/.local/share/containers/storage/networks/
。然后确认 podman network ls
显示了这些网络。或者,您也可以使用 podman network create
命令重新创建网络。
Cgroups v1 弃用
对具有 cgroups v1 的系统的支持已弃用,将在将来的版本中删除。请迁移到 cgroups v2。大多数发行版已经迁移,因此我们预计不会有太多用户受到影响。在 cgroups v1 系统上,将为每个 podman 命令打印警告。要关闭警告,请设置 PODMAN_IGNORE_CGROUPSV1_WARNING
环境变量。
rootless 网络的 Pasta 默认值
默认的 rootless 网络工具已从 slirp4netns 切换到 pasta。它应该提供更好的性能和更多功能。因此,如果您使用具有网络的 rootless 容器,则需要确保安装了 pasta(passt 包的一部分)。虽然我不认为这对许多人来说一定是重大变更,但对某些用户来说可能是。在 4.X 上使用默认网络选项创建的 rootless 容器将在升级后继续使用 slirp4netns 作为网络工具,因为网络模式是在创建容器时设置的,因此如果您想让您的旧容器继续工作,则需要确保在升级后仍然安装了 slirp4netns。
Pasta 默认情况下不执行网络地址转换 (NAT),并将您主接口的 IP 地址复制到容器命名空间。为此,pasta 将选择具有默认路由的接口。如果 pasta 找不到具有默认路由的接口,它将选择一个接口,前提是只有一个接口具有有效路由。如果您没有默认路由,并且多个接口定义了路由,则 pasta 将无法确定正确的接口,并且将无法启动。在这种情况下,用户需要使用 -i 选项为 pasta 指定要使用的接口,因为 Podman 启动了 pasta,用户无法直接执行此操作。可以在 containers.conf 中设置一组默认的 pasta 选项,pasta_options 键接受一个选项数组(它们对应于 pasta cli 选项,请参阅 pasta(1) 手册页)。
[network]
pasta_options = ["-i", "eth0"]
默认情况下,无法通过 eth0(或您的主接口的名称)IP 连接到主机,因为容器中使用了完全相同的 IP,因此不会路由到外部。这可能会给主机用户带来问题。因为我们依赖于主机 IP 可以访问,所以会出现 host.containers.internal 名字条目问题。对于 Podman 5.0.0,此条目可能包含无效的 IP,但我们正在为 Podman 5.0.1 修复此问题。但是,如果您只有一个主机 IP(不包括 localhost),则如果容器始终使用相同的 IP,则将无法路由到该 IP,因此底层问题将仍然存在。一个解决方法是在容器中告诉 pasta 使用另一个地址。在这种情况下,在 containers.conf 中设置类似以下内容
[network]
pasta_options = ["-a", "10.0.2.0", "-n", "24", "-g", "10.0.2.2", "--dns-forward", "10.0.2.3"]
此外,可以在 containers.conf 中的 [network] 部分使用 default_rootless_network_cmd 选择默认的 rootless 网络工具,该工具可以设置为 pasta 或 slirp4netns。因此,如果您遇到错误,您始终可以恢复到 slirp4netns。
[network]
default_rootless_network_cmd = "slirp4netns"
Podman 检查
podman 检查 JSON 输出中的一些字段已更改,以更好地匹配 Docker 输出。Config.Entrypoint 字段已从字符串更改为数组,因为它可以保存多个参数。以前,这些参数将以空格分隔,这对解析不利。Config.StopSignal 字段现在是字符串,而不是整数。因此,它不再返回信号编号,而是返回信号名称。这对我们人类来说更易于阅读,并且更利于跨平台兼容性,因为不同平台之间的信号编号可能不同。最后,如果容器没有定义健康检查,则 State.Health 字段将不再显示。相同的更改适用于 libpod REST API。两个版本之间的差异看起来像这样
23,27d22
< "Health": {
< "Status": "",
< "FailingStreak": 0,
< "Log": null
< },
145c140,142
< "Entrypoint": "sh",
---
> "Entrypoint": [
> "sh"
> ],
149c146
< "StopSignal": 15,
---
> "StopSignal": "SIGTERM",
Podman Pod 检查
podman pod inspect 命令现在始终输出数组,而不是单个对象。这样做是为了提高与其他执行相同操作的检查命令的一致性。如果您解析 podman pod inspect
JSON,则必须更新它以使用第一个数组元素。
容器统计信息 API
libpod 统计信息 API 已更改为返回每个接口的网络统计信息。包含所有接口总和的单个 NetInput 和 NetOutput 字段已删除,取而代之的是添加了一个 Network 字段,该字段包含一个映射/对象,其键为接口名称,值为此接口的统计信息。
"Network":{"eth0":{"RxBytes":3740,"RxDropped":0,"RxErrors":0,"RxPackets":42,"TxBytes":3036,"TxDropped":0,"TxErrors":0,"TxPackets":34}}
这为用户提供了更多信息。
Podman 命令行标志
接受数组的许多 Podman CLI 选项的解析已更改,不再接受以字符串分隔的列表。
这些选项是
--annotation
用于podman manifest annotate
和podman manifest add
--configmap
、--log-opt
和--annotation
用于podman kube play
--pubkeysfile
用于podman image trust set
--encryption-key
和--decryption-key
用于podman create
、podman run
、podman push
和podman pull
--env-file
用于podman exec
--bkio-weight-device
、--device-read-bps
、--device-write-bps
、--device-read-iops
、--device-write-iops
、--device
、--label-file
、--chrootdirs
、--log-opt
和--env-file
用于podman create
和podman run
--hooks-dir
和--module
作为全局podman
选项。
进行此更改的原因是允许在值中使用逗号,而不是将其解释为分隔符。例如,如果我的注释包含一个逗号,设置 --annotation key=val,withcomma
,它将导致错误,因为它试图将 withcomma
解析为第二个注释。因此,除非您依赖于逗号作为分隔符,否则此更改不应影响您。否则,您需要为每个值多次提供该选项,即 --annotation key1=val1 --annotation key2=val2
。
回复 George取消回复