Skip to content
  • hosting
  • servers
  • infrastructure
  • podman

What Are Podman Pods?

DNS and IP Resolution

  • Podman pods function like a network stack.
  • Picture five VMs, each dedicated to a single application, working together to deliver a service. For example, "Firewall, Ingress, Database, SIEM, Frontend."
  • To make it work, your applications need access to the 'Database,' relying on your LAN's DHCP and DNS servers to cooperate for successful location resolution.

Docker Does This!

  • Docker handles this scenario well. Naming a Docker container 'Database' allows any container on the same network to access it seamlessly.

  • No worrying that the LAN hosting the VM takes care of it because it probably doesn't. Docker does for us.

  • This solution works for small-scale setups.

But What About Scalability?

  • Imagine needing a similar application with its own database, SIEM agent, firewall, and a different frontend. It might even share the same database or not.
  • To manage this, you ensure the containers are not on the same network, or at least have different names. However, scaling becomes complicated.

Pods to the Rescue!

  • Enter Podman pods. Create a pod, name it 'SuperApplication.'
  • A pod is essentially a network name and an IP address (possibly more in practice, but for this example, let's keep it simple).
  • Inside this pod, you can set up a Database, SIEM agent, firewall, ingress, and a frontend - each as its own container.
  • The magic happens because these components are in the same pod. They can communicate using localhost:port**, even though they're separate containers.
  • As you scale with Kubernetes, they'll continue to appear as local services to each other, even if they run on different servers.

** Note: useage of localhost is not recommended, especially if whatever application is listening only on ipv4 or 6, instead direct 127.0.0.1 or ::1 should be used to prevent failures due to dns responding with both addresses when an application is only listening on one or the other. Even though this may not make your application fully fail, it can very well cause a timeout while it tries the wrong address causing a 1-3 second timeout before it finally connects to the right loopback ip.

Added by Chat-GPT and heavily edited via lots of back and fourth with ChatGPT after using it for Grammer and Punctuation

Use Cases for Podman Pods

Podman pods offer several use cases, including:

  • Isolation: Podman pods provide a level of network isolation, allowing you to run multiple containers together while keeping them separated from containers in other pods. This is especially useful when you need to ensure that containers within a pod can communicate with each other but not with containers outside the pod.

  • Multi-Service Applications: When you have a complex application composed of multiple services, each service can be placed in the same pod, simplifying communication between them. This is particularly handy for microservices architectures.

  • Simplified Network Configuration: While network configuration is still necessary, Podman pods simplify communication between different containers. In cases where containers need to interact with each other, using localhost within the same pod reduces complexity. However, specific network settings, such as IPv6, may require additional configuration, and you'll need to configure Podman accordingly.

Benefits and Drawbacks

Benefits of using Podman pods include improved network isolation, simplified networking, and ease of use for multi-service applications. However, there are some drawbacks to consider:

  • Ease of Transition: If you're already familiar with Docker containers and looking to explore Podman pods, the transition can be relatively straightforward, as the fundamental networking concepts are similar. It's important to note that using Podman pods is optional and may not be the starting point for everyone.

  • Transitioning Naming Convention: When using Podman pods, there is a shift from individual container naming to groups of containers sharing a name. This transition might present a slight learning curve, particularly for those accustomed to unique container names in traditional Docker setups.

Best Practices

When working with Podman pods, consider the following best practices:

  • Consistent Naming: Use clear and consistent naming conventions for your pods and containers to make management and troubleshooting easier.

  • Security: Ensure that your pod's network configuration aligns with your security requirements. Consider using security features provided by Podman to enhance the overall security of your containers.