透過整合 Kustomize、Helm 和 Image Updater,Argo CD 提供了一個全面的 GitOps 解決方案,能夠滿足各種複雜場景的需求:

  • 組態管理:使用 Kustomize 處理環境差異和變異性
  • **包管理

Argo CD 容器映像自動更新與私有儲存函式庫

在現代雲原生應用程式開發中,持續佈署是提高交付效率的關鍵因素。Argo CD 作為一個強大的 GitOps 工具,不僅可以幫助我們同步 Git 儲存函式庫Kubernetes 叢集,還提供了多種進階功能來自動化整個佈署流程。今天,我們將探討 Argo CD 的兩個重要功能:容器映像自動更新和從私有 Git 儲存函式庫應用程式。

容器映像自動更新的實作與驗證

在實施 Argo CD Image Updater 後,我們需要驗證它是否正常運作。從上一個部分的設定完成後,系統應該已經建立了一個標籤為 1.1.0 的新容器。這個變更會被 Argo CD Image Updater 控制器檢測到,並觸發儲存函式庫新。

讓我們檢查控制器的日誌,確認更新過程是否如預期進行:

kubectl logs argocd-image-updater-59c45cbc5c-kjjtp -f -n argocd

在日誌中,我們應該能看到類別似以下的輸出:

time="2022-06-20T21:19:05Z" level=info msg="Setting new image to quay.io/rhdevelopers/bgd:1.1.0" alias=myalias application=bgdk-app image_name=rhdevelopers/bgd image_tag=1.0.0 registry=quay.io
time="2022-06-20T21:19:05Z" level=info msg="Successfully updated image 'quay.io/rhdevelopers/bgd:1.0.0' to 'quay.io/rhdevelopers/bgd:1.1.0', but pending spec update (dry run=false)" alias=myalias application=bgdk-app image_name=rhdevelopers/bgd image_tag=1.0.0 registry=quay.io
time="2022-06-20T21:19:05Z" level=info msg="Committing 1 parameter update(s) for application bgdk-app" application=bgdk-app

這些日誌記錄展示了 Argo CD Image Updater 的工作流程。控制器首先檢測到新版本的容器映像(1.1.0),然後將應用程式設定中的映像標籤從 1.0.0 更新為 1.1.0。最後,它提交了這個變更,使 Argo CD 能夠檢測並同步新版本到叢集中。

檢查儲存函式庫我們會發現一個新的 Kustomize 檔案:.argocd-source-bgdk-app.yaml,這個檔案更新了映像值到新的容器版本。Argo CD 會檢測這個變更,並將叢集適當地更新為新的映像。

如果需要刪除應用程式,可以使用 CLI 工具或 UI 介面:

argocd app delete bgdk-app

理解映像更新策略

Argo CD Image Updater 提供多種更新策略,定義瞭如何尋找新版本。預設情況下,它使用語義版本控制來檢測最新版本。

版本限制

我們可以增加可選的版本約束欄位,以限制哪些版本可以自動更新。例如,如果只想更新修補程式版本,可以修改 image-list 註解:

argocd-image-updater.argoproj.io/image-list: myalias=quay.io/rhdevelopers/bgd:1.2.x

最新構建策略

Argo CD Image Updater 也可以更新到具有最新構建日期的映像:

argocd-image-updater.argoproj.io/myalias.update-strategy: latest
argocd-image-updater.argoproj.io/myimage.allow-tags: regexp:^[0-9a-f]{7}$

這裡的 allow-tags 設定會限制只考慮符合指定正規表示式的標籤進行更新,這對於使用提交雜湊作為標籤的情況特別有用。

摘要更新策略

摘要更新策略將使用映像摘要來更新應用程式的映像標籤:

argocd-image-updater.argoproj.io/myalias.update-strategy: digest

設定私有容器儲存函式庫若容器儲存在私有儲存函式庫Argo CD Image Updater 需要讀取許可權才能檢測變更。

首先,建立一個代表容器儲存函式庫的新 Secret:

kubectl create -n argocd secret docker-registry quayio --docker-server=quay.io --docker-username=$QUAY_USERNAME --docker-password=$QUAY_PASSWORD

然後,Argo CD Image Updater 使用 ConfigMap 作為設定來源,這是註冊私有容器儲存函式庫方:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-image-updater-config
data:
  registries.conf: |
    registries:
    - name: RedHat Quay
      api_url: https://quay.io
      prefix: quay.io
      insecure: yes
      credentials: pullsecret:argocd/quayio

這個 ConfigMap 設定了 Argo CD Image Updater 的儲存函式庫:

  • name 是一個識別儲存函式庫稱
  • api_url 是服務的 URL
  • prefix 是容器映像中使用的字首
  • credentials 指定了從 argocd 名稱空間的 quayio secret 取得憑證

自定義提交訊息

Argo CD Image Updater 提交更新時會使用預設訊息:

commit 3caf0af8b7a26de70a641c696446bbe1cd04cea8 (HEAD -> main, origin/main)
Author: argocd-image-updater <noreply@argoproj.io>
Date: Thu Jun 23 09:41:00 2022 +0000
build: automatic update of bgdk-app
updates image rhdevelopers/bgd tag '1.0.0' to '1.1.0'

我們可以透過在 argocd-image-updater-config ConfigMap 中設定 git.commit-message-template 來自定義提交訊息:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-image-updater-config
data:
  git.user: alex
  git.email: alex@example.com
  git.commit-message-template: |
    build: automatic update of {{ .AppName }}
    {{ range .AppChanges -}}
    updates image {{ .Image }} tag '{{ .OldTag }}' to '{{ .NewTag }}'
    {{ end -}}

這個設定了提交時的使用者名、電子郵件和訊息範本。範本使用 Golang 的 text/template 語法:

  • {{ .AppName }} 是應用程式的名稱
  • {{ range .AppChanges -}} 迭代更新執行的所有變更
  • {{ .Image }}{{ .OldTag }}{{ .NewTag }} 分別是映像名稱、先前容器標籤和新容器標籤

更新 ConfigMap 後,記得重新啟動 Argo CD Image Updater 控制器:

kubectl rollout restart deployment argocd-image-updater -n argocd

從私有 Git 儲存函式庫

在企業環境中,大多數程式碼和佈署清單都儲存在私有 Git 儲存函式庫Argo CD 提供了多種方法來存取這些私有儲存函式庫

註冊私有 Git 儲存函式庫在 Argo CD 中,有兩種方式註冊帶有憑證的 Git 儲存函式庫用 Argo CD CLI/UI 工具或使用 YAML 檔案。

使用 Argo CD CLI 註冊

使用者名和密碼註冊私有儲存函式庫

argocd repo add https://github.com/argoproj/argocd-example-apps \
  --username <username> --password <password>

使用 Argo CD UI 註冊

  1. 在瀏覽器中開啟 Argo CD UI
  2. 點選「Settings/Repositories」按鈕(帶齒輪圖示的按鈕)
  3. 點選「Connect Repo using HTTPS」按鈕
  4. 填寫表格,輸入必要的資料
  5. 點選「Connect」按鈕測試連線並將儲存函式庫到 Argo CD

使用 Kubernetes Secret 註冊

另一種方法是建立包含儲存函式庫證訊息的 Kubernetes Secret:

apiVersion: v1
kind: Secret
metadata:
  name: private-repo
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  type: git
  url: https://github.com/argoproj/private-repo
  password: my-password
  username: my-username

這個 Secret 設定了一個私有 Git 儲存函式庫證資訊:

  • metadata.namespace 必須是 argocd,以便 Argo CD 能夠存取它
  • 標籤 argocd.argoproj.io/secret-type: repository 告訴 Argo CD 這是一個儲存函式庫
  • stringData.url 是要註冊的儲存函式庫RL
  • stringData.usernamestringData.password 是存取憑證

應用此檔案後,效果與手動方法相同。當我們在 Application 資源的 repoURL 值中使用已註冊認證的儲存函式庫RL 時,Argo CD 將使用註冊的憑證登入。

支援的認證方式

除了使用者名和密碼外,Argo CD 還支援其他認證方法,如令牌、TLS 客戶端證書、SSH 私鑰或 GitHub App 憑證。

使用 TLS 客戶端證書

argocd repo add https://repo.example.com/repo.git \
  --tls-client-cert-path ~/mycert.crt \
  --tls-client-cert-key-path ~/mycert.key

使用 SSH 私鑰

argocd repo add git@github.com:argoproj/argocd-example-apps.git \
  --ssh-privatekey-path ~/.ssh/id_rsa

或使用 Kubernetes Secret:

apiVersion: v1
kind: Secret
metadata:
  name: private-repo
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  type: git
  url: git@github.com:argoproj/my-private-repository
  sshPrivateKey: |
    -----BEGIN OPENSSH PRIVATE KEY-----
    ...
    -----END OPENSSH PRIVATE KEY-----

使用 GitHub App 認證

透過 CLI 設定 GitHub App 認證:

argocd repo add https://github.com/argoproj/argocd-example-apps.git --github-app-id 1 --github-app-installation-id 2 --github-app-private-key-path test.private-key.pem

或使用宣告式方法:

apiVersion: v1
kind: Secret
metadata:
  name: github-repo
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  type: git
  repo: https://ghe.example.com/argoproj/my-private-repository
  githubAppID: 1
  githubAppInstallationID: 2
  githubAppEnterpriseBaseUrl: https://ghe.example.com/api/v3
  githubAppPrivateKeySecret: |
    -----BEGIN OPENSSH PRIVATE KEY-----
    ...
    -----END OPENSSH PRIVATE KEY-----

這些設定範例展示了 Argo CD 支援的不同認證方法:

  • TLS 客戶端證書:適用於需要雙向 TLS 驗證的儲存函式庫 SSH 私鑰:適用於透過 SSH 協定存取的儲存函式庫別是在不能使用 HTTPS 的環境中
  • GitHub App 認證:提供比個人存取令牌更精細的許可權控制,是存取 GitHub 儲存函式庫薦方式

Argo CD 安全最佳實踐

在設定 Argo CD 與私有儲存函式庫像登入檔整合時,有幾個安全最佳實踐值得注意:

  1. 最小許可權原則:為 Argo CD 提供的憑證應僅具有最小必要許可權,通常只需要讀取許可權
  2. 定期輪換憑證:設定流程定期更新所有儲存函式庫

Argo CD 中的 Kubernetes 資源管理與佈署順序控制

在實際的 Kubernetes 環境中,應用程式佈署順序經常是成功與否的關鍵因素。例如,資料函式庫在應用程式之前佈署,或者某些初始化工作需要在主應用程式啟動前完成。Argo CD 提供了強大的機制來控制這些佈署順序,這在複雜的微服務架構中尤為重要。

Argo CD 的預設佈署順序

當使用 Argo CD 佈署 Kubernetes 資源時,它會依照一個預設順序來應用這些資源。這個順序根據以下邏輯:

  1. 依據資源類別

    • Namespaces(名稱空間)
    • NetworkPolicy(網路政策)
    • LimitRange(資源限制範圍)
    • ServiceAccount(服務帳號)
    • Secret(機密資訊)
    • ConfigMap(設定對映)
    • StorageClass(儲存類別)
    • PersistentVolumes(永久儲存卷)
    • ClusterRole(叢集角色)
    • Role(角色)
    • Service(服務)
    • 守護程式集合(守護程式集)
    • Pod(容器組)
    • ReplicaSet(副本集)
    • Deployment(佈署)
    • 有狀態集合(有狀態集)
    • 工作(任務)
    • Ingress(入口)
  2. 相同類別中:依照名稱的字母順序進行佈署

然而,這個預設順序可能無法滿足所有應用程式的需求。例如,當你需要在應用程式佈署後執行資料函式庫,或是在佈署完成後執行測試等情況。

如何自訂佈署順序

Argo CD 提供了兩種主要方式來控制資源的佈署順序:

  1. 同步波次(Sync Waves):透過設定波次數值來排序資源
  2. 資源鉤子(Resource Hooks):在不同階段執行特定操作

同步階段與鉤子類別

Argo CD 在佈署過程中有三個主要階段:

  1. PreSync:在應用資源清單之前執行
  2. Sync:應用資源清單的過程
  3. PostSync:在所有資源同步成功後執行

鉤子與同步波次示意圖

以下是可用的資源鉤子類別:

鉤子類別說明使用場景
PreSync在佈署資源清單前執行資料函式庫
Sync與資源清單同時執行複雜的滾動更新策略,如金絲雀發布或暗啟動
PostSync在所有 Sync 鉤子成功(健康)完成後執行執行測試以驗證佈署是否正確
SyncFail在同步操作失敗時執行失敗時的回復操作
Skip跳過資源清單的應用需要手動步驟來佈署應用時(如釋放公共流量到新版本)

使用同步波次控制佈署順序

同步波次是 Argo CD 控制資源佈署順序的強大機制。預設情況下,所有資源的波次值為零,數值較小的波次會先被佈署。

如何設定同步波次

使用 argocd.argoproj.io/sync-wave 註解來設定資源的波次數值:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgresql
  namespace: todo
  annotations:
    argocd.argoproj.io/sync-wave: "0"
...
apiVersion: batch/v1
kind: 工作
metadata:
  name: todo-table
  namespace: todo
  annotations:
    argocd.argoproj.io/sync-wave: "1"
...

上面的例子中,PostgreSQL 佈署會先執行(波次 0),然後才會執行建立資料函式庫作業(波次 1)。

鉤子的刪除策略

預設情況下,鉤子資源(如 工作)在完成後不會被自動刪除。如果需要自動清理這些資源,可以使用 argocd.argoproj.io/hook-delete-policy 註解:

apiVersion: batch/v1
kind: 工作
metadata:
  name: todo-insert
  annotations:
    argocd.argoproj.io/hook: PostSync
    argocd.argoproj.io/hook-delete-policy: HookSucceeded
...

支援的刪除策略有:

策略說明
HookSucceeded鉤子成功後刪除
HookFailed鉤子失敗後刪除
BeforeHookCreation在建立新的鉤子之前刪除

實際案例:佈署 Todo 應用程式

讓我們來看一個更具體的例子:佈署一個連線 PostgreSQL 資料函式庫Todo 應用程式。佈署順序非常重要:

  1. 首先佈署 PostgreSQL 資料函式庫. 建立資料函式庫(表格)
  2. 佈署 Todo 應用程式
  3. 插入一些預設的 Todo 專案

Todo 應用佈署流程

建立 Argo CD 應用程式

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: todo-app
  namespace: argocd
spec:
  destination:
    namespace: todo
    server: https://kubernetes.default.svc
  project: default
  source:
    path: ch07/todo
    repoURL: https://github.com/gitops-cookbook/gitops-cookbook-sc.git
    targetRevision: main
  syncPolicy:
    automated:
      prune: true
      selfHeal: false
    syncOptions:
      - CreateNamespace=true

這個 YAML 定義了一個 Argo CD 的 Application 資源,指向 GitHub 倉函式庫 ch07/todo 目錄。它設定了自動同步策略(automated),啟用了 prune 選項(刪除不再存在於 Git 中的資源),並且在同步時自動建立名稱空間(CreateNamespace=true)。應用程式將佈署到 todo 名稱空間中。

當你應用這個設定後,Argo CD 會按照指定的順序佈署所有資源。

設定同步時間視窗

在生產環境中,控制何時允許佈署是非常重要的。例如,你可能希望只在非工作時間或維護視窗期間進行佈署,以減少對使用者的影響。Argo CD 提供了同步時間視窗功能來解決這個需求。

什麼是同步時間視窗?

同步時間視窗(Sync Windows)是 Argo CD 中的一個概念,用於設定應用程式同步的時間段,可以設定為允許(allow)或阻止(deny)同步。

如何定義同步時間視窗

同步時間視窗透過 AppProject 資源進行定義,需要設定以下內容:

  1. 類別:允許(allow)或阻止(deny)
  2. 排程:使用 cron 格式定義初始時間
  3. 持續時間:時間視窗的持續時長
  4. 適用範圍:指定適用的應用程式、名稱空間或叢集

Cron 表示式說明

Cron 表示式代表一個時間點,由以下欄位組成:

┌────────── 分鐘 (0 - 59)
│ ┌────────── 小時 (0 - 23)
│ │ ┌────────── 月份中的日 (1 - 31)
│ │ │ ┌────────── 月份 (1 - 12)
│ │ │ │ ┌────────── 星期中的日 (0 - 6)
* * * * *

時間視窗設定範例

以下是一個只允許在每天晚上 22:00 到 23:00 之間同步名稱以 -prod 結尾的應用程式的設定:

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: default
spec:
  syncWindows:
  - kind: allow
    schedule: '0 22 * * *'
    duration: 1h
    applications:
    - '*-prod'

這個設定建立了一個同步時間視窗,類別為 allow(允許),排程為 0 22 * * *(每天晚上 10 點整),持續時間為 1 小時。它只適用於名稱符合 *-prod 模式的應用程式,意味著只有那些以 -prod 結尾的應用程式才能在這個時間視窗內同步。

更複雜的時間視窗設定

你可以同時設定多個時間視窗,組合使用允許和阻止類別:

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: default
  namespace: argocd
spec:
  syncWindows:
  - kind: deny
    schedule: '0 22 * * *'
    duration: 1h
    manualSync: true
    namespaces:
    - bgd
  - kind: allow
    schedule: '0 23 * * *'
    duration: 1h
    clusters:
    - prod-cluster

這個設定建立了兩個同步時間視窗:

  1. 第一個視窗阻止(deny)在每晚 22:00 開始的一小時內對 bgd 名稱空間進行自動同步,但允許手動同步(manualSync: true)。
  2. 第二個視窗允許(allow)在每晚 23:00 開始的一小時內對 prod-cluster 叢集進行同步。

檢視當前的時間視窗

你可以透過 Argo CD UI 或 CLI 工具檢視當前的時間視窗:

argocd proj windows list default

輸出類別似於:

ID  STATUS   KIND  SCHEDULE    DURATION  APPLICATIONS  NAMESPACES  CLUSTERS     MANUALSYNC
0   Inactive deny  0 22 * * *  1h        -             bgd         -            Enabled
1   Inactive allow 0 23 * * *  1h        -             -           prod-cluster Disabled

啟用手動同步

當應用程式處於禁止同步的時間視窗時,你可能仍然需要在緊急情況下進行手動同步。Argo CD 允許你啟用手動同步選項:

使用 CLI 工具:

argocd proj windows enable-manual-sync <PROJECT ID>

或者在 YAML 設定中設定:

- kind: deny
  schedule: '0 22 * * *'
  duration: 1h
  manualSync: true
  namespaces:
  - bgd

實際應用與最佳實踐

在實際使用 Argo CD 控制佈署順序和時間視窗時,我發現以下做法特別有效:

同步波次最佳實踐

  1. 使用簡單的數字系統:對於大多數應用,使用 0, 10, 20, 30… 的波次數值,這樣在需要時可以在中間插入新的波次。

  2. 按功能分組波次

    • 基礎設施資源(名稱空間、儲存類別等):波次 0
    • 資料儲存(資料函式庫取等):波次 10
    • 後端服務:波次 20
    • 前端應用:波次 30
    • 初始化作業和測試:波次 40-50
  3. 保持波次一致性:在所有應用程式中保持一致的波次設計,這樣團隊成員更容易理解和維護。

時間視窗最佳實踐

  1. 區分環境:為不同環境(開發、測試、生產)設定不同的時間視窗策略。

  2. 結合監控系統:將佈署時間與系統使用低峰期對齊,可以透過分析監控資料來確定最佳佈署時間。

  3. 預留緩衝時間:為佈署和可能的回復預留足夠的時間,不要將時間視窗設定得太短。

  4. 檔案化時間視窗策略:確保所有團隊成員瞭解佈署時間視窗,避免在關鍵業務時間意外佈署。

Argo CD 佈署順序與時間控制的進階技巧

在管理大型微服務架構時,

安全與自動化的完美結合:DevSecOps與GitOps實踐

在現代技術環境中,安全不再是事後的考量,而是整個IT生命週期中的共同責任。DevSecOps作為一種新興方法,將安全整合到DevOps流程中,強調「安全即程式碼」的理念,以減少摩擦並提供更大價值。這與GitOps的原則完美契合,兩者都推崇宣告式的方法來管理基礎設施和應用程式。

然而,這種方法也帶來了一個關鍵問題:如何避免在Git中儲存未加密的明文憑證?這不僅是一個技術問題,更是安全實踐的核心挑戰。

GitOps中的安全管理模式

在GitOps工作流程中,Argo CD提供了兩種主要的安全管理模式:

  1. 在Git中儲存加密後的敏感資料 - 例如使用Sealed Secrets
  2. 在外部服務或金鑰管理系統中儲存敏感資料 - 只在Git中儲存對這些敏感資料的參考

這兩種模式各有優缺點,適用於不同的場景和安全需求。在本文中,玄貓將探討這些方法,並提供實際的實施。

Sealed Secrets:安全地在Git中管理敏感資料

問題背景

在實施GitOps時,我們面臨一個關鍵挑戰:如何在Git儲存函式庫全地管理Kubernetes Secrets和其他敏感資料?

Sealed Secrets解決方案

Sealed Secrets是由Bitnami開發的開放原始碼專案,它能將Kubernetes Secrets加密成SealedSecret自訂資源,使其可以安全地儲存在Git中。這種方法完美解決了GitOps與安全性的衝突。

核心元件與運作原理

Sealed Secrets使用公鑰加密技術,主要由兩個部分組成:

  1. Kubernetes控制器:掌握用於加密和解密的私鑰和公鑰,負責協調加密的秘密。控制器還支援自動私鑰輪換和金鑰到期管理,以強制重新加密秘密。

  2. kubeseal CLI:開發人員使用的命令列工具,用於在提交到Git儲存函式庫密秘密。

SealedSecret物件僅能由目標Kubernetes叢集中執行的SealedSecret控制器加密和解密,確保了最高階別的安全性。kubeseal CLI允許開發人員將普通的Kubernetes Secret資源轉換為SealedSecret資源定義。

實作Sealed Secrets

以下是在Kubernetes叢集中實作Sealed Secrets的步驟:

1. 安裝kubeseal CLI

首先,我們需要為您的作業系統安裝kubeseal CLI。在撰寫本文時,我使用的是0.18.2版本。

對於macOS使用者,可以透過Homebrew安裝:

brew install kubeseal

2. 安裝Sealed Secrets控制器

接下來,在Kubernetes叢集中安裝控制器:

kubectl create -f https://github.com/bitnami-labs/sealed-secrets/releases/download/0.18.2/controller.yaml

成功安裝後,您將看到類別似以下的輸出:

serviceaccount/sealed-secrets-controller created
deployment.apps/sealed-secrets-controller created
customresourcedefinition.apiextensions.k8s.io/sealedsecrets.bitnami.com created
service/sealed-secrets-controller created
rolebinding.rbac.authorization.k8s.io/sealed-secrets-controller created
rolebinding.rbac.authorization.k8s.io/sealed-secrets-service-proxier created
role.rbac.authorization.k8s.io/sealed-secrets-service-proxier created
role.rbac.authorization.k8s.io/sealed-secrets-key-admin created
clusterrolebinding.rbac.authorization.k8s.io/sealed-secrets-controller created
clusterrole.rbac.authorization.k8s.io/secrets-unsealer created

3. 建立並加密Secret

作為範例,讓我們為Pac-Man遊戲建立一個Secret:

kubectl create secret generic pacman-secret \
  --from-literal=user=pacman \
  --from-literal=pass=pacman

您將看到輸出:secret/pacman-secret created

以下是這個Secret的YAML表示:

apiVersion: v1
data:
  pass: cGFjbWFu
  user: cGFjbWFu
kind: Secret
metadata:
  name: pacman-secret
  namespace: default
type: Opaque

4. 轉換Secret為SealedSecret

現在,我們可以使用kubeseal將Secret轉換為SealedSecret:

kubectl get secret pacman-secret -o yaml | kubeseal -o yaml > pacman-sealedsecret.yaml

生成的SealedSecret檔案內容如下:

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  creationTimestamp: null
  name: pacman-secret
  namespace: default
spec:
  encryptedData:
    pass: AgBJR1AgZ5Gu5NOVsG1E8SKBcdB3QSDdzZka3RRYuWV7z8g7ccQ0dGc1suVOP8wX/ZpPmIMp8+urPYG62k4E
          ZRUjuu/Vg2E1nSbsGBh9eKu3NaO6tGSF3eGk6PzN6XtRhDeER4u7MG5pj/+FXRAKcy8Z6RfzbVEGq/QJQ4z0
          ecSNdJmG07ERMm1Q+lPNGvph2Svx8aCgFLqRsdLhFyvwbTyB3XnmFHrPr+2DynxeN8XVMoMkRYXgVc6GAoxU
          K7CnC3Elpuy7lIdPwc5QBx9kUVfra83LX8/KxeaJwyCqvscIGjtcxUtpTpF5jm1t1DSRRNbc4m+7pTwTmnRi
          UuaMVeujaBco4521yTkh5iEPjnjvUt+VzK01NVoeNunqIazp15rFwTvmiQ5PAtbiUXpT733zCr60QBgSxPg3
          1vw98+u+RcIHvaMIoDCqaXxUdcn2JkUF+bZXtxNmIRTAiQVQ1vEPmrZxpvZcUh/PPC4L/RFWrQWnOzKRyqLq
          9wRoSLPbKyvMXnaxH0v3USGIktmtJlGjlXoW/i+HIoSeMFS0mUAzOF5M5gweOhtxKGh3Y74ZDn5PbVA/9kbk
          uWgvPNGDZL924Dm6AyM5goHECr/RRTm1e22K9BfPASARZuGA6paqb9h1XEqyqesZgM0R8PLiyLuu+tpqydR0
          SiYLc5VltdjzpIyyy9Xmw6Aa3/4SB+4tSwXSUUrB5yc=
    user: AgBhYDZQzOwinetPceZL897aibTYp4QPGFvP6ZhDyuUAxOWXBQ7jBA3KPUqLvP8vBcxLAcS7HpKcDSgCdi47
          D2WhShdBR4jWJufwKmR3j+ayTdw72t3ALpQhTYI0iMYTiNdR0/o3vf0jeNMt/oWCRsifqBxZaIShE53rAFEj
          EA6D7CuCDXu8BHk1DpSr79d5Au4puzpHVODh+v1T+Yef3k7DUoSnbYEh3CvuRweiuq5lY8G0oob28j38wdyx
          m3GIrexa+M/ZIdO1hxZ6jz4edv6ejdZfmQNdru3c6lmljWwcO+0Ue0MqFi4ZF/YNUsiojI+781n1m3K/giKc
          yPLn0skD7DyeKPoukoN6W5P71OuFSkF+VgIeejDaxuA7bK3PEaUgv79KFC9aEEnBr/7op7HY7X6aMDahmLUc
          /+zDhfzQvwnC2wcj4B8M2OBFa2ic2PmGzrIWhlBbs1OgnpehtGSETq+YRDH0alWOdFBq1U8qn6QA8Iw6ewu8
          GTele3zlPLaADi5O6LrJbIZNlY0+PutWfjs9ScVVEJy+I9BGdyT6tiA/4v4cxH6ygG6NzWkqxSaYyNrWWXtL
          hOlqyCpTZtUwHnF+OLB3gCpDZPx+NwTe2Kn0jY0c83LuLh5PJ090AsWWqZaRQyELeL6y6mVekQFWHGfK6t57
          Vb7Z3+5XJCgQn+xFLkj3SIz0ME5D4+DSsUDS1fyL8uI=
  template:
    data: null
    metadata:
      creationTimestamp: null
      name: pacman-secret
      namespace: default
    type: Opaque

這裡可以看到data部分已經被加密,只有Sealed Secrets控制器可以解密。這種加密機制使用非對稱加密,確保即使SealedSecret被公開,其內容也不會洩露。加密的資料包含兩個部分:

  1. pass:加密後的密碼
  2. user:加密後的使用者名稱

這些加密資料只能由特定Kubernetes叢集中的Sealed Secrets控制器解密,提供了強大的安全保障。

5. 使用Argo CD佈署SealedSecret

現在,您可以安全地將SealedSecret推播到Kubernetes清單倉函式庫建立Argo CD應用程式:

argocd app create pacman \
  --repo https://github.com/gitops-cookbook/pacman-kikd-manifests.git \
  --path 'k8s/sealedsecrets' \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace default \
  --sync-policy auto

檢查應用程式是否正在執行與健康:

argocd app list

您應該會看到類別似以下的輸出:

NAME    CLUSTER                         NAMESPACE  PROJECT  STATUS  HEALTH   SYNCPOLICY  CONDITIONS  REPO                                                 PATH               TARGET
pacman  https://kubernetes.default.svc  default    default  Synced  Healthy  <none>      <none>      https://github.com/gitops-cookbook/pacman-kikd-manifests.git  k8s/sealedsecrets