Understanding Kubernetes Architecture: From Master Nodes to Service Discovery

Kubernetes Architecture

From a high level, Kubernetes consists of a Master control plane, worker Nodes, and etcd for persistent data storage.

The Master includes the API Server, Scheduler, and Controller Manager, all of which interact with etcd.

API Server : Unified entry point for resource operations, handling security, registration, and discovery while abstracting direct etcd access.

Scheduler : Assigns Pods to Nodes based on scheduling rules.

Controller Manager : Ensures resources reach their desired state.

Each Node runs containers, kubelet, and kube-proxy.

kubelet : Manages container lifecycles, monitors health via cAdvisor, and reports node status.

kube-proxy : Implements service discovery and load‑balancing by watching Services and Endpoints.

Creating a Deployment

A Deployment is a controller that manages ReplicaSets and Pods. The creation flow involves several components:

kubectl sends a request to create a Deployment.

The API Server stores the desired state in etcd.

The Deployment controller watches the resource and creates a ReplicaSet.

The ReplicaSet controller creates Pods.

The Scheduler binds each unscheduled Pod to a suitable Node.

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

kube-proxy sets up Service‑related networking rules.

Pod Fundamentals

A Pod is the smallest deployable unit in Kubernetes and represents a group of tightly coupled containers that share network, storage, and configuration.

Containers within a Pod share an infra container that provides a common network namespace, and they can mount the same volume to share storage.

Container Orchestration Resources

Kubernetes provides various controllers for different workloads: Deployment for stateless apps, StatefulSet for stateful apps, DaemonSet for node‑level agents, and Job/CronJob for batch processing.

Using Deployment as an example, the relationship is:

Deployment controls the version and update strategy of a ReplicaSet.

ReplicaSet controls the number of Pods.

This design enables horizontal scaling (adjusting replica count) and versioned updates/rollbacks.

Horizontal Scaling

Scaling is achieved by modifying the replica count in the ReplicaSet, e.g., changing from 2 to 3 adds one Pod; decreasing the count performs a shrink.

Update and Rollback

When updating from version v1 to v2, the old ReplicaSet’s Pods are gradually terminated while the new ReplicaSet’s Pods are created, ensuring continuous availability. Rolling back reverses this process.

Rolling Updates

Kubernetes performs rolling updates by replacing Pods one at a time while keeping a minimum number of Pods available (e.g., at least 2) and a maximum number of Pods running (e.g., up to 4). The RollingUpdateStrategy can be tuned with maxSurge (extra Pods) and maxUnavailable (allowed down Pods).

Networking in Kubernetes

Three basic connectivity requirements must be satisfied:

Node ↔ Pod communication.

Pod ↔ Pod communication on the same Node.

Pod ↔ Pod communication across different Nodes.

In‑node communication uses the cni0 / docker0 bridge. Cross‑node traffic is commonly implemented with CNI plugins such as Flannel (VXLAN or host‑gateway mode), which stores node network information in etcd and programs routing tables.

Microservice Service Object

A Service abstracts a set of Pods (the microservice) and provides a stable endpoint. It solves two problems:

Pods have dynamic IPs, making direct calls unreliable.

Load‑balancing across multiple Pod instances is needed.

Service selects Pods via label selectors, creates an Endpoints list, and routes traffic accordingly.

Service Discovery and Network Calls

With the underlying "three‑way" network in place, Kubernetes enables service discovery through the Service object and DNS.

Service‑to‑Service Calls

Two common patterns are used:

ClusterIP : kube-proxy configures iptables/ipvs to expose a virtual IP (VIP) that load‑balances traffic to backend Pods.

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

External Access (North‑South Traffic)

External clients reach services via three mechanisms:

NodePort : Exposes a port on each Node’s IP; traffic is forwarded to the Service.

LoadBalancer : Leverages cloud provider load balancers to expose a public IP.

Ingress : A layer that routes external HTTP/HTTPS traffic to internal Services based on host/path rules, typically built on top of NodePort and/or LoadBalancer.

By understanding these components and workflows, readers can grasp what is being discussed whenever Kubernetes is mentioned.