Cloud Native 16 min read

Mastering Kubernetes: From Pods to High Availability Explained

This article demystifies Kubernetes by explaining its core scheduling function, the role of Pods, YAML configuration, probes, high‑availability constructs like ReplicaSet and Deployment, internal components, resource limits, and practical cluster‑setup tools, providing a comprehensive guide for newcomers and practitioners alike.

macrozheng
macrozheng
macrozheng
Mastering Kubernetes: From Pods to High Availability Explained

Kubernetes has become an essential technology; companies that don’t adopt it struggle to stay relevant. Installing Kubernetes involves overcoming network hurdles, but the greater challenge lies in mastering its concepts.

Many Kubernetes articles are hard to read, including the official documentation. To understand Kubernetes, you must first grasp its primary function: scheduling containers based on overall resource usage and deploying them anywhere in the cluster.

The term anywhere implies that you cannot access deployed instances via conventional IP or port methods, which adds complexity.

Key resources that Kubernetes schedules include cpu, memory, network, and io. Before learning how these resources are scheduled, you need to understand what a Pod is—the fundamental unit of Kubernetes.

1. Pod

A Pod is the smallest scheduling unit in Kubernetes and contains one or more containers (you can think of them as Docker containers). All containers in a Pod share a single IP address, even when multiple containers are present.

Pods achieve this shared IP through a shared namespace and cgroup. Containers within the same Pod can communicate via localhost as if they were processes on the same host. Pods can also mount shared storage volumes, allowing containers to read and write the same data.

Sidecar containers, health probes, and other auxiliary containers also run inside a Pod, effectively replacing some responsibilities of the Docker pause container and creating shared network namespaces.

Pods are declared using YAML to avoid excessive API design. However, YAML files can become large and unwieldy, a common source of frustration for Kubernetes operators.

apiVersion: v1               # version
kind: Service                # resource type
metadata:
  namespace: bcmall          # namespace binding
  name: bcmall-srv           # Service name
spec:
  type: NodePort
  selector:
    app: container-bcmall-pod
  ports:
    - port: 8080            # service port inside cluster
      targetPort: 80        # pod port
      nodePort: 14000       # external port
      protocol: TCP

To apply this YAML, run: kubectl create -f ./bcmall.yaml Pods can be accessed via their IP address or internal DNS (via CoreDNS), behaving like ordinary machines where containers are just processes.

2. Probes and Hooks

After a Pod is scheduled, it must be initialized and its health reported. Kubernetes provides three types of probes: livenessProbe (heartbeat that kills the container if it’s not alive), readinessProbe (indicates the container is ready to receive traffic), and startupProbe (ensures the container has started before other probes run).

Typical settings use a 120‑second startupProbe, a 5‑second interval for livenessProbe, and a 10‑second interval for readinessProbe. These configurations are defined in the Pod’s YAML.

Hooks allow execution of custom commands at specific lifecycle moments: PostStart runs after container start, and PreStop runs before container termination.

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/busybox
    args:
    - /bin/sh
    - -c
    - "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

3. High‑Availability Terminology Explosion

YAML complexity grows because of the many kind types. The first high‑availability construct is ReplicaSet (RS), which maintains a desired number of Pod replicas. Deployments build on ReplicaSets, offering rolling updates and requiring proper label selectors in spec.template.metadata.labels.

Kubernetes uses labels for filtering resources, e.g.: kubectl get pod -n demo -l app=nginx,version=v1 Services provide stable, non‑IP access to Pods, abstracting away the dynamic IP changes of individual Pods. Service types include:

ClusterIP – virtual IP within the cluster.

NodePort – static port on each node (uses NAT).

LoadBalancer – external load balancer for outside traffic.

ExternalName – rarely used DNS alias.

4. Internal Components

Kubernetes consists of control‑plane components and node‑level daemons. Core control‑plane components:

kube‑apiserver – REST API entry point for authentication, authorization, and service discovery.

kube‑scheduler – assigns unscheduled Pods to nodes.

kube‑controller‑manager – maintains overall cluster state.

Node‑level daemons:

kubelet – communicates with the API server, reports node status, and runs assigned Pods.

kube‑proxy – handles Service traffic routing inside and outside the cluster.

5. Additional Concepts

StatefulSet – provides stable network IDs and ordered deployment for stateful workloads.

DaemonSet – ensures a copy of a Pod runs on every node.

ConfigMap & Secret – externalize configuration and sensitive data.

PV & PVC – persistent storage resources independent of Pod lifecycles.

StorageClass – enables dynamic provisioning of PVs.

Job – runs a task to completion.

CronJob – schedules periodic tasks.

CRD – custom resource definitions.

6. Resource Limits

Kubernetes enforces resource constraints via requests (minimum guaranteed) and limits (maximum). They are analogous to JVM -Xms and -Xmx settings. Example:

requests:
  memory: "64Mi"
  cpu: "250m"
limits:
  memory: "128Mi"
  cpu: "500m"

Memory uses Mi (mebibytes) and CPU uses millicores (m). For a 4‑core node, 250m represents ¼ of a core.

Kubernetes also offers LimitRange and ResourceQuota kinds to restrict resource requests across a namespace.

7. Cluster‑Setup Tools

Common tools for building a Kubernetes cluster include kind, minikube, kubeadm, and rancher2. While Rancher2 simplifies network issues for beginners, the officially recommended and most compatible tool is kubeadm, which can create a cluster with a single kubeadm init command.

The three main pain points in Kubernetes are:

YAML configuration explosion.

Complex and diverse networking options.

Intricate permission and certificate setup.

Understanding these areas enables you to master Kubernetes.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Cloud NativeDeploymentKubernetesDevOpsYAMLServicePod
macrozheng
Written by

macrozheng

Dedicated to Java tech sharing and dissecting top open-source projects. Topics include Spring Boot, Spring Cloud, Docker, Kubernetes and more. Author’s GitHub project “mall” has 50K+ stars.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.