アドミッション コントローラーを検証する
この記事はシリーズの一部です。 最初に概要をご覧ください。
アドミッション コントローラーが問題の原因になることはほとんどありませんが、適切に機能させることは重要です。 この記事では、正しく機能していないアドミッション コントローラーが他のコンポーネントに与える可能性のある影響について説明します。 また、アドミッション コントローラーのパフォーマンスを検証するために使用できるコマンドについても説明します。
アドミッション コントローラー
アドミッション コントローラーは、Kubernetes API サーバーへの要求を、要求が認証および認可された後て、オブジェクトが永続化される前に、インターセプトするコードです。
アドミッション コントローラーでは、"検証"、"変更"、または両方の組み合わせを行うことができます。 "変更" コントローラーは、要求を受け入れる前に関連オブジェクトを変更できます。 "検証" コントローラーは、要求が特定の定義済みの条件を満たしていることの確認だけを行います。
アドミッション コントローラーの主な機能の 1 つは、オブジェクトの作成、削除、変更に対する要求を調整することです。 さらに、アドミッション コントローラーは、API サーバー プロキシ経由でのポッドへの接続の要求など、カスタム動詞を制限できます。 ただし、アドミッション コントローラーは、get、watch、list などの操作を含め、オブジェクトの読み取り要求をブロックすることはできません。
"変更 Webhook や検証 Webhook" などの一部のコンポーネントは、、アドミッション コントローラーに影響を与える可能性があります。 変更および検証 Webhook を Kubernetes クラスターに組み込む場合は、高可用性を設けることが不可欠です。 異常なノードによって API サーバー要求がブロックされないようにする必要があります。 API サーバーへの要求がブロックされないように、アドミッション制御パイプラインを監視することが重要です。 異常なアドミッション コントローラーは、変更および検証 Webhook に影響を与える可能性があります。 監視する必要がある Webhook ベースのアドミッション コントローラーには、次のものが含まれます。
Gatekeeper を拡張する Azure Kubernetes Service (AKS) クラスター用の Azure Policy アドオン。 Gatekeeper は、Open Policy Agent 用のアドミッション コントローラー Webhook です。
Kubernetes クラスターで動的アドミッション コントローラーとして動作する Kyverno。 Kyverno は、Kubernetes API サーバーから検証と変更のアドミッション Webhook HTTP コールバックを受け取り、一致するポリシーを適用して、アドミッション ポリシーを適用したり、要求を拒否したりする結果を返します。 トラブルシューティングのリファレンス (例: APIServer で Webhook 呼び出しに失敗) については、Kyverno のトラブルシューティングに関するドキュメントを参照してください。
また、適切に機能していないアドミッション コントローラーは、"サービス メッシュ" などのさまざまなコンポーネントに影響を与える可能性があります。 Istio や Linkerd などのサービス メッシュは、アドミッション コントローラーを使って、たとえば、ポッド内のサイドカー コンテナーの挿入を自動化します。 サービス メッシュをシームレスに動作させるには、アドミッション コントローラーが正常に機能していることを評価して検証することが重要です。
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 pod と kubectl 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 が意図したとおりに動作していることを確認するには、次の手順のようにします。
次のコマンドを実行して、クラスター内の検証 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 の経過時間が含まれます。
次のコマンドを実行して、クラスター内の変更 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 の経過時間が含まれます。
次のコマンドを実行して、特定のアドミッション コントローラーの具体的な詳細を取得します。
kubectl get MutatingWebhookConfiguration <mutating-webhook-name> -o yaml<mutating-webhook-name>は、詳細を取得する変更 Webhook の名前に置き換えます。 このコマンドの出力では、指定した変更 Webhook の構成の YAML 表現が表示されます。
このセクションのコマンドを実行して出力を調べると、Kubernetes クラスター内に検証および変更 Webhook が存在し、想定どおりに構成されていることを確認できます。 この検証は、適切な機能を確認するために不可欠です。 また、Webhook がクラスター内のリソースを検証および変更するためのポリシーに準拠していることを確認するためにも重要です。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパルの作成者:
- Paolo Salvatori | プリンシパル カスタマー エンジニア
その他の共同作成者:
- Francis Simy Nazareth | シニア テクニカル スペシャリスト
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
関連リソース
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示