Container Deployment

Overview The default Kubernetes security posture can be summed up in one word: open. The default ServiceAccount has broad API access (depending on version and PSP configuration), Pods run as root, containers can mount the host filesystem, and the network is fully open. This “default open” design lowers the barrier to entry but creates significant security risks in production. This article covers RBAC permission models, ServiceAccount management, Pod Security Standards, SecurityContext, NetworkPolicies, and audit logging—systematically explaining K8s security hardening practices....

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

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

Overview Many teams perceive Docker Compose as merely a “local development orchestration tool.” In reality, for small to medium production scenarios (single node or a handful of nodes), Compose remains a highly cost-effective solution. Its syntax is simple, the learning curve is low, and it doesn’t require a full K8s cluster operations team—yet it handles multi-service orchestration, dependency management, health checks, and resource limits effectively. This article skips basic Compose syntax and focuses on real production pain points: how to manage service dependencies without cascading startup failures, how to write reliable health checks, how to avoid hardcoding secrets in compose files, how to prevent logs from filling up disk space, and when to migrate from Compose to K8s....

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