关于 cert-manager Webhook 的一切

cert-manager 使用自定义资源定义扩展 Kubernetes API。它安装一个 webhook，它具有三个主要功能

验证: 确保在创建或更新 cert-manager 资源时，它们符合 API 的规则。这种验证比例如确保资源符合 OpenAPI 模式更为深入，而是包含诸如不允许为单个 Issuer 资源指定多个 Issuer 类型之类的逻辑。验证准入始终被调用，并将以成功或失败的响应进行回复。
变异/默认值: 在创建和更新操作期间更改资源的内容，例如设置默认值。
转换: 该 Webhook 还负责在 cert-manager CustomResources (cert-manager.io) 中实现跨版本的转换。这意味着可以同时支持多个 API 版本；从 v1alpha2 到 v1。这使得可以依赖我们配置模式的特定版本。

ℹ️ 这被称为动态准入控制。在 Kubernetes 文档中阅读有关动态准入控制的更多信息。

概述

Webhook 组件作为另一个 pod 部署，该 pod 与主 cert-manager 控制器和 CA 注入器组件一起运行。

为了使 API 服务器与 Webhook 组件通信，Webhook 需要一个 API 服务器配置为信任的 TLS 证书。

Webhook 在部署 Webhook 的命名空间中创建 secret/cert-manager-webhook-ca。此密钥包含一个自签名根 CA 证书，用于为 Webhook pod 签名证书，以满足此要求。

然后可以将 Webhook 配置为

指向由 Webhook CA 签名的 TLS 证书和密钥的路径，或者
对 CA 密钥的引用，以便在 Webhook 启动时动态生成证书和密钥

已知问题和解决方案

GKE 私有集群上的 Webhook 连接问题

如果在 Webhook 附近发生错误，但 Webhook 正在运行，那么 Webhook 很可能无法从 API 服务器访问。在这种情况下，请按照 GKE 私有集群说明确保 API 服务器可以与 Webhook 通信。

AWS EKS 上的 Webhook 连接问题

在 EKS 上使用自定义 CNI（例如 Weave 或 Calico）时，cert-manager 无法访问 Webhook。发生这种情况是因为控制平面无法配置为在 EKS 上运行自定义 CNI，因此控制平面和工作节点之间的 CNI 不同。解决方法是在主机网络中运行 Webhook，以便 cert-manager 可以访问它。

cert-manager 安装后不久的 Webhook 连接问题

首次安装 cert-manager 时，cert-manager API 可用需要几秒钟。这是因为 cert-manager API 需要 cert-manager Webhook 服务器，启动需要一些时间。以下是原因

Webhook 服务器在启动时执行领导者选举，这可能需要几秒钟。
Webhook 服务器可能需要几秒钟才能启动并生成其自签名 CA 和服务证书，以及将它们发布到密钥中。
cainjector 在启动时执行领导者选举，这可能需要几秒钟。
cainjector 启动后，将需要几秒钟才能更新所有 Webhook 配置中的 caBundle。

因此，在安装 cert-manager 以及执行安装后 cert-manager API 操作时，您需要检查临时的 API 配置错误并重试。

您也可以添加一个安装后检查，该检查对 cert-manager API 执行 kubectl --dry-run 操作。或者，您可以添加一个安装后检查，该检查自动重试安装验证步骤，直到它们成功。

其他 Webhook 问题

如果您遇到 Webhook 的任何其他问题，请参阅 Webhook 故障排除指南。