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