Table of Contents
Docker containers are much more lightweight compared to classic VMs as they leverage host OS instead of starting their own OS.
Containers are using 2 features of Linux-based OS:
Namespaces and Cgroups (Control Groups).
Lets you allocate resources in an isolated environment (like a sandbox).
On a container start, docker daemon generates a set of unique namespaces exclusively for that container:
- User/UIDs namespaces — a container running within the user namespace is isolated from the User IDs and Group IDs of other containers, making them unaware of each other’s existence.
- UTS namespaces — isolate hostname and domain name information.
- IPC namespaces — isolate IPC method.
- Net namespaces — isolate network interfaces.
- PID namespaces — isolate process IDs.
- Mount namespaces — isolate mount points.
are limiting resources which are allowed to be utilized by a container:
- CPU — limits CPU utilization.
- Memory — limits memory usage.
- Disk I/O — limits disk I/O.
- Network — limits network bandwidth.
A bit more details — https://blog.kubesimplify.com/understanding-how-containers-work-behind-the-scenes
Is used for orchestrating docker containers based on defined policies. It automates deployments, scaling and management of containerized apps.
Main features: self-healing (automatically restarts containers), automatic rollouts and rollbacks, automated discovery and load balancing, horizontal scaling.
is a host machine, it has a docker and some amount of running containers of different services. It is controlled by the Control Plane.
Pod is a deployable unit. It is a one service instance, consists of one or few containers.
kubelet is monitoring node’s pods health status and reports to the Control Plane every few seconds. Also gets instructions from Control Plane’s API.
kube-proxy routes incoming traffic to an exact pod, makes sure that every pod has a unique IP address.
docker can be replaced with any other container runtime, like containerd or CRI-O.
is managing the cluster. It receives commands by an API or based on policies and applies them to the cluster. It consists of:
kube-apiserver which handles API communication for administrating the cluster.
etcd which is used for storing configs and current cluster state.
kube-scheduler checks incoming tasks and assigns pods to available nodes in the cluser.
kube-controller-manager monitors the cluster state and checks if its parameters are valid for the configs.
More details — https://blog.kubesimplify.com/introduction-to-kubernetes.
is a package manager for Kubernetes.
K8s is not aware of the whole application/site, it is only aware of some parts that need to be configured.
Helm sits on a higher level, and it cares about how to group services into a runnable application. In charts, it keeps the k8s configs for every service. When a chart is applied to the cluster, a release is created.
Helm instructs k8s with exact commands when we say something like
$ helm install wordpress
$ helm upgrade wordpress
$ helm rollback wordpress
$ helm uninstall wordpress
You can configure things like autoscaler, ingress, CPU and memory limits, health check probes.
More details — https://blog.kubesimplify.com/introduction-to-helm.