Crossplane 讓開發者能以熟悉的 Kubernetes 方式管理雲端資源，大幅降低了跨雲平台管理的複雜度。透過自定義資源定義 (CRD)，Crossplane 將雲端資源抽象成 Kubernetes 物件，實作了基礎設施即程式碼的目標。這使得開發者可以使用 kubectl 等工具管理雲端資源，如同管理 Pod、Deployment 等原生 Kubernetes 資源一樣。
Crossplane 的核心概念是 Provider 和 ProviderConfig。Provider 負責連線 Crossplane 與特定的雲端供應商，而 ProviderConfig 則提供連線所需的憑證資訊。透過這些元件，Crossplane 能夠與雲端供應商的 API 互動，建立、更新和刪除雲端資源。在資源建立過程中，Crossplane 會自動處理資源之間的依賴關係，確保資源以正確的順序進行組態。例如，在建立虛擬機器之前，Crossplane 會先確保網路資源已準備就緒。
Crossplane供應商與託管資源組態
在前一章，我們已經見識到 Crossplane 的強大之處。現在，讓我們回到起點，探索一些基礎概念：Crossplane 供應商與託管資源。玄貓不喜歡只講理論，所以我們直接進入實作，但在這之前，讓我們先設定好本章會用到的環境。
環境組態
跟之前一樣，執行指令碼！
cd crossplane-tutorial
nix-shell --run $SHELL
chmod +x setup/01-managed-resources.sh
./setup/01-managed-resources.sh
source .env
接下來，安裝 Crossplane 本身。後續章節會將安裝納入設定指令碼，但這是我們第一次實際操作，所以玄貓認為有必要展示一下安裝過程。
其實很簡單，只需要執行一個 Helm 指令：
helm upgrade --install crossplane crossplane \
--repo https://charts.crossplane.io/stable \
--namespace crossplane-system --create-namespace --wait
準備就緒，讓我們深入 Crossplane 供應商的世界。
Crossplane 供應商
供應商透過自定義資源定義（CRD）和控制器擴充套件 Crossplane 的能力。
通常，一個供應商會與一組 API 相關聯。例如，AWS、Google Cloud 和 Azure 供應商。安裝它們會使用數百個 CRD 擴充套件 Kubernetes API。大多數情況下，每個 CRD 都對應一個 API 端點。
重點是，供應商可以是任何東西。除了我提到的那些，還有 Kubernetes 供應商、SQL 供應商、Helm 供應商等等。
我們很快就會看到供應商的作用。現在，讓我們快速瀏覽 Upbound Marketplace，這裡收集和整理了各種供應商。
在那裡，我們可以搜尋供應商，或者直接瀏覽。如果你是新手，後者可能是一個好的起點。
左側可以切換到 Configurations 或 Functions，我們稍後會探索。
在供應商頁面中，會列出所有可用的供應商。花點時間看看有什麼。完成後，我們將安裝本章會用到的特定供應商。
範例：建立虛擬機器
在深入研究供應商之前，讓我們先決定本章要建構什麼。由於我們才剛開始，所以做一些簡單的事情。在您最喜歡的 HyperScaler 中建立 VM 是一個不錯的選擇。
要建立和管理虛擬機器，我們需要知道 API 群組。我們可以透過瀏覽 Marketplace 找到它，但那可能需要太多時間，所以讓我們直接搜尋。根據您選擇的供應商，搜尋 AWS、Azure 或 GCP（Google Cloud）。選擇名稱中包含 family 的供應商，如果使用 Azure 或 GCP，請選擇 Providers，然後搜尋 compute，如果使用 AWS，則搜尋 ec2。
玄貓在本章中使用 Azure，所以我的範例可能與你的略有不同。
點選選擇的供應商（例如 provider-aws-ec2、provider-gcp-compute 或 provider-azure-compute）。在特定供應商的頁面上，我們可以看到很多東西，稍後會探索。現在，重要的是「安裝 Manifest」按鈕，它提供了關於如何定義代表所選供應商的資源的指示。
我們可以複製該 Manifest 並將其貼到 YAML 檔案中，但我們不會這麼做，因為我已經事先準備好了。讓我們看一下它。
cat providers/$HYPERSCALER-vm.yaml
輸出如下：
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: provider-azure-compute
spec:
package: xpkg.upbound.io/upbound/provider-azure-compute:v0.39.0
---
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: provider-azure-network
spec:
package: xpkg.upbound.io/upbound/provider-azure-network:v0.39.0
由於玄貓在本章中使用 Azure（你可以使用三大雲端供應商中的任何一個），因此這裡定義了 provider-azure-compute，其中包含與 Azure 中計算相關的託管資源定義。還有 provider-azure-network 供應商，因為我們需要為 VM 定義網路。
如果你選擇 AWS 或 Google Cloud，你將只看到一個供應商。
讓我們執行 kubectl apply 來安裝它…
kubectl apply --filename providers/$HYPERSCALER-vm.yaml
…並列出所有可用的套件版本。
kubectl get pkgrev
輸出如下（為了簡潔而截斷）：
NAME HEALTHY REVISION IMAGE ...
.../provider-azure-compute-... 1 .../provider...
.../provider-azure-network-... 1 .../provider...
這可能會讓人困惑。
我們安裝了一個或兩個供應商，但接著我們列出了名為「套件版本」的東西。
讓我解釋一下…
套件允許擴充套件 Crossplane 以包含新功能。這通常看起來像是捆綁一組 Kubernetes CRD 和控制器，它們代表一些 API 端點。有三種型別的套件：供應商、組態和函式。
換句話說，供應商以及組態和函式是一種套件，因此透過列出所有套件版本，我們得到了所有套件。如果我們有組態或函式，我們也會看到它們。
讓我們回到前一個指令的輸出。
我們可以看到我們定義的供應商已套用，但它們尚未報告為 HEALTHY。這可能需要一些時間，因為一個供應商有時可能包含數十甚至數百個 CRD。
附帶一提，我們可以只列出供應商，而不是包含供應商的套件，使用 kubectl get providers。大多數時候，玄貓對所有型別的套件都感興趣，而不僅僅是供應商，所以我們可能會在本章的其餘部分使用 kubectl get pkgrev。
讓我們再次檢索套件。
探索 Crossplane 的 Provider 與受管資源：玄貓的實戰解析
在 Crossplane 的世界裡，Provider 扮演著至關重要的角色，它們像是連線 Kubernetes 控制平面與外部雲端服務的橋樑。讓我們一起深入瞭解 Provider 的運作方式，以及如何利用它們來管理雲端資源。
首先，透過 kubectl get pkgrev 指令，我們可以檢視已安裝的 Provider 狀態。
kubectl get pkgrev
輸出結果會顯示 Provider 的健康狀態、版本和映象等資訊。你會注意到，所有的 Provider 最終都會變成 HEALTHY 狀態，這表示它們已成功佈署並正常運作。
此外，你可能會觀察到一個名為 provider-family-azure 的新 Provider 出現。這就是所謂的 Provider Family。
Provider Family 的由來：玄貓的觀察
早期的 Crossplane Provider，每個雲平台（如 AWS、Azure、GCP）都只有單一 Provider。但由於每個 Provider 都會為雲平台的 API 端點建立 CRD（Custom Resource Definition），而雲平台往往擁有數百個 API 端點，這導致安裝單一 Provider 就可能產生近千個 CRD。如果同時安裝多個雲平台的 Provider，叢集中 CRD 的數量很容易達到數千個，進而引發效能問題，甚至導致較小規模的控制平面叢集當機。
雖然 Kubernetes 社群不斷努力改善 CRD 數量過多的問題，但 Crossplane 團隊也決定將大型 Provider 拆分為 Provider Family。因此，現在 AWS、GCP 或 Azure 的 Provider 被拆分為更小的 Provider，例如我們前面定義和套用的那個。
這個神秘的 Family Provider 會在我們套用 Family 中的任何一個 Provider 時自動安裝。它包含了額外的 Managed Resource Definition，這些定義對於 Family 中的所有 Provider 都是必要的。
CRD、Controller 與 Managed Resource Definition：玄貓的解構
在安裝了一些 Provider 之後，我們可以透過 kubectl get crds 指令來檢視這些 CRD。
kubectl get crds
輸出結果會顯示數十甚至數百個 CRD。每個 CRD 代表一個我們可以定義的雲平台資源。舉例來說，如果我想在 Azure 中建立和管理虛擬機器，可以使用 linuxvirtualmachines.compute.azure.upbound.io 這個 CRD。它包含了擴充套件的 Kubernetes API 端點，以及定義 VM 的 schema。
設定 Provider 憑證：玄貓的建議
Crossplane 必須能夠驗證帳戶，才能管理 AWS、Azure 或 Google Cloud 資源。我們需要提供具有足夠許可權的憑證，才能管理我們計劃定義的資源。
我們可以透過 ProviderConfig 來提供憑證，它會參考一個包含憑證的 Secret。我們先前執行的設定指令碼已經建立憑證檔案，現在我們可以開始建立 Secret。
如果你使用 AWS，請執行以下指令：
kubectl --namespace crossplane-system \
create secret generic aws-creds \
--from-file creds=./aws-creds.conf
如果你使用 Google Cloud，請執行以下指令：
kubectl --namespace crossplane-system \
create secret generic gcp-creds \
--from-file creds=./gcp-creds.json
如果你使用 Azure，請執行以下指令：
kubectl --namespace crossplane-system \
create secret generic azure-creds \
--from-file creds=./azure-creds.json
接下來，我們需要告訴 Crossplane 在哪裡可以找到我們剛剛建立的 Secret。我們透過與已安裝的 Provider 相關聯的 ProviderConfig 來實作這一點。
providers/$HYPERSCALER-config.yaml 檔案內容如下：
apiVersion: azure.upbound.io/v1beta1
kind: ProviderConfig
metadata:
name: default
spec:
credentials:
source: Secret
secretRef:
namespace: crossplane-system
name: azure-creds
key: creds
其中，apiVersion 是特定於 Provider 的，而 secretRef 則指定了 Secret 的位置。
最後，套用 ProviderConfig：
kubectl apply --filename providers/$HYPERSCALER-config.yaml
現在，Crossplane 已經準備好管理你選擇的雲平台中的資源。
建立受管資源：玄貓的實戰演練
Crossplane Managed Resource 代表由 Crossplane 管理的資源。它可以是任何東西，例如 AWS EC2 例項、Azure 中受管的 PostgreSQL 資料函式庫、Google Cloud Run 例項、Kubernetes 物件、Helm release 或 GitHub 儲存函式庫。只要控制平面叢集中存在 Managed Resource Definition，我們就可以根據它建立 Managed Resource。
Managed Resource Definition 及其對應的 Controller 是透過 Provider 安裝的，就像我們在前一節中套用的那樣。因此，安裝 Provider 會導致安裝許多 Managed Resource Definition，它們帶有 Kubernetes Custom Definition 和 Controller。
在 Crossplane Marketplace 中，我們可以檢視可以建立的 Managed Resource 列表，從而判斷我們感興趣的 Provider 是否包含我們需要的資源定義。
選擇你想管理的資源（AWS 或 Google Cloud 請選擇 Instance，Azure 請選擇 LinuxVirtualMachine），然後檢視 API 檔案，其中包含完整的 schema 和所有欄位。
我準備了一個範例，用於在你選擇的雲平台中建立和管理 VM。
examples/$HYPERSCALER-vm.yaml 檔案內容如下：
apiVersion: compute.azure.upbound.io/v1beta1
kind: LinuxVirtualMachine
metadata:
name: my-vm
spec:
forProvider:
location: eastus
resourceGroupNameRef:
name: dot-group
size: Standard_A1_v2
sourceImageReference:
為何採用 Crossplane 管理 Azure 資源：從範例組態談起
在雲端原生應用程式的佈署中，資源管理是一個核心挑戰。本文將探討如何使用 Crossplane 這一 CNCF 專案來管理 Azure 資源，並分享玄貓在實戰中累積的經驗與見解。
Azure 資源的 Kubernetes 風格組態
Crossplane 允許我們使用 Kubernetes 風格的 YAML 檔案來定義和管理雲端資源。以下是一個 Azure 虛擬機器的組態範例：
apiVersion: compute.azure.upbound.io/v1beta1
kind: LinuxVirtualMachine
metadata:
name: dot-vm
spec:
forProvider:
location: eastus
size: Standard_DS1_v2
resourceGroupNameRef:
name: dot-group
adminSshKey:
- publicKey: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC... you@me.com
username: adminuser
adminUsername: adminuser
osDisk:
- caching: ReadWrite
storageAccountType: Standard_LRS
networkInterfaceIdsRefs:
- name: dot-interface
這個 YAML 檔案描述了一個 Linux 虛擬機器，包括其位置、大小、管理員使用者名稱、SSH 金鑰等。spec.forProvider 區塊定義了資源的具體引數，這些引數與 Azure API 的引數幾乎一一對應。
資源參照：動態組態的關鍵
在上述範例中，resourceGroupNameRef 和 networkInterfaceIdsRefs 是兩個特殊的欄位。它們允許我們參照其他資源，而不是硬編碼資源群組和網路介面的名稱。這種做法有以下優點：
- 避免硬編碼： 減少組態中的硬編碼，提高可維護性。
- 動態組態： 允許 Crossplane 動態地解析資源之間的依賴關係。
- 最終一致性： 遵循 Kubernetes 的最終一致性模型，允許資源以任何順序建立。
玄貓認為，資源參照是 Crossplane 的一個核心特性。它使得我們可以像管理 Kubernetes 資源一樣管理雲端資源，並充分利用 Kubernetes 的宣告式組態和自動化能力。
依賴管理：Crossplane 的 Kubernetes 風格
與其他工具不同，Crossplane 沒有明確的依賴管理機制。相反，它遵循 Kubernetes 的邏輯，即一切都是最終一致的。這意味著我們可以同時套用多個資源，Crossplane 會自動處理它們之間的依賴關係。
如果某個資源缺少必要的資訊，Crossplane 會等待直到資訊可用。例如，如果虛擬機器的資源群組尚未建立，Crossplane 會等待資源群組建立完成後再建立虛擬機器。
資源群組、網路介面、子網路和虛擬網路的定義
除了虛擬機器之外，我們還需要定義資源群組、網路介面、子網路和虛擬網路。以下是一些範例組態：
apiVersion: azure.upbound.io/v1beta1
kind: ResourceGroup
metadata:
name: dot-group
spec:
forProvider:
location: eastus
---
apiVersion: network.azure.upbound.io/v1beta1
kind: NetworkInterface
metadata:
name: dot-interface
spec:
forProvider:
ipConfiguration:
- name: my-vm
privateIpAddressAllocation: Dynamic
subnetIdRef:
name: dot-subnet
location: eastus
resourceGroupNameRef:
name: dot-group
---
apiVersion: network.azure.upbound.io/v1beta1
kind: Subnet
metadata:
name: dot-subnet
spec:
forProvider:
addressPrefixes:
- 10.0.1.0/24
resourceGroupNameRef:
name: dot-group
virtualNetworkNameRef:
name: dot-network
---
apiVersion: network.azure.upbound.io/v1beta1
kind: VirtualNetwork
metadata:
name: dot-network
spec:
forProvider:
addressSpace:
- 10.0.0.0/16
location: eastus
resourceGroupNameRef:
name: dot-group
這些組態定義了 Azure 資源之間的依賴關係。例如，網路介面需要一個子網路，而子網路又需要一個虛擬網路。Crossplane 會自動處理這些依賴關係，確保資源以正確的順序建立。
Managed Resources 的侷限性與 Compositions 的優勢
雖然 Managed Resources 提供了一種管理雲端資源的方式，但它們也有一些侷限性。例如，它們可能會導致組態重複和混亂。為瞭解決這些問題，Crossplane 引入了 Compositions 的概念。
Compositions 允許我們將多個 Managed Resources 組合在一起，形成一個更高階別的抽象。這使得我們可以更輕鬆地定義和管理複雜的雲端應用程式。玄貓將在後續的文章中探討 Crossplane Compositions。
玄貓解說：Crossplane 如何助你玩轉雲端資源自動化
在雲端原生應用開發的世界裡，Crossplane 絕對是值得關注的一項技術。它不僅擴充套件了 Kubernetes 的能力，更將雲端資源的管理帶入了一個全新的境界。今天，就讓玄貓來帶領大家深入瞭解 Crossplane 的運作機制，以及它如何實作雲端資源的自動化管理。
資源狀態一覽：kubectl
想知道 Crossplane 管理了哪些資源嗎？一個簡單的指令就能搞定：
kubectl get managed
這個指令就像一個快捷鍵，能列出所有由 Crossplane 管理的資源。你可以清楚看到每個資源的 API、名稱，以及最重要的 READY 和 SYNCED 狀態。
- READY：代表實際的雲端資源是否已準備就緒，例如 Azure 上的 VM 是否已啟動並執行。
- SYNCED：表示 Crossplane 是否已同步資源的資訊。如果資源之間存在依賴關係，例如 VM 依賴於網路介面，那麼必須等到所有依賴的資源都同步完成，Crossplane 才能開始組態 VM。
玄貓提醒：如果發現某些資源長時間處於非同步狀態，很可能是因為缺少必要的參考資訊。這時，請檢查資源之間的依賴關係是否正確設定。
雲端資源的幕後推手
當你透過 Kubernetes API 建立自定義資源（CR）時，Crossplane 的控制器就會開始忙碌起來。它們會與你選擇的雲端供應商（例如 Azure、AWS 或 Google Cloud）的 API 進行溝通，進而建立所需的資源。
這個過程並非一蹴可幾。Crossplane 會先建立那些不依賴其他資源的元件，然後再處理那些需要依賴資訊的資源。一旦所有依賴的資源都就緒，Crossplane 就能夠取得所需的資料，並完成剩餘資源的建立。
持續監控：漂移檢測與協調
Kubernetes 最吸引人的特性之一，就是它能持續監控資源的狀態，並在發現漂移（drift）時自動進行協調（reconciliation）。舉例來說，如果一個 ReplicaSet 管理的 Pod 發生了變更，ReplicaSet 會立即檢測到這個漂移，並更新 Pod 以符合期望的狀態。
Crossplane 將這個概念提升到了一個新的層次。無論你使用 Crossplane 管理哪種型別的資源，它都會確保這些資源的狀態始終與你定義的期望狀態保持一致。
為了驗證這個特性，我們可以嘗試停止或刪除雲端供應商控制檯中的 VM 例項。稍等片刻，Crossplane 就會檢測到這個漂移，並自動將 VM 還原到正確的狀態。
玄貓的經驗：在 Azure 的情況下，由於 Azure API 不支援啟動已停止的 VM，因此我們通常會透過刪除 VM 來觸發漂移檢測與協調。
更新資源：與漂移檢測協調異曲同工
更新 Crossplane 管理的資源，也遵循著相同的漂移檢測與協調流程。當你修改了資源的組態清單（manifest）並將其應用到 Kubernetes 叢集時，Crossplane 會將這個變更視為一個漂移，並自動協調資源的狀態，使其與新的組態保持一致。
舉例來說，假設我們想要將 Azure VM 的大小從 Standard_A1_v2 變更為 Standard_A2_v2，我們可以修改對應的 YAML 檔案，然後執行 kubectl apply 指令。Crossplane 會自動檢測到這個變更，並更新 VM 的大小。
