# Crossplane trong 40 ngày

## PHASE 0 - Tuần 0: Nền tảng bắt buộc trước khi học Crossplane (3 ngày)

### Ngày 0.1 - Kubernetes API machinery

*   CRD là gì thực sự: OpenAPI v3 schema, `apiVersion`/`kind`/`group`, cách `kube-apiserver` lưu trữ resource tuỳ biến trong etcd.
    
*   Cách hoạt động của Admission Webhooks (Validating/Mutating) - Crossplane dùng chúng để validate Composition, XRD.
    
*   `CustomResourceDefinition` versioning, conversion webhook - vì XRD của bạn sẽ có nhiều version theo thời gian.
    

**Thực hành**: viết một CRD tay (không dùng framework), apply vào kind, quan sát OpenAPI schema qua `kubectl explain`.

### Ngày 0.2 - Mẫu hình Controller (controller-runtime)

*   Reconciler interface: `Reconcile(ctx, req) (Result, error)` - vòng lặp *level-triggered*, không phải *edge-triggered*. Đây là khái niệm quan trọng nhất bạn cần nội tâm hoá.
    
*   Informer/Lister cache, work queue, rate limiting/backoff khi reconcile lỗi.
    
*   Owner References và Garbage Collection - vì XR "compose" ra MR bằng owner reference, không phải bằng một cơ chế bí ẩn nào khác.
    
*   Finalizers - vì sao xoá một Managed Resource đôi khi bị "stuck Terminating".
    

**Thực hành**: viết một controller tối giản bằng `controller-runtime` (Go) reconcile một ConfigMap giả lập - không liên quan Crossplane, chỉ để hiểu vòng lặp.

### Ngày 0.3 - OCI & Package registry cơ bản

*   Crossplane Package (`xpkg`) thực chất là gì: một OCI image chứa CRD + metadata, không phải Helm chart.
    
*   `docker manifest`, layer, digest, image signing (cosign) - vì bạn sẽ ký và verify Provider package ở tuần 5.
    

**Thực hành**: build một OCI image tối giản bằng `crane`/`docker buildx`, push lên registry cá nhân (ghcr.io), inspect layer.

## PHASE 1 - Tuần 1: Kiến trúc Crossplane & Package Manager

### Ngày 1 - Tổng quan kiến trúc của Crossplane

*   Crossplane core = 1 Deployment gồm: **Package Manager** (cài/gỡ Provider, Configuration, Function packages) + **Composition Engine** (reconcile XR → composed resources).
    
*   Provider = một Deployment riêng, mỗi Provider chạy controller riêng cho từng loại Managed Resource (MR) nó hỗ trợ.
    
*   Function = một Deployment/Pod chạy như gRPC server, được Composition Engine gọi qua `RunFunctionRequest`/`RunFunctionResponse` (giao thức **KRM Functions**).
    
*   Cài Crossplane v2.3 lên kind bằng Helm, dùng CLI mới: `crossplane xpkg`, `crossplane beta trace`, `crossplane render`.
    

**Bài tập:**

1.  Vẽ sơ đồ luồng dữ liệu: `kubectl apply XR` → Composition Engine → gọi Function pipeline → tạo MR → Provider controller → gọi cloud API.
    
2.  Cài `crossplane-cli` v2, chạy `crossplane version` để xác nhận CLI và control plane cùng version.
    
3.  Kiểm tra Pod của core Crossplane, đọc log để thấy chính xác controller nào đang chạy (`kubectl logs -n crossplane-system deploy/crossplane -f`).
    

### Ngày 2 - xpkg format & Package Manager internals

*   Cấu trúc 1 package: `package.yaml` (meta) + CRD YAMLs, đóng gói trong OCI image theo `xpkg` spec.
    
*   3 loại package: `Provider`, `Configuration` (bundle nhiều XRD+Composition), `Function`.
    
*   Dependency resolution: `Configuration` khai báo `dependsOn`, Package Manager tự cài Provider/Function phụ thuộc.
    
*   `ImageConfig` (từ v1.18, mở rộng ở v2.2): cấu hình registry auth, image rewrite, và - mới trong v2.2 - gán `DeploymentRuntimeConfig` theo prefix ảnh, áp dụng cả cho package cài gián tiếp qua dependency.
    
*   v2 bỏ default registry: mọi package reference **bắt buộc phải fully-qualified** (`xpkg.upbound.io/...` hoặc registry riêng).
    
*   Ký & verify package bằng cosign; `Provider` deletion protection (alpha v2.3) chặn xoá nhầm Provider khi còn MR đang tồn tại.
    

**Bài tập:**

1.  Cài `provider-aws-s3` bằng địa chỉ image fully-qualified, quan sát `ProviderRevision` được tạo ra.
    
2.  Tạo một `ImageConfig` để trỏ registry mirror nội bộ cho mọi package có prefix `xpkg.upbound.io/upbound`.
    
3.  Đọc source `package.yaml` của một Configuration public trên GitHub, xác định `dependsOn` của nó.
    

### Ngày 3 - Managed Resources & Provider architecture

*   Vòng đời MR: `Observe → Create/Update/Delete` - pattern `managed.ExternalClient` trong `crossplane-runtime`.
    
*   `ExternalName` annotation - cách Crossplane map 1 K8s object với 1 resource cloud thật.
    
*   Deletion policy (`Delete`/`Orphan`), Management policy (`ObserveOnly` để import tài nguyên có sẵn mà không quản lý full lifecycle).
    
*   Late initialization: Provider tự điền field còn thiếu từ giá trị cloud trả về sau khi Create.
    
*   `ProviderConfig` vs `DeploymentRuntimeConfig` - cái đầu là credential/config gọi cloud API, cái sau là cấu hình runtime cho chính Pod của Provider (resource limits, env vars, service account).
    

**Bài tập:**

1.  Tạo S3 bucket qua MR, sau đó set `managementPolicies: ["ObserveOnly"]` và quan sát Crossplane ngừng ghi đè.
    
2.  Tạo `DeploymentRuntimeConfig` giới hạn CPU/memory cho Provider AWS, gán qua `spec.runtimeConfigRef`.
    
3.  Với 1 MR đã tạo, dùng `crossplane beta trace` để xem chuỗi Observe/Ready/Synced hiện tại.
    

### Ngày 4 - Managed Resource Definitions (MRD)

*   Vấn đề MRD giải quyết: Provider lớn (AWS có hàng trăm loại MR) cài hết CRD gây phình etcd/apiserver.
    
*   MRD cho phép **activate có chọn lọc** - chỉ cài CRD của MR bạn thực sự dùng.
    

**Bài tập:**

1.  Cài `provider-aws` phiên bản hỗ trợ MRD, activate chỉ `Bucket` và `RDSInstance`, xác nhận CRD khác không tồn tại trong cluster.
    
2.  So sánh số lượng CRD/dung lượng etcd trước và sau khi dùng MRD.
    

### Ngày 5 - Ôn tập + Lab tích hợp tuần 1

*   Lab: cài Crossplane v2.3, cài Provider AWS + GCP với MRD chọn lọc, tạo 1 S3 bucket và 1 Cloud SQL bằng MR thuần (chưa dùng Composition).
    

## PHASE 2 - Tuần 2: Composition v2 bằng Functions

### Ngày 6 - XRD v2: namespaced XR

*   XRD v2 có `spec.scope: Namespaced | Cluster | LegacyCluster`. Mặc định XR giờ **namespaced** - không còn cần khái niệm `Claim (XRC)` để có namespace-scoping riêng như v1.
    
*   `[v1 legacy]` Ghi chú: v1 dùng `XR` (cluster-scoped) + `Claim/XRC` (namespaced) làm hai resource riêng. v2 hợp nhất lại: bản thân XR đã namespaced.
    
*   Thiết kế schema XRD tốt: OpenAPI validation, default values, `status` subresource cho output.
    

**Bài tập:**

1.  Viết một XRD `scope: Namespaced` cho resource `XDatabase` với field `engine`, `size`.
    
2.  So sánh với 1 XRD `scope: LegacyCluster` có `claimNames` - apply cả hai, quan sát khác biệt khi tạo instance.
    

### Ngày 7 - Composition Function pipeline & giao thức KRM Functions

*   Một Composition = `spec.mode: Pipeline` + danh sách `pipeline[].functionRef` - mỗi bước nhận `RunFunctionRequest` (observed/desired state) và trả `RunFunctionResponse`.
    
*   Function chính thức thay thế P&T: `function-patch-and-transform` (do Crossplane maintain) - hoạt động giống P&T cũ nhưng chạy như 1 function trong pipeline, không phải native engine.
    
*   Các function cộng đồng phổ biến: `function-go-templating`, `function-kcl`, `function-cue`, `function-auto-ready`.
    
*   `RequiredResources`/`RequiredSchemas` (mới v2.2) - function có thể yêu cầu Crossplane cung cấp thêm resource/schema trước khi chạy tiếp - nền tảng cho logic phức tạp (vd: đọc 1 Secret trước khi tạo MR).
    

**Bài tập:**

1.  Viết 1 Composition dùng `function-patch-and-transform` để tạo `RDSInstance` (MySQL) + `EKSCluster` từ 1 XR duy nhất.
    
2.  Chuyển đổi thử 1 Composition `mode: Resources` cũ (nếu có mẫu) sang Pipeline bằng lệnh `crossplane beta convert pipeline-composition old.yaml -o new.yaml`.
    

### Ngày 8 - Viết Composition Function bằng Go (function-sdk-go)

*   Kiến trúc 1 Function: gRPC server implement `RunFunction`, input/output là Unstructured KRM object.
    
*   Scaffold bằng `function-sdk-go`, build local, test bằng `crossplane render` (không cần deploy).
    

**Bài tập:**

1.  Viết Function Go: tự động gắn tag `managed-by: crossplane`, `env: <namespace>` vào mọi resource được compose.
    
2.  Viết Function Go tạo thêm 1 DNS record (giả lập) khi phát hiện resource `LoadBalancer` trong desired state.
    
3.  Viết unit test cho Function bằng cách mock `RunFunctionRequest`.
    

### Ngày 9 - Viết Composition Function bằng Python (function-sdk-python)

*   Tương tự Go nhưng dùng SDK Python, phù hợp khi team quen Python hơn (vd: cần gọi thư viện ML/data để tính toán trước khi tạo resource).
    

**Bài tập:**

1.  Viết lại Function "auto-tag" ở Ngày 8 bằng Python, so sánh cold-start latency giữa 2 bản Go/Python.
    
2.  Viết Function Python gửi Slack notification khi 1 bước pipeline fail (dùng `webhook`).
    

### Ngày 10 - Testing & debugging Function pipeline

*   `crossplane render xr.yaml composition.yaml functions.yaml` - engine render "high-fidelity" ở v2.3 chạy **chính reconciler thật** thay vì bản giả lập riêng, nên output khớp 100% với hành vi in-cluster.
    
*   `crossplane beta validate` - validate Composition/XRD trước khi apply (dùng trong CI).
    
*   **Pipeline Inspector** (alpha, v2.2): sidecar nhận bản sao mọi `RunFunctionRequest/Response` giữa các bước - dùng để debug logic phức tạp nhiều bước mà không cần sửa code function.
    

**Bài tập:**

1.  Chạy `crossplane render` cho Composition WordPress ở Ngày 7, so sánh output khi đổi input.
    
2.  Bật Pipeline Inspector cho 1 Composition nhiều bước, quan sát request/response giữa từng function.
    
3.  Viết 1 CI job (GitHub Actions) chạy `crossplane beta validate` + `crossplane render` + so sánh snapshot (golden file testing).
    

## PHASE 3 - Tuần 3: Namespaced XR, Connection Details, Secrets, Runtime Config

### Ngày 11 - Compose bất kỳ Kubernetes resource nào

*   Điểm khác biệt lớn của v2: XR có thể compose **Deployment, Service, hoặc CRD của bên thứ ba** (vd: CloudNativePG Cluster) - không bắt buộc phải là Managed Resource.
    
*   Cần cấp quyền RBAC rõ ràng cho Crossplane compose resource ngoài Crossplane API.
    

**Bài tập:**

1.  Viết Composition tạo XR `App` compose ra: 1 `Deployment`, 1 `Service`, 1 `RDSInstance` - trong cùng namespace với XR.
    
2.  Cấp Role/RoleBinding tối thiểu để Crossplane compose được `apps/v1 Deployment`.
    

### Ngày 12 - Migration path: XRC (Claim) → namespaced XR

*   v1: người dùng cuối tạo `Claim` (namespaced) → Crossplane tạo `XR` (cluster-scoped) tương ứng.
    
*   v2: người dùng cuối tạo thẳng `XR` (đã namespaced) - bỏ tầng trung gian Claim.
    
*   **Chưa có tool tự động migrate** resource v1 cluster-scoped sang v2 namespaced (tính đến v2.3) - phải làm thủ công hoặc chờ tooling từ cộng đồng.
    
*   Best practice khi bắt đầu dự án mới: dùng namespaced XR ngay từ đầu, không cần thiết kế theo mô hình Claim cũ nữa.
    

**Bài tập:**

1.  So sánh 1 project mẫu viết theo style Claim (v1) và style namespaced XR (v2) cho cùng 1 use case WordPress.
    
2.  Đọc kỹ output của `crossplane beta upgrade check` trên 1 cluster v1 giả lập, liệt kê các resource cần sửa trước khi lên v2.
    

### Ngày 13 - Connection Details

*   v2 **xoá native connection-details support ở cấp XR** (chỉ MR vẫn giữ `writeConnectionSecretToRef`).
    
*   Cách tái tạo tính năng: dùng `function-patch-and-transform` - nó tự động compose 1 `Secret` gộp connection details của các resource con, đặt tên/namespace theo `spec.writeConnectionSecretToRef` trên XR.
    

**Bài tập:**

1.  Viết Composition có 2 MR đều publish connection detail (endpoint DB + password), gộp thành 1 Secret ở namespace của XR.
    
2.  Viết 1 Deployment (compose cùng XR) đọc Secret đó qua `envFrom.secretRef`.
    

### Ngày 14 - Quản lý secret thực tế: External Secrets Operator + Vault

*   Vì external secret store **bị xoá khỏi Crossplane native** ở v2, cách chuẩn production hiện nay: dùng **External Secrets Operator (ESO)** đọc từ Vault/AWS Secrets Manager, đồng bộ vào K8s Secret mà Crossplane compose tham chiếu tới - Crossplane không tự nói chuyện với Vault nữa.
    

**Bài tập:**

1.  Cài ESO, tạo `SecretStore` trỏ tới Vault, đồng bộ 1 secret DB password vào cluster.
    
2.  Compose XR tham chiếu Secret do ESO tạo (không phải Crossplane tạo).
    

### Ngày 15 - DeploymentRuntimeConfig chi tiết

*   Thay thế hoàn toàn `ControllerConfig` (deprecated từ v1.11, xoá ở v2).
    
*   Cấu hình: replica count, resource requests/limits, `serviceAccountName`, extra env var, args cho Provider pod (vd `--max-reconcile-rate`).
    
*   `ImageConfig` (Ngày 2) có thể gán `DeploymentRuntimeConfig` tự động theo prefix image - hữu ích khi Configuration cài Provider gián tiếp qua dependency mà bạn không apply trực tiếp.
    

**Bài tập:**

1.  Convert 1 `ControllerConfig` mẫu (nếu có từ hệ thống cũ) sang `DeploymentRuntimeConfig` bằng `crossplane beta convert deployment-runtime`.
    
2.  Set `--max-reconcile-rate=50` cho Provider AWS qua DeploymentRuntimeConfig, quan sát tốc độ reconcile tăng lên.
    

## PHASE 4 - Tuần 4: Viết Provider từ đầu bằng Go + crossplane-runtime

### Ngày 16 - Kiến trúc 1 Provider

*   `managed.ExternalConnecter.Connect()` → trả về `managed.ExternalClient` với 4 method: `Observe`, `Create`, `Update`, `Delete`.
    
*   Đọc source code thật của `provider-aws-s3` hoặc `provider-template` để thấy pattern thực tế (không lý thuyết suông).
    
*   Reconciler wrapper của `crossplane-runtime` tự lo: retry/backoff, status condition (`Ready`, `Synced`), event recording - bạn chỉ cần implement 4 method trên.
    

**Bài tập:**

1.  Clone `crossplane/provider-template`, đọc kỹ `internal/controller/.../reconciler.go`, vẽ lại sequence diagram Observe→Create.
    
2.  Xác định chỗ nào trong code xử lý `ExternalName`, chỗ nào xử lý late-init.
    

### Ngày 17 - Scaffold Provider bằng code generation

*   `provider-template` + `angryjet` (code-gen tool tạo `DeepCopy`, `ResourceSpec/Status` boilerplate từ struct Go).
    
*   Thiết kế API type cho resource tuỳ chỉnh "CoffeeShop" (`name`, `location`, `menu`) theo convention `ForProvider`/`AtProvider`.
    

**Bài tập:**

1.  Scaffold provider "provider-coffeeshop" từ template, generate CRD YAML từ Go struct.
    
2.  Viết `ProviderConfig` type cho provider này (credential tới 1 REST API giả lập).
    

### Ngày 18 - Implement CRUD cho external API

*   Viết `Observe`: gọi API, so sánh spec vs trạng thái thật, set `ResourceUpToDate`/`ResourceExists`.
    
*   Viết `Create`/`Update`/`Delete`, xử lý lỗi 404/409 đúng convention (không panic, trả `errors.Wrap`).
    
*   Xử lý idempotency: `Create` gọi 2 lần không được tạo trùng.
    

**Bài tập:**

1.  Dựng 1 REST API giả (Express/FastAPI) làm "cloud" cho CoffeeShop, implement đủ 4 method.
    
2.  Test toàn bộ vòng đời: apply → update field `menu` → xoá, xác nhận API backend phản ánh đúng.
    

### Ngày 19 - Testing Provider

*   Unit test: mock HTTP client, test riêng từng method `Observe/Create/Update/Delete` không cần cluster thật.
    
*   Integration test: chạy `envtest` (etcd + apiserver giả lập) + provider binary + backend giả lập, apply MR thật, assert trạng thái.
    
*   Test `crossplane render` cho Composition dùng resource "CoffeeShop" này.
    

**Bài tập:**

1.  Viết unit test coverage ≥ 80% cho `internal/controller`.
    
2.  Viết 1 integration test bằng `envtest` mô phỏng full lifecycle.
    

### Ngày 20 - Đóng gói & publish Provider

*   Build multi-arch OCI image, đóng gói theo `xpkg` spec (`crossplane xpkg build`), ký bằng cosign.
    
*   Semantic versioning cho Provider - vì `ProviderRevision` giữ lịch sử, breaking change API phải bump major.
    
*   Publish lên `ghcr.io`, viết `Provider` manifest fully-qualified để người khác cài.
    

**Bài tập:**

1.  Build và push `provider-coffeeshop:v0.1.0` lên ghcr.io cá nhân, cài vào cluster test bằng `Provider` manifest.
    
2.  Ký image bằng cosign, verify chữ ký trước khi cài (`crossplane xpkg verify` hoặc `cosign verify`).
    

## PHASE 5 - Tuần 5: CI/CD, GitOps, Multi-tenancy đúng cách, Policy

### Ngày 21 - GitOps với Argo CD/Flux

*   Pattern chuẩn: Git repo chứa XR/Composition/XRD YAML → Argo CD/Flux sync vào cluster → Crossplane reconcile.
    
*   App-of-apps pattern: tách repo "platform" (Composition/XRD, do platform team quản lý) khỏi repo "workload" (XR instance, do dev team quản lý).
    
*   Xử lý drift: Argo CD self-heal vs Crossplane tự sửa lại resource - tránh 2 controller "đánh nhau".
    

**Bài tập:**

1.  Setup Argo CD trỏ vào 1 Git repo chứa Composition WordPress, sync tự động.
    
2.  Tạo repo thứ hai chỉ chứa XR instance, để dev team tự tạo PR mà không cần quyền vào repo platform.
    

### Ngày 22 - CI pipeline cho Function & Provider

*   Pipeline chuẩn: `go test`/`pytest` → `crossplane beta validate` → `crossplane render` (golden-file diff) → build OCI → cosign sign → push → (optional) deploy staging.
    
*   Dùng `crossplane-diff` (dựa trên render engine mới ở v2.3) để preview thay đổi Composition trước khi merge - giống `terraform plan`.
    

**Bài tập:**

1.  Viết GitHub Actions pipeline đầy đủ các bước trên cho `provider-coffeeshop`.
    
2.  Thêm bước `crossplane-diff` vào PR check để reviewer thấy trước resource nào sẽ thay đổi.
    

### Ngày 23 - Multi-tenancy

1.  **Namespace isolation** (nhẹ nhất): mỗi team 1 namespace, XR namespaced (v2) tự nhiên cô lập theo namespace, RBAC giới hạn theo namespace.
    
2.  **Composition-level self-service**: platform team sở hữu Composition/XRD (cluster-scoped resource, cần quyền cao), dev team chỉ có quyền tạo XR trong namespace của họ - không được sửa Composition.
    
3.  **Control-plane-per-tenant** (cô lập mạnh nhất): mỗi tenant/BU có 1 Crossplane control plane riêng (self-hosted cluster riêng, hoặc dùng Upbound Spaces nếu dùng bản thương mại) - tránh "noisy neighbor" ở tầng controller.
    

**Bài tập:**

1.  Thiết kế RBAC: Role cho phép team A tạo/sửa XR `XDatabase` trong namespace `team-a`, nhưng không được sửa `Composition`/`XRD`.
    
2.  So sánh chi phí vận hành giữa pattern 1 và pattern 3 cho tổ chức 5 team.
    

### Ngày 24 - RBAC, ResourceQuota, NetworkPolicy cho control plane

*   RBAC 2 lớp: (a) ai được tạo XR/Claim, (b) `ProviderConfig` nào Crossplane dùng để nói chuyện với cloud - tách quyền dev khỏi credential cloud thật.
    
*   `ResourceQuota` theo namespace giới hạn số XR một team được tạo.
    
*   `NetworkPolicy` giới hạn Provider pod chỉ gọi ra ngoài internet tới cloud API cần thiết, chặn lateral movement.
    

**Bài tập:**

1.  Viết ClusterRole/Role tách biệt: `platform-admin` (sửa Composition/XRD) vs `app-developer` (chỉ tạo XR).
    
2.  Viết ResourceQuota giới hạn 10 XR `XDatabase` mỗi namespace.
    
3.  Viết NetworkPolicy chỉ cho phép Provider pod egress tới CIDR của AWS API endpoint.
    

### Ngày 25 - Policy enforcement thực tế bằng Kyverno/OPA Gatekeeper

*   Vì Crossplane **không có Policy Engine built-in**, policy validate ở tầng admission dùng Kyverno hoặc Gatekeeper - áp lên chính XR hoặc lên Composition.
    
*   Ví dụ policy thật: chặn XR tạo RDS instance class lớn hơn `db.t3.medium` ở namespace `dev`; bắt buộc mọi XR có label `cost-center`.
    

**Bài tập:**

1.  Viết 1 Kyverno ClusterPolicy validate field `spec.size` của XR `XDatabase` không vượt giới hạn theo namespace.
    
2.  Viết 1 policy bắt buộc mọi `Composition` mới phải có `mode: Pipeline` (chặn ai đó cố dùng lại `mode: Resources` đã deprecated).
    

## PHASE 6 - Tuần 6: Observability, Performance, Security, Nâng cấp

### Ngày 26 - Metrics của Crossplane

*   Tên metric: `engine_controllers_*`, `engine_watches_*`, `crossplane_composition_run_function_*`
    
*   Dashboard Grafana: reconcile rate, reconcile error rate theo Provider, function pipeline latency theo step.
    

**Bài tập:**

1.  Cài Prometheus ServiceMonitor scrape Crossplane core + Provider pods.
    
2.  Xây 1 Grafana dashboard: top 5 MR reconcile chậm nhất, error rate theo Provider trong 1h qua.
    

### Ngày 27 - Debug production incident

*   `crossplane beta trace <kind>/<name>` - công cụ số 1 khi debug: hiển thị cây XR → composed resources → trạng thái Synced/Ready của từng cái.
    
*   Pipeline Inspector (Ngày 10) khi lỗi nằm trong logic Function, không phải trong Provider.
    
*   Log pattern thường gặp: "cannot resolve resource references", "composed resource is not yet ready", credential lỗi ProviderConfig.
    

**Bài tập:**

1.  Cố tình tạo 1 lỗi (typo field, credential sai), dùng `crossplane beta trace` để định vị nguyên nhân trong < 2 phút.
    
2.  Viết runbook nội bộ: "5 bước debug khi XR stuck ở Ready=False".
    

### Ngày 28 - Performance & scaling

*   `--max-reconcile-rate` per-provider, số lượng worker/goroutine per controller.
    
*   Sizing control plane: bao nhiêu XR/MR thì cần tách Provider ra node riêng, cần scale etcd.
    
*   Cost của Function pipeline: mỗi bước là 1 gRPC call - pipeline quá nhiều bước làm chậm reconcile toàn hệ thống.
    

**Bài tập:**

1.  Load test: tạo 500 XR cùng lúc, đo reconcile rate trước/sau khi tăng `--max-reconcile-rate`.
    
2.  Đo latency pipeline có 5 function step vs 2 function step, rút gọn nếu có thể.
    

### Ngày 29 - Bảo mật

*   Supply chain: bắt buộc fully-qualified image + cosign verify trước khi Package Manager cài (dùng `ImageConfig` để enforce).
    
*   Provider deletion protection (alpha v2.3): bật để tránh xoá nhầm Provider còn resource sống.
    
*   Least-privilege IAM: mỗi `ProviderConfig` nên map với 1 IAM Role/Service Account hẹp nhất có thể (không dùng 1 credential admin cho toàn bộ Provider).
    
*   Secret hygiene: connection-detail Secret nên có TTL/rotation qua ESO, không để credential tĩnh vĩnh viễn.
    

**Bài tập:**

1.  Bật `--enable-provider-deletion-protection`, thử xoá 1 Provider đang có MR sống, xác nhận bị chặn.
    
2.  Thiết kế IAM Role hẹp cho Provider AWS chỉ được thao tác S3 + RDS, không có quyền IAM/EC2.
    

### Ngày 30 - Nâng cấp & migration production

*   `crossplane beta upgrade check` (CLI v1.20) quét toàn bộ control plane, báo chính xác resource nào cần sửa trước khi lên v2.
    
*   Nguyên tắc nâng cấp: **luôn đi tuần tự từng minor version**, dùng patch mới nhất mỗi bước (vd v1.18 → v1.19 → v1.20 → v2.0 → v2.1 → v2.2 → v2.3).
    
*   Backup/restore trạng thái XR/MR bằng Velero trước khi nâng cấp lớn - vì reconcile sai sau upgrade có thể xoá nhầm tài nguyên cloud thật.
    

**Bài tập:**

1.  Chạy `crossplane beta upgrade check` trên 1 cluster v1.20 giả lập có dùng P&T cũ, đọc báo cáo và sửa từng issue.
    
2.  Viết runbook nâng cấp production: pre-check → backup Velero → upgrade minor-by-minor → post-check bằng `crossplane beta trace` trên toàn bộ XR.
    

## PHASE 7 - Tuần 7–8: Capstone Projects

### Capstone 1 (Ngày 31–35): Multicloud Kubernetes Platform

**Bài toán**: doanh nghiệp cần self-service tạo cluster K8s trên AWS (EKS), GCP (GKE), Azure (AKS) qua 1 API thống nhất.

**Yêu cầu kỹ thuật:**

1.  XRD namespaced `XCluster` với schema chung (node count, instance type, region, cloud provider).
    
2.  Composition dùng Function pipeline (Go hoặc `function-go-templating`) chọn nhánh tạo EKS/GKE/AKS theo field `provider`.
    
3.  `DeploymentRuntimeConfig` + `ImageConfig` cấu hình runtime cho 3 Provider.
    
4.  GitOps: repo platform (Composition/XRD) tách khỏi repo workload (XR instance), sync qua Argo CD.
    
5.  Policy Kyverno chặn node count > ngưỡng theo namespace/môi trường.
    
6.  Dashboard Grafana theo dõi trạng thái tất cả cluster đang quản lý.
    
7.  Runbook: nâng cấp version K8s của toàn bộ cluster qua CompositionRevision, canary theo namespace trước khi rollout toàn bộ.
    

### Capstone 2 (Ngày 36–40): Internal Developer Platform (IDP) hoàn chỉnh

**Bài toán**: xây self-service platform cho app team tự triển khai infra (DB, queue, cache, LB) cho ứng dụng của họ, nhiều môi trường (dev/staging/prod), nhiều cloud.

**Yêu cầu kỹ thuật:**

1.  Bộ Composition cho từng thành phần (DB, MQ, cache, LB), dùng `EnvironmentConfig` để khác biệt hoá theo dev/staging/prod (kích thước, class, region).
    
2.  Self-service qua namespaced XR: app team chỉ có RBAC tạo XR trong namespace của họ, không đụng vào Composition/XRD.
    
3.  Secret quản lý qua ESO + Vault, connection detail compose qua `function-patch-and-transform`.
    
4.  CI pipeline đầy đủ cho Composition (test, render, diff, publish) theo chuẩn Ngày 22.
    
5.  Observability: metrics + trace + alert khi XR ở trạng thái `Ready=False` quá 10 phút.
    
6.  Disaster recovery: backup Velero định kỳ, tài liệu runbook khôi phục control plane từ backup.
    
7.  Viết tài liệu onboarding cho app team mới: cách tạo XR đầu tiên, cách đọc trạng thái, cách debug lỗi cơ bản bằng `crossplane beta trace`.
    

## Tài nguyên tham khảo

*   Docs chính thức: docs.crossplane.io/latest (luôn xem đúng version bạn đang chạy, có version switcher)
    
*   What's New in v2: docs.crossplane.io/latest/whats-new
    
*   Hướng dẫn nâng cấp v1→v2: docs.crossplane.io/latest/guides/upgrade-to-crossplane-v2
    
*   Blog chính thức (release notes chi tiết từng bản): blog.crossplane.io
    
*   Source code tham khảo: `crossplane/crossplane`, `crossplane/function-sdk-go`, `crossplane/function-sdk-python`, `crossplane/provider-template`
    

## Lưu ý khi học

*   Luôn build lab trên đúng version mục tiêu (v2.3+) - đừng học theo blog/tutorial cũ ghi `mode: Resources` hay `ControllerConfig` mà không kiểm tra ngày viết.
    
*   Ưu tiên đọc source code thật (Provider, Function SDK) hơn là chỉ đọc doc - phần lớn "hiểu sâu internals" nằm ở đây.
    
*   Mỗi tuần nên có ít nhất 1 buổi "phá" có chủ đích: cố tình gây lỗi (credential sai, RBAC thiếu, quota vượt) để luyện phản xạ debug - đây là kỹ năng khác biệt nhất giữa người "biết dùng" và người "vận hành được production".