diff --git a/slides/kube/kubenet.md b/slides/kube/kubenet.md index 7c567584..0b8519dc 100644 --- a/slides/kube/kubenet.md +++ b/slides/kube/kubenet.md @@ -52,9 +52,9 @@ (15 are listed in the Kubernetes documentation) -- It *looks like* you have a level 3 network, but it's only level 4 +- Pods have level 3 (IP) connectivity, but *services* are level 4 - (The spec requires UDP and TCP, but not port ranges or arbitrary IP packets) + (Services map to a single UDP or TCP port; no port ranges or arbitrary IP packets) - `kube-proxy` is on the data path when connecting to a pod or container,
and it's not particularly fast (relies on userland proxying or iptables) @@ -72,10 +72,32 @@ - Unless you: - routinely saturate 10G network interfaces - - count packet rates in millions per second - - run high-traffic VOIP or gaming platforms - - do weird things that involve millions of simultaneous connections
(in which case you're already familiar with kernel tuning) + +- If necessary, there are alternatives to `kube-proxy`; e.g. + [`kube-router`](https://www.kube-router.io) + +--- + +## The Container Network Interface (CNI) + +- The CNI has a well-defined [specification](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration) for network plugins + +- When a pod is created, Kubernetes delegates the network setup to CNI plugins + +- Typically, a CNI plugin will: + + - allocate an IP address (by calling an IPAM plugin) + + - add a network interface into the pod's network namespace + + - configure the interface as well as required routes etc. + +- Using multiple plugins can be done with "meta-plugins" like CNI-Genie or Multus + +- Not all CNI plugins are equal + + (e.g. they don't all implement network policies, which are required to isolate pods)