Kubernetes Architecture Overview and Practical Insights

Recently the author studied Kubernetes and deployed a test‑environment service on it, then shared the experience in this article aimed at readers who are not yet familiar with Kubernetes.

The primary goal of using Kubernetes is to manage services like livestock rather than pets, improving resource utilization and allowing developers to focus on application code while the platform handles high availability.

Kubernetes inherits concepts from Google Borg; as Borg’s paper states, it hides resource management details, operates with high reliability, and efficiently runs workloads across thousands of machines.

To verify these goals, one can randomly kill a node, observe automatic migration of application instances, and check auto‑scaling with traffic.

The article then examines a typical multi‑tier application architecture and identifies necessary improvements: replacing static load balancers with a smart load balancer that reacts to service discovery, using domain names and private DNS for MySQL, employing service discovery for Memcached, containerizing applications with Docker to abstract OS and resource dependencies, introducing a master scheduler with agents on each node, handling network and port conflicts via SDN‑like solutions, and decoupling applications from hardware resources.

Kubernetes provides a comprehensive solution for these challenges. Its master consists of four core components:

etcd : a distributed key‑value store used as the configuration center and state store. Example directory structure:

etcdctl ls /registry<br/>/registry/minions (node info)<br/>/registry/namespaces<br/>/registry/pods<br/>/registry/services<br/>...

kube-apiserver : the front‑end API server that validates and persists requests to etcd.

kube-scheduler : watches for new pods in etcd and assigns them to nodes. It is pluggable; custom algorithms can be implemented. Example interface:

type ScheduleAlgorithm interface {<br/>    Schedule(api.Pod, NodeLister) (selectedMachine string, err error)<br/>}

kube-controller-manager : runs controllers that manage nodes, pods, replication, services, namespaces, etc., by reacting to events in etcd.

On each node, two agents run:

kubelet : manages containers, images, volumes, and interacts with the API server to start/stop pods.

kube-proxy : implements the Service abstraction, providing a virtual IP (clusterIP) and load‑balancing via iptables or userspace proxy.

Other key concepts include:

Pods : the smallest deployable unit, often consisting of a pause container plus application containers sharing a network namespace.

Replication Controller : ensures a desired number of pod replicas for high availability.

Services : stable network endpoints that abstract a set of pods, enabling decoupling of consumers from providers.

Labels and Selectors : key‑value pairs used to group and discover resources.

Namespaces : provide isolation for resource names within a cluster.

Kubectl : the command‑line tool that talks to the API server.

Kube‑dns : provides DNS for services and pods using etcd, skydns, and kube2sky components.

Networking : while Kubernetes expects pods to communicate directly, users must supply a CNI plugin (e.g., Flannel, Open vSwitch, Weave).

Configuration files : resources are defined in YAML or JSON.

Potential impacts of adopting Kubernetes include reduced complexity for distributed application development and operations, more complete CI/CD pipelines, easier deployment of distributed storage solutions, and lower barriers for on‑premise SaaS offerings.

The author also lists practical problems encountered:

Access to gcr.io is blocked in some regions, requiring a proxy.

Concurrent image pulls can corrupt images; pre‑pulling on each node is recommended.

Pod containers lack defined startup order, leading to race conditions (e.g., etcd must start before skydns).

Containers may lose external network access when using Flannel due to iptables issues.

Complex applications may require dozens of YAML files, making one‑click deployment challenging.

Public load‑balancer solutions depend on the underlying IaaS.

kube-proxy performance can be a bottleneck; the author provides a simple benchmark using a Go “Hello World” service.

For more details, the original article and source code are referenced at the end of the document.