mirror of
https://github.com/containers/podman.git
synced 2025-05-17 15:18:43 +08:00
[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>
This commit is contained in:
@ -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.
|
||||
|
@ -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.
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
```
|
||||
|
||||
|
@ -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**
|
||||
|
||||
|
@ -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 container’s port 80 (where the Nginx server is
|
||||
|
Reference in New Issue
Block a user