Podman 5.0 详细的重大变更

Podman 5.0 已发布,随之而来的是一些破坏性变更,但没有理由害怕它们;除非您正在使用 podman machine,否则您甚至可能不会注意到它们。

Podman Machine

最大的破坏性变更是对 podman machine 配置文件进行了重大重构。没有从旧格式到新格式的迁移。在 MacOS 上,出于对性能更优的 Apple hypervisor 的偏好,也已移除对 qemu 提供程序的支持。有关 machine 变更的更多详细信息,请参阅 Brent Baude 的这篇帖子

CNI 移除

在 Podman 4.0 中,我们引入了新的网络后端 netavark 来配置容器网络,从那时起,我们默认使用 netavark 而不是 CNI。然而,从 3.X 及更早版本更新的用户并未迁移到 netavark,因此他们继续使用 CNI。由于尝试与两个工具协同工作会增加支持负担,Podman 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 环境变量。

Pasta 默认用于无根网络

默认的无根网络工具已从 slirp4netns 切换到 pasta。它应该提供更好的性能和更多功能。因此,如果您将无根容器与网络一起使用,则需要确保已安装 pasta(passt 软件包的一部分)。虽然我认为这对于许多人来说不一定是破坏性变更,但对于某些用户来说可能是。在 4.X 上使用默认网络选项创建的无根容器,即使在升级后仍将继续使用 slirp4netns 作为网络工具,因为网络模式是在创建容器时设置的,因此如果您希望旧容器继续工作,您需要确保在这种情况下升级后 slirp4netns 仍然已安装。

Pasta 默认不执行网络地址转换 (NAT),并将主接口的 IP 地址复制到容器命名空间中。为此,pasta 将选择具有默认路由的接口。如果 pasta 找不到具有默认路由的接口,它将选择一个接口(如果只有一个具有有效路由的接口)。如果您没有默认路由,并且有多个接口定义了路由,pasta 将无法找出正确的接口,并且将无法启动。在这种情况下,用户需要使用 -i 选项指定要使用的接口,因为 Podman 启动 pasta,用户不能直接这样做。可以在 containers.conf 中设置一组默认的 pasta 选项,pasta_options 键接受一个选项数组(它们对应于 pasta cli 选项,请参阅 pasta(1) 手册页)。 

[network]
pasta_options = ["-i", "eth0"]

默认情况下,将无法通过 eth0(或您的主接口的名称)IP 连接到主机,因为容器中使用了完全相同的 IP,因此不会路由到外部。这可能会给 host.containers.internal 名称条目的用户带来问题,因为我们依赖于主机 IP 可以访问。对于 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 可以设置为 pasta 或 slirp4netns。因此,如果您遇到错误,可以随时恢复到 slirp4netns。

[network]
default_rootless_network_cmd = "slirp4netns"

Podman Inspect

Podman inspect 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 Inspect

podman pod inspect 命令现在始终输出一个数组而不是单个对象。这样做是为了提高与其他执行相同操作的 inspect 命令的一致性。如果您解析 podman pod inspect JSON,则必须更新它以使用第一个数组元素。

容器统计 API

libpod stats 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 annotatepodman manifest add
  • --configmap--log-opt--annotation 用于 podman kube play
  • --pubkeysfile 用于 podman image trust set
  • --encryption-key--decryption-key 用于 podman createpodman runpodman pushpodman 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 createpodman run
  • --hooks-dir--module 作为全局 podman 选项。

此更改的原因是为了允许在它们的值中使用逗号,而不是将其解释为分隔符。例如,如果我的注释包含逗号设置 --annotation key=val,withcomma,它会导致错误,因为它试图将 withcomma 解析为第二个注释。因此,除非您依赖逗号作为分隔符,否则此更改不应影响您。否则,您需要为每个值多次提供选项,即 --annotation key1=val1 --annotation key2=val2

“Podman 5.0 破坏性变更详情”的一条回复

  1. Gael Avatar

    Pasta 确实很糟糕……当所有我看到的是容器因为网络未准备好而启动失败时,获得“更多功能”和“更好的性能”有什么意义?

    你无法想象今天向管理层演示 Fedora CoreOS 的使用是多么令人沮丧,而且我的新部署随机失败,因为 pasta 显然无法协调并等待网络准备好监听这些接口。

    会议结果是“这令人印象深刻,让我们使用它,但让我们继续使用 Ubuntu Pro”。

发表评论

订阅

输入您的电子邮件地址以接收来自本网站的电子邮件更新。

返回

您的消息已发送

警告
警告
警告。

分类


搜索