KarpenterプロバイダーによるOCI上のよりスマートなKubernetes自動スケーリングがGAに (2026/04/09)

KarpenterプロバイダーによるOCI上のよりスマートなKubernetes自動スケーリングがGAに (2026/04/09)

https://blogs.oracle.com/cloud-infrastructure/smarter-kubernetes-autoscaling-with-karpenter

投稿者:Kay Singh | Principal Product Manager

OKE 用 OCI の Karpenter プロバイダー

本日、OCI 向け Karpenter Provider の一般提供開始と、GitHub でのオープンソース版の公開を発表いたします。OCI Kubernetes Engine OKE でワークロードを実行している場合、このリリースにより、事前に固定形状の管理対象ノードプールを定義することなく、より高速で柔軟かつ管理しやすいオートスケーリングが可能になります。

課題

Kubernetesの現在のノードレベルのオートスケーリングモデル(つまり、クラスタオートスケーラー)は、単一のコンピューティングシェイプを使用するマネージドノードプールを中心に構築されています。これは機能しますが、本番ワークロードを実行する顧客にとって、実際的な制約も生み出します。

チームがワークロードごとに異なる構成を必要とする場合、多数のノードプールを作成および管理する必要があります。優先する構成の容量が不足すると、別の有効な構成が利用可能であっても、スケーリングが停止する可能性があります。これを回避するため、チームは事前に予備のプールを作成し、実際に必要な容量よりも多くの容量を確保します。しかし、これは長期的にはコストと運用作業の増加につながります。

顧客は、プラットフォームチームがすべてのノードプール、構成、フォールバックパスを事前に計画する必要なく、アプリケーションの需要に応じて自動的にスケーリングする機能を求めている。

ソリューション

OCI 用 Karpenter Provider は、Karpenter の柔軟なオートスケーリング モデルを OKE にもたらします。

Karpenterは、事前に定義されたノードプールをスケーリングするのではなく、スケジュールされていないPodを監視し、ワークロード要件と管理者が許可するOCI容量オプションに基づいて、適切なコンピューティング構成をリアルタイムでプロビジョニングします。管理者は、より広範な容量ポリシーを一度定義するだけで、需要の変化に応じてノードの選択とプロビジョニングをKarpenterが処理します。

OCIのお客様にとってこれが重要な理由

今回のリリースにより、OCI上でのKubernetesのオートスケーリングがよりシンプルに、より柔軟に、そしてより効率的になります。

さまざまな形状、アーキテクチャ、または購入モデルに対応するために、増え続ける静的な管理対象ノードプールを管理する代わりに、チームはより広範なポリシーを定義し、実行時にKarpenterに許可されたオプションから選択させることができます。これにより、プラットフォームチームの計画オーバーヘッドが削減され、変化するワークロードのニーズへの対応が容易になります。

また、スケーリング時の回復力も向上します。ある形状が利用できない場合、Karpenter は Cluster Autoscaler のように単一の管理対象ノードプールの境界で停止するのではなく、許可されているオプションの中から次に最適な形状に移行できます。

Karpenter Provider for OCI を利用することで、お客様は以下のことが可能になります。

  • 実際のワークロード需要に基づいて、必要な時にノードをプロビジョニングする
  • 管理する必要のある静的管理ノードプールの数を減らす
  • 1つのポリシーでより幅広いOCIコンピューティングオプションを使用する
  • 空いているノードや使用頻度の低いノードを統合することで、コスト効率を向上させます。
  • さまざまな形状や建築様式に合わせて簡単にスケール調整が可能
  • ノード構成がずれた場合に、継続的な調整と自動置換を行うことで、ノードのライフサイクル管理を改善します。

プラットフォームチームにとって、これはノードプールの事前計画に費やす時間を削減し、後々のノードの乱立管理に費やす時間を削減できることを意味します。また、クラスターを効率的に維持し、長期にわたって望ましい構成に整合させるためのより明確な道筋を示すことにもなります。

アプリケーションチームにとっては、ワークロードが変更されるたびにプラットフォームチームが新しいプールを作成するのを待つことなく、通常のKubernetesリクエスト、セレクタ、テイント、アフィニティを引き続き使用できることを意味します。

仕組み

OCI 用 Karpenter プロバイダーは、NodePool と OciNodeClass という 2 つの主要な概念を使用します。

Karpenter NodePool は、柔軟なポリシーを定義します。ここでは、管理者がインスタンスファミリー、アーキテクチャ、可用性ドメイン、オンデマンドやプリエンプティブなどの購入オプションといった、許可されるコンピューティングの種類を指定します。

OciNodeClassは、OCI固有の構成を定義します。開発者はここで、コンパートメント、サブネット、ネットワーク設定、セキュリティグループ、イメージ構成などの詳細を設定します。

この分離は重要です。NodePoolは「何を」実行するかを定義し、OciNodeClassは「どのように」実行するかを定義するからです。これらが確立されると、KarpenterはスケジュールされていないPodを監視し、ノードを自動的にプロビジョニングします。開発者は基盤となるノード設定について何も知る必要はありません。標準的なKubernetes仕様を使用してワークロードをデプロイするだけで、Karpenterがバックグラウンドでプロビジョニングを処理します。

OCI向けに構築

Karpenter Provider for OCI は、OCI 固有のインフラストラクチャと OKE 固有のワークフローに対応するように設計されています。このリリースでは、大まかに言うと、以下のような OCI ネイティブ機能をサポートしています。

  • OKEとの統合 
  • OCIフレキシブルコンピューティングシェイプのサポート 
  • プリエンプティブ容量のサポート 
  • OKEイメージのサポート 
  •  ワークロードを考慮したアクセスパターンによるOCI IAM統合
  • OCI環境のネットワークサポート(  OCI VCN CNIおよび セカンダリVNIC 構成を含む)
  • 容量予約のサポート 
  • クラスター配置グループのサポート 
  • コンピューティングクラスタのサポート 
  • ブートストラップやkubeletレベルの設定など、ノードの動作をカスタマイズするオプション

導入が容易

OCI 用 Karpenter プロバイダーは、移行中に既存の Cluster Autoscaler で管理されている容量と共存できますが、両方のオートスケーラーが同じスケジュールされていない Pod に応答しないようにする必要があります。最も安全な移行パターンは、所有権を明確に分離することです。重要なシステムワークロード用に既存の管理ノードプール容量を少量残し、ラベル、テイント、ノードアフィニティを使用して、定義されたワークロードセットに対して最初に Karpenter を導入します。これらのワークロードが Karpenter でプロビジョニングされたノードで期待どおりに実行されたら、移行された容量に対して Cluster Autoscaler をスケールダウンまたは無効にすることができます。これにより、両方のオートスケーラーが同じ需要シグナルに対してノードをプロビジョニングしようと競合する可能性が低減されます。

顧客の視点

当社は、顧客企業の1社であるGoTo社に、OCI向けKarpenterプロバイダーの早期アクセスを提供しました。GoTo社からの感想は以下のとおりです。

「Karpenterは、多くの手動ノードプール計画を、より動的なプロビジョニングモデル(マルチシェイプ、マルチAD)に置き換えることで、OCI上でのオートスケーリングを簡素化してくれます。私たちのユースケースでは、これはフォールバック動作の改善と高速化、プラットフォームとワークロード間の所有権境界の明確化、そして新しいキャパシティの導入における拡張性の向上を意味します。」

Getting started

OCI 用 Karpenter プロバイダーの利用を開始するには、まず公式ドキュメントを参照してください。ドキュメントには、前提条件、インストール、構成、および使用方法が記載されています。

一般的に、セットアップの流れは次のようになります。

  1. 既存または新規の OKE クラスターから始めましょう。
  2. Karpenter Provider for OCI の前提条件とインストール手順を確認してください。
  3.  プロバイダーがOCIリソースを適切に管理できるように、必要な IAMポリシーとアクセスモデルを設定します。
  4. GitHubリポジトリからKarpenterプロバイダーをインストールしてください
  5. プロビジョニングに必要な Kubernetes および OCI 構成を定義します。これには、などのリソースが含まれ NodePool ます OCINodeClass
  6. クラスターのニーズに基づいて、OCI上でワークロード認識型キャパシティの起動を開始します。

まとめ

OCI向けKarpenterプロバイダーは、OKEの顧客に対し、ワークロードのニーズに合わせてリアルタイムで容量を調整することで、より柔軟なスケーリング方法を提供すると同時に、ノードプールの計画と管理のオーバーヘッドを削減します。

詳細については、公式ドキュメントを参照し、GitHubリポジトリをご覧ください。まずは少数のワークロードでKarpenterの動作を評価し、そこから徐々に拡張していくことをお勧めします。

リソース

コメント

このブログの人気の投稿

Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20)

ミリ秒の問題: BCCグループとOCIが市場データ・パフォーマンスを再定義する方法(AWSに対するベンチマークを使用) (2025/11/13)

OCIのカスタム・ルート表を使用した詳細なルーティング制御 (2025/02/27)