【CNDW2024】初心者から中級者まで学べるPFNのKubernetes Admission Policy実践

CloudNative Days Winter 2024において「実践/先取り入門Kubernetes Validating/Mutating Admission Policy」と題されたセッションには、Preferred Networksの須田一輝氏、京都大学工学部のANSAI SHOMA氏、東京科学大学情報理工学院の大川快氏の各氏が登壇した。同セッションでは、Kubernetesの新機能であるValidating Admission Policy（VAP）およびMutating Admission Policy（MAP）の実践活用と今後の展望について語られている。なお須田氏はPFNのメンバーであり、ANSAI氏と大川氏はPFNインターンシップに参加した学生で、今回共同での調査と発表に臨んでいる。

高性能クラスタ運用とPFCPのマルチテナント管理の工夫

Preferred Networks（PFN）はAI技術において、ソフトウェアとハードウェアを融合させた垂直統合型の取り組みを行っている。その中心にあるのが、社内および外販向けの高性能計算基盤である。須田氏は「近年、さまざまな産業向けやお客様向けに新しいソリューションの提供を積極的に始めています」と説明し、PFNがLLM（Large Language Model、大規模言語モデル）の学習や生成AI分野で幅広い活動を展開していることを語った。その中で、PFCP（Preferred Computing Platform）というクラウドサービスを通じて、自社開発のAIプロセッサ「MN-Core」やGPUクラスタを外部ユーザーに提供している。PFCPは単なる学習用途にとどまらず、推論環境の運用やリソース可視化機能を含めたマルチテナント型のサービスとして運用されている。

そのようなマルチテナント環境では、他のユーザーに影響を与えない厳格な管理が必要である。ここで重要となるのが、マニフェストの検証と変更である。PFNでは、Pod Security Standards（PSS）をベースにしたカスタムポリシーをはじめ、他テナントのリソースに干渉しないルールや、特定サービス仕様を満たすための独自ポリシーを多数運用していることが説明された。

PFNにおけるマニフェストの検証と変更

これらの実現には従来「Validating/Mutating Admission Webhook」を活用してきた。しかしWebhookベースの仕組みは柔軟性がある反面、課題も多い。須田氏は「Webサーバーを自前で実装することは、開発もテストも必要で、ビルド、デプロイ、運用が伴うので大変です」と語り、その負荷と維持コストを具体的に指摘した。さらに須田氏は「外部サーバーにリクエストを飛ばす仕組みのため、APIサーバーのレスポンスがどうしても遅くなってしまうことがありますし、高負荷時にはサーバーが落ちてしまうリスクも抱えています」と、実際の運用現場で直面している課題を説明した。

APIサーバー組み込み型検証機能とその実践的な課題共有

次に大川氏からValidating Admission Policy（VAP）の基礎と実践事例、そして現場で直面している課題が語られた。VAPはKubernetes APIサーバーに標準で組み込まれた機能であり、外部Webhookサーバーを使わずにマニフェストの検証を行える点が大きな強みである。大川氏は「APIサーバーだけで完結できるので、運用負荷やパフォーマンス面でも非常に有利です」とその魅力を語った。

APIサーバーに組み込まれている

またVAPで用いるポリシー記述にはCommon Expression Language（CEL）が採用されており、複雑なロジックを柔軟かつ簡潔に表現できることも強調された。大川氏は「CELのおかげで、従来のWebhookサーバーではコード化しなければならなかったルールを、宣言的にわかりやすく書けるようになりました」と語り、その利便性を改めて紹介した。

実際にPFNで適用しているポリシー例として、ingress-nginxの特定アノテーション利用を禁止するルールが紹介された。一見すると単純な条件に見えるものの、「細かい例外やサービス仕様に対応しようとすると、あっという間に複雑になってしまいます」と大川氏は述べ、現場での実感をにじませた。またカスタムリソースを対象としたポリシーではさらに複雑さが増し、誰が見ても理解できる状態を保つことの難しさを痛感していると語った。「正直なところ、書き換えを行ったあとで本当にこれまで通りの挙動を保てているのか、不安になることも多いです」と語り、保守性や検証環境の整備が不可欠であることを強調した。

ポリシー検証を支えるOSS開発と運用現場の安心感

次に、ANSAI氏がインターンの成果として開発したテストツール「kaptest」について詳しく解説した。複雑化しがちなVAPポリシーの変更やリファクタリング時に安全性を確保する目的で開発されたこのツールは、PFNの2024年夏インターンシップにおいてわずか2週間で完成に至ったものだという。

VAP のテストツール“kaptest”

ANSAI氏は「最初は本当に短い期間で作れるか不安でしたが、複雑なポリシーに手を入れるたびに感じていた不安を少しでも解消できるものを残したいと思って開発に臨みました」と語った。

kaptestは、静的テストを通じて実際のクラスタを立ち上げなくてもポリシーの挙動を検証できる点が大きな特徴だ。設定ファイルにテストケースを定義し、コマンド一発で実行できる手軽さも現場に受け入れられた理由だ。「手元で簡単に試せて『これなら安心して変更できる』と実感できるようになったことが大きな収穫でした」とANSAI氏は振り返り、開発者目線での利便性と安心感を強調した。

新機能としてのMAPとその限界・将来への期待

次に大川氏がMutating Admission Policy（MAP）の概要と検証結果について解説を行った。MAPは、Kubernetes APIサーバーに組み込まれたマニフェスト変更機能であり、従来のMutating Admission Webhookの代替として期待されている。大川氏は「APIサーバー組み込みのため、外部サーバーに頼らずに変更処理が行える点が大きな特徴です」と説明した。

MAPは、Common Expression Language（CEL）を使って変更内容をパッチ形式で記述できる仕組みを持っている。しかし検証を進める中で、いくつか限界も見えてきたという。大川氏は「実際に運用中のWebhookサーバーを置き換えられるかを検証した結果、基本的な処理は可能でしたが、配列操作や関数定義ができないなどCELの制約に直面しました」と述べた。そのため複雑なロジックを書こうとすると冗長になりがちであり、現時点ではすべてをMAPで代替することは難しいと説明された。

それでも、PFNとしては今後の機能拡張に大きな期待を寄せている。大川氏は「公式でもこの制約を認識していて、今後は関数追加などの提案が増えるのではないかと感じています。我々としてもアップストリームへの貢献を視野に入れています」と述べ、検証活動の成果だけでなく、今後コミュニティとともに進化していく可能性を語った。

PFNのMutating Admission Policyへの期待

PFNの実運用知見を通して語られた最新技術の展望と課題

最後に須田氏が登壇し、本セッション全体のまとめを行った。まず、Validating Admission Policy（VAP）については、APIサーバーに組み込まれたマニフェスト検証機能であり、CELを用いて簡潔かつ柔軟にポリシーを記述できることを改めて強調した。v1.30でGAとなり、PFNでもすでに実戦投入済みであることを説明した上で、「静的テストについては、今回紹介したOSSのkaptestを使って安心して運用できます」とメッセージを送った。

続いて、Mutating Admission Policy（MAP）についても触れ、こちらはAPIサーバー組み込みのマニフェスト変更機能としてv1.32でアルファ実装予定であることを紹介した。しかし現時点ではCELの機能が限定的で、複雑な記述は冗長になりやすいことや、静的テストツールが未整備である課題も示した。須田氏は「今後機能が拡張される予定ですし、静的テストツールについてもコミュニティ全体で進化していくことを期待しています」と語り、前向きな展望を示して、セッションを締めくくった。