24 ngày học EKS

TUẦN 1: Nền tảng Kubernetes & EKS

Ngày 1: Kubernetes là gì?

Sáng: Khái niệm, lợi ích, Pod/Service/Deployment/ReplicaSet.

Chiều: Kiến trúc (Control plane, Worker node, etcd, kube-apiserver).

Bài tập: Cài Minikube, deploy "Hello World", scale thử, khám phá dashboard.

Ngày 2: Amazon EKS Tổng quan

Sáng: EKS khác gì Kubernetes tự quản lý; control plane managed, node group, networking.

Chiều: Ngoài eksctl, giới thiệu Terraform module terraform-aws-modules/eks/aws - vì production không tạo cluster bằng CLI thủ công.

Bài tập: Tạo cluster bằng eksctl (để hiểu cơ chế) và viết lại bằng Terraform (để hiểu cách làm thật); kết nối kubectl, deploy app đơn giản.

Production Notes: eksctl phù hợp học/demo, nhưng cluster production cần Terraform/CDK để version control, code review, và tái tạo được (disaster recovery ở mức hạ tầng).

Ngày 3: Cấu hình Cluster & Helm

Sáng: Managed vs self-managed node group; EBS/EFS/FSx, PV/PVC.

Chiều: Helm - package manager cho Kubernetes: Chart, Release, Values, templating. Vì sao production không viết YAML tay cho từng service mà dùng Helm chart để chuẩn hóa & tái sử dụng.

Bài tập: Tạo managed node group; deploy app cần storage bền vững; viết 1 Helm chart cơ bản cho app "Hello World" thay vì manifest YAML thuần.

TUẦN 2: Mạng, IAM cho Pod & Autoscaling

Ngày 4: Mạng EKS-

Sáng: VPC CNI, IP-per-pod, ALB/NLB.

Chiều: Prefix Delegation (tăng mật độ IP/node để giảm IP exhaustion), Custom Networking (tách IP pod khỏi CIDR node), Security Groups for Pods (gán SG riêng theo pod thay vì theo node).

Bài tập: Bật Prefix Delegation trên node group; cấu hình Security Group riêng cho 1 pod nhạy cảm (ví dụ pod truy cập RDS).

Production Notes: IP exhaustion là lỗi phổ biến nhất khi cluster scale - không phải do thiếu compute mà do subnet hết IP vì mỗi pod cần 1 IP VPC (trừ khi dùng custom networking).

Ngày 5: IAM cho Pod - IRSA & EKS Pod Identity

Sáng

• Vấn đề của "IAM role gắn vào node": mọi pod trên node đó đều có chung quyền → vi phạm least-privilege nghiêm trọng.

• IRSA (IAM Roles for Service Accounts): OIDC provider, ServiceAccount annotation, trust policy - cấp quyền IAM riêng cho từng pod.

• EKS Pod Identity: cơ chế thay thế IRSA từ 2023+, đơn giản hóa (không cần OIDC per-cluster, không cần trust policy phức tạp) - khuyến nghị dùng cho cluster mới.

Chiều

• Bài tập: Cấu hình IRSA cho 1 pod truy cập S3 với quyền tối thiểu; làm lại bằng EKS Pod Identity và so sánh độ phức tạp.

Production Notes: Đây là lỗ hổng bảo mật phổ biến nhất trong EKS thực tế - dùng chung node IAM role cho mọi workload. Mọi pod truy cập AWS resource phải qua IRSA/Pod Identity, không ngoại lệ.

Ngày 6: Autoscaling - Karpenter

Sáng

• Giới hạn của Cluster Autoscaler truyền thống (phụ thuộc Auto Scaling Group, chậm, không tối ưu instance type).

• Karpenter: provisioning node theo pod pending trực tiếp, chọn instance type/AZ tối ưu tự động, consolidation (gộp node để tiết kiệm chi phí), hỗ trợ Spot tự động thay thế khi bị reclaim.

• NodePool và EC2NodeClass (cấu hình Karpenter thế hệ mới).

Chiều

• Bài tập: Cài Karpenter, viết NodePool cho phép chọn cả On-Demand và Spot; tạo tải để quan sát Karpenter tự provision node; bật consolidation và quan sát node bị gộp khi tải giảm.

Production Notes: Karpenter hiện là khuyến nghị chính thức của AWS thay Cluster Autoscaler cho cluster mới - tiết kiệm chi phí đáng kể nhờ chọn đúng instance type theo nhu cầu thực tế thay vì cố định theo node group.

Ngày 7: EKS Auto Mode & Lựa chọn mô hình vận hành

Sáng: EKS Auto Mode - AWS tự quản lý luôn cả node, networking, storage add-on (giảm gánh vận hành, đánh đổi bằng ít tùy biến hơn). So sánh ma trận: Managed Node Group vs Self-managed vs Fargate vs Karpenter vs Auto Mode - khi nào dùng gì.

Chiều: Bài tập: Tạo thử 1 cluster ở chế độ Auto Mode, so sánh trải nghiệm vận hành với cluster Karpenter đã làm ở Ngày 6.

TUẦN 3: Bảo mật, Policy Enforcement & Add-ons

Ngày 8: Bảo mật EKS nền tảng

Sáng: IAM roles/policies (ôn lại trong bối cảnh IRSA), Network Policy.

Chiều: Add-on EKS: CoreDNS, kube-proxy, VPC CNI, metrics-server - quản lý qua EKS Add-ons API thay vì cài tay.

Bài tập: Áp dụng Network Policy giới hạn traffic giữa namespace; cập nhật add-on qua eksctl/Terraform thay vì Helm thủ công.

Ngày 9: Pod Security Standards & Policy Engine

Sáng

• Pod Security Policy (PSP) đã bị loại bỏ khỏi Kubernetes - thay bằng Pod Security Standards (PSA): namespace label enforce/audit/warn theo mức Privileged/Baseline/Restricted.

• Policy Engine: OPA/Gatekeeper hoặc Kyverno (đang phổ biến hơn vì viết bằng YAML thay Rego) để enforce quy tắc tùy chỉnh (ví dụ: bắt buộc resource limit, cấm image từ registry không tin cậy).

Chiều

• Bài tập: Gắn PSA "restricted" cho namespace production; viết Kyverno policy chặn deploy pod không có resources.limits hoặc dùng image :latest.

Production Notes: Không có policy engine, không gì ngăn được developer deploy pod chạy privileged hoặc pull image từ Docker Hub public không kiểm soát - đây là yêu cầu bắt buộc cho compliance (SOC2/PCI).

Ngày 10: Quản lý Secrets

Sáng: Kubernetes Secret mặc định chỉ base64 (không mã hóa thật) - rủi ro nếu etcd bị lộ. Giải pháp: bật envelope encryption với KMS cho EKS secrets.

Chiều: External Secrets Operator - đồng bộ secret từ AWS Secrets Manager/Parameter Store vào Kubernetes tự động, tránh secret nằm trong Git.

Bài tập: Bật KMS envelope encryption cho cluster; cài External Secrets Operator, đồng bộ 1 secret từ Secrets Manager vào pod.

Ngày 11: Observability & Fargate

Sáng: CloudWatch Logs/Metrics + giới hạn của CloudWatch Container Insights ở scale lớn - giới thiệu Prometheus + Grafana (qua Amazon Managed Prometheus/Grafana) làm chuẩn observability thực sự cho production, và OpenTelemetry cho distributed tracing.

Chiều: EKS Fargate - trường hợp sử dụng, giới hạn (không hỗ trợ DaemonSet, privileged pod).

Bài tập: Triển khai Amazon Managed Prometheus + Grafana, tạo dashboard theo dõi latency/error rate; deploy 1 app lên Fargate profile.

TUẦN 4: GitOps, Ingress & Service Mesh

Ngày 12: GitOps với ArgoCD

Sáng

• Vì sao kubectl apply thủ công không phù hợp production: không audit trail, dễ config drift.

• GitOps: Git là nguồn chân lý duy nhất; ArgoCD tự động đồng bộ cluster theo state trong Git, phát hiện và cảnh báo drift.

• App of Apps pattern để quản lý nhiều microservices qua 1 ArgoCD instance.

Chiều

• Bài tập: Cài ArgoCD, kết nối 1 Git repo chứa Helm chart app đã làm Ngày 3; thử sửa trực tiếp trên cluster bằng kubectl và quan sát ArgoCD tự động revert (self-healing).

Production Notes: GitOps là chuẩn bắt buộc cho mọi tổ chức vận hành nhiều cluster/nhiều môi trường - không có nó, không thể trả lời câu hỏi "cluster đang chạy config gì" một cách đáng tin cậy.

Ngày 13: Ingress & AWS Load Balancer Controller

Sáng: So với Ingress cũ, AWS Load Balancer Controller (ALB/NLB provisioning tự động qua annotation); giới thiệu Gateway API - chuẩn thế hệ mới thay thế Ingress, tách biệt vai trò platform team (Gateway) và app team (HTTPRoute).

Chiều: Bài tập: Cài AWS Load Balancer Controller, expose app qua ALB Ingress; làm lại bằng Gateway API (HTTPRoute) để so sánh.

Ngày 14: Service Mesh - Istio/App Mesh

Sáng

• Bài toán: mTLS giữa service, traffic splitting (canary), retry/circuit breaker tự động - Kubernetes Service không giải quyết được các nhu cầu này.

• Kiến trúc Service Mesh (sidecar proxy - Envoy), so sánh Istio vs AWS App Mesh (đã deprecated, khuyến nghị Istio hoặc Cilium Service Mesh) vs không dùng mesh (dùng VPC Lattice ở tầng VPC nếu đủ).

Chiều

• Bài tập: Cài Istio, bật sidecar injection cho 1 namespace, cấu hình mTLS strict, thực hiện canary deployment 90/10 giữa 2 version của cùng 1 service.

Production Notes: Không phải mọi cluster cần Service Mesh - chỉ cân nhắc khi có nhiều microservice cần mTLS/traffic shaping tinh vi; nếu chỉ cần kết nối cross-VPC đơn giản, VPC Lattice (tầng hạ tầng) nhẹ hơn nhiều so với việc vận hành Istio.

Ngày 15: Multi-tenancy & Namespace Isolation

Sáng: Chiến lược multi-tenant: namespace-per-team, ResourceQuota, LimitRange, RBAC theo namespace.

Chiều: Bài tập: Thiết lập RBAC cho 2 team chỉ được thao tác trong namespace riêng; áp ResourceQuota giới hạn CPU/memory theo namespace.

TUẦN 5: Vận hành, Chi phí & Khắc phục Sự cố

Ngày 16: Nâng cấp Cluster An toàn

Sáng: Nâng cấp phiên bản Kubernetes, rolling update; chiến lược Blue/Green Cluster Upgrade cho hệ thống critical (dựng cluster mới, di chuyển traffic dần thay vì upgrade tại chỗ).

Chiều: Bài tập: Thực hiện rolling update ứng dụng; mô phỏng kịch bản blue/green cluster migration ở quy mô nhỏ.

Ngày 17: Tối ưu chi phí EKS

Sáng: Spot instance, Cost Explorer, cost allocation tag (như bản gốc) + Karpenter consolidation, Vertical Pod Autoscaler (VPA) để right-size request/limit dựa trên usage thật (tránh over-provisioning phổ biến).

Chiều: Bài tập: Bật VPA ở chế độ recommendation, so sánh request hiện tại với đề xuất; tính toán tiết kiệm chi phí khi áp dụng Karpenter consolidation + Spot.

Ngày 18: Backup & Disaster Recovery

Sáng: Etcd/control plane do AWS quản lý (không cần backup thủ công), nhưng application state và cluster resources thì có - Velero để backup namespace/PV, restore sang cluster khác hoặc region khác.

Chiều: Bài tập: Cài Velero với S3 backend, backup 1 namespace có PVC, xóa namespace, restore lại từ backup và kiểm tra dữ liệu.

Production Notes: "EKS managed control plane" không đồng nghĩa "không cần backup" - dữ liệu ứng dụng, cấu hình RBAC, Secret, ConfigMap vẫn có thể mất nếu không có chiến lược backup riêng.

Ngày 19: Khắc phục sự cố

Sáng: Kỹ thuật debug (kubectl describe/logs/events, kubectl debug), các lỗi thường gặp: CrashLoopBackOff, ImagePullBackOff, OOMKilled, pod Pending do thiếu IP/resource.

Chiều: Bài tập: Debug 3 kịch bản lỗi cấy sẵn (thiếu IRSA permission gây API call fail; ResourceQuota chặn deploy; Karpenter không provision do NodePool constraint sai).

TUẦN 6: Dự án

Ngày 20: Thiết kế & Chuẩn bị

Sáng: Chọn ứng dụng microservices (ví dụ: cửa hàng trực tuyến - user/product/cart service); chia nhỏ service, chọn công nghệ.

Chiều: Thiết kế kiến trúc tổng thể; tạo IAM/IRSA plan cho từng service; khởi tạo Git repo theo mô hình GitOps (source repo + config repo riêng).

Ngày 21: Xây dựng, Đóng gói & Helm Chart

Sáng: Viết từng microservice, API endpoint, unit/integration test.

Chiều: Đóng gói Docker image, đẩy lên ECR; viết Helm chart chuẩn hóa cho từng service (không viết YAML rời rạc).

Ngày 22: Triển khai

Sáng: Cấu hình cluster: Karpenter NodePool, PSA restricted, Kyverno policy, External Secrets.

Chiều: Triển khai qua ArgoCD (không kubectl apply tay); cấu hình IRSA/Pod Identity riêng cho từng service; expose qua AWS Load Balancer Controller/Gateway API.

Ngày 23: Observability, Resilience & Kiểm thử

Sáng: Tích hợp Prometheus/Grafana dashboard, OpenTelemetry tracing; cấu hình HPA + Karpenter cho autoscale 2 tầng (pod + node).

Chiều: Load test (k6/Locust); tuỳ chọn: cấu hình canary deployment qua Istio nếu dự án có ≥3 service gọi lẫn nhau.

Ngày 24: Hoàn thiện, Backup & Đánh giá

Sáng: Cấu hình Velero backup; viết runbook vận hành (upgrade, rollback, incident response).

Chiều: Trình bày dự án; đánh giá theo rubric: bảo mật (IRSA/PSA/Kyverno), khả năng mở rộng (Karpenter/HPA), chi phí (Spot/consolidation), khả năng phục hồi (Velero/multi-AZ), mức độ GitOps hóa.

Sản phẩm: Toàn bộ cluster config + Helm chart + ArgoCD Application trong Git repo (có CI pipeline build/push image); tài liệu kiến trúc; dashboard Grafana; báo cáo chi phí.