IBM Cloud Docs
Webhookが壊れてクラスタマスターの操作が失敗するのはなぜですか?

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 サーバーと通信できなくなっている可能性がある。

以下のコマンドを実行してテストポッドを作成し、壊れたウェブフックを特定するエラーを取得します。 テストがパスすれば、その失敗は一時的なものであった可能性があり、再試行が可能である。

  1. 以下のコマンドを実行して、テスト・ポッドを作成し、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
    
  2. 壊れた 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
      
  3. 次のコマンドの出力の 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
    
  4. オプション: ウェブフックをバックアップしてください。特に、ウェブフックの再インストール方法がわからない場合や、ウェブフックを作成するのに必要な権限を持っていない場合です。

    kubectl get mutatingwebhookconfiguration <name> -o yaml > mutatingwebhook-backup.yaml
    
    kubectl get validatingwebhookconfiguration <name> -o yaml > validatingwebhook-backup.yaml
    
  5. Web フックの関連サービスおよびポッドの状況を確認します。

    1. サービスの Type フィールド、Selector フィールド、Endpoint フィールドを確認します。

      kubectl describe service -n <namespace> <service_name>
      
    2. サービスタイプが ClusterIP の場合、WebhookがクラスタマスターのKubernetesAPIに安全に接続できるように、Konnectivityポッドが Running ステータスになっていることを確認します。 ポッドが正常でない場合は、ポッドのイベント、ログ、ワーカー・ノードの正常性や他のコンポーネントを確認して、トラブルシューティングしてください。

      • Konnectivity エージェントのポッドを確認します。
        kubectl describe pods -n kube-system -l app=konnectivity-agent
        
    3. サービスにエンドポイントがない場合は、デプロイメントやポッドなどのバッキング・リソースの正常性を確認します。 リソースが正常でない場合は、ポッドのイベント、ログ、ワーカー・ノードの正常性や他のコンポーネントを確認して、トラブルシューティングしてください。 詳しくは、アプリ・デプロイメントのデバッグを参照してください。

      kubectl get all -n my-service-namespace -l <key=value>
      
    4. サービスにバッキング・リソースがない場合、またはポッドのトラブルシューティングを行っても問題が解決しない場合は、先ほど確認したミューティングまたはバリデーションのWebhook設定を削除してください。

      kubectl delete validatingwebhookconfiguration NAME
      
      kubectl delete mutatingwebhookconfiguration NAME
      
  6. クラスター・マスター操作 (クラスターの更新など) を再試行します。

  7. まだエラーが表示される場合は、ワーカー・ノードかネットワーク接続に問題がある可能性があります。

    • ワーカー・ノードのトラブルシューティング
    • クラスター・マスター内の Kubernetes API サーバーに Web フックが接続できることを確認します。 例えば、Calico ネットワーク・ポリシー、セキュリティー・グループ、またはその他のタイプのファイアウォールを使用する場合は、適切なアクセス権を持つクラシック・クラスターまたは VPC クラスターをセットアップします。
    • インストールしたアドオンによって Web フックが管理されている場合は、アドオンをアンインストールします。 Web フックの問題の原因となる一般的なアドオンとしては、以下があります。
  8. Web フックを再作成するか、アドオンを再インストールします。

  9. 問題が解決しない場合は、サポートにお問い合わせください。 サポート Case を開きます。 ケースの詳細には、関連するログファイル、エラーメッセージ、コマンド出力を必ず含めてください。