Understanding the fundamental architecture will help you successfully deploy Kubernetes (K8s). Read on as we’ll introduce you to some of the key components of K8s.

The Cluster

This is the most important aspect of K8s. A cluster  is a set of physical or virtual machines, called “nodes.” Each cluster consists of one or more master nodes and multiple worker nodes.

Worker nodes run your application load or application containers. The most important elements of worker nodes are:

  • Kubelet: A single binary service that runs on each worker node within the cluster. The kubelet manages pods (each pod consists of one or more containers running together), images, volumes and networks. Each Kubelet is responsible for its node and constantly communicates with the master node and API Server about which container should be running, stopped or reconfigured. 
  • Kube-proxy: This network proxy focuses more on communication. The kube-proxy is responsible for configuring the network stack on worker nodes so that the pods and containers running in the cluster can talk to each other over the network. This occurs through distributed iptables/nftables based on the network proxy and load balancer.

Master nodes run system components such as Metadata Storage, API server, Controller Managers and Schedulers for the cluster. There can be variations of this architecture. In most cases, master nodes are physical or virtual machines, but sometimes can be logical nodes (e.g. EKS managed service).

The most important elements of master nodes are:

  • Distributed Watchable Storage: This is storage for the cluster’s metadata. Here, K8s holds and stores information about which nodes are part of the cluster, which containers are requested to run, and more. In most cases, this storage is an etcd cluster, an open-source, key-value system that is reliable and watchable and maintains a persistent master state. This provides storage for the API server.
  • API server: This is the heart of K8s. The K8s API server is the only component that directly talks to the storage. It provides a CRUD-y REST interface for external and internal clients. API views clusters as a set of objects and presents this view to both the outside world and inside components.
  • Scheduler: When a client creates a new pod, it usually doesn’t specify which node this pod should run on. Enter the Scheduler. It binds unscheduled pods or containers to worker nodes.
  • Controller Manager: As controllers monitor the state of the cluster, the Controller Manager implements the logic behind them. It performs all other cluster-level functions such as deployments, rollout, job control and pod replication control.

Security

As worker and master nodes work to run the cluster, the API server must be protected from unauthorized access. K8s implements a strong authentication and authorization system that is pluggable, extensible and supports different modes of authentication.

Transport Layer Security (TLS) enables K8s by default. Through TLS, components can talk to each other over the network with strong encryption and key certificates protecting this communication. 

Clients

The most-frequently used external client is Kubectl (CLI). Kubectl manages K8s clusters and applications. In addition, there is the K8s dashboard, a simple web user-interface (UI) for K8s clusters that controls pods and visualizes objects representable in the K8s API.

How these elements work together

Now that we have a foundational understanding of the basic structure of K8s, we can start to envision how they all work together to run a cluster. 

This is the typical process of K8s architecture: 

  1. The user uses Kubectl to create new deployment objects via REST API in the K8s database.
  2. The Controller Manager, which constantly watches the API server’s node usage, notices that there is a new deployment object, but no pods for that deployment object. The Controller Manager then creates pod objects in the database, based on the deployment object specification.
  3. The Scheduler then sees that the pod objects are not yet assigned to nodes. It allocates them to available nodes according to the nodes’ load and the pods specifications. Finally, the Scheduler marks each pod, designating the node it should run on.
  4. Kubelets then take the baton. As soon as a kubelet notices that a new pod appeared in the K8s API, assigned to this kubelet’s node and not yet started, the Kubelet starts running the container according to the corresponding pod’s specification.

This process happens very quickly, within seconds.

Don’t be intimidated

There’s a lot to learn when it comes to K8s architecture, but it’s worth learning to improve your operations. To take some of the burden off, you can use a K8s management platform like Kublr. Kublr offers turnkey container management that allows you to deploy K8s across different environments without sacrificing operational capabilities.

Learn more about Kublr today!