透過整合 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是服務的 URLprefix是容器映像中使用的字首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 註冊
- 在瀏覽器中開啟 Argo CD UI
- 點選「Settings/Repositories」按鈕(帶齒輪圖示的按鈕)
- 點選「Connect Repo using HTTPS」按鈕
- 填寫表格,輸入必要的資料
- 點選「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是要註冊的儲存函式庫RLstringData.username和stringData.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 與私有儲存函式庫像登入檔整合時,有幾個安全最佳實踐值得注意:
- 最小許可權原則:為 Argo CD 提供的憑證應僅具有最小必要許可權,通常只需要讀取許可權
- 定期輪換憑證:設定流程定期更新所有儲存函式庫
Argo CD 中的 Kubernetes 資源管理與佈署順序控制
在實際的 Kubernetes 環境中,應用程式佈署順序經常是成功與否的關鍵因素。例如,資料函式庫在應用程式之前佈署,或者某些初始化工作需要在主應用程式啟動前完成。Argo CD 提供了強大的機制來控制這些佈署順序,這在複雜的微服務架構中尤為重要。
Argo CD 的預設佈署順序
當使用 Argo CD 佈署 Kubernetes 資源時,它會依照一個預設順序來應用這些資源。這個順序根據以下邏輯:
-
依據資源類別:
- Namespaces(名稱空間)
- NetworkPolicy(網路政策)
- LimitRange(資源限制範圍)
- ServiceAccount(服務帳號)
- Secret(機密資訊)
- ConfigMap(設定對映)
- StorageClass(儲存類別)
- PersistentVolumes(永久儲存卷)
- ClusterRole(叢集角色)
- Role(角色)
- Service(服務)
- 守護程式集合(守護程式集)
- Pod(容器組)
- ReplicaSet(副本集)
- Deployment(佈署)
- 有狀態集合(有狀態集)
- 工作(任務)
- Ingress(入口)
-
相同類別中:依照名稱的字母順序進行佈署
然而,這個預設順序可能無法滿足所有應用程式的需求。例如,當你需要在應用程式佈署後執行資料函式庫,或是在佈署完成後執行測試等情況。
如何自訂佈署順序
Argo CD 提供了兩種主要方式來控制資源的佈署順序:
- 同步波次(Sync Waves):透過設定波次數值來排序資源
- 資源鉤子(Resource Hooks):在不同階段執行特定操作
同步階段與鉤子類別
Argo CD 在佈署過程中有三個主要階段:
- PreSync:在應用資源清單之前執行
- Sync:應用資源清單的過程
- 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 應用程式。佈署順序非常重要:
- 首先佈署 PostgreSQL 資料函式庫. 建立資料函式庫(表格)
- 佈署 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 資源進行定義,需要設定以下內容:
- 類別:允許(allow)或阻止(deny)
- 排程:使用 cron 格式定義初始時間
- 持續時間:時間視窗的持續時長
- 適用範圍:指定適用的應用程式、名稱空間或叢集
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
這個設定建立了兩個同步時間視窗:
- 第一個視窗阻止(
deny)在每晚 22:00 開始的一小時內對bgd名稱空間進行自動同步,但允許手動同步(manualSync: true)。 - 第二個視窗允許(
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 控制佈署順序和時間視窗時,我發現以下做法特別有效:
同步波次最佳實踐
-
使用簡單的數字系統:對於大多數應用,使用 0, 10, 20, 30… 的波次數值,這樣在需要時可以在中間插入新的波次。
-
按功能分組波次:
- 基礎設施資源(名稱空間、儲存類別等):波次 0
- 資料儲存(資料函式庫取等):波次 10
- 後端服務:波次 20
- 前端應用:波次 30
- 初始化作業和測試:波次 40-50
-
保持波次一致性:在所有應用程式中保持一致的波次設計,這樣團隊成員更容易理解和維護。
時間視窗最佳實踐
-
區分環境:為不同環境(開發、測試、生產)設定不同的時間視窗策略。
-
結合監控系統:將佈署時間與系統使用低峰期對齊,可以透過分析監控資料來確定最佳佈署時間。
-
預留緩衝時間:為佈署和可能的回復預留足夠的時間,不要將時間視窗設定得太短。
-
檔案化時間視窗策略:確保所有團隊成員瞭解佈署時間視窗,避免在關鍵業務時間意外佈署。
Argo CD 佈署順序與時間控制的進階技巧
在管理大型微服務架構時,
安全與自動化的完美結合:DevSecOps與GitOps實踐
在現代技術環境中,安全不再是事後的考量,而是整個IT生命週期中的共同責任。DevSecOps作為一種新興方法,將安全整合到DevOps流程中,強調「安全即程式碼」的理念,以減少摩擦並提供更大價值。這與GitOps的原則完美契合,兩者都推崇宣告式的方法來管理基礎設施和應用程式。
然而,這種方法也帶來了一個關鍵問題:如何避免在Git中儲存未加密的明文憑證?這不僅是一個技術問題,更是安全實踐的核心挑戰。
GitOps中的安全管理模式
在GitOps工作流程中,Argo CD提供了兩種主要的安全管理模式:
- 在Git中儲存加密後的敏感資料 - 例如使用Sealed Secrets
- 在外部服務或金鑰管理系統中儲存敏感資料 - 只在Git中儲存對這些敏感資料的參考
這兩種模式各有優缺點,適用於不同的場景和安全需求。在本文中,玄貓將探討這些方法,並提供實際的實施。
Sealed Secrets:安全地在Git中管理敏感資料
問題背景
在實施GitOps時,我們面臨一個關鍵挑戰:如何在Git儲存函式庫全地管理Kubernetes Secrets和其他敏感資料?
Sealed Secrets解決方案
Sealed Secrets是由Bitnami開發的開放原始碼專案,它能將Kubernetes Secrets加密成SealedSecret自訂資源,使其可以安全地儲存在Git中。這種方法完美解決了GitOps與安全性的衝突。
核心元件與運作原理
Sealed Secrets使用公鑰加密技術,主要由兩個部分組成:
-
Kubernetes控制器:掌握用於加密和解密的私鑰和公鑰,負責協調加密的秘密。控制器還支援自動私鑰輪換和金鑰到期管理,以強制重新加密秘密。
-
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被公開,其內容也不會洩露。加密的資料包含兩個部分:
pass:加密後的密碼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