Containerization

Why Helm? Managing K8s applications with bare kubectl apply -f works at small scale, but as environments multiply (dev/staging/prod) and services grow, problems quickly surface: Hardcoded configuration: Each environment has its own YAML file with image tags, replica counts, and resource limits hardcoded. Changing a single value means editing ten files. No version management: Upgrades and rollbacks rely on manual records—no way to know what version was last deployed. No reusability: Deploying Redis and MySQL requires two completely different YAML sets with no way to templatize....

GitOps Core Principles GitOps is a modern continuous delivery methodology introduced by Weaveworks in 2017. It uses Git as the Single Source of Truth for infrastructure and application configuration, achieving continuous deployment through declarative practices. According to the ArgoCD documentation, GitOps follows four core principles: 1. Declarative System Infrastructure and application configurations are stored in Git as declarative descriptions (YAML/Helm/Kustomize): # Example Git repository structure infra-repo/ ├── apps/ │ ├── frontend/ │ │ ├── deployment....

Overview Kubernetes v1.24 officially removed dockershim, meaning Docker Engine is no longer used as the K8s container runtime. Instead, CRI-compliant (Container Runtime Interface) runtimes are used, with containerd being the de facto standard choice. Many ops teams perceive containerd as merely a “Docker replacement,” but its architecture, image management, and CLI tools differ significantly from Docker. This article provides a deep dive into the CRI specification, containerd architecture, daily operations, and migration from Docker....

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

The Hidden Costs of Oversized Images Many teams overlook image size during the early stages of containerization. A Spring Boot image often weighs 800MB–1.2GB, and even a Go application image can easily exceed 700MB. The problems caused by oversized images go far beyond “wasting a little disk space”: Slow pulls and deployment latency: In CI/CD pipelines or elastic scaling scenarios, nodes must pull the image before starting the container. A 1GB image takes over 80 seconds to download on a 100 Mbps internal network, while a 50MB image takes just 4 seconds....

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