在 Kubernetes 環境中佈署應用程式時，基礎設施的準備往往耗時費力。利用 Crossplane Compositions，我們可以將複雜的基礎設施定義轉換為簡潔的 YAML 檔案，實作基礎設施即程式碼，並透過 GitOps 進行版本控制和自動化佈署。這不僅提升了效率，也減少了人為錯誤的風險。
Crossplane Compositions 的核心概念是將基礎設施抽象成可重複使用的模組。透過定義 ClusterClaim、SQLClaim 和 AppClaim 等資源，我們可以宣告所需的 Kubernetes 叢集、資料函式庫和應用程式，並讓 Crossplane 負責協調這些資源的建立和組態。這讓我們可以專注於應用程式開發，而不必糾結於底層基礎設施的細節。舉例來說，一個簡單的 YAML 檔案即可描述一個包含 Kubernetes 叢集、PostgreSQL 資料函式庫和後端應用程式的完整環境。透過引數化的設定，我們可以輕鬆調整叢集規模、資料函式庫版本等設定，而無需修改大量的組態檔案。此外，將這些 YAML 檔案儲存在 Git 儲存函式庫中，可以利用 GitOps 工具，例如 Argo CD，實作自動化的資源組態和版本控制。當 YAML 檔案發生變更時，Argo CD 會自動將變更應用到 Kubernetes 叢集，確保基礎設施與程式碼保持同步。
使用 Crossplane Compositions 快速開發生產級 Kubernetes 環境
在雲原生應用開發中，快速與一致地佈署基礎設施至關重要。傳統方式需要大量手動組態，耗時與容易出錯。身為一個在雲端基礎建設打滾多年的老手，我發現 Crossplane Compositions 提供了一個優雅的解決方案，能讓我們用更簡潔的方式定義和佈署複雜的雲端資源。
告別繁瑣：使用 YAML 宣告所需資源
Crossplane Compositions 的核心概念是使用 YAML 檔案來宣告我們需要的雲端資源。這些 YAML 檔案描述了叢集、資料函式庫、應用程式等資源的所需狀態。Crossplane 會自動協調這些資源的建立和組態，讓我們從繁瑣的手動操作中解放出來。
以下是一個範例，展示如何使用 Crossplane Compositions 佈署一個 Kubernetes 叢集、PostgreSQL 資料函式庫和一個後端應用程式：
# 建立 Kubernetes 叢集
apiVersion: devopstoolkitseries.com/v1alpha1
kind: ClusterClaim
metadata:
name: cluster-01
spec:
id: cluster-01
compositionSelector:
matchLabels:
provider: aws-official
cluster: eks
parameters:
nodeSize: small
minNodeCount: 3
---
# 儲存資料函式庫密碼
apiVersion: v1
kind: Secret
metadata:
name: silly-demo-db-password
data:
password: cG9zdGdyZXM=
---
# 建立 PostgreSQL 資料函式庫
apiVersion: devopstoolkitseries.com/v1alpha1
kind: SQLClaim
metadata:
name: silly-demo-db
spec:
id: silly-demo-db
compositionSelector:
matchLabels:
provider: aws-official
db: postgresql
parameters:
version: "13"
size: small
---
# 佈署後端應用程式
apiVersion: devopstoolkitseries.com/v1alpha1
kind: AppClaim
metadata:
name: silly-demo
spec:
id: silly-demo
compositionSelector:
matchLabels:
type: backend-db
location: remote
parameters:
namespace: production
image: c8n.io/vfarcic/silly-demo:1.4.52
port: 8080
host: silly-demo.acme.com
dbSecret:
name: silly-demo-db
namespace: a-team
kubernetesProviderConfigName: cluster-01
內容解密
- ClusterClaim: 此段 YAML 定義了一個 Kubernetes 叢集，指定了叢集供應商 (AWS)、叢集型別 (EKS)、節點大小 (small) 和最小節點數量 (3)。Crossplane 會根據這些引數自動建立和組態叢集。
- Secret: 此段 YAML 建立一個 Kubernetes Secret，用於儲存資料函式庫密碼。在實際生產環境中，建議使用更安全的密碼管理方案，例如 HashiCorp Vault。
- SQLClaim: 此段 YAML 定義了一個 PostgreSQL 資料函式庫，指定了資料函式庫供應商 (AWS)、資料函式庫型別 (PostgreSQL)、版本 (13) 和大小 (small)。Crossplane 會自動建立資料函式庫伺服器，並在其中建立新的使用者和資料函式庫。
- AppClaim: 此段 YAML 定義了一個後端應用程式，指定了應用程式的佈署位置 (remote)、名稱空間 (production)、映象 (c8n.io/vfarcic/silly-demo:1.4.52)、連線埠 (8080)、主機 (silly-demo.acme.com) 和資料函式庫密碼 Secret。Crossplane 會自動將應用程式佈署到指定的叢集，並將其連線到資料函式庫。
一鍵佈署：透過 GitOps 自動化資源組態
上述 YAML 檔案定義了我們所需的雲端資源。接下來，我們可以將這些檔案提交到 Git 儲存函式庫，並使用 GitOps 工具（例如 Argo CD）來自動化資源組態。
以下是一些範例指令，展示如何將 YAML 檔案提交到 Git 儲存函式庫：
cp examples/$HYPERSCALER-intro.yaml a-team/intro.yaml
git add .
git commit -m "Intro"
git push
Argo CD 會監控 Git 儲存函式庫中的變更，並自動將變更應用到 Kubernetes 叢集。這意味著，當我們更新 YAML 檔案時，Argo CD 會自動更新雲端資源，確保它們與 Git 儲存函式庫中的定義保持一致。
深入觀察：Crossplane 如何協調資源
當 Argo CD 將 YAML 檔案應用到 Kubernetes 叢集時，Crossplane 會開始協調資源的建立和組態。Crossplane 會根據 YAML 檔案中的定義，自動建立 Kubernetes 叢集、PostgreSQL 資料函式庫和後端應用程式。
我們可以透過 kubectl 指令來觀察 Crossplane 的協調過程：
kubectl --namespace a-team get clusterclaims,sqlclaims,appclaims
此指令會顯示 ClusterClaim、SQLClaim 和 AppClaim 等資源的狀態。一開始，這些資源的 READY 欄位可能為 False，表示資源尚未完全建立和組態。隨著 Crossplane 的協調，這些資源的 READY 欄位最終會變為 True，表示資源已準備就緒。
玄貓觀點：擁抱雲原生，加速創新
Crossplane Compositions 提供了一個強大的工具，能讓我們以更簡潔、更一致的方式定義和佈署雲端資源。透過將基礎設施即程式碼 (Infrastructure as Code) 和 GitOps 相結合，我們可以實作雲端資源的自動化組態，加速應用程式的開發和佈署。
從玄貓的角度來看，Crossplane Compositions 代表了雲原生技術的發展方向。它讓我們能夠更專注於應用程式的開發，而無需花費大量時間和精力在基礎設施的組態上。這將有助於我們加速創新，並在競爭激烈的市場中保持領先地位。
## Crossplane 資源追蹤：深入解析叢集、資料函式庫與應用程式佈署狀態
在雲原生環境中，Crossplane 提供了一種獨特的方式來管理基礎架構即程式碼。透過 kubectl，我們可以觀察 Crossplane 管理的眾多資源。
kubectl get managed
執行上述指令後，會看到類別似以下的輸出（為了簡潔起見，已截斷）：
NAME READY SYNCED EXTERNAL-NAME AGE
internetgateway.../cluster-01 False True 18s
internetgateway.../silly-demo-db False True 18s
NAME READY SYNCED EXTERNAL-NAME AGE
mainroutetableassociation.../cluster-01 False True 18s
mainroutetableassociation.../silly-demo-db False True 18s
NAME READY SYNCED EXTERNAL-NAME AGE
route.../cluster-01 False 18s
route.../silly-demo-db False 18s
NAME READY SYNCED EXTERNAL-NAME AGE
routetableassociation.../cluster-01-1a False 18s
routetableassociation.../cluster-01-1b False 18s
routetableassociation.../cluster-01-1c False 18s
routetableassociation.../silly-demo-db-1a False 18s
routetableassociation.../silly-demo-db-1b False 18s
routetableassociation.../silly-demo-db-1c False 18s
NAME READY SYNCED EXTERNAL-NAME AGE
routetable.../cluster-01 False True 18s
routetable.../silly-demo-db False True 18s
...
這個輸出展示了由 Crossplane 管理的 AWS 資源，像是 Internet Gateways、路由表關聯、主要路由表關聯、路由、安全組規則、安全組、子網路、VPC，以及像是叢集認證、叢集、節點組、角色策略附加、角色、RDS 例項和子網路群組等資源。如果是使用 Google Cloud 或 Azure，看到的資源型別會有所不同。
儘管 YAML 檔案可能只有短短幾十行，但它們實際上定義並管理了大量的雲端資源。
使用 Crossplane CLI 追蹤資源狀態
Crossplane CLI 提供了一個更方便的方式來探索由 Crossplane 管理的資源。trace 指令（目前為 Beta 版本）可以視覺化資源之間的依賴關係和狀態。
crossplane beta trace clusterclaim cluster-01 --namespace a-team
內容解密：
crossplane beta trace：使用 Crossplane CLI 的追蹤功能（Beta 版）。clusterclaim cluster-01：指定要追蹤的 ClusterClaim 資源，名稱為 cluster-01。--namespace a-team：指定資源所在的名稱空間。
執行後，會看到類別似以下的樹狀結構輸出：
NAME SYNCED READY STATUS
ClusterClaim/cluster-01 (a-team) True False Waiting: ...
└─ CompositeCluster/cluster-01-lkm96 True False Creating...
├─ InternetGateway/cluster-01 True True Available
├─ MainRouteTableAssociation/cluster-01 True True Available
├─ RouteTableAssociation/cluster-01-1a True False Creating
├─ RouteTableAssociation/cluster-01-1b False - ReconcileError...
├─ RouteTableAssociation/cluster-01-1c True False Creating
├─ RouteTable/cluster-01 True True Available
├─ Route/cluster-01 False - ReconcileError...
...
這個輸出顯示了由 ClusterClaim 資源管理的所有資源的樹狀結構。可以看到 ClusterClaim 建立了 CompositeCluster 複合資源，而 CompositeCluster 又建立了一系列的受管資源。
玄貓提醒： 資源的 SYNCED 和 READY 狀態非常重要。Crossplane 管理的資源是最終一致的，有些資源可能因為缺少資訊或前置條件未滿足而無法同步或就緒。
追蹤 SQLClaim 和 AppClaim 的狀態
類別似地，我們可以追蹤 SQLClaim 和 AppClaim 資源的狀態。
crossplane beta trace sqlclaim silly-demo-db --namespace a-team
內容解密：
crossplane beta trace：使用 Crossplane CLI 的追蹤功能（Beta 版）。sqlclaim silly-demo-db：指定要追蹤的 SQLClaim 資源，名稱為 silly-demo-db。--namespace a-team：指定資源所在的名稱空間。
輸出範例：
NAME SYNCED READY STATUS
SQLClaim/silly-demo-db (a-team) True False Waiting:...
└─ SQL/silly-demo-db-lp9xm True False Creating...
├─ VPC/silly-demo-db True True Available
├─ Subnet/silly-demo-db-a True False Creating
├─ Subnet/silly-demo-db-b True True Available
├─ Subnet/silly-demo-db-c True False Creating
├─ SubnetGroup/silly-demo-db False - ReconcileError...
├─ InternetGateway/silly-demo-db True True Available
├─ RouteTable/silly-demo-db True True Available
├─ Route/silly-demo-db False - ReconcileError...
├─ MainRouteTableAssociation/silly-demo-db False - ReconcileError...
├─ RouteTableAssociation/silly-demo-db-1a False - ReconcileError...
├─ RouteTableAssociation/silly-demo-db-1b False - ReconcileError...
├─ RouteTableAssociation/silly-demo-db-1c False - ReconcileError...
├─ SecurityGroup/silly-demo-db True True Available
├─ SecurityGroupRule/silly-demo-db False - ReconcileError...
├─ Instance/silly-demo-db False - ReconcileError...
├─ ProviderConfig/silly-demo-db - -
├─ Database/silly-demo-db False - ReconcileError...
└─ ProviderConfig/silly-demo-db-sql - -
同樣地，追蹤 AppClaim：
crossplane beta trace appclaim silly-demo --namespace a-team
內容解密：
crossplane beta trace：使用 Crossplane CLI 的追蹤功能（Beta 版）。appclaim silly-demo：指定要追蹤的 AppClaim 資源，名稱為 silly-demo。--namespace a-team：指定資源所在的名稱空間。
輸出範例：
NAME SYNCED READY STATUS
AppClaim/silly-demo (a-team) True False Waiting...
└─ App/silly-demo-9pfkj True False Creating...
├─ Object/silly-demo-deployment False - ReconcileError...
├─ Object/silly-demo-service False - ReconcileError...
├─ Object/silly-demo-ingress False - ReconcileError...
└─ Object/silly-demo-secret False - ReconcileError...
由於應用程式需要在新的叢集上執行，因此在叢集建立完成之前，應用程式尚未執行是正常的。所有資源最終都會達到一致的狀態。
透過 Crossplane CLI 的 trace 指令，我們可以清楚地瞭解資源的佈署狀態和依賴關係，這對於除錯和監控雲原生應用程式非常有幫助。
Crossplane 實戰：追蹤資源、驗證應用程式與環境清理
在上一節中，我們簡要體驗了 Crossplane 的強大功能。現在，讓我們更深入地探索如何追蹤資源、驗證應用程式是否正常運作，並學習如何安全地清理環境。準備好一杯咖啡，讓我們開始吧！
追蹤 SQLClaim 的奧秘
首先，我們再次使用 crossplane beta trace 指令來追蹤 SQLClaim：
crossplane beta trace sqlclaim silly-demo-db --namespace a-team
這次的輸出應該顯示所有執行 PostgreSQL 所需的資源都處於 Available 狀態。這表示我們的受管資料函式庫已經成功啟動並執行。
NAME SYNCED READY STATUS
SQLClaim/silly-demo-db (a-team) True True Available
└─ SQL/silly-demo-db-lp9xm True True Available
├─ VPC/silly-demo-db True True Available
├─ Subnet/silly-demo-db-a True True Available
├─ Subnet/silly-demo-db-b True True Available
├─ Subnet/silly-demo-db-c True True Available
├─ SubnetGroup/silly-demo-db True True Available
├─ InternetGateway/silly-demo-db True True Available
├─ RouteTable/silly-demo-db True True Available
├─ Route/silly-demo-db True True Available
├─ MainRouteTableAssociation/silly-demo-db True True Available
├─ RouteTableAssociation/silly-demo-db-1a True True Available
├─ RouteTableAssociation/silly-demo-db-1b True True Available
├─ RouteTableAssociation/silly-demo-db-1c True True Available
├─ SecurityGroup/silly-demo-db True True Available
├─ SecurityGroupRule/silly-demo-db True True Available
├─ Instance/silly-demo-db True True Available
├─ ProviderConfig/silly-demo-db - -
├─ Database/silly-demo-db True True Available
├─ ProviderConfig/silly-demo-db-sql - -
└─ Object/silly-demo-db True True Available
深入 ClusterClaim 的世界
接下來，讓我們看看叢集的情況。使用以下指令追蹤 ClusterClaim：
crossplane beta trace clusterclaim cluster-01 --namespace a-team
同樣地，輸出結果應該顯示執行叢集所需的所有資源都已啟動並執行。這意味著 Crossplane 應該能夠順利佈署與後端應用程式相關的資源。由於資料函式庫和叢集都已完全運作，應用程式也應該正常執行。
NAME SYNCED READY STATUS
ClusterClaim/cluster-01 (a-team) True True Available
└─ CompositeCluster/cluster-01-lkm96 True True Available
├─ InternetGateway/cluster-01 True True Available
├─ MainRouteTableAssociation/cluster-01 True True Available
├─ RouteTableAssociation/cluster-01-1a True True Available
├─ RouteTableAssociation/cluster-01-1b True True Available
├─ RouteTableAssociation/cluster-01-1c True True Available
├─ RouteTable/cluster-01 True True Available
├─ Route/cluster-01 True True Available
...
驗證 AppClaim 的狀態
為了確認應用程式是否真的在執行，我們可以追蹤 AppClaim：
crossplane beta trace appclaim silly-demo --namespace a-team
如果一切順利，您會看到類別似以下的輸出：
NAME SYNCED READY STATUS
AppClaim/silly-demo (a-team) True True Available
└─ App/silly-demo-9pfkj True True Available
├─ Object/silly-demo-deployment True True Available
├─ Object/silly-demo-service True True Available
├─ Object/silly-demo-ingress True True Available
└─ Object/silly-demo-secret True True Available
這表示我們最初定義的三個資源已經擴充套件成數十個其他資源，包括雲端供應商的資源和新的 Kubernetes 叢集中的資源。
最後確認：進入叢集一探究竟
為了確保一切都如預期般運作，玄貓建議進入新建立的叢集，確認後端應用程式是否真的在執行。首先，匯出 KUBECONFIG 變數：
export KUBECONFIG=$PWD/kubeconfig.yaml
然後，從您選擇的雲端供應商檢索 Kubeconfig。
Google Cloud:
gcloud container clusters get-credentials cluster-01 \ --region us-east1 --project $PROJECT_IDAWS:
aws eks update-kubeconfig --region us-east-1 \ --name cluster-01 --kubeconfig $KUBECONFIGAzure:
az aks get-credentials --resource-group cluster-01 \ --name cluster-01 --file $KUBECONFIG
玄貓提醒： 這些指令會根據您使用的雲端供應商而有所不同。
現在，我們可以檢查叢集是否真的有我們指定的節點數量：
kubectl get nodes
輸出應該類別似這樣：
NAME STATUS ROLES AGE VERSION
ip-10-0-0-241.ec2.internal Ready <none> 30s v1.27.7-eks-e71965b
ip-10-0-1-82.ec2.internal Ready <none> 26s v1.27.7-eks-e71965b
ip-10-0-2-216.ec2.internal Ready <none> 32s v1.27.7-eks-e71965b
確認節點存在後，讓我們檢查應用程式是否在 production 名稱空間中執行：
kubectl --namespace production get all,ingresses
如果一切正常，您會看到類別似以下的輸出：
NAME READY STATUS RESTARTS AGE
pod/silly-demo-998c464fc-8j9jj 1/1 Running 0 17m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/silly-demo ClusterIP 172.20.219.47 <none> 8080/TCP 17m
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/silly-demo 1/1 1 1 17m
NAME DESIRED CURRENT READY AGE
replicaset.apps/silly-demo-998c464fc 1 1 1 17m
NAME CLASS HOSTS ADDRESS PORTS AGE
ingress.networking.k8s.io/silly-demo <none> silly-demo.acme.com 80 17m
這表示應用程式正在執行，並且已連線到 PostgreSQL 資料函式庫。
展望 Crossplane 的無限可能
以上只是 Crossplane 眾多功能的一瞥。它改變了我們管理各種資源的方式，使我們能夠建立控制平面，並實作過去只有少數公司才能做到的事情。
環境清理：永續發展的根本
每個章節都以建立資源的說明開始，並以銷毀資源的說明結束。這樣，您可以獨立探索每個部分，並在不產生額外費用的情況下休息。
為了保持環境整潔，以下是如何銷毀我們建立的所有內容：
unset KUBECONFIG
chmod +x destroy/00-intro.sh
./destroy/00-intro.sh
exit
玄貓總結： 本文展示了 Crossplane 如何追蹤資源、驗證應用程式狀態，以及安全地清理環境。希望這些實戰經驗能激發您對 Crossplane 的興趣，讓我們在下一節中繼續深入探索！
