Updating CNI Plugins for Podman: A Step-by-Step Guide

Posted on by Michael McCulley

One night, while trying to answer my newest questions:

  • What the hell is Podman?
  • Is it better than Docker?
  • Wait, it’s got pods? Well… Pod…man. Okay, yeah, that checks out.

I ran into an odd error, while creating a network, that the good old interwebs said was a bug that had been hanging around in Podman for over a year. No bueno, Podman. Seriously…

But I don’t like to back down, and this error raised some good questions too.

The Error

WARN[0000] Error validating CNI config file /home/mike/.config/cni/net.d/cni-podman1.conflist: [plugin bridge does not support config version "1.0.0" plugin portmap does not support config version "1.0.0" plugin firewall does not support config version "1.0.0" plugin tuning does not support config version "1.0.0"]

First thought? Well, let’s be real — WTF?! But really, the question was, “What is a CNI config or plugin?”

Down the rabbit hole I went. First, trying to understand the error, getting a little context about CNI along the way. The kicker? No one had a fix. Some suggested downgrading Podman versions, or editing the conflist files. Those are solutions, but not good solutions, and even the latest release still had the bug? I don’t want to use old software because the new software is buggy, and I don’t want to have to manually edit a file every time I create a network from the CLI. What the hell?!

Okay, next question: “What exactly is CNI, and how can I upgrade the plugins?” After some apt searches, googling and a deep GitHub dive, I found that CNI (Container Networking Interface) plugins usually install automatically with Kubernetes related software. You almost never hear about them unless something breaks. Finding an upgrade package, or instructions for upgrading them? Good luck!

But there is a way

So here’s how you update the CNI plugins. This should work if you are using Podman, Rancher, or Kubernetes in Linux.

Why Update the CNI Plugins?

CNI plugins are essential for managing container networking, and having an outdated or broken version can cause all sorts of issues. By updating the plugins, we can:

  • Fix compatibility issues with newer configurations.
  • Add support for new networking features.
  • Resolve bugs in older versions.

Steps to Update CNI Plugins

1. Determine Your Architecture for the Correct Release

First, figure out your system’s architecture. This helps ensure you download the correct version of the CNI plugins.

export ARCH_CNI=$( [ $(uname -m) = aarch64 ] && echo arm64 || echo amd64)

If you’re on ARM64 (like a Raspberry Pi), this command will set ARCH_CNI to arm64. For most desktop or server environments, it will be amd64.

2. Set the Latest Release Version

Now, set the CNI plugin version you want to install. You can find the latest version on the [CNI Plugins GitHub releases page](https://github.com/containernetworking/plugins/releases).

export CNI_PLUGIN_VERSION=v1.6.0

In this example, we’re using version v1.6.0.

3. Download the CNI Plugins

Download the appropriate version of the CNI plugins using curl. This command will dynamically grab the correct release based on your architecture and version settings:

curl -L -o cni-plugins.tgz "https://github.com/containernetworking/plugins/releases/download/${CNI_PLUGIN_VERSION}/cni-plugins-linux-${ARCH_CNI}-${CNI_PLUGIN_VERSION}.tgz"

This will download the CNI plugins archive to your current directory.

4. Extract the Plugins to a Safe Location

You’ll need a place to dump the plugins. Create a directory for that:

mkdir ~/src/cni

Now extract the downloaded archive into this directory:

sudo tar -C ~/src/cni -xzf cni-plugins.tgz

5. Backup the Old CNI Plugin Folder

Before replacing the existing CNI plugins, it’s always a good idea to back up the old directory, just in case. The location of your CNI plugins may vary, but the default path is usually `/usr/lib/cni`:

sudo mv /usr/lib/cni /usr/lib/cni.old

6. Install the New CNI Plugins

With the old CNI plugins backed up, you can now copy the updated plugins to the correct location:

sudo cp -rf ~/src/cni/ /usr/lib/cni

This will replace the existing CNI plugins with the updated ones.

TLDR – Just give me the fix already!

# Determine ARCH for correct release
export ARCH_CNI=$( [ $(uname -m) = aarch64 ] && echo arm64 || echo amd64)

# Set to latest release version (https://github.com/containernetworking/plugins/releases)
export CNI_PLUGIN_VERSION=v1.6.0

# Grab the latest release version
curl -L -o cni-plugins.tgz "https://github.com/containernetworking/plugins/releases/download/${CNI_PLUGIN_VERSION}/cni-plugins-linux-${ARCH_CNI}-${CNI_PLUGIN_VERSION}".tgz

# We need a place to dump this archive to somewhere "safe"
mkdir ~/src/cni

# Dump the archive
sudo tar -C ~/src/cni -xzf cni-plugins.tgz

# rename the old plugin folder (location depends on your environment)
# I am working in wsl Ubuntu
sudo mv /usr/lib/cni /usr/lib/cni.old

# replace that broken shiz with some hopefully non-broken shiz
sudo cp -rf ~/src/cni/ /usr/lib/cni

Conclusion

This worked for me, and should resolve THIS particular issue. I have no clue if it will introduce new issues. I just figured this out about an hour ago, and figured I’d write this up prior to testing. If you see this article, then I tested it and it worked for the purposes of tonight’s experiment. Let me know if it works for you or not.

At this point, I will probably keep my CNI plugins up to date to avoid network-related headaches in the future, since it seems to be important to the container world. Who doesn’t develop in containers of some kind these days?

If you follow the above instructions, please remember to back up your original files before making any changes. If you run into any issues afterwards, just revert the changes.

Now, I can go back to trying to figure out if Podman is better than Docker, or just… different.