Pods and CNI Networks in Podman: Best Practices for Container Networking

When working with containerized applications, networking and service communication are critical components of a successful deployment strategy. Podman, the daemonless container engine that’s gaining significant traction in enterprise environments, offers two powerful concepts borrowed from Kubernetes: Pods and CNI (Container Network Interface) networks. Understanding these concepts and applying industry best practices can make your deployments more secure, scalable, and maintainable.

What Are Pods in Podman?

A Pod in Podman is a group of one or more containers that share fundamental system resources, creating a tightly coupled execution environment. This concept mirrors Kubernetes Pods and provides several shared namespaces:

Network namespace: All containers share the same IP address and port space
IPC namespace: Enables inter-process communication between containers
UTS namespace: Shared hostname
Optionally, shared volumes: Persistent data accessible across containers

This shared namespace model means containers within the same Pod can communicate seamlessly via localhost, completely eliminating DNS complexity and network overhead. Pods are the ideal solution for tightly coupled services that need to operate as a cohesive unit.

Common Use Cases for Pods

Database with administration tool: PostgreSQL + pgAdmin, MySQL + phpMyAdmin
Application with sidecar pattern: Web app + logging agent (Fluentd), app + metrics exporter (Prometheus exporter)
Service mesh components: Application + Envoy proxy
Init container patterns: Database migration tool + main application
Multi-tier caching: Application + Redis + session manager

Benefits of Pods

Simplified Communication

Use localhost instead of container names, DNS resolution, or IP addresses
Zero network latency between containers
Simplified security configurations for inter-container communication

Unified Lifecycle Management

Start, stop, and restart as a single atomic unit
Guaranteed co-scheduling (containers always run together)
Simplified health checks and monitoring

Streamlined Port Management

Expose Pod ports once at the Pod level, not per container
Avoid port conflicts between containers in the Pod
Single network interface for external access

Resource Efficiency

Shared network stack reduces overhead
Single infra container manages shared namespaces
Reduced memory footprint compared to separate containers

What Is CNI (Container Network Interface)?

CNI is an industry-standard specification for container networking developed by the Cloud Native Computing Foundation (CNCF). It’s used by Podman, Kubernetes, OpenShift, Mesos, and other container orchestration platforms. CNI defines a plugin-based architecture that handles how containers connect to networks, IP address allocation, DNS resolution, and network isolation.

CNI Architecture in Podman

Podman uses netavark (the modern CNI backend) or the legacy CNI plugins to manage network configurations. Each network is defined by a JSON configuration file that specifies:

Network driver (bridge, macvlan, ipvlan)
Subnet and IP range allocation
DNS settings and domain names
Network isolation and firewall rules

Key Features of CNI Networks

Bridge Networking (Default)

Creates a virtual bridge (similar to docker0)
Provides NAT for outbound connectivity
Enables container-to-container communication on the same host

DNS-Based Service Discovery

Containers on the same CNI network can resolve each other by name
Automatic DNS entries for container names
No need for hard-coded IP addresses

Network Isolation and Security

Multiple networks provide namespace isolation
Containers on different networks cannot communicate by default
Firewall rules automatically applied at the network level

Advanced Networking Options

macvlan: Assign unique MAC addresses to containers
ipvlan: Layer 3 routing without MAC address overhead
Custom subnets: Control IP addressing schemes
IPv6 support: Dual-stack networking capabilities

Creating and Managing CNI Networks

# Create a custom bridge network
podman network create --driver bridge --subnet 10.89.0.0/24 appnet

# List all networks
podman network ls

# Inspect network configuration
podman network inspect appnet

# Remove a network
podman network rm appnet

Pods vs. CNI Networks: When to Use What

Understanding the distinction between these two concepts is crucial for designing effective container architectures.

Pods: Tightly Coupled Services

Use Pods when:

Containers must share the same network namespace (localhost communication required)
Services have a synchronized lifecycle (start/stop together)
You’re implementing sidecar or ambassador patterns
Containers need to share IPC or UTS namespaces
You want guaranteed co-location

Examples:

Web application + log aggregator
Database + backup agent
API service + authentication proxy

CNI Networks: Loosely Coupled Services

Use CNI Networks when:

Services are independent but need to communicate
You require DNS-based service discovery
Containers/Pods have different lifecycles or scaling requirements
You need network-level isolation between application tiers
Services might be on different hosts (future scaling)

Examples:

Frontend Pod → Backend API Pod → Database Pod
Microservices architecture with service-to-service communication
Multi-tenant environments requiring network isolation

Best Practice Decision Matrix

Scenario	Solution
App + sidecar logging container	Single Pod
Database + admin UI	Single Pod
Frontend ↔ Backend ↔ Database	Separate Pods on CNI network
Multiple microservices	Separate Pods on shared CNI network(s)
Development vs. Production isolation	Separate CNI networks

Should You Put Everything in One Pod?

Absolutely not. This is one of the most common anti-patterns in container orchestration.

While Pods dramatically simplify networking between containers, they create strong coupling that can severely limit your deployment flexibility:

Problems with Monolithic Pods

Scaling Limitations

Cannot scale individual services independently
All containers scale together, wasting resources
No horizontal pod autoscaling for specific services

Lifecycle Coupling

Restarting one container restarts the entire Pod
Updates to one service require Pod recreation
Increased downtime for maintenance operations

Resource Contention

Containers compete for shared CPU/memory limits
One misbehaving container can impact others
Difficult to set appropriate resource quotas

Deployment Complexity

Harder to implement rolling updates
Cannot version services independently
Increased blast radius for failures

Monitoring and Debugging

Logs from all containers mixed together
Harder to isolate performance issues
Complicated health check logic

The Single Responsibility Principle

Apply the single responsibility principle to Pods:

✅ Good: One logical unit per Pod

Pod: database-pod
  ├── postgres (primary service)
  └── postgres-exporter (monitoring sidecar)

Pod: admin-pod
  └── pgadmin (separate lifecycle)

Pod: app-pod
  ├── webapp (primary service)
  └── nginx-sidecar (reverse proxy)

❌ Bad: Everything in one Pod

Pod: monolith-pod
  ├── postgres
  ├── pgadmin
  ├── redis
  ├── webapp
  ├── nginx
  └── worker-queue

Industry-Standard Pod Design

One primary service per Pod (plus optional sidecars)
Sidecars should be auxiliary (logging, monitoring, proxying)
Separate Pods for services with different scaling needs
Use CNI networks for inter-Pod communication
Design for independent deployment and updates

Example Architecture: Real-World Multi-Tier Application

Here’s a production-ready architecture following best practices:

Network: appnet (10.89.0.0/24)
├── Pod: database-pod (10.89.0.10)
│   ├── postgres:15 (port 5432)
│   └── postgres-exporter (port 9187) [monitoring sidecar]
│
├── Pod: admin-pod (10.89.0.11)
│   └── pgadmin4 (port 80)
│
├── Pod: cache-pod (10.89.0.12)
│   ├── redis:7 (port 6379)
│   └── redis-exporter (port 9121) [monitoring sidecar]
│
├── Pod: backend-api-pod (10.89.0.20)
│   ├── fastapi-app (port 8000)
│   └── fluentd-sidecar (log aggregation)
│
└── Pod: frontend-pod (10.89.0.30)
    ├── nginx-webapp (port 80)
    └── nginx-exporter (port 9113) [monitoring sidecar]

Network: monitoring-net (10.89.1.0/24)
└── Pod: prometheus-pod (10.89.1.10)
    ├── prometheus (port 9090)
    └── grafana (port 3000)

Communication Flow

Frontend → Backend: DNS-based (backend-api-pod:8000)
Backend → Database: DNS-based (database-pod:5432)
Backend → Cache: DNS-based (cache-pod:6379)
All Pods → Prometheus: Metrics exporters accessible via CNI network
Containers within each Pod: localhost communication

Production-Ready Ansible Example

Here’s an enterprise-grade Ansible playbook implementing the database Pod with best practices:

---
- name: Deploy PostgreSQL Pod with pgAdmin
  hosts: container_hosts
  become: true
  vars:
    postgres_version: "15-alpine"
    pgadmin_version: "latest"
    pod_network: "appnet"
    postgres_data_path: "/opt/container-data/postgres"
    pgadmin_data_path: "/opt/container-data/pgadmin"
    
  tasks:
    - name: Create CNI network
      containers.podman.podman_network:
        name: "{{ pod_network }}"
        driver: bridge
        subnet: 10.89.0.0/24
        state: present

    - name: Create data directories
      ansible.builtin.file:
        path: "{{ item }}"
        state: directory
        mode: '0755'
        owner: root
        group: root
      loop:
        - "{{ postgres_data_path }}"
        - "{{ pgadmin_data_path }}"

    - name: Create Pod for PostgreSQL and pgAdmin
      containers.podman.podman_pod:
        name: database-pod
        state: created
        network: "{{ pod_network }}"
        publish:
          - "5432:5432"   # PostgreSQL
          - "8080:80"     # pgAdmin
        label:
          app: database
          tier: data

    - name: Run PostgreSQL container in Pod
      containers.podman.podman_container:
        name: postgres
        image: "docker.io/postgres:{{ postgres_version }}"
        pod: database-pod
        state: started
        env:
          POSTGRES_USER: "admin"
          POSTGRES_PASSWORD: "{{ vault_postgres_password }}"
          POSTGRES_DB: "production_db"
          PGDATA: "/var/lib/postgresql/data/pgdata"
        volume:
          - "{{ postgres_data_path }}:/var/lib/postgresql/data:Z"
        healthcheck:
          test: ["CMD-SHELL", "pg_isready -U admin"]
          interval: 10s
          timeout: 5s
          retries: 5
        label:
          component: database

    - name: Run pgAdmin container in Pod
      containers.podman.podman_container:
        name: pgadmin
        image: "docker.io/dpage/pgadmin4:{{ pgadmin_version }}"
        pod: database-pod
        state: started
        env:
          PGADMIN_DEFAULT_EMAIL: "[email protected]"
          PGADMIN_DEFAULT_PASSWORD: "{{ vault_pgadmin_password }}"
          PGADMIN_CONFIG_SERVER_MODE: "True"
          PGADMIN_CONFIG_MASTER_PASSWORD_REQUIRED: "False"
        volume:
          - "{{ pgadmin_data_path }}:/var/lib/pgadmin:Z"
        label:
          component: admin-ui

    - name: Generate systemd unit for Pod
      containers.podman.podman_generate_systemd:
        name: database-pod
        dest: /etc/systemd/system/
        restart_policy: always
        new: true

    - name: Enable and start Pod service
      ansible.builtin.systemd:
        name: pod-database-pod
        enabled: true
        state: started
        daemon_reload: true

Key Enhancements in This Example

Network Isolation: Dedicated CNI network
Data Persistence: Volume mounts with SELinux labels (:Z)
Health Checks: PostgreSQL readiness probe
Systemd Integration: Automatic restart and boot-time startup
Security: Passwords from Ansible Vault
Labels: Metadata for monitoring and management
Version Pinning: Controlled image versions

Advanced Topics and Best Practices

Security Considerations

Network Policies

# Create isolated network for sensitive data
podman network create --driver bridge --subnet 10.90.0.0/24 \
  --opt isolate=true secure-net

SELinux Context Always use :Z or :z flags for volume mounts on SELinux-enabled systems:

:Z: Private unshared label (recommended for single container)
:z: Shared label (for multi-container access)

User Namespaces Run containers as non-root users:

- name: Run rootless container
  containers.podman.podman_container:
    name: app
    image: myapp:latest
    userns: keep-id
    user: "1000:1000"

Performance Optimization

Resource Limits

- name: Container with resource constraints
  containers.podman.podman_container:
    name: backend
    memory: "2g"
    memory_reservation: "1g"
    cpus: "1.5"
    pids_limit: 200

Network Performance

Use host networking for high-throughput services (loses isolation)
Use macvlan for direct network access without bridge overhead
Consider SR-IOV for hardware-accelerated networking in VMs

Monitoring and Observability

Container Logs

# View Pod logs (all containers)
podman pod logs database-pod

# Follow specific container logs
podman logs -f postgres

Network Inspection

# Check Pod network details
podman pod inspect database-pod | jq '.[] | .InfraConfig.NetworkOptions'

# Verify DNS resolution
podman exec webapp ping -c 3 database-pod

Metrics Collection Integrate Prometheus exporters as sidecar containers in each Pod for comprehensive observability.

Troubleshooting Common Issues

DNS Resolution Problems

# Test DNS from within container
podman exec webapp nslookup database-pod

# Check network DNS settings
podman network inspect appnet | jq '.[].plugins[] | select(.type=="dnsname")'

Port Conflicts

# List all published ports
podman pod ps --format "{{.Name}}\t{{.Ports}}"

# Check host port bindings
ss -tulpn | grep -E ':(5432|8080)'

Permission Issues

# Check SELinux denials
ausearch -m avc -ts recent

# Verify volume mount permissions
podman unshare ls -la /opt/container-data/postgres

Key Takeaways

Use Pods for tightly coupled services that share lifecycle and need localhost communication
Use CNI networks for service discovery between independent Pods or containers
Never create monolithic Pods – design for single responsibility and independent scaling
Implement proper network isolation using separate CNI networks for different tiers or environments
Leverage sidecar patterns for cross-cutting concerns (logging, monitoring, proxying)
Always use systemd integration for production deployments with automatic restarts
Apply security best practices: SELinux labels, user namespaces, resource limits
Design for observability with health checks, logging sidecars, and metrics exporters

Migration Path from Docker

If you’re coming from Docker Compose:

Docker Compose services → Podman Pods (for tightly coupled) or separate containers on CNI network
Docker Compose networks → Podman CNI networks
Use podman-compose for gradual migration
Convert to systemd units for production

Conclusion

Podman’s implementation of Pods and CNI networks provides a powerful, Kubernetes-compatible approach to container networking without requiring a daemon or orchestrator. By understanding when to use Pods versus CNI networks, and following industry best practices for modular design, you can build container architectures that are secure, scalable, and maintainable.

The key is treating Pods as atomic units of deployment for tightly coupled services, while using CNI networks to enable communication between these independent units. This approach gives you the flexibility to scale, update, and manage components independently while maintaining clean service boundaries.

Start small with simple Pods, gradually introduce CNI networks for inter-service communication, and always design with production requirements in mind: monitoring, logging, security, and resilience.

Further Reading: