Master Kubernetes: From Architecture to Deployment and Service Mesh

Kubernetes has become the king of container orchestration, a cluster management engine offering scaling, rolling upgrades, self‑healing, service discovery, and more.

This article quickly introduces Kubernetes and clarifies what is meant when we discuss it.

Kubernetes Architecture

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

The Master controls the entire cluster and includes components such as Api Server, Scheduler, and Controller, all of which interact with etcd for data storage.

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

Scheduler: Assigns Pods to Nodes based on scheduling rules.

Controller: Ensures resources reach their desired state.

Nodes provide the compute power where containers actually run, hosting components like kubelet and kube-proxy.

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

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

Starting from Creating a Deployment

A Deployment is a controller resource for orchestrating Pods; the following steps illustrate how Kubernetes components cooperate to create a Deployment.

kubectl sends a request to create a Deployment.

Api Server receives the request and writes the resource to etcd; subsequent component 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 detects unbound Pods, matches them to suitable Nodes, and binds them.

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

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

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

Pod

Pods are the smallest deployable unit in Kubernetes and serve as the fundamental building block for applications.

They address the need for tightly coupled containers that share network, storage, and configuration, enabling scenarios such as sidecar containers for logging or proxying.

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

Container Orchestration

Kubernetes offers many orchestration controllers, 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: Deployment controls ReplicaSet versioning, ReplicaSet controls the number of Pods, and Pods run the containers.

Horizontal Scaling

Scaling is achieved by adjusting the replica count in a ReplicaSet, e.g., changing from 2 to 3 replicas performs a horizontal scale‑out, and decreasing performs a scale‑in.

Update / Rollback

Updates involve creating a new ReplicaSet (e.g., version v2) while gradually reducing the old ReplicaSet (v1) replicas; rollback reverses this process.

Rolling Update

During a rolling update, Pods are upgraded one by one, ensuring at least two Pods remain available while up to four may serve traffic, allowing safe rollbacks if bugs appear. The RollingUpdateStrategy can tune maxSurge and maxUnavailable.

Kubernetes Networking

After understanding orchestration, the next question is how Pods communicate.

Kubernetes relies on three basic connectivity guarantees:

Node ↔ Pod communication.

Pod ↔ Pod communication on the same Node.

Pod ↔ Pod communication across different Nodes.

Different Pods communicate via the cni0/docker0 bridge; Nodes reach Pods through the same bridge. Cross‑Node Pod communication can be implemented with solutions like Flannel’s vxlan or host‑gateway mode, which uses etcd to share network information and set up routing tables.

Microservices – Service

In microservice architectures, a Service abstracts a set of Pods, providing a stable endpoint and load balancing.

Reasons for using a Service:

Pod IPs are not fixed, making direct calls impractical.

Load balancing across multiple Pod instances is required.

Pods are typically labeled, e.g., app=xxx, and a Service selects Pods with the same label selector app=xxx.

Service Discovery and Network Calls in Kubernetes

With the three‑way connectivity in place, Kubernetes enables both internal and external service communication.

Service‑to‑Service Calls

Two main internal call methods exist: ClusterIP and DNS.

ClusterIP creates a virtual IP (VIP) via kube-proxy (iptables/ipvs) that load‑balances traffic to the backing Pods.

DNS mode provides an A record such as service-name.namespace-name.svc.cluster.local that resolves to the ClusterIP, allowing callers to use the Service name directly.

External Access

North‑south traffic (external requests) can be exposed via three Service types: NodePort, LoadBalancer, and Ingress.

NodePort maps a host port to the Service, LoadBalancer provisions a cloud provider’s load balancer, and Ingress offers a unified entry point that routes traffic to multiple Services, effectively acting as a “service for services”.

In summary, we have covered the core concepts of Kubernetes, how its components work together, and how microservices run within a Kubernetes cluster.