Kubernetesで大規模なAI/MLワークロードを実行することは、特にしっかりとした計画が立てられていない場合、リソース割り当て、セキュリティのハードル、監視の要求の迷路をナビゲートしているように感じることがあります。 確かに、画像認識や解約予測などのニューラル ネットワーク タスクを見るのはエキサイティングですが、クラスターを限界まで押し上げることへの懸念は常にあります。
MLOps は、モデルの作成、テスト、リリースを追跡するのに役立つ一連のアイデアとツールとして、データ サイエンティスト、DevOps 担当者、セキュリティ チームの間のギャップを埋める、ここでのフレンドリーなアンカーです。 緊密なコラボレーションが促進されるため、あるチームのデータサイエンティストと別のチームのKubernetesの第一人者は、お互いを踏むことなく自信を持ってモデルを更新できます'のつま先。 MLOps とコンテナー オーケストレーションが出会うと、AI パイプラインを制御するためのより予測可能な方法が得られます。
この記事の目的は、Kubernetes で複雑な AI タスクを実行するためのベスト プラクティスを共有することです。 私たち'スケーリング、スケジューリング、セキュリティ、リソース管理、および経験豊富なプラットフォームエンジニアやKubernetesの機械学習に足を踏み入れたばかりの人々にとって重要なその他の要素について説明します。 各セクションを歩くことで、'クラスターを保護するための実用的なヒントをピックアップします。 AIセキュリティリスクコストを抑え、モデルが切望するコンピューティング能力を提供します。
Kubernetesの安全なコーディングプラクティス[チートシート]
この 10 ページのチート シートは、インフラストラクチャとプラットフォームの開発者がコンテナ化されたアプリケーションを保護するための高度で実用的なガイダンスを提供します。
PDFのダウンロード
リソース管理
トレーニングまたは推論のためにコンテナをスピンアップする前に、クラスターリソースがワークロードの強度と一致していることを確認することが重要です。 結局のところ、GPU の要求を無視したり、適切な CPU サイジングをスキップしたりすると、パフォーマンスが低下し、メモリ不足がランダムに発生し、チームが失望します。
GPU と特殊なハードウェアの割り当て
GPU、TPU、その他のアクセラレータは、クラスター内のスポーツカーのようなものです'のガレージ。 これにより、大規模なモデルをトレーニングしたり、推論中に膨大なスループットを処理したりできます。 これらのハードウェアリソースをポッド内で利用できるようにするには、Kubernetes が提供するデバイスプラグインに依存します。 たとえば、 公式のNVIDIAデバイスプラグインでは、Pod ごとに GPU スライスをリクエストできます。
重要なヒントを 1 つ? 適切なリソース要求を設定すると、スケジューラは正しい GPU を備えた適切なノードを確実に検出します。 これらのリソース定義をスキップすると、ワークロードがアクセラレータのないノードに到達し、ジョブが失敗する可能性があります。 また、GPU ノードに nvidia.com/gpu=true などのラベルを付けて、nodeSelector や nodeAffinity を介して簡単にターゲットにすることもできます。
次のコード スニペットは、NVIDIA から 1 つの GPU を要求する基本的なポッド仕様を示しています。
apiバージョン: v1
種類: ポッド
メタデータ:
名前: gpu-training-pod
仕様：
コンテナー：
- 名前: gpu-training-container
画像:nvcr.io/nvidia/tensorflow:22.01-tf2-py3
リソース：
切り：
nvidia.com/gpu:1
nodeSelectorを使用します。
nvidia.com/gpu: "真"CPU とメモリのサイズ設定
すべてのデータパイプラインまたはモデルトレーニングジョブにGPUが必要なわけではありません。 多くのタスクは、サイズが正しく設定されていれば、CPU で完全に正常に実行されます。 リクエストと制限を設定することで、Kubernetes スケジューラはノードに収まるポッドの数を認識します。 これらのパラメーターがないと、スケジューリングが不十分になったり、ポッドが同じ CPU コアをめぐって競合したりするリスクがあります。 スケジューリングを次のレベルに引き上げるには、 クラスターの自動スケーリング トラフィックやトレーニングジョブの突然の急増を吸収します。
Prometheus などの監視システムを使用して、実際の使用状況の指標を注意深く監視することを忘れないでください。 Pod が常に 90% の CPU に達する場合は、リクエストをわずかに調整します。 逆に、ポッドの CPU 使用率が 20% 前後にとどまれば、リクエストを減らすことができます。
次に、CPU とメモリの要求と制限を定義するデプロイの例を示します。
apiVersion: apps/v1
kind: デプロイメント
メタデータ:
名前: ml-inference-deployment
仕様：
レプリカ: 2
テンプレート：
仕様：
コンテナー：
- 名前: ml-inference-container
画像: your-registry/ml-inference:latest
リソース：
要求：
CPU: "500メートル"
記憶： "512マイル"
切り：
CPU: "1000メートル"
記憶： "1024マイル"AI/ML ワークロードのスケーリング
一度'リソースを要求して割り当てる方法が決まったので、次は拡張します。 一部のシナリオでは、推論ポッドを水平方向にスケーリングして、急増した受信リクエストを処理することがあります。 また、特殊なノードの種類を必要とする可能性のある大規模なトレーニングジョブをスケジュールする場合もあります。
水平および垂直スケーリング
水平スケーリングは、特に推論エンドポイントの場合、予測不可能なユーザー負荷に対処するために必要なものです。 設定するのがベストプラクティスです HPA CPU または GPU の使用状況を監視し、状況が熱くなったら新しいポッドをスピンアップします。 それでも、コンテナが単一ノードでより多くのメモリまたは CPU コアを必要とする場合は、垂直スケーリングの方が良い答えになる可能性があります。 垂直ポッド オートスケーラー (VPA) は、時間の経過とともに安定したワークロードの要求を微調整するのに役立ちます。
ここは's は、CPU 使用率でデプロイメントを参照する HPA のスニペットです。
apiVersion: 自動スケーリング/v2
種類: HorizontalPodAutoscaler
メタデータ:
名前: inference-hpa
仕様：
scaleTargetRef を呼び出します。
apiVersion: apps/v1
kind: デプロイメント
名前: inference-deployment
最小レプリカ: 2
最大レプリカ数: 15
メトリック：
- タイプ: リソース
資源：
名前: CPU
ターゲット：
タイプ: 使用率
平均使用率: 75バッチ ジョブとスケジューリング
大規模なトレーニングは、多くの場合、バッチ プロセスとして優れています。 パイプラインを簡素化するには、1 回限りの実験には Kubernetes ジョブを使用し、夜間の再トレーニングなどのスケジュールされたタスクには CronJobs を使用します。 このアプローチを採用することで、ジョブの実行が成功するたびに、モデルまたは成果物をどこかに自動的に保存して、さらに使用できるようになります。
適切に構造化されたバッチジョブにより、実行時間の長いトレーニングタスクがクラスターノードに過負荷をかけることはありません。 これを実現するには、他のポッドと同じ方法で GPU または CPU リソースを要求し、それらを効果的に管理できます。
以下は、夜間のトレーニングランを開始するCronJobです。
apiVersion: バッチ/v1
種類: CronJob
メタデータ:
名前: nightly-model-training
仕様：
計画： "0 2 * * *"
jobTemplate を使用します。
仕様：
テンプレート：
仕様：
コンテナー：
- 名前: training-container
画像: your-registry/training-image:latest
リソース：
切り：
nvidia.com/gpu:1
コマンド: ["ニシキヘビ", "train.py"]
restartPolicy: なしマルチクラスターおよびハイブリッド戦略
場合によっては、ワークロードを複数の Kubernetes クラスター、特に冗長性が必要な場合や、一部のジョブをオンプレミスで実行し、他のジョブをクラウドで実行する場合に使用します。 これにより、コストを節約し、リスクを軽減できます。 次のようなツール アントス ジョブの分散方法を示す管理コンソールを提供します。 もしあれば'ある環境で問題が発生した場合、別の環境にフェイルオーバーできるため、次の環境で安心できます。'重要なユーザー向け推論タスクをやりくりします。
ストレージとデータ管理
ジョブを効率的に拡張できるようになると、データが中心になります。 どこに保存されますか? どれくらい早く読めますか? どのようにバックアップしますか? これらの質問は、大規模なトレーニングデータセットを扱うときによく現れ、データ取得がボトルネックになるのを防ぐために重要です。
ハイパフォーマンス・ストレージ・クラス
SSD に支えられた StorageClass は、読み取り/書き込み需要が大きいワークロードのトレーニングに最適です。 これらを最大限に活用するには、適切な StorageClass を参照する PersistentVolumeClaim (PVC) と、バッキングストレージに適したクラスタープロビジョニングを定義します。 また、読み取り/書き込み IOPS (1 秒あたりの入出力操作数) を必ず監視して、ストレージボリュームが必要なスループットを処理できることを確認してください。
以下は、高性能ストレージクラスを求めるPVCです。
piバージョン: v1
種類: PersistentVolumeClaim
メタデータ:
名前:FAST-PVC
仕様：
accessModes を呼び出します。
- ReadWriteOnce (読み取り)
storageClassName: 高性能 SSD
リソース：
要求：
ストレージ:100Giデータの局所性とキャッシング
分散トレーニングでは、データの局所性が重要です。 ワーカーがリモート ボリュームからデータを取得すると、ネットワーク遅延によって速度が低下する可能性があります。 解決策は? リモートストレージの前にキャッシュレイヤーを配置するか、ノードローカルSSDボリュームを選択します。 別の戦略は、データの読み取りと書き込みを処理するキャッシュサイドカーコンテナを同じポッドで実行し、特定のワークフローのパフォーマンスを向上させることです。
次のスニペットは、トレーニング データのキャッシュを提供するサイドカー コンテナを示しています。
apiVersion: apps/v1
kind: デプロイメント
メタデータ:
名前: training-deployment
仕様：
レプリカ: 2
セレクタ：
matchLabels:
アプリ: training-app
テンプレート：
メタデータ:
ラベル：
アプリ: training-app
仕様：
コンテナー：
- 名前: caching-sidecar
画像: your-registry/caching-sidecar:latest
volumeMountsを呼び出します。
- 名前: cache-volume
マウントパス: /cache
- 名前: training-container
画像: your-registry/training-image:latest
volumeMountsを呼び出します。
- 名前: cache-volume
マウントパス: /dataset
ボリューム：
- 名前: cache-volume
emptyディレクトリ: {}バックアップとバージョン管理
モデルバージョンの追跡が標準であるのには正当な理由があります。新しいモデルが本番環境で失敗した場合(まあ、それは起こります!)、頻繁にロールバックする必要があります。 モデル・アーティファクトをオブジェクト・ストレージに保存するだけでなく、スケジュール・バックアップを実行することも重要です。 たとえあなたが'自動バックアップを提供するクラウド サービスを再使用する場合は、将来の問題を防ぐために追加のバックアップを行う方法です。
以下は Argoワークフロー モデルアーティファクトを S3 のリモートバケットにアップロードします。
apiVersion: argoproj.io/v1alpha1
kind: ワークフロー
メタデータ:
生成名: model-backup-
仕様：
エントリポイント: backup-model
テンプレート：
- 名前: backup-model
コンテナ：
イメージ: your-registry/backup-tool:latest
コマンド: ["バックアップ・モデル"]
引数: ["--モデルパス=/モデル", "--destination=s3://ml-backups"]セキュリティに関する考慮事項
私たち'クラスターが乗っ取られたり、データが流出したりするという見出しは、2024 年 5 月のように見たことがあるでしょう。 ハギングフェイスでの不正アクセス事件 攻撃者がAIモデルホスティングプラットフォームを標的にした場所。 これらの侵害は、その理由を浮き彫りにしています Kubernetes のセキュリティ そして AIセキュリティ が大きな優先事項となっている。 コンテナ化されたワークロードと高度な ML パイプラインを組み合わせると、脅威ベクトルは急速に増殖します。 させる'これらのリスクを抑制するためのいくつかの方法について説明します。
25人のAIエージェント。 257回のリアルアタック。 勝者は誰?
ゼロデイ発見からクラウド特権のエスカレーションまで、25のエージェントとモデルの組み合わせを257の実際の攻撃的セキュリティ課題でテストしました。 結果は驚く👀かもしれません
Kubernetesセキュリティの基礎
セキュリティを強化するには、次のベスト プラクティスに従います。
コンテナーイメージのスキャン 展開前に脆弱性を検出します。
ロールベースのアクセス制御 (RBAC) を適用する を使用して、ワークロードをデプロイ、変更、または削除できるユーザーを制限します。
ポッドセキュリティ標準(PSS)の適用 クラスタを脅威にさらす可能性のある設定ミスを防止します。
アクセスを制限する コンテナー・レジストリー 不正な変更を監視します。
安定した参照で画像にタグを付ける 検証済みのバージョンのみが本番環境で使用されるようにします。
ここは'は、名前空間に最小限の権限を付与する RBAC スニペットです。
kind: ロール
apiVersion: rbac.authorization.k8s.io/v1
メタデータ:
ネームスペース:ml-project
名前: ml-project-role
準則：
- apiグループ: ["", "アプリ"]
リソース: ["ポッド", "展開"]
動詞: ["取得", "リスト", "創造する", "更新", "削除"]
---
種類: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
メタデータ:
名前: ml-project-rolebinding
ネームスペース:ml-project
氓：
- 種類: ユーザー
名前: ml-user
apiグループ: rbac.authorization.k8s.io
roleRef を呼び出します。
kind: ロール
名前: ml-project-role
apiグループ: rbac.authorization.k8s.ioモデルの整合性の保護
AI モデルがより強力になり、広く展開されるにつれて、敵対的攻撃、データポイズニング、ディストリビューション ドリフトの標的にもなります。 攻撃者はトレーニング データを操作して、モデルのパフォーマンスを損なったり、モデルのロジックの弱点を悪用したりする可能性があります。
これらの脅威を軽減するには、受信データの異常を監視し、ドリフト検出ツールを使用してモデルの実際のパフォーマンスが低下し始めた時期を特定し、精査されたデータセットでのみトレーニング (または再トレーニング) します。 この警戒を維持することで、進化する脅威に直面してもモデルの正確性と回復力を維持できます。
以下は、Alibi Detect ライブラリを使用してデータ ドリフトを検出する方法を示すサンプル Python スニペットです。
alibi_detect.cdからKSDriftをインポートします
numpyをnpとしてインポートする
# 参照データ(例:ベースライントレーニングデータ)
X_ref = np.random.rand(1000, 10)
# 新しい受信データ(ライブトラフィックサンプルなど)
X = np.random.rand(1000, 10) # 実際の生産データに置き換える
# ドリフト検出器を初期化する
cd = KSDrift(X_ref、p_val=0.05)
# ドリフトチェックを実行する
preds = cd.predict(X)
プレド['data_drift']:
print("データドリフトが検出されました! P値:"、プレド['p_val'])
# オプションで、再トレーニングパイプラインまたはアラートをトリガーします
然も無くば：
print("データドリフトは検出されません。 P値:"、プレド['p_val'])イメージの署名
モデルの整合性を維持するための手順を実行したら、次の防御レイヤーは、モデルアーティファクトを保持するコンテナーイメージに署名して、モデルの信頼性を確認することです。 次のようなツール 連署 デジタル署名を簡単に追加できるようにし、保存時の暗号化とトレーニングデータの保管過程により、特に規制された業界でエコシステムをさらに保護できます。
コンテナイメージには、簡単な Cosign コマンドで署名できます。
$ cosign sign --key cosign.key your-registry/your-image:tagさらに、CI パイプラインに自動コード スキャン ステップを追加します。 これにより、依存関係の潜在的な脆弱性が本番環境に到達する前に発見できます。 以下は、オープンソースのセキュリティスキャナーであるTrivyをGitHub Actionsパイプラインに統合するコードスニペットです。
名前: code-scanning-workflow
オン: [push, pull_request]
ジョブ：
スキャン：
実行オン:ubuntu-latest
ステップス：
- 用途:アクション/checkout@v2
- 名前: Scan with Trivy
用途:aquasecurity/trivy-action@master
で：
image-ref です。 "your-registry/your-image:latest"
形式： "テーブル"ネットワークの分離とゼロトラスト
AI ワークロードのセキュリティ保護は、強力なネットワーク分離から始まります。 効果的なアプローチの 1 つは、 ネットワークポリシー どのポッドと 名前空間 お互いにコミュニケーションをとることができます。 それを超えて、'同じクラスター内の他のアプリケーションと一緒に AI/ML ワークロードを実行しないようにするためのベスト プラクティス。 推論サービスを一般的なWebアプリケーションから分離するなど、目的に基づいてワークロードをセグメント化することで、侵害が発生した場合のラテラルムーブメントのリスクを最小限に抑えることができます。
このアプローチはゼロトラスト原則に沿っており、ネットワークトラフィックのすべての部分が慎重に扱われます。'はクラスタ内部にあります。 これらのガードレールは、強力なIDアクセス管理と組み合わせることで、偶発的なデータ漏洩や侵入の試みを防ぐのに役立ちます。
ここは's は、トラフィックを推論名前空間のみに制限する NetworkPolicy です。
apiVersion: networking.k8s.io/v1
種類: NetworkPolicy
メタデータ:
名前: allow-namespace-traffic
ネームスペース:推論[ねーむすぺーす:推論]
仕様：
ポッドセレクター: {}
イングレス：
-差出人：
- namespaceSelector:
matchLabels:
目的: 推論エンドツーエンドの可視性: コードからランタイムまで
AI/ML ワークロードは、コード開発からランタイム実行まで、ライフサイクル全体にわたる複雑なセキュリティとコンプライアンスの課題をもたらします。 完全な可視性がなければ、設定ミス、脆弱性、ドリフトがKubernetesクラスターに忍び込み、侵害のリスクが高まる可能性があります。
これに対処するために、チームはAIパイプラインのすべての段階をカバーするセキュリティ戦略を必要としています:コードとしてのインフラストラクチャ(IaC)構成のスキャン、コンテナイメージの保護、 ランタイム保護の適用そして 継続的な監視 異常の場合。 パイプライン全体にセキュリティ制御を統合することで、AI ワークロードの回復力とコンプライアンスを維持できます。
Wiz は、クラスター全体の脆弱性、コンプライアンスの問題、セキュリティ体制をリアルタイムで追跡できるプラットフォームを提供します。 Wiz ダッシュボードを利用して、コンテナ イメージの問題、構成ミス、さらには 秘密 コードに潜んでいる:
可観測性:監視、ロギング、トレース
機械学習ワークロード用にクラスターをチューニングする場合、'が起こっています。 つまり、ポッドからメトリクスを収集し、ログを一元化された場所に保存し、マイクロサービス全体でリクエストを追跡します。 徹底したオブザーバビリティにより、何かが不発になった場合のトラブルシューティングが簡単になります。
メトリクスとアラート
Prometheus は通常、監視スタックの中心に位置し、主要なパフォーマンス メトリックの追跡に役立ちます。 AI/ML 運用をスムーズに行うには、次のツールを組み合わせて使用します。
プロメテウス モデル推論サービスから CPU、メモリ、GPU 使用率のメトリクスを収集します。
グラファナ クラスターのパフォーマンスを視覚化し、異常を検出するためのリアルタイムダッシュボードを提供します。
アラートルール リソース使用量が定義されたしきい値を超えると、通知 (Slack アラートなど) を自動的にトリガーします。
以下は、GPU の使用率が高い場合にアラートを生成する PrometheusRule です。
以下は、GPU の使用率が高い場合にアラートを生成する PrometheusRule です。
apiVersion: monitoring.coreos.com/v1
種類: PrometheusRule
メタデータ:
名前: gpu-usage-rules
ネームスペース:モニタリング[ねーむすぺーす:モニタリング]
仕様：
グループ：
- 名前:gpu-alerts
準則：
- アラート: HighGPUUsage
expr:nvidia_gpu_utilization > 90
用途: 5m
ラベル：
重大度: 警告
注釈：
概要： "高い GPU 使用率が検出されました"分散トレーシングとパフォーマンスインサイト
OpenTelemetry は、特に AI パイプラインに複数のマイクロサービスが含まれている場合、分散トレースに最適です。 各サービスはトレーススパンを出力し、ボトルネックが存在する可能性のある場所を特定するのに役立ちます。 このアプローチは、データ処理フローの遅いリクエストやランダムなパフォーマンスの異常をデバッグする場合に非常に貴重です。
OpenTelemetry Collector と Jaeger が連携して、AI/ML ワークロードのエンドツーエンドのトレースとパフォーマンスに関するインサイトを提供する方法は次のとおりです。
セキュリティとパフォーマンスをWizと関連付ける
場合によっては、パフォーマンスの低下がセキュリティ関連のイベントに関連していることがあります。 Wiz は、セキュリティの調査結果とパフォーマンス データをブレンドすることで、その相関関係を確認するのに役立ちます。 疑わしいプロセスが GPU リソースを占有しているか、既知の脆弱性がクラスターの不安定性につながっている可能性があります。 これらのパターンが表示されると、Wiz は即時修正を促します。
🚨Kubernetesセキュリティ研究報告書 2025
20万+クラウドアカウントからの新たな洞察が、Kubernetes環境における最新のリスク、攻撃傾向、セキュリティギャップを明らかにします。
PDFのダウンロード
AI/ML ワークフローの CI/CD
トレーニングされたモデルの出荷には、単にファイルをコピーするだけでは不十分であることは誰もが知っています。 ML アーティファクトのビルド、テスト、デプロイを完全に自動化したいと考えています。 ここで CI/CD パイプラインが役に立ちます。 テストを実行し、イメージをスキャンし、レジストリにプッシュし、新しいバージョンを本番環境にロールアウトするタスクをチェーンできます。
モデルのライフサイクル管理の自動化
次のようなツール テクトン 又は Argo ワークフロー データの準備からトレーニング、デプロイまで、モデルのライフサイクル全体のパイプラインを定義できます。 各ステージは、変更をコミットするたびに自動的にトリガーされるため、プロセスの一貫性が保たれます。 また、検証チェックを追加して、モデルを本番用にタグ付けする前に、モデルが事前定義された精度しきい値を満たしていることを確認することもできます。 これにより、パフォーマンスの低いモデルがデプロイされ、ユーザー エクスペリエンスに影響を与えるのを防ぐことができます。
以下は Tekton PipelineRun これにより、モデルの構築とデプロイが開始されます。
apiVersion: tekton.dev/v1beta1
種類: PipelineRun
メタデータ:
名前: ml-pipeline-run
仕様：
pipelineRef を呼び出します。
名前: ml-build-deploy-pipeline
ワークスペース:
- 名前: shared-data
volumeClaimTemplate を使用します。
仕様：
アクセスモード: ["ReadWriteOnce (読み取り)"]
リソース：
要求：
ストレージ:5Gi
パラメータ:
- 名前: model-name
価値： "my-ml-モデル"不変のアーティファクトと GitOps
コミットハッシュで画像にタグを付けると便利で、コードまたはモデルのバージョンを正確に把握できます'再実行。 GitOps は、Kubernetes マニフェストを Git リポジトリに保存できるようにすることで、そのプラクティスを拡張します。 これらのマニフェストに対する変更は、制御された方法でクラスターに自動的に適用されます。 この方法は、いつ、なぜ変更が起こったのかを正確に追跡するのに役立ちます。
ここは's と Argo CDアプリケーション デプロイメント構成を管理するために Git リポジトリを参照します。
apiVersion: argoproj.io/v1alpha1
種類: 応用
メタデータ:
名前: ml-inference-app
仕様：
行き先：
名前空間: ml-inference
サーバー: https://kubernetes.default.svc
源：
repoURL に指定します。 'https://github.com/your-org/ml-deploy-configs.git'
targetリビジョン: main
path:マニフェスト/推論[path:manifests/inference]
プロジェクト: デフォルト
syncPolicy を使用します。
自動：
プルーン: true
selfHeal: trueパフォーマンスの最適化
モデルは迅速に応答し、高価な GPU や CPU 時間を無駄にしないようにする必要があります。 幸いなことに、HPA パラメーターや負荷分散ルールを微調整するだけで、貴重なミリ秒を削減し、コストを大幅に削減できます。
ロードバランシング
Ingress リソースを使用した負荷分散は、トラフィックを適切な推論サービスにルーティングするのに役立ちます。 モデルの異なるバージョンを分離するには、パスベースのルーティングを使用するオプションがあります。
以下は、複数の推論サービスへのパスベースのルーティングを備えたIngressです。
apiVersion: networking.k8s.io/v1
種類: イングレス
メタデータ:
名前: inference-ingress
仕様：
準則：
- ホスト:ml.example.com
http:
パス：
- パス: /v1/
pathType: プレフィックス
バックエンド:
サービス：
名前: inference-model-v1
港：
番号: 8081
- パス: /v2/
pathType: プレフィックス
バックエンド:
サービス：
名前: inference-model-v2
港：
番号: 8081コストプロファイリングと最適化
誰もが、GPU ノード、CPU ノード、メモリ使用量が支出とどのように一致するかを見るのが好きです。 しかし、リソースを手動で調整するのは時間がかかり、非効率的です。 そこで、次のようなツールが使われます。 カーペンター そして オートパイロット リソースの需要に合わせてクラスター ノードを自動的にスケーリングできるため、手動のノード プロビジョニングが不要になります。 永続的なコンピューティングを必要としないワークロードをトレーニングする場合、 スポットインスタンス コストを大幅に削減できますが、パイプラインが潜在的な中断に対処できることを確認してください。
以下は、インスタンスタイプをワークロードに一致させるための Karpenter 設定の例です。
apiVersion: karpenter.sh/v1alpha5
種類: プロビジョナー
メタデータ:
名前: デフォルト
仕様：
必要条件：
-鍵： "node.kubernetes.io/instance-type"
演算子:入力
値: ["m5.large", "m5.xlargeサイズ"]
供給者：
subnetSelectorを使用します。
karpenter.sh/discovery: "my-cluster"
securityGroupSelectorを使用します。
karpenter.sh/discovery: "my-cluster"大金を節約する別の方法は? Wiz などのツールを使用して、リソースの構成ミスや異常な使用パターンに関連するコスト要因がないかどうかを確認します。 Wiz は、作成中にノードを強化して、ノードが自動的にスケーリングされるだけでなく、安全であることを確認するのにも役立ちます。
結論
私たち'Kubernetes での機械学習ワークフローのさまざまな戦略について説明しました。 リソース管理から AI セキュリティのベストプラクティス、Tekton パイプラインの接続まで、私たちは'それぞれの作品が安定したプラットフォームにどのように貢献できるかを見てきました。 主なアイデアは、AI セキュリティ リスクを監視し、コスト超過を監視し、人々が信頼するパイプラインを構築することです。
これらのベストプラクティスを実装すると、クラスターの中断を最小限に抑え、データサイエンティストが自信を持って更新をプッシュできるようになります。 私たち'これらの提案があなたの仕事にどのように当てはまるかを見るのが楽しみです。 私たち'あなたが作成したもの、発見した教訓、そしてKubernetesワークフローで機械学習をどのようにレベルアップし続けているかについて、ぜひお聞かせください。
この旅は複雑に感じるかもしれませんが、Wiz のような適切なツールがあれば'リアルタイムスキャン、ダッシュボード、コンプライアンス機能など、トレーニングと推論のためのより安全な環境を構築できます。 もしあなたが'安全性を維持しながら AI/ML プロジェクトを改良および拡張したい場合は、コンテナの脆弱性、クラスター設定、コンプライアンス ベンチマークを包括的に把握できる Wiz を試してみてください。 Wiz を使用すると、クラスターを健全かつコスト効率が高く、侵入から安全に保つことができます。
クラウドをコードから本番まで保護
急成長中の企業が、コンテナ、Kubernetes、クラウド環境をビルド時からリアルタイムまで保護するためにWizを選択する理由をご覧ください。
