Kubernetes Flashcards
What are the components of Kubernetes Control Plane?
The control plane manages the cluster. They usually run in master nodes, separate from worker nodes. The etcd database may run in in its own nodes.
API Server: this is the RESTful server that users interact with; usually with kubectl command line. The main implementation is called kube-apiserver. It scales horizontally.
etcd: That is the Kubernetes database. It is a highly available and consistent key-value store.
Scheduler. It watches for newly created Pods and selects a Node for them to run on. It takes into account factors such as individual and collective resource requirements, hardware/software/policy contraints, affinity and anti-affinity specifications, data locality, inter-workload inteference and deadlines.
Controller Manager: it runs Controllers. Logically each controller is a different control loop but they are all bundled in a single binary/process for simplicity. Some of them are Node Controller (responds when nodes go down), Job Controller (creates pods for jobs), EndpointSlice Controller (provides links between services and pods), and Service Account Controller (creates default service accounts).
Cloud Controller Manager: manages cloud-specific logic. Links the cluster to the cloud provider’s API. If running Kubernetes locally then you do not have it. Can be scaled horizontally.
What are the Kubernetes components that run on Worker Nodes? What do they do?
Kubelet and Kube-proxy (and Container runtime).
Kubelet is an agent that runs on each node. It makes sure that containers are running and healthy. It only manages containers create by Kubernetes. For example it’s responsible for performing healthchecks.
Kube-proxy is a network proxy that runs on each node. It mantains network rules on nodes. It allows network communication to your Pods from network sessions inside or outside of your cluster. It uses the operating system packet filtering layer if there is one and it’s available. Otherwise, kube-proxy forwards the traffic itself.
Containe runtime is the software responsible for running containers. Today Kubernetes uses containerd by default. But it supports CRI-O, Docker and any other implementatio nof Kubernetes CRI.
What is shared by containers in a Pod?
Containers in a Pod natively share their network namespace and their storage.
Each pod is assigned an unique ip address. Every container in a pod shares the network namespace, including the ip address and network ports. Inside a pod the containers can communicate with one another using localhost. When communicating outside the pod they must coordinate how they use shared network resources such as ports. The containers inside a pod can also communicate with eachother using standard IPC like POSIX shared memory.
Each container has their own filesystem. However they can share volumes specified by the Pod. All containers in the Pod cna access the shared volumes, allowing containers to share data.
They do not share resources (memory and cpu): each container has its own cgroup.
Containers can also share the process namespace: https://kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace/
Interestingly, you can see that by ls -lrt the process. Inside a pod, /net, /ipc will be the same, /cgroup might be also the same due to cgroup virtualization.
cd /proc/19653/ns
# /proc/19653/ns# ls -lrt
total 0
lrwxrwxrwx 1 root root 0 Jul 4 01:42 uts -> uts:[4026536150]
lrwxrwxrwx 1 root root 0 Jul 4 01:42 user -> user:[4026531837]
lrwxrwxrwx 1 root root 0 Jul 4 01:42 pid_for_children -> pid:[4026536151]
lrwxrwxrwx 1 root root 0 Jul 4 01:42 pid -> pid:[4026536151]
lrwxrwxrwx 1 root root 0 Jul 4 01:42 net -> net:[4026536052]
lrwxrwxrwx 1 root root 0 Jul 4 01:42 mnt -> mnt:[4026536149]
lrwxrwxrwx 1 root root 0 Jul 4 01:42 ipc -> ipc:[4026536049]
lrwxrwxrwx 1 root root 0 Jul 4 01:42 cgroup -> cgroup:[4026531835]
How are StatefulSets different from DaemonSets?
It is the object used to manage stateful applications. It manages the deployment and scaling of a set of Pods and provides guarantees about the ordering and uniqueness of these Pods (unlikey Deployments).
These Pods are created from the same spec, but are not interchangeable: they each have a persistent indentifier that they mantain across any rescheduling.
Their spec differs from Deployments by having “volumeClaimTemplates”. This provides stable storage using PersistentVolumes. This guarantees that each Pod has their own PVC.
