Kubernetes
K8s Practice #3: DB Integration — RDS / Secrets Manager / External Secrets / Connection Pool
The `myshop-api` exposed in [#2](/en/posts/k8s-practice-2) is still an empty shell with no data store. This post organizes the flow of bringing up RDS PostgreSQL with Terraform, storing the master secret in AWS Secrets Manager, auto-syncing it into a K8s Secret with External Secrets Operator, accessing AWS without static credentials via IRSA, and adding PgBouncer as a connection pool. It also covers automating schema migration as a Job.
K8s Practice #2: The Foundation of App Deployment — Deployment / Service / Ingress / Helm
The stage of putting `myshop-api` on the empty EKS cluster brought up in [#1](/en/posts/k8s-practice-1). We organize Deployment / Service / Ingress / ConfigMap / Secret / ServiceAccount / HPA as one bundle, auto-provision an ALB with AWS Load Balancer Controller, and package the bundle as a Helm chart so the same chart deploys to dev and prod with different values.
K8s Practice #1: EKS Cluster Setup — Terraform / eksctl / IRSA / Addons
The first post in the K8s Practice series. We follow the path of building a real operational cluster rather than a toy abstraction. Defining the VPC and EKS cluster with Terraform, setting up node groups and IRSA, laying on the essential addons (VPC CNI, CoreDNS, kube-proxy, EBS CSI), and comparing eksctl as a faster setup option along the way. The starting point for the imaginary service myshop-api used throughout the 6-post series.
K8s Advanced #6: GitOps — ArgoCD / Flux
The last post in the K8s Advanced series. GitOps — the operational model where the source of truth for manifests lives in git and a controller inside the cluster watches git to sync automatically. Covers the difference between push and pull models, ArgoCD's Application CRD and sync wave, Flux's Source / Kustomization / HelmRelease, directory structure patterns, and how to safely store secrets in git via Sealed Secrets / External Secrets. Also includes a 6-post K8s Advanced retrospective and a preview of the next track, K8s Practice.
K8s Advanced #5: Observability — Prometheus / Grafana / Loki / OpenTelemetry
Operational cluster observability is composed of three axes — metrics, logs, and traces. The K8s standard stack for each axis is nearly settled. Metrics with Prometheus + kube-state-metrics + node-exporter, logs with Loki (or EFK), traces with OpenTelemetry, visualization with Grafana, alerting with Alertmanager. This post organizes the three-axis model, the standard components for each axis, and operational principles like cardinality, retention period, and alert design — all in one cycle.
K8s Advanced #4: CRD and the Operator Pattern — controller-runtime
One reason K8s is powerful is that you can extend its API itself. Defining new object kinds with CustomResourceDefinition and writing a reconcile loop for those objects with controller-runtime makes domain objects live as standard resources on top of K8s. Objects with names like PostgresCluster, RedisFailover, KafkaBroker are the result. This post organizes the CRD model, an Operator skeleton based on controller-runtime, and ownerReference / finalizer / status subresource — all in one cycle.
K8s Advanced #3: Admission Controller — OPA Gatekeeper / Kyverno
The K8s API server has a stage that can inspect and mutate manifests right before they're stored in etcd. This stage, called Admission Controller, is the entry point for the operational cluster's policy engine. Policies like "reject containers without limits," "force specific labels," "restrict image origins" are blocked at the manifest level without changing a line of code. This post organizes the position of the admission stage, built-in controllers, ValidatingWebhook and MutatingWebhook, and the models of two policy engines OPA Gatekeeper and Kyverno — all in one cycle.
K8s Advanced #2: RBAC / ServiceAccount in Depth — Aggregated ClusterRole / Impersonation / IRSA / Workload Identity
[Intermediate #7](/en/posts/k8s-intermediate-7) covered the four RBAC objects and the ServiceAccount model. On top of that, there's more depth encountered in operational clusters. Aggregated ClusterRole that makes ClusterRoles extensible by composing them via labels, Impersonation that temporarily acts as another user's permission, the flow where ServiceAccount tokens shifted from legacy secrets to projected tokens, and EKS's IRSA and GKE's Workload Identity that tie K8s ServiceAccounts to cloud IAM — one more layer of the permission model in depth.
K8s Advanced #1: CNI in Depth — Calico / Cilium / eBPF
The first post in the K8s Advanced series. In [Intermediate #7](/en/posts/k8s-intermediate-7), one line was left while covering NetworkPolicy: "the manifest is K8s standard, but actually blocking traffic is the CNI plugin's job." This post unfolds that one line. What CNI is, how the same K8s manifest runs differently on Calico vs Cilium, and how eBPF redraws the data plane — all in one cycle.
K8s Intermediate #7: RBAC / NetworkPolicy / ResourceQuota — Security and Resource Policy
The final post in the K8s Intermediate series. Through [#6](/en/posts/k8s-intermediate-6) we covered the workload operations model — controllers, persistent data, external entry points, resource model, health checks, autoscaling. This post covers the three objects `RBAC`, `NetworkPolicy`, and `ResourceQuota` that fill the last gap of multi-tenant operation, where multiple teams and environments share one cluster. The three dimensions of who can create objects, what traffic flows, and how much can be made are all bundled as namespace-level policy, and the real value of Namespace briefly noted in [Basics #7](/en/posts/k8s-basics-7) is unfolded by these three objects. Since this is the last post in the series, a 7-post retrospective and a preview of the next track (K8s Advanced) is also included.
K8s Intermediate #6: Autoscaling — HPA / VPA / Cluster Autoscaler
The model covered through [#5](/en/posts/k8s-intermediate-5) was at the dimension of a single Pod's resources and health signals. But operational load swings with time, user patterns, and events, and having a person manually adjust `replicas` each time quickly hits a wall. This post walks through the three dimensions of autoscaling that fill that gap — `HPA` which auto-scales Pod count, `VPA` which auto-recommends and adjusts a Pod's resource requests/limits, and `Cluster Autoscaler` which auto-adds and removes nodes themselves — in one cycle. The metrics-server precondition, HPA's `autoscaling/v2` manifest and algorithm, the asymmetric `behavior` of scale up/down, custom metrics and KEDA, VPA's three components, HPA/VPA conflict, Karpenter — all included.
K8s Intermediate #5: Health Checks — liveness / readiness / startup probes
If [#4](/en/posts/k8s-intermediate-4) covered the Pod's resource model, this post covers the model of how K8s judges whether a container is "alive" and "ready to take traffic." Three kinds of probes — liveness, readiness, startup — each play a different role, and misconfiguring them leads directly to operational incidents like infinite restart loops, traffic misses, and startup failure. This post walks through `httpGet` / `tcpSocket` / `exec` check methods, common parameters like `initialDelaySeconds` / `periodSeconds` / `failureThreshold`, the cascading failure that happens when external dependencies are put into liveness, and the graceful shutdown drawn by `terminationGracePeriodSeconds` and the PreStop hook — all in one cycle.