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/，作为无根用户的默认目录是 ~/.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 选项为 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"]

此外，可以在 [network] 部分下的 containers.conf 中选择默认的无根网络工具，使用 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 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。