Skip to main content
operator 提供可选的 Kubernetes NetworkPolicy 资源,用于 限制哪些流量可以到达 controller manager pod (容器组) ——也就是 operator 进程本身,而不是 ClickHouse server 或 Keeper pod (容器组) 。这些策略默认关闭, 因此只有在你希望隔离 operator 的入口流量时才需要启用。 这些策略覆盖 operator 向其他客户端公开的两个端口:指标 端点和 admission webhook。
只有当 cluster 的 CNI plugin 实现了 NetworkPolicy 时,NetworkPolicy 才会生效 (例如 Calico 或 Cilium) 。如果 CNI 不强制执行 NetworkPolicy, 这些资源虽然会被创建,但实际上不会产生任何效果,而且 Kubernetes 也不会返回 error。在依赖这些策略之前,请先确认你的 CNI 会强制执行这些策略。

Helm 图表会创建什么

启用后,该图表最多会创建两个仅针对入口流量的策略,二者都会选择 controller-manager pod (容器组) : 这两个策略都只声明 policyTypes: [Ingress]。它们不会限制 operator 的出站流量,也不会影响 ClickHouse server 或 Keeper pod (容器组) 。

默认拒绝行为

当某个 pod (容器组) 被入口 NetworkPolicy 选中时,该 pod (容器组) 就会切换为对入口流量默认拒绝:一旦任一策略生效,所有未被显式允许、发往 controller manager pod (容器组) 的入站流量都会被丢弃。启用后, 唯一能够到达 operator 的入口流量只有:
  • 来自带有 metrics: enabled 标签的命名空间的指标抓取,以及
  • 来自带有 webhook: enabled 标签的命名空间的 admission webhook 调用。
发往该 pod (容器组) 的其他所有流量都会被拒绝。这正是预期的加固效果,但也 意味着未加标签的抓取器或 webhook 调用方会在这些 策略生效的那一刻停止工作。

启用这些策略

如果使用 Helm,请在配置值中设置此开关:
allow-webhook-traffic 还要求 webhook.enabled: true ( 默认启用) ,因此禁用 webhook 也会一并移除其策略。 对于原始 kubectl 清单,请按 kubectl install guide 中所述, 取消注释 [NETWORK POLICY] 部分。 这些原始清单同样包含这两条策略。

为客户端命名空间添加标签

由于这两条策略都会通过 namespaceSelector 匹配源命名空间,因此每个需要访问 operator 的命名空间 都必须带有相应的标签。来自未打标签命名空间的抓取或 webhook 调用都会被丢弃。
请将其与 Monitoring → 保护指标端点 中介绍的指标 RBAC 配合使用: NetworkPolicy 控制可达性,而 集群角色 绑定控制授权。要让受保护的抓取成功,这两者都必须同时具备。
准入 webhook 请求来自 Kubernetes API server,而不是普通的 pod (容器组) 。这些流量是否受 NetworkPolicy 约束,以及它显示为 来自哪个源,取决于你的控制平面拓扑和 CNI — 托管控制平面尤其如此,它们可能会从 namespaceSelector 无法匹配的地址访问该 webhook。如果 API server 的流量不在 webhook: enabled 命名空间的覆盖范围内,启用 allow-webhook-traffic 可能会阻断 准入,并导致 ClickHouseCluster/KeeperCluster 的创建和更新请求 超时。启用后,请先在非生产集群上测试准入;如有需要,再为 API server 添加 一条显式放行规则。

验证

启用后,请确认:
  • Prometheus 仍在抓取指标端点 (其命名空间带有 metrics: enabled 标签,并绑定到 metrics-reader 集群角色) 。
  • 创建或更新 ClickHouseCluster 仍可通过准入控制 (webhook 可达) 。
如果抓取未返回数据,或者对 CR 执行 apply 时卡住,最可能的原因是源命名空间未打标签,或上文提到的 API 服务器可达性注意事项。
最后修改于 2026年7月3日