在雲原生時代，有效管理 Kubernetes 叢集中的雲端資源至關重要。Crossplane 提供了一個宣告式的資源管理平台，而 Configuration Package 則進一步簡化了組態的封裝和分享。本文將探討如何利用 Upbound Registry 發布和安裝 Configuration Package，並分享一些實戰技巧。首先，我們需要將 Crossplane 的相關設定，包含 Compositions、Composite Resource Definitions (XRDs) 以及 Configuration 等封裝成 OCI 映象。這個映象就代表我們的 Configuration Package，其中包含所有執行 Composite Resources 和 Composite Resource Claims 所需的元件。封裝完成後，我們需要選擇一個容器 Registry 來存放這個 Package。雖然 Docker Hub、GitHub Registry 等都是可行的選項，但 Upbound Registry 提供了更便捷的整合，並且免費使用。透過 Up CLI，我們可以輕鬆地登入 Upbound Registry、建立 Repository，並將 Configuration Package 推播到 Registry 中。在推播完成後，雖然 Package 已經儲存在 Registry 中，但還需要進一步發布才能在 Marketplace 上公開。為了避免 Marketplace 上出現過多的重複 Package，我們通常不會立即發布。完成推播後，記得清理本地檔案以維持環境整潔。最後，我們將示範如何在一個只安裝了 Crossplane 的 Kubernetes 叢集中安裝這個 Configuration Package，並將其轉換成可管理 PostgreSQL 資料函式庫的控制平面。過程中會使用 kubectl apply 指令來佈署 Configuration，並使用 yq 工具修改 Configuration 檔案中的 Package 路徑，確保其指向正確的 Registry 位置。由於佈署 Package 和建立 CRD 需要一些時間，建議可以利用這段時間稍作休息。
利用 Upbound Registry 發布與安裝 Crossplane 組態包：玄貓的實戰
在雲原生時代，Crossplane 讓我們能夠以宣告式的方式管理各種雲端資源。為了更好地組織和分享我們的組態，將它們封裝成 Configuration Package 是個不錯的選擇。本文將介紹如何使用 Upbound Registry 來發布和安裝 Crossplane Configuration Package，讓你的組態管理更上一層樓。
建立 Configuration Package：從 YAML 到 OCI 映象
首先，我們需要將 Compositions、Composite Resource Definition 和 Configuration 等資源封裝成一個 OCI 映象。這個映象就是 Configuration Package，它包含了執行 Composite Resources 和 Composite Resource Claims 所需的一切。
在封裝之前，先來看看我們的組態包裡有哪些東西：
Configuration Packages
92
1 aws.yaml
2 azure.yaml
3 crossplane.yaml
4 definition.yaml
5 dot-sql-b1062aa3bfc8.xpkg
6 google.yaml
其中，dot-sql-*.xpkg 就是我們要推播的 Configuration Package。
選擇你的 Registry：為何玄貓推薦 Upbound Registry
接下來，我們需要選擇一個容器映象 Registry 來存放我們的 Configuration Package。你可以選擇 Docker Hub、GitHub Registry、Harbor 等任何你喜歡的 Registry。
但為了方便起見，玄貓推薦使用 Upbound Registry。它是免費的，並且是大多數公共 Configuration Packages、Providers 和其他資源的家。
首先，你需要在 accounts.upbound.io 建立一個 Upbound 帳戶。
使用 Up CLI 與 Registry 互動：玄貓的終端偏好
玄貓個人偏好使用終端來操作，因此我們將使用 Up CLI 來完成後續步驟。
首先，登入到 Upbound Registry：
1 up login
然後，建立一個新的 Repository：
1 up repository create dot-sql
如果你喜歡圖形介面，也可以在瀏覽器中開啟 marketplace.upbound.io 來檢視新建立的 Repository。
推播 Configuration Package：讓世界看到你的作品
現在，我們已經準備好將 Configuration Package 推播到 Registry 了。但在此之前，我們需要使用 Crossplane CLI 進行身份驗證。
首先，將你的 Upbound 使用者名稱儲存在 UP_USER 變數中：
1 # Replace `[...]` with the username
2 export UP_USER=[...]
然後，登入：
1 crossplane xpkg login --username $UP_USER
最後，推播 Configuration Package：
1 crossplane xpkg push xpkg.upbound.io/$UP_USER/dot-sql:v0.0.7
推播完成後，重新整理瀏覽器中的 Repository，你就能看到你的 Configuration Package 已經在那裡了。
發布 Configuration Package：可選但重要的一步
雖然我們的 Configuration Package 已經儲存在 Upbound Marketplace Registry 中，但它還沒有被發布，也就是說它不會在 Marketplace 中列出。
你可以選擇發布它，讓更多人看到你的作品。但為了避免 Marketplace 中出現大量重複的 dot-sql packages，我們在這裡就不發布它了。
清理本地檔案：保持環境整潔
完成後，我們可以刪除本地的 Configuration Package 檔案：
1 rm dot-sql-*.xpkg
然後，回到專案的根目錄：
1 cd ../..
安裝 Configuration Package：將組態應用到叢集
現在，讓我們看看如何使用我們剛剛構建並儲存在 Registry 中的 Configuration Package。
回到只有 Crossplane 安裝的叢集，我們要將這個簡陋的叢集轉換為可以管理 PostgreSQL 資料函式庫的控制平面。
首先，檢視 Configuration 檔案：
1 cat providers/dot-sql-v7.yaml
內容如下：
1 ---
2 apiVersion: pkg.crossplane.io/v1
3 kind: Configuration
4 metadata:
5 name: crossplane-sql
6 spec:
7 package: xpkg.upbound.io/vfarcic/dot-sql:v0.0.7
這個 Configuration 參照了我們剛剛構建並推播到 Registry 的 Package。
但請注意，這裡的 vfarcic 需要替換成你自己的 Upbound 使用者名稱。
使用 yq 命令進行替換：
1 yq --inplace \
2 ".spec.package = \"xpkg.upbound.io/$UP_USER/dot-sql:v0.0.7\"" \
3 providers/dot-sql-v7.yaml
然後，應用這個 Configuration：
1 kubectl apply --filename providers/dot-sql-v7.yaml
這時候可以去喝杯咖啡了，因為佈署 Package 和建立 CRD 需要一些時間。
使用 Crossplane 組態包管理雲端資源：進階
在雲端原生應用程式的開發中，如何有效地管理和佈署基礎設施資源是一個關鍵挑戰。Crossplane 透過組態包（Configuration Packages）提供了一種解決方案，允許開發者以宣告式的方式定義和佈署雲端資源。本文將探討如何使用 Crossplane 組態包來管理多雲環境下的資源，並分享我在實戰中積累的經驗。
探索組態包的奧秘
Crossplane 的組態包本質上是一個包含 Providers、Compositions 和 Composite Resource Definitions (XRDs) 的容器映象。透過將這些元件封裝在一起，我們可以更輕鬆地在不同的環境中佈署和管理雲端資源。
首先，讓我們看看如何檢視已安裝的組態包：
kubectl get pkgrev
執行上述指令後，你可能會看到類別似以下的輸出（為了簡潔起見，已截斷）：
NAME HEALTHY REVISION IMAGE ...
.../crossplane-sql-... True 1 xpkg.upbound.io/vfarcic/dot-sql:v0.0.7...
.../crossplane-provider-sql-... True 1 ...
.../upbound-provider-aws-ec2-... True 1 ...
.../upbound-provider-aws-rds-... True 1 ...
.../upbound-provider-azure-dbforpostgresql-... True 1 ...
.../upbound-provider-family-aws-... True 1 ...
.../upbound-provider-family-azure-... True 1 ...
.../upbound-provider-family-gcp-... True 1 ...
.../upbound-provider-gcp-sql-... True 1 ...
從輸出中我們可以看到兩種型別的包：
- Configuration：例如
crossplane-sql，這是我們剛剛佈署的組態。 - Providers：例如
upbound-provider-aws-ec2，這些是我們在crossplane.yaml檔案中指定的 Providers。
值得注意的是，Kubernetes Provider 並未包含在組態包中。這主要是因為 Kubernetes Provider 的設定相對複雜，通常需要在組態包之外單獨管理。此外，Provider Configs（包含雲端供應商憑證）也不會包含在組態包中，因為將憑證儲存在容器映象中是不安全的。
接下來，讓我們確認 Compositions 是否已正確佈署：
kubectl get compositions
預期的輸出如下：
NAME XR-KIND XR-APIVERSION AGE
aws-postgresql SQL devopstoolkitseries.com/v1alpha1 8m28s
azure-postgresql SQL devopstoolkitseries.com/v1alpha1 8m28s
google-postgresql SQL devopstoolkitseries.com/v1alpha1 8m28s
確認所有 Compositions 都已成功佈署後，我們就可以繼續處理遺漏的部分。
Provider Configs：安全地管理雲端憑證
將 Provider Configs 納入組態包是不合理的，因為它們包含連線到雲端供應商所需的敏感憑證。因此，我們需要像之前一樣單獨佈署它們。
以下是一個 ProviderConfig 範例：
apiVersion: aws.upbound.io/v1beta1
kind: ProviderConfig
metadata:
name: default
spec:
credentials:
source: Secret
secretRef:
namespace: crossplane-system
name: aws-creds
key: creds
這個 ProviderConfig 參照了一個儲存在 Kubernetes Secret 中的 AWS 憑證。透過這種方式，我們可以安全地管理雲端憑證，而無需將它們儲存在組態包中。
現在，讓我們佈署 ProviderConfig：
kubectl apply --filename providers/$HYPERSCALER-config.yaml
Kubernetes Provider：額外的考量
如前所述，Kubernetes Provider 需要額外的處理。讓我們直接佈署它：
kubectl apply --filename providers/provider-kubernetes-incluster.yaml
驗證佈署結果
為了驗證一切是否正常工作，我們可以佈署一個 Composite Claim：
kubectl --namespace a-team apply --filename examples/$HYPERSCALER-sql-v6.yaml
然後，使用 crossplane beta trace 指令來追蹤資源的建立過程：
crossplane beta trace sqlclaim my-db --namespace a-team
這個指令會顯示 Claim 建立 Composite Resource 以及 Composite Resource 建立 Managed Resources 的過程。如果一切組態正確，最終所有資源都應該處於 Available 狀態。
玄貓的經驗分享：組態包管理的最佳實踐
從我過去幾年使用 Crossplane 的經驗來看，組態包提供了一種強大與靈活的方式來管理雲端資源。然而，要充分利用組態包的優勢，需要遵循一些最佳實踐：
- 保持組態包的精簡：只包含必要的 Providers、Compositions 和 XRDs。避免將與環境相關的組態（例如 Provider Configs）納入組態包中。
- 使用版本控制：為你的組態包建立版本控制系統，以便追蹤變更並在需要時回復。
- 自動化佈署：使用 CI/CD 管道自動化組態包的構建、測試和佈署過程。
- 定期更新：定期更新你的組態包，以確保你使用的是最新版本的 Providers 和 Compositions。
持續進化：組態包
雖然我們已經可以使用組態包來管理雲端資源，但 Crossplane 的組態包功能仍在不斷進化。在未來的版本中，我們可以期待看到更多的功能，例如：
- 更精細的許可權控制：允許我們更精確地控制哪些使用者可以佈署和修改組態包。
- 更強大的測試工具：提供更全面的工具來測試組態包的正確性和可靠性。
- 更好的整合：與其他雲端原生工具（例如 Helm 和 Kustomize）更好地整合。
運用玄貓函式（BlackCat Functions）提升 Crossplane 組合彈性
到目前為止，我們成功地建構並發布了 Crossplane 組合，但過程並不容易，結果也不一定符合需求。即使我沒有在前幾章提到，我們正面臨兩個潛在的問題。
首先，我們必須編寫大量的 YAML。AWS 組合有超過四百行的 YAML。Google 的情況稍好，約為兩百行，而 Azure 只有約一百二十行。這些組合確實完成了大量工作，因此這樣的規模是合理的。然而，不可否認的是，擁有數百行的 YAML 可能不是編寫組態清單的最佳方式。使用者（即建立宣告的人）可以免於這些複雜性，因為他們的需求只需幾行程式碼即可滿足。儘管使用宣告很容易，但定義組合卻不然。
幸運的是，這些 YAML 僅代表 Kubernetes 資源，因此我們可以像平常一樣，使用任何格式和工具來產生這些組態清單。可以是 Helm 範本、Kustomize 覆寫、用 Go、Python、TypeScript 或 Java 編寫的 cdk8s、Jsonnet 或你今天可能正在使用的任何其他格式。這就是 Kubernetes 的美妙之處。它期望 YAML，但並不關心我們在將其提交到 API 之前如何產生它。
然而，擁有過多的 YAML 並不是我們將在本章中嘗試解決的問題。我這麼說的部分原因是，我難以猜測你的偏好，而與你可能已經知道如何編寫 Helm 範本、Kustomize 覆寫或任何其他你可能選擇的格式和工具來管理 Kubernetes 資源。請記住，這些都是 Kubernetes 資源，因此沒有理由不使用你已經在使用的東西。我們可能會在接下來的章節中討論它，但現在，我們將專注於解決不同的問題。
玄貓對管理資源彈性的思考
Crossplane 組合在管理資源方面不提供任何彈性。我們在組閤中指定的任何內容都將被管理。我們可以透過修補（Patching）自定義體驗，但這僅限於我們如何檢索和填充值。Crossplane 組合不允許條件、迴圈或更複雜的邏輯。
這就是我們將在本章中解決的問題。我們將瞭解如何使用玄貓函式（Composition Functions）來「使」Crossplane 組合做我們想讓它們做的事情。
但在我們繼續之前，我想明確說明我提到的這兩個問題非常不同。第一個問題通常透過範本解決方案解決，是如何產生應用於 Kubernetes API 的 Kubernetes 組態清單的問題。Helm、Kustomize 和其他類別似工具提供了一種將範本或覆寫（或我們正在使用的任何東西）轉換為 Kubernetes YAML 的方法，然後將其提交到 Kubernetes API。Kubernetes API 不關心範本。它僅適用於包含組態清單的 YAML，這些組態清單會轉換為叢集中的資源。
第二個問題與叢集內發生的過程有關。一旦將複合宣告傳送到 Kubernetes API，控制器就會將該宣告「擴充套件」為複合資源（XR），而複合資源又會建立和管理管理資源（MR）。與 Helm、Kustomize 和在客戶端執行某些操作的類別似工具（例如，你的筆記型電腦）不同，玄貓函式（Composition Functions）使我們能夠靈活地處理控制平面叢集內發生的過程。區別在於我們是在將某些東西提交到 Kubernetes API 之前還是之後「靈活」。
今天，我們將解決後者。我們將使用玄貓函式（Composition Functions）為控制平面叢集內發生的過程提供彈性。
玄貓函式（BlackCat Functions）出現的背景
讓我給你講述一下導致我們使用玄貓函式（Composition Functions）的背景故事。自 Crossplane 的早期以來，使用者一直在要求社群增加與產生管理資源相關的新功能。
人們要求使用條件，以便他們可以透過程式設計方式決定要建立哪些資源。這很容易增加，但我們沒有增加它。
人們要求使用迴圈，以便他們可以遍歷值以建立可變數量的管理資源。這也很容易，但我們也沒有增加它。
人們要求使用更複雜的功能，例如查詢超大規模供應商以查詢可用 IP 的列表。我們當然沒有增加它。
還有無數其他請求，但沒有一個請求被納入 Crossplane 組合。為什麼會這樣？這是否意味著 Crossplane 社群不關心功能請求？
社群正在努力滿足 Crossplane 使用者的需求，同時也在努力避免將 Crossplane API 變成一團糟。增加每個人需要的每項功能，會導致 API 變得過於複雜，並且無法很好地滿足每個人的需求。因此，社群決定保持 Crossplane API（特別是組合 API）的簡單性。我們並不是要將其轉換為 DSL。
儘管如此，問題仍然存在。人們需要額外的功能，但社群不想將這些功能增加到組合規範中。相反，社群想出了在不將任何這些功能烘焙到其規範中的情況下，擴充套件組合功能的方法。這種「擴充套件」就是今天所知的玄貓函式（Composition Functions）。讓我們來看看它們。
與每一章一樣，我們將從設定開始。
章節設定
你現在應該知道如何操作了。本章使用的所有命令都在 Gist 中。進入 crossplane-tutorial 目錄（如果你還沒有進入），…
cd crossplane-tutorial
…啟動 Nix Shell，它將帶入我們需要的所有工具，…
nix-shell --run $SHELL
…給予指令碼可執行許可權，…
chmod +x setup/04-functions.sh
…然後執行它。
./setup/04-functions.sh
玄貓對函式組合的看法
玄貓認為函式組合的出現，解決了 Crossplane 在組合管理資源時缺乏彈性的問題。透過函式組合，開發者可以更靈活地控制資源的生成，實作條件判斷、迴圈等複雜邏輯，而無需修改 Crossplane 核心 API。這種擴充套件方式既滿足了使用者的需求，又保持了 Crossplane API 的簡潔性，避免了 API 過於臃腫和難以維護的問題。
玄貓談雲原生：利用組合函式提升 Crossplane 應用彈性
在雲原生架構中，Crossplane 作為一個強大的控制平面工具，讓開發者能以宣告式的方式管理各種雲端資源。但隨著應用場景日趨複雜，我們需要更彈性的方式來客製化資源的佈署流程。這時，組合函式（Composition Functions）就派上用場了。
現有 Composite Claim 的不足之處
讓我們先回顧一下先前的 Composite Claim 設定。假設我們使用以下指令追蹤名為 my-db 的 SQLClaim：
crossplane beta trace sqlclaim my-db --namespace a-team
你可能會看到類別似這樣的輸出：
NAME SYNCED READY STATUS
SQLClaim/my-db (a-team) True True Available
└─ SQL/my-db-... True True Available
├─ ResourceGroup/my-db-... True True Available
├─ Server/my-db-... True True Available
├─ FirewallRule/my-db-... True True Available
├─ ProviderConfig/my-db-... - -
└─ Database/my-db-... True True Available
這個 Claim 在之前的章節中已經使用過。但仔細想想，這樣的設計是否還有改進空間？
一個潛在的問題是，在 PostgreSQL 伺服器中建立的資料函式庫名稱，預設會與 Claim ID 相同。雖然 Claim ID 必須是唯一的，但使用者可能希望資料函式庫名稱能更有彈性。此外，有些使用者可能只需要資料函式庫伺服器，而不需要在伺服器中建立資料函式庫。他們可能使用其他工具來管理資料函式庫，並希望 Crossplane 專注於伺服器的管理。
透過組合函式實作更靈活的組態
為瞭解決這些問題，我們可以考慮以下幾種方案：
- 自訂資料函式庫名稱： 擴充套件 Composite Resource Definition，允許使用者指定資料函式庫名稱的陣列。這樣一來，使用者可以根據需求建立任意數量的資料函式庫，甚至完全不建立。
- 引入資料函式庫 Schema 管理： 讓使用者不僅能建立 PostgreSQL 伺服器和相關基礎設施，還能定義資料函式庫 Schema。
Crossplane 本身雖然沒有管理資料函式庫 Schema 的機制，但我們可以整合其他工具來實作這個目標。玄貓個人推薦 Atlas Operator，它是一個專為 Kubernetes 設計的 Schema 管理工具。
整合 Atlas Operator 的關鍵在於將 AtlasSchema 資源增加到 Composition 中。這需要一個包含資料函式庫伺服器驗證資訊的 Secret。由於我們已經在 Composition 中產生 Secret，因此可以使用 patching 的方式，將 AtlasSchema 資源與正確的 Secret 連結起來。
組合函式：Patch and Transform
在眾多的組合函式中，Patch and Transform 是一個不錯的起點。它可以讓我們在不修改底層資源定義的情況下，動態地修改資源的組態。
那麼，我們該如何使用 Patch and Transform 函式呢？
首先，你需要在 Kubernetes 叢集中佈署這個函式。Functions 也是一種特殊的 Packages，就像 Providers 和 Configurations 一樣。你可以從 Upbound Marketplace 上找到 Patch and Transform 函式的 YAML 檔案，並使用 kubectl apply 指令佈署它。
接下來，我們需要定義一個 Composition，告訴 Crossplane 如何使用這個函式。在 Composition 中，你可以指定要修改的資源，以及要套用的轉換規則。Patch and Transform 函式允許你使用 JSON Patch 或其他轉換方式，靈活地修改資源的組態。
透過 Patch and Transform 函式，我們可以輕鬆地實作自訂資料函式庫名稱、管理資料函式庫 Schema 等功能，從而提升 Crossplane 應用的彈性。
總之，組合函式為 Crossplane 帶來了更大的靈活性和可擴充套件性。透過善用這些函式，我們可以更好地滿足各種雲原生應用場景的需求。
kubectl apply --filename providers/function-patch-and-transform.yaml
kubectl apply --filename compositions/sql-v8/$HYPERSCALER.yaml
crossplane beta trace sqlclaim my-db --namespace a-team
