Crossplane Composition：雲原生資料函式庫組態的利器

– 12 分鐘閱讀

Crossplane Composition 提供了一種宣告式的 API，讓開發者可以像拼積木一樣，將來自不同雲供應商的基礎設施資源組裝成一個個可複用的模組。這不僅簡化了雲原生應用程式佈署的複雜性，更提升了資源管理的效率和可維護性。

在過去，組態雲端資料函式庫往往需要大量的 YAML 檔案，並在其中硬編碼資料函式庫連線資訊、使用者許可權等細節。這種方式不僅容易出錯，也難以適應快速變化的雲原生環境。現在，藉由 Crossplane Composition，我們可以將這些組態抽象成可複用的模組，並透過引數化的方式，根據不同的環境需求進行調整。

舉例來說，我們可以建立一個 PostgreSQL 資料函式庫的 Composition，其中包含資料函式庫執行個體、使用者帳號、連線資訊等資源。開發者只需要指定資料函式庫版本、儲存空間大小等引數，Crossplane 就會自動完成所有底層資源的建立和組態。更重要的是，這個 Composition 可以跨雲平台使用，無論是 AWS、Azure 還是 GCP，都能夠輕鬆佈署。

除了簡化組態，Composition 還提升了資源管理的安全性。透過將敏感資訊儲存在 Kubernetes Secret 中，並由 Composition 進行參照，可以避免將這些資訊暴露在 YAML 檔案中，降低了安全風險。

此外，Composition 也提供了版本控制和更新機制。當需要更新資料函式庫版本或修改組態時，只需要更新 Composition 即可，Crossplane 會自動完成所有相關資源的更新，無需手動修改大量的 YAML 檔案。

然而，使用 Composition 也並非一帆風順。在實戰中，我遇到過一些挑戰，例如何處理不同雲供應商之間的差異、如何設計合理的 Composition 結構等。透過不斷的摸索和實踐，我總結了一些最佳實踐，例如：

  • 使用 matchControllerRef 實作自動參照，簡化組態並提高可靠性。
  • 制定統一的資源命名規範，方便管理和除錯。
  • 善用標籤管理，實作更精細的資源選擇。
  • 及時處理 Crossplane 拋出的錯誤，確保系統的穩定性。

總而言之，Crossplane Composition 是一個強大的工具，它可以幫助我們更好地管理雲原生環境中的資料函式庫資源。雖然在使用過程中可能會遇到一些挑戰，但只要掌握了正確的方法和技巧，就能夠充分發揮 Composition 的優勢，提升開發效率，降低維運成本。

探索 Crossplane Composition：跨雲資料倉管理的起點

在雲原生時代，跨越多個雲平台管理資源的需求日益增加。Crossplane 的 Composition 功能提供了一種強大的方式來定義和管理這些資源，就像一個藍圖，指導 Crossplane 如何在不同的雲環境中建立和組態資源。本文將探討 Composition 的建立、組態以及如何利用它來管理跨雲資料函式庫服務。

Composition 初體驗：建立跨雲資料函式庫藍圖

首先，我們需要建立 Composition。這些 Composition 定義了在不同雲平台上建立 PostgreSQL 資料函式庫所需的資源。以下指令用於建立 aws-postgresql、azure-postgresql 和 google-postgresql 三個 Composition：

kubectl apply -f compositions/sql-v1.yaml

執行後，我們可能會看到一些警告訊息，提示某些資源定義（例如 VPC、Subnet 等）找不到。這些警告表示我們還需要安裝對應的 Provider，Provider 提供了這些資源的具體定義。

解決資源定義缺失：安裝 Provider

為了讓 Crossplane 能夠正確建立和管理資源，我們需要安裝 Provider。Provider 包含了建立 Composition 中定義的資源所需的資訊。以下是如何安裝 Provider 的範例：

apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-aws-ec2
spec:
  package: xpkg.upbound.io/upbound/provider-aws-ec2:v0.47.1

這個 YAML 檔案定義了幾個 Provider，包括 AWS 的 ec2 和 rds Provider，以及 GCP 的 sql Provider 和 Azure 的 dbforpostgresql Provider。執行以下指令來安裝這些 Provider：

kubectl apply --filename providers/sql-v1.yaml

安裝完成後，可以使用 kubectl get pkgrev 指令來檢查 Provider 的狀態。由於需要下載和安裝大量的資源定義，這個過程可能需要一些時間。請耐心等待，直到所有 Provider 的狀態都顯示為 HEALTHY。

組態 Provider：連線雲平台

一旦 Provider 安裝完成，我們需要組態它們，以便 Crossplane 可以連線到我們的雲帳戶。這通常涉及到建立 ProviderConfig 資源，並提供必要的認證資訊。以下是一個 ProviderConfig 的範例：

apiVersion: gcp.upbound.io/v1beta1
kind: ProviderConfig
metadata:
  name: default
spec:
  projectID: dot-20231226202303
  credentials:
    source: Secret
    secretRef:
      namespace: crossplane-system
      name: gcp-creds
      key: creds

這個 ProviderConfig 定義了連線到 GCP 所需的專案 ID 和認證資訊。執行以下指令來應用這個組態：

kubectl apply --filename providers/$HYPERSCALER-config.yaml

請注意，即使我們建立了所有三個雲平台的 Composition，我們只需要組態其中一個，因為我們的目標是演示 Composition 的基本概念。

啟動資料倉管理：修改 Composite Resource

現在，我們已經準備好開始管理資料函式庫伺服器了。為此，我們需要修改 Composite Resource，並指定要使用的 Composition。以下是一個修改後的 Composite Resource 的範例：

apiVersion: devopstoolkitseries.com/v1alpha1
kind: SQL
metadata:
  name: my-db
spec:
  compositionSelector:
    matchLabels:
      provider: google
      db: postgresql

在這個範例中，我們使用 compositionSelector 欄位來指定要使用的 Composition。matchLabels 欄位用於選擇具有特定標籤的 Composition。在這個例子中，我們選擇了 provider: google 和 db: postgresql 標籤，這將會選擇 google-postgresql Composition。

玄貓觀點：Composition 的價值與挑戰

玄貓認為，Crossplane 的 Composition 功能為跨雲資源管理帶來了巨大的價值。它讓我們可以定義一個通用的資源模型，並在不同的雲平台上重複使用。然而，使用 Composition 也存在一些挑戰。

  • 複雜性：Composition 的定義可能變得非常複雜，特別是當涉及到大量的資源和組態時。
  • 可維護性：隨著時間的推移，Composition 可能需要更新和修改，以適應新的需求和雲平台的變化。
  • 學習曲線：Crossplane 和 Composition 的概念可能需要一定的學習成本，特別是對於那些不熟悉 Kubernetes 的人來說。

儘管存在這些挑戰，玄貓仍然相信 Crossplane 的 Composition 是一個非常有前途的技術，它可以幫助我們更好地管理跨雲資源，並實作真正的雲原生應用。

總之，Crossplane 的 Composition 提供了一種強大的方式來定義和管理跨雲資源。透過建立 Composition、安裝 Provider 和組態 ProviderConfig，我們可以輕鬆地在不同的雲平台上建立和管理資料函式庫伺服器。雖然使用 Composition 存在一些挑戰，但其帶來的價值和潛力是巨大的。

雲端SQL服務的煉金術：Crossplane Compositions的魔力

在雲端原生應用開發的旅程中，我們常常面臨一個挑戰：如何在不同的雲端供應商（AWS、Azure、GCP）之間，提供一致與易於管理的服務？今天，玄貓將帶領大家深入Crossplane Compositions的世界，看看如何利用它來開發一個跨雲的SQL服務。

金鑰與藍圖：定義標準與選擇

首先，我們需要一個 Kubernetes Secret，用來存放資料函式庫伺服器的初始密碼。這個 Secret 會被 Composition 參照，就像是啟動資料函式庫的鑰匙。

apiVersion: v1
kind: Secret
metadata:
  name: my-db-password
type: Opaque
data:
  password: <base64 encoded password>

接下來，我們要定義 SQL 的藍圖。這個藍圖不再只是空殼，而是包含了 spec.compositionSelector，這是一個非常重要的欄位。它允許我們選擇 SQL 服務的不同實作方式，例如 Google Cloud、AWS 或 Azure。

apiVersion: database.example.org/v1alpha1
kind: SQL
metadata:
  name: my-db
spec:
  compositionSelector:
    matchLabels:
      provider: gcp

這個 SQL 定義的巧妙之處在於，它讓服務的使用者可以選擇他們想要的雲端供應商，而無需關心底層的實作細節。使用者只需更改 provider 標籤，就可以在不同的雲端環境中執行資料函式庫。對使用者來說，一切都是相同的，但背後的運作方式卻截然不同。這種差異性被巧妙地隱藏起來，成為使用者無需關心的實作細節。

玄貓認為，這種設計模式非常符合雲端原生的理念：將複雜性封裝在底層，提供簡單易用的介面給使用者。

擴充套件的可能性：PostgreSQL vs. MySQL

如果我們建立更多的 Compositions，我們還可以讓使用者選擇不同的資料函式庫引擎，例如 PostgreSQL 和 MySQL。但為了避免讓這篇文章過於冗長，玄貓決定先專注於 PostgreSQL 在 AWS、Azure 和 Google Cloud 上的佈署。

當然，我們也可以讓使用者選擇更多選項，例如資料函式庫伺服器的大小或 PostgreSQL 的版本。但現在，我們先保持簡單，只讓使用者選擇雲端供應商。

佈署與追蹤：見證奇蹟的時刻

現在，讓我們應用這個 Secret 和 SQL Composite Resource：

kubectl apply --filename examples/$HYPERSCALER-sql-v1.yaml

然後，使用 crossplane beta trace 命令來追蹤 SQL 資源以及它所建立的所有子資源。

crossplane beta trace sql my-db

在 Google Cloud 的情況下，我們會看到 SQL/my-db 建立了兩個資源：DatabaseInstance 和 User。一開始，它們的狀態都是 Creating，這表示它們正在被建立中。因此，父資源 SQL/my-db 的狀態也是 Not Ready。

這個過程需要一些時間，具體取決於雲端供應商和需要建立的資源數量。所以，去喝杯咖啡吧！當你回來時，這個過程應該已經完成了。再次執行 crossplane trace 命令，你會看到所有資源的狀態都變成了 Available。

crossplane beta trace sql my-db

我們成功了！我們建立了一個服務，讓每個人都能在三大雲端供應商中建立和管理 PostgreSQL，而與操作非常簡單。

如果你不相信玄貓的話，可以開啟你最喜歡的雲端供應商的控制檯，親眼看看資料函式庫伺服器和所有相關資源是否真的已經啟動並執行。

藍圖解構：Crossplane 的魔法

那麼，我們到底做了什麼？

  1. 我們為 AWS、Google Cloud 和 Azure 上的 SQL 資料函式庫伺服器建立了 Compositions。
  2. Crossplane 建立了一個 Controller，用於監控 Composite Resources。
  3. 當有人將 Composite Resource 應用到控制平面叢集時，Controller 會將其「展開」為在所選雲端供應商中執行 PostgreSQL 伺服器所需的所有 Managed Resources。
  4. 例如，如果 matchLabels.provider 設定為 google，Crossplane Controller 會將 Composite Resource 展開為在 Google Cloud 中執行資料函式庫伺服器所需的 Managed Resources。
  5. 類別似地，如果 matchLabels.provider 設定為 aws，Controller 會將其展開為在 AWS 中執行資料函式庫伺服器所需的 Managed Resources。

未臻完美：持續進化的旅程

老實說，到目前為止，我們所做的事情還遠非完美。SQL 服務的使用者無法影響結果，所有 Crossplane 資源都是叢集範圍的，這遠非完美，而與可能不安全，我們建立的資料函式庫伺服器內部沒有資料函式庫，還有很多其他問題。我們將修復或實作所有這些問題，以及其他一些問題。我們才剛剛開始。從現在開始，我們將不斷改進這些 Compositions，直到達到完美。

我們應該修復的第一件事是我們使用的選擇器。

資源參照與選擇器：更精準的控制

現在，讓我們回到前面，看看我們在上一章中使用的一個定義。

cat examples/$HYPERSCALER-vm.yaml

Instance 資源透過 spec.forProvider.networkInterface.networkRef 參照了 Network，並硬編碼為 dot-network。本質上，我們告訴 Crossplane，它可以從名為 dot-network 的 Network 資源中取得 Instance 所需的資訊。

這種方式雖然可行，但並不是參照資源的最佳方式。

在本章前面定義 Compositions 時，我們使用了一種更好的方法，所以讓我們再次看看我們所做的事情（以及我尚未解釋的事情）。

cat compositions/sql-v1/$HYPERSCALER.yaml

雲原生時代的資料函式庫組態：告別硬編碼，擁抱靈活參照

在雲原生架構中，如何有效地管理和組態資料函式庫資源，一直是開發者關注的焦點。傳統的硬編碼方式不僅缺乏彈性，而與容易出錯。本文將探討如何利用 Crossplane 的 Composition 功能，以更靈活、更可靠的方式管理資料函式庫資源，並分享我在實戰中積累的一些經驗與教訓。

從硬編碼到靈活參照：資料函式庫組態的演進

在早期的雲原生實踐中，我們常常使用硬編碼的方式來組態資料函式庫資源。例如，在 Kubernetes 的 YAML 檔案中，直接指定資料函式庫的名稱、版本和大小。這種方式雖然簡單直接，但也存在諸多問題。

假設我們需要建立一個 PostgreSQL 資料函式庫，並為其建立一個使用者。傳統的做法可能會是這樣：

apiVersion: sql.gcp.upbound.io/v1beta1
kind: User
metadata:
  name: my-user
spec:
  forProvider:
    instanceSelector:
      matchLabels:
        crossplane.io/composite: my-db # 硬編碼的資料函式庫名稱

這種方式的弊端顯而易見：

  • 缺乏彈性：如果我們需要更改資料函式庫的名稱，就必須修改所有參照該名稱的 YAML 檔案。
  • 容易出錯：在大型專案中，手動修改這些檔案很容易出錯，導致組態不一致。
  • 難以重用：這種組態方式難以在不同的環境中重用，例如開發、測試和生產環境。

為瞭解決這些問題，Crossplane 引入了 Composition 的概念。Composition 允許我們將多個資源組合在一起，形成一個邏輯單元，並透過參照的方式來管理這些資源。

利用 matchControllerRef 實作自動參照

Crossplane 提供了一種更簡潔、更可靠的方式來參照 Composition 內部的資源，那就是使用 matchControllerRef。這種方式不需要我們手動指定資源的名稱或標籤，而是讓 Crossplane 自動去尋找相關的資源。

以下是一個使用 matchControllerRef 的範例：

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: google-postgresql
spec:
  resources:
    - name: sql
      base:
        apiVersion: sql.gcp.upbound.io/v1beta1
        kind: DatabaseInstance
        spec:
          forProvider:
            ...
    - name: user
      base:
        apiVersion: sql.gcp.upbound.io/v1beta1
        kind: User
        spec:
          forProvider:
            ...
          instanceSelector:
            matchControllerRef: true # 自動尋找 DatabaseInstance

在這個範例中，我們將 User 資源的 instanceSelector.matchControllerRef 設定為 true。這意味著，User 資源會自動尋找同一個 Composition 內的 DatabaseInstance 資源，而不需要我們手動指定任何資訊。

玄貓認為，matchControllerRef 的優勢在於：

  • 簡化組態：我們不需要手動指定資源的名稱或標籤，減少了組態的複雜性。
  • 提高可靠性：Crossplane 會自動處理資源之間的參照關係，避免了手動組態可能導致的錯誤。
  • 增強可重用性：這種組態方式可以在不同的環境中重用，提高了組態的可維護性。

實戰經驗：matchControllerRef 的最佳實踐

在實際專案中，玄貓發現 matchControllerRef 是一種非常有效的資源參照方式。然而，要充分發揮其優勢，還需要注意以下幾點：

  • 資源命名規範：為了方便管理和除錯，我們應該為 Composition 內的資源制定統一的命名規範。
  • 標籤管理：Crossplane 會自動為資源增加一些標籤，例如 crossplane.io/composite。我們可以利用這些標籤來進行更精細的資源選擇。
  • 錯誤處理：當 Crossplane 無法找到相關的資源時，會丟擲錯誤。我們應該及時處理這些錯誤，確保系統的穩定性。

進階應用：Patching 的妙用

除了資源參照，Crossplane 還提供了 Patching 的功能，允許我們在 Composition 中修改資源的屬性。這使得我們可以根據不同的需求，定製資料函式庫的組態。

例如，我們可以定義一個 CompositeResourceDefinition，允許使用者指定資料函式庫的版本和大小：

apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
  name: sqls.devopstoolkitseries.com
spec:
  versions:
    - name: v1alpha1
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                id:
                  type: string
                  description: Database ID
                parameters:
                  type: object
                  properties:
                    version:
                      description: The DB version depends...
                      type: string
                    size:
                      description: "Supported sizes: small, medium, large"
                      type: string
                      default: small
                  required:
                    - version
                  required:
                    - parameters

在這個 CompositeResourceDefinition 中，我們定義了 version 和 size 兩個引數，允許使用者指定資料函式庫的版本和大小。接下來，我們可以利用 Patching 功能，將這些引數傳遞給底層的 DatabaseInstance 資源。具體做法將在後續的文章中詳細介紹。

總結，Crossplane 的 Composition 功能為我們提供了一種更靈活、更可靠的方式來管理雲原生環境中的資料函式庫資源。透過 matchControllerRef 和 Patching 等功能，我們可以告別硬編碼，擁抱靈活組態，從而提高開發效率，降低維運成本。

玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。