新：在推特和Mastodon

与 Kubernetes 平台提供商的兼容性

以下内容详细介绍了在部署 cert-manager 时可能会遇到的各种兼容性问题和怪癖。如果您认为我们遗漏了什么，请随时提出问题或提供包含详细信息的拉取请求！

如果您正在使用 AWS Fargate，或者您已明确配置 cert-manager 在主机网络上运行，请注意，kubelet 默认监听端口 10250，这与 cert-manager webhook 的默认端口冲突。

因此，您需要在设置 cert-manager 时更改 webhook 的端口。

对于使用 Helm 的安装，您可以在安装 cert-manager 时使用命令行标志或 values.yaml 文件中的条目设置 webhook.securePort 参数。

如果您遇到端口冲突，您可能会看到有关不受信任证书的令人困惑的错误消息。有关更多详细信息，请参见 #3237。

GKE

当 Google 为私有集群配置控制平面时，他们会自动在 Kubernetes 集群的网络和一个单独的 Google 管理的项目之间配置 VPC 对等连接。

为了限制 Google 可以访问集群中的内容，配置的防火墙规则限制了对 Kubernetes Pod 的访问。这意味着 webhook 无法正常工作，您会看到类似于 内部错误：调用准入 webhook 失败 ... 服务器目前无法处理请求 的错误。

为了在 GKE 私有集群中使用 webhook 组件，您必须配置额外的防火墙规则，允许 GKE 控制平面访问您的 webhook Pod。

您可以在 GKE 文档 中阅读有关如何为 GKE 控制平面节点添加防火墙规则的更多信息。

GKE Autopilot

由于 对变异准入 webhook 的限制，使用 Kubernetes < 1.21 的 GKE Autopilot 模式不支持 cert-manager。

截至 2021 年 10 月，只有“快速”Autopilot 版本通道为 Kubernetes 主节点推出了 1.21 版本。通过 helm 图表进行安装可能会导致错误消息，但 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 类型的安装，则意味着“您必须在安装之前手动更新清单，将 kube-system 替换为 cert-manager”或“不要使用 kubectl apply 安装 cert-manager。Helm 是推荐的解决方案”。

AWS EKS

在 EKS 上使用自定义 CNI（例如 Weave 或 Calico）时，cert-manager 无法访问 webhook。发生这种情况是因为控制平面无法配置为在 EKS 上运行自定义 CNI，因此控制平面和工作节点之间的 CNI 不同。

为了解决这个问题，可以通过将部署中的 webhook.hostNetwork 键设置为 true，或者如果使用 Helm，则在您的 values.yaml 文件中进行配置，将 webhook 运行在主机网络中，这样 cert-manager 就可以访问它。

请注意，在主机网络上运行需要更改 webhook 的端口；有关详细信息，请参见页面顶部的警告。

AWS Fargate

值得注意的是，使用 AWS Fargate 不允许进行太多网络配置，并且会导致 webhook 的端口与在端口 10250 上运行的 kubelet 冲突，如 #3237 所示。

在 Fargate 上部署 cert-manager 时，您*必须*更改 webhook 监听的端口。有关更多详细信息，请参见此页面顶部的警告。

由于 Fargate 强制您使用其网络，因此您无法手动设置网络类型和 webhook.hostNetwork 等选项，helm 图表上的这些选项将导致您的 cert-manager 部署以令人惊讶的方式失败。