透過整合 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