Welcome to the world of Kubernetes Networking ! We ll discuss how kubernetes achieves a plug-n-play interface driver pattern for almost all external components, such as network and storage. We will talk about Container Breakouts and Network Isolation, mention the hype-word eBPF and talk about policies , and that nobody likes to be told what to do.
Lastly, we ll briefly go over container alternatives, such as gVisor (that you have actually been actively using a few times during this class).
Last Updated: 2024-05-07
What
We will cover the following topics:
- CNI
- Network Policies
- SecurityContext
- microVMs
What you'll build today
By the end of today's lecture, you should have
- ✅ A kind local install using cilium and understanding how to layer CNIs
- ✅ The securityContext stanza
- ✅ At least one network policy and observing how its blocking things
- ✅ Debug your network and capture traffic
- ✅ An ingress or Gateway API
Homework (Flipped Classroom)
How should I prepare
- Your Helm Chartv0.02 is deployable to your choice of Kubernetes
- Your Helm Chart is properly packaged and in a registry, (using automation)
- Your Kubernetes is up and running
PreRead
- The PDF book "Kubernetes Networking and Cilium" (see Slack; up to page 29)
- https://www.youtube.com/watch?v=GgCA2USI5iQ
What you'll need
- A browser (this lab was only tested on Chrome)
- Kind and Helm locally usable
- A laptop with internet
In K8s design, there are (at least) three major plugin interfaces, that allow the kubernetes binary to use a wide variety of implementations without the need to recompile.
The most important are: CNI, CSI and CRI
Container Network Interface (CNI): CNI is a specification for configuring network interfaces for Linux containers. It provides a common interface for different networking solutions, allowing them to be swapped in and out as needed.
Container Storage Interface (CSI): CSI is a standard for exposing arbitrary block and file storage systems to containerized workloads. It allows storage vendors to develop a plugin once and have it work across a variety of container orchestration systems. In Kubernetes, when a persistent volume is needed, the Kubelet uses CSI to interact with the appropriate storage plugin to create, attach, and mount the volume. CSI plugins, such as those provided by cloud providers or other storage solutions, implement the CSI specification and provide the actual storage capabilities.
Container Runtime Interface (CRI): CRI is a plugin interface that enables the Kubelet to use a wide variety of container runtimes.
How to make things communicate?
Recap : the Kubernetes Components:
https://kubernetes.io/docs/concepts/architecture/
https://kubernetes.io/docs/concepts/cluster-administration/networking/
So, how is the network actually happening?
https://github.com/containernetworking/cni/blob/main/SPEC.md
https://static.sched.com/hosted_files/kccncna19/69/CNI%20Intro%20Nov%202019.pdf
How does your network package get to the pod?
https://cilium.io/blog/2021/05/11/cni-benchmark/
Lets see what projects are out there and how they differ
Navigating CNI and Service Meshes
We ll be doing live labs
Lab URl
https://play.instruqt.com/isovalent/invite/mzdyw0tfcnab
Gateway API lab
https://play.instruqt.com/embed/isovalent/tracks/cilium-gateway-api
We will use Hubble to tap into the network flows
Hubble lab
https://github.com/cilium/hubble
https://isovalent.com/labs/hubble-connectivity-visibility/
List of labs that would use Kubeshark or other advanced network capabilities:
Useful tool is the visual editor
https://editor.networkpolicy.io/?id=RkzvTTj0yAFtuhY8
Congratulations, you've successfully completed this training on networking
What's next?
- Lecture 10 will be on advanced patterns, the ACME protocol and operators
Reference docs
- Several OReilly books have been cited in this tutorial