Kubernetes

Overview The Kubernetes scheduler is one of the most critical control plane components—it decides which node each Pod runs on. Scheduling quality directly impacts cluster resource utilization, application performance, and reliability. Understanding how the scheduler works is fundamental to effective K8s production operations. This article systematically covers the scheduling flow, filter-and-score mechanism, affinity, taints and tolerations, priority and preemption, and custom schedulers. Based on Kubernetes v1.30. Reference: Kubernetes Scheduler Documentation...

Four Core Requirements of the Kubernetes Networking Model The Kubernetes networking model is built on four core requirements. Understanding them is the foundation for mastering K8s networking. According to the official Kubernetes networking model documentation, these four requirements form the cornerstone of cluster network communication. 1. Pod-to-Pod Communication K8s requires that all Pods can communicate directly via IP without NAT (Network Address Translation). This means: Each Pod has its own IP address Pod-to-Pod communication uses real Pod IPs, without NAT translation Regardless of which Node a Pod is scheduled on, the Pod-to-Pod network remains flat and reachable This is the most fundamental design decision in the K8s networking model....

Overview Kubernetes Service provides Layer 4 load balancing, but in production, most web applications need Layer 7 routing capabilities: domain-based virtual hosting, path-based routing, TLS termination, and canary deployments. Ingress is K8s’s abstraction for Layer 7 routing, and the Ingress Controller is the concrete implementation of this abstraction. Choosing an Ingress Controller is not a small decision—it sits at the entry point of all external traffic. A wrong choice or misconfiguration can impact the availability of the entire cluster’s services....

Overview kubectl is the most commonly used tool for Kubernetes administrators, yet most people only use 20% of its capabilities. You type kubectl get pods -n production dozens of times a day without realizing a single alias can cut the keystrokes in half. When problems arise, you only know kubectl describe and kubectl logs, unaware that krew plugins can troubleshoot network, resource, and certificate issues with a single command. This article systematically covers the kubectl productivity toolchain — from aliases to plugins to interactive tools — to double your daily K8s operation efficiency....

K8s Storage System: Three-Layer Abstraction The Kubernetes storage system decouples storage consumers from providers through three layers of abstraction. This is the core concept for understanding container persistent storage. According to the K8s storage documentation, the three-layer structure is: ┌──────────────────────────────────────────────────────┐ │ Pod (Consumer) │ │ volumeMounts → volumes │ ├──────────────────────────────────────────────────────┤ │ PVC (Claim) — User requests storage │ │ "I need 10Gi RWO storage" │ ├──────────────────────────────────────────────────────┤ │ StorageClass (Dynamic Provisioning) │ │ "Use ceph-rbd driver, reclaim: Retain" │ ├──────────────────────────────────────────────────────┤ │ PV (Physical Resource) — Actual storage │ │ "10....

Semantics of Requests and Limits In Kubernetes, each container can be configured with CPU and Memory requests and limits. Many developers fail to distinguish between the two, leading to frequent Pod evictions or OOMKilled events. apiVersion: v1 kind: Pod metadata: name: api-server spec: containers: - name: app image: myapp:latest resources: requests: cpu: "250m" # 0.25 core memory: "256Mi" limits: cpu: "500m" # 0.5 core memory: "512Mi" Core Differences Dimension Requests Limits Phase At scheduling time At runtime Meaning Minimum guaranteed resources for the Pod Maximum resource cap for the Pod Scheduler behavior Scheduler uses requests to determine if a node has sufficient resources Scheduler ignores limits Runtime behavior Guaranteed share in cgroups CPU is throttled; Memory triggers OOMKilled Overcommit allowed Yes (sum of all Pod limits on a node can exceed node capacity) Memory overcommit is not recommended In simple terms:...