Claude + Kubernetes — Sinh manifest, debug pods và tối ưu cluster

Kubernetes là nền tảng orchestration container được sử dụng rộng rãi nhất hiện nay, nhưng đi kèm với đó là sự phức tạp đáng kể trong cấu hình và vận hành. Từ việc viết manifest YAML cho Deployment, Service, Ingress đến troubleshooting pod failures và tối ưu resource allocation — mỗi bước đều đòi hỏi kiến thức chuyên sâu. Claude có thể trở thành trợ lý đắc lực giúp bạn làm việc hiệu quả hơn với Kubernetes ở mọi giai đoạn.

Sinh Kubernetes Manifest từ yêu cầu

Deployment và Service cơ bản

Bắt đầu với trường hợp phổ biến nhất: deploy một ứng dụng web lên Kubernetes. Thay vì tự viết YAML từ đầu, hãy mô tả yêu cầu cho Claude và để Claude sinh manifest hoàn chỉnh.

Sinh Kubernetes manifest cho ứng dụng web với yêu cầu:

Application:
- Image: myregistry.io/api-server:v2.1.0
- Port: 8080 (HTTP), 8443 (gRPC)
- Environment variables từ ConfigMap và Secret
- Cần mount volume cho config file tại /app/config

Deployment:
- 3 replicas, RollingUpdate strategy (maxUnavailable: 1, maxSurge: 1)
- Resource requests: 256m CPU, 512Mi memory
- Resource limits: 500m CPU, 1Gi memory
- Liveness probe: HTTP GET /healthz port 8080, delay 15s
- Readiness probe: HTTP GET /ready port 8080, delay 5s
- Pod anti-affinity: không chạy 2 pod trên cùng node

Service:
- ClusterIP service cho internal traffic
- Expose port 80 -> target 8080, port 443 -> target 8443

Ingress:
- NGINX Ingress Controller
- Host: api.example.com
- TLS với cert-manager (Let's Encrypt)
- Rate limiting: 100 requests/second
- CORS headers cho frontend.example.com

Namespace: production
Labels theo convention: app.kubernetes.io/*

Claude sẽ sinh ra bộ manifest hoàn chỉnh bao gồm Deployment, Service, Ingress, ConfigMap, HorizontalPodAutoscaler và các annotation cần thiết. Điểm quan trọng là Claude sẽ thêm các best practices mà bạn có thể quên, như securityContext, podDisruptionBudget và topology spread constraints.

Stateful Applications

Với các ứng dụng stateful như database, message queue hay distributed cache, bạn cần StatefulSet thay vì Deployment. Claude hiểu rõ sự khác biệt và sẽ sinh cấu hình phù hợp.

Sinh Kubernetes manifest cho PostgreSQL cluster với:

1. StatefulSet: 3 replicas (1 primary + 2 replicas)
2. PersistentVolumeClaim: 100Gi mỗi pod, storageClass: gp3-encrypted
3. Service:
   - Headless service cho StatefulSet
   - ClusterIP service cho primary (read-write)
   - ClusterIP service cho replicas (read-only)
4. ConfigMap cho postgresql.conf tuning:
   - shared_buffers: 2GB
   - work_mem: 256MB
   - max_connections: 200
5. Secret cho credentials (placeholder values)
6. PodDisruptionBudget: minAvailable 2
7. Init container để setup replication

Namespace: databases
Storage encryption phải enabled

Troubleshooting Pods với Claude

Debug Kubernetes pods là kỹ năng quan trọng nhưng thường tốn nhiều thời gian. Claude có thể phân tích output từ các lệnh kubectl và đưa ra hướng giải quyết nhanh chóng.

Pod không start được

Pod của tôi stuck ở trạng thái CrashLoopBackOff.
Đây là thông tin debug:

kubectl describe pod:
[Dán output kubectl describe pod]

kubectl logs (previous container):
[Dán output kubectl logs --previous]

kubectl get events --field-selector involvedObject.name=pod-name:
[Dán events]

Hãy phân tích:
1. Root cause của CrashLoopBackOff
2. Các bước fix cụ thể
3. Cách prevent vấn đề tương tự

Pod bị OOMKilled

Pod bị OOMKilled liên tục. Thông tin:

kubectl describe pod:
[Dán output - chú ý phần Last State và Reason]

kubectl top pod (trước khi bị kill):
[Dán metrics nếu có]

Application: Java Spring Boot
Current limits: 512Mi memory
JVM flags hiện tại: -Xmx256m -Xms128m

Hãy phân tích:
1. Tại sao bị OOM dù Xmx đã set thấp hơn limit?
2. Cách tính memory limit phù hợp cho JVM container
3. Recommend JVM flags cho container environment
4. Có nên dùng -XX:+UseContainerSupport?

Claude sẽ giải thích rằng JVM sử dụng memory ngoài heap (metaspace, thread stacks, direct buffers, native memory) và cách tính tổng memory cần thiết. Đây là kiến thức chuyên sâu mà nhiều developer bỏ qua khi containerize ứng dụng Java.

Service không kết nối được

Service A không gọi được Service B trong cùng cluster.
Thông tin:

Service A (namespace: app):
[kubectl get svc -n app]
[kubectl get endpoints -n app]

Service B (namespace: backend):
[kubectl get svc -n backend]
[kubectl get endpoints -n backend]

Network Policy hiện tại:
[kubectl get networkpolicy -n backend -o yaml]

DNS test từ pod A:
[kubectl exec -it pod-a -- nslookup service-b.backend.svc.cluster.local]

Curl test:
[kubectl exec -it pod-a -- curl -v http://service-b.backend.svc.cluster.local:8080]

Hãy debug step-by-step và xác định nguyên nhân.

Tối ưu Resource Limits

Thiết lập resource requests và limits đúng cách là một trong những thách thức lớn nhất khi vận hành Kubernetes. Đặt quá cao gây lãng phí, đặt quá thấp gây OOMKill hoặc CPU throttling.

Phân tích resource usage của cluster và đề xuất tối ưu.

Metrics từ Prometheus/Grafana (7 ngày qua):

Namespace: production
Pod: api-server
- CPU request: 500m, limit: 1000m
- Memory request: 512Mi, limit: 1Gi
- Actual CPU usage: P50=120m, P95=350m, P99=480m
- Actual Memory usage: P50=380Mi, P95=420Mi, P99=450Mi
- Số lần bị CPU throttled: 23 lần trong 7 ngày
- Số lần OOMKilled: 0

Pod: worker
- CPU request: 1000m, limit: 2000m
- Memory request: 2Gi, limit: 4Gi
- Actual CPU usage: P50=80m, P95=150m, P99=200m
- Actual Memory usage: P50=256Mi, P95=300Mi, P99=320Mi
- Số lần bị CPU throttled: 0
- Số lần OOMKilled: 0

Hãy đề xuất:
1. Resource requests/limits mới cho từng pod
2. Giải thích lý do điều chỉnh
3. Ước tính tiết kiệm node capacity
4. Có nên bỏ CPU limit không? (Debate về CPU limits)
5. VPA (Vertical Pod Autoscaler) có phù hợp không?

Claude sẽ phân tích chi tiết: worker đang over-provisioned nghiêm trọng (chỉ dùng 10-20% CPU và 8-16% memory so với request), trong khi api-server bị CPU throttled do limit quá gần actual P99. Claude cũng sẽ đề cập đến cuộc tranh luận trong cộng đồng Kubernetes về việc có nên set CPU limit hay không.

Helm Chart Scaffolding

Helm là package manager phổ biến nhất cho Kubernetes. Claude có thể giúp bạn tạo Helm chart từ các manifest có sẵn hoặc từ yêu cầu mới.

Tạo Helm chart cho microservice với yêu cầu:

Chart name: api-gateway
Chart version: 1.0.0
App version: 2.3.0

Templates cần có:
1. Deployment với configurable replicas, image, resources
2. Service (ClusterIP hoặc LoadBalancer tùy values)
3. Ingress (optional, enabled qua values)
4. HPA (optional, configurable min/max replicas)
5. ConfigMap từ values
6. Secret (external-secrets operator compatible)
7. ServiceAccount với optional IAM role annotation (EKS)
8. PodDisruptionBudget
9. NetworkPolicy

values.yaml phải có:
- Defaults hợp lý cho development environment
- Comments giải thích mỗi field
- Phân chia rõ ràng theo section

Yêu cầu thêm:
- _helpers.tpl với các template functions chuẩn
- NOTES.txt hướng dẫn sau khi install
- Chart.yaml với dependencies (nếu cần)
- Hỗ trợ multiple environments qua values files:
  values-dev.yaml, values-staging.yaml, values-prod.yaml

Network Policies

Network Policy là tính năng quan trọng để bảo mật traffic giữa các pods trong cluster. Tuy nhiên, viết Network Policy đúng cách khá phức tạp vì logic default-deny và cách match labels có thể gây nhầm lẫn.

Thiết kế Network Policies cho microservice architecture sau:

Namespace: production
Services:
- frontend (port 3000) - nhận traffic từ Ingress Controller
- api-gateway (port 8080) - nhận traffic từ frontend
- user-service (port 8081) - nhận traffic từ api-gateway
- order-service (port 8082) - nhận traffic từ api-gateway
- payment-service (port 8083) - nhận traffic từ order-service
- notification-service (port 8084) - nhận từ order-service và user-service

External:
- Tất cả services cần gọi DNS (kube-dns)
- payment-service cần gọi external payment gateway (api.stripe.com)
- notification-service cần gọi SMTP server (10.0.1.50:587)

Yêu cầu:
1. Default deny all ingress và egress cho namespace
2. Network Policy cho từng service theo principle of least privilege
3. Cho phép Prometheus scrape metrics (port 9090) từ namespace monitoring
4. Giải thích logic của mỗi policy

RBAC Configuration

Role-Based Access Control trong Kubernetes quyết định ai được làm gì trong cluster. Cấu hình RBAC sai có thể gây ra lỗ hổng bảo mật nghiêm trọng hoặc ngược lại, block developer không thể làm việc.

Thiết kế RBAC cho Kubernetes cluster với các role sau:

1. Platform Team (cluster-admin level):
   - Full access toàn cluster
   - Quản lý namespaces, nodes, storage
   - Install/upgrade Helm releases

2. Backend Developers:
   - Namespace: staging, development
   - Quyền: get/list/watch trên mọi resource
   - Quyền: create/update/delete Deployments, Services, ConfigMaps
   - Quyền: exec vào pods, xem logs
   - KHÔNG được: tạo/sửa NetworkPolicy, RBAC, PV/PVC
   - KHÔNG được: access namespace production

3. Frontend Developers:
   - Namespace: staging-frontend
   - Quyền: get/list/watch Pods, Services, Deployments
   - Quyền: xem logs
   - KHÔNG được: exec vào pods, sửa resource

4. CI/CD Service Account:
   - Namespace: production, staging
   - Quyền: update Deployments (chỉ image tag)
   - Quyền: create/delete Jobs
   - KHÔNG được: access Secrets directly

5. Monitoring (read-only):
   - All namespaces
   - Quyền: get/list/watch trên mọi resource
   - KHÔNG được: bất kỳ write operation nào

Sinh ClusterRole, Role, ClusterRoleBinding, RoleBinding cho tất cả.
Giải thích principle of least privilege được áp dụng như thế nào.

Horizontal Pod Autoscaler nâng cao

HPA v2 hỗ trợ scaling dựa trên nhiều metrics khác nhau, không chỉ CPU và memory. Claude có thể giúp bạn cấu hình HPA phù hợp với workload cụ thể.

Cấu hình HPA cho api-gateway với yêu cầu:

Scaling metrics (ưu tiên từ cao đến thấp):
1. Custom metric: http_requests_per_second (từ Prometheus)
   - Target: 1000 rps per pod
2. CPU utilization: target 70%
3. Memory utilization: target 80%

Scaling behavior:
- Min replicas: 3
- Max replicas: 20
- Scale up: tối đa 4 pods mỗi 60 giây
- Scale down: tối đa 2 pods mỗi 300 giây
- Stabilization window: 120s cho scale down

Yêu cầu:
1. HPA v2 manifest
2. Prometheus Adapter configuration cho custom metric
3. Giải thích scaling algorithm
4. Cách test HPA hoạt động đúng

Debugging Cluster-level Issues

Ngoài pod-level troubleshooting, Claude cũng giúp bạn debug các vấn đề ở cluster level.

Cluster gặp vấn đề: nhiều pods pending, không schedule được.

kubectl get nodes:
[Dán output - 5 nodes, some NotReady hoặc resource pressure]

kubectl describe node node-3:
[Dán output - chú ý Conditions, Allocatable, Allocated resources]

kubectl get pods --all-namespaces --field-selector=status.phase=Pending:
[Dán danh sách pods pending]

kubectl describe pod [pending-pod]:
[Dán output - chú ý Events section với FailedScheduling]

Cluster autoscaler logs:
[Dán relevant log lines]

Hãy phân tích:
1. Tại sao pods không schedule được?
2. Node nào có vấn đề và cần action gì?
3. Cluster autoscaler có hoạt động đúng không?
4. Recommendations để prevent tình huống này

Kubernetes Security Hardening

Bảo mật Kubernetes cluster đòi hỏi nhiều lớp bảo vệ. Claude có thể review cấu hình và đề xuất hardening measures.

Review security posture của Kubernetes cluster:

Cluster info:
- EKS 1.28, 3 node groups (system, app, spot)
- Ingress: NGINX Ingress Controller
- Service Mesh: không có
- CNI: VPC CNI

Hiện tại đã có:
- RBAC enabled
- Pod Security Standards: baseline
- Network Policies: chưa có
- Secrets: plain Kubernetes secrets
- Image scanning: chưa có

Hãy đề xuất security hardening roadmap theo priority:
1. Quick wins (làm ngay, ít effort)
2. Medium term (1-2 sprint)
3. Long term (quarterly planning)

Mỗi item cần:
- Mô tả risk nếu không làm
- Manifest hoặc config cụ thể
- Cách verify đã apply đúng

Prompt Templates tổng hợp

Migration workload lên Kubernetes

Tôi cần migrate ứng dụng từ VM sang Kubernetes:

Ứng dụng hiện tại:
- Runtime: [ngôn ngữ/framework]
- Chạy trên: [số VM, specs]
- Dependencies: [database, cache, queue, v.v.]
- Traffic pattern: [RPS, peak times]
- State: [stateless/stateful, session handling]
- Persistent data: [volumes, file uploads]
- Configuration: [env vars, config files, secrets]

Hãy lên kế hoạch migration bao gồm:
1. Containerization strategy (Dockerfile)
2. Kubernetes manifests cần thiết
3. Migration steps (zero-downtime)
4. Rollback plan
5. Monitoring và alerting setup
6. Các risk và mitigation

Cost optimization cho cluster

Phân tích và tối ưu chi phí Kubernetes cluster:

Cluster: EKS với [số node], instance type [type]
Namespaces: [liệt kê]

kubectl top nodes:
[Dán output]

kubectl top pods --all-namespaces:
[Dán output]

Hãy đề xuất:
1. Right-sizing node pools
2. Spot instances cho workload phù hợp
3. Pod resource optimization
4. Namespace resource quotas
5. Cluster autoscaler tuning
6. Ước tính tiết kiệm chi phí

Service Mesh và Observability

Khi hệ thống microservice trên Kubernetes phát triển, service mesh trở thành thành phần quan trọng để quản lý traffic giữa các services. Claude có thể giúp bạn đánh giá và triển khai service mesh phù hợp.

Tôi đang cân nhắc triển khai service mesh cho K8s cluster
với 25 microservices. Hãy so sánh:

1. Istio: feature-rich nhưng heavy
2. Linkerd: lightweight, dễ deploy
3. Cilium Service Mesh: eBPF-based, no sidecar

Cluster info:
- EKS 1.28, 15 nodes (m5.xlarge)
- 25 services, 80 pods total
- Traffic: 5000 RPS peak
- Team size: 3 DevOps engineers

Đánh giá theo:
- Resource overhead (CPU/memory per sidecar)
- Learning curve và operational complexity
- mTLS, traffic management, observability features
- Impact lên latency (P99)
- Recommend option nào cho team size này

Distributed Tracing Setup

Observability trong Kubernetes cluster bao gồm ba trụ cột: logs, metrics và traces. Claude có thể hướng dẫn bạn thiết lập distributed tracing một cách hiệu quả.

Thiết kế observability stack cho K8s cluster:

Requirements:
1. Centralized logging: thu thập logs từ tất cả pods
2. Metrics: Prometheus + Grafana (đã có)
3. Distributed tracing: chưa có, cần triển khai
4. Alerting: PagerDuty integration

Hãy đề xuất:
1. Logging stack: Fluentbit vs Promtail + Loki
2. Tracing: Jaeger vs Tempo, sampling strategy
3. OpenTelemetry Collector deployment (DaemonSet vs Sidecar)
4. Grafana dashboards cho K8s monitoring
5. Manifest cho toàn bộ observability stack
6. Storage sizing và retention policy

GitOps với ArgoCD

GitOps là phương pháp quản lý Kubernetes deployments sử dụng Git repository làm single source of truth. ArgoCD là công cụ GitOps phổ biến nhất cho Kubernetes. Claude có thể giúp bạn thiết lập và vận hành ArgoCD hiệu quả.

Thiết lập ArgoCD cho multi-environment deployment:

Environments: dev, staging, production
Repository structure: monorepo với Kustomize overlays

Yêu cầu:
1. ArgoCD Application manifest cho mỗi environment
2. ApplicationSet để auto-generate apps từ directory structure
3. Sync policies:
   - Dev: auto-sync enabled
   - Staging: auto-sync với manual promotion từ dev
   - Production: manual sync, require 2 approvals
4. RBAC: dev team chỉ sync dev/staging, platform team sync production
5. Notifications: Slack khi sync thành công hoặc thất bại
6. Health checks custom cho application-specific endpoints
7. Rollback strategy khi deployment fail

Sinh manifest và giải thích workflow.

Lưu ý khi sử dụng Claude với Kubernetes

• Luôn verify trên staging trước: Apply manifest Claude sinh ra trên staging environment trước khi production. Dù Claude sinh code chính xác phần lớn thời gian, mỗi cluster có đặc thù riêng
• Cung cấp version info: Kubernetes API thay đổi giữa các version. Cho Claude biết cluster version để nhận được manifest đúng apiVersion
• Không paste sensitive data: Khi debug, redact credentials, API keys và IP nội bộ trước khi paste vào Claude
• Kết hợp với kubectl: Claude phân tích output, bạn thực thi lệnh. Workflow hiệu quả nhất là chạy kubectl, paste output cho Claude, nhận phân tích, rồi thực hiện fix
• Dùng dry-run trước: Luôn chạy kubectl apply --dry-run=client trước khi apply thực tế để phát hiện lỗi syntax

Bước tiếp theo

Bạn đã nắm được cách sử dụng Claude để làm việc hiệu quả với Kubernetes — từ sinh manifest, debug pods đến tối ưu cluster và thiết lập bảo mật. Kubernetes là hệ sinh thái rộng lớn và Claude có thể hỗ trợ bạn trong hầu hết mọi tình huống. Khám phá thêm các hướng dẫn kỹ thuật nâng cao tại Thư viện Nâng cao Claude.