A distributed, reliable key-value store for the most critical data of a distributed system
default port: 2379
./etcdctl set key1 value1 ./etcdctl get key1
Every information you see when you run the
kubectl get command is from the Etcd Server.
To list all keys stored by Kubernetes, run the command like this. Run inside the etcd-master POD.
kubectl exec etcd-master -n kube-system etcdctl get / --prefix -keys-only
Kube-apiserver is the primary management component in kubernetes. When you run a kubectl command, the kubectl utility is in fact reaching to the kube-apiserver. The kube-apiserver first authenticates the request and validates it. It then retrieves the data from the etcd cluster and reponds back with the requested information.
POST request is available as well.
curl -X POST /api/v1/namespaces/default/pods ...[other]
enable verbose for your command
kubectl get pods -A -v 8
I0209 16:48:43.713733 29886 loader.go:374] Config loaded from file: /Users/~/.kube/config I0209 16:48:43.714375 29886 loader.go:374] Config loaded from file: /Users/~/.kubeconfig_pro I0209 16:48:43.724834 29886 round_trippers.go:463] GET https://127.0.0.1:6443/api/v1/pods?limit=500 I0209 16:48:43.724856 29886 round_trippers.go:469] Request Headers: I0209 16:48:43.724870 29886 round_trippers.go:473] Accept: application/json;as=Table;v=v1;g=meta.k8s.io,application/json;as=Table;v=v1beta1;g=meta.k8s.io,application/json I0209 16:48:43.724879 29886 round_trippers.go:473] User-Agent: kubectl/v1.25.0 (darwin/amd64) kubernetes/a866cbe I0209 16:48:43.744984 29886 round_trippers.go:574] Response Status: 200 OK in 20 milliseconds
kube-apiserver is the only component that interacts directly with the etcd datastrore.
kube-controller-manager manages various controllers in kubernetes. A controller is like an office or department within the master ship that have their own set of responsibilities.
These offices are:
No 1. Continuously on the lookout for the status of the ships
No 2. Take necessary actions to remediate the situation
Node Monitor Period = 5s
Node Monitor Grace Period = 40s
POD Eviction Timeout = 5m
kube-scheduler is responsible for scheduling pods on nodes. It is only reponsible for deciding which pod goes on which node. It doesn’t actually place the pod on the nodes.
The scheduler decides which nodes the pods are placed on depending on certain criteria. You may have pods with different resource requirements. You can have nodes in the cluster dedicated to certain applications.
1. Filter Nodes 2. Rank Nodes - calculates the amount of resources that would be free on the nodes after placing the pod on them
The kubelet is like the captain on the ship. They lead all activities on a ship. They’re the ones responsible for doing all the paperwork necessary to become part of the cluster. They’re the sole point of contact from the master ship. They load or unload containers on the ship as instructed by the scheduler on the master. The kubelet in the kubernetes worker node, registers the node with the kubernetes cluster. When it receives instructions to load a container or a pod on the node, it requests the container runtime engine, which maybe Docker, to pull the required image and run an instance. The kubelet then continues to monitor the state of the pod and the containers in it and reports to the kube-apiserver on a timely basis.
kube-proxy is a process that runs on each node in the kubernetes cluster. Its job is to look for new services and every time a new service is created it creates the appropriate rules on each node to forward traffic to those services to the backend pods. One way it does this is using IPTABLES rules.