Slide 1

Slide 1 text

実践/先取り 入門 Validating/Mutating Admission Policy CloudNative Days Winter 2024 (2024/11/28, 29) SUDA Kazuki (@superbrothers), Preferred Networks, Inc. ANSAI Shoma, 京都大学 工学部 情報学科 4年 OKAWA Kai, 東京科学大学 情報理工学院 情報工学系 博士2年 Kubernetes API 組み込みの マニフェスト検証、変更を行う新機能です!

Slide 2

Slide 2 text

SUDA Kazuki / @superbrothers ● Preferred Networks, Inc. / エンジニア ○ 社内向けの ML/DL プラットフォーム開発運用 ○ 外販の AI ワークロード向けクラウドサービス開発運用 ● Kubernetes Meetup Tokyo 共同主催者 ● オライリー書籍 監訳 ○ 「入門 Prometheus」 ○ 「Kubernetes で実践する クラウドネイティブ DevOps」

Slide 3

Slide 3 text

ANSAI Shoma ● 京都大学 工学部 情報学科 4年 ○ 認証・認可に関する研究 ● Golang, React, Ruby on Rails を使った Web 開発 ○ VTuber が歌った曲を自動で集計するセトリサイト ○ https://song-list.piny940.com ● 自宅サーバー上で Kubernetes クラスタ運用 www.piny940.com

Slide 4

Slide 4 text

OKAWA Kai ● 東京科学大学 横田理央研究室 博士2年 ○ コンピュータビジョン・3次元復元に関する研究 ● よく使う言語は C++,Pythhon ● 研究室で運用している GPU クラスタの管理者 ● 最近 Kubernetes を導入

Slide 5

Slide 5 text

アジェンダ ● PFN のオンプレ Kubernetes クラスタ ● Validating Admission Policy ○ 入門 Validating Admission Policy ○ PFN における Validating Admission Policy の実践と課題 ○ Validating Admission Policy テストツール “kaptest” ● Mutating Admission Policy ○ 入門 Mutating Admission Policy ○ Mutating Admission Policy の検証 ● まとめ 5

Slide 6

Slide 6 text

PFN の オンプレ Kubernetes クラスタ

Slide 7

Slide 7 text

7 PFNの事業: AI技術のバリューチェーンを垂直統合 ソリューション・製品 計算基盤 AIチップ PFNは、チップ、計算基盤、生成AI基盤モデル、ソリューション・製品まで、AI技術の バリューチェーンを垂直統合し、ソフトウェアとハードウェアを高度に融合することで、 競争力の高い技術の開発および産業応用を進めています。 生成AI基盤モデル 様々な産業・消費者向けのソリューション・製品 MN-Core™ MN-Core™ 2 GPUクラスタ MN-3 (MN-Core™ クラスタ) PLaMo Prime(今秋提供予定のLLM) PLaMo Lite(エッジ向けSLM) MN-Core 第三世代 MN-Core™ 2を 計算資源とした クラウドサービス 物質のエネルギー計算モデル PFP LLM向け 推論チップ (2026年提供予定) Kubernetes はここ!

Slide 8

Slide 8 text

PFN のオンプレ Kubernetes クラスタ 社内計算基盤 / 生成 AI 向けの最新クラスタ 8 Cloud Native Days Summer 2024 生成AI向け機械学習クラスタ構築のレシピ 北海道石狩編 GPU、MN-Core のオンプレクラスタに加えて、 さくらインターネット様の高火力 PHYを利用したクラスタを新たに構築

Slide 9

Slide 9 text

PFN のオンプレ Kubernetes クラスタ PFCP / AI ワークロード向けのクラウドサービス (1/2) 9 ● PFN が構築、運用する深層学習・AIワークロード向けのクラウドサービス ○ https://pfcomputing.com/ (2024年10月に利用受付を開始) ● PFN が開発する AI プロセッサ “MN-Core 2” をオンデマンドで利用できる ● マルチテナント ○ 1つのクラスタを複数のテナントで利用可能 ● 実験も学習も推論も ○ 学習だけでなく、推論サーバの運用まで幅広いワークロードをサポート 対話型実験環境 分散学習・LLM 推論など

Slide 10

Slide 10 text

PFN のオンプレ Kubernetes クラスタ PFCP / AI ワークロード向けのクラウドサービス (2/2) 10 ● リソース使用状況の可視化 ○ ワークロード状態を観測するためのモニタリングサービスも付随 ● もちろん Kubernetes がベース ○ 深層学習・AI ワークロード向けにカスタマイズ ■ 2018年から機械学習向けの計算基盤としてKubernetes を 活用してきた経験を活かして ワークロード・計算資源監視 管理コンソール

Slide 11

Slide 11 text

PFN のオンプレ Kubernetes クラスタ PFN におけるマニフェストの検証と変更 社内基盤、PFCP ともにマルチテナントでの提供のため、他のテナントの 影響を受けずに利用いただくために独自のマニフェスト検証や変更による ガードレールを運用する必要がある。 ● Pod Security Standards (PSS) をベースとしたカスタムのポリシ ● 他のテナントのリソースに干渉させないためのポリシ ● そのほか、サービス仕様を満たすための様々なポリシ 11 namespace namespace namespace ✅ API サーバで検証と変更を行う!

Slide 12

Slide 12 text

Kubernetes API サーバが外部の Webhook サーバと連携して マニフェストの検証と変更 ● サーバを実装することで柔軟なポリシの適用が可能 ● この機能を利用したサードパーティのアドオン (Kyverno、Gatekeeper等)を利用すればサーバ実装は不要 マニフェスト検証と変更を実現する Validating/Mutating Admission Webhook 12 Mutating Admission Validating Admission Webhook サーバ … … … Webhook サーバ kubebuilder で簡単に 実装できます! MutatingとValidating の処理を 同じサーバに同居できます

Slide 13

Slide 13 text

マニフェスト検証と変更を実現する Validating/Mutating Admission Webhook の課題 13 Webhook サーバの実装やサードパーティアドオン含め運用が必要で、 また外部サーバへのリクエストによるパフォーマンスに課題あり ✅ 新機能である Validating/Mutating Admission Policy を使用することで これらの問題が解決される! Mutating Admission Validating Admission Webhook サーバ … … … Webhook サーバ 実装するということは ビルド、デプロイ、運用が伴う😣 リクエスト増加で パフォーマンス劣化の懸念 高負荷でWebhook サーバが 落ちることも😣

Slide 14

Slide 14 text

入門 Validating Admission Policy

Slide 15

Slide 15 text

Validating Admission Policy (VAP) Kubernetes API サーバ組み込みのマニフェストの検証機能 ● API サーバ組み込み機能で追加の実装や運用が不要 ● Common Expression Language (CEL) でポリシを簡単に記述できる ● v1.30 で GA したので安心して利用できる 15 apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: "demo-policy.example.com" spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["apps"] apiVersions: ["v1"] resources: ["deployments"] operations: ["CREATE", "UPDATE"] validations: - expression: "object.spec.replicas <= 5" apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicyBinding metadata: name: "demo-binding-test.example.com" spec: policyName: "demo-policy.example.com" validationActions: [Deny] matchResources: namespaceSelector: matchLabels: environment: test Deployment リソースの 作成と更新が対象 レプリカ数が5以下だと OK このラベルにマッチする namespace で有効になる 指定がなければクラスタ全体

Slide 16

Slide 16 text

Validating Admission Policy パラメータリソース: ポリシとパラメータの分離 (1/2) 1つのポリシを複数の設定で使い回せる! 16 apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: "demo-policy.example.com" spec: failurePolicy: Fail paramKind: apiVersion: rules.example.com/v1 kind: ReplicaLimit matchConstraints: resourceRules: - apiGroups: ["apps"] apiVersions: ["v1"] resources: ["deployments"] operations: ["CREATE", "UPDATE"] validations: - expression: >- "object.spec.replicas <= params.maxReplicas" apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicyBinding metadata: name: "demo-binding.example.com" spec: policyName: "demo-policy.example.com" validationActions: [Deny] matchResources: namespaceSelector: matchLabels: environment: test paramRef: name: "replica-limit-test.example.com" namespace: "default" apiVersion: rules.example.com/v1 kind: ReplicaLimit metadata: name: "replica-limit-test.example.com" namespace: "default" maxReplicas: 5 params でパラメータを参照 パラメータ指定に カスタムリソースを使用 ConfigMap も使えます! パラメータに使用する カスタムリソース Binding でどのオブジェクトを パラメータとして使用するか指定

Slide 17

Slide 17 text

Validating Admission Policy パラメータリソース: ポリシとパラメータの分離 (2/2) パラメータのオブジェクトが 作成されている namespace と ポリシの適用範囲には関連がないことに注意 apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicyBinding metadata: name: "demo-binding.example.com" spec: policyName: "demo-policy.example.com" validationActions: [Deny] matchResources: namespaceSelector: matchLabels: environment: test paramRef: name: "replica-limit-test.example.com" namespace: "default" prod namespace environment=prod default namespace ReplicaLimit test01 namespace environment=test test02 namespace environment=test

Slide 18

Slide 18 text

Validating Admission Policy API サーバに組み込まれている Webhook サーバ の実装/運用が不要でパフォーマンス課題も解消! 18 Mutating Admission Validating Admission Validating Admission Policies Validating Admission Controllers Validating Admission Webhooks apiVersion: apps/v1 kind: Deployment ... spec: replicas: 3 ✅ object.spec.replicas <= 5 … … … CEL 表現

Slide 19

Slide 19 text

PFN における Validating Admission Policy の 実践と課題

Slide 20

Slide 20 text

PFN における Validating Admission Policy の実践 ingress-nginx の annotations 使用の禁止 20 apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: forbid-ingress-nginx-annotations spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["networking.k8s.io"] apiVersions: ["v1"] resources: ["ingresses"] operations: ["CREATE", "UPDATE"] variables: annotations: "object.metadata.?annotations.orValue({})" validations: - expression: "variables.annotations.filter(k, k.startsWith('nginx.ingress.kubernetes.io/')).size() == 0" message: "cannot set annotations prefixed by 'nginx.ingress.kubernetes.io/'" 変数を定義する機能 とても単純なポリシで ぱっと見でうまく機能しそうなことがわかる カスタムのメッセージも出せる

Slide 21

Slide 21 text

PFN における Validating Admission Policy の実践 カスタムリソースの制御 21 apiVersion: admissionregistration.k8s.io/v1beta1 kind: ValidatingAdmissionPolicy metadata: name: forbid-httpproxy-external-auth-disabled spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["projectcontour.io"] apiVersions: ["*"] resources: ["httpproxies"] operations: ["CREATE", "UPDATE"] variables: - name: annotations expression: "has(object.metadata.annotations) ? object.metadata.annotations : {}" - name: ingressClassInAnn1 expression: "'projectcontour.io/ingress.class' in variables.annotations ? variables.annotations['projectcontour.io/ingress.class'] : ''" - name: ingressClassInAnn2 expression: "'kubernetes.io/ingress.class' in variables.annotations ? variables.annotations['kubernetes.io/ingress.class'] : ''" - name: isContourExternalIngressClass expression: >- has(object.spec.ingressClassName) && object.spec.ingressClassName == 'contour-external' || variables.ingressClassInAnn1 == 'contour-external' || variables.ingressClassInAnn2 == 'contour-external' validations: - expression: "!variables.isContourExternalIngressClass || object.metadata.name.size() < 40" message: "The name of the HTTPProxy with contour-external ingressClass must be less than 40 characters." - expression: "!variables.isContourExternalIngressClass || !has(object.spec.virtualhost.authorization.authPolicy.disabled)" message: "'authorization.authPolicy.disabled' field must not be set." もちろんカスタムリソースも 制御できます ぱっと見ではうまく機能するのかわからない😣 今後の修正/変更が困難かも

Slide 22

Slide 22 text

ValidatingAdmissionPolicy の課題 ポリシが複雑になると、ぱっと見で正しく機能するかどうかわからない ● 複数の variables, validations が登場するポリシになってくると、 期待したように機能するかがわからなくなる ○ 👉 テストしたくなる ● テストしたいくらい複雑なポリシは Webhook サーバで実装して テストコードを書いたほうがよい ○ でもやっぱり Webhook サーバの扱いは面倒 「VAP のポリシをテストできるツールを インターシップで開発してもらおう!」 22

Slide 23

Slide 23 text

Validating Admission Policy の テストツール “kaptest”

Slide 24

Slide 24 text

VAP のテストツール “kaptest” VAP のマニフェストに対してテストケースとなるマニフェストを使って VAP ポリシの評価結果を静的にテストできる ● 2024年の PFN 2週間インターンシップにおいて開発 ● OSS として GitHub で公開 ○ https://github.com/pfnet/kaptest ● 紹介記事をブログエントリで公開 ○ Kubernetes の Validating Admission Policy のテストツールを開 発しました 24

Slide 25

Slide 25 text

VAP のテストツール “kaptest” 使い方 コマンドラインツールとしてテストを実行 25 # kaptest.yaml validatingAdmissionPolicies: - ../vap.yaml resources: - resources.yaml testSuites: - policy: simple-policy tests: - object: kind: Deployment name: good-deployment expect: admit - object: kind: Deployment name: bad-deployment expect: deny - policy: error-policy tests: - object: kind: Deployment name: good-deployment expect: error # スケルトンファイルの生成 $ kaptest init vap.yaml $ tree vap.test/ vap.test/ ├── kaptest.yaml └── resources.yaml # テストの実行 $ kaptest run vap.test/kaptest.yaml 特徴 ● クラスタなしに静的にテストできる ● Kubernetes がサポートする独自 CEL 関数を 使用したポリシもテストできる

Slide 26

Slide 26 text

VAP のテストツール “kaptest” 実践: ポリシのリファクタリング 26 variables: - name: annotations expression: "has(object.metadata.annotations) ? object.metadata.annotations : {}" - name: ingressClassInAnn1 expression: "'projectcontour.io/ingress.class' in variables.annotations ? variables.annotations['projectcontour.io/ingress.class'] : ''" - name: ingressClassInAnn2 expression: "'kubernetes.io/ingress.class' in variables.annotations ? variables.annotations['kubernetes.io/ingress.class'] : ''" - name: isContourExternalIngressClass expression: >- has(object.spec.ingressClassName) && object.spec.ingressClassName == 'contour-external' || variables.ingressClassInAnn1 == 'contour-external' || variables.ingressClassInAnn2 == 'contour-external' variables: - name: isContourExternalIngressClass expression: >- object.spec.?ingressClassName == optional.of('contour-external') || object.metadata.?annotations['projectcontour.io/ingress.class'] == optional.of('contour-external') || object.metadata.?annotations['kubernetes.io/ingress.class'] == optional.of('contour-external') CEL Optional Values を使用してリファクタ(v1.29〜) テストツールがあることで安心して書き換えられる!

Slide 27

Slide 27 text

入門 Mutating Admission Policy

Slide 28

Slide 28 text

Mutating Admission Policy Kubernetes API サーバ組み込みの マニフェストの変更機能 ● VAP と同様に CEL を使用してポリシを記述 ● v1.32 に Alpha レベルで追加予定の新機能 28 apiVersion: admissionregistration.k8s.io/v1alpha1 kind: MutatingAdmissionPolicy metadata: name: "demo-policy.example.com" spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: [""] apiVersions: ["v1"] resources: ["pods"] operations: ["CREATE"] mutations: - patchType: ApplyConfiguration applyConfiguration: expression: >- Object{ metadata: Object.metadata{ labels: {"environment": "test"} } } apiVersion: admissionregistration.k8s.io/v1alpha1 kind: MutatingAdmissionPolicyBinding metadata: name: "demo-binding.example.com" spec: policyName: "demo-policy.example.com" matchResources: namespaceSelector: matchLabels: environment: test オブジェクトを書き換えるのではなく パッチを書きます VAP と同様に 有効にする範囲を指定

Slide 29

Slide 29 text

Mutating Admission Policy パラメータリソース: ポリシとパラメータの分離 VAP と同様に1つのポリシを複数の設定で使い回せる! 29 apiVersion: admissionregistration.k8s.io/v1alpha1 kind: MutatingAdmissionPolicy metadata: name: "demo-policy.example.com" spec: paramKind: apiVersion: rules.example.com/v1 kind: Environment failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: [""] apiVersions: ["v1"] resources: ["pods"] operations: ["CREATE"] mutations: - patchType: ApplyConfiguration applyConfiguration: expression: >- Object{ metadata: Object.metadata{ labels: {"environment": params.value} } } apiVersion: admissionregistration.k8s.io/v1alpha1 kind: MutatingAdmissionPolicyBinding metadata: name: "demo-binding.example.com" spec: policyName: "demo-policy.example.com" paramRef: name: "environment-test.example.com" namespace: "default" matchResources: namespaceSelector: matchLabels: environment: test apiVersion: rules.example.com/v1 kind: Environment metadata: name: "environment-test.example.com" namespace: "default" value: test パラメータ指定に使用する リソースを指定 パラメータで変数化 パラメータとして使用する オブジェクトの指定

Slide 30

Slide 30 text

Mutating Admission Policy API サーバに組み込まれている 同じくWebhook サーバ の実装/運用が不要でパフォーマンス課題も解消! 30 Mutating Admission Validating Admission Mutating Admission Policies Mutating Admission Controllers Mutating Admission Webhooks apiVersion: v1 kind: Pod metadata: name: app apiVersion: v1 kind: Pod metadata: name: app labels: environment: test Object{ metadata: Object.metadata{ labels: {"environment": "test"} } } … … … CEL 表現

Slide 31

Slide 31 text

Mutating Admission Policy PFN の Mutating Admission Policy への期待 既存の Webhook サーバ実装を置き換えられるのか ● PFN 2024夏季インターンシップで先行して調査、検証を実施 ○ Kubernetes に機能追加されていない (24年8月時点) ○ プロポーザルとプルリクエストで実装中のコードを使用 ● 検証結果をブログエントリで公開 ○ Kubernetes Mutating Admission Policyの調査、検証 31

Slide 32

Slide 32 text

Mutating Admission Policy の 機能検証 (24年8月時点)

Slide 33

Slide 33 text

Mutating Admission Policy の機能検証 (24年8月時点) 実際に開発運用している Webhook サーバの実装の一部を対象として 置き換えられるのかどうかを検証 ● 検証のポイント ○ 置き換えできるかどうか ○ 置き換えられる場合に無理なく達成できるかどうか(可読性等 ○ 置き換えられない場合に何が足りないか ● 検証対象のポリシ 1. 環境変数 NVIDIA_VISIBLE_DEVICES に none を強制 ○ GPU を要求していない Pod で GPU を見えなくする 2. RDMA ジョブの設定自動化 3. 拡張リソースの要求有無をラベルに付与 33

Slide 34

Slide 34 text

Mutating Admission Policy の機能検証: 環境変数 NVIDIA_VISIBLE_DEVICES に none を強制 Pod マニフェスト変更の期待値 34 apiVersion: v1 kind: Pod ... spec: containers: - name: app1 ... - name: app2 resources: limits: nvidia.com/gpu: 0 ... - name: app3 resources: limits: nvidia.com/gpu: 1 ... apiVersion: v1 kind: Pod ... spec: containers: - name: app1 env: - name: NVIDIA_VISIBLE_DEVICES value: none ... - name: app2 resources: limits: nvidia.com/gpu: 0 env: - name: NVIDIA_VISIBLE_DEVICES value: none ... - name: app3 resources: limits: nvidia.com/gpu: 1 ... GPU を要求していない コンテナ 環境変数を設定 GPU を要求している コンテナには設定しない

Slide 35

Slide 35 text

Mutating Admission Policy の機能検証: 環境変数 NVIDIA_VISIBLE_DEVICES に none を強制 Webhook サーバ実装と CEL 記述の比較 35 func (m *mutator) mutate(_ context.Context, logger logr.Logger, pod *corev1.Pod) error { m.mutateContainers(logger, pod.Spec.InitContainers) m.mutateContainers(logger, pod.Spec.Containers) return nil } func (m *mutator) mutateContainers(logger logr.Logger, containers []corev1.Container) { for i, ctr := range containers { gpu := ctr.Resources.Limits["nvidia.com/gpu"] if gpu.CmpInt64(0) == 0 { envs := m.mutateEnv(ctr.Env) ctr.Env = envs } containers[i] = ctr } } func (m *mutator) mutateEnv(envs []corev1.EnvVar) []corev1.EnvVar { found := false for i, env := range envs { if env.Name == "NVIDIA_VISIBLE_DEVICES" { found = true if env.Value != "none" { env.Value = "none" envs[i] = env } } } if !found { envs = append(envs, corev1.EnvVar{ Name: "NVIDIA_VISIBLE_DEVICES", Value: "none", }) } return envs } Object { spec: Object.spec{ initContainers: object.spec.?initContainers.orValue([]).filter( ct, quantity(ct.resources.?limits['nvidia.com/gpu'].orValue("0")).asInteger() == 0 ).map(ct, Object.spec.containers { name: ct.name, env: [Object.spec.containers.env { name: 'NVIDIA_VISIBLE_DEVICES', value: 'none', }] }), containers: object.spec.?containers.orValue([]).filter( ct, quantity(ct.resources.?limits['nvidia.com/gpu'].orValue("0")).asInteger() == 0 ).map(ct, Object.spec.containers { name: ct.name, env: [Object.spec.containers.env { name: 'NVIDIA_VISIBLE_DEVICES', value: 'none', }] }) } } ✅ パッチを用意すればよいので簡潔 ❌ 関数定義できないので冗長になりがち ❌ 静的テストツールがない(kaptest に期待) コンテナに対する処理を共通化したいが 関数が定義できない😣

Slide 36

Slide 36 text

Mutating Admission Policy の機能検証 (24年8月時点) CEL の限界 できないことがまだまだある ● List から Map を作成できない ● 配列の結合ができない CEL は停止性を保証する等の理由から非チューリング完全で機能が限定的 ● CEL の Kubernetes 拡張に独自機能を追加して対応 ● 今後必要に応じてアップストリームにプルリクエスト作成を検討 36

Slide 37

Slide 37 text

まとめ

Slide 38

Slide 38 text

まとめ 入門 Validating/Mutating Admission Policy Validating Admission Policy ● API サーバ組み込みのマニフェストの検証機能 ● CEL でポリシを簡単に記述できる ● v1.30 で GA したので安心して利用できる ● PFN ではすでに実戦投入済み ● 静的テストには OSS の kaptest が使える Mutating Admission Policy ● API サーバ組み込みのマニフェストの変更機能 ● v1.32 で Alpha レベルで追加予定 ● CEL の機能が限定的で、記述が冗長になりがち ● 24年11月時点で静的テストツールがなく今後に期待 38 apiVersion: admissionregistration.k8s.io/v1 kind: ValidatingAdmissionPolicy metadata: name: "demo-policy.example.com" spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: ["apps"] apiVersions: ["v1"] resources: ["deployments"] operations: ["CREATE", "UPDATE"] validations: - expression: "object.spec.replicas <= 5" apiVersion: admissionregistration.k8s.io/v1alph kind: MutatingAdmissionPolicy metadata: name: "demo-policy.example.com" spec: failurePolicy: Fail matchConstraints: resourceRules: - apiGroups: [""] apiVersions: ["v1"] resources: ["pods"] operations: ["CREATE"] mutations: - PatchType: ApplyConfiguration mutation: >- Object{ metadata: Object.metadata{ labels: {"environment": "test"} }

Slide 39

Slide 39 text

We’re hiring! Preferred Networks の基盤技術グループでは採用を実施中です! ● 機械学習プラットフォームエンジニア Kubernetes, 社内向け機械学習プラットフォーム、外販クラウドサービスの開発運用 キーワード: K8s, オンプレ, GPU, Observability, MLOps, HPC, スケジューラ, AWS,       Front/Backend, コンテナネットワーク, データセンタネットワーク, RDMA, RoCE v2 ● ストレージエンジニア ストレージの企画設計管理運用 ● 大規模計算基盤エンジニア/ネットワーク・インフラ運用エンジニア クラスタの物理設計、MN-Core™ を含めた先端システム設計等 39 カジュアル面談にお気軽にご応募ください

Slide 40

Slide 40 text

Appendix ● Kubernetes の Validating Admission Policy のテストツールを開発しました - Preferred Networks Research & Development ● Kubernetes Mutating Admission Policyの調査、検証 - Preferred Networks Research & Development ● Validating Admission Policy | Kubernetes ● CEL | Common Expression Language ● Common Expression Language in Kubernetes | Kubernetes ● kaptest: Kubernetes Admission Policy TESTing tool ● Mutating Admission Policies · Issue #3962 · kubernetes/enhancements ● KEP-3962: MutatingAdmissionPolicy Alpha by jpbetz · Pull Request #127134 · kubernetes/kubernetes 40