為何叢集主節點作業會因 Webhook 中斷而失敗?

Virtual Private Cloud 標準基礎架構

此疑難排解主題不適用於一般 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 Webhook 資源，可驗證或轉換許可 Webhook，可截取及修改從叢集中各種服務到叢集主節點中 API 伺服器的要求。

因為 Webhook 可以變更或拒絕要求，所以中斷的 Webhook 可能會以各種方式影響叢集的功能，例如阻止您更新主要版本或其他維護作業。如需相關資訊，請參閱 Kubernetes 文件中的 Dynamic Admission Control。

中斷 Webhook 的潛在原因包括:

發出要求的基礎資源遺漏或性能不佳，例如 Kubernetes 服務、端點或 Pod。
Webhook 是附加程式或其他外掛程式應用程式的一部分，未正確安裝或性能不佳。
您的叢集可能有網路連線功能問題，導致 Webhook 無法與叢集主節點中的 Kubernetes API 伺服器進行通訊。

執行以下命令建立一個測試 Pod，以取得標識損壞的 Webhook 的錯誤。如果測試通過，則故障可能是暫時的，可以重試。

執行以下命令建立測試 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 名稱。在以下範例輸出中，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"}'
```
  輸出範例
```
image-admission-config
```
- 如果錯誤沒有中斷的 Webhook，請在下列步驟中列出叢集裡的所有 Webhook 並檢查其配置。
```
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

選用：備份 Webhook，尤其是當您不知道如何重新安裝 Webhook 或沒有建立 Webhook 所需的權限時。

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

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

請檢查 Webhook 相關服務及 Pod 的狀態。
1. 檢查服務類型、選取器及端點欄位。
```
oc describe service -n <namespace> <service_name>
```
2. 如果服務類型為 ClusterIP，請檢查 Konnectivity Pod 是否處於 Running 狀態，以便 Webhook 可以安全地連線到叢集 Master 中的Kubernetes API。如果 Pod 性能不佳，請檢查 Pod 事件、日誌、工作者節點性能及其他元件，以進行疑難排解。
  - 檢查 Konnectivity 代理程式 Pod。
```
oc describe pods -n kube-system -l app=konnectivity-agent
```
3. 如果服務沒有端點，請檢查支持資源 (例如部署或 Pod) 的性能。如果資源性能不佳，請檢查 Pod 事件、日誌、工作者節點性能及其他元件，以進行疑難排解。如需相關資訊，請參閱對應用程式部署進行除錯。
```
oc get all -n my-service-namespace -l <key=value>
```
4. 如果服務沒有任何支持資源，或者如果對 Pod 進行疑難排解無法解決問題，請移除先前識別的轉換或驗證 Webhook 配置。
```
oc delete validatingwebhookconfiguration NAME
```
```
oc delete mutatingwebhookconfiguration NAME
```
重試叢集主要作業，例如更新叢集。
如果您仍然看到錯誤，則可能有工作者節點或網路連線功能問題。
- 工作者節點疑難排解。
- 確保 Webhook 可以連接至叢集主節點中的 Kubernetes API 伺服器。例如，如果您使用 Calico 網路原則、安全群組或某種其他類型的防火牆，請設定具有適當存取權的標準或 VPC 叢集。
- 如果 Webhook 是由您所安裝的附加程式所管理，請解除安裝該附加程式。導致 Webhook 問題的一般附加程式包括下列:
  - Portieris
重建 Webhook 或重新安裝附加程式。
如果仍然發生此問題，請聯絡支援人員。開啟支援案例。在案例詳細資訊中，請務必包含任何相關的日誌檔案、錯誤訊息或命令輸出。