基于 Kubernetes YAML 创建容器、pod 和卷

概要

podman kube play [选项] file.yml|-|https://demo.io/file.yml

描述

podman kube play 读取 Kubernetes YAML 结构化文件。它会重新创建 YAML 中描述的容器、pod 或卷。在 pod 内的容器启动后，将输出新 Pod 的 ID 或新卷的名称。如果 YAML 文件指定为 "-"，则 podman kube play 将从标准输入读取 YAML 文件。

输入也可以是指向 YAML 文件的 URL，例如 https://podman.io/demo.yml。`podman kube play` 将从 URL 读取 YAML 并从中创建 pod 和容器。

使用 --down 命令行选项，它还能够拆除之前通过 podman kube play 运行创建的 pod。

使用 --replace 命令行选项，它将拆除之前通过 podman kube play 运行创建的 pod（如果有的话），并使用 Kubernetes YAML 文件重新创建 pod。

理想情况下，输入文件是由 Podman 命令创建的（参见 podman-kube-generate(1)）。这保证了平滑的导入和预期的结果。

目前支持的 Kubernetes 类型有：

• Pod
• Deployment
• PersistentVolumeClaim
• ConfigMap
• Secret
• DaemonSet

Kubernetes Pods 或 Deployments

kube play 仅支持三种卷类型，即 hostPath、emptyDir 和 persistentVolumeClaim 卷类型。

• 当使用 hostPath 卷类型时，仅支持 default (empty)、DirectoryOrCreate、Directory、FileOrCreate、File、Socket、CharDevice 和 BlockDevice 子类型。Podman 将 hostPath path 的值解释为文件路径，当其中包含至少一个正斜杠时；否则，Podman 将该值视为命名卷的名称。

• 当使用 persistentVolumeClaim 时，claimName 的值是 Podman 命名卷的名称。

• 当使用 emptyDir 卷时，Podman 会创建一个匿名卷，该卷附加到在 pod 中运行的容器，并在 pod 被删除后自动删除。

注意：容器的默认重启策略是 always。您可以通过在规范中设置 restartPolicy 字段来更改默认值。

注意：当使用带有 init 容器的 kube YAML 时，init 容器会以 once 类型值创建。要更改默认类型，请使用 io.podman.annotations.init.container.type 注解将类型设置为 always。

注意：kube play 创建的 hostPath 卷类型会被赋予一个 SELinux 共享标签（z），而绑定挂载不会被重新标记（使用 chcon -t container_file_t -R <directory>）。

注意：要为 pod 设置用户命名空间，请在 pod/deployment 定义中使用 io.podman.annotations.userns 注解。这可以通过 --userns 标志覆盖。

注意：使用 io.podman.annotations.volumes-from 注解将一个容器的卷绑定挂载到另一个容器。您可以将多个源容器的卷挂载到目标容器。属于同一 pod 的源容器必须在 kube YAML 中定义在目标容器之前。注解的格式为 io.podman.annotations.volumes-from/targetContainer: "sourceContainer1:mountOpts1;sourceContainer2:mountOpts2"。

注意：如果使用 :latest 标签，Podman 会尝试从注册表中拉取镜像。如果镜像是在本地使用 Podman 或 Buildah 构建的，它的域名为 localhost，在这种情况下，即使镜像有 :latest 标签，Podman 也会使用本地存储中的镜像。

注意：命令 podman play kube 是 podman kube play 的别名，执行相同的功能。

注意：可以使用 podman kube down 命令停止和删除基于相同 Kubernetes YAML 创建的 pod 或容器，该 YAML 由 podman kube play 使用。

注意：要自定义在 podman kube play 期间创建的 infra 容器的名称，请在 pod 定义中使用 io.podman.annotations.infra.name 注解。当从使用 --infra-name 标志创建的 pod 生成 kube yaml 时，此注解会自动设置。

Kubernetes PersistentVolumeClaims

Kubernetes PersistentVolumeClaim 代表 Podman 命名卷。Podman 仅需要 PersistentVolumeClaim 名称来创建卷。Kubernetes 注解可用于利用 Podman 卷的可用选项。

• volume.podman.io/driver
• volume.podman.io/device
• volume.podman.io/type
• volume.podman.io/uid
• volume.podman.io/gid
• volume.podman.io/mount-options
• volume.podman.io/import-source
• volume.podman.io/image

使用 volume.podman.io/import-source 将注解值中指定的 tar 包（.tar, .tar.gz, .tgz, .bzip, .tar.xz, .txz）的内容导入到创建的 Podman 卷中。

Kube play 能够根据正确的目录布局和 Containerfiles 实时构建镜像。然而，这个选项对于远程客户端（包括 Mac 和 Windows（不包括 WSL2）机器）尚不可用。请考虑以下 YAML 文件中的摘录：

apiVersion: v1
kind: Pod
metadata:
...
spec:
  containers:
  - name: container
    image: foobar
...

在当前工作目录中存在一个名为 foobar 的目录，其中包含名为 Containerfile 或 Dockerfile 的文件时，Podman kube play 会构建该镜像并将其命名为 foobar。以下是该示例的目录结构示例： 这个 YAML 片段定义了一个 Kubernetes Pod，其中包含一个名为 container 的容器，该容器将使用 foobar 镜像。如果您想要 Podman 使用 kube play 功能来启动这个 Pod，并实时构建 foobar 镜像（如果它不存在于本地存储中），您需要确保本地目录结构符合 Podman 的期望，并包含相应的 Containerfile（或 Dockerfile）来描述如何构建该镜像。然而，请注意，实时构建功能在远程客户端上可能不可用，这取决于您的具体设置和操作系统。

|- mykubefiles
    |- myplayfile.yaml
    |- foobar
         |- Containerfile

构建过程中，foobar 目录被视为构建上下文目录。如果本地存储中已经存在一个名为 foobar 的镜像，则不会重新构建该镜像，除非使用了 --build 标志。使用 --build=false 可以完全禁用构建过程。

Kubernetes ConfigMap

Kubernetes ConfigMap 可以作为 Pods 或 Deployments 中环境变量或卷的来源。在 Podman 中，ConfigMap 并不是一个独立的对象；相反，当容器使用 ConfigMap 时，Podman 会根据需要创建环境变量或卷。

例如，下面的 YAML 文档定义了一个 ConfigMap 并在 Pod 中使用它：

apiVersion: v1
kind: ConfigMap
metadata:
  name: foo
data:
    FOO: bar
---
apiVersion: v1
kind: Pod
metadata:
  name: foobar
spec:
  containers:
  - name: container-1
    image: foobar
    envFrom:
    - configMapRef:
        name: foo
        optional: false

结果，对于 container-1 容器，环境变量 FOO 被设置为 bar。

Kubernetes Secret

Kubernetes Secret 代表 Podman 命名的 secret。Kubernetes Secret 会整体保存，并可作为 Pods 或 Deployments 中环境变量或卷的来源。

例如，下面的 YAML 文档定义了一个 Secret 并在 Pod 中使用它：

kind: Secret
apiVersion: v1
metadata:
  name: foo
data:
  foo: YmFy # bar 的 base64 编码
---
apiVersion: v1
kind: Pod
metadata:
  name: foobar
spec:
  containers:
  - name: container-1
    image: foobar
    env:
    - name: FOO
      valueFrom:
        secretKeyRef:
          name: foo
          key: foo

结果，对于 container-1 容器，环境变量 FOO 被设置为 bar。请注意，Secret 数据通常以 base64 编码形式存储，在上述示例中，YmFy 是 bar 的 base64 编码。

选项说明

选项	说明
--annotation	为 Pod 或其资源添加注解。注解是键值对，用于存储有关资源的额外信息，但不直接影响资源的行为。
--container	指定与选项相关的容器。这可能用于选择或操作特定的容器实例。
--authfile	指定认证文件的路径，用于认证到容器镜像仓库等服务的访问。
--build	即使镜像在本地存储中已经存在，也构建镜像。使用 --build=false 完全禁用构建。此选项不适用于远程 Podman 客户端。
--cert-dir	指定证书目录的路径，用于存放与 TLS 相关的证书和密钥文件。
--configmap	使用位于指定路径的 Kubernetes ConfigMap YAML 文件，为容器内的环境变量值提供来源。此选项不适用于远程 Podman 客户端。
--context-dir	使用指定的路径作为每个镜像的构建上下文目录。这通常是包含 Dockerfile 和其他构建文件的目录。需要 --build 选项为 true。此选项不适用于远程 Podman 客户端。
--creds	指定用于访问容器镜像仓库的凭证信息，通常包括用户名和密码。
--force	强制执行某些操作，如销毁与 PersistentVolumeClaims 关联的卷，即使这些操作可能导致数据丢失或其他不良后果。
--help, -h	显示帮助信息，包括可用选项和它们的基本描述。
--ip	为 Pod 分配一个静态 IP 地址。当创建多个 Pod 时，可以多次指定此选项，以确保每个 Pod 都有一个唯一的 IP 地址。
--log-driver	设置用于容器日志的驱动程序。不同的驱动程序可能具有不同的日志收集、存储和转发机制。
--log-opt	为日志驱动程序提供额外的配置选项。这些选项取决于所选的日志驱动程序，并允许用户进一步定制日志的行为。
--mac-address	为 Pod 分配一个静态 MAC 地址。当 kube play 创建多个 Pod 时，可以多次指定此选项。注意：当加入多个网络时，使用 --network name:mac=<mac> 语法。
--network	如果没有指定网络选项，并且在 YAML 文件中没有配置 host 网络模式，则会创建一个新的网络堆栈，并将 Pod 附加到它上面，从而实现 Pod 之间的通信。
--no-hosts	此选项与 Kubernetes YAML 中添加的主机冲突。
--publish	定义或覆盖 YAML 文件中的端口定义。YAML 文件和命令行中的端口列表被合并。匹配是通过使用 containerPort 字段进行的。如果 containerPort 既存在于 YAML 文件中又存在于选项中，则后者优先。
--publish-all	设置此选项为 true 将把所有端口暴露给主机，即使仅在 K8 YAML 中通过 containerPort 指定。在哪些端口将被暴露方面，--publish 的优先级高于 hostPort，hostPort 的优先级又高于 containerPort。如果设置为 false（这是默认值），则只有通过 hostPort 或 --publish 定义的端口才会在主机上发布。
--quiet, -q	在拉取镜像时抑制输出信息。
--replace	销毁由之前运行的 kube play 创建的 Pod 并重新创建 Pod。此选项用于根据 Kubernetes YAML 保持现有 Pod 的最新状态。
--seccomp-profile-root	seccomp 配置文件的目录路径（默认值："/var/lib/kubelet/seccomp"）。此选项不适用于远程 Podman 客户端，包括 Mac 和 Windows（不包括 WSL2）机器。
--start	在创建 Pod 后启动它，设置为 false 则仅创建它。
--tls-verify	启用 TLS 验证（通常用于与远程服务器通信时的安全连接）。
--userns.container	指定用户命名空间模式来运行容器。这通常用于控制容器内的用户权限和隔离。
--replace	销毁由之前运行的 kube play 创建的 Pod 并重新创建 Pod。此选项用于根据 Kubernetes YAML 保持现有 Pod 的最新状态。
--seccomp-profile-root	seccomp 配置文件的目录路径（默认值："/var/lib/kubelet/seccomp"）。此选项不适用于远程 Podman 客户端，包括 Mac 和 Windows（不包括 WSL2）机器。
--start	在创建 Pod 后启动它，设置为 false 则仅创建它。
--tls-verify	启用 TLS 验证（通常用于与远程服务器通信时的安全连接）。
--userns.container	指定用户命名空间模式来运行容器。这通常用于控制容器内的用户权限和隔离。
--wait, -w	在前台运行 Pod 和容器。默认值为 false。在另一个 shell 中，您可以随时运行 podman pod ps 来查看正在运行的 Pod 和容器的列表。当以 tty 模式附加时，您可以通过按 Ctrl-C 或接收任何其他中断信号来终止 Pod 和容器。通过 podman kube play 创建的所有 Pod、容器和卷在退出时都会被移除。

请注意，这个表格是基于您提供的选项描述生成的，并可能需要根据您所使用的 Podman 和 Kubernetes 的具体版本和上下文进行调整。为了获得最准确和最新的信息，请查阅官方文档。

示例

下面是 podman kube play 命令的一些使用示例：

根据指定的主机 YAML 文件重新创建 Pod 和容器

$ podman kube play demo.yml
52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6

根据发送到 stdin 的 YAML 文件重新创建 Pod 和容器

$ cat demo.yml | podman kube play -
52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6

销毁指定的 YAML 文件中描述的 Pod 和容器

$ podman kube play --down demo.yml
Pods stopped:
52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6
Pods removed:
52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6

提供多个 configmap 文件作为指定 Pod 和容器内的环境变量源

$ podman kube play demo.yml --configmap configmap-foo.yml,configmap-bar.yml
52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6

$ podman kube play demo.yml --configmap configmap-foo.yml --configmap configmap-bar.yml
52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6

创建一个连接到两个网络的 Pod，每个网络都有静态 IP

$ podman kube play demo.yml --network net1:ip=10.89.1.5 --network net2:ip=10.89.10.10
52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6

请注意，必须先使用 podman-network-create(1) 命令创建网络。

从指向 YAML 文件的 URL 创建和销毁 Pod

$ podman kube play https://podman.io/demo.yml
52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6

$ podman kube play --down https://podman.io/demo.yml
Pods stopped:
52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6
Pods removed:
52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6

如果指向的 YAML 文件被更改或修改，podman kube play --down 将不会从 URL 正常工作。

更多关于 Kubernetes 支持的信息，请查看：kubernetes_support

另请参阅

• podman(1): Podman 主命令的文档，用于管理容器和 Pods。
• podman-kube(1): Podman 的 Kubernetes 支持命令，用于生成 Kubernetes YAML 描述文件。
• podman-kube-down(1): Podman 的 Kubernetes 支持命令，用于销毁由 podman kube play 创建的 Pods 和容器。
• podman-network-create(1): Podman 的网络管理命令，用于创建新的容器网络。
• podman-kube-generate(1): Podman 的 Kubernetes 支持命令，用于从现有的容器和 Pods 生成 Kubernetes YAML 描述文件。
• podman-build(1): Podman 的构建命令，用于构建容器镜像。
• containers-certs.d(5): 容器镜像证书的目录格式文档，描述了如何管理和使用容器镜像的证书。