Demystifying Kubernetes: Architecture, Core Components, and Custom Controllers Explained

Introduction

This article, authored by the ADDOPS team, shares a practical understanding of Kubernetes (K8s) architecture and component interactions, aiming to make the registration‑watch workflow and related innovations easy to grasp.

Kubernetes Architecture Overview

Kubernetes follows a master‑slave model where the Master acts as the control plane (the brain) and Slaves (nodes) serve as the work units (neurons). The system is composed of loosely coupled functional components.

etcd Component

etcd provides highly available, strongly consistent storage for cluster state, serving as the foundation for many Kubernetes features and enabling reliable service discovery and configuration sharing across the cluster.

kube‑apiserver Component

kube‑apiserver is the central entry point of the cluster, acting as the message bus and API gateway. It wraps etcd to expose a unified query interface and implements the resource registration and discovery framework that underpins all other components.

Other Core Components

kube‑controller‑manager : aggregates various resource controllers (e.g., ReplicationController, ReplicaSetController, DeploymentController) that watch resources via the list/watch mechanism and reconcile desired state.

ReplicaSetController : watches ReplicaSet and Pod resources, creates Pods to match the desired replica count, and recreates Pods when they fail.

kube‑scheduler : discovers newly created Pods via the registration‑discovery framework, evaluates node suitability, and binds Pods to appropriate nodes.

kubelet : runs on each node, periodically fetches the desired state of Pods/Containers from the API server and ensures the actual state matches.

kube‑proxy : implements Service abstraction by monitoring Service and Endpoint resources and configuring network rules to route traffic to the correct Pods.

Custom Controllers Developed by the Team

lb‑controller : a custom load‑balancer controller that integrates Kubernetes with the company's LVS‑based layer‑4 proxy, dynamically adding or removing Pods from virtual IPs based on pod lifecycle events.

log‑controller : integrates Kubernetes pod events with the company's Qbus log collection system (built on Kafka, Logstash, and Qconf), automatically configuring Logstash agents for new Pods to streamline log aggregation.

Extending Kubernetes with client‑go

The client‑go library abstracts the complexities of connecting to the API server and watching resource changes, allowing developers to focus on handling state transitions.

Conclusion

By reviewing the architecture and component interactions, readers should gain a clearer picture of Kubernetes internals and be inspired to explore further custom extensions and optimizations.