[CI:DOCS] Add CNI deprecation notices to documentation

Where the terms CNI and cni are used in documentation like man pages,
readme's, and tutorials, we have begun to add deprecation notices where
applicable. In cases where netavark cannot do what CNI can, those have
been left alone.

[NO NEW TESTS NEEDED]

Signed-off-by: Brent Baude <bbaude@redhat.com>
pull/17162/head
Brent Baude 2023-01-18 14:11:16 -06:00
parent 0768680b98
commit f07aa2adde
6 changed files with 16 additions and 20 deletions

View File

@ -25,7 +25,7 @@ At a high level, the scope of Podman and libpod is the following:
* Support for multiple container image formats, including OCI and Docker images.
* Full management of those images, including pulling from various sources (including trust and verification), creating (built via Containerfile or Dockerfile or committed from a container), and pushing to registries and other storage backends.
* Full management of container lifecycle, including creation (both from an image and from an exploded root filesystem), running, checkpointing and restoring (via CRIU), and removal.
* Full management of container networking, using CNI, Netavark, and slirp4netns
* Full management of container networking, using Netavark.
* Support for pods, groups of containers that share resources and are managed together.
* Support for running containers and pods without root or other elevated privileges.
* Resource isolation of containers and pods.
@ -86,7 +86,7 @@ Podman uses OCI projects and best of breed libraries for different aspects:
- Runtime: We use the [OCI runtime tools](https://github.com/opencontainers/runtime-tools) to generate OCI runtime configurations that can be used with any OCI-compliant runtime, like [crun](https://github.com/containers/crun/) and [runc](https://github.com/opencontainers/runc/).
- Images: Image management uses the [containers/image](https://github.com/containers/image) library.
- Storage: Container and image storage is managed by [containers/storage](https://github.com/containers/storage).
- Networking: Networking support through use of [Netavark](https://github.com/containers/netavark) and [Aardvark](https://github.com/containers/aardvark-dns). Support for [CNI](https://github.com/containernetworking/cni) is also available. Rootless networking is handled via [slirp4netns](https://github.com/rootless-containers/slirp4netns).
- Networking: Networking support through use of [Netavark](https://github.com/containers/netavark) and [Aardvark](https://github.com/containers/aardvark-dns). Rootless networking is handled via [slirp4netns](https://github.com/rootless-containers/slirp4netns).
- Builds: Builds are supported via [Buildah](https://github.com/containers/buildah).
- Conmon: [Conmon](https://github.com/containers/conmon) is a tool for monitoring OCI runtimes, used by both Podman and CRI-O.
- Seccomp: A unified [Seccomp](https://github.com/containers/common/blob/main/pkg/seccomp/seccomp.json) policy for Podman, Buildah, and CRI-O.

View File

@ -1,5 +1,8 @@
## `cni` ##
**Note**: CNI is being deprecated from Podman and support will be dropped at a future date. Use of netavark is now
advised and is the default network backend for Podman.
There are a wide variety of different [CNI](https://github.com/containernetworking/cni) network configurations. This
directory just contains an example configuration that can be used as the
basis for your own configuration.

View File

@ -10,7 +10,8 @@ podman\-network - Manage Podman networks
The network command manages networks for Podman.
Podman supports two network backends [Netavark](https://github.com/containers/netavark)
and [CNI](https://www.cni.dev/). Support for netavark was added in Podman v4.0. To configure
and [CNI](https://www.cni.dev/). Netavark is the default network backend and was added in Podman v4.0. CNI will be
deprecated in the future in preference of Netavark. To configure
the network backend use the `network_backend`key under the `[Network]` in
**[containers.conf(5)](https://github.com/containers/common/blob/master/docs/containers.conf.5.md)**.
New systems should use netavark by default, to check what backed is used run

View File

@ -34,7 +34,7 @@ Print usage statement
#### **--rootless-netns**
Join the rootless network namespace used for CNI and netavark networking. It can be used to
Join the rootless network namespace used for netavark networking. It can be used to
connect to a rootless container via IP address (bridge networking). This is otherwise
not possible from the host network namespace.
@ -87,20 +87,12 @@ $ podman unshare --rootless-netns ip addr
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: tap0: <BROADCAST,UP,LOWER_UP> mtu 65520 qdisc fq_codel state UNKNOWN group default qlen 1000
link/ether 36:0e:4a:c7:45:7e brd ff:ff:ff:ff:ff:ff
link/ether aa:8c:0b:73:98:f6 brd ff:ff:ff:ff:ff:ff
inet 10.0.2.100/24 brd 10.0.2.255 scope global tap0
valid_lft forever preferred_lft forever
inet6 fe80::340e:4aff:fec7:457e/64 scope link
valid_lft forever preferred_lft forever
3: cni-podman2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 5e:3a:71:d2:b4:3a brd ff:ff:ff:ff:ff:ff
inet 10.89.1.1/24 brd 10.89.1.255 scope global cni-podman2
valid_lft forever preferred_lft forever
inet6 fe80::5c3a:71ff:fed2:b43a/64 scope link
valid_lft forever preferred_lft forever
4: vethd4ba3a2f@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master cni-podman2 state UP group default
link/ether 8a:c9:56:32:17:0c brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::88c9:56ff:fe32:170c/64 scope link
inet6 fd00::a88c:bff:fe73:98f6/64 scope global dynamic mngtmpaddr
valid_lft 86389sec preferred_lft 14389sec
inet6 fe80::a88c:bff:fe73:98f6/64 scope link
valid_lft forever preferred_lft forever
```

View File

@ -93,10 +93,10 @@ Path to the command binary to use for setting up a network. It is currently onl
#### **--network-config-dir**=*directory*
Path to the directory where network configuration files are located.
For the CNI backend the default is "/etc/cni/net.d" as root
and "$HOME/.config/cni/net.d" as rootless.
For the netavark backend "/etc/containers/networks" is used as root
and "$graphroot/networks" as rootless.
For the CNI backend the default is "/etc/cni/net.d" as root
and "$HOME/.config/cni/net.d" as rootless. CNI will be deprecated from Podman in the future for netavark.
#### **--noout**

View File

@ -32,7 +32,7 @@ port mapping. Depending on the firewall implementation, we have observed firewa
ports being opened automatically due to running a container with a port mapping (for
example). If container traffic does not seem to work properly, check the firewall
and allow traffic on ports the container is using. A common problem is that
reloading the firewall deletes the cni/netavark iptables rules resulting in a loss of
reloading the firewall deletes the netavark iptables rules resulting in a loss of
network connectivity for rootful containers. Podman v3 provides the podman
network reload command to restore this without having to restart the container.
@ -128,7 +128,7 @@ client can connect to the container.
Now run the container.
```
$ podman run -dt --name webserver --net cni-podman1 -p 8081:80 quay.io/libpod/banner
$ podman run -dt --name webserver --net podman1 -p 8081:80 quay.io/libpod/banner
269fd0d6b2c8ed60f2ca41d7beceec2471d72fb9a33aa8ca45b81dc9a0abbb12
```
Note in the above run command, the containers port 80 (where the Nginx server is