Of the new features in Podman v4.0, one of the most important is a new network stack, written from scratch in Rust to support Podman. The new stack is composed of two tools, the Netavark network setup tool and the Aardvark DNS server. Together, they offer several advantages over the existing Container Networking Interface (CNI) stack, including:
- Better IPv6 support
- Improved support for containers in multiple networks
- Improved performance
We've received a lot of questions about the reasons for this change. Podman has used the CNI to manage container networking since its first release in early 2018. However, as users' container environments and networks became more complex, it was clear that Podman's and the CNI's primary needs were diverging.
Podman aims to deliver a dedicated single-node container management tool, and the CNI was created to serve Kubernetes, so it is inherently based on clusters. Podman requires new functionality, such as support for container names and aliases in Domain Name System (DNS) lookups, that's not very useful to the CNI. Meanwhile, the CNI project is considering deprecating functionality that Podman relies on because it is not needed to support Kubernetes.
Given the inherent tension between Podman's goals and the CNI's, our team evaluated the options and decided that our best course of action was to create Netavark and Aardvark and tailor them to the needs of Podman's users.
What are Netavark and Aardvark?
Netavark and Aardvark work together to enable container networking. Netavark is a direct counterpart to the CNI. It configures network bridges, firewall rules, and system settings to allow containers to access the internet. Unlike the CNI, however, Netavark does not use a plugin model. Instead, it performs all required setup itself.
Aardvark is a DNS server Netavark uses to service container DNS requests and enable containers to resolve other containers by their names or aliases. In CNI, the dnsname plugin provides this functionality. Aardvark is activated by Netavark when containers are running and automatically exits when all containers have exited.
[ Learn from those who have been there. Download Tales from the field: A system administrator's guide to IT automation. ]
Three new features
In its initial release, the new Netavark and Aardvark stack continues to support almost all of the CNI's features and adds three primary improvements.
1. IPv6 improvements
IPv6 compatibility with Podman has long been an issue, and we have addressed it in Podman v4.0. IPv6 networks with Network Address Translation (NAT) and port forwarding are now fully tested and supported by Netavark, and static IPv6 addresses can be assigned to containers in these networks.
2. Containers in multiple networks
For containers in multiple networks, it is now possible to specify static IPv4, IPv6, and MAC addresses on a per-network basis; previously, this was only possible for containers joined to a single network. Podman 4.0 also improves DNS resolution for containers in multiple networks. In previous Podman versions, a container could resolve the names of other containers only in the first network it joined. Now, containers can resolve other containers in every network they join.
3. Performance improvements
By abandoning the CNI's plugin model, Netavark and Aardvark significantly improve performance. The CNI requires numerous plugins to execute in sequence to configure the network. Instead, Netavark performs all of the required setup in a single tool, avoiding significant overhead. This should be visible to users through even a simple podman run command, as network configuration was one of the most prolonged portions of container setup. While this was not a Netavark design goal, it has been a welcome change.
[ Learn what it takes to develop cloud-native applications using modern tools such as microservices. Download the eBook Kubernetes-native microservices with Quarkus and MicroProfile. ]
How Podman is taking advantage of the new stack
Podman has seen many changes to take advantage of this new functionality. Containers can now set static IP, IPv6, and MAC addresses on a per-network basis (before, these were supported only for containers in a single network) using advanced network options, such as:
podman run –network testnet1:ip=10.88.0.4,mac=11:22:33:44:55:66 ….
These options can also be set when connecting to a new network via podman network connect, for example:
podman network connect –ip 172.16.128.100 –ip6 fd11:2222:3333::1 testnet2 myctr
Support for creating dual-stack networks is also improved. The podman network create command now accepts all subnet-related options multiple times, allowing IPv4 and IPv6 subnets to be specified simultaneously.
Netavark and Aardvark's initial releases focus on attaining feature parity with CNI to ensure a smooth migration, but we're far from done adding features. Most importantly, we are looking to improve our support for alternate firewall systems. Netavark, like CNI, presently supports only systems using iptables firewalls. In a future release, we are looking to add support for nftables and firewalld as Netavark backends. We are also looking to improve support for IPv6 when using rootless Podman.
CNI compatibility remains
The Podman team recognizes that not all Podman users will be able to use Netavark. Existing containers in nondefault networks cannot be converted to Netavark, and Netavark doesn't support advanced CNI plugins (for example, connecting to Kubernetes networks created using Flannel). To ensure a smooth transition, we will continue to support CNI with Podman, and existing Podman installations will continue to use CNI for networking.
New installations can opt to use CNI by explicitly specifying it via the containers.conf configuration file, using the network_backend field. CNI and Netavark cannot be used simultaneously in order to avoid conflicts in the configurations the two create.
What's next?
The new network stack is a very exciting moment for the Podman team. It's the culmination of many months of great effort (and more than a little frustration!). In Netavark and Aardvark, we've delivered many new features, and we look forward to using them as the foundation for even more improvements. Netavark and Aardvark are available now in upstream Podman and should be arriving in Fedora 36, RHEL 9.0, and (as Tech Preview) RHEL 8.6.
关于作者
Matt Heon has been a software engineer on Red Hat's Container Runtimes team for the last five years. He's one of the original authors and lead maintainers of the Podman project. He focuses on container security, networking, and low-level development.
