Kubernetes

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:...