最新消息：在Twitter和Mastodon取得專案更新

與 Kubernetes 平台供應商的相容性

您將在下方找到關於部署 cert-manager 時可能受到影響的各種相容性問題和怪癖的詳細資訊。如果您認為我們遺漏了某些內容，請隨時提出問題或發送包含詳細資訊的提取請求！

如果您使用 AWS Fargate，或者您已特別設定 cert-manager 運行於主機網路，請注意 kubelet 預設會監聽 10250 埠，這會與 cert-manager webhook 的預設埠衝突。

因此，在設定 cert-manager 時，您需要變更 webhook 的埠。

對於使用 Helm 安裝的情況，您可以在安裝 cert-manager 時，設定 webhook.securePort 參數，您可以透過命令列旗標或在您的 values.yaml 檔案中進行設定。

如果您遇到埠衝突，可能會看到關於不受信任憑證的混淆錯誤訊息。請參閱 #3237 以了解更多詳細資訊。

GKE

當 Google 為私有叢集設定控制平面時，它們會自動在您的 Kubernetes 叢集網路和一個獨立的 Google 管理專案之間設定 VPC 對等互連。

為了限制 Google 可以存取您叢集內的內容，所設定的防火牆規則會限制對您的 Kubernetes Pod 的存取。這意味著 webhook 將無法運作，您會看到類似 Internal error occurred: failed calling admission webhook ... the server is currently unable to handle the request 的錯誤。

為了在 GKE 私有叢集中使用 webhook 組件，您必須設定額外的防火牆規則，以允許 GKE 控制平面存取您的 webhook pod。

您可以在 GKE 文件中閱讀有關如何為 GKE 控制平面節點新增防火牆規則的更多資訊。

GKE Autopilot

由於 對 mutating admission webhooks 的限制，Kubernetes 版本低於 1.21 的 GKE Autopilot 模式不支援 cert-manager。

截至 2021 年 10 月，只有 "rapid" Autopilot 發布通道推出了 Kubernetes master 的 1.21 版本。透過 helm chart 安裝可能會導致錯誤訊息，但據一些使用者回報 cert-manager 運作正常。歡迎提供回饋和 PR。

問題：GKE Autopilot 不允許修改 kube-system 命名空間。

在過去，我們使用 kube-system 命名空間來防止在同一個叢集中多次安裝 cert-manager。

在這些環境中以預設設定安裝 cert-manager 可能會導致啟動問題。一些徵兆包括：

  • cert-manager-cainjector 記錄類似以下的錯誤：
E0425 09:04:01.520150       1 leaderelection.go:334] error initially creating leader election record: leases.coordination.k8s.io is forbidden: User "system:serviceaccount:cert-manager:cert-manager-cainjector" cannot create resource "leases" in API group "coordination.k8s.io" in the namespace "kube-system": GKEAutopilot authz: the namespace "kube-system" is managed and the request's verb "create" is denied
  • cert-manager-startupapicheck 無法完成，並記錄類似以下訊息：
Not ready: the cert-manager webhook CA bundle is not injected yet

解決方案：設定 cert-manager 使用不同的命名空間進行領導者選舉，如下所示：

helm install \
  cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --version ${CERT_MANAGER_VERSION} --set global.leaderElection.namespace=cert-manager

對於 kubectl apply 類型的安裝，其含義是：「您必須在安裝前手動更新 manifests，將 kube-system 替換為 cert-manager」，或「不要使用 kubectl apply 安裝 cert-manager。建議使用 Helm」。

AWS EKS

當在 EKS 上使用自訂 CNI（例如 Weave 或 Calico）時，cert-manager 無法連線到 webhook。這是因為控制平面無法設定為在 EKS 上使用自訂 CNI 運行，因此控制平面和工作節點之間的 CNI 不同。

為了解決這個問題，可以將 webhook 運行於主機網路中，以便 cert-manager 可以連線到它，方法是在您的部署中將 webhook.hostNetwork 鍵設定為 true，或者，如果使用 Helm，則在您的 values.yaml 檔案中設定它。

請注意，在主機網路中運行需要變更 webhook 的埠；有關詳細資訊，請參閱本頁頂端的警告。

AWS Fargate

值得注意的是，使用 AWS Fargate 不允許太多的網路設定，並且會導致 webhook 的埠與在埠 10250 上運行的 kubelet 衝突，如 #3237 中所述。

在 Fargate 上部署 cert-manager 時，您必須變更 webhook 監聽的埠。有關更多詳細資訊，請參閱本頁頂端的警告。

由於 Fargate 強制您使用其網路，您無法手動設定網路類型和選項，例如 helm chart 上的 webhook.hostNetwork，這會導致您的 cert-manager 部署以令人意外的方式失敗。