NAME¶ 名称

podman-kube-play - Create containers, pods and volumes based on Kubernetes YAML
podman-kube-play - 根据 Kubernetes YAML 创建容器、Pod 和卷

SYNOPSIS¶ 概要

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

DESCRIPTION¶ 描述

podman kube play reads in a structured file of Kubernetes YAML. It recreates the containers, pods, or volumes described in the YAML. Containers within a pod are then started, and the ID of the new Pod or the name of the new Volume is output. If the YAML file is specified as “-”, then podman kube play reads the YAML file from stdin. The input can also be a URL that points to a YAML file such as https://podman.io/demo.yml. podman kube play reads the YAML from the URL and create pods and containers from it.
podman kube play 读取 Kubernetes YAML 的结构化文件。它会重新创建在 YAML 中描述的容器、Pod 或卷。然后启动 Pod 中的容器，并输出新 Pod 的 ID 或新卷的名称。如果将 YAML 文件指定为“-”，则 podman kube play 会从 stdin 读取 YAML 文件。输入也可以是指向 YAML 文件的 URL，例如 https://podman.io/demo.yml。 podman kube play 会从 URL 读取 YAML，并根据其创建 Pod 和容器。

Using the --down command line option, it is also capable of tearing down the pods created by a previous run of podman kube play.
使用 --down 命令行选项，还可以拆除由上一次运行 podman kube play 创建的 Pod。

Using the --replace command line option, it tears down the pods(if any) created by a previous run of podman kube play and recreate the pods with the Kubernetes YAML file.
使用 --replace 命令行选项，它会拆除由上一次运行 podman kube play 创建的 Pod（如果有的话），并使用 Kubernetes YAML 文件重新创建 Pod。

Ideally the input file is created by the Podman command (see podman-kube-generate(1)). This guarantees a smooth import and expected results.
理想情况下，输入文件由 Podman 命令创建（参见 podman-kube-generate(1)）。这可以确保平稳导入和预期结果。

Currently, the supported Kubernetes kinds are:
目前，支持的 Kubernetes 种类有：

Pod
Deployment 部署
PersistentVolumeClaim 持久卷索赔
ConfigMap 配置映射
Secret 机密
DaemonSet 守护进程集

Kubernetes Pods or Deployments

Only three volume types are supported by kube play, the hostPath, emptyDir, and persistentVolumeClaim volume types.
kube play 仅支持三种卷类型，即 hostPath、emptyDir 和 persistentVolumeClaim 卷类型。

When using the hostPath volume type, only the default (empty), DirectoryOrCreate, Directory, FileOrCreate, File, Socket, CharDevice and BlockDevice subtypes are supported. Podman interprets the value of hostPath path as a file path when it contains at least one forward slash, otherwise Podman treats the value as the name of a named volume.
使用 hostPath 卷类型时，仅支持默认（空）、DirectoryOrCreate、Directory、FileOrCreate、File、Socket、CharDevice 和 BlockDevice 子类型。当 hostPath 路径至少包含一个正斜杠时，Podman 将 hostPath 路径的值解释为文件路径，否则 Podman 将该值视为命名卷的名称。
When using a persistentVolumeClaim, the value for claimName is the name for the Podman named volume.
使用 persistentVolumeClaim 时，claimName 的值是 Podman 命名卷的名称。
When using an emptyDir volume, Podman creates an anonymous volume that is attached the containers running inside the pod and is deleted once the pod is removed.
当使用 emptyDir 卷时，Podman 会创建一个匿名卷，该卷会附加到容器内的运行容器，并在删除 pod 时被删除。

Note: The default restart policy for containers is always. You can change the default by setting the restartPolicy field in the spec.
注意: 容器的默认重启策略是 always 。您可以通过在规范中设置 restartPolicy 字段来更改默认值。

Note: When playing a kube YAML with init containers, the init container is created with init type value once. To change the default type, use the io.podman.annotations.init.container.type annotation to set the type to always.
注意: 在播放带有 init 容器的 kube YAML 时，init 容器将使用 init 类型值 once 创建。要更改默认类型，请使用 io.podman.annotations.init.container.type 注释将类型设置为 always 。

Note: hostPath volume types created by kube play is given an SELinux shared label (z), bind mounts are not relabeled (use chcon -t container_file_t -R <directory>).
注意：由 kube play 创建的 hostPath 卷类型被赋予 SELinux 共享标签（z），绑定挂载不会重新标记（使用 chcon -t container_file_t -R <directory> ）。

Note: To set userns of a pod, use the io.podman.annotations.userns annotation in the pod/deployment definition. For example, io.podman.annotations.userns=keep-id annotation tells Podman to create a user namespace where the current rootless user’s UID:GID are mapped to the same values in the container. This can be overridden with the --userns flag.
注意：要设置 pod 的 userns，请在 pod/deployment 定义中使用 io.podman.annotations.userns 注释。例如，io.podman.annotations.userns=keep-id 注释告诉 Podman 创建一个用户命名空间，其中当前的无根用户的 UID:GID 映射到容器中的相同值。这可以使用 --userns 标志覆盖。

Note: Use the io.podman.annotations.volumes-from annotation to bind mount volumes of one container to another. You can mount volumes from multiple source containers to a target container. The source containers that belong to the same pod must be defined before the source container in the kube YAML. The annotation format is io.podman.annotations.volumes-from/targetContainer: "sourceContainer1:mountOpts1;sourceContainer2:mountOpts2".
注意：使用 io.podman.annotations.volumes-from 注释将一个容器的卷绑定挂载到另一个容器。您可以将多个源容器的卷挂载到目标容器。属于同一 pod 的源容器必须在 kube YAML 中的源容器之前定义。注释格式为 io.podman.annotations.volumes-from/targetContainer: "sourceContainer1:mountOpts1;sourceContainer2:mountOpts2" 。

Note: If the :latest tag is used, Podman attempts to pull the image from a registry. If the image was built locally with Podman or Buildah, it has localhost as the domain, in that case, Podman uses the image from the local store even if it has the :latest tag.
注意：如果使用 :latest 标签，Podman 将尝试从注册表中拉取镜像。如果镜像是在本地使用 Podman 或 Buildah 构建的，则其域为 localhost ，在这种情况下，即使具有 :latest 标签，Podman 也会使用本地存储中的镜像。

Note: The command podman play kube is an alias of podman kube play, and performs the same function.
注意：命令 podman play kube 是 podman kube play 的别名，并执行相同的功能。

Note: The command podman kube down can be used to stop and remove pods or containers based on the same Kubernetes YAML used by podman kube play to create them.
注意：命令 podman kube down 可用于停止和删除基于相同 Kubernetes YAML 创建的 Pod 或容器，该 YAML 由 podman kube play 使用。

Note: To customize the name of the infra container created during podman kube play, use the io.podman.annotations.infra.name annotation in the pod definition. This annotation is automatically set when generating a kube yaml from a pod that was created with the --infra-name flag set.
注意: 要自定义在 podman kube play 创建的基础设施容器的名称，请在 pod 定义中使用 io.podman.annotations.infra.name 注释。当从设置了 --infra-name 标志的 pod 生成 kube yaml 时，此注释会自动设置。

Kubernetes PersistentVolumeClaims

A Kubernetes PersistentVolumeClaim represents a Podman named volume. Only the PersistentVolumeClaim name is required by Podman to create a volume. Kubernetes annotations can be used to make use of the available options for Podman volumes.
Kubernetes PersistentVolumeClaim 代表一个 Podman 命名卷。只有 PersistentVolumeClaim 名称对于 Podman 创建卷是必需的。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

Use volume.podman.io/import-source to import the contents of the tarball (.tar, .tar.gz, .tgz, .bzip, .tar.xz, .txz) specified in the annotation’s value into the created Podman volume
使用 volume.podman.io/import-source 导入注释值中指定的 tarball (.tar, .tar.gz, .tgz, .bzip, .tar.xz, .txz) 的内容到创建的 Podman 卷中

Kube play is capable of building images on the fly given the correct directory layout and Containerfiles. This option is not available for remote clients, including Mac and Windows (excluding WSL2) machines, yet. Consider the following excerpt from a YAML file:
Kube play 能够根据正确的目录布局和 Containerfiles 动态构建镜像。该选项目前不适用于远程客户端，包括 Mac 和 Windows（不包括 WSL2）机器。请考虑以下 YAML 文件摘录：

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

If there is a directory named foobar in the current working directory with a file named Containerfile or Dockerfile, Podman kube play builds that image and name it foobar. An example directory structure for this example looks like:
如果当前工作目录中有一个名为 foobar 的目录，并且有一个名为 Containerfile 或 Dockerfile 的文件，Podman kube play 将构建该镜像并命名为 foobar 。此示例的目录结构如下：

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

The build considers foobar to be the context directory for the build. If there is an image in local storage called foobar, the image is not built unless the --build flag is used. Use --build=false to completely disable builds.
构建将 foobar 视为构建的上下文目录。如果本地存储中有一个名为 foobar 的镜像，则除非使用 --build 标志，否则不会构建该镜像。使用 --build=false 可以完全禁用构建。

Kubernetes ConfigMap

Kubernetes ConfigMap can be referred as a source of environment variables or volumes in Pods or Deployments. ConfigMaps aren’t a standalone object in Podman; instead, when a container uses a ConfigMap, Podman creates environment variables or volumes as needed.
Kubernetes ConfigMap 可以被引用为 Pod 或 Deployments 中环境变量或卷的来源。ConfigMaps 在 Podman 中不是一个独立的对象；相反，当容器使用 ConfigMap 时，Podman 根据需要创建环境变量或卷。

For example, the following YAML document defines a ConfigMap and then uses it in a Pod:
例如，以下 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

and as a result environment variable FOO is set to bar for container container-1.
结果环境变量 FOO 被设置为 bar 用于容器 container-1 。

Kubernetes Secret

Kubernetes Secret represents a Podman named secret. The Kubernetes Secret is saved as a whole and may be referred to as a source of environment variables or volumes in Pods or Deployments.
Kubernetes Secret 代表一个名为 secret 的 Podman。Kubernetes Secret 被保存为一个整体，可以被引用为 Pod 或 Deployments 中的环境变量或卷的来源。

For example, the following YAML document defines a Secret and then uses it in a Pod:
例如，以下 YAML 文档定义了一个 Secret，然后在 Pod 中使用它：

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

and as a result environment variable FOO is set to bar for container container-1.
结果容器 container-1 的环境变量 FOO 被设置为 bar 。

Automounting Volumes

An image can be automatically mounted into a container if the annotation io.podman.annotations.kube.image.automount/$ctrname is given. The following rules apply:
如果给定注释 io.podman.annotations.kube.image.automount/$ctrname ，则图像可以自动挂载到容器中。以下规则适用：

The image must already exist locally.
图像必须已经存在于本地。
The image must have at least 1 volume directive.
图像必须至少有一个卷指令。
The path given by the volume directive will be mounted from the image into the container. For example, an image with a volume at /test/test_dir will have /test/test_dir in the image mounted to /test/test_dir in the container.
由卷指令给出的路径将从图像挂载到容器中。例如，具有卷的图像在图像中的 /test/test_dir 将被挂载到容器中的 /test/test_dir 。
Multiple images can be specified. If multiple images have a volume at a specific path, the last image specified trumps.
可以指定多个镜像。如果多个镜像在特定路径上有一个卷，那么最后指定的镜像将覆盖之前的。
The images are always mounted read-only.
这些镜像始终以只读方式挂载。
Images to mount are defined in the annotation “io.podman.annotations.kube.image.automount/$ctrname” as a semicolon-separated list. They are mounted into a single container in the pod, not the whole pod. The annotation can be specified for additional containers if additional mounts are required.
要挂载的镜像在注释“io.podman.annotations.kube.image.automount/$ctrname”中定义为以分号分隔的列表。它们被挂载到 pod 中的单个容器中，而不是整个 pod。如果需要额外的挂载，可以为其他容器指定该注释。

OPTIONS¶ 选项

--annotation=key=value¶

Add an annotation to the container or pod. This option can be set multiple times.
向容器或 Pod 添加注释。此选项可以设置多次。

--authfile=path¶

Path of the authentication file. Default is ${XDG_RUNTIME_DIR}/containers/auth.json on Linux, and $HOME/.config/containers/auth.json on Windows/macOS. The file is created by podman login. If the authorization state is not found there, $HOME/.docker/config.json is checked, which is set using docker login.
认证文件的路径。在 Linux 上默认为 ${XDG_RUNTIME_DIR}/containers/auth.json ，在 Windows/macOS 上默认为 $HOME/.config/containers/auth.json 。该文件由 podman login 创建。如果授权状态未在那里找到，则会检查 $HOME/.docker/config.json ，该值是使用 docker login 设置的。

Note: There is also the option to override the default path of the authentication file by setting the REGISTRY_AUTH_FILE environment variable. This can be done with export REGISTRY_AUTH_FILE=path.
注意：还有一种选择，可以通过设置 REGISTRY_AUTH_FILE 环境变量来覆盖认证文件的默认路径。可以通过 export REGISTRY_AUTH_FILE=path 来实现。

--build¶

Build images even if they are found in the local storage. Use --build=false to completely disable builds. (This option is not available with the remote Podman client)
即使在本地存储中找到镜像，也要构建它们。使用 --build=false 来完全禁用构建。（此选项在远程 Podman 客户端中不可用）

Note: You can also override the default isolation type by setting the BUILDAH_ISOLATION environment variable. export BUILDAH_ISOLATION=oci. See podman-build.1.md for more information.
注意：您还可以通过设置 BUILDAH_ISOLATION 环境变量来覆盖默认的隔离类型。导出 BUILDAH_ISOLATION=oci。有关更多信息，请参阅 podman-build.1.md。

--cert-dir=path¶

Use certificates at path (*.crt, *.cert, *.key) to connect to the registry. (Default: /etc/containers/certs.d) For details, see containers-certs.d(5). (This option is not available with the remote Podman client, including Mac and Windows (excluding WSL2) machines)
使用证书路径（*.crt, *.cert, *.key）连接到注册表。（默认值：/etc/containers/certs.d）有关详细信息，请参阅 containers-certs.d(5)。（此选项不适用于远程 Podman 客户端，包括 Mac 和 Windows（不包括 WSL2）机器）

--configmap=path¶

Use Kubernetes configmap YAML at path to provide a source for environment variable values within the containers of the pod. (This option is not available with the remote Podman client)
使用路径处的 Kubernetes configmap YAML 为 pod 中的容器提供环境变量值的来源。（此选项在远程 Podman 客户端中不可用）

Note: The --configmap option can be used multiple times or a comma-separated list of paths can be used to pass multiple Kubernetes configmap YAMLs. The YAML file may be in a multi-doc YAML format. But, it must container only configmaps
注意：--configmap 选项可以多次使用，或者可以使用逗号分隔的路径列表传递多个 Kubernetes configmap YAML。YAML 文件可以采用多文档 YAML 格式。但是，它必须仅包含 configmaps。

--context-dir=path¶

Use path as the build context directory for each image. Requires --build option be true. (This option is not available with the remote Podman client)
使用 path 作为每个镜像的构建上下文目录。需要 --build 选项为 true。（此选项在远程 Podman 客户端中不可用）

--creds=[username[:password]]¶
--creds=[用户名[:密码]] ¶

The [username[:password]] to use to authenticate with the registry, if required. If one or both values are not supplied, a command line prompt appears and the value can be entered. The password is entered without echo.
如果需要，用于与注册表进行身份验证的[用户名[:密码]]。如果一个或两个值未提供，将出现命令行提示，并可以输入该值。密码输入时不会显示。

Note that the specified credentials are only used to authenticate against target registries. They are not used for mirrors or when the registry gets rewritten (see containers-registries.conf(5)); to authenticate against those consider using a containers-auth.json(5) file.
请注意，指定的凭据仅用于对目标注册表进行身份验证。它们不用于镜像或注册表被重写时（请参阅 containers-registries.conf(5) ）；要对其进行身份验证，请考虑使用 containers-auth.json(5) 文件。

--force¶

Tear down the volumes linked to the PersistentVolumeClaims as part of --down
拆除与 PersistentVolumeClaims 关联的卷作为 --down 的一部分

--help, -h¶ --help，-h ¶

Print usage statement 打印使用说明

--ip=IP address¶ --ip=IP 地址

Assign a static ip address to the pod. This option can be specified several times when kube play creates more than one pod. Note: When joining multiple networks use the --network name:ip=<ip> syntax.
为 pod 分配静态 IP 地址。当 kube play 创建多个 pod 时，可以多次指定此选项。注意：当加入多个网络时，请使用 --network name:ip=<ip> 语法。

--log-driver=driver¶

Set logging driver for all created containers.
为所有创建的容器设置日志驱动程序。

--log-opt=name=value¶

Logging driver specific options.
记录驱动程序特定选项。

Set custom logging configuration. The following names are supported:
设置自定义日志配置。支持以下名称：

path: specify a path to the log file (e.g. --log-opt path=/var/log/container/mycontainer.json);
path: 指定日志文件的路径（例如 --log-opt path=/var/log/container/mycontainer.json）;

max-size: specify a max size of the log file (e.g. --log-opt max-size=10mb);
max-size: 指定日志文件的最大大小（例如 --log-opt max-size=10mb）;

tag: specify a custom log tag for the container (e.g. --log-opt tag=”{{.ImageName}}”. It supports the same keys as podman inspect --format. This option is currently supported only by the journald log driver.
标签: 为容器指定自定义日志标签（例如 --log-opt tag=”{{.ImageName}}”）。它支持与 podman inspect --format 相同的键。此选项目前仅受 journald 日志驱动程序支持。

--mac-address=MAC address¶
--mac-address=MAC 地址 ¶

Assign a static mac address to the pod. This option can be specified several times when kube play creates more than one pod. Note: When joining multiple networks use the --network name:mac=<mac> syntax.
为 pod 分配静态 MAC 地址。当 kube play 创建多个 pod 时，可以多次指定此选项。注意：在加入多个网络时，请使用 --network name:mac=<mac> 语法。

--network=mode, --net¶

Set the network mode for the pod.
设置 pod 的网络模式。

Valid mode values are: 有效的模式值为：

bridge[:OPTIONS,…]: Create a network stack on the default bridge. This is the default for rootful containers. It is possible to specify these additional options:
bridge[:OPTIONS,…]: 在默认桥接器上创建一个网络堆栈。这是 rootful 容器的默认设置。可以指定以下附加选项：
- alias=name: Add network-scoped alias for the container.
  alias=name: 为容器添加网络范围的别名。
- ip=IPv4: Specify a static IPv4 address for this container.
  ip=IPv4: 为此容器指定静态 IPv4 地址。
- ip6=IPv6: Specify a static IPv6 address for this container.
  ip6=IPv6: 为此容器指定静态 IPv6 地址。
- mac=MAC: Specify a static MAC address for this container.
  mac=MAC: 为此容器指定静态 MAC 地址。
- interface_name=name: Specify a name for the created network interface inside the container.
  interface_name=name: 为容器内创建的网络接口指定名称。
For example, to set a static ipv4 address and a static mac address, use --network bridge:ip=10.88.0.10,mac=44:33:22:11:00:99.
例如，要设置静态 IPv4 地址和静态 MAC 地址，请使用 --network bridge:ip=10.88.0.10,mac=44:33:22:11:00:99 。
<network name or ID>[:OPTIONS,…]: Connect to a user-defined network; this is the network name or ID from a network created by podman network create. Using the network name implies the bridge network mode. It is possible to specify the same options described under the bridge mode above. Use the --network option multiple times to specify additional networks.
<网络名称或 ID>[:选项,…]：连接到用户定义的网络；这是通过 podman network create 创建的网络的网络名称或 ID。使用网络名称意味着桥接网络模式。可以指定与上面的桥接模式下描述的相同选项。多次使用 --network 选项以指定其他网络。
For backwards compatibility it is also possible to specify comma-separated networks on the first --network argument, however this prevents you from using the options described under the bridge section above.
为了向后兼容，还可以在第一个 --network 参数上指定逗号分隔的网络，但这将阻止您使用上面桥接部分中描述的选项。
none: Create a network namespace for the container but do not configure network interfaces for it, thus the container has no network connectivity.
none: 为容器创建一个网络命名空间，但不为其配置网络接口，因此容器没有网络连接。
container:id: Reuse another container’s network stack.
container:id: 重用另一个容器的网络堆栈。
host: Do not create a network namespace, the container uses the host’s network. Note: The host mode gives the container full access to local system services such as D-bus and is therefore considered insecure.
host: 不创建网络命名空间，容器使用主机的网络。注意：主机模式使容器完全访问本地系统服务，如 D-bus，因此被认为是不安全的。
ns:path: Path to a network namespace to join.
ns:path: 加入网络命名空间的路径。
private: Create a new namespace for the container. This uses the bridge mode for rootful containers and slirp4netns for rootless ones.
private: 为容器创建一个新的命名空间。对于 rootful 容器，使用桥接模式，对于 rootless 容器，使用 slirp4netns。
slirp4netns[:OPTIONS,…]: use slirp4netns(1) to create a user network stack. This is the default for rootless containers. It is possible to specify these additional options, they can also be set with network_cmd_options in containers.conf:
slirp4netns[:OPTIONS,…]: 使用 slirp4netns(1) 创建用户网络堆栈。这是无根容器的默认设置。可以指定这些附加选项，它们也可以在 containers.conf 中使用 network_cmd_options 进行设置：
- allow_host_loopback=true|false: Allow slirp4netns to reach the host loopback IP (default is 10.0.2.2 or the second IP from slirp4netns cidr subnet when changed, see the cidr option below). The default is false.
  allow_host_loopback=true|false: 允许 slirp4netns 访问主机环回 IP（默认为 10.0.2.2 或 slirp4netns cidr 子网中的第二个 IP，当更改时，请参阅下面的 cidr 选项）。默认值为 false。
- mtu=MTU: Specify the MTU to use for this network. (Default is 65520).
  mtu=MTU: 指定此网络使用的 MTU。（默认值为 65520 ）。
- cidr=CIDR: Specify ip range to use for this network. (Default is 10.0.2.0/24).
  cidr=CIDR: 指定用于此网络的 IP 范围。（默认值为 10.0.2.0/24 ）。
- enable_ipv6=true|false: Enable IPv6. Default is true. (Required for outbound_addr6).
  enable_ipv6=true|false: 启用 IPv6。默认为 true。（ outbound_addr6 所需）。
- outbound_addr=INTERFACE: Specify the outbound interface slirp binds to (ipv4 traffic only).
  outbound_addr=INTERFACE: 指定 slirp 绑定到的出站接口（仅限 IPv4 流量）。
- outbound_addr=IPv4: Specify the outbound ipv4 address slirp binds to.
  outbound_addr=IPv4: 指定 slirp 绑定到的出站 IPv4 地址。
- outbound_addr6=INTERFACE: Specify the outbound interface slirp binds to (ipv6 traffic only).
  outbound_addr6=INTERFACE: 指定 slirp 绑定到的出站接口（仅限 IPv6 交通）。
- outbound_addr6=IPv6: Specify the outbound ipv6 address slirp binds to.
  outbound_addr6=IPv6: 指定 slirp 绑定到的出站 IPv6 地址。
- port_handler=rootlesskit: Use rootlesskit for port forwarding. Default.
  port_handler=rootlesskit: 使用 rootlesskit 进行端口转发。默认选项。
  Note: Rootlesskit changes the source IP address of incoming packets to an IP address in the container network namespace, usually 10.0.2.100. If the application requires the real source IP address, e.g. web server logs, use the slirp4netns port handler. The rootlesskit port handler is also used for rootless containers when connected to user-defined networks.
  注意：Rootlesskit 会将传入数据包的源 IP 地址更改为容器网络命名空间中的 IP 地址，通常为 10.0.2.100 。如果应用程序需要真实的源 IP 地址，例如 Web 服务器日志，请使用 slirp4netns 端口处理程序。当连接到用户定义网络时，也会使用 rootlesskit 端口处理程序。
- port_handler=slirp4netns: Use the slirp4netns port forwarding, it is slower than rootlesskit but preserves the correct source IP address. This port handler cannot be used for user-defined networks.
  port_handler=slirp4netns：使用 slirp4netns 端口转发，速度比 rootlesskit 慢，但保留正确的源 IP 地址。此端口处理程序不能用于用户定义网络。
pasta[:OPTIONS,…]: use pasta(1) to create a user-mode networking stack.
pasta[:OPTIONS,…]: 使用 pasta(1) 创建用户模式网络堆栈。
This is only supported in rootless mode.
这仅在无根模式下支持。
By default, IPv4 and IPv6 addresses and routes, as well as the pod interface name, are copied from the host. If port forwarding isn’t configured, ports are forwarded dynamically as services are bound on either side (init namespace or container namespace). Port forwarding preserves the original source IP address. Options described in pasta(1) can be specified as comma-separated arguments.
默认情况下，IPv4 和 IPv6 地址和路由以及 Pod 接口名称都从主机复制。如果未配置端口转发，则端口将在两侧绑定服务时动态转发（init 命名空间或容器命名空间）。端口转发会保留原始源 IP 地址。可以将 pasta(1)中描述的选项指定为逗号分隔的参数。
In terms of pasta(1) options, --config-net is given by default, in order to configure networking when the container is started, and --no-map-gw is also assumed by default, to avoid direct access from container to host using the gateway address. The latter can be overridden by passing --map-gw in the pasta-specific options (despite not being an actual pasta(1) option).
在 pasta(1)选项方面，默认情况下会提供--config-net，以便在启动容器时配置网络，并且默认情况下也会假定--no-map-gw，以避免容器直接使用网关地址访问主机。后者可以通过在 pasta 特定选项中传递--map-gw 来覆盖（尽管这不是实际的 pasta(1)选项）。
Also, -t none and -u none are passed if, respectively, no TCP or UDP port forwarding from host to container is configured, to disable automatic port forwarding based on bound ports. Similarly, -T none and -U none are given to disable the same functionality from container to host.
同样，如果未配置主机到容器的 TCP 或 UDP 端口转发，则分别传递 -t none 和 -u none，以禁用基于绑定端口的自动端口转发。类似地，给出 -T none 和 -U none 以禁用容器到主机的相同功能。
Some examples: 一些例子：
- pasta:--map-gw: Allow the container to directly reach the host using the gateway address.
  pasta:--map-gw: 允许容器直接使用网关地址访问主机。
- pasta:--mtu,1500: Specify a 1500 bytes MTU for the tap interface in the container.
  pasta:--mtu,1500: 为容器中的 tap 接口指定一个 1500 字节的 MTU。
- pasta:--ipv4-only,-a,10.0.2.0,-n,24,-g,10.0.2.2,--dns-forward,10.0.2.3,-m,1500,--no-ndp,--no-dhcpv6,--no-dhcp, equivalent to default slirp4netns(1) options: disable IPv6, assign 10.0.2.0/24 to the tap0 interface in the container, with gateway 10.0.2.3, enable DNS forwarder reachable at 10.0.2.3, set MTU to 1500 bytes, disable NDP, DHCPv6 and DHCP support.
  pasta:--ipv4-only,-a,10.0.2.0,-n,24,-g,10.0.2.2,--dns-forward,10.0.2.3,-m,1500,--no-ndp,--no-dhcpv6,--no-dhcp, 等同于默认的 slirp4netns(1) 选项：禁用 IPv6，在容器中为 tap0 接口分配 10.0.2.0/24 ，使用网关 10.0.2.3 ，启用可在 10.0.2.3 访问的 DNS 转发器，将 MTU 设置为 1500 字节，禁用 NDP、DHCPv6 和 DHCP 支持。
- pasta:-I,tap0,--ipv4-only,-a,10.0.2.0,-n,24,-g,10.0.2.2,--dns-forward,10.0.2.3,--no-ndp,--no-dhcpv6,--no-dhcp, equivalent to default slirp4netns(1) options with Podman overrides: same as above, but leave the MTU to 65520 bytes
  pasta:-I,tap0,--ipv4-only,-a,10.0.2.0,-n,24,-g,10.0.2.2,--dns-forward,10.0.2.3,--no-ndp,--no-dhcpv6,--no-dhcp, 等同于默认的 slirp4netns(1) 选项，但具有 Podman 覆盖：与上述相同，但将 MTU 保留为 65520 字节。
- pasta:-t,auto,-u,auto,-T,auto,-U,auto: enable automatic port forwarding based on observed bound ports from both host and container sides
  pasta:-t,auto,-u,auto,-T,auto,-U,auto: 根据主机和容器双方观察到的绑定端口启用自动端口转发
- pasta:-T,5201: enable forwarding of TCP port 5201 from container to host, using the loopback interface instead of the tap interface for improved performance
  pasta:-T,5201: 启用将容器中的 TCP 端口 5201 转发到主机，使用环回接口而不是 tap 接口以提高性能

When no network option is specified and host network mode is not configured in the YAML file, a new network stack is created and pods are attached to it making possible pod to pod communication.
当未指定网络选项且 YAML 文件中未配置主机网络模式时，将创建一个新的网络堆栈，并将 pod 附加到其中，从而实现 pod 之间的通信。

--no-hosts¶

Do not create /etc/hosts for the pod. By default, Podman manages /etc/hosts, adding the container’s own IP address and any hosts from --add-host. --no-hosts disables this, and the image’s /etc/hosts is preserved unmodified.
不为 pod 创建 /etc/hosts。默认情况下，Podman 管理 /etc/hosts，添加容器自己的 IP 地址和任何来自 --add-host 的主机。--no-hosts 禁用此功能，并保留镜像的 /etc/hosts 不受修改。

This option conflicts with host added in the Kubernetes YAML.
此选项与在 Kubernetes YAML 中添加的主机冲突。

--publish=[[ip:][hostPort]:]containerPort[/protocol]¶

Define or override a port definition in the YAML file.
在 YAML 文件中定义或覆盖端口定义。

The lists of ports in the YAML file and the command line are merged. Matching is done by using the containerPort field. If containerPort exists in both the YAML file and the option, the latter takes precedence.
YAML 文件中的端口列表和命令行中的端口列表将被合并。匹配是通过使用 containerPort 字段来完成的。如果 containerPort 在 YAML 文件和选项中都存在，则后者优先。

--publish-all¶

Setting this option to true will expose all ports to the host, even if only specified via containerPort in the K8 YAML. In terms of which port will be exposed, --publish has higher priority than hostPort, has higher priority than containerPort.
将此选项设置为 true 将会将所有端口暴露给主机，即使只在 K8 YAML 中通过 containerPort 指定。在确定要暴露的端口时，--publish 的优先级高于 hostPort，hostPort 的优先级高于 containerPort。

If set to false (which is the default), only ports defined via hostPort or --publish are published on the host.
如果设置为 false （默认值），则仅发布通过 hostPort 或--publish 定义的端口。

--quiet, -q¶

Suppress output information when pulling images
在拉取图像时抑制输出信息。

--replace¶ --替换 ¶

Tears down the pods created by a previous run of kube play and recreates the pods. This option is used to keep the existing pods up to date based upon the Kubernetes YAML.
拆除之前运行 kube play 创建的 Pod，并重新创建 Pod。此选项用于根据 Kubernetes YAML 保持现有 Pod 的最新状态。

--seccomp-profile-root=path¶

Directory path for seccomp profiles (default: “/var/lib/kubelet/seccomp”). (This option is not available with the remote Podman client, including Mac and Windows (excluding WSL2) machines)
seccomp 配置文件的目录路径（默认值：“/var/lib/kubelet/seccomp”）。（此选项不适用于远程 Podman 客户端，包括 Mac 和 Windows（不包括 WSL2）机器）

--start¶

Start the pod after creating it, set to false to only create it.
创建后启动 Pod，将其设置为 false 仅创建而不启动。

--tls-verify¶

Require HTTPS and verify certificates when contacting registries (default: true). If explicitly set to true, TLS verification is used. If set to false, TLS verification is not used. If not specified, TLS verification is used unless the target registry is listed as an insecure registry in containers-registries.conf(5)
在联系注册表时需要 HTTPS 并验证证书（默认值为 true）。如果显式设置为 true，则使用 TLS 验证。如果设置为 false，则不使用 TLS 验证。如果未指定，则除非目标注册表在 containers-registries.conf(5) 中被列为不安全注册表，否则将使用 TLS 验证。

--userns=mode¶ --userns=mode

Set the user namespace mode for the container.
为容器设置用户命名空间模式。

If --userns is not set, the default value is determined as follows.
如果未设置 --userns ，则默认值将如下确定。

If --pod is set, --userns is ignored and the user namespace of the pod is used.
如果设置了 --pod ，则 --userns 将被忽略，且使用 Pod 的用户命名空间。
If the environment variable PODMAN_USERNS is set its value is used.
如果环境变量 PODMAN_USERNS 已设置，则使用其值。
If userns is specified in containers.conf this value is used.
如果在 containers.conf 中指定了 userns ，则使用该值。
Otherwise, --userns=host is assumed.
否则，假定为 --userns=host 。

--userns="" (i.e., an empty string) is an alias for --userns=host.
--userns="" （即空字符串）是 --userns=host 的别名。

This option is incompatible with --gidmap, --uidmap, --subuidname and --subgidname.
此选项与--gidmap、--uidmap、--subuidname 和--subgidname 不兼容。

Rootless user --userns=Key mappings:
无根用户--userns=Key 映射：

Key	Host User 主机用户	Container User 容器用户
auto	$UID	nil (Host User UID is not mapped into container.) nil（主机用户 UID 未映射到容器。）
host	$UID	0 (Default User account mapped to root user in container.) 0（默认用户帐户映射到容器中的 root 用户。）
keep-id	$UID	$UID (Map user account to same UID within container.) $UID（将用户帐户映射到容器内相同的 UID。）
keep-id:uid=200,gid=210	$UID	200:210 (Map user account to specified UID, GID value within container.) 200:210（将用户帐户映射到容器内指定的 UID、GID 值。）
nomap	$UID	nil (Host User UID is not mapped into container.) nil（主机用户 UID 未映射到容器。）

Valid mode values are: 有效的模式值为：

auto[:OPTIONS,…]: automatically create a unique user namespace.
auto[:OPTIONS,…]：自动创建唯一的用户命名空间。

rootful mode: The --userns=auto flag requires that the user name containers be specified in the /etc/subuid and /etc/subgid files, with an unused range of subordinate user IDs that Podman containers are allowed to allocate.
rootful mode ： --userns=auto 标志要求在 /etc/subuid 和 /etc/subgid 文件中指定容器的用户名，使用未使用的次要用户 ID 范围，Podman 容器允许分配。
```
 Example: `containers:2147483647:2147483648`.
```
rootless mode: The users range from the /etc/subuid and /etc/subgid files will be used. Note running a single container without using --userns=auto will use the entire range of UIDs and not allow further subdividing. See subuid(5).
rootless mode ：用户范围从 /etc/subuid 和 /etc/subgid 文件中获取。请注意，如果不使用 --userns=auto 运行单个容器，则将使用整个 UID 范围，不允许进一步细分。请参阅 subuid(5)。

Podman allocates unique ranges of UIDs and GIDs from the containers subordinate user IDs. The size of the ranges is based on the number of UIDs required in the image. The number of UIDs and GIDs can be overridden with the size option.
Podman 从 containers 从属用户 ID 中分配唯一的 UID 和 GID 范围。范围的大小取决于镜像中所需的 UID 数量。可以使用 size 选项覆盖 UID 和 GID 的数量。

The option --userns=keep-id uses all the subuids and subgids of the user. The option --userns=nomap uses all the subuids and subgids of the user except the user’s own ID. Using --userns=auto when starting new containers does not work as long as any containers exist that were started with --userns=keep-id or --userns=nomap.
选项 --userns=keep-id 使用用户的所有子 UID 和子 GID。选项 --userns=nomap 使用用户的所有子 UID 和子 GID，但不包括用户自己的 ID。只要存在使用 --userns=keep-id 或 --userns=nomap 启动的容器，使用 --userns=auto 启动新容器将无法正常工作。

Valid auto options: 有效的 auto 选项：

gidmapping=CONTAINER_GID:HOST_GID:SIZE: to force a GID mapping to be present in the user namespace.
gidmapping=CONTAINER_GID:HOST_GID:SIZE: 用于强制在用户命名空间中存在 GID 映射。
size=SIZE: to specify an explicit size for the automatic user namespace. e.g. --userns=auto:size=8192. If size is not specified, auto estimates a size for the user namespace.
size=SIZE: 用于为自动用户命名空间指定显式大小。例如 --userns=auto:size=8192 。如果未指定 size ， auto 会为用户命名空间估算一个大小。
uidmapping=CONTAINER_UID:HOST_UID:SIZE: to force a UID mapping to be present in the user namespace.
uidmapping=CONTAINER_UID:HOST_UID:SIZE: 强制在用户命名空间中存在 UID 映射。

The host UID and GID in gidmapping and uidmapping can optionally be prefixed with the @ symbol. In this case, podman will look up the intermediate ID corresponding to host ID and it will map the found intermediate ID to the container id. For details see --uidmap.
gidmapping 和 uidmapping 中的主机 UID 和 GID 可以选择性地以 @ 符号为前缀。在这种情况下，podman 将查找与主机 ID 对应的中间 ID，并将找到的中间 ID 映射到容器 ID。有关详细信息，请参阅 --uidmap。

container:id: join the user namespace of the specified container.
container:id: 加入指定容器的用户命名空间。

host or “” (empty string): run in the user namespace of the caller. The processes running in the container have the same privileges on the host as any other process launched by the calling user.
主机或“”（空字符串）：在调用者的用户命名空间中运行。在容器中运行的进程在主机上具有与调用用户启动的任何其他进程相同的特权。

keep-id: creates a user namespace where the current user’s UID:GID are mapped to the same values in the container. For containers created by root, the current mapping is created into a new user namespace.
keep-id：创建一个用户命名空间，其中当前用户的 UID:GID 被映射到容器中的相同值。对于由 root 创建的容器，当前映射被创建到一个新的用户命名空间中。

Valid keep-id options: 有效的 keep-id 选项：

uid=UID: override the UID inside the container that is used to map the current user to.
uid=UID: 覆盖容器内用于映射当前用户的 UID。
gid=GID: override the GID inside the container that is used to map the current user to.
gid=GID: 覆盖容器内用于映射当前用户的 GID。

nomap: creates a user namespace where the current rootless user’s UID:GID are not mapped into the container. This option is not allowed for containers created by the root user.
nomap: 创建一个用户命名空间，其中当前无根用户的 UID:GID 不映射到容器中。此选项不允许由 root 用户创建的容器使用。

ns:namespace: run the pod in the given existing user namespace.
ns:namespace: 在给定的现有用户命名空间中运行 pod。

--wait, -w¶

Run pods and containers in the foreground. Default is false.
在前台运行 pods 和容器。默认值为 false。

At any time you can run podman pod ps in another shell to view a list of the running pods and containers.
任何时候，您都可以在另一个 shell 中运行 podman pod ps 来查看正在运行的 pod 和容器的列表。

When attached in the tty mode, you can kill the pods and containers by pressing Ctrl-C or receiving any other interrupt signals.
在 tty 模式下附加时，您可以通过按下 Ctrl-C 或接收任何其他中断信号来终止 pod 和容器。

All pods, containers, and volumes created with podman kube play is removed upon exit.
所有使用 podman kube play 创建的 pod、容器和卷在退出时都会被删除。

EXAMPLES¶ 示例

Recreate the pod and containers described in the specified host YAML file.
重新创建在指定主机 YAML 文件中描述的 pod 和容器。

$ podman kube play demo.yml
52182811df2b1e73f36476003a66ec872101ea59034ac0d4d3a7b40903b955a6

Recreate the pod and containers specified in a YAML file sent to stdin.
重新创建在通过 stdin 发送的 YAML 文件中指定的 pod 和容器。

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

Tear down the pod and containers as described in the specified YAML file.
拆除在指定的 YAML 文件中描述的 pod 和容器。

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

Provide multiple configmap files as sources for environment variables within the specified pods and containers.
为指定的 pod 和容器提供多个 configmap 文件作为环境变量的来源。

$ 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

Create a pod connected to two networks with a static ip on each.
创建一个连接到两个网络的 pod，每个网络都有一个静态 IP。

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

Please take into account that networks must be created first using podman-network-create(1).
请注意，网络必须首先使用 podman-network-create(1) 创建。

Create and teardown from a URL pointing to a YAML file.
从指向 YAML 文件的 URL 创建和拆除。

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

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

podman kube play --down does not work with a URL if the YAML file the URL points to has been changed or altered.
如果 URL 指向的 YAML 文件已更改或更改，则 podman kube play --down 无法使用 URL。

Podman Kube Play Support¶
Podman Kube Play 支持 ¶

This document outlines the kube yaml fields that are currently supported by the podman kube play command.
本文档概述了当前由 podman kube play 命令支持的 kube yaml 字段。

Note: N/A means that the option cannot be supported in a single-node Podman environment.
注意：N/A 表示该选项在单节点 Podman 环境中无法支持。

Pod Fields¶ Pod 字段 ¶

Field	Support
containers	✅
initContainers	✅
imagePullSecrets	no
enableServiceLinks	no
os.name	no
volumes	✅
nodeSelector	N/A
nodeName	N/A
affinity.nodeAffinity	N/A
affinity.podAffinity	N/A
affinity.podAntiAffinity	N/A
tolerations.key	N/A
tolerations.operator	N/A
tolerations.effect	N/A
tolerations.tolerationSeconds	N/A
schedulerName	N/A
runtimeClassName	no
priorityClassName	no
priority	no
topologySpreadConstraints.maxSkew	N/A
topologySpreadConstraints.topologyKey	N/A
topologySpreadConstraints.whenUnsatisfiable	N/A
topologySpreadConstraints.labelSelector	N/A
topologySpreadConstraints.minDomains	N/A
restartPolicy	✅
terminationGracePeriodSeconds	✅
activeDeadlineSeconds	no
readinessGates.conditionType	no
hostname	✅
setHostnameAsFQDN	no
subdomain	no
hostAliases.hostnames	✅
hostAliases.ip	✅
dnsConfig.nameservers	✅
dnsConfig.options.name	✅
dnsConfig.options.value	✅
dnsConfig.searches	✅
dnsPolicy	no
hostNetwork	✅
hostPID	✅
hostIPC	✅
shareProcessNamespace	✅
serviceAccountName	no
automountServiceAccountToken	no
securityContext.runAsUser	✅
securityContext.runAsNonRoot	no
securityContext.runAsGroup	✅
securityContext.supplementalGroups	✅
securityContext.fsGroup	no
securityContext.fsGroupChangePolicy	no
securityContext.seccompProfile.type	no
securityContext.seccompProfile.localhostProfile	no
securityContext.seLinuxOptions.level	✅
securityContext.seLinuxOptions.role	✅
securityContext.seLinuxOptions.type	✅
securityContext.seLinuxOptions.user	✅
securityContext.sysctls.name	✅
securityContext.sysctls.value	✅
securityContext.windowsOptions.gmsaCredentialSpec	no
securityContext.windowsOptions.hostProcess	no
securityContext.windowsOptions.runAsUserName	no

Container Fields¶ 容器字段 ¶

Field	Support
name	✅
image	✅
imagePullPolicy	✅
command	✅
args	✅
workingDir	✅
ports.containerPort	✅
ports.hostIP	✅
ports.hostPort	✅
ports.name	✅
ports.protocol	✅
env.name	✅
env.value	✅
env.valueFrom.configMapKeyRef.key	✅
env.valueFrom.configMapKeyRef.name	✅
env.valueFrom.configMapKeyRef.optional	✅
env.valueFrom.fieldRef	✅
env.valueFrom.resourceFieldRef	✅
env.valueFrom.secretKeyRef.key	✅
env.valueFrom.secretKeyRef.name	✅
env.valueFrom.secretKeyRef.optional	✅
envFrom.configMapRef.name	✅
envFrom.configMapRef.optional	✅
envFrom.prefix	no
envFrom.secretRef.name	✅
envFrom.secretRef.optional	✅
volumeMounts.mountPath	✅
volumeMounts.name	✅
volumeMounts.mountPropagation	no
volumeMounts.readOnly	✅
volumeMounts.subPath	no
volumeMounts.subPathExpr	no
volumeDevices.devicePath	no
volumeDevices.name	no
resources.limits	✅
resources.requests	✅
lifecycle.postStart	no
lifecycle.preStop	no
terminationMessagePath	no
terminationMessagePolicy	no
livenessProbe	✅
readinessProbe	no
startupProbe	no
securityContext.runAsUser	✅
securityContext.runAsNonRoot	no
securityContext.runAsGroup	✅
securityContext.readOnlyRootFilesystem	✅
securityContext.procMount	✅
securityContext.privileged	✅
securityContext.allowPrivilegeEscalation	✅
securityContext.capabilities.add	✅
securityContext.capabilities.drop	✅
securityContext.seccompProfile.type	no
securityContext.seccompProfile.localhostProfile	no
securityContext.seLinuxOptions.level	✅
securityContext.seLinuxOptions.role	✅
securityContext.seLinuxOptions.type	✅
securityContext.seLinuxOptions.user	✅
securityContext.windowsOptions.gmsaCredentialSpec	no
securityContext.windowsOptions.hostProcess	no
securityContext.windowsOptions.runAsUserName	no
stdin	no
stdinOnce	no
tty	no

PersistentVolumeClaim Fields¶
持久卷声明字段 ¶

Field	Support
volumeName	no
storageClassName	✅
volumeMode	no
accessModes	✅
selector	no
resources.limits	no
resources.requests	✅

ConfigMap Fields¶ 配置映射字段 ¶

Field	Support
binaryData	✅
data	✅
immutable	no

Deployment Fields¶ 部署字段 ¶

Field	Support
replicas	✅ (the actual replica count is ignored and set to 1) ✅（实际副本计数被忽略并设置为 1）
selector	✅
template	✅
minReadySeconds	no
strategy.type	no
strategy.rollingUpdate.maxSurge	no
strategy.rollingUpdate.maxUnavailable	no
revisionHistoryLimit	no
progressDeadlineSeconds	no
paused	no

DaemonSet Fields¶ DaemonSet 字段 ¶

Field	Support
selector	✅
template	✅
minReadySeconds	no
strategy.type	no
strategy.rollingUpdate.maxSurge	no
strategy.rollingUpdate.maxUnavailable	no
revisionHistoryLimit	no

NAME¶ 名称

SYNOPSIS¶ 概要

DESCRIPTION¶ 描述

OPTIONS¶ 选项

--annotation=key=value¶

--authfile=path¶

--build¶

--cert-dir=path¶

--configmap=path¶

--context-dir=path¶

--creds=[username[:password]]¶
--creds=[用户名[:密码]] ¶

--force¶

--help, -h¶ --help，-h ¶

--ip=IP address¶ --ip=IP 地址

--log-driver=driver¶

--log-opt=name=value¶

--mac-address=MAC address¶
--mac-address=MAC 地址 ¶

--network=mode, --net¶

--no-hosts¶

--publish=[[ip:][hostPort]:]containerPort[/protocol]¶

--publish-all¶

--quiet, -q¶

--replace¶ --替换 ¶

--seccomp-profile-root=path¶

--start¶

--tls-verify¶

--userns=mode¶ --userns=mode

--wait, -w¶

EXAMPLES¶ 示例

Podman Kube Play Support¶
Podman Kube Play 支持 ¶

Pod Fields¶ Pod 字段 ¶

Container Fields¶ 容器字段 ¶

PersistentVolumeClaim Fields¶
持久卷声明字段 ¶

ConfigMap Fields¶ 配置映射字段 ¶

Deployment Fields¶ 部署字段 ¶

DaemonSet Fields¶ DaemonSet 字段 ¶

SEE ALSO¶ 参见 ¶

Podman

Navigation 导航

Related Topics 相关主题

NAME¶ 名称

SYNOPSIS¶ 概要

DESCRIPTION¶ 描述

OPTIONS¶ 选项

--annotation=key=value¶

--authfile=path¶

--build¶

--cert-dir=path¶

--configmap=path¶

--context-dir=path¶

--creds=[username[:password]]¶--creds=[用户名[:密码]] ¶

--force¶

--help, -h¶ --help，-h ¶

--ip=IP address¶ --ip=IP 地址

--log-driver=driver¶

--log-opt=name=value¶

--mac-address=MAC address¶--mac-address=MAC 地址 ¶

--network=mode, --net¶

--no-hosts¶

--publish=[[ip:][hostPort]:]containerPort[/protocol]¶

--publish-all¶

--quiet, -q¶

--replace¶ --替换 ¶

--seccomp-profile-root=path¶

--start¶

--tls-verify¶

--userns=mode¶ --userns=mode

--wait, -w¶

EXAMPLES¶ 示例

Podman Kube Play Support¶Podman Kube Play 支持 ¶

Pod Fields¶ Pod 字段 ¶

Container Fields¶ 容器字段 ¶

PersistentVolumeClaim Fields¶持久卷声明字段 ¶

ConfigMap Fields¶ 配置映射字段 ¶

Deployment Fields¶ 部署字段 ¶

DaemonSet Fields¶ DaemonSet 字段 ¶

SEE ALSO¶ 参见 ¶

--creds=[username[:password]]¶
--creds=[用户名[:密码]] ¶

--mac-address=MAC address¶
--mac-address=MAC 地址 ¶

Podman Kube Play Support¶
Podman Kube Play 支持 ¶

PersistentVolumeClaim Fields¶
持久卷声明字段 ¶