Webhookが壊れてクラスタマスターの操作が失敗するのはなぜですか?
仮想プライベート・クラウド クラシック・インフラストラクチャー
このトラブルシューティング・トピックは、Webhook の一般的なトラブルシューティング用ではありません。 クラスター・マスターの更新に関連しない Webhook の問題については、 Webhook のデバッグ を参照してください。
クラスターのバージョンの更新などのマスター操作中に、クラスターの Web フック・アプリケーションが破損していました。
現在、マスター操作を完了できません。 以下のようなエラーが表示されます。
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'
クラスターには、クラスター内のさまざまなサービスからクラスター・マスター内の API サーバーへの要求をインターセプトおよび変更できる、構成可能な Kubernetes Web フック・リソース (検証アドミッション Web フックおよび変更アドミッション Webhook) があります。
Web フックは要求を変更したり拒否したりできるので、Web フックが壊れると、クラスターの機能にさまざまな形で影響を及ぼすことがあります。例えば、マスター・バージョンの更新などの保守操作ができなくなります。 詳細については、Kubernetesドキュメントの Dynamic Admission Controlを参照。
Web フックが壊れた原因として、以下が考えられます。
- 要求を発行する基礎となるリソース (Kubernetes サービス、エンドポイント、ポッドなど) が欠落しているか正常でない。
- Web フックはアドオンまたは他のプラグイン・アプリケーションの一部であるが、そのアドオンまたは他のプラグイン・アプリケーションが正しくインストールされていないか、正常でない。
- ネットワーク接続の問題がクラスターに発生していて、その問題のために Web フックがクラスター・マスター内の Kubernetes API サーバーと通信できなくなっている可能性がある。
以下のコマンドを実行してテストポッドを作成し、壊れたウェブフックを特定するエラーを取得します。 テストがパスすれば、その失敗は一時的なものであった可能性があり、再試行が可能である。
-
以下のコマンドを実行して、テスト・ポッドを作成し、
ibm-system
ネームスペースにラベルを付ける。kubectl run webhook-test --image us.icr.io/armada-master/pause:3.10 -n ibm-system kubectl delete pod -n ibm-system webhook-test --ignore-not-found kubectl label ns ibm-system ibm-cloud.kubernetes.io/webhook-test-at="$(date -u +%FT%H_%M_%SZ)" --overwrite
壊れた Web フックの名前がエラー・メッセージに含まれている可能性があります。 以下の出力例では、ウェブフックは'
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
-
壊れた Web フックの名前を取得します。
- 壊れた Web フックがエラー・メッセージで示された場合は、
trust.hooks.securityenforcement.admission.cloud.ibm.com
を、前の手順で特定した壊れた Web フックに置き換えてください。
出力例kubectl get mutatingwebhookconfigurations,validatingwebhookconfigurations -o jsonpath='{.items[?(@.webhooks[*].name=="trust.hooks.securityenforcement.admission.cloud.ibm.com")].metadata.name}{"\n"}'
image-admission-config
- 壊れた Web フックがエラーで示されていない場合は、クラスター内のすべての Web フックをリストし、以下のステップでそれらの構成を確認します。
kubectl get mutatingwebhookconfigurations,validatingwebhookconfigurations
- 壊れた Web フックがエラー・メッセージで示された場合は、
-
次のコマンドの出力の
clientConfig
セクションで、変更 Web フックまたは検証 Web フックの構成の中のサービスとロケーションの詳細を確認します。image-admission-config
を、特定した名前に置き換えてください。 Web フックがクラスター外に存在する場合は、クラスター所有者に問い合わせて Web フックの状況を確認してください。kubectl get mutatingwebhookconfiguration image-admission-config -o yaml
kubectl get validatingwebhookconfigurations image-admission-config -o yaml
出力例
clientConfig: caBundle: <redacted> service: name: <name> namespace: <namespace> path: /inject port: 443
-
オプション: ウェブフックをバックアップしてください。特に、ウェブフックの再インストール方法がわからない場合や、ウェブフックを作成するのに必要な権限を持っていない場合です。
kubectl get mutatingwebhookconfiguration <name> -o yaml > mutatingwebhook-backup.yaml
kubectl get validatingwebhookconfiguration <name> -o yaml > validatingwebhook-backup.yaml
-
Web フックの関連サービスおよびポッドの状況を確認します。
-
サービスの Type フィールド、Selector フィールド、Endpoint フィールドを確認します。
kubectl describe service -n <namespace> <service_name>
-
サービスタイプが ClusterIP の場合、WebhookがクラスタマスターのKubernetesAPIに安全に接続できるように、Konnectivityポッドが Running ステータスになっていることを確認します。 ポッドが正常でない場合は、ポッドのイベント、ログ、ワーカー・ノードの正常性や他のコンポーネントを確認して、トラブルシューティングしてください。
- Konnectivity エージェントのポッドを確認します。
kubectl describe pods -n kube-system -l app=konnectivity-agent
- Konnectivity エージェントのポッドを確認します。
-
サービスにエンドポイントがない場合は、デプロイメントやポッドなどのバッキング・リソースの正常性を確認します。 リソースが正常でない場合は、ポッドのイベント、ログ、ワーカー・ノードの正常性や他のコンポーネントを確認して、トラブルシューティングしてください。 詳しくは、アプリ・デプロイメントのデバッグを参照してください。
kubectl get all -n my-service-namespace -l <key=value>
-
サービスにバッキング・リソースがない場合、またはポッドのトラブルシューティングを行っても問題が解決しない場合は、先ほど確認したミューティングまたはバリデーションのWebhook設定を削除してください。
kubectl delete validatingwebhookconfiguration NAME
kubectl delete mutatingwebhookconfiguration NAME
-
-
クラスター・マスター操作 (クラスターの更新など) を再試行します。
-
まだエラーが表示される場合は、ワーカー・ノードかネットワーク接続に問題がある可能性があります。
- ワーカー・ノードのトラブルシューティング。
- クラスター・マスター内の Kubernetes API サーバーに Web フックが接続できることを確認します。 例えば、Calico ネットワーク・ポリシー、セキュリティー・グループ、またはその他のタイプのファイアウォールを使用する場合は、適切なアクセス権を持つクラシック・クラスターまたは VPC クラスターをセットアップします。
- インストールしたアドオンによって Web フックが管理されている場合は、アドオンをアンインストールします。 Web フックの問題の原因となる一般的なアドオンとしては、以下があります。
-
Web フックを再作成するか、アドオンを再インストールします。
-
問題が解決しない場合は、サポートにお問い合わせください。 サポート Case を開きます。 ケースの詳細には、関連するログファイル、エラーメッセージ、コマンド出力を必ず含めてください。