最佳实践

在本节中，您将学习如何配置 cert-manager 以符合流行的安全标准，例如 CIS Kubernetes 基准、NSA Kubernetes 加固指南或 BSI Kubernetes 安全建议。

您还将学习有关在生产环境中部署 cert-manager 的最佳实践；例如，由 Datree 及其内置规则等工具强制执行的最佳实践，以及由 Learnk8s 在其“Kubernetes 生产最佳实践”清单中记录的最佳实践。

概述

Helm 图表或 YAML 清单（Deployment、Pod、ServiceAccount 等）中的默认 cert-manager 资源旨在实现向后兼容，而不是最佳实践或最高安全级别。您可能会发现默认资源不符合您的 Kubernetes 集群的安全策略，在这种情况下，您可以使用 Helm 图表值修改安装配置以覆盖默认值。

网络需求和网络策略

每个 cert-manager Pod 的网络需求总结如下。一些网络需求取决于特定的颁发者/集群颁发者配置和/或特定配置选项。

当您了解到 **您的** cert-manager 安装的网络需求后，您应该考虑实施“最小权限”网络策略，使用 Kubernetes 网络 (CNI) 插件，例如 Calico。

网络策略应阻止不受信任的客户端连接到 cert-manager Pod，并阻止 cert-manager 连接到不受信任的服务器。

在 Calico 文档中可以找到此建议的示例。

无论您使用 Calico 还是 Kubernetes 网络策略，我们都建议为您的 Kubernetes Pod 创建隐式默认拒绝策略。这确保了默认情况下拒绝不需要的流量。

📖 Calico 最佳实践：隐式默认拒绝策略。

您可以使用 Kubernetes 内置的 NetworkPolicy 资源，该资源是可移植的，因为它被任何 Kubernetes 网络 (CNI) 插件 识别。或者，您可能更喜欢使用您的 CNI 软件提供的自定义资源。

📖 了解 Kubernetes 内置 NetworkPolicy API，并查看 一些示例策略。

网络需求

以下是网络需求概述

1. UDP / TCP：cert-manager（全部） -> Kubernetes DNS：所有 cert-manager 组件都对集群和外部域名执行 UDP DNS 查询。一些 DNS 查询可能使用 TCP。

2. TCP：Kubernetes（API 服务器） -> cert-manager（webhook）：Kubernetes API 服务器建立到 cert-manager webhook 组件 的 HTTPS 连接。阅读 cert-manager webhook 故障排除指南 以了解 webhook 网络需求。

3. 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，以验证尝试修改 Approved 或 Denied 条件的 CertificateRequest 资源。

4. TCP：cert-manager（controller） -> HashiCorp Vault（身份验证和资源 API 端点）：如果使用 Vault 颁发者，cert-manager controller 可能会建立到一个或多个 Vault API 端点的 HTTPS 连接。Vault 端点的目标主机和端口在颁发者或集群颁发者资源中配置。

5. TCP：cert-manager（controller） -> Venafi TLS Protect（身份验证和资源 API 端点）：如果使用 Venafi 颁发者，cert-manager controller 可能会建立到一个或多个 Venafi API 端点的 HTTPS 连接。Venafi API 端点的目标主机和端口在颁发者或集群颁发者资源中配置。

6. TCP：cert-manager（controller） -> DNS API 端点（用于 ACME DNS01）：如果使用 具有 DNS01 求解器的 ACME 颁发者，cert-manager controller 可能会建立到 DNS API 端点（如 Amazon Route53）以及任何关联的身份验证端点的 HTTPS 连接。

7. UDP / TCP：cert-manager（controller） -> 外部 DNS：如果使用 ACME 颁发者，cert-manager controller 可能会将 DNS 查询发送到递归 DNS 服务器，作为 ACME 挑战自检过程的一部分。这样做是为了确保在要求 ACME 服务器执行检查之前，DNS01 或 HTTP01 挑战是可解析的。

   在 DNS01 的情况下，它也可能执行一系列 DNS 查询以查询权威 DNS 服务器，以计算要添加 DNS01 挑战记录的 DNS 区域。在 DNS01 的情况下，cert-manager 还 支持 DNS over HTTPS。

   您可以使用以下 controller 标志 选择 DNS 服务器的主机和端口：--acme-http01-solver-nameservers、--dns01-recursive-nameservers 和 --dns01-recursive-nameservers-only。

8. TCP：ACME（Let's Encrypt） -> cert-manager（acmesolver）：如果使用为 HTTP01 配置的 ACME 颁发者，cert-manager 将在颁发者的命名空间或 cert-manager 命名空间（如果它是集群颁发者）中部署一个 acmesolver Pod、一个服务和一个 Ingress（或 Gateway API）资源。ACME 实现将通过您选择的 Ingress 负载均衡器与该 Pod 建立 HTTP 连接，因此您的网络策略必须允许这样做。

   ℹ️ acmesolver Pod **不需要** 访问 Kubernetes API 服务器。

9. TCP：Metrics Server -> 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 相同的节点上运行，并且以某种方式获得了对底层节点的 root 访问权限，则它可能能够读取 controller 在内存中缓存的 Secret 中的私钥。

您可以通过在为受信任的平台运算符保留的节点上运行 cert-manager 来降低这种风险。

cert-manager 的 Helm 图表包含参数来配置 Pod 的 tolerations 和 nodeSelector，以用于每个组件。这些参数的确切值将取决于您的特定集群。

📖 阅读 将 Pod 分配到节点，位于 Kubernetes 文档 中。

📖 阅读有关 污点和容忍度，位于 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 图表值安装 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 图表中显式设置容忍度。

ℹ️ 或者，您可以使用 Kyverno 来限制 Pod 允许使用的容忍度。请阅读 Restrict control plane scheduling 作为起点。

高可用性

cert-manager 有三个长期运行的组件：控制器、cainjector 和 webhook。这些组件中的每一个都有一个 Deployment，默认情况下每个 Deployment 都有 1 个副本，但这不提供高可用性。cert-manager 的 Helm 图表包含用于配置 replicaCount 的参数，用于每个 Deployment。在生产环境中，我们建议使用以下 replicaCount 参数

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

控制器和 cainjector

控制器和 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 控制器只有一个副本，则中断的风险较小。例如，如果托管单个 cert-manager 控制器管理器 Pod 的节点被驱逐，在另一个节点上启动新 Pod 时将会有延迟，并且在该时间内创建或更改的任何 cert-manager 资源将不会被协调，直到新 Pod 启动。但控制器管理器无论如何都是异步工作的，因此任何依赖 cert-manager 自定义资源的应用程序都将被设计为容忍这种情况。也就是说，最佳实践是如果集群有足够的资源，则运行每个控制器的 2 个或更多副本。

📖 请阅读 Google Kubernetes Engine (GKE) 文档中的 Ensure control plane stability when using webhooks，以了解 webhook 中断如何破坏集群的示例。

📖 请阅读 Cisco Tech Blog 上的 The dark side of Kubernetes admission webhooks，以详细了解由 webhook 引起的潜在问题以及如何避免这些问题。

拓扑传播约束

请考虑使用 Topology Spread Constraints，以确保节点或数据中心的中断不会降低 cert-manager 的运行效率。

为了实现高可用性，您不希望副本 Pod 被调度到同一个节点上，因为如果该节点发生故障，活动 Pod 和备用 Pod 都将退出，并且在另一个节点上有足够的可用资源来运行新 Pod 之前，以及该 Pod 变为就绪之前，该控制器将不再对资源进行协调。

如果集群在区域之间分布了节点，那么将 Pod 运行在不同的数据中心（可用区）中也是可取的。这样，如果托管活动 Pod 的数据中心发生故障，备用 Pod 将立即准备好接管领导权。

幸运的是，您可能不需要做任何事情来实现这些目标，因为 Kubernetes >= 1.24 有内置的默认约束，这意味着上面描述的高可用性调度将隐式发生。

ℹ️ 如果您的集群没有使用内置的默认约束。您可以使用 Helm 图表值向 cert-manager 的每个组件添加 Topology Spread Constraints。

PodDisruptionBudget

为了实现高可用性，您还应该部署一个 PodDisruptionBudget 资源，其中 minAvailable=1。

这可以确保自愿的中断（例如节点的驱逐）无法进行，除非至少另一个副本已成功调度到另一个节点并启动。Helm 图表包含参数，用于为每个长期运行的 cert-manager 组件启用和配置 PodDisruptionBudget。我们建议使用以下参数

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

📖 请阅读 Kubernetes 文档中的 Specifying a Disruption Budget for your Application。

⚠️ 这些 PodDisruptionBudget 设置仅适用于高可用性部署。您必须将每个 Deployment 的 replicaCount 设置为大于 minAvailable 值，否则 PodDisruptionBudget 将阻止您驱逐 cert-manager Pod。

优先级类名称

在 Kubernetes 博客中，对设置优先级类的原因做了以下总结：Protect Your Mission-Critical Pods From Eviction With PriorityClass

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 图表值将 priorityClassName: system-cluster-critical 设置为所有 cert-manager Pod。

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

📖 请阅读 Protect Your Mission-Critical Pods From Eviction With PriorityClass，这是一篇关于 Pod 优先级和抢占如何确保在资源短缺的情况下，通过决定调度和驱逐的顺序，让关键任务 Pod 保持运行状态的 Kubernetes 博客文章。

📖 请阅读 Guaranteed Scheduling For Critical Add-On Pods，以了解为什么 system-cluster-critical 应该用于对完全功能的集群至关重要的附加组件。

📖 阅读默认情况下限制优先级类消耗，了解为什么平台管理员可能会将某些高优先级类的使用限制在有限数量的命名空间。

📖 一些使用system-cluster-critical 优先级类名称的其他重要附加组件示例：NVIDIA GPU 运算符、OPA Gatekeeper、Cilium。

可扩展性

cert-manager 有三个长期运行的组件：控制器、cainjector 和 webhook。Helm 图表不包括任何这些组件的资源请求和限制，因此您应该提供适合您的集群的资源请求和限制。

控制器和 cainjector

控制器和 cainjector 组件使用领导者选举来确保只有一个副本处于活动状态。这可以防止在多个副本对相同的 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 时，它是通过一个服务进行连接的，该服务在所有就绪副本之间对连接进行负载均衡。因此，在 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 healthz 端点，但 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，原因如下：

1. 设置 automountServiceAccountToken: false 将允许 cert-manager 安装在配置了 Kyverno（或其他一些策略系统）来拒绝具有此字段设置为 true 的 Pod 的集群上。Kubernetes 默认值为 true。
2. 使用 automountServiceAccountToken: true，Pod 中的所有容器将挂载 ServiceAccount 令牌，包括 Kubernetes 准入控制器可能注入到 cert-manager Pod 资源中的 side-car 和 init 容器。最低权限原则建议最好将 ServiceAccount 令牌显式挂载到 cert-manager 容器中。

因此，建议设置 automountServiceAccountToken: false 并手动将一个投影的 Volume 添加到每个 cert-manager Deployment 资源中，包含 ServiceAccount 令牌、CA 证书和命名空间文件，这些文件通常会 由 Kubernetes ServiceAccount 控制器自动添加，并显式地向每个 cert-manager 容器添加一个只读的 VolumeMount。

此配置的示例包含在下面的 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.k8s.ac.cn/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

其他

此建议列表仍在开发中。如果您有其他最佳实践建议，请 为本页做出贡献。