次の方法で共有


アドミッション コントローラーを検証する

この記事はシリーズの一部です。 最初に概要をご覧ください。

アドミッション コントローラーが問題の原因になることはほとんどありませんが、適切に機能させることは重要です。 この記事では、正しく機能していないアドミッション コントローラーが他のコンポーネントに与える可能性のある影響について説明します。 また、アドミッション コントローラーのパフォーマンスを検証するために使用できるコマンドについても説明します。

アドミッション コントローラー

アドミッション コントローラーは、Kubernetes API サーバーへの要求を、要求が認証および認可された後て、オブジェクトが永続化される前に、インターセプトするコードです。

アドミッション コントローラーでは、"検証"、"変更"、または両方の組み合わせを行うことができます。 "変更" コントローラーは、要求を受け入れる前に関連オブジェクトを変更できます。 "検証" コントローラーは、要求が特定の定義済みの条件を満たしていることの確認だけを行います。

アドミッション コントローラーの主な機能の 1 つは、オブジェクトの作成、削除、変更に対する要求を調整することです。 さらに、アドミッション コントローラーは、API サーバー プロキシ経由でのポッドへの接続の要求など、カスタム動詞を制限できます。 ただし、アドミッション コントローラーは、getwatchlist などの操作を含め、オブジェクトの読み取り要求をブロックすることはできません。

"変更 Webhook や検証 Webhook" などの一部のコンポーネントは、、アドミッション コントローラーに影響を与える可能性があります。 変更および検証 Webhook を Kubernetes クラスターに組み込む場合は、高可用性を設けることが不可欠です。 異常なノードによって API サーバー要求がブロックされないようにする必要があります。 API サーバーへの要求がブロックされないように、アドミッション制御パイプラインを監視することが重要です。 異常なアドミッション コントローラーは、変更および検証 Webhook に影響を与える可能性があります。 監視する必要がある Webhook ベースのアドミッション コントローラーには、次のものが含まれます。

また、適切に機能していないアドミッション コントローラーは、"サービス メッシュ" などのさまざまなコンポーネントに影響を与える可能性があります。 IstioLinkerd などのサービス メッシュは、アドミッション コントローラーを使って、たとえば、ポッド内のサイドカー コンテナーの挿入を自動化します。 サービス メッシュをシームレスに動作させるには、アドミッション コントローラーが正常に機能していることを評価して検証することが重要です。

AKS クラスター用 Azure Policy アドオンの状態を確認する

AKS 用 Azure Policy アドオンをインストールする場合は、次の kubectl コマンドを使って、クラスターでの Azure Policy アドミッション コントローラーのインストールと機能を検証できます。

# Verify that Azure Policy pods are running.
kubectl get pod -n gatekeeper-system

# Sample output
...
NAME                                     READY   STATUS    RESTARTS   AGE
gatekeeper-audit-65844778cb-rkflg        1/1     Running   0          163m
gatekeeper-controller-78797d4687-4pf6w   1/1     Running   0          163m
gatekeeper-controller-78797d4687-splzh   1/1     Running   0          163m
...

このコマンドを実行すると、gatekeeper-system 名前空間内の Azure Policy エージェント ポッドの可用性が検証されます。 出力が想定したものと異なる場合は、アドミッション コントローラー、API サービス、またはカスタム リソース定義 (CRD) に関する問題を示している可能性があります。

# Check that all API resources are working correctly. Use the following command to list all API resources.
kubectl api-resources

# Sample output
...
NAME                                     SHORTNAMES    APIGROUP                       NAMESPACED   KIND
bindings                                                                              true         Binding
componentstatuses                        cs                                           false        ComponentStatus
configmaps                               cm                                           true         ConfigMap
...

このコマンドは、すべての API リソースが正しく機能することを確認するのに役立ちます。 予期されるリソースが出力に含まれ、エラーや足りないコンポーネントがないことを確認します。 kubectl get podkubectl api-resources コマンドを使って、AKS 用 Azure Policy アドオンの状態を確認し、Kubernetes クラスター内のアドミッション コントローラーの機能を検証します。 クラスターの全体的な正常性と安定性を維持できるよう、アドミッション コントローラーを定期的に監視して、適切に機能することを確認します。

次の kubectl get コマンドを使って、ポリシーの割り当てがクラスターに適用されていることを確認します。

kubectl get constrainttemplates

Note

ポリシーの割り当ては、各クラスターに同期されるまで最大 20 分かかる場合があります。

次の例のような出力になる必要があります。

NAME                                     AGE
k8sazureallowedcapabilities              23m
k8sazureallowedusersgroups               23m
k8sazureblockhostnamespace               23m
k8sazurecontainerallowedimages           23m
k8sazurecontainerallowedports            23m
k8sazurecontainerlimits                  23m
k8sazurecontainernoprivilege             23m
k8sazurecontainernoprivilegeescalation   23m
k8sazureenforceapparmor                  23m
k8sazurehostfilesystem                   23m
k8sazurehostnetworkingports              23m
k8sazurereadonlyrootfilesystem           23m
k8sazureserviceallowedports              23m

詳細については、次のリソースを参照してください。

Webhook を検証する

Kubernetes クラスターで検証および変更 Webhook が意図したとおりに動作していることを確認するには、次の手順のようにします。

  1. 次のコマンドを実行して、クラスター内の検証 Webhook の一覧を表示します。

    kubectl get ValidatingWebhookConfiguration -o wide
    

    次の例のような出力になる必要があります。

    NAME                         WEBHOOKS   AGE
    aks-node-validating-webhook   1          249d
    azure-policy-validating-webhook-configuration   1          249d
    gatekeeper-validating-webhook-configuration     1          249d
    

    出力を調べて、検証 Webhook が存在し、その構成が想定どおりであることを確認します。 出力には、各検証 Webhook の名前、Webhook の数、各 Webhook の経過時間が含まれます。

  2. 次のコマンドを実行して、クラスター内の変更 Webhook の一覧を表示します。

    kubectl get MutatingWebhookConfiguration -o wide
    

    次の例のような出力になる必要があります。

    NAME                         WEBHOOKS   AGE
    aks-node-mutating-webhook    1          249d
    azure-policy-mutating-webhook-configuration    1          249d
    gatekeeper-mutating-webhook-configuration      1          249d
    

    出力を調べて、変更 Webhook の一覧が正しく表示され、それらの構成が想定どおりであることを確認します。 出力には、各変更 Webhook の名前、Webhook の数、各 Webhook の経過時間が含まれます。

  3. 次のコマンドを実行して、特定のアドミッション コントローラーの具体的な詳細を取得します。

    kubectl get MutatingWebhookConfiguration <mutating-webhook-name> -o yaml
    

    <mutating-webhook-name> は、詳細を取得する変更 Webhook の名前に置き換えます。 このコマンドの出力では、指定した変更 Webhook の構成の YAML 表現が表示されます。

このセクションのコマンドを実行して出力を調べると、Kubernetes クラスター内に検証および変更 Webhook が存在し、想定どおりに構成されていることを確認できます。 この検証は、適切な機能を確認するために不可欠です。 また、Webhook がクラスター内のリソースを検証および変更するためのポリシーに準拠していることを確認するためにも重要です。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

その他の共同作成者:

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。