Understanding Kubernetes Architecture, Deployments, Pods, and Service Networking

Kubernetes Architecture

From a macro view, Kubernetes consists of a Master, Nodes, and etcd. The Master controls the cluster and includes the API Server, Scheduler, and Controller, all interacting with etcd for data storage.

API Server : unified entry point for resource operations, abstracts direct etcd interaction, provides security, registration, and discovery.

Scheduler : assigns Pods to Nodes based on scheduling rules.

Controller : ensures resources reach the desired state.

Nodes provide compute power and run containers, kubelet, and kube-proxy.

kubelet : manages container lifecycle, monitors via cAdvisor, performs health checks, reports node status.

kube-proxy : implements service discovery and load balancing, watches Service/Endpoints changes.

Creating a Deployment

A Deployment is a controller that orchestrates Pods. The creation flow is:

kubectl sends a create‑deployment request.

API Server stores the request in etcd.

Deployment controller watches the resource and creates a ReplicaSet.

ReplicaSet controller creates Pods.

Scheduler binds each unassigned Pod to a suitable Node.

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

kube-proxy sets up Service‑related networking rules.

After these steps the Pods run as expected.

Pod

A Pod is the smallest deployable unit in Kubernetes, designed for tightly coupled containers that share network, storage, and configuration.

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

Container Orchestration

Kubernetes offers various controllers for different workloads: Deployment (stateless), StatefulSet (stateful), DaemonSet (daemon processes), Job/CronJob (batch).

Deployments manage ReplicaSets, which control the number of Pods, and enable horizontal scaling and versioned updates/rollbacks.

Horizontal Scaling

Scaling is achieved by adjusting the replica count in the ReplicaSet.

Update / Rollback

Updating changes the replica count from the old ReplicaSet to the new one; rollback reverses the process.

Rolling Update

During a rolling update, Pods are upgraded one by one while maintaining a minimum number of available Pods, allowing quick rollback if a bug appears.

Kubernetes Networking

Three basic connectivity requirements:

Node ↔ Pod communication.

Pod ↔ Pod on the same Node.

Pod ↔ Pod across different Nodes.

Pod‑to‑Pod communication uses the cni0/docker0 bridge; inter‑Node pod traffic can be implemented with solutions like Flannel (vxlan/hostgw) that use etcd to distribute routing information.

Microservice – Service

A Service provides a stable endpoint for a set of Pods, handling dynamic Pod IPs and load balancing.

Typical usage adds a label such as app=xxx to Pods and creates a Service with the same selector app=xxx .

Service Discovery and Network Calls

Inside the cluster, Service traffic can be accessed via ClusterIP (VIP) or DNS. ClusterIP creates a virtual IP that kube-proxy routes to backend Pods. DNS resolves service-name.namespace.svc.cluster.local to the ClusterIP.

External access (north‑south traffic) is provided by NodePort, LoadBalancer, or Ingress, with Ingress acting as a unified entry point that routes to Services.

By understanding these concepts, readers can grasp how Kubernetes operates and how microservices run on it.