#Ingress
2 posts
K8s Practice #2: App Deployment Skeleton — 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 Intermediate #3: Ingress and Ingress Controller — The External Entry Point
[K8s Basics #5](/en/posts/k8s-basics-5) covered LoadBalancer as the standard external entry point, but when dozens of Services need external exposure, spinning up one cloud LoadBalancer per Service quickly inflates cost and management overhead. Routing by domain or path also can't be solved with a single LoadBalancer. This post follows the object that gathers that burden in one place — `Ingress` — and the Ingress Controller (nginx / Traefik / GKE Ingress / AWS ALB Controller) that turns those manifests into actual traffic, walking through the two-layer model, host/path-based routing, `pathType`, TLS termination, and `IngressClass` in one cycle.