在雲原生環境下，有效管理 Kubernetes 資源和名稱空間至關重要。過去，Crossplane Composition 的 spec.writeConnectionSecretsToNamespace 欄位常被硬編碼為 crossplane-system，限制了 Secret 的存放位置。現在，透過 Composition 中的 Patches 機制，我們可以將 spec.claimRef.namespace 的值動態賦予其他資源的名稱空間欄位，實作更靈活的資源組態。如此一來，Secret 便能建立在 Claim 所在的名稱空間，提升資源管理效率。同時，調整 Composite Resource 的 kind 欄位，確保其在 API group 內的唯一性，有助於資源的清晰識別。實際佈署時，使用 kubectl apply --namespace <namespace> 命令，即可將資源佈署到指定的名稱空間。此外，Claim 作為開發者入口，結合 RBAC 許可權控制，讓開發者只能操作 Claim，而無法直接存取底層 Composition 和 Managed Resources，簡化開發流程並提升安全性。管理員則可透過 crossplane trace 命令追蹤所有資源狀態，掌握全域性。最後，透過 kubectl get secrets 命令驗證 Secret 是否已成功建立在指定的名稱空間，確保組態正確。
玄貓解構 Crossplane Composition：名稱空間遷移與資源管理實戰
在雲原生應用開發中，資源管理和名稱空間策略至關重要。玄貓將帶領大家深入瞭解 Crossplane Composition 的實戰應用，特別是如何透過 Composition 將資源佈署到正確的名稱空間，並提升整體資源管理效率。
擺脫硬編碼：名稱空間遷移的必要性
在舊版本的 Crossplane Composition 中，spec.writeConnectionSecretsToNamespace 常常被硬編碼為 crossplane-system。這種做法雖然簡單，但缺乏靈活性，使得 Secret 只能在固定的名稱空間中建立。為了提升靈活性，我們需要擺脫這種硬編碼方式，讓 Secret 能夠在 Claim 所在的名稱空間中建立。
Composition 的改造：Patch 的妙用
為了實作名稱空間的動態遷移，我們需要對 Composition 進行改造。以下是一個改造後的 Composition 範例：
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
name: google-postgresql
spec:
resources:
- name: sql
patches:
- fromFieldPath: spec.claimRef.namespace
toFieldPath: spec.forProvider.rootPasswordSecretRef.namespace
- name: user
patches:
- fromFieldPath: spec.claimRef.namespace
toFieldPath: spec.forProvider.passwordSecretRef.namespace
- name: sql-config
patches:
- fromFieldPath: spec.claimRef.namespace
toFieldPath: spec.credentials.connectionSecretRef.namespace
- name: sql-secret
patches:
- fromFieldPath: spec.claimRef.namespace
toFieldPath: spec.references[1].patchesFrom.namespace
- fromFieldPath: spec.claimRef.namespace
toFieldPath: spec.forProvider.manifest.metadata.namespace
在這個 Composition 中，我們使用了 patches 欄位，將 spec.claimRef.namespace 的值動態地賦予給其他資源的名稱空間欄位。Crossplane 會自動將 spec.claimRef.namespace 增加到由 Claim 建立的所有 Composite Resources 中，因此我們可以直接使用它來填充名稱空間欄位。
Composite Resource 的變更：Kind 的重要性
除了 Composition 之外，我們還需要對 Composite Resource 進行一些修改。其中一個重要的變更是 kind 欄位。在 Composite Resource Definition 中，Composite Resources (cluster-scoped) 的 kind 被設定為 SQL，而 Claims 的 kind 被設定為 SQLClaim。玄貓認為，這些名稱可以根據實際需求進行調整，但必須確保在 API group 內是唯一的。
實戰演練：kubectl apply 的正確姿勢
完成了 Composition 和 Composite Resource 的修改後，我們可以使用 kubectl apply 命令來佈署資源。這次，我們需要指定 --namespace 引數，確保 Secret 和 Claim 在同一個名稱空間中建立。
kubectl --namespace a-team apply --filename examples/$HYPERSCALER-sql-v6.yaml
透過這個命令，我們可以在 a-team 名稱空間中建立 Secret 和 Claim。
開發者入口：Claim 的價值
如果我們想要建立一個開發者入口，Claim 將會扮演重要的角色。透過 RBAC，我們可以限制開發者只能存取 Claims，而無法直接存取 Compositions 和 Managed resources。這樣可以實作資源的清晰分離，讓開發者專注於應用開發，而管理員則負責資源的管理和維護。
管理員視角：crossplane trace 的威力
雖然開發者只能看到特定名稱空間中的資源，但管理員仍然可以透過 crossplane trace 命令來追蹤所有資源的狀態。
crossplane beta trace sqlclaim my-db --namespace a-team
這個命令可以顯示 SQLClaim 建立的 Composition SQL 以及相關的 Managed Resources。透過這個工具，管理員可以全面瞭解資源的佈署情況。
驗證成果：Secret 的名稱空間
當所有資源都處於 Available 狀態時，我們可以驗證 Secret 是否在正確的名稱空間中建立。
kubectl --namespace a-team get secrets
如果 Secret 出現在 a-team 名稱空間中，則表示我們的改造成功了。
玄貓結語
Crossplane Composition 是 Crossplane 中最重要的功能之一。透過本文的介紹，玄貓希望大家能夠更深入地瞭解 Composition 的實戰應用，並在實際專案中靈活運用。在雲原生時代，資源管理和名稱空間策略至關重要。掌握 Crossplane Composition，將有助於我們更好地管理雲原生資源，提升應用開發效率。
從零開始：開發可移植的 Crossplane 組態包
在上一篇文章中，玄貓（BlackCat）示範瞭如何使用 Composition 來封裝託管的 PostgreSQL 資料函式庫，使其能在 AWS、Azure 和 Google Cloud 上執行。這讓我們能夠提供一種簡單的服務，讓任何人都能建立資料函式庫及其所需的一切，同時將複雜性轉化為底層的實作細節。
但我們仍然面臨一個發布的問題。我們需要指導管理控制平面的人員去應用 Provider、Composite Resource Definition 和 Composition。我們需要分發所有這些我們編寫的清單（manifests）。雖然這不一定是個壞主意，特別是當我們使用像 Argo CD 和 Flux 這樣的 GitOps 工具時，但有沒有更好的方法來分發所有這些東西呢？
答案是肯定的。我們可以構建 OCI 映象（你可能稱之為 Docker 映象），將 Crossplane 執行一組 Composition 所需的一切都封裝進去。我們稱它們為組態包（Configuration Packages），就像 Provider，以及你將在後面章節中發現的 Function 一樣，它們都是 Crossplane 包的不同變體。這些就是我們在使用 kubectl get pkgrev 命令檢索 Package Revision 時看到的那些。
因此，本章將專門介紹 Crossplane 組態包，它提供了一種分發 Composite Resource Definition、Composition 及其依賴的 Provider 的機制。
讓我們先設定好本章實踐部分所需的一切。
環境組態
跟著玄貓（BlackCat）的步驟，你應該已經很熟悉了。
本章使用的所有命令都可以在這個 Gist https://gist.github.com/vfarcic/3f4f9bf05c937b9f12e6bcb43f3c0bc7 找到。
首先，進入 crossplane-tutorial 的目錄（除非你已經在那裡了）…
cd crossplane-tutorial
…然後執行 Nix Shell…
nix-shell --run $SHELL
…使設定指令碼可執行…
chmod +x setup/03-configurations.sh
…並執行它。
./setup/03-configurations.sh
最後，source 環境變數。
source .env
構建組態包
玄貓（BlackCat）猜測你可能覺得我試圖隱藏什麼，所以讓我們先證明我們目前使用的控制平面叢集中幾乎什麼都沒有。
有任何 Composition 嗎？
kubectl get compositions
沒有。輸出顯示 No resources found。
Package 呢？
kubectl get pkgrev
仍然是 No resources found。
玄貓（BlackCat）讓你自己去發現，除了 Crossplane 本身和你選擇的超大規模供應商的憑證 Secret 之外，叢集中確實沒有其他東西。
與之前的文章不同，我們沒有應用 Package、Composition、Composite Resource Definition 或任何其他我們到目前為止使用的資源型別。玄貓（BlackCat）想確保我們可以將所有這些都封裝到一個容器映象中，並將其應用到一個“乾淨”的控制平面。
實際上，這並非完全正確，但我們稍後會討論例外情況。
現在，讓我們看一下包含 Composition 新版本的目錄，首先進入目錄…
cd compositions/sql-v7
…然後列出裡面的所有內容。
ls -1
輸出如下。
aws.yaml
azure.yaml
crossplane.yaml
definition.yaml
google.yaml
整個目錄是我們在前一篇文章中使用的最後一個目錄的副本。玄貓（BlackCat）沒有修改 Composition 或 Composite Resource Definition。它們完全相同。但是那裡有一個新檔案。一個 Configuration 被增加到了 crossplane.yaml 檔案中。這是新增加的內容，所以讓我們看一下它。
cat crossplane.yaml
輸出如下（為簡潔起見，已截斷）。
apiVersion: meta.pkg.crossplane.io/v1
kind: Configuration
metadata:
name: dot-sql
annotations:
meta.crossplane.io/maintainer: Viktor Farcic (@vfarcic)
meta.crossplane.io/source: github.com/vfarcic/crossplane-tutorial
meta.crossplane.io/license: MIT
meta.crossplane.io/description: Fully operational PostgreSQL...
meta.crossplane.io/readme: A Configuration package that defines...
spec:
crossplane:
version: ">=v1.14.0"
dependsOn:
- provider: xpkg.upbound.io/upbound/provider-aws-ec2
version: ">=v0.36.0"
- provider: xpkg.upbound.io/upbound/provider-aws-rds
version: ">=v0.36.0"
- provider: xpkg.upbound.io/upbound/provider-azure-dbforpostgresql
version: ">=v0.33.0"
- provider: xpkg.upbound.io/upbound/provider-gcp-sql
version: ">=v0.33.0"
- provider: crossplane/provider-sql
version: ">=v0.5.0"
# - provider: xpkg.upbound.io/crossplane-contrib/provider-kubernetes
# version: ">=v0.10.0"
這個 Configuration 是一個 Kubernetes 資源，就像與 Crossplane 相關的任何其他資源一樣。它包含一些訊息性的註解，除非我們將 Configuration 發布到 Upbound Marketplace。
“真正”的操作在 spec 部分。
在這裡，我們指定了 Crossplane 的最低版本是 v1.14.0。如果我們在 Composition 中使用了增加到特定 Crossplane 版本的功能，那麼這個版本就很重要。我們將在後面的章節中看到 Crossplane 1.14 中可用的一個功能。
最後，spec.dependsOn 陣列包含一個 Provider 及其版本的列表。由於我們的 Composition 使用了 AWS ec2 和 rds、Azure dbforpostgresql、Google Cloud 的 sql 和 sql Provider，所以我們在這裡指定了這些。正如你很快就會看到的，當我們應用 Configuration 時，所有這些 Provider 都會自動安裝。
我們也使用了 kubernetes Provider，但它在 Configuration 中被註解掉了。如果你還記得前一篇文章，Kubernetes Provider 需要“額外”的資源，比如 ServiceAccount、ClusterRoleBinding 和 ControllerConfig。此外，Kubernetes Provider 需要被修改以使用該 ControllerConfig。否則，如果我們不應用所有這些，Kubernetes Provider 將沒有許可權透過 Kubernetes API 建立資源，就像 AWS、Azure 和 Google Cloud Provider 需要帶有身份驗證的組態一樣。不幸的是，這些不能放入 Configuration Package 中。玄貓（BlackCat）本應該把它從 Configuration 中移除，但我想把它留在這裡作為一個提醒，它需要單獨應用。
現在我們已經看到了 Configuration，我們可以構建一個 Configuration Package，它將包含該 Configuration 以及來自該目錄的所有 Composition 和 Composite Resource Definition。
