Podman is an open source tool for managing OCI containers and container images. It allows users to find, run, build, share and deploy applications using containers. Some key points about Podman include: - It is daemonless, secure, and designed for Linux containers. - Podman manages the entire container lifecycle from creation to deletion. It handles mounting, networking, and the container runtime. - When running a container, Podman generates an OCI specification, pulls the image if needed, configures networking using Netavark, and uses Conmon to monitor the container process. - Podman 4 introduced a new network stack based on Netavark and Aardvark-dns

1. V0000000
Overview and internals
1
Podmanager

2. V0000000
2
Daemonless, open source, secure, Linux
native tool designed to make it easy to
find, run, build, share and deploy
applications using (OCI) Containers and
Container Images.

3. V0000000
The history
3
Project begins
Forked from CRI-O
Was called kpod
2017
2018
Podman v0.2 Released
First public release
Project is renamed Podman
Move fast with weekly releases
Podman v1.0 Released
First stable release
Default in RHEL 8
2019
2020
Podman v2.0 released
First release with REST API
Beginning of modern Podman
Podman v3.0 released
First release with Compose support
2021
2022
Podman v4.0 and v4.1 released
New network stack
Events in podman history

4. V0000000
4
Important container
vocabulary

5. V0000000
Vocabulary
5
Container Image or Image
An image is the basis of a container. Built of layers, each
containing part of a filesystem, and metadata.
Registry
Images are distributed via registries, web services that allow them
to be pulled (retrieved) and pushed (created or updated)
Container
A container is a set of processes that have been isolated from the
rest of the system. Containers are made from images.

6. V0000000
Vocabulary
6
Rootful, Rootless
Containers can be run both as the root user (rootful) and as
non-root users (rootless). Rootless containers has no additional
privileges then the user who created it.
Runtime
The OCI runtime is a low-level tool that creates a container based
on a standardized spec. Podman is not a Runtime, Podman is an
Engine that uses runtimes.
Namespace
Linux Kernel namespaces are the fundamental tool of container
isolation, limiting what parts of the system that a container can
see.

7. V0000000
7
Podman’s internals

8. V0000000
8
Manages container lifecycle - create,
start, stop, pause, unpause. Manages
mounting, networking as well.
Networking
Libpod
Connect containers to the internet via
iptables, slirp4netns, DNS. Handled by
Netavark and Aardvark.
CLI
Customize container configuration via
over 120 CLI flags to create an OCI spec
for the container
Podman components
Podman is modular in nature

9. V0000000
9
Creates the container from an OCI spec,
managing kernel namespaces,
capabilities, resource limits
Conmon
Container runtime
Extremely lightweight container monitor.
Manages logging, attaching, records exit
codes.
OCI
Standardized specification for containers
and images that Podman uses. Allows us
to interoperate with other tools.
Podman components continued …

10. V0000000
10
Low-level image library. Manages pushing
to and pulling from registries.
Containers-Common
Containers Image
Common code for managing networking
and images
Containers Storage
Low-level storage library. Manages
storage of images and containers.
Podman components continued …

11. V0000000
11
Allows rootless Podman to work. Grants
Podman the ability to use additional UIDs
and GIDs and mount filesystems.
Database
Rootless user namespace
Maintain a list of current containers and
pods and their current state.
Buildah
A tool that facilitates building OCI
container images
Podman components continued …

12. V0000000
12
Anatomy of running a
container

13. V0000000
To populate the rootless user namespace,
Podman invokes newuidmap and newgidmap
which add extra users and groups.
13
If rootless, podman creates the rootless user
namespace. This occurs immediately after
you hit ENTER.
What happens when you execute ‘podman run’?
Anatomy of a container with Podman

14. V0000000
14
Podman CLI collects
descriptive information
about a container from the
user and defaults
otherwise.
Anatomy of a container with Podman
The input is validated and
defaults are applied.
If the image is not already in
local storage, the image is
pulled.

15. V0000000
The container is created in libpod. The OCI
spec and and other information is stored in
the database.
15
An OCI specification is created by combining
the values from the user, the defaults, and
values embedded in an image’s metadata.
Anatomy of a container with Podman continued ...

16. V0000000
16
Container startup begins.
The container’s root
filesystem is mounted.
Anatomy of a container with Podman continued ...
The container’s network
namespace is configured to
access the internet by
Netavark.
The OCI spec is finalized
and saved to disk.

17. V0000000
17
The Conmon container
monitor is invoked by
Podman and double-forks.
Anatomy of a container with Podman continued ...
Common invokes the OCI
runtime to create the
container.
The OCI runtime finishes
container setup and
executes the container
entrypoint

18. V0000000
18
When the container exits,
Conmon records its exit
code and invokes Podman
to clean up the container.
Anatomy of a container with Podman continued ...
Podman calls Netavark to
tear down the container’s
network.
Podman calls the OCI
runtime to delete the
container.

19. V0000000
19
Podman unmounts
the container’s
storage.
Anatomy of a container with Podman continued ...
Podman reads the
container’s exit code and
records it in the database.

20. V0000000
20
New network stack

21. V0000000
What is the new stack
21
The Podman network stack is
now based on two
components. Both were
written in Rust for performance
and reduction in binary size.
Netavark Aardvark-dns
Network setup
Configures all network interfaces and
firewall rules necessary for the
container to access the internet and
other containers.
http://github.com/containers/netavark
Container DNS server
Handles all DNS queries by
containers and allows them to resolve
other containers in the same network
by name.
http://github.com/containers/aardvark-dns
Overview

22. V0000000
Why overhaul the network stack
IPv6
We can now offer a much improved IPv6 experience out of the box
Advanced container DNS
Our existing DNS stack had serious limitations for containers in
multiple networks
Speed
Containers start noticeably faster
More focus on single node
The new stack does what Podman needs; not other projects’ needs.
22
Benefits of migrating

23. V0000000
Network setup and teardown
23
Podman Netavark Aardvark-dns
How the stack works

24. V0000000
24
New installations automatically use
Netavark. Existing installations will remain
on previous stack (CNI) until migrated.
To migrate, it is usually necessary to remove
all containers with podman system reset.
Can also force Netavark via config file.
Usage
Both new and old network stacks are supported

25. V0000000
25
Podman machine

26. V0000000
Podman machine allows you to run Podman on a
host that is not capable of running Linux
containers. It configures a virtual machine that
where the Linux containers are run and
communicates with the host operating system.
▸ Uses Fedora CoreOS
▸ Black box approach
▸ No cost, no sign-up, no registration
26
Deploy Podman in a virtual machine
What is Podman machine

27. V0000000
27
Guided install on Windows. Uses WSL for
virtualization.
Linux
Windows
Any distribution that packages Podman
should be able to run the machine
command.
Mac OS
Install using Homebrew (the missing
package manager). Future will have a
self-contained Podman (no brew
needed)
Supported hosts
Available for x86_64 and aarch64 architectures

28. V0000000
Machines features
28
Podman’s API sockets are extended to the
host OS for API use
Interaction with sockets
Expose container ports on the host
operating system
Port mapping
podman machine init
Easy setup
Mount directories from the host into the
machine for use with containers
Volume mounting

29. V0000000
29
Podman 4 highlights

30. V0000000
Podman 4
30
Podman 4 is the largest release
we have done. It includes 78
new features and a slew of bug
fixes.
776 90
Commits
Across 6 months of development
Contributors
Most from the community
https://github.com/containers/podman/releases/tag/v4.0.0

31. V0000000
31
Written in rust, customized for Podman networking, works in rootless, no
outward facing change
▸ IPv6 support
▸ Better Container-Container DNS support
▸ Improved startup time
▸ Focus on single node networking
Podman 4
New network stack

32. V0000000
Kube
32
Volumes from configMaps with play kube are
now supported.
Volume support
Options have been been added for
no-hosts, replace, log-opt, network,
annotation, context-dir, and more.
New options for play kube
Kubernetes init-style containers can be
generated by Podman. Play and generate
kube can also use.
Init
When running pods based on kubernetes
YAML, container images can be built locally
and automatically.
Build images with play kube
Generate and play enhancements

33. V0000000
Kube continued …
33
Set default resource limits with play kube
when not defined in kube yaml
Resource control
Support for ENV variables from fieldRef and
resourceFieldRef sources.
Injecting environment variables
Why use a file format that only works with
Docker. Kube YAML works with Podman and
Kubernetes. Podman makes this easy.
Stop using docker compose
Generate and play enhancements

34. V0000000
34
Lots of changes for Podman machine. This will be a theme in Podman 4
now and into the future.
▸ Support for windows and installer
▸ Volume support included in Podman 4.1 (now available)
▸ Socket mapping between virtual machine and host
▸ Ability to change hardware allocations (CPU, memory, disk)
Podman 4
Podman machine improvements

35. V0000000
35
Pods now feature greatly improved support for sharing resources
between containers. Adding a resource to a pod makes it accessible to all
containers in the pod.
▸ Volumes
▸ Devices
▸ Security settings
▸ Sysctls
▸ More to come
Pod Enhancements

36. V0000000
Podman 4.1 Highlights
36
Podman has supported Compose v1 since
Podman 3.0, but the Compose v2 rewrite
required extra work.
Support for Docker Compose v2
Podman 4.0 and 4.1 has enhanced build
features to better support BuildKit.
Build enhancements
A volume mount for $HOME:$HOME by
default. On Mac OS, it literally is
/Users/<name> on the host and
/Users/<name> in the machine
Default volume mounts
The Podman team prioritized shrinking the
binary size of podman and podman-remote.
Podman 4.1 is 15% smaller than 4.0.
Binary size reduction
Concentrated on user feedback and bugs

37. V0000000
Podman Build Improvements
37
Explicitly specify what architecture your build
targets in FROM instructions.
Improved multi-architecture support
Manifest lists can now be tagged just like
images.
Manifest List enhancements
Builds can now use tmpfs, cache, bind
mounts (including overlay bind mounts), and
images. Mounts from another stage are
possible.
New mount types are available
Instead of creating an image directly, make a
tarball, or a directory.
Better Control over Output
Adding advanced features from BuildKit

38. V0000000
38
Community

39. V0000000
Interaction with community
39
A monthly meeting on the third Thursday
for discussion of technical topics related
to Podman.
Mailing List
Community cabal
An email list for suggestions, support, and
more.
podman@lists.podman.io
Podman monthly meeting
The first Tuesday of every even
numbered month. Focuses on project
news and demos of new features and new
ways to use Podman
Podman is a happy, healthy project. Join us!

40. V0000000
Podman continues to gain momentum in the
container community.
▸ 395 contributors
▸ Over 15,000 commits
▸ 13,700 github stars
40
Podman is a happy, healthy project
Github statistics

41. V0000000
Social media and communication
Github – http://github.com/containers/podman
Web – http://podman.io
Twitter – @Podman_io
Youtube – https://www.youtube.com/c/Podman
41

42. V0000000
42
End of prepared material