core concepts

• cluster architecture
• service & other network primitives
• api primitives

kubernets architecture

• worker nodes

  • host applications
  • kubelet
  • kube-proxy
  • container runtime
    • containerd
    • cri-o
    • docker

• master

  • etcd
  • kube-scheduler
  • node-controller
  • replication-controller
  • kube-apiserver

etcd

a distributed reliable key-value store that is simple, secure & fast

• key-value store
  • no duplicate keys cause each value is used once

installation

1. download binaries
2. extract
3. run the executeable

etcd will listen on port 2379 by default

etcdctl is used to handle keys and values

etcd in kubernetes

every information we became using the kubectl get command is received from etcd

• nodes
• pods
• configs
• secrets
• accounts
• roles
• bindings
• others

every changes are updated in etcd server

therte are 2 ways to install etcd

• setup manual
  • configure using the advertise client url
• setup kubeadm
  • create a pod which contains the etcd server

etcdctl is the cli tool to interact with etcd
etcdctl can interact using api version 2 and version 3
by default etcdctl uses version 2

etcd commands

# version 2
> etcdctl backup
> etcdctl cluster-health
> etcdctl mk
> etcdctl mkdir
> etcdctl set

# version 3
> etcdctl snapshot save 
> etcdctl endpoint health
> etcdctl get
> etcdctl put

kube-apiserver

the primary management resource in kubernetes - api server can also be managed by sending a post request instead of the the kubectl command

responceable for

1. authenticate user
2. validate request
3. retrieve data
4. update etcd
5. scheduler
6. kubelet

api-server is the only part that communicate with etcd directly

important options in kube-apiserver service are

• --etcd-servers
• --etcd-cafile
• --etcd-certfile
• --etcd-keyfile
• --kubelet-certificate-authority
• --kubelet-client-certificate
• --kubelet-client-key
• --kubelet-https

if installed per kubeadm - the kube-apiserver is deployed by using a pod on the master node. in this case the api-server configuration file lays under: /etc/kubernetes/manifests/kube-apiserver.yaml - to get this information on a none kubeadm setup is to inspect the systemd unit file - also ps aux|grep kube-apiserver shows the actually used options as well

controller manager

can continiously monitoring the status of the components using in the system and bringing the whole system in a functionally state.

node-controller - receives every 5 seconds a heartbeat from the nodes (over the apiserver)

• node monitor period = 5sec
• node monitor grace period = 40sec
• pod eviction timeout = 5min
  • if this fail the node controller removes all pods from there and roll the pods in another node relais on the replicaset

replication controller - monitoring the status of the replicasets and ensure the given number of pods are available

there are also

• deployment-controller
• namespace-controller
• endpoint-controller
• cronjob
• job-controller
• pv-protection-controller
• service-account-controller
• statefull-set
• replicaset
• pv-binder-controller

all of these are managed in the kube-controller-manger - the kube-controller-manager is setting up by systemd unit file as well

in this unitfile we specified the

• --node-monitor-period
• --node-monitor-grace-period
• --pod-eviction-timeout

with the option --controller we can chosse which kind of controllers are used - by default all controllers are enabled

if installed per kubeadm - the kube-controller-manager is deployed by using a pod on the master node - in this case the kube-controller-manager configuration file lays under: /etc/kubernetes/manifests/kube-controller-manager.yaml - to get this information on a none kubeadm setup is to inspect the systemd unit file - also ps aux|grep kube-controller-manager shows the actually used options as well

kube-sheduler

responsable for scheduling pods or nodes

the kube-scheduler only decide which pod goes on which node

here we can setup a multinode setup with different efficient hardware dedicated to the application runs on

high level workflow

1. filter nodes that fits the profile - maybe 10 cpus
2. ranks nodes the get the best node for the pod - which has more free cpus

if installed per kubeadm - the kube-scheduler is deployed by using a pod on the master node - in this case the kube-scheduler configuration file lays under: /etc/kubernetes/manifests/kube-scheduler.yaml - to get this information on a none kubeadm setup is to inspect the systemd unit file - also ps aux|grep kube-scheduler shows the actually used options as well

kubelet

the kubelet - which runs on the worker nodes - register the nodes on k8s cluster. when it get a instruction - from the scheduler over the api-server - it request the container runtime to pull the required image and run that instance. kubelet monitors the state of the node and pods

kubeadm does NOT deploy kubelets

inspect the systemd unit file - also ps aux|grep kubelet shows the actually used options as well

kube proxy

is a process that runs on each node in a cluster. its job is to look for new services - it creates the appropiate rules on each node to forward traffic to those services to the backend. one way to do this is using iptables to forward traffic heading to the ip of the service to the ip of the pod.

if installed per kubeadm - the kube-scheduler is deployed in a daemon-set by using a pod on each node in the cluster

pod

a single instance of an application.