集群主节点操作为何由于 Webhook 中断而失败?

虚拟私有云传统基础设施

此故障诊断主题不适用于常规 Webhook 故障诊断。请参阅调试 Webhook，以了解与更新集群主节点无关的 Webhook 问题。

排查导致集群主节点运行受阻的 Webhook 故障。

在主操作 (例如更新集群版本) 期间，集群具有中断的 Webhook 应用程序。

现在，主操作无法完成。您会看到类似于以下内容的错误：

Cannot complete cluster master operations because the cluster has a broken webhook application. For more information, see the troubleshooting docs: 'https://ibm.biz/master_webhook'

您的群集拥有可配置的 Kubernetes 网络钩子资源，可验证或更改接纳网络钩子，从而拦截和修改群集中的各种服务向群集主控中的 API 服务器发出的请求。

由于 Webhook 可以更改或拒绝请求，因此中断的 Webhook 会以各种方式影响集群的功能，例如阻止您更新主版本或其他维护操作。有关更多信息，请参阅 Kubernetes 文档中的动态许可控制。

中断 Webhook 的潜在原因包括:

发出请求的底层资源缺少或运行状况不佳，例如 Kubernetes 服务，端点或 pod。
Webhook 是未正确安装或运行状况不佳的附加组件或其他插件应用程序的一部分。
集群可能存在网络连接问题，导致 Webhook 无法与集群主节点中的 Kubernetes API 服务器进行通信。

运行以下命令创建测试 pod，以获取可识别网络钩子故障的错误信息。如果测试通过，那么故障可能是暂时的，可以重新测试。

运行以下命令创建测试 pod 并标记 ibm-system 命名空间。

oc run webhook-test --image us.icr.io/armada-master/pause:3.10 -n ibm-system
oc delete pod -n ibm-system webhook-test --ignore-not-found
oc label ns ibm-system ibm-cloud.kubernetes.io/webhook-test-at="$(date -u +%FT%H_%M_%SZ)" --overwrite

错误消息可能具有中断的 Webhook 的名称。在以下示例输出中，网络钩子是 trust.hooks.securityenforcement.admission.cloud.ibm.com。

Error from server (InternalError): Internal error occurred: failed calling webhook "trust.hooks.securityenforcementadmission.cloud.ibm.com": Post https://ibmcloud-image-enforcement.ibm-system.svc:443/mutating-pods?timeout=30s: dialtcp 172.21.xxx.xxx:443: connect: connection timed out

获取中断的 Webhook 的名称。

如果错误消息包含中断的 Webhook，请将 trust.hooks.securityenforcement.admission.cloud.ibm.com 替换为先前标识的中断的 Webhook。

    oc get mutatingwebhookconfigurations,validatingwebhookconfigurations -o jsonpath='{.items[?(@.webhooks[*].name=="trust.hooks.securityenforcement.admission.cloud.ibm.com")].metadata.name}{"\n"}'
    ```
    示例输出
    ```sh {: pre}
    image-admission-config
    ```
*   如果错误没有中断的 Webhook，请列出集群中的所有 Webhook，并在以下步骤中检查其配置。
```sh {: pre}
    oc get mutatingwebhookconfigurations,validatingwebhookconfigurations
    ```

在以下命令的输出中的 clientConfig 部分中查看变异或验证 Webhook 配置的服务和位置详细信息。将 image-admission-config 替换为先前标识的名称。如果 Webhook 存在于集群外部，请与集群所有者联系以检查 Webhook 状态。

oc get mutatingwebhookconfiguration image-admission-config -o yaml

oc get validatingwebhookconfigurations image-admission-config -o yaml

示例输出

  clientConfig:
    caBundle: <redacted>
    service:
        name: <name>
        namespace: <namespace>
        path: /inject
        port: 443

可选项：备份网络钩子，尤其是在不知道如何重新安装网络钩子或没有创建网络钩子所需权限的情况下。

oc get mutatingwebhookconfiguration <name> -o yaml > mutatingwebhook-backup.yaml

oc get validatingwebhookconfiguration <name> -o yaml > validatingwebhook-backup.yaml

检查 Webhook 的相关服务和 pod 的状态。

检查服务类型，选择器和端点字段。

    oc describe service -n <namespace> <service_name>
    ```
2. 如果服务类型为 **ClusterIP**，请检查 Konnectivity pod 是否处于 **Running** 状态，以便 webhook 可以安全地连接到群集主控中的 Kubernetes API。 如果 pod 运行状况不佳，请检查 pod 事件，日志，工作程序节点运行状况和其他组件以进行故障诊断。

    * 检查 Konnectivity 代理程序 pod。
        ```sh {: pre}
        oc describe pods -n kube-system -l app=konnectivity-agent
        ```

1. 如果服务没有端点，请检查支持资源 (例如部署或 pod) 的运行状况。 如果资源运行状况不佳，请检查 pod 事件，日志，工作程序节点运行状况和其他组件以进行故障诊断。 有关更多信息，请参阅 [调试应用程序部署](/docs/openshift?topic=openshift-debug_apps)。
```sh {: pre}
    oc get all -n my-service-namespace -l <key=value>
    ```
1. 如果服务没有任何支持资源，或者如果对 pod 进行故障诊断无法解决问题，请除去先前标识的更改或验证 Webhook 配置。
```sh {: pre}
    oc delete validatingwebhookconfiguration NAME
    ```
    ```sh {: pre}
    oc delete mutatingwebhookconfiguration NAME
    ```

请重试集群主操作，例如更新集群。
如果仍看到该错误，那么可能存在工作程序节点或网络连接问题。
- 工作程序节点故障诊断。
- 确保 Webhook 可以连接到集群主节点中的 Kubernetes API 服务器。例如，如果使用 Calico 网络策略，安全组或其他类型的防火墙，请设置具有相应访问权的经典或 VPC 集群。
- 如果 Webhook 由您安装的附加组件管理，请卸载该附加组件。导致 Webhook 问题的常见附加组件包括以下内容:
  - Portieris
重新创建 Webhook 或重新安装附加组件。
如果问题仍然存在，请联系支持团队。打开支持案例。在案例详细信息中，请务必包含任何相关日志文件、错误信息或命令输出。