Let’s take a look at the following Kubernetes architecture diagram:
Well, this might look complicated at first glance, but actually, it’s not so much. I’m pretty sure that by the end of this article you will have a clear understanding of how these components interact with each other.
Kubernetes Master Components The Kubernetes master runs the Scheduler, Controller Manager, API Server and etcd components and is responsible for managing the Kubernetes cluster. Essentially, it’s the brain of the cluster! Now, let’s dive into each master component.
In production, you should set up Kubernetes with multiple masters for high availability. See how to build high-Availability clusters official guides for further information.
Etcd Etcd is a distributed, consistent key-value store used for configuration management, service discovery, and coordinating distributed work.
When it comes to Kubernetes, etcd reliably stores the configuration data of the Kubernetes cluster, representing the state of the cluster (what nodes exist in the cluster, what pods should be running, which nodes they are running on, and a whole lot more) at any given point of time.
As all cluster data is stored in etcd, you should always have a backup plan for it. You can easily back up your etcd data using the etcdctl snapshot save command. In case you are running Kubernetes on AWS, you can also back up etcd by taking a snapshot of the EBS volume.
Etcd is written in Go and uses the Raft consensus algorithm to manage a highly-available replicated log. Raft is a consensus algorithm designed as an alternative to Paxos. The Consensus problem involves multiple servers agreeing on values; a common problem that arises in the context of replicated state machines. Raft defines three different roles (Leader, Follower, and Candidate) and achieves consensus via an elected leader. For further information, please read the Raft paper.
Etcdctl is the command-line interface tool written in Go that allows manipulating an etcd cluster. It can be used to perform a variety of actions, such as:
Set, update and remove keys.
Verify the cluster health.
Add or remove etcd nodes.
Generating database snapshots.
You can play online with a 5-node etcd cluster at http://play.etcd.io.
Etcd also implements a watch feature, which provides an event-based interface for asynchronously monitoring changes to keys. Once a key is changed, its “watchers” get notified. This is a crucial feature in the context of Kubernetes, as the API Server component heavily relies on this to get notified and call the appropriate business logic components to move the current state towards the desired state.
API Server When you interact with your Kubernetes cluster using the kubectl command-line interface, you are actually communicating with the master API Server component.
The API Server is the main management point of the entire cluster. In short, it processes REST operations, validates them, and updates the corresponding objects in etcd. The API Server serves up the Kubernetes API and is intended to be a relatively simple server, with most business logic implemented in separate components or in plugins.
The API Server is the only Kubernetes component that connects to etcd; all the other components must go through the API Server to work with the cluster state.
The API Server is also responsible for the authentication and authorization mechanism. All API clients should be authenticated in order to interact with the API Server.
The API Server also implements a watch mechanism (similar to etcd) for clients to watch for changes. This allows components such as the Scheduler and Controller Manager to interact with the API Server in a loosely coupled manner.
This pattern is extensively used in Kubernetes. For example, when you create a pod using kubectl, this what happens:
Create Pod Flow. Source: heptio.com
kubectl writes to the API Server.
API Server validates the request and persists it to etcd.
etcd notifies back the API Server.
API Server invokes the Scheduler.
Scheduler decides where to run the pod on and return that to the API Server.
API Server persists it to etcd.
etcd notifies back the API Server.
API Server invokes the Kubelet in the corresponding node.
Kubelet talks to the Docker daemon using the API over the Docker socket to create the container.
Kubelet updates the pod status to the API Server.
API Server persists the new state in etcd.
Controller Manager The Kubernetes Controller Manager is a daemon that embeds the core control loops (also known as “controllers”) shipped with Kubernetes. Basically, a controller watches the state of the cluster through the API Server watch feature and, when it gets notified, it makes the necessary changes attempting to move the current state towards the desired state. Some examples of controllers that ship with Kubernetes include the Replication Controller, Endpoints Controller, and Namespace Controller.
Besides, the Controller Manager performs lifecycle functions such as namespace creation and lifecycle, event garbage collection, terminated-pod garbage collection, cascading-deletion garbage collection, node garbage collection, etc.
Scheduler The Scheduler watches for unscheduled pods and binds them to nodes via the /binding pod subresource API, according to the availability of the requested resources, quality of service requirements, affinity and anti-affinity specifications, and other constraints. Once the pod has a node assigned, the regular behavior of the Kubelet is triggered and the pod and its containers are created (see the pod creation flow on API Server section: steps 4 to 11).
If this article was helpful to you, please like and share it with your friends. Plus, follow me on LinkedIn and subscribe to my website to get notified when part 2 of this article (Kubernetes Architecture: Node Components) is published!
This article was based on contents of my book Continuous Delivery for Java Apps: Build a CD Pipeline Step by Step Using Kubernetes, Docker, Vagrant, Jenkins, Spring, Maven, and Artifactory, which I invite you to download and read the free sample (110 pages) just clicking on Read Free Sample and choosing your preferred format (PDF, EPUB, MOBI, or WEB). Basically, the free sample will guide you through these subjects:
Unit Tests
Integration Tests
Acceptance Tests (Distributed Acceptance Tests with Selenium-Grid)
Performance Tests using Gatling
Continuous Integration
Continuous Delivery
Continuous Deployment
Canary Release
Feature Branch
A/B Tests
Feature Flags
Docker
ChatOps
Please check out my other articles:
Thank you very much for your time!
Jorge Acetozi is a software engineer who spends almost his whole day having fun with things such as AWS, Kubernetes, Docker, Terraform, Ansible, Cassandra, Redis, Elasticsearch, Graylog, New Relic, Sensu, Elastic Stack, Fluentd, RabbitMQ, Kafka, Java, Spring, and much more! He loves deploying applications in production while thousands of users are online, monitoring the infrastructure, and acting quickly when monitoring tools decide to challenge his heart’s health! Check out his books:
Comments