使用许可控制器和 Webhook 访问集群主节点

在请求到达在 Red Hat OpenShift on IBM Cloud 集群主节点中运行的 API 服务器之前，许可控制器会拦截来自各种 Kubernetes 资源的授权 API 请求。更改许可 Webhook 可能会修改请求，并且验证许可 Webhook 会检查请求。如果任一 Webhook 拒绝请求，那么整个请求都将失败。高级功能 (无论是内置功能还是添加功能) 通常需要许可控制器作为安全预防措施，并控制将哪些请求发送到 API 服务器。有关更多信息，请参阅 Kubernetes 文档中的使用准入控制器和动态准入控制。

我可以创建自己的许可控制器吗?

是，请参阅 Kubernetes 和 Red Hat OpenShift 文档以获取更多信息。

如 Kubernetes 文档中所述，您可以将许可控制器用于控制平面以其他方式处理的操作。因此，在配置定制许可控制器时，请务必谨慎。由于定制许可控制器而在集群中发生的任何更改都由您负责。

使用 Webhook 的最佳实践是什么?

配置 Webhook 时，请记住以下最佳实践和注意事项。

请勿使用突变网络钩子来突变其他控制器或操作员拥有的资源。这样做可能会导致资源所有者和 webhook 之间的无限调节循环。 Webhooks 可以通过检查资源数据中是否设置了 metadata.ownerReferences 来确定资源所有权。例如，Kubernetes replicaset 资源由 Kubernetes 部署资源拥有，绝不能被 webhook 更改。
为 Webhook 创建副本 pod，以便在一个 pod 关闭时，Webhook 仍可以处理来自资源的请求。如果可能，请跨区域分布副本 pod。
设置相应的 failurePolicy 选项，例如，您的 Webhook 是失败还是忽略连接失败或超时。如果您希望 Webhook 忽略连接错误超时，那么可以将 failurePolicy 设置为 Ignore。请注意，如果 Webhook 拒绝请求，那么这不会更改 apiserver 的行为方式。
查看 timeoutSeconds 时间间隔。使用 v1beta1.admissionregistration.k8s.io API 的较旧 Webhook 的缺省超时为 30 秒。 v1 API 使用缺省值 10 秒。如果 Webhook 故障策略为“忽略”且当前 timeoutSeconds 为 30，请考虑将超时减少到 10 秒。对于 OpenShift 集群，控制平面组件通常具有自己的 13 秒超时。
为 Webhook 设置相应的 CPU 和内存资源请求和限制。
添加活动性和就绪性探测器，以帮助确保 Webhook 容器正在运行并准备好为请求提供服务。
设置 pod 反亲缘关系调度规则，以便尽可能使 Webhook pod 在不同的工作程序节点和区域上运行。您可以改为使用 pod 拓扑。但是，请避免污点或强制亲缘关系，这可能会限制可以调度 Webhook pod 的位置。
针对 Webhook pod 将 pod 优先级设置为 system-cluster-critical，以便其他 pod 无法从您的 Webhook pod 获取资源。
将 Webhook 的作用域限定为相应的项目。避免处理在系统关键项目中运行的资源的网络钩子，这些项目默认设置在集群中，例如 kube-system、ibm-system、ibm-operators、calico-apiserver、calico-system、tigera-operator 和 openshift-* 项目。
查看 namespaceSelector 选项。您可以向某些关键名称空间 (例如 kube-system) 添加标签，因此不会针对这些情况调用 Webhook。此设置称为“选择性停用”样式配置。或者，您可以配置 namespaceSelector 选项，以便仅对具有特定标签的名称空间调用 Webhook。此设置称为“选择性加入”配置。根据 Webhook 的用途，对所有名称空间调用 Webhook 可能很重要。查看 Kubernetes 文档中的 namespaceSelector 配置选项，并调整 Webhook 配置。
确保集群中的工作程序节点具有用于运行 Webhook 应用程序的正确大小。例如，如果 pod 请求的 CPU 或内存超过工作程序节点所能提供的 CPU 或内存，那么不会调度 pod。

还有哪些类型的应用使用许可控制器?

许多集群附加组件，插件和其他第三方扩展使用许可控制器。一些常见的问题包括:

Portieris

设置许可控制器 Webhook

在集群版本 4.14 和更高版本中，Konnectivity 取代了 OpenVPN 解决方案。如果您的群集版本为 4.14 及更高版本，并且您的 webhook 使用 ClusterIP, 则必须更新您的 webhook 以使用 Kubernetes 服务。

您可以通过将 Webhook 应用程序作为 Kubernetes 服务进行引用，或者通过将 Webhook 应用程序作为 IP 地址或公共注册的 DNS 名称进行引用来配置 Webhook。

用于将 Webhook 应用程序作为 Kubernetes 服务引用的示例配置

clientConfig:
   caBundle: #CA_BUNDLE_BASE64#
   service:
      name: admission-webhook
      namespace: default
      path: /validate
      port: 443

用于将 Webhook 应用程序作为 IP 地址或公共注册的 DNS 名称进行引用的示例配置

clientConfig:
   caBundle: #CA_BUNDLE_BASE64#
   url: https://#WEBHOOK_URL#:443/validate

请注意以下限制，以将 Webhook 应用程序作为 IP 地址或 DNS 名称进行引用:

如果 URL 是一个DNS，那么这个DNS必须是一个公开注册的DNS名称。不支持专用 DNS 配置。
如果 URL 是一个外部IP地址，这意味着webhook服务位于集群之外，则使用控制平面网络连接到该服务。控制平面必须能够到达 IP 地址。例如，如果 IP 地址来自本地网络，并且控制平面无法访问 IP 地址，那么 Webhook 服务不起作用。
如果 URL 是一个集群IP地址，这意味着webhook服务位于集群内部，那么 Kubernetes API需要连接到集群网络。如果您使用的是集群版本 1.21 及更高版本，且您的网络挂钩使用集群 IP 地址，则必须更新您的网络挂钩，改为使用 Kubernetes 服务。

我需要一个中断的 Webhook 的帮助。我该怎么办？