最佳實務

在本節中，您將學習如何設定 cert-manager 以符合熱門的安全標準，例如 CIS Kubernetes Benchmark、NSA Kubernetes 硬化指南或 BSI Kubernetes 安全建議。

您也將學習在生產環境中部署 cert-manager 的最佳實務；例如 Datree 及其內建規則等工具所強制執行的實務，以及 Learnk8s 在其「Kubernetes 生產環境最佳實務」清單中記錄的實務。

概觀

Helm 圖表或 YAML 資訊清單中的預設 cert-manager 資源 (部署、Pod、ServiceAccount 等) 設計用於回溯相容性，而不是最佳實務或最大安全性。您可能會發現預設資源不符合 Kubernetes 叢集上的安全原則，在這種情況下，您可以使用 Helm 圖表值修改安裝組態，以覆寫預設值。

網路需求和網路原則

下方摘要說明每個 cert-manager Pod 的網路需求。某些網路需求取決於特定的 Issuer/ClusterIssuer 設定和/或特定的組態選項。

當您了解您的 cert-manager 安裝的網路需求後，您應該考慮實作「最小權限」網路原則，使用 Kubernetes 網路 (CNI) 外掛程式，例如 Calico。

網路原則應該防止不受信任的用戶端連線至 cert-manager Pod，並且應該防止 cert-manager 連線至不受信任的伺服器。

在 Calico 文件中可以找到此建議的範例

我們建議為您的 Kubernetes Pod 建立隱含的預設拒絕原則，無論您使用 Calico 或 Kubernetes 網路原則。這可確保預設會拒絕不必要的流量。

📖 Calico 最佳實務：隱含的預設拒絕原則。

您可以使用 Kubernetes 內建的 NetworkPolicy 資源，因為任何 Kubernetes 網路 (CNI) 外掛程式都可以識別該資源。或者，您可能偏好使用 CNI 軟體提供的自訂資源。

📖 了解 Kubernetes 內建 NetworkPolicy API，並查看一些範例原則。

網路需求

以下是網路需求的概觀

UDP/TCP：cert-manager (全部) -> Kubernetes DNS：所有 cert-manager 元件都會針對叢集和外部網域名稱執行 UDP DNS 查詢。某些 DNS 查詢可能會使用 TCP。
TCP：Kubernetes (API 伺服器) -> cert-manager (webhook)：Kubernetes API 伺服器會與 cert-manager webhook 元件建立 HTTPS 連線。請閱讀 cert-manager webhook 疑難排解指南，以了解 webhook 網路需求。
TCP：cert-manager (webhook、controller、cainjector、startupapicheck) -> Kubernetes API 伺服器：cert-manager webhook、controller、cainjector 和 startupapicheck 會與 Kubernetes API 伺服器建立 HTTPS 連線，以與 cert-manager 自訂資源和 Kubernetes 資源互動。cert-manager webhook 是一種特殊情況；它會連線至 Kubernetes API 伺服器，以使用 SubjectAccessReview API 來驗證嘗試修改 CertificateRequest 資源的 Approved 或 Denied 條件的用戶端。
TCP：cert-manager (controller) -> HashiCorp Vault (驗證和資源 API 端點)：如果您使用 Vault Issuer，cert-manager controller 可能會與一或多個 Vault API 端點建立 HTTPS 連線。Vault 端點的目標主機和連接埠是在 Issuer 或 ClusterIssuer 資源中設定的。
TCP：cert-manager (controller) -> Venafi TLS Protect (驗證和資源 API 端點)：如果您使用 Venafi Issuer，cert-manager controller 可能會與一或多個 Venafi API 端點建立 HTTPS 連線。Venafi API 端點的目標主機和連接埠是在 Issuer 或 ClusterIssuer 資源中設定的。
TCP：cert-manager (controller) -> DNS API 端點 (適用於 ACME DNS01)：如果您使用具有 DNS01 解題器的 ACME Issuer，cert-manager controller 可能會與 DNS API 端點 (例如 Amazon Route53) 和任何相關的驗證端點建立 HTTPS 連線。
UDP/TCP：cert-manager (controller) -> 外部 DNS：如果您使用 ACME Issuer，cert-manager controller 可能會將 DNS 查詢傳送至遞迴 DNS 伺服器，做為 ACME 挑戰自我檢查程序的一部分。這麼做的目的是確保在要求 ACME 伺服器執行檢查之前，可以解析 DNS01 或 HTTP01 挑戰。

在 DNS01 的情況下，它也可能會執行一系列對授權 DNS 伺服器的 DNS 查詢，以計算要在其中新增 DNS01 挑戰記錄的 DNS 區域。在 DNS01 的情況下，cert-manager 也支援透過 HTTPS 的 DNS。

您可以使用下列控制器標幟來選擇 DNS 伺服器的主機和連接埠：--acme-http01-solver-nameservers、--dns01-recursive-nameservers 和 --dns01-recursive-nameservers-only。
TCP：ACME (Let's Encrypt) -> cert-manager (acmesolver)：如果您使用針對 HTTP01 設定的 ACME Issuer，cert-manager 會在 Issuer 的命名空間中或在 cert-manager 命名空間中 (如果它是 ClusterIssuer) 部署 acmesolver Pod、服務和 Ingress (或閘道 API) 資源。ACME 實作會透過您選擇的輸入負載平衡器與此 Pod 建立 HTTP 連線，因此您的網路原則必須允許這麼做。

ℹ️ acmesolver Pod 不需要存取 Kubernetes API 伺服器。
TCP：度量伺服器 -> cert-manager (controller)：cert-manager controller 具有度量伺服器，該伺服器會在 TCP 連接埠 9402 上接聽 HTTP 連線。建立允許從您選擇的度量收集器存取此服務的網路原則。

在專用節點集區中隔離 cert-manager

cert-manager 是一個叢集範圍的運算子，您應該將其視為平台控制平面的一部分。cert-manager controller 會建立和修改 Kubernetes Secret 資源，而且 controller 和 cainjector 都會在記憶體中快取 TLS Secret 資源。這兩個原因說明您應該考慮將 cert-manager 元件與其他權限較低的工作負載隔離。例如，如果不受信任或惡意的工作負載與 cert-manager controller 在同一個節點上執行，而且不知何故取得基礎節點的根存取權，則它可能可以讀取 controller 在記憶體中快取的 Secret 中的私密金鑰。

您可以透過在保留給受信任平台運算子的節點上執行 cert-manager 來降低此風險。

cert-manager 的 Helm 圖表具有參數，可設定每個元件的 Pod tolerations 和 nodeSelector。這些參數的確切值取決於您的特定叢集。

📖 請閱讀將 Pod 指派給節點中的Kubernetes 文件。

📖 請閱讀 Taints and Tolerations 中的Kubernetes 文件。

範例

這個範例示範如何使用：taints 來排斥非平台 Pod 在您為平台控制平面預留的節點上執行；使用 tolerations 來允許 cert-manager Pod 在這些節點上執行；以及使用 nodeSelector 來將 cert-manager Pod 放置在這些節點上。

標記節點

kubectl label node ... node-restriction.kubernetes.io/reserved-for=platform

污損節點

kubectl taint node ... node-restriction.kubernetes.io/reserved-for=platform:NoExecute

然後使用以下 Helm chart 值安裝 cert-manager

nodeSelector:
  kubernetes.io/os: linux
  node-restriction.kubernetes.io/reserved-for: platform
tolerations:
- key: node-restriction.kubernetes.io/reserved-for
  operator: Equal
  value: platform

webhook:
  nodeSelector:
    kubernetes.io/os: linux
    node-restriction.kubernetes.io/reserved-for: platform
  tolerations:
  - key: node-restriction.kubernetes.io/reserved-for
    operator: Equal
    value: platform

cainjector:
  nodeSelector:
    kubernetes.io/os: linux
    node-restriction.kubernetes.io/reserved-for: platform
  tolerations:
  - key: node-restriction.kubernetes.io/reserved-for
    operator: Equal
    value: platform

startupapicheck:
  nodeSelector:
    kubernetes.io/os: linux
    node-restriction.kubernetes.io/reserved-for: platform
  tolerations:
  - key: node-restriction.kubernetes.io/reserved-for
    operator: Equal
    value: platform

ℹ️ 這個範例使用 nodeSelector 來放置 Pod，但您也可以使用 affinity.nodeAffinity。這裡選擇 nodeSelector 是因為它的語法更簡單。

ℹ️ 預設的 nodeSelector 值 kubernetes.io/os: linux 避免在混合作業系統叢集中將 cert-manager Pod 放置在 Windows 節點上，因此這裡也必須明確包含它。

📖 請閱讀在 EKS 最佳實務指南中將租戶工作負載隔離到特定節點的指南，以深入了解這些技術。

📖 了解如何在 Google Kubernetes Engine 上將工作負載隔離在專用節點池中。

📖 了解如何使用節點選擇器將 Pod 放置在特定節點上，使用 RedHat OpenShift。

📖 閱讀更多關於 node-restriction.kubernetes.io/ 前綴和 NodeRestriction 准入外掛程式。

ℹ️ 在多租戶叢集上，考慮啟用 PodTolerationRestriction 外掛程式，以限制租戶可以將哪些容忍度添加到其 Pod。您也可以使用該外掛程式將預設容忍度添加到 cert-manager 命名空間，這樣就不需要在 Helm chart 中明確設定容忍度。

ℹ️ 或者，您可以使用 Kyverno 來限制允許 Pod 使用哪些容忍度。請閱讀限制控制平面排程作為起點。

高可用性

cert-manager 有三個長時間運行的元件：controller、cainjector 和 webhook。每個元件都有一個 Deployment，預設情況下，每個 Deployment 都有 1 個副本，但這並未提供高可用性。cert-manager 的 Helm chart 具有設定每個 Deployment 的 replicaCount 的參數。在生產環境中，我們建議使用以下 replicaCount 參數

replicaCount: 2
webhook:
  replicaCount: 3
cainjector:
  replicaCount: 2

controller 和 cainjector

controller 和 cainjector 元件使用 leader election 來確保只有一個副本處於活動狀態。這可以防止多個副本協調相同的 API 資源時可能發生的衝突。因此，在這些元件中，您可以使用多個副本來實現高可用性，而不是用於水平擴展。

使用兩個副本可以確保有一個待命 Pod 被排程到一個節點，該節點準備好在當前領導者遇到中斷時接管領導權。例如，當領導者 Pod 從其節點中排空時。或者，如果領導者 Pod 遇到意外的死鎖。

沒有太多理由使用超過 2 個這些元件的副本。

webhook

預設情況下，cert-manager webhook Deployment 有 1 個副本，但在生產環境中，您應該使用 3 個或更多。如果 cert-manager webhook 不可用，則對 cert-manager 自定義資源的所有 API 操作都將失敗，這將會中斷任何建立、更新或刪除 cert-manager 自定義資源的軟體（包括 cert-manager 本身），並且可能會對您的叢集造成其他中斷。因此，尤其重要的是始終保持多個 cert-manager webhook 副本在運行。

ℹ️ 相反地，如果只有一個 cert-manager controller 副本，則發生中斷的風險較小。例如，如果託管單個 cert-manager controller manager Pod 的節點被排空，則在另一個節點上啟動新 Pod 時會出現延遲，並且在新的 Pod 啟動之前，不會協調在此期間建立或更改的任何 cert-manager 資源。但無論如何，controller manager 是異步工作的，因此任何依賴 cert-manager 自定義資源的應用程式都將設計為容忍這種情況。儘管如此，最佳實務是在叢集有足夠資源的情況下運行每個 controller 的 2 個或更多副本。

📖 請閱讀 Google Kubernetes Engine (GKE) 文件中的使用 webhook 時確保控制平面穩定性，其中包含 webhook 中斷可能如何破壞您的叢集的範例。

📖 請閱讀 Cisco 技術部落格上的 Kubernetes 准入 webhook 的陰暗面，以了解更多關於 webhook 可能導致的問題以及如何避免這些問題。

拓撲分佈約束

考慮使用拓撲分佈約束，以確保節點或資料中心的中斷不會降低 cert-manager 的運作。

為了實現高可用性，您不希望將副本 Pod 排程在同一節點上，因為如果該節點發生故障，活動和待命 Pod 都會退出，並且在有另一個節點具有足夠的可用資源來運行新的 Pod 之前，以及直到該 Pod 準備就緒之前，該 controller 將不會進一步協調資源。

如果叢集的節點分佈在各個區域之間，則 Pod 也應該在不同的資料中心（可用性區域）中運行。然後，在託管活動 Pod 的資料中心發生故障時，待命 Pod 將立即可用以接管領導權。

幸運的是，您可能不需要執行任何操作即可實現這些目標，因為 Kubernetes >= 1.24 具有內建的預設約束，這表示上述高可用性排程將隱式發生。

ℹ️ 如果您的叢集未使用內建的預設約束。您可以使用 Helm chart 值將拓撲分佈約束添加到每個 cert-manager 元件。

Pod 中斷預算

為了實現高可用性，您還應該部署一個具有 minAvailable=1 的 PodDisruptionBudget 資源。

這確保在另一個節點上成功排程並啟動至少一個其他副本之前，無法進行自願中斷，例如排空節點。Helm chart 具有為每個長時間運行的 cert-manager 元件啟用和設定 PodDisruptionBudget 的參數。我們建議使用以下參數

podDisruptionBudget:
  enabled: true
  minAvailable: 1
webhook:
  podDisruptionBudget:
    enabled: true
    minAvailable: 1
cainjector:
  podDisruptionBudget:
    enabled: true
    minAvailable: 1

📖 請閱讀 Kubernetes 文件中關於為您的應用程式指定中斷預算的資訊。

⚠️ 這些 PodDisruptionBudget 設定僅適用於高可用性部署。您必須將每個 Deployment 的 replicaCount 增加到大於 minAvailable 值，否則 PodDisruptionBudget 會阻止您排空 cert-manager Pod。

優先順序類別名稱

在 Kubernetes 部落格使用 PriorityClass 保護您的任務關鍵型 Pod 免於驅逐中總結了設定優先順序類別的原因如下

Pod 優先順序和搶佔功能有助於在資源短缺時透過決定排程和驅逐的順序，確保任務關鍵型 Pod 處於運行狀態。

如果 cert-manager 對您的平台至關重要，則在 cert-manager Pod 上設定 priorityClassName 以保護它們免受搶佔，在 Kubernetes 節點資源不足的情況下。如果沒有 priorityClassName，cert-manager Pod 可能會被驅逐以釋放其他 Pod 的資源，這可能會對任何依賴 cert-manager 的應用程式造成中斷。

大多數 Kubernetes 叢集都會帶有兩個內建的優先順序類別名稱：system-cluster-critical 和 system-node-critical，這些名稱用於 Kubernetes 核心元件。這些也可以用於關鍵附加元件，例如 cert-manager。

我們建議使用以下 Helm chart 值來為所有 cert-manager Pod 設定 priorityClassName: system-cluster-critical

global:
  priorityClassName: system-cluster-critical

在某些叢集上，可能會設定 ResourceQuota 准入控制器，以限制某些優先級類別在特定命名空間中的使用。例如，Google Kubernetes Engine (GKE) 預設只允許 priorityClassName: system-cluster-critical 用於 kube-system 命名空間中的 Pod。

📖 請閱讀 Kubernetes PR #93121，了解此功能的實作方式與原因。

在這種情況下，您需要在 cert-manager 命名空間中建立 ResourceQuota。

# cert-manager-resourcequota.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: cert-manager-critical-pods
  namespace: cert-manager
spec:
  hard:
    pods: 1G
  scopeSelector:
    matchExpressions:
    - operator: In
      scopeName: PriorityClass
      values:
      - system-node-critical
      - system-cluster-critical

kubectl apply -f cert-manager-resourcequota.yaml

📖 請閱讀使用 PriorityClass 保護您的關鍵任務 Pod 免於被驅逐，這是一篇關於 Pod 優先級和搶佔如何透過決定排程和驅逐順序，來確保在資源緊張時關鍵任務 Pod 能夠正常運作的 Kubernetes 部落格文章。

📖 請閱讀確保關鍵附加元件 Pod 的排程，以了解為什麼 system-cluster-critical 應該用於對完全正常運作的叢集至關重要的附加元件。

📖 請閱讀預設限制優先級類別的消耗，以了解為什麼平台管理員可能會將某些高優先級類別的使用限制在有限數量的命名空間中。

📖 以下是一些使用 system-cluster-critical 優先級類別名稱的其他關鍵附加元件範例：NVIDIA GPU Operator、OPA Gatekeeper、Cilium。

可擴展性

cert-manager 有三個長時間運行的元件：控制器 (controller)、cainjector 和 webhook。 Helm 圖表不包含這些元件的資源請求和限制，因此您應該提供適合您叢集的資源請求和限制。

控制器和 cainjector

控制器和 cainjector 元件使用領導者選舉 (leader election) 來確保只有一個複本處於活動狀態。這可以防止如果多個複本協調相同的 API 資源時可能發生的衝突。您不能對這些元件使用水平擴展。請改用垂直擴展。

記憶體

使用垂直擴展為這些元件分配足夠的記憶體資源。在具有大量 API 資源或大型 API 資源的叢集上，記憶體需求會更高。這是因為每個元件都會協調一個或多個 Kubernetes API 資源，並且每個元件都會將中繼資料（有時是整個資源）快取在記憶體中，以減少 Kubernetes API 伺服器的負載。

如果您的叢集中包含大量的 CertificateRequest 資源，例如在使用許多臨時或短期的憑證頻繁輪換時，您需要增加控制器 Pod 的記憶體限制。

您還可以透過設定 cainjector 僅監看 cert-manager 命名空間中的資源，並設定它不監看 Certificate 資源來減少 cainjector 的記憶體消耗。以下是如何使用 Helm 圖表值設定 cainjector 命令列標誌。

cainjector:
  extraArgs:
  - --namespace=cert-manager
  - --enable-certificates-data-source=false

⚠️️ 只有在 cainjector 專門用於 cert-manager webhook 時，此最佳化才適用。如果 cainjector 也用於管理其他軟體的 webhook 的 TLS 憑證，則不適用。例如，一些 Kubebuilder 衍生專案可能會依賴 cainjector 來注入其 webhook 的 TLS 憑證。

CPU

使用垂直擴展為這些元件分配足夠的 CPU 資源。在這些元件協調的資源更新頻率很高的叢集上，CPU 需求會更高。每當資源變更時，它都會被排入佇列，由元件重新協調。更高的 CPU 資源可以讓元件更快地處理佇列。

webhook

cert-manager webhook 不使用領導者選舉，因此您可以透過增加複本數量來水平擴展它。當 Kubernetes API 伺服器連線到 cert-manager webhook 時，它會透過一個服務來執行此操作，該服務會在所有 Ready 複本之間對連線進行負載平衡。因此，在 cert-manager 自訂資源互動頻率高的叢集上，增加 webhook 複本的數量到 3 個或更多是有明顯好處的。此外，webhook 的記憶體需求不高，因為它不使用快取。因此，擴展 webhook 的資源成本相對較低。

使用活性探針

Datree 文件中可以找到此建議的一個範例：確保每個容器都配置了活性探針。

活性探針可讓 Kubernetes 判斷何時應該替換 Pod。它們是配置彈性叢集架構的基礎。

cert-manager webhook 和控制器 Pod 確實有活性探針。cainjector Pod 尚未有活性探針。更多資訊如下。

webhook

cert-manager webhook 有一個預設啟用的活性探針，並且可以使用 Helm 值設定時序和閾值。

控制器

📢 cert-manager 控制器活性探針是在 cert-manager 版本 1.12 中引入，並在版本 1.14 中預設啟用。如果它在實際應用中引起問題，請與我們聯繫。

cert-manager 控制器的活性探針是一個 HTTP 探針，它連線到 healthz 伺服器的 /livez 端點，該伺服器在連接埠 9443 上偵聽，並在其自己的執行緒中執行。 /livez 端點目前會報告以下子系統的組合狀態，並且每個子系統都有自己的 /livez 端點。這些是：

/livez/leaderElection：如果領導者選舉記錄未更新，或者領導者選舉執行緒已退出但未使父進程崩潰，則會傳回錯誤。
/livez/clockHealth：如果在系統時鐘和 Go 用於排程計時器的單調時鐘之間偵測到時鐘偏差，則會傳回錯誤。

ℹ️ 未來，可以使用 /livez 端點檢查更多子系統，類似於 Kubernetes 確保日誌記錄不被阻塞和為每個控制器進行健康檢查的方式。

📖 閱讀關於如何存取個別健康檢查和詳細狀態資訊 (cert-manager 使用與 Kubernetes 相同的 healthz 端點多工器)。

cainjector

cainjector Pod 沒有存活探針或 /livez 健康檢查端點，但在 GitHub 問題中有其合理性：cainjector 在嘗試關閉後進入殭屍狀態。如果您也遇到過這個特定的問題，請在該問題中添加您的意見，如果您對 cainjector 中的存活探針有一般性請求，請在 Helm：允許為所有建立的 Pod 配置就緒、存活和啟動探針中添加您的意見。

背景資訊

cert-manager 的 controller 程序和 cainjector 程序都使用 Kubernetes 的領導者選舉程式庫，以確保每個程序在任何時候只有一個副本處於活動狀態。Kubernetes 控制平面元件也使用這個程式庫。

領導者選舉程式碼在一個單獨的執行緒（go 協程）中迴圈執行。如果它最初贏得領導者選舉，並且之後未能續訂其領導者選舉租約，它將會退出。如果領導者選舉執行緒退出，所有其他執行緒將會優雅地關閉，然後該程序將會退出。同樣地，如果任何其他主執行緒意外退出，將會觸發其餘執行緒的有序關閉，並且該程序也會退出。

這遵循了容器在發生致命錯誤時應該崩潰的原則。Kubernetes 將會重新啟動崩潰的容器，如果它重複崩潰，則連續重新啟動之間的時間間隔將會增加。

因此，只有在這個有序關閉過程中存在錯誤，或者在其他執行緒中存在錯誤，導致程序死鎖且無法關閉時，才需要存活探針。

📖 閱讀 Kubernetes 文件中的配置存活、就緒和啟動探針，並特別注意該文件中的註記和注意事項。

📖 閱讀使用存活探針搬石頭砸自己的腳，以獲得更多關於存活探針的警示資訊。

限制自動掛載服務帳戶令牌

這個建議在 Kyverno 政策目錄中描述如下

Kubernetes 會自動在每個 Pod 中掛載 ServiceAccount 憑證。ServiceAccount 可能被分配了允許 Pod 存取 API 資源的角色。阻止此功能是最小權限最佳實踐的延伸，如果 Pod 不需要與 API 伺服器對話即可運作，則應遵循此做法。此政策確保這些 ServiceAccount 令牌的掛載被阻止

cert-manager 元件 _確實_ 需要與 API 伺服器對話，但我們仍然建議將 automountServiceAccountToken: false 設置為以下原因

設置 automountServiceAccountToken: false 將允許 cert-manager 安裝在 Kyverno（或某些其他政策系統）配置為拒絕將此欄位設置為 true 的 Pod 的叢集上。Kubernetes 的預設值是 true。
使用 automountServiceAccountToken: true 時，Pod 中 _所有_ 的容器都將掛載 ServiceAccount 令牌，包括可能由 Kubernetes 准入控制器注入到 cert-manager Pod 資源中的 side-car 和 init 容器。最小權限原則建議最好將 ServiceAccount 令牌明確地掛載到 cert-manager 容器中。

因此，建議設置 automountServiceAccountToken: false，並手動將一個 projected Volume 添加到每個 cert-manager Deployment 資源，其中包含 ServiceAccount 令牌、CA 憑證和命名空間檔案，這些檔案通常會由 Kubernetes ServiceAccount 控制器自動添加，並明確地將一個唯讀 VolumeMount 添加到每個 cert-manager 容器。

此配置的範例包含在下面的 Helm Chart Values 檔案中。

最佳實踐 Helm Chart Values

下載以下 Helm chart values 檔案，並使用 --values 標誌將其提供給 helm install、helm upgrade 或 helm template

🔗 values.best-practice.yaml

# Helm chart values which make cert-manager comply with CIS, BSI and NSA
# security benchmarks and other best practices for deploying cert-manager in
# production.
#
# Read the rationale for these values in:
# * https://cert-manager.dev.org.tw/docs/installation/best-practice/
global:
  priorityClassName: system-cluster-critical

replicaCount: 2
podDisruptionBudget:
  enabled: true
  minAvailable: 1
automountServiceAccountToken: false
serviceAccount:
  automountServiceAccountToken: false
volumes:
- name: serviceaccount-token
  projected:
    defaultMode: 0444
    sources:
    - serviceAccountToken:
        expirationSeconds: 3607
        path: token
    - configMap:
        name: kube-root-ca.crt
        items:
        - key: ca.crt
          path: ca.crt
    - downwardAPI:
        items:
        - path: namespace
          fieldRef:
            apiVersion: v1
            fieldPath: metadata.namespace
volumeMounts:
- mountPath: /var/run/secrets/kubernetes.io/serviceaccount
  name: serviceaccount-token
  readOnly: true

webhook:
  replicaCount: 3
  podDisruptionBudget:
    enabled: true
    minAvailable: 1
  automountServiceAccountToken: false
  serviceAccount:
    automountServiceAccountToken: false
  volumes:
  - name: serviceaccount-token
    projected:
      defaultMode: 0444
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          name: kube-root-ca.crt
          items:
          - key: ca.crt
            path: ca.crt
      - downwardAPI:
          items:
          - path: namespace
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
  volumeMounts:
  - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
    name: serviceaccount-token
    readOnly: true

cainjector:
  extraArgs:
  - --namespace=cert-manager
  - --enable-certificates-data-source=false
  replicaCount: 2
  podDisruptionBudget:
    enabled: true
    minAvailable: 1
  automountServiceAccountToken: false
  serviceAccount:
    automountServiceAccountToken: false
  volumes:
  - name: serviceaccount-token
    projected:
      defaultMode: 0444
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          name: kube-root-ca.crt
          items:
          - key: ca.crt
            path: ca.crt
      - downwardAPI:
          items:
          - path: namespace
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
  volumeMounts:
  - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
    name: serviceaccount-token
    readOnly: true

startupapicheck:
  automountServiceAccountToken: false
  serviceAccount:
    automountServiceAccountToken: false
  volumes:
  - name: serviceaccount-token
    projected:
      defaultMode: 0444
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          name: kube-root-ca.crt
          items:
          - key: ca.crt
            path: ca.crt
      - downwardAPI:
          items:
          - path: namespace
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
  volumeMounts:
  - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
    name: serviceaccount-token
    readOnly: true

其他

此建議清單仍在制定中。如果您有其他最佳實踐建議，請為此頁面做出貢獻。