1. Cloud Native — Định nghĩa CNCF
Theo CNCF (Cloud Native Computing Foundation), cloud native là cách build và run scalable applications trong dynamic environments như public, private, hybrid cloud, sử dụng: containers, microservices, declarative APIs, immutable infrastructure.
| Principle | Ý nghĩa | Ví dụ |
|---|---|---|
| Containerized | Đóng gói app + dependencies | Docker image |
| Dynamically orchestrated | Automated scheduling, scaling, healing | Kubernetes |
| Microservices | Loose coupling, single responsibility | Auth service, Payment service |
| Declarative APIs | Describe desired state, not steps | kubectl apply -f deployment.yaml |
| Immutable infrastructure | Never modify running; replace instead | New image version → rolling update |
2. Microservices vs Monolith
MONOLITH MICROSERVICES
───────────────────── ──────────────────────────────
┌──────────────────┐ ┌────────┐ ┌────────┐ ┌─────┐
│ Auth │ UI │ │ Auth │ │ Cart │ │ UI │
│ Cart │ API │ │Service │ │Service │ │Svc │
│ Payment │ DB │ └────────┘ └────────┘ └─────┘
└──────────────────┘ │ │ │
Deploy as 1 unit └─── API Gateway ───┘
│
Client/Browser| Aspect | Monolith | Microservices |
|---|---|---|
| Deployment | All-or-nothing | Independent per service |
| Scaling | Scale entire app | Scale only bottleneck service |
| Complexity | Low (single codebase) | High (distributed) |
| Fault isolation | One bug crashes all | Failure contained in service |
| Technology | Single stack | Polyglot (best tool per service) |
3. 12-Factor App
The 12-factor app methodology định nghĩa best practices cho cloud native applications:
| # | Factor | Cloud Native Practice |
|---|---|---|
| 1 | Codebase | 1 repo per app, many deploys |
| 2 | Dependencies | Declare explicitly (package.json, go.mod) |
| 3 | Config | Store in environment (ConfigMap, Secrets) |
| 4 | Backing services | DB, cache = attached resources via URL |
| 5 | Build/Release/Run | Strict separation (CI builds, CD deploys) |
| 6 | Processes | Stateless processes, store state externally |
| 7 | Port binding | Export service via port (no web server layer) |
| 8 | Concurrency | Scale via process model (HPA) |
| 9 | Disposability | Fast startup, graceful shutdown |
| 10 | Dev/Prod parity | Same tools/services across environments |
| 11 | Logs | Treat as event streams (stdout, not files) |
| 12 | Admin processes | Run one-off admin tasks as Jobs |
Exam tip: Factors 3, 6, 9, 11 hay xuất hiện trong câu hỏi KCNA. Factor 3 (config in env) → ConfigMap/Secret. Factor 6 (stateless) → lý do dùng external storage. Factor 11 (logs as streams) → stdout → log aggregator.
4. Service Mesh
Khi microservices nhiều lên, cần quản lý: mTLS, retry, circuit breaker, observability. Service Mesh giải quyết điều này bằng cách inject sidecar proxy vào mỗi Pod.
Without Service Mesh: With Service Mesh (Istio):
App A ──────────────► App B App A ──► [Envoy] ──► [Envoy] ──► App B
(manual TLS, retry code) sidecar sidecar
(auto mTLS, metrics, retry, tracing)| Tính năng | Service Mesh cung cấp |
|---|---|
| mTLS mutual authentication | Auto-encrypt traffic giữa services |
| Traffic management | Canary, A/B, weighted routing |
| Observability | Auto metrics, tracing, access logs |
| Resilience | Retry, timeout, circuit breaker |
5. Cheat Sheet
| Câu hỏi exam | Đáp án |
|---|---|
| CNCF định nghĩa cloud native bao gồm? | Containers, microservices, declarative APIs, immutable infra |
| Config nên lưu ở đâu theo 12-factor? | Environment variables (không hardcode) |
| Logs theo 12-factor? | Treat as streams (stdout/stderr) |
| Service mesh inject gì vào Pod? | Sidecar proxy (Envoy) |
| Microservices scale phần nào? | Chỉ service có bottleneck |
6. Practice Questions
Q1: According to the 12-factor app methodology, how should an application store its database connection string?
- A) Hardcoded in the source code
- B) In a configuration file committed to the repository
- C) As an environment variable (Kubernetes ConfigMap or Secret) ✓
- D) In the container image as a build argument
Explanation: Factor 3 (Config) states: "Store config in the environment." In Kubernetes, this means using ConfigMaps for non-sensitive config and Secrets for sensitive values, injected as environment variables.
Q2: What is the primary benefit of using a Service Mesh in a microservices architecture?
- A) Replace Kubernetes for container orchestration
- B) Provide infrastructure-level networking features (mTLS, retry, observability) without changing application code ✓
- C) Store application configuration
- D) Persist application state across container restarts
Explanation: Service mesh moves cross-cutting concerns (security, observability, resilience) to the infrastructure layer via sidecar proxies. Developers don't need to implement retry logic or mTLS in each service.
Q3: Which characteristic distinguishes "immutable infrastructure" from traditional infrastructure?
- A) Servers are never rebooted
- B) Running systems are replaced rather than modified in-place ✓
- C) Configuration changes require manual approval
- D) Infrastructure is defined using only YAML files
Explanation: Immutable infrastructure means you never update/patch a running container — you build a new image, deploy it, replace old containers. This eliminates configuration drift and improves repeatability.