OKE の進化 - Oracle Cloud Infrastructure Kubernetes Engine の現在地 -

Oracle Cloud Hangout Café Premium 資料

※セッションでは割愛したアップデート情報も公開

Transcript

1. OKE の進化 ～ Oracle Cloud Infrastructure Kubernetes Engine の現在地 ～ Oracle Cloud Hangout Café Premium Yutaka Ichikawa, Kyotaro Nonaka, Yoichiro Nakagawa Cloud Business Unit / AI Platform Unit AI Solutions Architect
2. Agenda title 1 OCI Kubernetes Engine (OKE) とは？ 2 OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ 3 休憩 4 OKE クラスタ管理の現在地 ～ Karpenter/Observability Agent Demo ～ 2 Copyright © 2026, Oracle and/or its affiliates
3. OCI Kubernetes Engine (OKE) とは？ OKE 紹介
4. OCI Kubernetes Engine (OKE) とは？ OCI Kubernetes Engine (OKE) エンタープライズ品質の性能と可用性 • 高性能なインフラストラクチャによる分散アプリケーション環境 • 冗長構成を自動で構成する高可用性 マネージド環境 • ワーカーノードを柔軟に管理できる Managed Nodes • ワーカーノードの管理を不要とする Virtual Nodes (オプション機能) Cloud Native Java ソリューションや Oracle Database との親和性 • Cloud Native な Java アプリケーション開発 • Oracle Database / MySQL の Cloud Native アプローチ 4 Copyright © 2026, Oracle and/or its affiliates OCI Kubernetes Engine
5. OCI Kubernetes Engine (OKE) とは？ エンタープライズ品質の性能と可用性 高性能 IaaS 上に構築された確実な性能を実現する Kubernetes プラットフォーム ミッションクリティカル・システムに不可欠な安定した高性能を確実に維持 • 各ホスト間を 低レイテンシーかつ広帯域の N/W で接続したボトルネックの無いインフラストラクチャ • 大規模な数のコンテナのデプロイメントにおいてネットワーク性能劣化による品質低下を確実に防止 第3者機関による N/W 性能検証結果 Other OCI https://www.accenture.com/t20171003T083750Z__w__/us-en/_acnmedia/PDF-62/AccentureEnterprise-Workloads-Meet-Cloud.pdf 5 Copyright © 2026, Oracle and/or its affiliates
6. OCI Kubernetes Engine (OKE) とは？ エンタープライズ品質の性能と可用性 物理障害に対する耐障害性をマネージド機能により確実かつ容易に実現 AD : Availability Domain FD : Fault Domain ※ 単一 AD 構成のデータセンターでは、物理ハードウェアを AD 内で複数の FD に分けてグループ化し、それぞれに分散配置することで可用性を確保します。 ※ 最大 200 Gb / s の帯域幅 6 Copyright © 2026, Oracle and/or its affiliates
7. OCI Kubernetes Engine (OKE) とは？ マネージド環境 ワーカーノードを柔軟に管理できる Managed Nodes と費用対効果を促す Basic Cluster Basic Cluster（基本クラスタ） • Kubernetes および OKE によって提供されるコア機能を提供 • IaaS サービス課金のみ ( Cluster に課金はなし) • 拡張クラスタで提供されるオプション機能は利用不可 • サポートするワーカーノード数は 1000 Node まで ※Basic Cluster から Enhanced Cluster へは In-place upgrade によるアップグレードが可能 (Enhanced Cluster から Basic Cluster へのダウングレードは不可) OKE Basic Cluster Managed Nodes • ワーカーノードの各ノードに SSH ログインして柔軟に管理 • Cluster Autoscaler 機能を利用して自動ノードスケール • 永続化領域（OCI Block Volume / FSS）の利用 • AMD 以外の仮想マシンインスタンスを利用 7 Copyright © 2026, Oracle and/or its affiliates Managed Nodes ワーカーノード
8. OCI Kubernetes Engine (OKE) とは？ マネージド環境 ワーカーノードの管理を不要とする Virtual Nodes をはじめ、オプション機能を実現する Enhanced Cluster Enhanced Cluster（拡張クラスタ） Basic Cluster で提供される機能に加えて、以下オプション機能を提供 • Virtual Nodes • アドオン機能管理 • Workload Identity • オンデマンドノードサイクル • SLAの提供 • クラスタごとに課金が発生（¥15.5/hour） • サポートする ワーカーノード数は 2000 Node まで Virtual Nodes • ステートレスなアプリケーションをスケーラブルに利用 • ワーカーノードの運用負荷を削減 • ワーカーノードが消費するリソースを意識せず、コンテナアプリケーションを運用 8 Copyright © 2026, Oracle and/or its affiliates OKE Enhanced Cluster Virtual Nodes ワーカーノード Virtual Nodes はユーザから操作不可
9. OCI Kubernetes Engine (OKE) とは？ マネージド環境 ワーカーノードの管理を不要とする Virtual Nodes ワーカーノードに対するセキュリティパッチやトラブルシューティングなどのメンテナンスが不要な仮想ワーカーノード OKE Virtual Nodes Enhanced Cluster 選択可能な Compute シェイプは E3 / E4 / A1 (2026/7 時点) Virtual Nodes ワーカーノード Virtual Nodes はユーザから操作不可 9 • 1 Virtual Node あたり 500 Pod まで実行可能 • オートスケールには HPA リソースの作成が必要 • CNI は OCI VCN-Native Pod networking を利用 Copyright © 2026, Oracle and/or its affiliates • ユーザ側での OCPU とメモリの選択不要 • Pod が消費する OCPU とメモリは、デプロイされた Pod の Resource Requests / Limits から算出(※) (※) Resource Requests / Limits の指定がない場合、 0.125OCPU / メモリ 0.5GB を割り当てる(課金は 1 OCPU / メモリ 1 GB として切り上げ) 詳細ドキュメント : https://docs.oracle.com/jajp/iaas/Content/ContEng/Tasks/contengcomparingvirtualwithmanagednodes_topic.htm#contengusingvirtu alormanagednodes_topic
10. OCI Kubernetes Engine (OKE) とは？ マネージド環境 OKE 利用パターン Basic Cluster（基本クラスタ） Enhanced Cluster（拡張クラスタ） Managed Nodes Managed Nodes Virtual Nodes コア機能 ◯ ◯ ◯ Workload Identity × ◯ ◯ アドオン管理 × ◯ ◯ オンデマンド ノードサイクル × ◯ (コントロールプレーンと同時アップグレード) 課金 ワーカーノード（各ノード）のみ ( OKE およびクラスタ課金なし) 拡張クラスタ + ワーカーノード （各ノード） Enhanced Cluster（拡張クラスタ）¥15.5 / hour Virtual Nodes（1 Virtual Node あたり）¥2.325 / hour ノード料金表 : https://www.oracle.com/jp/cloud/compute/pricing/ 10 Copyright © 2026, Oracle and/or its affiliates 拡張クラスタ + Virtual Nodes + Pod が利用する OCPU / メモリ
11. OCI Kubernetes Engine (OKE) とは？ マネージド環境 オプション機能概要 機能 概要 アドオン管理 Kubernetes クラスタの構築および拡張するためのソフトウェアを管理 （詳細ドキュメント：https://docs.oracle.com/jajp/iaas/Content/ContEng/Tasks/contengintroducingclusteraddons.htm） Workload Identity ワークロード ID に対するポリシーによって他の OCI リソースに対するアクセス制御 オンデマンドノードサイクル 既存のノード・プールに新しい Kubernetes バージョンを指定してから、ノード・プール内の 管理対象ノードで実行されている Kubernetes のバージョンをアップグレードできる機能 SLAの提供 SLA ( Service Level Agreement ) を提供 （例：特定のワークロード ( Pod ) から OCI Object Storage に対する全権限を許可するなど） 詳細ドキュメント：https://docs.oracle.com/ja-jp/iaas/Content/ContEng/home.htm 11 Copyright © 2026, Oracle and/or its affiliates
12. OKE の進化 OKE の主要なアップデートと使いどころ
13. セキュリティ・認証、ネットワーク 13 Copyright © 2026, Oracle and/or its affiliates
14. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ セキュリティ・認証、ネットワーク アップデート傾向 セキュリティ・認証： 2023～2024年に集中（ワークロード・アイデンティティ、OIDC 対応、資格証明ローテーション等の「認証基盤の整 備」）。 2025年以降は落ち着きつつ、2026年に Zero Trust Packet Routing (ZPR) という新しい方向性が登場。 ネットワーク： 2023年はまだ少数だが年々増加し、2026年は11件と過去最多。特に VCN ネイティブ CNI とロードバランサ （LB/NLB）周りの細かい機能強化が継続的に積み重なっている。 1 Copyright © 2026, Oracle and/or its affiliates
15. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ セキュリティ・認証、ネットワーク アップデート一覧 セキュリティ・認証 ネットワーク Zero Trust Packet Routing (ZPR)のサポート 管理対象LBのHTTP/2サポート クラスタ資格証明の自動ローテーションのサポート 複数のセカンダリVNICアタッチメントに対するサポート OIDCディスカバリを使用したOCI以外のリソースへのポッド承認 管理対象LBのCookieベースのセッション永続性のサポート のサポート 外部OIDCアイデンティティ・プロバイダを使用した認証のサポート 予約済パブリックIPv4アドレスをLB/NLBに割り当てるための注釈 のサポート ワークロード・アイデンティティを使用した他テナント・コンパートメント LBリスナー・プロトコルとしてのGRPCのサポート へのアクセスサポート OCIネイティブ・イングレス・コントローラのクラスタ・アドオンとしてのデ プロイのサポート Istioのクラスタ・アドオンとしてのデプロイのサポート OCIネイティブ・イングレス・コントローラ使用時のFlannelのサポート OCIネイティブ・イングレス・コントローラのサポート 1 Copyright © 2026, Oracle and/or its affiliates
16. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ セキュリティ・認証 Zero Trust Packet Routing（ZPR）のサポート (リリースノート:https://docs.oracle.com/iaas/releasenotes/conteng/conteng-zpr-security-attribute-support.htm) 概要 • Zero Trust Packet Routing（ZPR）は、OCIリソースに付与した「セキュリティ属性」をもとに通信を制御するネットワーク・セキュ リティ機能 • IPアドレスやCIDRだけでなく、「本番環境」「機密データ用」などのリソース属性を基準に通信可否を定義可能 • OKEで利用する対応OCIリソース(Load Balancer、ワーカーノードのVNIC など)にもZPRを適用でき、NSGやSecurity Listに 加えて属性ベースのアクセス制御を追加可能 ユースケース • 本番・機密ワークロードの通信制御 ProductionやConfidentialなどの属性を持つリソース間だけ通信を許可し、開発・検証環境からの意図しないアクセスを防止 • 複数OKEクラスタへの共通セキュリティポリシー IPアドレスやCIDRをクラスタごとに管理せず、共通のセキュリティ属性を利用して一貫したアクセス制御を適用 • 既存ネットワーク制御との多層防御 NSGやSecurity Listでネットワーク境界を制御しつつ、ZPRで通信可能なリソースの組み合わせをさらに限定 1 Copyright © 2026, Oracle and/or its affiliates
17. Zero Trust Packet Routing（ZPR）のサポート 属性はOKEで利用する対応OCIリソース(Load Balancer、ワーカーノードのVNIC など)に付与可能 OCI ZPRポリシー in network: backend-vcn VCN allow app:invoice-writer endpoints to connect to storage:invoice-fss endpoints backend-vcn（VCN：ポリシーの適用範囲） ✓ OKE：帳票生成Pod FSS：帳票保管領域 許可 属性：app:invoice-writer 別アプリPod 属性：app:other-api 属性：storage:invoice-fss × 拒否 invoice-fssへの許可パスなし ※ ZPRは既存のネットワーク制御に追加で適用されます 17 Copyright © 2026, Oracle and/or its affiliates
18. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ セキュリティ・認証 クラスタ資格証明の自動ローテーションのサポート (リリースノート:https://docs.oracle.com/iaas/releasenotes/conteng/conteng-Credential-auto-rotation-Release-Note.htm) 概要 • OKEクラスタ内部で利用する資格証明には有効期限があり、期限切れ前にローテーションが必要 • 有効期限まで90日以内になっても手動ローテーションが開始されていない場合、OKEが資格証明の自動ローテーションを試行 • 資格証明の更新漏れによるクラスタ停止リスクを軽減するセーフティネットとして利用可能 ユースケース • 資格証明期限切れによるクラスタ障害の防止 更新作業の漏れが発生した場合でも自動ローテーションを試行し、期限切れによるサービス影響を低減 • 多数のOKEクラスタの運用 開発、検証、本番など多数のクラスタを管理する環境で、個々の資格証明の更新漏れリスクを削減 • 長期稼働クラスタの運用安全性向上 計画的な資格証明ローテーションに加え、自動ローテーションをセーフティネットとして利用 2 Copyright © 2026, Oracle and/or its affiliates
19. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ セキュリティ・認証 OIDC Discoveryによる非OCIリソースへのPod認証のサポート (リリースノート:https://docs.oracle.com/iaas/releasenotes/conteng/conteng-OIDC-Discovery-Release-Note.htm) 概要 • OIDC Discoveryは、OIDCのIssuerや公開鍵など、外部サービスが認証に必要とする情報を標準的な形式で公開する仕組み • OKE上のPodのServiceAccountを外部クラウドから信頼できるIDとして利用し、AWS、Azure、Google Cloudなどへ固定 Credentialを持たずにアクセス可能 • Kubernetes Secretに長期的なAPIキーを保存する必要を減らし、ワークロード単位のSecretlessな認証を実現 ユースケース • OKEから外部クラウドへのSecretlessアクセス OKE上のPodからAWS S3やGoogle Cloud Storageなどへ、長期的なアクセスキーを保持せずにアクセス • マルチクラウドのデータ処理基盤 OKE上のETL、AI/ML、バッチ処理から複数クラウドのデータソースやAPIへアクセス • CI/CD・自動化処理の資格情報管理削減 OKE上のジョブやCI/CDツールから外部クラウドAPIを利用し、固定Credentialの配布・保管・ローテーションを削減 3 Copyright © 2026, Oracle and/or its affiliates
20. OIDC Discoveryによる非OCIリソースへのPod認証のサポート 長期的な認証情報をPodに保持せず、非OCIリソースへアクセス 前提条件 ① OKEでOIDC Discoveryを有効化(ServiceAccount Token の Issuer が、外部から検証可能な OKE の OIDC Issuer になる) ② AWS IAMにOKE Issuer URLを登録 ③ IAM Roleに、対象ServiceAccount の利用を許可 OCI / OKE AWS OKE Pod (アプリ) ServiceAccount Token (JWT) AWS Security Token Service IAM Role (S3ReadOnly) ① ServiceAccount Token を取得 ② ServiceAccount Token を AWS Security Token Service へ送信 ③ IAM Roleの利用条件を確認 ④ 一時的なAWS認証情報を返す ⑤ アプリが一時的なAWS認証情報でS3へアクセス 20 Copyright © 2026, Oracle and/or its affiliates | Confidential: Internal/Restricted/Highly Restricted Amazon S3 Bucket
21. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ ネットワーク 複数のセカンダリVNICアタッチメントのサポート (リリースノート:https://docs.oracle.com/iaas/releasenotes/conteng/conteng-Generic-VNIC-attachments.htm) 概要 • OKEのワーカーノードに複数のSecondary VNICをアタッチし、VNICごとにSubnet、NSG、IP割当などを個別に設定可能 • ネットワーク用途ごとの分離や、Multusを利用した複数ネットワーク・インターフェースを持つPod構成に対応 • 利用可能なPod IPを拡張することで、1ノードあたりのPod密度を高めた構成にも利用可能 ユースケース • 用途ごとのネットワーク分離 フロントエンド、バックエンド、管理、ストレージなどの通信を異なるVNICやSubnetへ分離 • 高密度なPod配置 Secondary VNICを利用してPodに割り当て可能なIPアドレスを増やし、多数のPodを収容するワーカーノードを構成 • 複数NICを必要とするワークロード Multusと組み合わせ、通信系、NFV、特殊なネットワーク構成を必要とするPodに複数のネットワーク・インターフェースを提供 6 Copyright © 2026, Oracle and/or its affiliates
22. 複数のセカンダリVNICアタッチメントのサポート ネットワーク要件の異なるPodを、用途ごとに異なるSubnet / NSGへ分離可能 • Before：Pod用 Secondary VNIC は 1 系統 Worker Node Frontend Pod Secondary VNIC 共通 Pod Subnet / NSG 異なるネットワーク要件でも同じ Pod ネットワーク (ネットワーク要件ごとに分けるにはNode Pool分離などを検討) 22 After：Pod用 Secondary VNICを複数系統に分離 Worker Node Frontend Pod Backend Pod • Copyright © 2026, Oracle and/or its affiliates Backend Pod Secondary VNIC A Frontend 用 Subnet / NSG Secondary VNIC B Backend 用 Subnet / NSG Node Pool構成を増やさず、Podごとに異なるネットワーク要件 へ対応可能
23. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ セキュリティ・認証 外部OIDCアイデンティティ・プロバイダを使用した認証のサポート (リリースノート:https://docs.oracle.com/iaas/releasenotes/conteng/conteng-OIDC-Auth-Release-Note.htm) 概要 • OIDC Identity Provider（IdP）は、ユーザーを認証してIDトークンを発行する外部認証基盤 • OCI IAMだけでなく、企業で利用している外部OIDC IdPをOKEクラスタのユーザー認証元として利用可能 • Kubernetes RBACと組み合わせることで、企業のユーザー／グループ管理とOKEのアクセス権限を連携可能 ユースケース • 企業の共通IdPによるOKEログイン 開発者や運用担当者が企業で利用しているIDを使い、kubectlからOKEクラスタへアクセス • 複数OKEクラスタの認証統一 開発、検証、本番など複数クラスタで同じIdPを利用し、クラスタごとの個別ユーザー管理を削減 • 企業IDとKubernetes RBACの連携 IdPのユーザーやグループとKubernetes RBACを組み合わせ、開発者、運用担当者、管理者など役割ごとに操作権限を分離 4 Copyright © 2026, Oracle and/or its affiliates
24. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ セキュリティ・認証 Workload Identityによる他テナンシ／コンパートメントへのアクセス (リリースノート:https://docs.oracle.com/iaas/releasenotes/changes/1d21721f-90eb-43a0-8483-745c16097da8/index.htm) 概要 • OKE Workload Identityは、OKE上のPodをOCI IAM上のワークロードとして識別し、Pod単位でOCIリソースへのアクセス権限 を付与する仕組み • クラスタと異なるコンパートメントや別テナンシに配置されたOCIリソースにも、Workload Identityを利用してアクセス可能 • ワーカーノード全体ではなく、Cluster、Namespace、ServiceAccountなどを基準に最小権限のIAM設計が可能 ユースケース • 共有サービス用コンパートメントへのアクセス OKEクラスタとは別コンパートメントに配置したObject StorageやVaultへ、必要なPodだけアクセスを許可 • アプリケーションごとの最小権限IAM 同一クラスタ上でもServiceAccountごとにアクセス可能なOCIリソースを分離し、アプリケーション単位で権限を制御 • 複数テナンシにまたがるデータ連携 OKEを実行するテナンシとデータを管理するテナンシを分離し、特定ワークロードだけにクロステナンシアクセスを許可 5 Copyright © 2026, Oracle and/or its affiliates
25. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ ネットワーク OCI Load BalancerのHTTP/2・gRPCサポート (リリースノート:https://docs.oracle.com/iaas/releasenotes/conteng/conteng-LB_HTTP2-support.htm / https://docs.oracle.com/iaas/releasenotes/conteng/conteng-LB-listener-GRPC-support.htm) 概要 • OKEがLoadBalancerタイプのKubernetes Service用に作成するOCI Load Balancerで、HTTP/2およびgRPC Listener を利用可能 • HTTP/2を利用するWeb/APIや、Protocol Buffersを利用するgRPCアプリケーションをOCI Load Balancerから直接公開可 能 • アプリケーション側で利用する通信プロトコルに合わせて、OKEの外部公開方式の選択肢を拡大 ユースケース • HTTP/2対応Web/APIサービスの公開 多数のHTTPリクエストを処理するWebサービスやAPIを、HTTP/2対応のOCI Load Balancer経由で公開 • gRPCベースのマイクロサービス公開 OKE上のgRPC APIをOCI Load Balancer経由で公開し、クライアントからgRPCで直接アクセス • AI/ML推論APIの公開 gRPCを利用するモデルサービング基盤をOKE上で実行し、OCI Load Balancerをエントリーポイントとして利用 7 Copyright © 2026, Oracle and/or its affiliates
26. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ ネットワーク OCI Load Balancerのアプリケーション公開・運用機能の拡充 (リリースノート:https://docs.oracle.com/iaas/releasenotes/conteng/conteng-cookie-based-session-persistence.htm / https://docs.oracle.com/iaas/releasenotes/conteng/conteng-LB-NLB-annotation-for-Reserved-IPv4.htm) 概要 • OKEが作成するOCI Load Balancerで、CookieベースのSession Persistence（Sticky Session）を利用可能 • Kubernetes ServiceのAnnotationからReserved Public IPv4を指定し、LB/NLBへ固定Public IPを割り当て可能 • 既存Webアプリケーションや外部システムとの接続要件を維持したまま、OKEへ移行・更新しやすくなる ユースケース • 既存WebアプリケーションのOKE移行 セッション情報をアプリケーションサーバー側で保持するシステムを、Sticky Sessionを利用して大幅に改修せず移行 • 外部システムとの固定IP連携 Firewall、外部SaaS、取引先システムなどの許可リストへ登録したPublic IPをOKE環境でも継続利用 • Service / Load Balancer再作成時の接続先維持 Kubernetes ServiceやLoad Balancerを再構築してもReserved Public IPを再利用し、外部利用者への影響を抑制 8 Copyright © 2026, Oracle and/or its affiliates
27. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ ネットワーク OCI Native Ingress Controllerのサポートと機能拡張 (リリースノート:https://docs.oracle.com/.../382db118... / .../97a0a1c3... / .../db2538a7...) 概要 • Kubernetes Ingressの定義をもとに、OCI Flexible Load Balancerを自動構成するIngress Controller • Flannel CNIを利用するOKEクラスタにも対応し、既存構成でもOCI Native Ingressを利用可能 • Cluster Add-onとして導入・更新管理でき、Ingress Controllerの運用をOKE側へ集約可能 ユースケース • 複数サービスを1つのLoad Balancerで公開 Host / Pathルールで複数のKubernetes Serviceへ振り分け、OCI Load Balancerを共有 • KubernetesマニフェストによるL7ルーティング管理 Ingress ResourceをGitなどで管理し、Load Balancer設定をコード化 • 複数クラスタへのIngress基盤の標準展開 開発・検証・本番クラスタに共通方式で導入し、Ingress Controllerを標準化 9 Copyright © 2026, Oracle and/or its affiliates
28. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ その他 Istioのクラスタ・アドオンとしてのサポート (リリースノート:https://docs.oracle.com/iaas/releasenotes/changes/b3fba65b-7abb-4a10-a6fa-b35481192bb0/index.htm) 概要 • Istioは、マイクロサービス間の通信制御、セキュリティ、可視化などを提供するService Mesh • IstioをOKEのCluster Add-onとして導入し、有効化、バージョン選択、更新などをOKE側から管理可能 • 利用者がIstioのインストールやライフサイクルを個別管理する負担を軽減し、複数クラスタへの標準展開を容易化 ユースケース • マイクロサービス間通信の制御 多数のサービス間通信をIstioで管理し、ルーティング、セキュリティ、可視化を共通の仕組みで実現 • Canary Release 新旧バージョンへ段階的にトラフィックを振り分け、本番トラフィックを利用しながら新バージョンを安全に検証 • Service Mesh運用の標準化 複数OKEクラスタへIstioを共通方式で導入し、インストール、バージョン管理、更新作業を効率化 10 Copyright © 2026, Oracle and/or its affiliates
29. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ その他 OCI Kubernetes Engineへの名称変更 (リリースノート:https://docs.oracle.com/iaas/releasenotes/conteng/conteng-rename.htm) 概要 • サービス名称を「OCI Container Engine for Kubernetes」から「OCI Kubernetes Engine」へ変更 • 略称のOKEは引き続き利用され、OKE API EndpointやOCI CLIコマンドへの変更はなし • 技術機能の追加ではなく、サービス名称およびドキュメント上の表記変更 ユースケース • 製品名称・資料表記の統一 提案資料、設計書、運用手順書などで従来名称からOCI Kubernetes Engineへ表記を統一 • 既存自動化資産の継続利用 名称変更後も既存のCLI、API、Terraform、運用スクリプトなどを変更せず継続利用 • OKEのサービス位置付けの明確化 Kubernetesサービスであることをサービス名称から直接理解しやすくする 11 Copyright © 2026, Oracle and/or its affiliates
30. AI/GPU・HPC、ストレージ 30 Copyright © 2026, Oracle and/or its affiliates
31. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ AI/GPU・HPC、ストレージ アップデート傾向 AI/GPU・HPC： 2023～2024年は「GPU シェイプ追加」程度だったのが、2026年に一気に5件が集中投入（NVIDIA GPU/Network Operator、AMD GPU、ノード機能検出、コンピュート・クラスタ）され、明確な加速フェー ズに突入 ストレージ： スナップショット・クローンから、直近では Virtual Nodes の FSS 対応という基本機能の着実な進化に加え、 Ultra High Performance、RAW ブロック、そして2026年の Lustre（HPC 向け並列ファイルシステ ム）・ SMB 対応へと、AI/HPC ワークロードを支える方向にも適応 1 Copyright © 2026, Oracle and/or its affiliates
32. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ AI/GPU・HPC、ストレージ アップデート一覧 AI/GPU・HPC ストレージ NVIDIA Network Operator クラスタ・アドオンのサポート Virtual Nodesにおける永続ボリューム（FSS）のサポート コンピュート・ホスト・グループおよびコンピュート・クラスタに対するサポート CSIドライバのSMBクラスタ・アドオンをデプロイするためのサポート NVIDIA GPUプラグインをクラスタ・アドオンとしてデプロイするためのサポート 新しいLustreファイル・システムへのPVCプロビジョニングのサポート 追加のGPUシェイプのサポート RAWブロックボリュームに支えられたPVCのReadWriteManyアクセス モードのサポート 追加のGPUシェイプのサポート RAWブロックボリューム・ストレージのサポート Ultra High Performanceブロックボリュームに支えられたPVCのサ ポート Kubernetesボリューム・クローンのサポート Kubernetesボリューム・スナップショットのサポート 1 Copyright © 2026, Oracle and/or its affiliates
33. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ AI/GPU・HPC 追加のGPUシェイプのサポート (2023年3月/2024年10月) (リリースノート: https://docs.oracle.com/iaas/releasenotes/changes/d0469e0c-7efa-4ddf-85e6-71d00d466081/index.htm) 概要 • 管理対象ノードでサポートされるGPUシェイプ - OCIで提供される使用可能な仮想マシン(VM) GPUシェイプおよびベア・メタル(BM) GPUシェイプをサポート - 詳細はコンピュート・シェイプを参照 • 自己管理ノードでサポートされるGPUシェイプ - 自己管理ノードをホストするコンピュート・インスタンスの作成時に選択したOKE Oracle Linux 7 (OL7)またはOracle Linux 8 (OL8)イメージで使用可能なGPUシェイプをサポート ユースケース • AI/ML・生成AI基盤 機械学習モデルの学習・推論、生成AI処理をGPUで高速化 • 大規模並列・HPC処理 シミュレーションや大量バッチなど、高いGPU演算性能を必要とする処理 • GPUアプリケーション基盤 画像・映像処理やGPU対応アプリをOKE上に集約し、コンテナで運用 33 Copyright © 2026, Oracle and/or its affiliates
34. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ AI/GPU・HPC NVIDIA GPUプラグインのクラスタ・アドオンをサポート(2024年12月) (リリースノート: https://docs.oracle.com/ja-jp/iaas/releasenotes/conteng/conteng-GPU-device-plugin-addon.htm) 概要 • NVIDIA GPUプラグインをOKEのクラスタ・アドオンとして利用可能 • Worker Node上のNVIDIA GPU数をKubernetesへ公開 • GPUの健全性を追跡し、GPUリソースをKubernetesから利用可能に ユースケース • GPUクラスタ構築の簡素化 GPU利用に必要なNVIDIA Device Pluginの導入・構成を容易に • GPUリソースの可視化・割当 ノード上のGPUを認識し、GPUワークロードへ適切に割当 • GPU基盤の運用標準化 Device PluginをOKEアドオンとして管理し、GPUクラスタの運用負荷を軽減 34 Copyright © 2026, Oracle and/or its affiliates
35. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ AI/GPU・HPC コンピュート・ホスト・グループおよびコンピュート・クラスタのサポート(2026年6月) (リリースノート: https://docs.oracle.com/ja-jp/iaas/releasenotes/conteng/conteng-Compute-cluster-and-HostGroup-support.htm) 概要 • Compute Host Group対応：Bare Metalノードを特定のホスト群へ配置可能 • Compute Cluster対応：RDMAネットワークを利用する管理対象ノード・プールを構成可能 - RDMA:別のサーバーのメモリへ、CPUやOSの処理を抑えて直接データを転送する仕組み ユースケース • 大規模AI/ML・分散トレーニング RDMAによる高速ノード間通信を活用し、大規模な分散学習を実行 • HPC・大規模並列処理 Compute Clusterを活用し、科学技術計算やシミュレーションを必要とする処理を実行 • Bare Metal基盤の運用最適化 Host Groupによる専用配置とOKEのノード管理を組み合わせ、基盤運用を効率化 35 Copyright © 2026, Oracle and/or its affiliates
36. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ AI/GPU・HPC NVIDIA Network Operatorクラスタ・アドオンのサポート(2026年7月) (リリースノート: https://docs.oracle.com/ja-jp/iaas/releasenotes/conteng/conteng-NVIDIA-Network-Operator-addon.htm) 概要 • NVIDIA Network OperatorをOKEのクラスタ・アドオンとして利用可能 • 高性能ネットワークに必要なNVIDIAネットワーク・コンポーネントのデプロイ・構成を自動化 • Multus CNI、NVIDIA IPAM、SR-IOV、RDMA CNIなどを統合的に管理 - Multus CNI：Podに複数のネットワークを接続 - NVIDIA IPAM：高速ネットワークのIPアドレス割当を管理 - SR-IOV：NICを仮想分割し、Podから直接利用することで高速・低遅延化 ユースケース • 大規模AI/ML・分散トレーニング RDMA/SR-IOVによる高性能ネットワークを活用し、GPUノード間の大規模な分散学習を支援 • HPC・低レイテンシ通信 SR-IOV/RDMAを活用し、低遅延・高帯域なノード間通信を必要とするHPC処理を実行 • 高性能ネットワーク基盤の運用効率化 Network Operatorによってネットワーク・コンポーネントの導入・構成を自動化し、GPU/HPCクラスタの構築・運用を簡素化 36 Copyright © 2026, Oracle and/or its affiliates
37. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ AI/GPU・HPC NVIDIA GPU Operatorクラスタ・アドオンのサポート(2026年7月) (リリースノート: https://docs.oracle.com/ja-jp/iaas/releasenotes/conteng/conteng-NVIDIA-GPU-Operator-addon.htm) 概要 • NVIDIA GPU OperatorをOKEのクラスタ・アドオンとして利用可能、GPUノードのNVIDIAコンポーネントの管理を自動化 • Device Plugin、Container Toolkit、MIG Manager、DCGM / DCGM Exporterなどを統合管理し、GPUワークロード、監視、GPU共有を 実現 - NVIDIA Device Plugin：GPUをKubernetesのリソースとして認識し、Podへ割り当てる仕組み - NVIDIA Container Toolkit：コンテナからNVIDIA GPUを利用可能にする実行環境 - MIG Manager：1つの対応GPUを複数の独立したGPUインスタンスに分割・管理する仕組み - DCGM / DCGM Exporter：GPUの使用率、メモリ、温度などを監視し、Prometheus等から利用できるメトリクスとして公開する仕組み ユースケース • GPUワークロード基盤の構築・運用簡素化 GPU利用に必要なNVIDIAコンポーネントを統合管理し、AI/ML基盤の構築・運用を効率化 • GPUリソースの共有・利用効率向上 MIGなどを活用してGPUリソースを分割・共有し、複数ワークロードで効率的に利用 • GPUの可視化・モニタリング DCGMによってGPUの利用状況や健全性を監視し、GPUクラスタの安定運用を支援 37 Copyright © 2026, Oracle and/or its affiliates
38. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ AI/GPU・HPC ノード機能検出クラスタ・アドオンのサポート(2026年7月) (リリースノート: https://docs.oracle.com/ja-jp/iaas/releasenotes/conteng/conteng-Node-Feature-Discovery-addon.htm) 概要 • Node Feature Discovery（NFD）をOKEのクラスタ・アドオンとして利用可能 • CPU、GPU、デバイス、カーネル、OSなど、各ノードのハードウェア/システム特性を自動検出 • 検出した特性をKubernetesのNode Labelとして公開し、ワークロードの配置に利用可能 ユースケース • GPUワークロードの最適配置 GPUなどのハードウェア特性を検出し、要件を満たすノードへワークロードを配置 • CPU/HPCワークロードの最適配置 CPUやカーネルなどの特性を活用し、特定のハードウェア要件を持つ処理を適切に配置 • 異種ノード環境の運用効率化 ノード特性の検出・ラベル付与を自動化し、多様なノード構成の管理を効率化 38 Copyright © 2026, Oracle and/or its affiliates
39. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ ストレージ Kubernetesボリューム・スナップショットのサポート(2023年6月) (リリースノート: https://docs.oracle.com/ja-jp/iaas/releasenotes/changes/fe943def-42aa-419a-8282-1ae0f13565ea/index.htm) 概要 • CSIボリューム・プラグインでKubernetes Volume Snapshotをサポート • OCI Block Volume Backupを利用し、永続ボリュームの特定時点のコピーを作成可能 • 作成したVolume Snapshotから新しいPersistent Volumeをプロビジョニング可能 ユースケース • 障害・データ破損からのリカバリ 特定時点のスナップショットから永続ボリュームを復元し、迅速にデータを復旧 • DR・バックアップ運用 Block Volume Backupを活用し、Kubernetesワークロードのデータ保護・DRを実現 • データ複製・検証環境の作成 スナップショットから新しいボリュームを作成し、テスト・検証用データを容易に複製 39 Copyright © 2026, Oracle and/or its affiliates
40. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ ストレージ Kubernetesボリューム・クローンのサポート(2023年10月) (リリースノート: https://docs.oracle.com/ja-jp/iaas/releasenotes/changes/4e2317d0-262b-4a9c-b95b-4d564faaa9bb/index.htm) 概要 • CSIボリューム・プラグインでKubernetes Volume Cloneをサポート • 既存の永続ボリュームを複製し、データをコピーした新しいPVC/PVを作成可能 • 複製したボリュームはソースから独立し、本番データに影響を与えず利用可能 ユースケース • 本番データを利用したテスト・検証 本番ボリュームを複製し、本番環境へ影響を与えず構成変更やアプリケーションを検証 • 開発・検証環境の迅速な複製 既存ボリュームから新しい環境用のデータを複製し、開発・テスト環境を迅速に準備 • データを保持した環境の分岐・並行利用 同一データを起点とした独立ボリュームを作成し、複数の検証やワークロードで並行利用 40 Copyright © 2026, Oracle and/or its affiliates
41. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ ストレージ Ultra High Performance Block Volumeのサポート(2024年2月) (リリースノート: https://docs.oracle.com/ja-jp/iaas/releasenotes/changes/55907959-efe1-4e86-8f43-cedf21b01bfe/index.htm) 概要 • Ultra High Performance Block Volumeを利用するKubernetes PVCを作成可能 • 30～120 VPUの高性能Block VolumeをOKEの永続ストレージとして利用可能 • 対応ノードへPodを配置し、高いストレージ性能を必要とするワークロードを実行可能 ユースケース • データベース/メッセージング基盤 高いIOPS・低レイテンシを必要とするデータベースをOKE上で稼働 • 大規模データ処理基盤 大量データを高速に読み書きする分析・バッチ処理のストレージ性能を向上 • 高I/Oステートフルアプリ 高いストレージ性能を必要とするステートフルアプリをコンテナ環境へ展開 41 Copyright © 2026, Oracle and/or its affiliates
42. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ ストレージ RAWブロック・ボリューム・ストレージのサポート(2025年1月) (リリースノート: https://docs.oracle.com/ja-jp/iaas/releasenotes/conteng/conteng_Raw-block-volume-support.htm) RAWブロック・ボリュームPVCにおけるReadWriteManyアクセス・モードのサポート(2025年5月) (リリースノート: https://docs.oracle.com/ja-jp/iaas/releasenotes/conteng/conteng-Raw-block-volume-ReadWriteMany.htm) 概要 • CSI Volume PluginでRaw Block Volumeをサポート • OCI Block Volumeをコンテナからブロックデバイスとして直接利用可能 • ファイルシステムを介さずアクセスすることで、ストレージI/Oのオーバーヘッドを削減 ユースケース • Raw Device対応データベース・ストレージエンジン Block Deviceをアプリから直接制御するワークロード • Filesystemを介さない高性能I/O Filesystemオーバーヘッドを避けたい性能センシティブな処理 • 既存Raw Deviceアプリのコンテナ化 Raw Block Deviceを前提とする既存システムをOKEへ移行 42 Copyright © 2026, Oracle and/or its affiliates
43. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ ストレージ Lustreファイル・システムのPVCプロビジョニングをサポート(2026年3月) (リリースノート: https://docs.oracle.com/ja-jp/iaas/releasenotes/conteng/conteng-Storage-on-new-Lustre-filesystem.htm) 概要 • File Storage with LustreをOKEの永続ストレージとして利用可能 • PVC作成にあわせて新しいLustreファイルシステムを動的にプロビジョニング • Lustre CSIプラグインにより、KubernetesからLustreボリュームのライフサイクルを管理 Lustreについて詳しくはこちら https://speakerdeck.com/oracle4engineer/ochacafe-cloud-storage 43 Copyright © 2026, Oracle and/or its affiliates
44. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ ストレージ SMBクラスタ・アドオンのサポート(2026年7月) (リリースノート: https://docs.oracle.com/ja-jp/iaas/releasenotes/conteng/conteng-CSI-Driver-SMB-addon.htm) 概要 • CSI Driver SMBをOKEのクラスタ・アドオンとして利用可能 • SMB/CIFSファイル共有をKubernetes PersistentVolumeとしてマウント可能 - SMB/CIFS：ネットワーク経由でファイルやフォルダを共有するためのプロトコル、Windowsのファイル共有で広く利用 • 複数Pod/ノードから共有ファイルへアクセスするReadWriteMany（RWX）構成に対応 ユースケース • 共有ファイルストレージ 複数のPodから共通のSMBファイル共有へアクセスし、ファイルを共有するワークロードを実行 • ステートフルアプリのデータ永続化 アプリケーションデータをSMB共有へ保存し、Podやノードのライフサイクルから独立してデータを保持 • 既存SMBファイル共有を利用するアプリのコンテナ化 SMB/CIFSを利用する既存アプリケーションのストレージ構成を維持しながらOKEへ展開 44 Copyright © 2026, Oracle and/or its affiliates
45. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ ストレージ Virtual Nodes における永続ボリューム(FSS)のサポート(2026年8月) (リリースノート: https://docs.oracle.com/ja-jp/iaas/releasenotes/conteng/conteng_virtual-nodes-persistent-storage-support.htm) 概要 • Virtual NodesでOCI File Storage ServiceをバックエンドとするPersistent Volumeをサポート • Virtual Nodes上のPodから永続的な共有ファイルストレージを利用可能 • Managed / Self-managed / Virtual Nodesの各ノードタイプでFSSを利用した永続ストレージに対応 ユースケース • ステートフルアプリのVirtual Nodes移行 - 永続データを必要とするアプリケーションを、インフラ管理不要なVirtual Nodes上で実行 • 共有ファイルを利用するWeb・業務アプリ - 複数PodからFSS上のファイルやコンテンツを共有するアプリケーションをVirtual Nodes上に展開 • Kubernetes基盤の運用負荷軽減 - Virtual NodesとFSSを組み合わせ、Worker Nodeとストレージ基盤の管理負荷を抑えたアプリケーション基盤を構築 45 Copyright © 2026, Oracle and/or its affiliates
46. OKE (OCI Kubernetes Engine) Virtual Nodes OKE Virtual Node インフラ管理不要(サーバレス)の Worker Node オプション ▪ ユースケース • Worker Nodeの運用にコストをかけずに運用したい • Worker Nodeの運用コスト増大を防ぎたい ▪ 特長 Pod 自動 スケール • Worker Node の管理が不要のサーバレス Worker Node環境 (Master Node は従来通りマネージドで提供) • スケーリング、アップグレード、トラブルシューティングなどのWorker Node 運用上のコストを自動化 Node 自動 スケール(※) • 永続ストレージ（FSS）に対応 • スケーリングは未実装(2026/8現在) • コンテナアプリケーションが消費するリソース (CPU/メモリ) に基づいたきめ 細やかな従量課金 OKE Virtual Node OKE Virtual Node Managed Node Pool ▪ 価格 • Cluster(Enhanced Cluster): ¥15.5/hour • Virtual Node(1Nodeあたり): ¥2.325/hour • Podが利用するリソース(OCPU/メモリ): Computeと同様 (※別途Compute/Block Volume/Network/Load BalancerなどのIaaSサービス)利用分を課金) 46 Copyright © 2026, Oracle and/or its affiliates Container Engine For Kubernetes (※)2026/8時点で未実装
47. Virtual Nodes の File Storage Service サポート 動的プロビジョニング • PVC作成とトリガーに、CSIプラグインがPVとFile System を自動作成 • 必要に応じて Mount Target も作成 OKE Virtual Node Persistent Volume Claim (Read Write Many) OCI FSS CSI Plugin Read Write Many • Virtual Node 上の複数の Pod から同一 FSS を共有ス トレージとして利用可能 Persistent Volume セキュリティ・アクセス制御 • 保存時の暗号化 • 転送中の暗号化 File Storage Mount Target https://docs.oracle.com/jajp/iaas/Content/ContEng/Tasks/contengcreatingpersistentvolumeclaim_Provisionin g_PVCs_on_FSS.htm#contengcreatingpersistentvolumeclaim_topicProvisioning_PVCs_on_new_FSS-Encrypting_data.dita 47 Copyright © 2026, Oracle and/or its affiliates • Pod の securityContext における fsGroup / fsGroupChangePolicy によるファイル所有権と権限の管 理
48. 運用・監視、ノード管理・スケーリング 48 Copyright © 2026, Oracle and/or its affiliates
49. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ 運用・監視、ノード管理・スケーリング アップデート傾向 運用・監視： 3年間ほぼ一定ペースで、ログ・監視・ DR 基盤が拡充。2026年は「ヘルス監視」「自動パッチ選択」など運用の自動化、 省力化へシフト。 ノード管理・スケーリング： 2023年に基礎機能（仮想ノード、拡張クラスタ、2,000ノード上限など）が集中投入され、2025～2026年は Karpenter統合、20,000ノード対応など大規模スケーリングへ進化。 1 Copyright © 2026, Oracle and/or its affiliates
50. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ 運用・監視、ノード管理・スケーリング アップデート一覧 1 運用・監視 ノード管理・スケーリング ワーカーノード/主要アドオンのヘルス・リソース使用状況の監視サポート ※後半デモ実施 クラスタ当たり20,000のワーカー・ノードに対するサポート 自動パッチ・バージョン選択のサポート オンデマンド仮想ノード・サイクリングのサポート OCI Full Stack Disaster Recoveryのサポート Karpenter Provider for OCI (KPO)のサポート ※後半デモ実施 Kubernetesメトリック・サーバーのクラスタ・アドオンとしてのデプロイのサポート 管理対象ノードプールと仮想ノードプール混在クラスタのサポート Container Engine for Kubernetesサービス・ログのサポート ノード・サイクリングが再起動・ブートボリューム置換に拡張 OCI Kubernetes Engine (OKE)クラスタ・アドオンの更新 Cluster AutoscalerでのWorkload Identity Principalsの 使用サポート OCI Kubernetes Engine (OKE)では、管理対象ノードを以前の Kubernetesバージョンにロールバックできます ポッド・レディネス・ゲートの仮想ノード・サポート Copyright © 2026, Oracle and/or its affiliates - Armシェイプでポッドを実行する仮想ノードのサポート - 自己管理ノードのサポート
51. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ 運用・監視 ワーカーノード/主要アドオンのヘルス・リソース使用状況の監視サポート (リリースノート:https://docs.oracle.com/iaas/releasenotes/conteng/conteng-Cluster-Observability-Release-Note.htm) 概要 • • OKE が、ワーカーノードごとに2つのマネージド・クラスタ・アドオンをデプロイ • ObservabilityAgent：kubelet、cAdvisor、CoreDNS、KubeProxy などからインフラ／リソース・メトリックを収集 • NodeProblemDetector：リソース逼迫、ネットワーク障害などのノードレベルの問題を検出し、Kubernetes のイベントや Condition として公開 収集したデータは、Prometheus／OpenMetrics 互換のツールから取得・可視化できる ユースケース • ノード障害・リソース逼迫の予兆検知 CPU、メモリー、ネットワーク使用率や Node Condition を監視し、Pod の性能低下やスケジューリング障害につながる問題を早 期に発見 • DNS 障害の迅速な切り分け CoreDNS のリクエスト数、エラー率、レスポンス時間を確認し、名前解決遅延や DNS エラーを分析 • Service ネットワークのトラブルシューティング KubeProxy のネットワーク統計を利用し、Service 経由の通信問題や異常を調査 51 Copyright © 2026, Oracle and/or its affiliates
52. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ 運用・監視 自動パッチ・バージョン選択のサポート (リリースノート:https://docs.oracle.com/ja-jp/iaas/releasenotes/conteng/conteng-k8s-patch-version-selection-Release-Note.htm) 概要 • クラスタまたはノード・プールの作成／更新時に、Kubernetes バージョンを major.minor 形式（例：1.35）で指定可能 • x.y を指定すると、OKE がそのマイナー系列で利用可能な最新のサポート済みパッチ・バージョンを自動選択 • 従来どおり major.minor.patch形式（例：1.35.2）で、特定のパッチ・バージョンを明示的に指定することも可能 • コンソール、OCI CLI、API から利用でき、Oracle は通常の運用では x.y 形式をベスト・プラクティスとして推奨 ユースケース • クラスタ構築・更新の自動化を簡素化 CLI／API ベースの自動化でパッチ番号を都度書き換えず、利用するマイナー系列だけを指定 • 新規クラスタ／ノード・プールのセキュリティ強化 古いパッチを誤って選択することを避け、OKE が検証・サポートする最新パッチを採用 • 複数クラスタのバージョン運用を標準化 組織として「 Kubernetes 1.x 系列を使用する」という方針を定め、更新時点の最新パッチへ統一 52 Copyright © 2026, Oracle and/or its affiliates
53. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ 運用・監視 OCI Full Stack Disaster Recovery のサポート (リリースノート:https://docs.oracle.com/iaas/releasenotes/conteng/conteng_FSDR-support.htm) 概要 • OKE クラスタを OCI Full Stack Disaster Recovery の DR 保護グループ（DR Protection Group）へ追加可能 • プライマリ／スタンバイ・リージョンの OKE クラスタを関連付け、Kubernetes リソースのバックアップ／リストアを含むエンドツーエンドの 復旧オーケストレーションを自動化 • OKE だけでなく、Compute、ストレージ、データベース、ロードバランサなどを含むアプリケーション全体を、共通の DR プランで連携 して復旧できる ユースケース • リージョン障害に備えたミッションクリティカル・システムのDR プライマリ・リージョンが利用できない場合に、OKE ワークロードをスタンバイ・クラスタへ復旧 • ステートフルなKubernetesアプリケーションの復旧 Kubernetes 構成に加えて、Persistent Volume で使用する Block Volume／File Storage のリージョン間レプリケーション を連携 • 複数サービスで構成されるシステムの一括切替え OKE、データベース、Compute、ストレージなどの復旧順序や依存関係を、1つの DR プランとしてオーケストレーション 53 Copyright © 2026, Oracle and/or its affiliates
54. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ 運用・監視 OCI Full Stack Disaster Recovery FSDR は、あらかじめ定義した復旧手順（DR Plan）に従って、 セカンダリ環境の OKE とその依存リソースを順番に復旧及び切 り替えるオーケストレーションサービス 仕組み • OKE 設定は Object Storage へ、PV データはブロック/ ファイルストレージのレプリケーション機能で、待機リージョンへ 継続的にコピー • FSDR が両リージョンを「DR 保護グループ」としてまとめ、 「DR プラン」（フェイルオーバー/スイッチオーバー）を自動生 成 • 実行時はボタン一つで、設定復元・ボリュームアタッチ・アプリ 起動までを自動実行 54 Copyright © 2026, Oracle and/or its affiliates
55. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ 運用・監視 Kubernetes メトリック・サーバーのクラスタ・アドオンとしてのデプロイのサポート (リリースノート:https://docs.oracle.com/iaas/releasenotes/changes/afbe9f1e-0a4a-4688-b2be-8c27dae19582/index.htm) 概要 • Kubernetes Metrics Server は、各ワーカー・ノードの kubelet から Node／Pod の CPU・メモリー使用量を収集し、 Kubernetes API Server を介して Resource Metrics API（metrics.k8s.io）として公開 • OKE のクラスタ・アドオンとして導入することで、Metrics Server の有効化／無効化、バージョン選択、構成変更、更新管理を OKE から実行可能 • Oracle による自動更新を利用する方式と、特定バージョンを選択して利用者が更新を管理する方式を選択可能 ユースケース • Horizontal Pod Autoscalerによる自動スケーリング Pod の CPU／メモリー使用状況に応じて、Deployment や StatefulSet のレプリカ数を自動調整 • Node／Pod のリソース使用状況の即時確認 kubectl top node や kubectl top pod を利用し、CPU／メモリー逼迫や負荷の偏りを迅速に確認 • 複数OKEクラスタへの標準的なメトリクス基盤の導入 クラスタごとにマニフェストや Helm チャートを個別管理せず、共通のアドオン管理方式で展開 • アドオンの保守・脆弱性対応の効率化 Oracle による自動更新を利用して運用負荷を軽減するか、互換性要件がある環境ではバージョンを固定して計画的に更新可能 55 Copyright © 2026, Oracle and/or its affiliates
56. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ 運用・監視 Container Engine for Kubernetes サービス・ログのサポート (リリースノート:https://docs.oracle.com/iaas/releasenotes/changes/afbe9f1e-0a4a-4688-b2be-8c27dae19582/index.htm) 概要 • OKE クラスタのコントロール・プレーンで稼働する、主要な Kubernetes プロセスのログを OCI Logging で確認可能（kubeapiserver、kube-scheduler、kube-controller-manager、cloud-controller-manager） • クラスタとログ・カテゴリを指定してサービス・ログを有効化し、時刻やキーワードによる検索、フィルタリング、可視化を実現 • ログはデフォルトの Kubernetes ログ詳細度である v=2 で出力され、通常動作の情報に加えて、システム上の重要な変化と関連 するメッセージを記録 ユースケース • Pod スケジューリング問題の調査 kube-scheduler の判断やエラーを確認し、Pod がノードへ配置されない原因を分析 • Kubernetes リソースの状態収束問題の調査 kube-controller-manager のイベントから、Deployment などが期待状態へ収束しない原因を確認 • OCI リソースのプロビジョニング障害の調査 cloud-controller-manager のログから、Load Balancer などの作成・更新処理を分析 • API およびコントロール・プレーン障害の切り分け kube-apiserver の処理、ネットワーク分断、Kubernetes プロセスのクラッシュ、ストレージ利用不能、構成ミスを調査 56 Copyright © 2026, Oracle and/or its affiliates
57. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ 運用・監視 Container Engine for Kubernetes サービス・ログのサポート コントロールプレーンの各コンポーネント（kube-apiserver、cloud-controller-manager、kube-controller-manager、kubescheduler、All log sources（一括取得））のログも取得可能 type=Loadbalancer のサービスを削除したログ 57 Copyright © 2026, Oracle and/or its affiliates
58. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ 運用・監視 OCI Kubernetes Engine (OKE)クラスタ・アドオンの更新 (リリースノート:https://docs.oracle.com/ja-jp/iaas/releasenotes/conteng/conteng-Add-on-release-notes-July-2026-Release-Note.htm) 概要 • 次のクラスタ・アドオンの新バージョンを提供 • WebLogic Kubernetes Operator：v4.3.10 • Istio：v1.29.5 • OCI Native Ingress Controller：v1.4.5 ユースケース • Gateway API 環境の証明書ライフサイクル自動化 Gateway リソースと cert-manager を連携し、HTTPS リスナーで使用する証明書の発行・更新と Kubernetes Secret への 格納を自動化 • gRPC マイクロサービスの外部公開 OCI Load Balancer に HTTP/2 ベースの gRPC リスナーを構成し、gRPC API を OKE 上のサービスへ安全にルーティング • 監視機能の可用性・リソース競合制御 ObservabilityAgent に組織の PriorityClass を適用し、リソース逼迫時のスケジューリング順序をクラスタの運用方針に合わせ て調整 58 Copyright © 2026, Oracle and/or its affiliates
59. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ 運用・監視 OCI Kubernetes Engine (OKE)では、管理対象ノードを以前のKubernetesバージョンにロールバック (リリースノート:https://docs.oracle.com/ja-jp/iaas/releasenotes/conteng/conteng_K8s-version-rollback.htm) 概要 • 既存の管理対象ノード・プールに以前の利用可能な Kubernetes バージョンを指定し、ノードを置き換えることで、ワーカー・ノード のバージョンをロールバック可能 • 拡張クラスタと基本クラスタの管理対象ノードに対応、対象はワーカー・ノードのみで、コントロール・プレーンおよび仮想ノードのロール バックには非対応 • ロールバック先は、テナンシで選択可能かつ、現在のコントロール・プレーンとバージョン互換性のある Kubernetes バージョンに限定 される ユースケース • アップグレード後の互換性問題からの復旧 kubelet やノード側コンポーネントの更新後に、アプリケーション、デバイス・プラグイン、運用エージェントなどで問題が発生した場合に 以前の構成へ戻す • 段階的アップグレードのフォールバック 一部のノード・プールを先行更新し、検証で問題が見つかった場合に、そのノード・プールだけをロールバック • 障害対応時の暫定復旧 原因分析や修正版の準備中に、直前まで稼働していたバージョンへ戻してサービスを安定化 59 Copyright © 2026, Oracle and/or its affiliates
60. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ ノード管理・スケーリング クラスタ当たり20,000のワーカー・ノードに対するサポート (リリースノート:https://docs.oracle.com/iaas/releasenotes/conteng/conteng_20000-node-support.htm) 概要 • OKE の拡張クラスタ（Enhanced Cluster）で、Kubernetesバージョン1.36以降、管理対象／自己管理ワーカーノードを最 大20,000台まで収容可能 • 5,000ノードを超える場合は、Oracle アカウント・チームによる事前承認が必要 • 利用可否は、リージョン／レルムのキャパシティ、テナンシのサービス制限、ネットワーク構成などに依存 ユースケース • 超大規模な共通 Kubernetes 基盤 複数部門、サービス、テナントのワークロードを単一の共有クラスタへ集約 • 大規模な並列・分散処理 AI/ML、バッチ処理、シミュレーションなど、多数のワーカーノードを必要とする処理基盤 • クラスタ統合による運用最適化 管理対象クラスタを減らし、監視、セキュリティ、アップグレード、ガバナンスを効率化 60 Copyright © 2026, Oracle and/or its affiliates
61. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ ノード管理・スケーリング オンデマンド仮想ノード・サイクリングのサポート (リリースノート:https://docs.oracle.com/iaas/releasenotes/conteng/conteng-virtual-node-cycling-release-note.htm) 概要 • 仮想ノードプールのプロパティ変更後にサイクリングを実行すると、OKE が既存ノードを自動的に Cordon → Drain → Terminate し、更新後のプロパティを持つ仮想ノードへ置き換える • 一時的に追加するノード数を示す maxSurge と、同時に利用不可にできるノード数を示す maxUnavailable により、サービス 可用性・更新速度・コストのバランスを制御可能 • 2026年7月6日時点では、OCI CLI および API から利用可能 ユースケース • 仮想ノード設定の一括反映 新しいノードプールを作成してワークロードを移行することなく、既存プール内のノードを新しい設定へ順次置換 • 可用性を維持したローリング更新 新しいノードを先に追加してから既存ノードを削除し、サービス停止リスクを抑えながら更新 • 大規模仮想ノードプールの更新自動化 手作業によるノード退避・削除・再作成を OKE に任せ、更新作業を標準化 61 Copyright © 2026, Oracle and/or its affiliates
62. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ ノード管理・スケーリング オンデマンド仮想ノード・サイクリングのサポート 新ノードは Active になると、新規 Pod や Drain で再作成された Pod の配置候補になります。実際の配置先は、リソースや Affinity などの条件に基づき、既存ノードを含めて Scheduler が決定する。 maxSurge = 1 / maxUnavailabel = 0 OKE Virtual Node OKE Virtual OKE Virtual OKE Virtual Node Node Node OKE Virtual OKE Virtual OKE Virtual Node Node Node 新 ノードプール 設定変更 62 新設定 ノード作成 パラメータ 説明 maxSurge 一時的に追加できるノード数の上限 maxUnavailabel 一時的に使用不可にできるノード数の上限 Copyright © 2026, Oracle and/or its affiliates 新 旧 OKE Virtual OKE Virtual OKE Virtual Node Node Node 新 旧ノード Cordon • • 対象ノードを「スケジュール不可」 に設定 新しいPodがこのノードに割り当て られなくなる 旧 Pod Drain • • Terminate OKE Virtual Node OKE Virtual OKE Virtual OKE Virtual Node Node Node 新 旧 旧ノード Terminate 既存のPodを他のノードへ自動移動 Kubernetes のスケジューラーが最適なノードを選んで 再配置
63. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ ノード管理・スケーリング Karpenter Provider for OCI (KPO) のサポート (リリースノート:https://docs.oracle.com/iaas/releasenotes/conteng/conteng-Karpenter-Support-Release-Note.htm) 概要 • オープンソースのノード・オートスケーラーである Karpenter を OKE クラスタで利用可能 • Pod を配置できるノードがない場合、Karpenter が Pod の要件を評価し、KPO が必要な Compute インスタンス、VNIC、ブー ト・ボリュームを作成してワーカーノードをクラスタへ追加 • Karpenter の NodePool でスケジューリング要件、上限、ノード置換ポリシーを定義し、OCINodeClass でシェイプ、イメージ、 ネットワーク、ストレージなどの OCI 固有設定を定義する ユースケース • 突発的な負荷への高速なスケールアウト トラフィック急増、イベント処理、バッチジョブなどに対し、Pending Pod の要件から必要なノードを直接追加 • ワークロードに適したComputeリソースの自動選択 CPU、メモリー、アーキテクチャ、可用性ドメインなどの条件に基づき、複数のシェイプ候補から適切な構成を選択 • インフラ・コストの最適化 Flexible Shape や Preemptible Instance を活用し、余剰キャパシティの集約と不要ノードの削減を自動化 63 Copyright © 2026, Oracle and/or its affiliates
64. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ ノード管理・スケーリング 管理対象ノードプールと仮想ノードプール混在クラスタのサポート (リリースノート:https://docs.oracle.com/iaas/releasenotes/conteng/conteng-Mixed-node-clusters-support-Release-Note.htm) 概要 • 1つの OKE クラスタ内に、管理対象ノード・プールと仮想ノード・プールを共存させることが可能 • 新規クラスタだけでなく、既存クラスタにも両方のノード・プールを追加できる • 管理対象ノード、仮想ノード、自己管理ノードを組み合わせ、ワークロードごとに最適な実行基盤を選択可能 ユースケース • ステートフル／ステートレスの適材適所配置 PVC や予測可能な性能が必要なステートフル・ワークロードは管理対象ノード、API フロントエンドや処理キューなどのステートレス・ワークロードは仮想ノードへ配置 • サーバーレス化の段階的な導入 仮想ノードへ移行可能なコンポーネントだけを移し、ノード制御が必要な既存ワーク ロードは管理対象ノードに維持 • AI/MLと一般アプリケーションの統合 GPU や特殊なネットワーク構成を必要とする処理は管理対象／自己管理ノード、 弾力的に増減する周辺 API やジョブは仮想ノードで実行 64 Copyright © 2026, Oracle and/or its affiliates
65. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ ノード管理・スケーリング ノード・サイクリングが再起動・ブートボリューム置換に拡張 (リリースノート:https://docs.oracle.com/ja-jp/iaas/releasenotes/conteng/conteng-node-cycling-release-note.htm) 概要 • 従来のノードの終了・再作成に加え、ノード・サイクリングの操作として以下をサポート ①ノードの再起動、②ブート・ボリュームの置換 • OKE が対象ノードを自動的に Cordon → Drain → 再起動／ブート・ボリューム置換し、ワークロードを退避してからメンテナンス を実行 • 管理対象ノードと自己管理ノードの個別操作に対応。管理対象ノード・プールでは、全ノードのブート・ボリュームを順次置換すること も可能 ユースケース • ノード障害・一時的な不具合の解消 OS やネットワーク状態、GPU／NVLink 関連の問題などに対し、Pod を退避して安全にノードを再起動 • 構成ドリフトや基盤障害のリセット ノードを終了せずにブート・ボリュームを新規作成して置換し、OS 環境をクリーンな状態へ復元 • ノード・プール設定の一括更新 Kubernetes バージョン、ノード・イメージ、SSH 公開鍵、KMS キー、ブート・ボリューム容量などを、ブート・ボリューム置換によって 全ノードへ反映 65 Copyright © 2026, Oracle and/or its affiliates
66. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ ノード管理・スケーリング ノード・サイクリングが再起動・ブートボリューム置換に拡張 Node Node Node Node Node 旧ノード Cordon 対象ノード • • 66 Node 対象ノードを「スケジュール不可」 に設定 新しいPodがこのノードに割り当て られなくなる Copyright © 2026, Oracle and/or its affiliates • • 2.ブートボリューム 置換 Node Pod Drain 1.インスタンス 再起動 Node Node 対象ノード再起動 ブート・ボリューム置換 既存のPodを他のノードへ自動移動 Kubernetes のスケジューラーが最適 なノードを選んで再配置 メンテナンス後、Pod のスケジュールが 可能となる
67. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ ノード管理・スケーリング Cluster Autoscaler での Workload Identity Principals の使用サポート (リリースノート:https://docs.oracle.com/iaas/releasenotes/changes/7bb6aca4-5c39-4ce6-bd19-40fd3a06fa5c /index.htm) 概要 • Kubernetes Cluster Autoscaler が管理対象ノード・プールを拡縮する際、OCI API の認証にワークロード・アイデンティティ・プ リンシパルを利用可能 • Cluster Autoscaler をスタンドアロン・プログラムとして実行する場合と、OKE のクラスタ・アドオンとして実行する場合の両方に対 応 • 従来のインスタンス・プリンシパルも引き続き選択可能 ユースケース • 最小権限によるオートスケーリング ノード・プール、Compute、サブネット、VNIC などの操作権限を、ワーカー・ノード全体ではなく Cluster Autoscaler ワークロード に限定 • 共有クラスタのセキュリティ強化 同じノード上で動作する他の Pod から権限を分離し、ノード単位のインスタンス・プリンシパルより細かなアクセス制御を実現 • ノード配置に依存しない認証 Cluster Autoscaler の Pod が別のノードへ再配置されても、ServiceAccount に基づく同一の IAM 認証・認可を維持 67 Copyright © 2026, Oracle and/or its affiliates
68. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ ノード管理・スケーリング Cluster Autoscaler での Workload Identity Principals の使用サポート 68 Copyright © 2026, Oracle and/or its affiliates
69. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ ノード管理・スケーリング ポッド・レディネス・ゲートの仮想ノード・サポート (リリースノート:https://docs.oracle.com/iaas/releasenotes/changes/64ce7d9b-fe1f-4c39-a351-eac150ab68bd/index.htm) 概要 • OKE が LoadBalancer タイプの Kubernetes Service として OCI Load Balancer／Network Load Balancer を作成 する際、仮想ノード上の Pod に Readiness Gate を設定可能 • Pod が通常の起動・準備条件を満たすだけでなく、OCI ロードバランサのバックエンド・セットへ正常に登録されたことを確認してから トラフィックを転送 • 新 Pod のバックエンド登録前に旧 Pod が終了する、または準備未完了の新 Pod へ通信が流れる、といった更新時のタイミング問 題を防止する ユースケース • 無停止に近いローリング・アップデート 新しい Pod がバックエンド・セットへ登録され、トラフィックを受信できる状態になるまで既存 Pod を維持 • 起動に時間がかかるアプリケーションの保護 初期化、キャッシュ生成、外部サービス接続などの完了前にトラフィックが到達することを防止 • 仮想ノードのスケールアウト時の安定化 新しく作成された Pod を、ロードバランサ側の登録処理が完了してからサービスへ参加させる 69 Copyright © 2026, Oracle and/or its affiliates
70. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ ノード管理・スケーリング 70 Copyright © 2026, Oracle and/or its affiliates
71. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ ノード管理・スケーリング Arm シェイプでポッドを実行している仮想ノードのサポート (リリースノート:https://docs.oracle.com/ja-jp/iaas/releasenotes/changes/eedb536d-48c3-4c35-aa5e-80d2a123de68/index.htm) 概要 • OKE の仮想ノードで、Arm ベースの Pod シェイプである Pod.Standard.A1.Flex を選択可能 • 対象の仮想ノードへスケジュールされた Pod は、OCI Ampere A1のArm プロセッサ上で実行される • 仮想ノードが持つ、ワーカー・ノード基盤のプロビジョニング、スケーリング、アップグレード、障害対応を OKE へ委ねる運用モデルを維 持しながら、Arm アーキテクチャを利用できる ユースケース • Arm ネイティブ・アプリケーションのサーバーレス実行 Arm 向けにビルドしたコンテナを、ワーカー・ノードの OS やインフラを管理せずに OKE へデプロイ • マルチアーキテクチャ対応の促進 同一タグに amd64 と arm64 を含むマルチアーキテクチャ・イメージを使用し、実行環境に応じて適切なイメージを自動選択 • Arm 移行に向けた開発・検証環境 既存アプリケーション、ライブラリ、サイドカーなどの Arm 互換性を、本番移行前に Kubernetes 環境で検証 71 Copyright © 2026, Oracle and/or its affiliates
72. OKE の進化 ～ OKE の主要なアップデートと使いどころ ～ ノード管理・スケーリング 自己管理ノードのサポート (リリースノート:https://docs.oracle.com/ja-jp/iaas/releasenotes/changes/da5f7092-29ab-4838-8e5f-447b488c2c4c /index.htm) 概要 • 利用者が OCI Compute で作成した Compute インスタンスまたはインスタンス・プールを、OKE クラスタのワーカー・ノードとして 登録可能 • 自己管理ノードは一般に Bring Your Own Nodes（BYON） と呼ばれ、OKE が作成・管理する管理対象ノードとは異なり、 OKE のノード・プールには所属しない • Compute サービスから直接作成するため、管理対象ノードや仮想ノードでは選択できない、特殊なシェイプや構成を Kubernetes ワークロードに利用できる ユースケース • GPU を使用する AI／ML 基盤 GPU シェイプやベアメタル構成を選択し、モデル学習・推論などのハードウェア・アクセラレーション用途に活用 • HPC・大規模分散処理 HPC／Optimized シェイプと、広帯域・超低遅延の RDMA クラスタ・ネットワークを組み合わせ、ノード間通信が多い処理を実行 • 特殊な Compute 構成の利用 シェイプ、イメージ、ストレージ、ネットワーク、配置方式などを Compute レベルで詳細に制御 72 Copyright © 2026, Oracle and/or its affiliates
73. OKEクラスタ管理の現在地 Karpenter/Observability Agent Demo
74. Karpenter 74 Copyright © 2026, Oracle and/or its affiliates
75. OKE クラスタ管理の現在地 ～ Karpenter/Observability Agent Demo ～ Karpenter • Karpenter（カーペンター）は、ワークロードの要求に応じて Kubernetes ノードを動的に起動・削除する、ノードオートスケーラー ／ライフサイクル管理基盤 • スケジュールできない Pod の CPU・メモリ、Zone、Affinity、Toleration などの条件を評価し、要件に合うノードを直接プロビジョ ニング • AWS が 2021 年に開発・OSS 化し、現在はベンダー中立の Kubernetes SIG Autoscaling のもとで開発、現在は複数クラ ウド向けの実装が提供 • OCI 向けが Karpenter Provider for OCI（KPO） で、Oracle が提供およびサポート https://karpenter.sh/ 75 Copyright © 2026, Oracle and/or its affiliates
76. OKE クラスタ管理の現在地 ～ Karpenter/Observability Agent Demo ～ Karpenter と Cluster Autoscaler の違い Cluster Autoscaler：既存のノードグループの台数を増減する仕組み Karpenter：Pod の要件に合うノードを動的に設計/作成し、ライフサイクルまで管理する仕組み 観点 Cluster Autoscaler Karpenter 共通 スケジュールできない Pod を検出してノードを追加し、 不要になったノードを削除 ノード構成 事前定義したプールを増減 必要なノードを都度作成 スケール単位 ノードプール単位 インスタンス単位 起動の速さ 遅め（プール経由） 速い（直接起動） 余剰の削除 削除のみ 削除＋統合＋小型化（Consolidation） Karpenter は、 Pod がリソース不足でスケジュールできない場合は、ちょうど良いサイズのノードを即座に追加、 Pod が減ってリソースに余剰が出た場合は、ノードを自動削除。 76 Copyright © 2026, Oracle and/or its affiliates
77. OKE クラスタ管理の現在地 ～ Karpenter/Observability Agent Demo ～ Karpenter の Consolidation における3つのパターン 空ノードの削除 統合 小型化 Pod が無いノードを削除 他ノードの空きに寄せてからノード削除 余剰シェイプの変更 Node A 稼働中 Node B Pod 無し 空 空 Node A 空きあり Node B 空きあり 削除 Node A 稼働中 77 Node B 削除 Copyright © 2026, Oracle and/or its affiliates 余剰 Node (4 OCPU / 32 GB) リソースが大幅に余剰 置き換え 1. 新ノード作成 2. Pod 移動 3. 余剰ノード削除 寄せて削除 Node A 稼働中 Node B 削除 Node (1 OCPU / 8 GB) 適切なリソースに変更 Node (4 OCPU /32GB) 余剰ノードを削除
78. OKE クラスタ管理の現在地 ～ Karpenter/Observability Agent Demo ～ Karpenter Provider for OCI（KPO）デモ概要 以下2種類の CRD を適用することで、Karpenter Controller がその設定を読み取る。 OCINodeClass：どんな仮想マシンを作るか NodePool：いつどれだけ作成/削除するか Namespace: karpenter Namespace:default Karpenter Controller 1. リソース不足で Pod が OCI Kubernetes Engine 既存ノードプール Pending 状態、それを Karpenter Controller が検 知して、Node を自動追加 OCI Compute OCI Compute Karpenter 管理ノードプール 2. ノード追加後、Pod は全て Running となる 3. Pod を 0 スケール、それを Karpenter Controller が検 OCI Compute 78 Copyright © 2026, Oracle and/or its affiliates OCI Compute 知して、Node を自動削除
79. OKE クラスタ管理の現在地 ～ Karpenter/Observability Agent Demo ～ OCINodeClass - OCI 固有の「ノードの作り方」テンプレート - 起動できるシェイプの候補 （Flex シェイプの OCPU / メモリ） ブートボリューム & イメージ （OKE 対応イメージを自動選択） ネットワーク（OCI VCN-Native Pod Networking 前提） Pod 用のセカンダリ VNIC（VCN-Native では必須） 公式ドキュメント：OCINodeClassリファレンス https://docs.oracle.com/ja-jp/iaas/Content/ContEng/Tasks/conteng-kpo.htm#conteng-kpo-ocinodeclass 79 Copyright © 2026, Oracle and/or its affiliates
80. OKE クラスタ管理の現在地 ～ Karpenter/Observability Agent Demo ～ NodePool - いつ、どれだけノードを作る／消すかの運用ルール Karpenter Docs: https://karpenter.sh/docs/ concepts/disruption/ • • WhenEmpty:空ノードのみ Balanced：空・明らかに余っ たノードは消すが、割に合わな い入れ替えはしない 空 or 低使用率のノードを統合して削減 1 分様子を見てから統合 クラスタ全体でこの NodePool が確保できる上限 （暴走防止の安全弁） オンデマンド（Spot/Preemptible は使わない） 使ってよいシェイプ候補 公式ドキュメント：スケジューリング、ラベルおよびテイント https://docs.oracle.com/ja-jp/iaas/Content/ContEng/Tasks/conteng-kpo.htm#conteng-kpo-scheduling 80 Copyright © 2026, Oracle and/or its affiliates
81. OKE クラスタ管理の現在地 ～ Karpenter/Observability Agent Demo ～ デモ資材 • 本日のデモで使用した資材 https://github.com/cyberblack28/karpenter-demo/tree/main • Karpenter Provider for OCI (KPO) 公式ドキュメント https://docs.oracle.com/ja-jp/iaas/Content/ContEng/Tasks/conteng-kpo.htm#conteng-kpo-ocinodeclass • Karpenter 公式 https://karpenter.sh/ 81 Copyright © 2026, Oracle and/or its affiliates
82. Observability Agent 82 Copyright © 2026, Oracle and/or its affiliates
83. OKEクラスタ管理の現在地 ～ Karpenter/Observability Agent Demo ～ Observability Agent Worker Node Worker Node Pod / Container のメトリクスを、Prometheus と Grafana で可視化 • OKE Add-on のObservability Agent を利用 App App Observability Agent Observability Agent :9995 :9995 • Worker Node ごとに Endpoint が存在するので、Prometheusで 集約 • 裏側で秒間10-100 のリクエストをAPI pod に対して実行 • Observability Agent からのメトリクスをGrafanaで確認 83 Copyright © 2026, Oracle and/or its affiliates
84. OKEクラスタ管理の現在地 ～ Karpenter/Observability Agent Demo ～ Observability Agent OKE Enhanced Cluster で利用できる、各 Worker Node に配備される add-on 標準メトリクスを mTLS endpoint に集約 • kubelet: Pod / Node の状態 Worker Node • CoreDNS: DNS リクエスト • cAdvisor: コンテナのリソース利用度 • kube-proxy: ネットワークの振る舞い Node ごとのエンドポイント公開 • https://<node-ip>:9995/metrics（port変更可能） App Observability Agent • Prometheus / OpenMetrics 形式 • mTLS で保護 84 Copyright © 2026, Oracle and/or its affiliates :9995
85. Thank you 85 Copyright © 2026, Oracle and/or its affiliates