Podman Generate Kube: Export Pods as Kubernetes YAML (2026)

Podman’s generate kube command is surprisingly good at turning your local Podman pods into Kubernetes YAML, but it’s not just a one-to-one translation.

Let’s see it in action. Imagine you have a simple web application running in a Podman pod:

# Create a pod
podman pod create --name my-web-app-pod -p 8080:80

# Run a container in the pod
podman run -d --pod my-web-app-pod --name my-nginx nginx

# Run another container for a backend service
podman run -d --pod my-web-app-pod --name my-backend docker.io/library/httpd:alpine

Now, let’s export this Podman pod to Kubernetes YAML:

podman generate kube my-web-app-pod > my-web-app-pod.yaml

If you cat my-web-app-pod.yaml, you’ll see something like this:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2023-10-27T10:30:00Z"
  name: my-web-app-pod
spec:
  containers:
  - image: docker.io/library/nginx
    name: my-nginx
    ports:
    - containerPort: 80
      hostPort: 8080
      protocol: TCP
  - image: docker.io/library/httpd:alpine
    name: my-backend

This looks like a basic Kubernetes Pod definition, right? But here’s the crucial part: Podman generate kube doesn’t just map Podman concepts to Kubernetes ones directly. It interprets your Podman setup and generates the closest equivalent in Kubernetes, aiming for functional parity.

The problem this solves is bridging the gap between developing and testing applications locally with Podman and deploying them to a Kubernetes cluster. Instead of manually writing complex Kubernetes manifests for every container and network configuration, generate kube provides a starting point, saving significant time and reducing the chance of syntax errors.

Internally, generate kube inspects the properties of your Podman pod and its containers. It looks at:

• Pod Name: Becomes the Kubernetes Pod metadata name.
• Container Names: Become Kubernetes container name fields.
• Container Images: Directly map to Kubernetes image fields.
• Port Mappings: This is where it gets interesting. Podman’s -p 8080:80 maps a host port to a container port. In Kubernetes, a Pod doesn’t have a "host" in the same sense; it runs within a cluster node. generate kube translates this to a Kubernetes ports definition with containerPort and hostPort. While hostPort is valid in Kubernetes, it’s often discouraged for production use due to potential port conflicts and limited scheduling flexibility. Podman is essentially generating a Pod that, if deployed as-is, would attempt to expose container ports directly on the node, similar to how Podman’s -p works.
• Networking: Podman pods share a network namespace by default. generate kube doesn’t explicitly represent this shared network namespace in the YAML because Kubernetes Pods, by design, share a network namespace. The generated YAML relies on Kubernetes’ default behavior.

The hostPort mapping in the generated YAML is a key detail. When you run a Kubernetes Pod with hostPort specified, the container’s port is exposed on the node where the pod is scheduled. This is functionally similar to Podman’s -p flag, which maps a port on your local machine (the "host") to the container. However, in a production Kubernetes environment, you’d typically use a Service (like NodePort, LoadBalancer, or ClusterIP) to expose your application, rather than relying on hostPort directly on the Pod. This is because hostPort can lead to scheduling constraints (a pod can only be scheduled on a node if the hostPort is available) and potential port conflicts if multiple pods try to use the same hostPort on the same node.

The next concept you’ll likely encounter is how to properly expose this Pod in a Kubernetes cluster using a Service.