1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
|
# Container Runtime Interface (CRI) Networking Specifications
## Introduction
[Container Runtime Interface (CRI)](container-runtime-interface.md) is
an ongoing project to allow container
runtimes to integrate with kubernetes via a newly-defined API. This document
specifies the network requirements for container runtime
interface (CRI). CRI networking requirements expand upon kubernetes pod
networking requirements. This document does not specify requirements
from upper layers of kubernetes network stack, such as `Service`. More
background on k8s networking could be found
[here](http://kubernetes.io/docs/admin/networking/)
## Requirements
1. Kubelet expects the runtime shim to manage pod's network life cycle. Pod
networking should be handled accordingly along with pod sandbox operations.
* `RunPodSandbox` must set up pod's network. This includes, but is not limited
to allocating a pod IP, configuring the pod's network interfaces and default
network route. Kubelet expects the pod sandbox to have an IP which is
routable within the k8s cluster, if `RunPodSandbox` returns successfully.
`RunPodSandbox` must return an error if it fails to set up the pod's network.
If the pod's network has already been set up, `RunPodSandbox` must skip
network setup and proceed.
* `StopPodSandbox` must tear down the pod's network. The runtime shim
must return error on network tear down failure. If pod's network has
already been torn down, `StopPodSandbox` must skip network tear down and proceed.
* `RemovePodSandbox` may tear down pod's network, if the networking has
not been torn down already. `RemovePodSandbox` must return error on
network tear down failure.
* Response from `PodSandboxStatus` must include pod sandbox network status.
The runtime shim must return an empty network status if it failed
to construct a network status.
2. User supplied pod networking configurations, which are NOT directly
exposed by the kubernetes API, should be handled directly by runtime
shims. For instance, `hairpin-mode`, `cni-bin-dir`, `cni-conf-dir`, `network-plugin`,
`network-plugin-mtu` and `non-masquerade-cidr`. Kubelet will no longer handle
these configurations after the transition to CRI is complete.
3. Network configurations that are exposed through the kubernetes API
are communicated to the runtime shim through `UpdateRuntimeConfig`
interface, e.g. `podCIDR`. For each runtime and network implementation,
some configs may not be applicable. The runtime shim may handle or ignore
network configuration updates from `UpdateRuntimeConfig` interface.
## Extensibility
* Kubelet is oblivious to how the runtime shim manages networking, i.e
runtime shim is free to use [CNI](https://github.com/containernetworking/cni),
[CNM](https://github.com/docker/libnetwork/blob/master/docs/design.md) or
any other implementation as long as the CRI networking requirements and
k8s networking requirements are satisfied.
* Runtime shims have full visibility into pod networking configurations.
* As more network feature arrives, CRI will evolve.
## Related Issues
* Kubelet network plugin for client/server container runtimes [#28667](https://github.com/kubernetes/kubernetes/issues/28667)
* CRI networking umbrella issue [#37316](https://github.com/kubernetes/kubernetes/issues/37316)
|
