5 CNIs and providing the Pod with a network

 

This chapter covers

  • Defining the Kubernetes SDN in terms of the kube-proxy and CNI
  • Connecting between traditional SDN Linux tools and CNI plugins
  • Using open source technologies to govern the way CNIs operate
  • Exploring the Calico and Antrea CNI providers

Software-Defined Networking (SDN) traditionally manages load balancing, iso-lation, and security of VMs in the cloud, as well as in many on-premise data centers. SDNs are a convenience which eases the burden on system administrators, allowing reconfiguration of large data center networks every week, or maybe every day, when new VMs are created or destroyed. Fast-forwarding into the age of containers, the concept of SDN takes on a whole new meaning because our networks change constantly (every second, in a large Kubernetes cluster), and so it must, by definition, be automated by software. The Kubernetes network is entirely software-defined and is constantly in flux due to the ephemeral and dynamic nature of the Kubernetes Pod and service endpoints.

In this chapter, we’ll look at Pod-to-Pod networking and, in particular, how hundreds or thousands of containers on a given machine can have unique, cluster-routable IP addresses. Kubernetes delivers this functionality in a modular and extensible way by using a Container Network Interface (CNI) standard, which can be implemented by a broad range of technologies to give each Pod a unique routable IP address.

5.1 Why we need software-defined networks in Kubernetes

5.2 Implementing the service side of the Kubernetes SDN: The kube-proxy

5.2.1 The kube-proxy’s data plane

5.2.2 What about NodePorts?

5.3 CNI providers

5.4 Diving into two CNI networking plugins: Calico and Antrea

5.4.1 The architecture of a CNI plugin

5.4.2 Let’s play with some CNIs

5.4.3 Installing the Calico CNI provider

5.4.4 Kubernetes networking with OVS and Antrea

5.4.5 A note on CNI providers and kube-proxy on different OSs

Summary