Understanding Kubernetes Architecture: From Master Nodes to Service Networking

Kubernetes Architecture

Kubernetes is the leading container orchestration engine, offering cluster scaling, rolling upgrades, auto‑healing, service discovery, and more.

The overall architecture consists of a Master, Nodes, and etcd.

Master : Controls the cluster and includes the API Server, Scheduler, and Controller Manager, all of which interact with etcd for data storage.

Node : Provides compute resources where containers run, featuring kubelet and kube‑proxy.

Master Components

API Server – unified entry point for resource operations, abstracting direct etcd access.

Scheduler – assigns Pods to Nodes based on scheduling rules.

Controller – ensures resources reach their desired state.

Node Components

kubelet – manages container lifecycles, monitors health via cAdvisor, and reports node status.

kube‑proxy – implements service‑level load balancing and updates network rules when services or endpoints change.

Creating a Deployment

A Deployment orchestrates Pods; the following steps illustrate how the various components collaborate when a Deployment is created:

kubectl sends a request to create the Deployment.

The API Server stores the request in etcd; subsequent interactions follow the same pattern.

The Deployment controller watches for changes and creates a ReplicaSet.

The ReplicaSet controller watches for changes and creates Pods.

The Scheduler binds unassigned Pods to suitable Nodes.

kubelet on the target Node creates the Pod and manages its lifecycle.

kube‑proxy sets up Service‑related networking rules.

Through this coordinated effort, the Deployment request results in running Pods.

Pod Basics

Pods are the smallest deployable units in Kubernetes, designed for tightly coupled containers that share network, storage, and configuration.

Containers within a Pod share an infra container for network identity and can mount the same volume, enabling shared storage.

Container Orchestration Resources

Kubernetes provides several controllers for different workloads: Deployment (stateless apps), StatefulSet (stateful apps), DaemonSet (node‑level agents), Job/CronJob (batch tasks).

Using Deployment as an example, the relationship is:

ReplicaSet controls the number of Pods.

Deployment controls the versioned ReplicaSets, enabling horizontal scaling and versioned updates/rollbacks.

Horizontal Scaling

Adjust the ReplicaSet’s replica count (e.g., from 2 to 3) to scale out, or reduce it to scale in.

Update / Rollback

When updating from version v1 to v2, the v1 ReplicaSet’s Pods are gradually terminated while v2 ReplicaSet’s Pods are created, achieving a seamless transition; rollback reverses the process.

Rolling Update

During a rolling update, Pods are upgraded one by one, maintaining at least two healthy Pods while at most four Pods may run, ensuring continuous service availability.

The RollingUpdateStrategy can be tuned with maxSurge (extra Pods allowed) and maxUnavailable (maximum Pods that can be taken down).

Kubernetes Networking

Three basic connectivity requirements (“three‑ways”) are:

Node ↔ Pod communication.

Pod ↔ Pod on the same Node.

Pod ↔ Pod across different Nodes.

Pod‑to‑Pod traffic uses the cni0/docker0 bridge; Node‑to‑Pod also goes through this bridge.

Cross‑Node Pod communication is typically implemented with CNI plugins like Flannel, which uses etcd to share network information and creates routing tables for inter‑Node traffic.

Microservice Service

A Service abstracts a set of Pods, providing a stable endpoint and load balancing.

Because Pod IPs are dynamic, Services use label selectors (e.g., app=xxx) to build an Endpoints list.

Service Discovery and Network Calls

With the “three‑ways” network in place, services can be accessed internally via two main mechanisms:

ClusterIP

ClusterIP creates a virtual IP (VIP) managed by kube‑proxy using iptables or IPVS; traffic to the VIP is load‑balanced across the backing Pods.

DNS

Each Service gets an A record like service-name.namespace-name.svc.cluster.local, allowing pods to reach the service simply by its name.

External Access (North‑South Traffic)

External traffic can reach the cluster via:

NodePort – exposes a port on each Node.

LoadBalancer – leverages cloud provider load balancers.

Ingress – a unified entry point that routes requests to Services, often built on top of NodePort and LoadBalancer.

By now, readers should understand the core concepts of Kubernetes, how its components interact, and how microservices run and communicate within a Kubernetes cluster.