Linux meets Kubernetes
Vishnu Kannan
https://www.linkedin.com/in/vishnukanan
https://github.com/vishh?tab=repositories
Overview
- Master node and worker nodes
- Containers enable you to focus more on your application and less on where it runs.
- Kubernetes does not use Docker, but uses parts of the Moby project (e.g. runc).
The anatomy of a running Docker container
- Overlay (type) filesystem (copy-on-write)
- Control groups (cgroups): Restrict resources, track processes
- Namespaces (virtual context, process trees, network interfaces, users and groups, mounted filesystems).
- Security: Seccomp, Capabilities, AppArmor, SELinux, Filesystem permissions. Provide least privilege.
- Volumes: Simply any data that is not within your overlay file system. Allows data used by your container to live beyond the life of the container.
- Network: Bridge + Veth + Iptables, Overlay and Underlay, eth0 and loopback.
Pods
Now that we all have a common understanding of a container, what is a pod?
One or more tightly coupled containers and volumes.
Pods let you build microservices:
- Shared Linux namespace.
- Shared storage.
- Shared network interface.
- Shared control groups.
Demo
Code: Github (will update when I know the repo)
My side-notes
My opinionated and supposed insights, not what Vish said.
We need to get better at explaining what is:
- Image
- Container
- Docker
- Docker Inc.
- Moby
For example, a Debian Docker container does not have a Debian built Linux kernel, it is utilising the kernel from the host. All a Debian image is, is a subset of the binaries and file system structure of Debian.
A Docker orchestration journey
We need to help the community understand:
- The different orchestrators.
- Which ones fit which purpose.
- How to move from simpler (Docker Swarm, ECS) to more powerful (Kubernetes) and how to translate the learnings so it doesn't feel like they've learnt two different orchestrators.