Today, we'll see what all of the Kubernetes components bring to the table for us. That's going to help us get a better grasp of the way Kubernetes works.
On the Kubernetes Master’s side:
This will be an in depth look into the Kubernetes Master components:
The api-server is the service that exposes the API we all interact with (either via command line, UI or other applications that need to interact with the cluster).
etcd is a distributed storage service, used as Kubernete’s control-plane storage. All of the cluster data is persisted in etcd.
kube-controller-manager is responsible for running controllers (Node Controller, Replication Controller, Endpoint Controller and Service Account & Token Controllers)
cloud-controller-manager is a daemon that is responsible for running all cloud-related controllers — Node Controller, Volume Controller, Route Controller, Service Controller and Persistent Volume Labels controller. The main benefit of having the cloud controller manager separate from the kubernetes controller is that it allows the vendor code and kubernetes core code to be developed independently from one another.
The Kubernetes scheduler (kube-scheduler for short) is a policy-rich, topology-aware, workload-specific function that figures out the best place for a new pod. To make such decisions, it takes into account individual, collective and quality of service resource requirements; hardware, software and policy constraints; affinity and anti-affinity specifications; data locality; inter-workload interference; deadlines; and more.
Cluster DNS is a DNS server, in addition to the other DNS server(s) in your environment, which serves DNS records for Kubernetes services. Containers started by Kubernetes automatically include this DNS server in their DNS searches.
Web UI (Dashboard)
web-ui-dashboard is a web-based Kubernetes user interface and dashboard mashed together. You can check your cluster’s state as well as operate it through its UI.
Container Resource Monitoring - Heapster
Heapster is Kubernetes' default generic time-series and containers metrics collection mechanism. Those metrics are collected on the nodes by cAdvisor and shipped by the kubelet to Heapster.
The Cluster-level logging mechanism is responsible for saving container logs to a central log store with query mechanisms attached to it. Those range from SaaS solutions, like a hosted Splunk instance, to various open source alternatives that you can run either on premises or on your cloud provider.
On the Kubernetes Node’s side:
The kubelet is the primary node agent. It is responsible for making sure the state that’s passed to it matches the world. That, in its context, means the node it is running. It checks for pods that have been assigned to it and creates them, mounts volumes to them, adds secrets to them, runs the containers defined in the pod manifest, performs liveness probes against the pods and reports the pod’s and node’s status to the rest of the system.
As the name suggests, kube proxy is responsible for forwarding traffic into the pods through firewall rules (iptables, for now).
Container Runtime (Docker, RKT or CRI-O)
These are the container runtimes supported by Kubernetes at the moment. The kubelet manages pods and their containers’ lifecycles.
Init systems (Supervisord, Systemd or init.d)
You can pick and choose any of those alternatives to make sure that especially both docker, the kubelet and any other kubernetes components are running.
Today we saw how all of the kubernetes' running parts interact together and what purpose each one has. We hope that this episode makes you realise that Kubernetes is not magic, it's just a well-written approach to solve day-to-day operational issues.