Demystifying Kubernetes: Architecture, Deployments, and Service Networking

Kubernetes has become the king of container orchestration, a container‑based cluster engine offering features such as cluster scaling, rolling upgrades and rollbacks, elastic scaling, self‑healing, and service discovery.

This article quickly introduces Kubernetes and explains what we mean when we talk about it.

Kubernetes Architecture

From a high level, Kubernetes consists of a Master, Nodes, and etcd.

The Master (control plane) manages the entire cluster and includes the API Server, Scheduler, and Controllers, all of which interact with etcd for data storage.

API Server : Provides a unified entry point for resource operations, abstracting direct etcd interaction and handling security, registration, and discovery.

Scheduler : Assigns Pods to Nodes based on scheduling rules.

Controller : Acts as the resource control center, ensuring resources reach their desired state.

Nodes are worker machines that provide compute capacity, where containers actually run, and include components such as kubelet and kube-proxy.

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

kube-proxy : Uses Services to provide intra‑cluster service discovery and load balancing, watching Service/Endpoints changes to update load‑balancing rules.

Starting with Creating a Deployment

A Deployment is a controller resource used to orchestrate Pods; we will introduce it later. Using a Deployment as an example, we examine what each component does during the creation of a Deployment resource.

kubectl sends a request to create a Deployment.

The API Server receives the request and writes the resource to etcd; subsequent component interactions follow the same pattern.

The Deployment controller watches for resource changes and creates a ReplicaSet.

The ReplicaSet controller watches for changes and creates Pods.

The Scheduler detects unbound Pods and selects an appropriate Node through matching and filtering.

kubelet on the selected Node discovers the new Pod and handles its creation and lifecycle.

kube-proxy initializes Service‑related resources, including service discovery and load‑balancing network rules.

Thus, coordinated actions of Kubernetes components complete the process from a Deployment request to fully running Pods.

Pod

Among Kubernetes API resources, the Pod is the most fundamental and smallest deployable unit.

Pods serve as a design pattern for tightly coupled containers that need to share network, storage, and configuration, such as servlet containers deploying WAR files or log collectors.

Within a Pod, containers share an infra container that provides a unified network namespace, and mounting the same volume enables shared storage, e.g., a directory on the host.

Container Orchestration

Container orchestration is Kubernetes' core capability, with many controller resources such as Deployment for stateless apps, StatefulSet for stateful apps, DaemonSet for daemon processes, and Job/CronJob for batch workloads.

Using Deployment as an example, the relationship is hierarchical: a ReplicaSet controls the number of Pods, while a Deployment controls the version of the ReplicaSet. This design enables horizontal scaling and versioned updates/rollbacks.

Horizontal Scaling

Horizontal scaling is simple: adjust the replica count in the ReplicaSet, e.g., from 2 to 3 to scale out, or decrease to scale in.

Update/Rollback

Updates and rollbacks illustrate the need for ReplicaSets. To change three instances from v1 to v2, the v1 ReplicaSet’s pod count decreases to 0 while the v2 ReplicaSet’s count increases to 3, completing the update; rollback reverses the process.

Rolling Update

In this example, pods are upgraded one by one, maintaining at least two available pods and at most four serving pods, ensuring service continuity and easy rollback if a new version has bugs.

In practice, the RollingUpdateStrategy can be configured; maxSurge specifies how many extra Pods the Deployment controller may create, and maxUnavailable indicates how many old Pods may be deleted.

Networking in Kubernetes

Having covered orchestration, how do containers communicate?

Kubernetes networking relies on three basic connectivity requirements:

Node ↔ Pod communication.

Pod ↔ Pod communication on the same Node.

Pod ↔ Pod communication across different Nodes.

In short, pods communicate via the cni0/docker0 bridge, and nodes reach pods through the same bridge.

Cross‑node pod communication can be implemented with solutions like Flannel’s VXLAN or host‑gw modes; Flannel learns other nodes’ network info from etcd and sets up routing tables to enable inter‑node communication.

Microservice – Service

Before proceeding, we need to understand an important resource: Service.

Why need Service? In microservices, Pods are instances; a Service represents the microservice, solving two problems:

Pod IPs are not fixed, making direct network calls unrealistic.

Service calls require load balancing across Pods.

Service uses label selectors to pick matching Pods and builds an Endpoints list for load balancing. Typically, all Pods of a microservice share a label such as app=xxx, and the Service’s selector is also app=xxx.

Service Discovery and Network Calls in Kubernetes

With the three‑way connectivity in place, we can explore how network calls in a microservice architecture are realized in Kubernetes.

This section briefly introduces how Kubernetes implements service discovery; detailed aspects are covered elsewhere.

Service‑to‑Service Calls

East‑west traffic between services uses two methods: ClusterIP and DNS.

ClusterIP is a Service type where kube-proxy uses iptables/ipvs to provide a virtual IP (VIP); accessing the VIP load‑balances to the backing Pods.

In DNS mode, a Service has an A record like service-name.namespace.svc.cluster.local pointing to the ClusterIP, so callers can simply use the service name.

External Access (North‑South)

External requests to a Kubernetes cluster are handled via three methods: NodePort, LoadBalancer, and Ingress.

NodePort exposes a specific port on the host via iptables to reach the Service.

LoadBalancer uses a cloud provider’s load balancer.

Ingress provides a unified external entry point, routing to backend Services, essentially a “service for services,” typically implemented using NodePort and LoadBalancer.

We have now covered the core Kubernetes concepts, its operation, and how microservices run on it, enabling us to understand discussions about Kubernetes.

Author: fredalxin Source: https://fredal.xin/what-is-kubernetes