Understanding Kubernetes Architecture: From Master Nodes to Service Discovery

Kubernetes has become the dominant container orchestration platform, offering features such as cluster scaling, rolling upgrades, self‑healing, and service discovery.

Kubernetes Architecture

The high‑level architecture consists of a Master, Nodes, and Etcd for persistent state.

Master : Controls the cluster and includes the API Server, Scheduler, and Controller Manager, all of which interact with Etcd.

Node : The worker machine that runs containers via kubelet and handles networking with kube-proxy .

Creating a Deployment

kubectl sends a request to create a Deployment.

The API Server stores the request in Etcd.

The Deployment controller watches the resource and creates a ReplicaSet.

The ReplicaSet controller watches the ReplicaSet and 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 for load balancing and service discovery.

Pod

A Pod is the smallest deployable unit in Kubernetes, grouping one or more tightly coupled containers that share a network namespace, storage volumes, and configuration.

Container Orchestration Resources

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

Horizontal Scaling

Scaling is achieved by adjusting the replica count in a ReplicaSet; increasing from 2 to 3 replicas performs a horizontal scale‑out, while decreasing performs a scale‑in.

Update / Rollback

When updating from version v1 to v2, the old ReplicaSet’s pod count is reduced to zero while the new ReplicaSet’s count is increased, achieving a seamless update; the reverse process performs a rollback.

Rolling Update

Kubernetes performs rolling updates by creating new Pods while keeping a minimum number of Pods available; the RollingUpdateStrategy can be tuned with maxSurge (extra Pods) and maxUnavailable (Pods that may be down).

Kubernetes Networking

Three basic connectivity requirements are satisfied: Node ↔ Pod, Pod ↔ Pod on the same Node, and Pod ↔ Pod across Nodes. Within a Node, communication uses the cni0/docker0 bridge; cross‑Node traffic is commonly implemented with Flannel (VXLAN or host‑gateway mode) which reads network information from Etcd and programs routing tables.

Service (Microservice)

A Service abstracts a set of Pods and provides a stable virtual IP and DNS name for load‑balanced access. Pods are selected via label selectors, e.g., app=xxx, and the Service creates an endpoints list representing the backing Pods.

Service Discovery and Network Calls

In‑cluster Calls

ClusterIP Services expose a VIP managed by kube-proxy (iptables or IPVS). Clients can reach the Service via the VIP, and DNS resolves service-name.namespace.svc.cluster.local to the ClusterIP address.

External Access

External traffic reaches the cluster via three Service types: NodePort (exposes a port on each Node), LoadBalancer (provisions a cloud provider LB), and Ingress (a unified entry point that routes to Services, often built on top of NodePort and LoadBalancer).

By understanding these components, you can grasp what discussions about Kubernetes actually refer to.