Merge pull request #169 from jpetazzo/what-is-cni

Add slide about CNI

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,
   <br/>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
     <br/>(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)