除錯 Webhook
執行 kubectl 指令時,您會看到類似下列範例的錯誤訊息。
Error from server (InternalError): error when creating "testjob.yaml": Internal error occurred: failed calling webhook "mywebhook.test.io": Post https://admission-webhook.default.svc:443/validate?timeout=30s: dial tcp 172.21.189.228:443: connect: connection timed out
error creating namespace "test": Internal error occurred: admission plugin "MutatingAdmissionWebhook" failed to complete mutation in 13s
Webhook 失敗也可能導致類似下列問題的問題。
- 您無法建立或修改 Pod、密碼或名稱空間。
- 您無法將工作者節點新增至叢集,或建立用於保留 LUKS 加密金鑰的密碼。
- 您無法修補、更新或升級,且基礎失敗與在叢集中建立資源相關。
所呼叫服務或安全通道中的問題可能導致要求因逾時而失敗。 在發生此情況之前,您可能不知道已安裝許可控制 Webhook。
許可控制 Webhook 可讓您驗證或修改或改變 Kubernetes API 要求。 這些 Webhook 是從叢集 apiserver
或 openshift-apiserver
呼叫,且通常會呼叫在叢集中執行的服務。 准入控制 webhooks 有定義資源類型的規則,例如 pod、命名空間等,以及它們被呼叫的操作,例如建立、擷取、更新、刪除 (CRUD)。
Webhook 具有失敗原則,指出 Kubernetes 在呼叫 Webhook 時是否可以忽略連線錯誤,或者連線錯誤是否必須使作業失敗。 當 MutatingWebhookConfiguration
資源在處理之前修改要求資料時,ValidatingWebhookConfiguration
資源會檢查要求。
Webhook 也可以在正常作業期間拒絕要求: Webhook 可能會拒絕違反安全原則的要求,或者它可能會執行其他資料驗證。 在這種情況下,失敗資訊會包含 denied the request
回應,並有指出問題的原因。
admission webhook "mutate.configuration.upsert.appconnect.ibm.com" denied the request: version is not supported
在 IBM Cloud Kubernetes Service中,呼叫叢集裡執行之服務的 Webhook 會使用將 IBM Cloud 帳戶中叢集控制平面連接至客戶帳戶中叢集工作者節點的安全通道來執行此動作。
請完成下列步驟,以識別導致問題的 Webhook。 然後除錯相關服務並移除或重建 Webhook (必要的話)。
-
執行下列指令,以取得 VPN Pod 日誌。 如果您無法取得 VPN 日誌,請遵循 除錯一般 CLI 問題 的步驟,並在您能夠擷取日誌時回到此頁面。 如果指令成功,且您可以取得日誌,則 VPN 通道會運作,且您可以繼續進行下一步。
kubectl get pods -n kube-system -l app=vpn
kubectl logs -n kube-system -l app=vpn
-
說明許可控制 Webhook 並將輸出儲存至稱為
webhooks.txt
的檔案。kubectl describe mutatingwebhookconfigurations,validatingwebhookconfigurations > webhooks.txt
-
檢閱
webhooks.txt
檔案,以取得錯誤訊息。 來自應用程式 (包括 kubectl) 的 Webhook 相關錯誤訊息可協助識別 Webhook。 -
檢閱拒絕類型、計數及拒絕碼的 apiserver 度量。 您可以使用下列指令來取得度量值的 Snapshot。
kubectl get --raw /metrics | grep apiserver_admission_webhook_rejection_count
apiserver_admission_webhook_rejection_count{error_type="calling_webhook_error",name="check-ignore-label.gatekeeper.sh",operation="UPDATE",rejection_code="0",type="validating"} 16
rejection_code
值 0 表示呼叫 Webhook 時發生錯誤。 非零rejection_code
值表示 Webhook 拒絕要求。有 3 個 apiserver 實例。 kubectl 指令會從其中一個度量值取得度量值,並反映其中的活動。 每一個 apiserver 都會傳回不同的資料。 未處理失敗要求的實例可能不會傳回此度量值。
-
檢閱先前步驟的指令輸出,並尋找 Webhook 說明以識別特定的
MutatingWebhookConfiguration
或ValidatingWebhookConfiguration
值。 如果錯誤、日誌或度量值沒有幫助,請檢閱您先前擷取的 Webhook 說明。 每一個 Webhook 配置都有一組規則,用來指定 Webhook 所呼叫的資源類型及動作。 此資訊可用來識別可能涉及的 Webhook。-
如果呼叫 Webhook 時發生錯誤,請檢閱該服務的文件,以取得產品特定的除錯步驟。
-
如果 Webhook 拒絕要求,請查看 Webhook 的原則及配置選項。 可能可以調整它們以容許要求。 或者,要求可能違反原則,且需要變更提出要求的要求或應用程式。 如需相關資訊,請參閱 使用 Webhook 的最佳作法。
-
檢閱 Webhook 正在呼叫的服務
- 取得服務及其端點的詳細資料。
kubectl get svc NAME -n NAMESPACE
kubectl get ep NAME -n NAMESPACE
-
如果 Webhook 正在呼叫不存在的服務,則 Webhook 可能因應用程式的不完整或不適當移除而殘留。 在此情況下,請尋找服務特定的文件,並遵循步驟來解除安裝服務。
-
如果您無法解除安裝服務,請刪除 Webhook 配置。
kubectl delete validatingwebhookconfiguration NAME
kubectl delete mutatingwebhookconfiguration NAME
-
- 如果服務存在,但沒有端點,請檢查 Pod 的性能。 首先,從服務取得 Pod 標籤。
輸出範例kubectl describe svc NAME -n NAMESPACE
Selector: app=my-webhook
- 列出使用標籤的 pod。 例如,下列指令中的標籤是
app=mywebhook
。kubectl get pods -n NAMESPACE -l app=my-webhook
- 檢閱指令輸出。 如果 Pod 性能不佳,請檢查 Pod 事件、日誌、工作者節點性能及其他元件,以進行疑難排解。 如需相關資訊,請參閱 對應用程式部署進行除錯。
停用或移除 Webhook
-
將失敗原則設為
Ignore
,以暫時忽略連線和逾時。 執行下列指令編輯 webhook。kubectl edit validatingwebhookconfiguration NAME
kubectl edit mutatingwebhookconfiguration NAME
-
搜尋
failurePolicy
,並將值變更為Ignore
。 -
儲存設定並退出編輯器。 如果調整失敗原則無法解決問題,請重複先前的步驟,並將值變回
Fail
。 -
暫時移除 Webhook。 將現有的 Webhook 配置儲存至檔案,然後再刪除它。
kubectl get validatingwebhookconfiguration NAME -o yaml > webhook-config.yaml
kubectl get mutatingwebhookconfiguration NAME -o yaml > webhook-config.yaml
-
刪除 Webhook 配置。
kubectl delete validatingwebhookconfiguration NAME
kubectl delete mutatingwebhookconfiguration NAME
-
等待幾分鐘,然後重試無法查看問題是否已解決的
kubectl
指令。 -
重建 Webhook。
kubectl apply -f webhook-config.yaml
-
如果仍然發生此問題,請聯絡支援人員。 開啟 支援案例。 在案例詳細資料中,請務必包括任何相關日誌檔、錯誤訊息或指令輸出。