OCI入門 Vol6 OKE入門 マネージドKubernetes クラスター作成・ノードプール・運用

1. この記事について — OCIのマネージドKubernetesを深掘りする

1-1. 本記事のゴール

本記事を読み終えると、次の4つができるようになります。

第一に、要件からBasic ClusterとEnhanced Clusterのどちらを選ぶべきか判断できるようになります。コントロールプレーンの課金有無・SLAの有無・対応機能の違いという3つの軸で、自分のワークロードに合った選択ができるようになります。

第二に、実際にOKEクラスターを作成し、kubeconfigを取得してkubectlで接続できるようになります。コンソールでのQuick Create、既存VCNを指定するCustom Createの両方の勘所を押さえます。

第三に、仮想ノード・マネージドノード・自己管理ノードという3種類のワーカーノードを使い分けられるようになります。サーバーレスに任せたい場面と、細かく制御したい場面の違いを理解し、Vol4で扱ったコンピュート形状の知識をどこで活かせるかが分かるようになります。

第四に、Kubernetesバージョンのアップグレード方式を判断できるようになります。コントロールプレーンとワーカーノードそれぞれのアップグレード手順と、In-place/Out-of-placeの選択基準を押さえます。

これら4つのゴールは、いずれも「知っている」で終わらせず「判断できる」「手を動かせる」状態を目指しています。読み進める際は、単に用語や機能名を覚えるのではなく、次にOKEクラスターを実際に触る場面でどう判断するかを意識しながら読んでいただくと、より実践的な理解につながります。

具体的な成果物イメージとして、次の一連の流れを本記事全体を通じて体験します。

OCIコンソールでOKEクラスターを作成(Quick Create)
  → oci ce cluster create-kubeconfig でkubeconfigを取得
  → kubectl get nodes でワーカーノードの疎通を確認
  → kubectl apply -f でサンプルアプリケーションをデプロイ
  → LoadBalancerサービスでアプリへの外部アクセスを確認

これらはすべて、Vol1〜5で構築したテナンシ・IAM・VCN・コンピュート・ストレージという土台の上に成り立ちます。単発の操作手順の暗記ではなく、なぜその選択をするのかという判断軸を持ち帰っていただくことを目指します。

本記事の各章は、単なる機能紹介にとどまらず、①なぜその選択をするのかという判断根拠、②実際に手を動かすハンズオン、③実務で陥りやすい落とし穴、④AWS EKSとの詳細対比、という4つの観点を必ず織り込む構成にしています。これは「シリーズ最終巻を薄くしない」という執筆方針に基づくものです。概要だけをなぞる記事ではなく、実際にOKEを使い始める際に迷う具体的なポイントまで踏み込みます。

なお、テナンシの作成やIAMポリシーの設計、VCNの構築そのものといったVol1〜3の内容は、本記事では前提知識として扱い、手順の再説明は行いません。それらの詳細を確認したい場合は、それぞれの巻を参照してください。

ハンズオンを実際に進める前提として、手元の環境にOCI CLIとkubectlがインストールされていることを想定しています。両ツールのインストール手順自体はOracle公式ドキュメントに譲り、本記事ではOKE固有のコマンドや判断のポイントに絞って解説します。また、Vol3で構築したVCN(パブリック/プライベートサブネットを含む構成)がすでに用意されている前提で進めますので、まだの場合はVol3を先に完了させておくことをお勧めします。

1-2. 読者像

本記事が想定する読者は、AWS EKSを実務で使った経験があるものの、OCIのOKEは未経験というクラウド実務者です。KubernetesのPod・Deployment・Service・ノードといった基礎概念はすでに理解しており、あらためて説明を必要としない前提で執筆しています。

また、Vol1〜5(テナンシ・コンパートメント、IAM、VCN、コンピュート、ストレージ)を読了済み、あるいは同等の知識をお持ちであることを前提としています。テナンシの作成方法やIAMポリシーの書き方、VCNのサブネット設計といった内容は本記事では再説明しません。

こうした読者が実際にOKEに触れる場面で直面しやすい課題は、次のようなものです。

• 「OKEのBasic ClusterとEnhanced Clusterの違いが分からない。どちらを選べばよいのか」
• 「仮想ノードという仕組みがあるらしいが、EKSのFargateと同じものなのか、それとも別物なのか」
• 「EKSのマネージドノードグループに相当する仕組みはOKEにあるのか」
• 「kubeconfigの取得方法やkubectlでの接続手順は、EKSと同じ感覚で進められるのか」
• 「クラスターのアップグレードやノードの入れ替えを、本番環境で安全に行う方法が分からない」

これらはいずれも、機能一覧を眺めるだけでは解決しない、実際に手を動かして初めて実感する課題です。本記事では、単に「OKEにはこういう機能がある」と紹介するのではなく、EKSでの経験と比較しながら「なぜOKEではこう設計されているのか」「EKSの感覚のままだとどこでつまずくのか」という視点を軸に解説します。

こうした課題感は、実際にAWSからOCIへの移行を検討する場面や、マルチクラウド構成でOKEを併用する場面で顕在化しやすいものです。本記事はそのような実務上の意思決定に耐えうる解像度を目指しています。

本記事は、これらの疑問に一つずつ答えていく構成になっています。EKSで得た知識を土台にしながら、OKE固有の用語や判断基準を身につけていただくことを狙いとしています。

疑問と対応する章の関係を先に示しておきます。Basic/Enhancedの選び方は2章、仮想ノードとFargateの違いは4章、マネージドノードグループとの対応は4章、kubeconfig取得とkubectl接続の実践は5章、アップグレードやノード入れ替えの安全な進め方は6章で扱います。読みたい章から先に読んでも迷わないように設計していますが、Basic/Enhancedの判断軸(2章)を先に押さえておくと、以降の章の理解が格段にスムーズになります。

本記事全体の書き方として、EKSの用語や操作感を「アンカー」として使いながら説明を進めます。「EKSでいうところの◯◯に相当します」という言い回しが繰り返し登場しますが、これは理解の近道として意図的に採用している構成です。EKSの経験がまったくない読者にとっては遠回りに感じる可能性がありますが、その場合はVol1〜5から順に読み進めることをお勧めします。

逆に、本記事では扱わない内容も明確にしておきます。テナンシの作成手順、IAMポリシーの文法、VCNのサブネット設計、コンピュートのシェイプ選定の詳細、ブロックボリュームの性能特性といった内容は、それぞれVol1〜5で扱い済みの前提として再説明しません。OKE固有の観点に絞ることで、全体を薄めず深く掘り下げます。

読み進める前の前提条件を、簡単なチェックリストとして整理しておきます。

• OCIテナンシを保有しており、コンパートメントとIAMポリシーの基本操作ができる(Vol1・Vol2相当)
• VCN・サブネット・セキュリティルールの基本構成を理解している(Vol3相当)
• KubernetesのPod・Deployment・Service・ノードといった基礎概念を理解している(EKSなど他クラウドでの経験を含む)
• 手元の端末にOCI CLIとkubectlをインストール済み、またはインストール可能である

このいずれかが未経験の場合でも読み進めることは可能ですが、該当する巻を先に確認しておくと理解がスムーズになります。特にBasic/Enhancedの判断やノードプール設計は、VCNとコンピュートの基礎が頭に入っている前提で解説を進めるため、Vol3までの内容には目を通しておくことをお勧めします。

次の1-3では、こうした読者像を踏まえたうえで、本記事がOCI入門シリーズ全体の中でどのような位置づけにあるかを見ていきます。

1-3. シリーズでの位置づけ — Vol1〜5の集大成としてのOKE

OCI入門シリーズは、Vol1からVol6までの全6巻でOCIの基礎を一巡する構成になっています。

Vol1では、テナンシ・コンパートメント・リージョンといったOCIの土台となる概念と、Always Freeの範囲を扱いました。OCIアカウントを開設し、最初に触れる基本単位を理解する巻です。

Vol2では、IAM Identity Domainsとポリシー、動的グループによるアクセス制御を扱いました。誰が・何に・どこまでアクセスできるかを制御する仕組みであり、本記事のOKEでもクラスターへのアクセス権限設計の土台になります。

Vol3では、VCN・サブネット・ゲートウェイ・セキュリティによるネットワーキングを扱いました。OKEクラスターは必ずVCNの中に作成されるため、Vol3の内容はそのまま本記事のクラスター作成(3章)の前提になります。

Vol4(コンピュート)ではAmpere A1やAMD、Intelといったコンピュート形状の選び方を、Vol5(ストレージ)ではブロックボリューム・オブジェクトストレージ・ファイルストレージの使い分けを扱っています。本記事の随所でVol4・Vol5の内容を前提として参照しますので、詳細はそれぞれの記事をご参照ください。

最終巻である本記事(Vol6)は、これらVol1〜5で積み上げてきた要素を束ねる集大成の位置づけになります。OKEのワーカーノードはVol4で選定したコンピュート形状の上で稼働し、永続ボリュームはVol5で扱うブロックボリュームと連携し、クラスターのネットワーク構成はVol3で構築したVCNの上に成り立ちます。つまりOKEは、単体で完結するサービスではなく、Vol1〜5の学習内容を土台として初めて実践できるサービスです。

本記事を最後まで読み終えたとき、OCIの基礎(アカウント・IAM・ネットワーク・コンピュート・ストレージ)から、その上で動くコンテナオーケストレーションまでを一気通貫で理解した状態になります。これはOCI入門シリーズ全6巻が目指すゴールです。

AWS EKSを実務で使っている方にとって、この一巡の価値は「OCIというもう一つの選択肢を、実務レベルの解像度で評価できるようになる」という点にあります。マルチクラウドの検討やセカンドオピニオンとしてのクラウド選定において、表面的な機能比較ではなく、実際に手を動かした経験に基づく判断ができるようになることを、本シリーズ全体のゴールとしています。

1-4. AWS EKSユーザーの読みどころ

本記事全体を通じて、OKEとAWS EKSの対応関係を随所で明示します。あらかじめ大まかな対応を予告しておくと、後の章の理解がスムーズになります。

とりわけ強調しておきたいのが、OKEにはBasic Clusterという無料階層が存在する点です。EKSにはこうした階層がなく、すべてのクラスターに一律でコントロールプレーン料金が発生します。個人の検証環境や小規模なPoCでコントロールプレーンの費用そのものを避けたい場合、この違いはOKEを選ぶ明確な理由になり得ます。この点は2章で詳しく扱います。

判断根拠として先取りしておくと、Basic Clusterは「無料だが機能とSLAが限定される」、Enhanced Clusterは「課金されるが全機能とSLAが手に入る」というトレードオフです。EKSしか知らない読者にとっては、この「無料か課金か」を自分で選べるという発想自体が新鮮に映るはずです。

もう一つの読みどころは、仮想ノードとFargateの対応です。どちらも「サーバーレスにPodを実行する」という体験を提供しますが、対応するオートスケーラーの範囲や課金の粒度には違いがあります。この違いは4章のノードプール設計で詳しく比較します。

kubeconfigの取得やkubectlでの接続手順そのものは、EKSとOKEで大きな差はありません。Kubernetes標準のツールチェーンを使う以上、両者の操作感は似通っています。違いが出るのは認証まわりの実装であり、この点は5章のハンズオンで実際に手を動かしながら確認します。

ここで一つ注意していただきたい落とし穴があります。上記の対応関係は、あくまで「役割としての近さ」を示すものであり、機能や制約まで完全に一致するわけではありません。たとえば仮想ノードとFargateは、どちらもサーバーレスなPod実行環境という点では似ていますが、対応するオートスケーラーの種類や、利用できるネットワーキングモードには違いがあります。「名前が対応しているから仕様も同じはず」という思い込みは避け、各章で違いの詳細まで確認する読み方を推奨します。

もう一つ、EKS経験者が見落としがちな観点として認証方式があります。EKSではIAM認証情報をベースにしたIAM authenticatorがkubectlの認証を担いますが、OKEではOCI CLIの認証情報をもとにした短命トークンが動的に生成される方式を採ります。仕組みの発想自体は近いものの、認証プラグインの設定箇所やトークンの生成タイミングには差があります。この違いは5章のハンズオンで実際にkubeconfigを取得しながら確認します。

以上を踏まえ、2章からは実際にOKEのアーキテクチャとBasic/Enhancedの違いに踏み込んでいきます。

← Vol5(OCIストレージ入門)を読む

2. OKEの全体像 — マネージドKubernetesとBasic/Enhanced

2-1. OKEとは — マネージドなKubernetesコントロールプレーン

OKE(Container Engine for Kubernetes)は、OracleがKubernetesのコントロールプレーンを完全にマネージドで提供するサービスです。コントロールプレーンはOracle側で複数のアベイラビリティドメイン(AD)にまたがって冗長構成され、可用性の高い運用が図られています。ただし、ADが1つしかないリージョンではこの分散構成の前提が変わります。東京リージョンでの扱いは2-5で改めて取り上げます。

一方、ワーカーノードはユーザー自身のテナンシー内のCompute(仮想マシンまたはベアメタル)上で稼働します。つまりOKEは「コントロールプレーンはOracle任せ、ワーカーはユーザー管理」という役割分担が明確なサービスです。

OKEクラスターは、Vol1で扱ったコンパートメントの中に作成するリソースです。開発・検証・本番といった環境ごとにコンパートメントを分けて運用している場合、OKEクラスターもその区分に沿って配置し、IAMポリシーによるアクセス制御(Vol2)をコンパートメント単位で適用できます。クラスター単体の設計だけでなく、テナンシ全体のリソース区分の中にどう位置づけるかも、実務では初期段階で決めておきたい設計判断です。

この構図はAWS EKSとまったく同じです。EKSもコントロールプレーンをAWSがマネージドで提供し、ワーカーノード(EC2やFargate)はユーザー側のリソースとして扱われます。EKSの経験がある方であれば、OKEのアーキテクチャ全体像は違和感なく理解できるはずです。

判断根拠として押さえておきたいのは、マネージドの範囲がコントロールプレーンに限定されている点です。ワーカーノードのOSパッチ適用やセキュリティ更新、容量計画は引き続きユーザーの責任範囲になります。この責任分界点はEKSと同一であり、Vol4で扱ったCompute運用の知識がそのまま活きます。

ハンズオンの視点から見ると、OKEを使う上で最初に安心できるのは、コントロールプレーンを構成するetcdやAPIサーバーといったコンポーネントを、ユーザー自身が直接運用・監視する必要のない点です。OCIコンソールのクラスター詳細画面では、コントロールプレーンのバージョンや状態を確認できますが、その裏側の冗長構成やアップグレード処理そのものはOracle側の責任範囲であり、ユーザーが個別のノードにSSHでログインして調整するような作業は発生しません。自前でKubernetesを構築・運用した経験がある方ほど、この「見えない部分の運用負荷がない」という点のありがたみを実感しやすいはずです。

落とし穴として意識しておきたいのは、「コントロールプレーンがマネージドだから、クラスター全体の運用もすべて任せられる」という誤解です。実際に運用負荷が発生するのはワーカーノード側であり、OSのセキュリティパッチ適用、コンテナランタイムのバージョン管理、ノードプールの容量計画といった作業は、Basic/Enhancedいずれの階層を選んでも変わらずユーザーの責任範囲に残ります。EKSでEC2ベースのマネージドノードグループを運用した経験がある方であれば、この感覚はそのまま引き継げます。

OKEがマネージドで引き受ける範囲と、ユーザーが引き続き担う範囲を整理すると次のようになります。

• Oracle側が担う範囲: コントロールプレーン(APIサーバー・etcd等)の構築・冗長化・パッチ適用
• Oracle側が担う範囲: コントロールプレーンの可用性監視とゼロダウンタイムでのアップグレード提供
• ユーザー側が担う範囲: ワーカーノードのOS・コンテナランタイムのセキュリティ更新
• ユーザー側が担う範囲: ノードプールの容量計画とオートスケール設定
• ユーザー側が担う範囲: デプロイするアプリケーション自体の設計・運用

この責任分界はEKSの「Shared Responsibility Model」と本質的に同じ考え方です。EKS運用経験のある方であれば、置き換えるべき用語こそ違いますが、責任範囲の線引きそのものに戸惑うことはないはずです。

もう一点押さえておきたいのが、コントロールプレーンを構成するリソース自体は、ユーザーのCompute利用枠を消費しない点です。ワーカーノードとして起動したCompute インスタンスは通常のCompute課金・クォータ管理の対象になりますが、コントロールプレーン部分はOKEというマネージドサービスの枠内で提供され、ユーザー側のテナンシー内リソースとしては見えません。EKSにおいてもコントロールプレーンはAWS管理のリソースとしてユーザーのVPC外に存在する構図であり、この点も共通しています。

OKEを使わずにCompute上へ自前でKubernetesを構築する選択肢と比較すると、判断根拠がより明確になります。

自前構築にはカスタマイズの自由度という利点もありますが、コントロールプレーンの構築・運用ノウハウを持たないチームにとっては、OKEのようなマネージドサービスを使う方が立ち上がりは早く、運用リスクも抑えられます。

EKSしか使ったことがない読者にとって、この判断軸は馴染み深いはずです。EKSが普及した理由の一つも、まさに自前でコントロールプレーンを運用する負荷から解放される点にあったからです。OKEを検討する際も同じ発想で、「コントロールプレーンの運用を任せられる安心感」を評価軸の一つに加えるとよいでしょう。

以上がOKEの基本アーキテクチャです。次の2-2では、OKE最大の特徴であるBasic/Enhancedの選択について詳しく見ていきます。

2-2. Basic vs Enhanced クラスター — 無料階層がある強み

OKEのクラスターには、Basic ClusterとEnhanced Clusterという2つの階層があります。この違いを理解することが、OKEを使いこなす最初の関門であり、AWS EKSに対するOKEの最大の差別化ポイントでもあります。

Basic Clusterは、Kubernetesのコア機能とOKEの基本機能のみを提供する階層です。コントロールプレーンの利用料金は無料で、SLO(Service Level Objective、努力目標としての可用性)は提示されますが、SLA(Service Level Agreement、財務保証を伴う契約)はありません。ノードプールはマネージドノードのみに限定され、仮想ノードや自己管理ノードは利用できません。

Enhanced Clusterは、仮想ノードプール・自己管理ノード・クラスターアドオンの柔軟な管理・ワークロードアイデンティティなど、OKEの全機能を利用できる階層です。コントロールプレーンには財務保証付きのSLA(99.95%)が適用されます。その代わりに、コントロールプレーンの利用料金が発生します。

Enhanced Clusterで追加される主な機能を個別に見ておきます。

• 仮想ノードプール(Virtual Node Pools): サーバーレスなワーカーノードを利用できる(4章で詳説)
• 自己管理ノード(Self-managed Nodes): GPU/HPCなど特殊シェイプに対応したノードを組み込める
• クラスターアドオンの柔軟な管理: CNI/CSIなどのアドオンをOracle管理下で柔軟に構成できる
• ワークロードアイデンティティ: Pod単位でIAM相当の権限を細かく制御できる
• ノード数上限の拡張: Basicと比較してクラスターあたりのノード数上限が高く設定される

これらはいずれも、小規模な検証を超えて本番運用を見据えた際に効いてくる機能群です。

SLAとSLOの違いも整理しておきます。SLOは「これくらいの可用性を目指す」という努力目標であり、未達成であっても契約上の補償はありません。一方、SLAは「この水準を下回った場合に金銭的な補償(サービスクレジット)をする」という契約上の保証です。Basic Clusterでも実運用上の可用性が極端に低いわけではありませんが、契約として財務保証を求める本番システムであれば、Enhanced ClusterのSLA 99.95%が判断の拠り所になります。この「契約としての保証があるかどうか」という観点は、社内の稟議やSLA要件を満たす必要がある場面で特に重要になります。

料金は2026年7月時点でクラスターあたり1時間$0.10、月間上限は$74.40です。★この金額はOracle Cloudのpricingページに基づくものであり、料金改定により変動する可能性があります。実際の契約前には必ずOracle Cloud公式のpricingページで最新の金額を確認してください。

作成時のデフォルトにも注意が必要です。OCIコンソールから作成するとEnhancedがデフォルトで選択されますが、CLIやAPIから作成するとBasicがデフォルトになります(2026年7月時点の挙動です)。「コンソールでうっかり作成したらEnhancedになっていて課金が発生していた」「CLIで自動化したらBasicになっていて仮想ノードが使えなかった」という取り違えは実務でよく起きる落とし穴です。要件を確認したうえで、作成時に明示的に選択することを習慣にしてください。

判断根拠として、要件からどちらを選ぶべきかを整理すると次のようになります。

• 検証環境・学習用途・コスト最優先のPoC → Basic Cluster(コントロールプレーン無料、SLOのみで十分な場面)
• 本番環境で財務保証付きSLAが必要 → Enhanced Cluster(SLA 99.95%が求められる場面)
• 仮想ノードや自己管理ノードを使いたい → Enhanced Cluster一択(Basicでは選択肢自体が存在しない)
• 判断に迷う場合 → 後からBasic→Enhancedへの昇格は可能なので、まずBasicで始めて必要になった時点で昇格する選択肢もある(ただしEnhanced→Basicの降格はできない点に注意)

Basic→Enhancedへの昇格を検討する際の実務上の注意点にも触れておきます。昇格には、対象クラスターがVCN-nativeなPodネットワーキングを採用しているなど、いくつかの前提条件を満たしている必要があります(★昇格の詳細な前提条件はOracle公式ドキュメントで事前に確認してください)。「必要になったら後から昇格すればよい」と気軽に考えず、将来Enhanced機能が必要になる可能性がある場合は、前提条件を満たすネットワーキング構成であらかじめクラスターを作成しておくと、後々のスムーズな移行につながります。

AWS EKSとの対比では、この「無料階層の有無」が最大の違いです。EKSにはBasic/Enhancedのような階層はなく、すべてのクラスターに一律でコントロールプレーン料金(2026年7月時点の標準サポート期間中は$0.10/時間、月間の上限なし)が発生します。個人の検証環境や小規模なPoCでコントロールプレーン費用そのものをゼロにしたい場合、OKEのBasic Clusterは明確な訴求点になります。

簡単な試算で比較してみます。開発・検証・本番の3つのクラスターをEnhancedで常時稼働させた場合、単純計算でコントロールプレーンの費用は月額$74.40×3=$223.20になります。同じ3クラスターをBasicで運用すれば、この費用はゼロです。一方でEKSの場合、3クラスターを標準サポート期間中に一律$0.10/時間で運用すると、1クラスターあたり月間上限がないため、24時間稼働で月額約$73相当(730時間×$0.10)が3クラスター分、階層を問わず発生します。さらにEKSでは、Kubernetesバージョンが標準サポート期間(提供開始から14か月)を過ぎて延長サポートに入ると、コントロールプレーン料金が$0.60/時間へと6倍に跳ね上がる点にも注意が必要です。OKEのBasic/Enhancedという「選べる」構造と比べると、EKSは階層選択の余地がない代わりに料金体系はシンプルという整理になります。

なお、この料金比較はあくまでコントロールプレーンの費用に限った話であり、ワーカーノードとして稼働するComputeインスタンスの費用は、OKE・EKSいずれの場合も別途発生します。「Basic Clusterを選べば運用コストがゼロになる」という誤解をしないよう注意してください。無料になるのはコントロールプレーンの管理料金部分のみで、実際のワークロードを支えるCompute・ストレージ・ネットワークの費用は、選んだノードプールの構成に応じて別途発生します。

2-3. APIエンドポイント — パブリック/プライベート

OKEクラスターのKubernetes APIエンドポイントには、パブリックエンドポイントとプライベートエンドポイントの2種類があります。

パブリックエンドポイントは、パブリックIPとプライベートIPの両方を持ち、インターネット経由で直接kubectlを実行できます。手元のマシンからそのまま接続できる手軽さがある一方、VCNのセキュリティルール設計が重要になります。

プライベートエンドポイントは、プライベートIPのみを持ち、VCN内部やVCNピアリング経由でのみアクセスできます。インターネットへの露出を避けたい本番環境向けの構成です。

選定チェックリストとして整理すると、次のようになります。

• 手早く検証したい・社外からもアクセスしたい → パブリックエンドポイント(セキュリティルールの絞り込みは必須)
• 本番環境でインターネット露出を避けたい → プライベートエンドポイント
• 社内ネットワークやVPN経由のみで運用したい → プライベートエンドポイント + Local Access
• CI/CDパイプラインから直接kubectlを実行したい → パブリックエンドポイント(実行元IPを許可リストに登録)

Custom Createでクラスターを作成する場合、APIエンドポイントには常にプライベートIPが割り当てられます。パブリックサブネットを指定した場合に限り、追加でパブリックIPを持たせるオプションが有効になります。★これは2026年7月時点の挙動です。今後の仕様変更の可能性もあるため、作成前にOracle公式ドキュメントで確認してください。

落とし穴として注意したいのが、パブリックエンドポイントを選択した場合のセキュリティ設計です。APIエンドポイントをインターネットに公開する以上、Vol3で扱ったセキュリティリスト・NSG(ネットワークセキュリティグループ)において、kubectlの通信に必要なポート(APIサーバーへのHTTPS通信)を許可する送信元IPを適切に絞り込む必要があります。「とりあえずパブリックエンドポイントにして、セキュリティルールは後で」という進め方は、意図しないアクセスを許してしまうリスクにつながります。プライベートエンドポイントを選んだ場合は、Cloud ShellやVCNピアリング経由のLocal Access(5章で扱います)が前提になるため、踏み台(バスティオン)構成やVPN接続の要否もあわせて検討することになります。

ハンズオンの観点では、作成済みのクラスターがどちらのエンドポイント構成になっているかは、OCIコンソールのクラスター詳細画面で確認できます。エンドポイントの種別は作成後に変更できない設定も含まれるため、要件を固めてから作成に進むことが重要です。

エンドポイント種別ごとの特徴を表で整理します。

AWS EKSにも同様に、パブリックアクセス・プライベートアクセス・その両方を組み合わせた設定があります。エンドポイントアクセスの考え方自体はOKEとEKSでほぼ共通しており、EKS運用経験があれば設計判断はスムーズに進むはずです。判断根拠としては、社内ネットワークからの運用が中心であればプライベートエンドポイント、CI/CDや複数拠点からの接続が必要であればパブリックエンドポイント(適切なセキュリティルールとの組み合わせ)、という切り分けが基本になります。

ここで混同しやすい点を整理しておきます。ここまで説明してきたAPIエンドポイントは、あくまでkubectlがKubernetes APIサーバーに接続するための経路です。デプロイしたアプリケーションを外部公開する際に使うOCI Load Balancer/NLB(7章で扱います)とは別物であり、両者は用途も設定箇所も異なります。「APIエンドポイントをパブリックにしたから、アプリも自動的に外部公開される」という誤解をしないよう注意してください。

2-4. OKEの構成要素 — クラスター・ノードプール・アドオン

OKEを構成する要素は、クラスター・ノードプール・ワーカーノード・アドオンという階層で整理できます。

クラスターは、コントロールプレーンとその配下にあるノードプール群をまとめる最上位の単位です。1つのクラスターの中に複数のノードプールを持つことができます。

構成要素の階層関係を整理すると、クラスター(1つ)の配下にノードプール(複数)があり、各ノードプールの配下にワーカーノード(複数)がある、という入れ子構造になります。さらにワーカーノードの上でPodが稼働し、アドオンはクラスター全体に横断的に機能を提供する、という位置づけです。EKSにおける「クラスター > ノードグループ > EC2インスタンス > Pod」という階層構造と対応関係にあり、階層の考え方自体はほぼ同一です。

ノードプールは、同じ形状・同じ設定を持つワーカーノードの集合です。用途ごとに複数のノードプールを使い分けるのが一般的な設計です。たとえば、通常ワークロード用のマネージドノードプールと、バッチ処理用の仮想ノードプールを併用するといった構成が考えられます。この使い分けの詳細は4章で扱います。

ワーカーノードは、実際にPodが稼働するCompute上の実体です。ノード形状の選定はVol4で扱ったコンピュートの形状選び(Ampere A1・AMD・Intelなど)がそのまま引き継がれます。本記事では形状そのものの説明は繰り返さず、OKE固有の観点(ノードプールとしての扱い)に絞って解説します。

構成要素とVol1〜5の関係を一覧にすると、次のように整理できます。

アドオンは、Kubernetesクラスターに追加機能を提供するコンポーネント群です。CNI(Container Network Interface)やCSI(Container Storage Interface)ドライバ、Cluster Autoscalerなどがアドオンとして提供され、Enhanced Clusterではこれらのアドオン管理をOracle側に任せる選択肢が広がります。

判断根拠として押さえておきたいのが、Basic ClusterとEnhanced Clusterでアドオンの扱いが異なる点です。Basic Clusterでは、アドオンのインストールやバージョンアップはユーザー自身が手動で行う必要があり、更新のタイミングを見落とすと、CSIドライバやCNIのバージョンがKubernetes本体のバージョンと乖離してしまうリスクがあります。Enhanced Clusterでは、アドオンのライフサイクル管理をOracle側に任せる選択肢が使えるため、運用負荷を下げたい場合はEnhancedを選ぶ理由の一つになります。この違いは、2-2で扱ったBasic/Enhancedの機能差の一部として理解しておくとよいでしょう。

代表的なアドオンの例を挙げておきます。

• CNI(Container Network Interface): Pod間のネットワーキングを担うアドオン
• Block Volume CSI: 永続ボリュームの接続を担うアドオン(7章で詳説)
• Cluster Autoscaler: マネージドノードのオートスケールを担うアドオン(6章で詳説)
• Kubernetes Dashboard/メトリクス関連: クラスターの可視化を担うアドオン群

落とし穴として、Basic ClusterからEnhanced Clusterへ昇格した直後は、アドオンの管理方式がすぐに切り替わるわけではない点に注意してください。既存のアドオンをOracle管理のライフサイクルに乗せ替えるには、別途アドオンの管理方式を切り替える操作が必要になる場合があります。昇格すれば自動的にすべてがマネージド化されると思い込まず、切り替え後の状態を確認する習慣をつけてください。

ノードプールとOCI Computeの関係にも触れておきます。ノードプールを作成すると、その裏側ではVol4で扱うコンピュートのインスタンス構成(インスタンスコンフィグレーション相当の仕組み)に基づいて、指定した形状・台数のワーカーノードがテナンシー内にプロビジョニングされます。ノードプールの設定変更(台数の増減やシェイプの変更)は、Compute側のインスタンス管理の延長として捉えると理解しやすくなります。

ハンズオンの観点では、ノードプールの台数変更は、対象ノードプールの詳細画面から目標ノード数を指定するだけで実行できます。裏側ではCompute側でインスタンスの起動・終了が自動的に行われ、起動したインスタンスは自動的にクラスターへ参加します。EKSのマネージドノードグループにおける「希望キャパシティ」の変更操作と、体験としてはよく似ています。

ネットワークの土台はVol3で構築したVCN、ストレージの土台はVol5で扱うブロックボリュームです。OKEはこれらのVol1〜5の要素をKubernetesという抽象化レイヤーでまとめ上げるサービスという位置づけになります。AWS EKSにおいても、CNI(VPC CNI)やEBS CSIドライバ、Cluster Autoscalerといったアドオンの構成は、EKSアドオンとして管理する仕組みがあり、考え方自体はOKEと共通しています。

2-5. 東京リージョン(ap-tokyo-1)での提供状況

OKEは、東京(ap-tokyo-1)を含むOracle Cloud Infrastructureの全商用リージョンで提供されています。基本的なクラスター作成・ノードプール運用は東京リージョンでも問題なく利用できます。

一方で注意すべき点もあります。東京リージョンは2026年7月時点でアベイラビリティドメイン(AD)が1つのみのリージョンです。2-1で触れたコントロールプレーンの「複数AD分散」という説明は複数ADを持つリージョンを前提としたものであり、東京リージョンではAD分散の恩恵がそのままの形では適用されない可能性があります。★この点はリージョン構成に依存するため、実際の構成はOCIコンソールまたは公式ドキュメントで確認する運用を推奨します。

落とし穴として、この「ADが1つ」という制約は、コントロールプレーンだけでなくワーカーノードの配置設計にも影響します。複数ADを持つリージョンであれば、ノードプールをADをまたいで分散配置することで、AD単位の障害に強い構成を組めます。東京リージョンではADによる分散という選択肢が使えないため、可用性を高めたい場合は、AD内の複数フォールトドメイン(Fault Domain)に分散させる、あるいは複数ADを持つ他リージョンとのマルチリージョン構成を検討するといった代替策が必要になります。AWS EKSでも、単一AZ構成のリージョンでは同様にAZ分散の恩恵が限定される点は共通しており、可用性設計はリージョン特性を踏まえて個別に検討すべき事項です。

また、Kubernetesバージョンの提供状況(2025〜2026年にかけて1.32〜1.35系が主流)や、最新のadd-on・特定のGPU shape・仮想ノードといった個別機能の提供有無については、リージョンによって展開時期に差が生じ得ます。★東京リージョンでの個別機能の可用性は本記事執筆時点で断定できないため、実際にクラスターを作成する際はOCIコンソールまたは公式ドキュメントで対象リージョンでの提供状況を必ず確認してください。

東京リージョンでOKEを使い始める前に確認しておきたい項目を整理します。

• 対象のKubernetesバージョンが東京リージョンで選択可能か(作成画面のバージョン一覧で確認)
• 利用したいノード形状(Ampere A1・AMD・Intel・GPUシェイプ等)が東京リージョンで提供されているか
• 仮想ノードや特定のアドオンなど、最新機能が東京リージョンにすでに展開されているか
• ADが1つである点を踏まえた可用性設計(フォールトドメイン分散やマルチリージョン構成の要否)

ハンズオンの観点では、クラスター作成画面のKubernetesバージョン選択欄で、対象リージョンにおいて実際に選べるバージョンの一覧を確認できます。新機能や特定シェイプの対応有無を事前に把握したい場合は、作成画面のプレビューに加えて、Oracle公式のリリースノートページを確認する習慣をつけておくと、想定外の機能制限に気づかないまま設計を進めてしまう事態を避けられます。

複数リージョンでの展開を検討する企業ユースケースでは、この「リージョン差」の考慮がより重要になります。東京リージョンを主戦場としつつ、複数ADを持つ他リージョンをディザスタリカバリ先として組み合わせる、あるいは最新機能の検証は他リージョンで先行して行い、東京リージョンには安定版として展開するといった運用も選択肢になります。AWS EKSでも、リージョンごとの機能ロールアウト時期の差は同様に存在するため、マルチリージョン運用の考え方自体はEKS経験者にとって馴染みのあるものです。

基礎的なOKE利用については東京リージョンで完結できますが、最新機能を試す際はリージョン差を念頭に置いて確認する習慣を持つとよいでしょう。

ここまでで、OKEの全体像・Basic/Enhancedの選び方・APIエンドポイント・構成要素・東京リージョンでの注意点を押さえました。次の3章では、実際にクラスターを作成するハンズオンに進みます。

3. クラスター作成 — Quick/Custom・エンドポイント・Basic選択

3-1. Quick Create と Custom Create — 自動か明示か

OKEクラスターを作成する際、最初に選ぶのがQuick CreateとCustom Createという2つの作成方式です。この選択が、その後のネットワーク構成や運用の自由度を大きく左右します。

Quick Createは、Kubernetes APIエンドポイント用サブネット・ワーカーノード用サブネット・ロードバランサー用サブネットを、OKE側がすべて自動的に作成してくれる方式です。既存のネットワーク設計を意識せずに数クリックでクラスターを立ち上げられるため、動作確認や学習目的での利用に向いています。

ただしQuick Createには見落としやすい制約があります。自動作成されるロードバランサー用サブネットは常にパブリックサブネットに固定され、この設定は変更できません。APIエンドポイント用サブネットとワーカーノード用サブネットについてはパブリック/プライベートを選択できますが、ロードバランサー側だけは仕様上の固定事項です。

Custom Createは、Vol3で構築したような既存のVCN・サブネットを明示的に指定して作成する方式です。暗号化設定などQuick Createでは選べない項目も細かく制御でき、既存のネットワーク設計にクラスターを統合したい場合や、本番運用を見据えた構成を組みたい場合に適しています。

判断根拠を整理すると、動作確認・学習・使い捨て検証であればQuick Create、Vol3で構築済みのVCNへ統合する場合や本番運用を見据える場合はCustom Create、という切り分けが基本になります。迷った場合は、後から作り直すコストが低い検証段階ではQuick Create、要件が固まった段階でCustom Createへ移行するという進め方も現実的です。

AWS EKSとの対比では、Quick CreateはVPCを含む周辺リソースを自動作成するeksctl create clusterのデフォルト実行に近い関係だといえます。Custom Createは、Terraformや詳細なコンソール操作で既存VPC・サブネットを明示的に指定する構成に相当します。eksctlも–vpc-private-subnetsのようなオプションを指定しない限りVPCを自動作成する挙動があり、Quick Createの「まず自動、必要なら明示」という発想はEKSのエコシステムにも共通しています。

落とし穴として、Quick Createで作成した検証用クラスターを、そのまま本番環境へ転用しようとするケースがあります。ロードバランサー用サブネットがパブリック固定になっている点に後から気づき、ネットワーク設計をやり直す事態につながりかねません。本番運用を見据える場合は、検証段階からCustom Createで着手しておくことをお勧めします。

ハンズオンに入る前の準備として、Custom Createを選ぶ場合はVol3で構築したVCNのOCID・サブネットOCIDを手元に控えておく必要があります。Quick Createであればこうした事前準備は不要ですが、その分、後からネットワーク構成を変更したくなった際の自由度は下がります。どちらの方式を選ぶにせよ、「後からどこまで変更できるか」を作成前に把握しておくと、想定外のやり直しを避けやすくなります。

3-2. Basic/Enhancedとエンドポイントの選択

クラスター作成時には、Basic/Enhancedの選択と、APIエンドポイントのパブリック/プライベート選択も同時に決める必要があります。判断基準そのものは2章で扱ったとおりですが、ここでは作成時特有の注意点を押さえます。

★特に重要な罠として、作成インターフェースによってデフォルトのクラスタータイプが異なります。OCIコンソールから作成すると、明示的に選択しない限りEnhanced Clusterがデフォルトで選ばれます。一方、CLIやAPIから作成した場合は、明示的に指定しない限りBasic Clusterがデフォルトになります(2026年7月時点の挙動であり、Oracle公式のService Change Announcementで示された移行期限までの暫定的な動作です。将来的にデフォルト自体が変更されることもあるため、契約前には必ず最新の公式情報を確認してください)。

この非対称なデフォルトは、実務で典型的な取り違えを生みます。「コンソールでとりあえず作成したらEnhancedになっていて、意図せずコントロールプレーン課金が発生していた」というケースと、逆に「CLIやTerraformで自動化したらBasicになっていて、仮想ノードプールを作ろうとしたらエラーになった」というケースの両方が実務でよく起きます。

この取り違えを防ぐ最も確実な方法は、作成インターフェースのデフォルトに頼らず、Basic/Enhancedのどちらを使うかを毎回明示的に指定することです。コンソールであればクラスタータイプの選択欄を必ず確認し、CLI/APIであれば--type(または対応するAPIパラメータ)を省略せずに指定する運用を徹底してください。

APIエンドポイントについては、2-3で整理したとおりパブリック/プライベートを要件に応じて選びます。Custom Createでは、パブリックサブネットを指定した場合に限りパブリックIPを追加で持たせる選択が可能になり、それ以外は常にプライベートIPが割り当てられます。作成後にエンドポイントの構成を変更できない項目も含まれるため、要件を固めてから作成に進むことが重要です。

EKSとの対比では、EKSにもクラスターエンドポイントのパブリック/プライベートアクセス設定がありますが、コントロールプレーンの課金体系そのものに階層(Basic/Enhanced相当)は存在せず、一律課金です。「無料か課金か」という選択肢自体がOKE特有の判断ポイントであることを、作成時にもあらためて意識しておくとよいでしょう。

IaC(Terraform等)でクラスター作成を自動化する場合も、この罠は同じ形で現れます。クラスタータイプを指定するパラメータを省略したモジュールを使い回していると、CLI/APIのデフォルトであるBasic Clusterが暗黙のうちに作られ続け、あるチームだけ仮想ノードプールが使えないことに何ヶ月も気づかないといった事態が起こり得ます。IaCのコードレビューでは、クラスタータイプのパラメータが明示されているかを確認項目に加えておくことをお勧めします。

3-3. ハンズオン — クラスターを作成する

ここでは、Vol3で構築したVCNを前提に、Custom CreateでBasic Clusterを作成する流れをハンズオン形式で確認します。VCN・サブネットの構築そのものはVol3で扱い済みのため、本記事では再説明しません。

まずOCIコンソールの場合、Developer Services > Kubernetes Clusters (OKE)からクラスターの作成を開始し、Custom Createを選択します。続けてKubernetesバージョン、クラスタータイプ(Basic/Enhanced)、Vol3で構築したVCN、APIエンドポイント用サブネット、パブリック/プライベートの別を順に指定していきます。ワーカーノードは、この時点ではノードプールの設定を後続に回す前提でスキップし、まずクラスター本体(コントロールプレーン)のみを作成する進め方も可能です。

CLIから作成する場合は、次のようなコマンドになります。VCN OCIDやサブネットOCIDは、Vol3で構築した際に控えたものを利用します。

oci ce cluster create \
  --compartment-id <compartment-ocid> \
  --name my-oke-cluster \
  --kubernetes-version v1.32.1 \
  --vcn-id <vcn-ocid> \
  --type BASIC_CLUSTER \
  --service-lb-subnet-ids '["<lb-subnet-ocid>"]' \
  --endpoint-subnet-id <api-endpoint-subnet-ocid> \
  --endpoint-public-ip-enabled false

--typeを明示することで、3-2で触れたデフォルトの罠を回避できます。クラスター作成の場合、OCI上では非同期の作業リクエスト(Work Request)として実行されるため、作成直後はACTIVE状態になっていません。次のコマンドで作業リクエストの完了を待ち受けます。

oci ce cluster get --cluster-id <cluster-ocid> \
  --query "data.\"lifecycle-state\"" --raw-output

ACTIVEが返ってくれば、クラスター本体の作成は完了です。この時点ではまだワーカーノードは存在しないため、4章でノードプールを追加していきます。

前提条件として、クラスター作成にはOKEサービスがユーザーに代わってリソースを操作するためのIAMポリシー(動的グループとポリシーの組み合わせ)が必要です。この設計自体はVol2で扱った内容の延長にあり、本記事では再説明しません。ポリシーが不足していると、クラスター作成の作業リクエストが失敗し、エラーメッセージからは原因を特定しにくいため、作成前にVol2の内容を踏まえてポリシーを確認しておくことをお勧めします。

もう一つの前提条件として、手元の端末に導入するOCI CLIとkubectlのバージョンにも注意が必要です。古すぎるバージョンではkubeconfig取得コマンドのオプションが対応しておらず、5章のハンズオンでつまずく原因になります。クラスターを作成する前に、両ツールを最新化しておくことをお勧めします。

落とし穴として、Custom Createで既存VCNを指定する際、指定したサブネットのセキュリティルール(セキュリティリスト/NSG)がOKEの要求する通信要件を満たしていないと、クラスター作成自体は成功してもノードプールの追加やkubectl接続でつまずくことがあります。Vol3で構築したVCNをそのまま使う場合でも、OKE用に必要なポート開放が済んでいるかを事前に確認しておくと、後続の章でのトラブルを避けられます。

クラスター本体がACTIVEになった時点では、まだPodを1つも実行できません。次の4章でノードプールを追加してワーカーを確保し、5章でkubeconfigを取得してkubectl接続を確認するところまで進めて、はじめてOKEクラスターとして機能し始めます。この順序は、EKSでコントロールプレーンだけを作成した直後の状態(ノードグループ追加前)と同じ感覚で捉えると理解しやすいはずです。

4. ノードプール設計 — 仮想/マネージド/自己管理と形状選択

4-1. 仮想ノード — サーバーレスK8s(EKS Fargate相当)

仮想ノード(Virtual Nodes)は、Kubernetesのノードという概念を意識せずにPodを実行できる、サーバーレスなワーカー実行環境です。Enhanced Clusterでのみ利用でき、Basic Clusterでは選択肢自体が存在しません。

仮想ノードの最大の特徴は、リソースの割り当てと課金がノード単位ではなくPod単位で行われる点です。ユーザーはワーカーノードとなるComputeインスタンスの台数やシェイプを意識する必要がなく、Podに指定したCPU/メモリのリクエスト値に応じて、Oracle側が裏側の実行基盤を自動的に用意します。

★最大Pod数について、OCIの公式ドキュメント内で記述に揺れが見られる点に注意が必要です。一部の概要ページでは500ポッドという記載が見られますが、Basic/Enhancedクラスターの比較ページおよび仮想/マネージドノードの比較ページ(本記事執筆時点で公式に確認済み)では、仮想ノードは1000ポッドまで自動的にスケールすると明記されています。数値に相違を見つけた場合は比較ページの記載を優先し、契約前には必ず最新のOracle公式ドキュメントで確認してください。

オートスケーリングの対応状況にも注意が必要です。仮想ノードはHPA(Horizontal Pod Autoscaler)とVPA(Vertical Pod Autoscaler)には対応していますが、Cluster Autoscalerには対応していません。これは、仮想ノードがそもそも「ノード」という単位を利用者に見せない設計であるためで、ノード数を増減させるという概念自体が存在しないことによります。Pod数を増やしたい場合はHPAで、Podあたりのリソース割り当てを調整したい場合はVPAで対応する、という整理になります。

ネットワークについても制約があり、仮想ノードではVCN-Native Pod Networkingのみがサポートされ、FlannelベースのCNIは利用できません。クラスター作成時にPodネットワーキングの方式を選択する必要があるため、仮想ノードの利用を予定している場合は、この点をあらかじめ踏まえてクラスター設計を進めてください。

ハンズオンの観点では、仮想ノードプールの作成は通常のノードプール作成画面から「仮想」を選択し、配置するAD・サブネット・Podの最大数などを指定する流れになります。マネージドノードのようにComputeシェイプを選ぶ手順は存在せず、これも「ノードを意識しない」という仮想ノードの性質を反映しています。

判断根拠として、仮想ノードが向いているのはバッチジョブや夜間集計処理のように負荷が変動しやすく、かつノード台数の見積もりや容量計画そのものを避けたいワークロードです。逆に、常時一定の負荷が続く定常ワークロードでは、後述するマネージドノードでCluster Autoscalerを使う方が、コストの見通しが立てやすくなります。

落とし穴として、仮想ノードプールに対してCluster Autoscalerの設定を試みてしまうケースがあります。仮想ノードはノード数という概念を持たないため、Cluster Autoscalerの対象にはならず、設定してもエラーにはならないまま何も起きないという分かりにくい挙動になります。仮想ノードでの負荷変動対応は、必ずHPAで設計してください。

AWS EKSとの対比では、仮想ノードはFargateに相当します。どちらも「サーバーレスにPodを実行する」という体験を提供する点は共通していますが、対応するオートスケーラーの範囲(仮想ノード=HPA/VPAのみで、ノード単位のオートスケールという概念自体が存在しない点はFargateも同様です)や、Podネットワーキングの実装(VCN-Native Pod NetworkingとFargateのENIベースネットワーキング)には違いがあります。「Fargateと同じもの」と単純に捉えず、対応関係はあくまで役割としての近さであることを踏まえたうえで、細かな制約は都度公式ドキュメントで確認することをお勧めします。

4-2. マネージドノード — Compute上のワーカー(EKS マネージドノードグループ相当)

マネージドノード(Managed Nodes)は、ユーザーのテナンシー内のComputeインスタンス上でワーカーノードを稼働させる、従来型のノードプールです。Basic Cluster・Enhanced Clusterの両方で利用できる、OKEの基本的なノードプール形態です。

課金は仮想ノードとは異なり、Computeインスタンス単位で発生します。Podがどれだけ稼働しているかにかかわらず、確保したインスタンスの分だけ課金される点は、通常のCompute利用と同じ考え方です。

オートスケーリングは、Cluster Autoscaler・HPA・VPAのすべてに対応しています。負荷変動に応じてノード数自体を増減させたい場合はCluster Autoscalerを、Pod数やリソース割り当てを調整したい場合はHPA/VPAを、それぞれ組み合わせて使うことになります。

利用できるシェイプについては、Vol4で扱ったAmpere A1(VM.Standard.A1.Flex)・AMD(VM.Standard.E4/E5.Flex)・Intel(VM.Standard3.Flex)といった標準的なVM/ベアメタルシェイプに加え、GPUシェイプも利用可能です。「GPUを使うなら自己管理ノードが必須」と思われがちですが、標準的なGPUシェイプはマネージドノードでも利用できます。一方で、Dedicated VM hostシェイプ、Micro VMシェイプ、RDMAネットワーク上のベアメタルHPCシェイプ、burstable系のFlexible shape(VM.Standard.E3.Flexなど)は、マネージドノードでは利用できません。これらが必要な場合は4-3で扱う自己管理ノードの対象になります。

★なお、RDMA対応についてはCompute Clusterを指定したマネージドノードプールという形で、一部のRDMA対応ベアメタルシェイプがマネージドノードでも利用できるようになりつつあります。この領域は機能追加が進んでいる部分でもあるため、RDMA/HPC用途を検討する際は本記事の記述を出発点としつつ、最新の公式ドキュメントで対応シェイプを確認することをお勧めします。

判断根拠として、標準的な常時稼働ワークロードで、ノード単位での細かい制御(特定シェイプの指定、DaemonSetの配置、Basic Clusterでの利用)が必要な場合は、マネージドノードが基本の選択肢になります。

ハンズオンの観点では、ノードプール作成時にシェイプ(Vol4の形状選定をそのまま適用します)、OKEが提供するイメージ(Oracle Linuxベースのワーカーノードイメージ)、ノード数の初期値と、Cluster Autoscalerを使う場合は最小/最大ノード数を指定します。ノードプールは用途ごとに複数作成するのが一般的で、たとえば通常ワークロード用とバッチ処理用でシェイプの異なるノードプールを分けるといった設計がよく行われます。

落とし穴として、複数のノードプールを異なるKubernetesバージョンやイメージで運用したまま放置してしまうケースがあります。ノードプールごとにバージョン・イメージが独立して管理されるため、更新を忘れたノードプールだけが古いバージョンのまま残り、6章で扱うアップグレード時に想定外の差分に気づくことがあります。

AWS EKSとの対比では、マネージドノードはマネージドノードグループに相当します。EC2ベースのワーカーをAWS側のライフサイクル管理に乗せるという発想は共通しており、Cluster Autoscalerの最小/最大/希望数という設定の考え方もほぼ同一です。異なるのは、EKSのマネージドノードグループがEC2 Auto Scaling Groupを内部で利用するのに対し、OKEのマネージドノードプールはOCI Compute側のインスタンスプール相当の仕組みで管理される点で、利用者から見た操作感自体に大きな差はありません。

4-3. 自己管理ノードと形状選択 — Vol4のコンピュート選定を継承

自己管理ノード(Self-managed Nodes)は、Enhanced Clusterでのみ利用できる、最も自由度の高いノードプール形態です。OKEのノードプールAPIを介さず、ユーザー自身がComputeインスタンスを作成し、OKEクラスターへの参加スクリプトを実行して手動で結合します。

自己管理ノードが必要になるのは、主に4-2で触れたマネージドノードの非対応シェイプを使いたい場面です。具体的には、Dedicated VM hostシェイプ、Micro VMシェイプ、RDMAネットワーク上のベアメタルHPCシェイプ、burstable系のFlexible shapeといった構成や、OKEが標準提供するOracle Linuxイメージ以外のカスタムイメージを使いたい場合が該当します。

★繰り返しになりますが、GPUシェイプそのものはマネージドノードでも利用できるため、「GPUワークロード=自己管理ノード」と短絡的に判断しないよう注意してください。自己管理ノードを選ぶべきかどうかは、GPUの有無ではなく、Dedicated host/Micro VM/RDMA上のベアメタルHPC/カスタムイメージといった、マネージドノードの制約に該当するかどうかで判断します。

ノード形状(Ampere A1/AMD/Intel)そのものの選定基準は、Vol4で扱ったコンピュートのシェイプ選びがそのまま引き継がれます。OKE固有の観点として追加で意識すべきは、選んだシェイプ・イメージのComputeインスタンスを、自分でクラスターに結合し、Kubernetesのノードとして認識させる作業そのものです。

判断根拠として整理すると、標準的なワークロードであればマネージドノード、RDMA対応のHPC/AI用途やDedicated host・Micro VM・カスタムイメージが必要な特殊要件の場合にのみ自己管理ノードを検討する、という順序が基本です。自己管理ノードは自由度が高い分、ノードのプロビジョニング・結合・スケーリングをすべて自前で設計する必要があり、運用負荷はマネージドノードより高くなります。

ハンズオンの観点では、自己管理ノードの追加は、通常のノードプール作成フローとは異なり、Computeインスタンスの起動時にOKEクラスターへ参加するクラウドイニシャライズスクリプト(cloud-init)を組み込む形で進めます。マネージドノードのように、ノード数の増減をOKE側のAPIで直接制御できないため、オートスケールが必要な場合は自分でインスタンスプールやスクリプトによる仕組みを用意することになります。

落とし穴として、自己管理ノードはOKE側のノードプールAPIの管理下に入らないため、コンソールのノードプール一覧には表示されず、通常のマネージドノードと同じ感覚で状態を把握しようとすると見落としが生じます。自己管理ノードを採用する場合は、Computeインスタンス側の監視・ライフサイクル管理を別途整備しておく必要があります。

AWS EKSとの対比では、自己管理ノードは、マネージドノードグループが登場する以前にEC2をブートストラップスクリプトで手動結合していた、いわゆるセルフマネージド型のEKSワーカーノードに相当します。あるいは、KarpenterでカスタムNodeClassを使い、EKS標準のマネージドノードグループでは対応できないシェイプ・設定を扱う構成に近い位置づけです。細かい制御と引き換えに運用負荷を引き受けるという点で、両者の性質はよく似ています。

4-4. ノード選定の早見表

3種類のノードを一覧で比較すると、次のようになります。

まず仮想ノードで運用レスに始められるかを検討し、Cluster Autoscalerによるノード単位の制御が必要になった時点でマネージドノードへ、そしてRDMA HPCやDedicated host・カスタムイメージといった特殊要件が生じた場合にのみ自己管理ノードを検討する、という順序で判断すると迷いにくくなります。1つのクラスター内で複数のノードプールを併用し、用途ごとに使い分ける構成も一般的です。

5. アプリデプロイ実践 — kubeconfig取得とkubectl接続

クラスターとノードプールが揃ったところで、いよいよ実際にkubectlで接続し、アプリケーションをデプロイするハンズオンに進みます。

5-1. kubeconfigの取得 — OCI CLIで生成

OKEクラスターにkubectlで接続するには、まずkubeconfigファイルを生成する必要があります。生成にはoci ce cluster create-kubeconfigコマンドを使います。

oci ce cluster create-kubeconfig \
  --cluster-id <cluster-ocid> \
  --file $HOME/.kube/config \
  --region ap-tokyo-1 \
  --token-version 2.0.0 \
  --kube-endpoint PUBLIC_ENDPOINT

判断根拠として押さえておきたいのが、前提バージョンです。--token-versionは2.0.0のみがサポート対象です。このバージョンのkubeconfigは、kubectl 1.11.9以降でないと正しく解釈できません。手元のkubectlが古いままだと、kubeconfigを生成できても接続時に認証エラーとなります。ハンズオンを始める前にkubectlのバージョンを確認しておくことをお勧めします。

--kube-endpointには、2-3で選択したAPIエンドポイントの種別に応じてPUBLIC_ENDPOINTまたはPRIVATE_ENDPOINTを指定します。生成されたkubeconfigの中身は、通常のkubeconfigと異なり、Kubernetes APIサーバーへの認証情報を直接埋め込むのではなく、OCI CLIコマンドを呼び出すexec pluginとして認証プラグインを登録する点が特徴です。この仕組みは5-2で詳しく扱います。

AWS EKSとの対比では、このコマンドはaws eks update-kubeconfigに相当します。どちらも「クラスターのメタデータからkubeconfigを生成し、認証は都度動的に解決する」という設計思想で共通していますが、生成されるkubeconfigの中身(exec pluginの実装)はクラウドごとに異なります。EKSのaws eks update-kubeconfigに慣れている方であれば、コマンドの位置づけそのものに違和感はないはずです。

落とし穴として、複数のOKEクラスターを行き来する場合、kubeconfigの生成先を毎回$HOME/.kube/configに上書き指定すると、既存のコンテキストが上書きされてしまうことがあります。クラスターごとに--fileで別ファイルを指定し、KUBECONFIG環境変数で切り替える運用にしておくと、複数クラスターを扱う際の事故を防げます。

5-2. アクセス方式 — Cloud Shellとローカル接続

kubectlでクラスターに接続する経路は、選択したAPIエンドポイントの種別によって変わります。

パブリックエンドポイントを選んだ場合、最も手早いのはOCI Cloud Shellからの接続です。Cloud Shellはブラウザから利用できるOCI標準のシェル環境で、OCI CLIがあらかじめ認証済みの状態でセットアップされているため、oci ce cluster create-kubeconfigを実行してすぐにkubectlを使い始められます。ローカル端末からの接続も可能ですが、その場合は手元にOCI CLIの認証設定(APIキーの登録)が必要です。

プライベートエンドポイントを選んだ場合、インターネット経由での直接接続はできないため、Local Access(VCN内部からの接続)が前提になります。VCNピアリングや踏み台インスタンス経由でVCN内部にアクセスできる環境を用意し、そこからOCI CLIの認証設定を行ったうえでkubeconfigを生成・利用します。Cloud Shellはインターネット経由の接続となるため、プライベートエンドポイントには利用できません。

認証の仕組みは、パブリック・プライベートいずれの経路でも共通しています。kubeconfigに登録されたexec pluginが、kubectlの実行のたびにOCI CLIを呼び出し、クラスタースコープの短命トークンを動的に生成します。トークンは有効期限が短く、Kubernetes API側もこのトークンを都度検証する仕組みのため、長期間有効な認証情報をローカルに保持し続けるリスクを抑えられます。

AWS EKSでは、IAM認証情報をもとにaws-iam-authenticatorまたはaws eks get-token相当の仕組みでトークンを生成し、kubectl実行時に動的に検証する設計を採ります。「実行のたびに短命トークンを動的生成する」という発想自体はOKEとEKSで共通しており、EKS運用経験があれば認証の全体像はスムーズに理解できるはずです。ただし、認証プラグインの設定箇所(kubeconfig内のexec設定)や、トークンの発行元(OCI CLI vs AWS CLI/IAM authenticator)は当然ながら異なるため、「同じ感覚で動くはず」と過信せず、実際に接続を試して挙動を確認することをお勧めします。

5-3. 接続確認とサンプルアプリのデプロイ

kubeconfigの準備ができたら、まずワーカーノードとの疎通を確認します。

kubectl get nodes

4章で作成したノードプールのワーカーノードがReady状態で一覧表示されれば、接続は成功です。ここでノードが表示されない、またはステータスがNotReadyのままの場合は、3-3で触れたセキュリティルール(APIエンドポイントおよびワーカーサブネットの通信要件)が満たされているかを確認してください。

疎通が確認できたら、サンプルアプリケーションをデプロイします。

kubectl apply -f sample-deployment.yaml

manifestの内容はKubernetes標準のDeploymentとServiceであり、OKE固有の記述は不要です。デプロイ後は次のコマンドでPodの起動状況を確認できます。

kubectl get pods -o wide

AWS EKSとの対比では、ここまでのkubectl get nodesからkubectl apply -fに至る一連の操作は、EKSとまったく同じ標準コマンドです。Kubernetes標準のツールチェーンを使う以上、manifestの書き方やデプロイ操作そのものにOKE固有の違いはありません。EKS経験者にとって、OKEとの差分は5-1・5-2で扱ったkubeconfig生成と認証の部分に集約されると考えて差し支えありません。

落とし穴として、PodがPendingのまま起動しない場合、原因の多くはノードプールのリソース不足(CPU/メモリの割当超過)か、4章で扱ったノード種別とスケジューリング設定(taint/tolerationやnodeSelector)の不整合です。kubectl describe pod <pod-name>でイベントを確認し、原因を切り分ける習慣をつけておくと、本番運用に入ってからのトラブルシューティングにも役立ちます。

6. 運用 — スケーリングとバージョンアップグレード

クラスターを作り込んだあとの運用フェーズでは、負荷変動への対応(スケーリング)と、Kubernetesバージョンの追随(アップグレード)が中心的な作業になります。ここでは、その2つの運用操作を実践的に見ていきます。

6-1. スケーリング — Cluster Autoscalerとオートスケール

マネージドノードプールのオートスケールには、Kubernetes Cluster Autoscalerを利用します。OKEでは、Cluster Autoscalerを「スタンドアロンプログラムとして自分でデプロイする方式」と「クラスターアドオンとしてOracle管理下で動かす方式」の2通りから選べます。

判断根拠として、スタンドアロン方式は設定ファイル(ノードプールごとのmin/max)を自分で管理する分、細かいチューニングの自由度が高い方式です。一方のクラスターアドオン方式は、OKEのコンソール操作でmin/maxを指定するだけで有効化でき、バージョンアップやライフサイクル管理をOracle側に任せられるため、運用負荷を抑えたい場合に向いています。迷った場合は、まずクラスターアドオン方式で始め、細かい制御が必要になった段階でスタンドアロン方式へ切り替える進め方が現実的です。

ここで必ず押さえておきたい落とし穴があります。Cluster Autoscalerは、マネージドノードプールに対してのみ機能し、4章で扱った仮想ノードプールには対応していません。仮想ノードは最大500Podまで自動的にスケールする設計であるうえ、リソースの実体をOracle側が管理しているため、Cluster Autoscalerによる台数調整という概念自体が当てはまらないためです。仮想ノードの負荷変動には、Cluster Autoscalerではなく水平Podオートスケーラー(HPA)で対応します。「仮想ノードを使っていればCluster Autoscalerも自動で効く」という誤解をしないよう注意してください。

AWS EKSとの対比では、マネージドノードグループに対するCluster Autoscalerの位置づけはOKEとほぼ同じです。EKSでは近年Karpenterというノードプロビジョニングツールも広く使われており、Pod単位の要求からノード形状・台数を動的に最適化する発想を持ち込んでいますが、OKEには2026年7月時点でKarpenter相当のネイティブな仕組みは提供されていません。仮想ノードプールが担うサーバーレス寄りの体験(4章参照)が、OKEにおけるKarpenter的な運用負荷軽減の受け皿に近い位置づけと捉えるとよいでしょう。

6-2. コントロールプレーンのアップグレード — ゼロダウンタイム

コントロールプレーンのKubernetesバージョンをアップグレードするには、クラスターの設定でより新しいバージョンを指定します。コントロールプレーンは2-1で触れたとおり複数のアベイラビリティドメインにまたがって冗長構成されているため(東京リージョンのようにADが1つのみのリージョンを除く)、アップグレード中もAPIサーバーへのアクセスが途切れることはなく、ゼロダウンタイムで進行します。

判断根拠として重要な制約が2つあります。第一に、コントロールプレーンのダウングレードはサポートされていません。アップグレード前に、デプロイ済みのマニフェストやカスタムリソースが新バージョンで問題なく動作するかを、検証環境で確認する運用を徹底してください。第二に、コントロールプレーンとワーカーノードのバージョンスキュー(許容される差)には上限があります。Kubernetes 1.28より前のバージョンでは、コントロールプレーンはワーカーノードより最大2マイナーバージョンまで先行できます(n-2)。1.28以降は、この上限が3マイナーバージョンまで(n-3)に緩和されています。

この制約は実務上、「コントロールプレーンだけ先にアップグレードし、ワーカーノードは後回しにする」という進め方が一定期間は許容されることを意味します。ただし許容範囲を超えたまま放置すると、ワーカーノード側でPodのスケジューリングに問題を招くおそれがあるため、コントロールプレーンのアップグレード後は、6-3で扱うワーカーノードのアップグレードも計画的に追随させることが重要です。

AWS EKSにも同様のバージョンスキューポリシーがあり、EKS運用経験があれば「コントロールプレーンを先に上げ、ワーカーを追随させる」という運用の型はそのまま流用できます。コントロールプレーンのアップグレード自体がゼロダウンタイムで提供される点もEKSと共通しており、この点は判断に迷う要素が少ない部分です。

6-3. ワーカーノードのアップグレード — 3つの方式

マネージドノードプールのワーカーノードをアップグレードする方式は、大きく3つに分かれます。

第一に、In-place(node cycling)です。ノードプールの設定により新しいKubernetesバージョンを指定したうえで、既存ノードをcordon・drainしてから入れ替える方式で、さらに「ブートボリュームを置換する(インスタンス自体は維持)」と「ノードそのものを置換する(インスタンスごと入れ替え)」の2通りの挙動を選べます。既存のノードプールをそのまま使い続けたい場合に適した、最も標準的な方式です。

第二に、In-place手動置換です。ノードプールの設定を新バージョンに変更したうえで、既存の各マネージドノードを1台ずつ手動で削除し、新しいノードに置き換えていきます。cordon・drainのタイミングを自分で細かく制御したい場合や、1台ずつ状態を確認しながら慎重に進めたい本番環境で選ばれる方式です。

第三に、Out-of-placeです。既存のノードプールはそのまま残し、新しいKubernetesバージョンを指定した別のノードプールを新規に作成して、段階的にワークロードを移行してから旧プールを削除します。新旧の環境を並行稼働させて検証しながら切り替えたい場合や、ロールバックの選択肢を残しておきたい場合に適した方式です。

仮想ノードプールについては、これら3方式の対象外です。仮想ノードはコントロールプレーンのアップグレードに追随して自動的にアップグレードされるため、ユーザー側で個別に操作する必要はありません。

落とし穴として、コントロールプレーンを1.14以降のバージョンにアップグレードすると、クラスターのkube-dnsサーバーは自動的にCoreDNSサーバーへ置き換えられます。この置き換えは自動で行われる一方、kube-dnsのConfigMapで独自のカスタマイズを加えていた場合、その設定はCoreDNSのConfigMapへは引き継がれません。DNSのカスタム設定をしている場合は、アップグレード後にCoreDNS用のConfigMapを作成し直す必要がある点を事前に把握しておいてください。

AWS EKSとの対比では、ワーカーノードのアップグレード方式が複数用意されている点は共通していますが、EKSのマネージドノードグループは「起動テンプレートのバージョンを更新して段階的に入れ替える」という単一に近い操作体系である一方、OKEは3方式を明示的に使い分ける設計になっています。1台ずつ慎重に進めたいのか、新旧プールを並行稼働させたいのかという運用要件に応じて方式を選べる柔軟性は、OKE側の特徴といえます。

7. ストレージ/LB連携とAWS EKS詳細対比

7-1. 永続ボリューム連携 — Block Volume CSI(Vol5委譲)

OKEでPodに永続ストレージを与える仕組みが、Block Volume CSI(Container Storage Interface)ドライバです。プロビジョナーとしてblockvolume.csi.oraclecloud.comが登録されており、PersistentVolumeClaim(PVC)を作成すると、裏側でVol5のブロックボリュームが動的にプロビジョニングされ、ワーカーノードへアタッチされます。ブロックボリューム自体の性能特性(VPU/GB・パフォーマンスレベルの選び方)はVol5で扱った内容そのものであり、本記事では再説明しません。ここではOKE(Kubernetes)側からどう連携するかに絞って解説します。

デフォルトで用意されているStorageClassは2種類あります。oci-bvは標準的なブロックボリュームを動的プロビジョニングするStorageClassで、volumeBindingMode: WaitForFirstConsumerが設定されています。これは、PVCを作成した時点ではなく、実際にPodがスケジューリングされるタイミングでボリュームを作成する挙動です。Podがどのアベイラビリティドメインに配置されるか確定してからボリュームを同じADに作成できるため、AD跨ぎによるアタッチ失敗を避けられます。もう一つのoci-bv-highは、高パフォーマンス構成(VPU/GBを高く設定したブロックボリューム)を動的プロビジョニングするStorageClassで、I/O性能を求めるワークロード向けに使い分けます。

判断根拠として、標準的なワークロードにはoci-bv、データベースなどI/O性能を要するワークロードにはoci-bv-highを選ぶのが基本方針です。Vol5で扱ったブロックボリュームのパフォーマンスレベル(VPU/GB)の考え方がそのままStorageClassのパラメータに反映されている点を意識すると、選定に迷いません。

ハンズオンとしては、PVCのYAMLでstorageClassName: oci-bvを指定してapplyするだけで、ボリューム作成からアタッチまでがCSIドライバ経由で自動的に進みます。手動でブロックボリュームを作成してからPVに紐づける静的プロビジョニングも可能ですが、通常は動的プロビジョニングで十分です。

落とし穴として、WaitForFirstConsumerの挙動を理解せずに「PVCを作ったのにボリュームがすぐ見えない」と誤解するケースがあります。これはバインドをPodスケジュール時まで遅延させる意図的な設計であり、故障ではありません。また、ブロックボリュームはアベイラビリティドメインに紐づくリソースであるため、ノードプールが複数ADにまたがっている構成では、PVがどのADに作成されたかによって、以降そのPVを使うPodは同じADのノードにしかスケジューリングできない点にも注意が必要です。

AWS EKSとの対比では、Block Volume CSIはAmazon EBS CSI Driver(ebs.csi.aws.com)に相当します。動的プロビジョニング・StorageClassによるパラメータ制御・WaitForFirstConsumerに相当するボリュームバインディングモードの考え方など、CSI仕様に準拠している点は共通しており、EKSでEBS CSIを使った経験があれば、OKEのBlock Volume CSIもマニフェストの書き方はほぼそのまま応用できます。異なるのは、パフォーマンスレベルの指定方法(EBSのボリュームタイプ・IOPS指定 vs OCIのVPU/GB指定)という具体的なパラメータ体系です。

アタッチメントタイプにも触れておきます。ブロックボリュームをワーカーノードへ接続する方式には、iSCSIとパラバーチャライズドの2種類があります。パラバーチャライズド接続は、アタッチ後すぐに利用でき、OS側で追加のコマンド実行を必要としない点が特徴です。一方iSCSI接続は、ベアメタルシェイプのワーカーノードでは唯一選択できる方式であり、後述するマルチアタッチ構成でも必須になります。CSIドライバ経由の動的プロビジョニングでは通常パラバーチャライズドが選ばれるため、Pod利用者の視点でアタッチメントタイプそのものを意識する場面は多くありませんが、ベアメタルノードプールを併用する構成では、この違いを踏まえておくとトラブルシューティングがしやすくなります。

ハンズオンの観点では、稼働中のPVCに対してオンラインでボリュームサイズを拡張できる点も実務上のポイントです。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data
spec:
  storageClassName: oci-bv
  accessModes:
 - ReadWriteOnce
  resources:
 requests:
storage: 100Gi  # 50Giから拡張する場合はこの値を書き換えてapply

spec.resources.requests.storageの値を大きくしてapplyするだけで、Podを止めることなくサイズ拡張が進みます。サイズ拡張に伴いIOPSも比例して引き上がる点は、Vol5で扱ったパフォーマンスレベルの考え方と一致します。★iSCSI接続の場合、拡張後のサイズをノード側で認識させるには、iSCSIターゲットを再スキャンする必要がある点にご注意ください。

落とし穴として、CSIドライバはブロックボリュームのスナップショット機能自体には対応していますが、VolumeSnapshotClassはインストール時にデフォルトでは作成されません。スナップショットやボリュームクローンを使いたい場合は、CSIドライバのインストール後にVolumeSnapshotClassを手動で作成する必要があります。この手順を見落とすと、「CSIドライバはスナップショット対応のはずなのに、VolumeSnapshotを作成してもエラーになる」という分かりにくいつまずきにつながります。

もう一点、複数のPodから同一ボリュームを共有したいという要件にも触れておきます。ブロックボリュームは1つのインスタンスへの排他的なアタッチが基本ですが、OCFS2やGFS2といったクラスター対応ファイルシステムを使う場合、または読み取り専用でよい場合に限り、複数インスタンスへの同時アタッチ(マルチアタッチ)が可能です。ただしマルチアタッチはiSCSI接続が必須であり、通常のパラバーチャライズド接続では利用できません。複数Podから読み書き共有したい(ReadWriteMany)要件がある場合、Block Volume CSI単体で無理に実現しようとせず、Vol5で扱ったファイルストレージ(NFS)ベースのCSIドライバを検討する方が設計としては素直です。

AWS EKSとの対比では、Amazon EBSも同様に単一インスタンスへの排他アタッチが基本であり、複数Podからの読み書き共有(ReadWriteMany)が必要な場合はEFS CSI Driverを使うのがEKSでの定石です。「ブロックストレージは基本的に排他アタッチ、共有したいならファイルストレージ側のCSIを使う」という設計判断の型は、OKE・EKSどちらでも共通しています。

7-2. LoadBalancer連携 — OCI Load Balancer/NLB

KubernetesのServiceリソースでtype: LoadBalancerを指定すると、OKEはOCI Cloud Controller Managerを通じて、対応するOCI Load BalancerまたはNetwork Load Balancer(NLB)を自動的にプロビジョニングします。追加のコントローラーは不要で、Service定義をapplyするだけで外部公開用のロードバランサーが自動的に立ち上がります。

デフォルトでは、OSIレイヤー7に対応するOCI Load Balancerがプロビジョニングされます。パススルー型のレイヤー4(TCP/UDP/ICMP)ロードバランシングを行うNetwork Load Balancerを使いたい場合は、Serviceのannotationにoci.oraclecloud.com/load-balancer-type: "nlb"を指定します。この指定を省略すると、通常のOCI Load Balancerが選ばれる点に注意してください。

そのほか、内部限定(プライベート)のロードバランサーにする指定や、バックエンドセットのヘルスチェック間隔、シェイプ(帯域)の指定など、細かな挙動もannotationで制御します。★annotationのキーと挙動は追加・変更される可能性があるため、最新の一覧はOracle公式ドキュメント(Summary of Annotations)で確認することをお勧めします。

判断根拠としては、シンプルなHTTP/HTTPS公開でレイヤー7の機能が必要な場合はOCI Load Balancer、TCP/UDPを低レイテンシでそのまま通したい場合や送信元IPをそのまま保持したい場合はNLBを選ぶのが基本です。

落とし穴として、annotationを何も指定せずtype=LoadBalancerのServiceを大量に作成すると、Service一つひとつに対して個別のロードバランサーがプロビジョニングされ、想定外のコスト増につながることがあります。複数のServiceを1つのロードバランサーに集約したい場合は、Ingressリソースと組み合わせる設計を検討してください。

AWS EKSとの対比では、この挙動はAWS Load Balancer Controllerが提供するALB/NLBのプロビジョニングに相当します。EKSではAWS Load Balancer Controllerを別途クラスターへインストールする必要がありますが、OKEではOCI Cloud Controller ManagerがOKEクラスターに標準で組み込まれているため、追加のコントローラーインストールなしでLoadBalancer型Serviceがすぐに機能します。annotationでロードバランサーの種別や挙動を制御するという設計思想自体は、EKSのservice.beta.kubernetes.io/aws-load-balancer-typeなどのannotationと共通しており、EKS経験者であれば違和感なく移行できるはずです。

サンプルのService定義は次のようになります。

apiVersion: v1
kind: Service
metadata:
  name: sample-app
  annotations:
 oci.oraclecloud.com/load-balancer-type: "nlb"
spec:
  type: LoadBalancer
  selector:
 app: sample-app
  ports:
 - port: 80
targetPort: 8080

先述のとおり、type: LoadBalancerのServiceを個別に増やしていくと、そのたびにロードバランサーが1つずつプロビジョニングされコスト増につながります。この課題への対応として、OKEにはOCI Native Ingress Controllerというアドオンも用意されています。Ingressリソースの内容に基づいて単一のOCI Load Balancerを複数のServiceで共有し、パスベース・ホストベースのルーティングを行える仕組みです。導入方式はスタンドアロン(Kubernetes 1.26以降で利用可)とクラスターアドオン(Kubernetes 1.28以降で利用可)の2通りがあり、Enhanced Clusterでのアドオン管理機能(2-4参照)と組み合わせて運用するとライフサイクル管理の負荷を抑えられます。

判断根拠として、Serviceが少数であればtype=LoadBalancerを個別に使う構成でも十分ですが、公開するアプリケーションが増えてロードバランサーのコストや管理対象が膨らんできた段階で、OCI Native Ingress Controllerによる集約を検討するとよいでしょう。

AWS EKSとの対比では、OCI Native Ingress ControllerはAWS Load Balancer ControllerのIngressサポート(ALB Ingress Controller相当の機能)に対応します。「単一のロードバランサーを複数のServiceで共有し、パス/ホストベースでルーティングする」という設計思想はEKS・OKEで共通しており、EKSでALB Ingressを使った経験があれば、OCI Native Ingress Controllerへの移行判断もスムーズに進むはずです。

7-3. AWS EKSとの総合対比 — 移行者向けの早見

ここまでの章で個別に触れてきたOKEとAWS EKSの対応関係を、最終確認として1つの表にまとめます。★EKS側の数値(課金・SLA等)は本記事執筆時点でAWS公式ドキュメントの最終fetchを行っていないため、実際の判断材料とする際はAWS公式ドキュメントで最新の値を必ず確認することを推奨します。

判断根拠として押さえておきたいのは、機能面での対応関係はおおむね1対1に近い一方、課金体系だけはOKEに「無料か課金かを選べる」という他にはない構造がある点です。EKS運用経験者がOKEを評価する際は、この課金構造の違いが、検証環境のコストや、複数クラスターを持つ組織全体のコントロールプレーン費用に与える影響を具体的に試算しておくと、実務での意思決定がスムーズになります。

落とし穴として、対応表はあくまで役割としての近さを示すものであり、細部の制約(最大Pod数、対応するネットワーキングモード、認証プラグインの設定方法など)まで完全に一致するわけではない点を、これまでの章で繰り返し確認してきました。表だけを見て「同じものだ」と判断せず、実際に触れる際は各章で扱った差異を思い出しながら検証することをお勧めします。

8. まとめ — OCI入門シリーズ全6巻の完結

8-1. この記事の振り返り

本記事では、OCIのマネージドKubernetesサービスであるOKEを、クラスター作成から運用まで一気通貫で扱いました。2章では、OKE最大の特徴であるBasic/Enhancedクラスターの選び方を、コントロールプレーン課金の有無・SLAの有無・利用できる機能という3つの軸で整理しました。3章では、Quick CreateとCustom Createという2つの作成方式と、--typeを明示してデフォルトの罠を避ける実践を確認しました。

4章では、仮想ノード・マネージドノード・自己管理ノードという3種類のワーカーノードの使い分けを、Vol4で扱ったコンピュート形状の知識と結びつけながら整理しました。5章では、kubeconfigの取得からkubectlでの接続、サンプルアプリのデプロイまでのハンズオンを実践し、6章では、Cluster Autoscalerによるスケーリングと、コントロールプレーン・ワーカーノードそれぞれのアップグレード手順を確認しました。

そして7章では、Block Volume CSIによる永続ボリューム連携(アタッチメントタイプ・オンライン拡張・マルチアタッチの制約を含む)とOCI Load Balancer/NLB・OCI Native Ingress Controllerによる外部公開を、Vol5のストレージ知識と結びつけながら扱い、最後にAWS EKSとの総合対比で全体を締めくくりました。

一貫して意識してきたのは、単なる機能一覧の紹介ではなく、①なぜその選択をするのかという判断根拠、②実際に手を動かすハンズオン、③実務で陥りやすい落とし穴、④AWS EKSとの詳細対比という4つの観点です。とりわけBasic/Enhancedの選択、ノード種別の使い分け、ストレージ・ネットワークの連携といった各所で、EKS経験者が抱きやすい疑問に先回りして答える構成を意識しました。EKSでの経験を土台にしながら、OKE固有の設計判断ができるようになることが、本記事を通じて目指した到達点です。

8-2. OCI入門シリーズを終えて — 次の一歩

本記事をもって、OCI入門シリーズは全6巻で一巡します。Vol1のテナンシ・コンパートメント・リージョンという土台から始まり、Vol2のIAMによるアクセス制御、Vol3のVCNによるネットワーキング、Vol4のコンピュート形状選び、Vol5のストレージ使い分け、そして本記事Vol6のOKEによるコンテナオーケストレーションまで、OCIを実務で使ううえでの基礎を一通り積み上げてきました。

この一巡を通じて得られるのは、個々のサービスの操作方法だけではありません。テナンシの区分・IAMポリシー・VCN設計・コンピュート形状・ストレージ選定という判断の積み重ねが、最終的にOKEクラスターという1つのシステムの上で結実する、という一連の設計思想そのものです。AWS EKSを実務で使ってきた読者にとっては、この一巡を経験することで、OCIを単なる「もう一つのクラウド」としてではなく、実際に手を動かして評価できる選択肢として捉え直せるようになったはずです。

シリーズを読み終えた次のステップとして、いくつかの学習方向が考えられます。1つは、TerraformなどのIaCツールを使ってVol1〜6で扱ったリソースをコード化し、再現可能な形で構築する方向です。もう1つは、OKEクラスターの可観測性(ログ・メトリクス・トレーシング)を整備し、実運用に耐える監視体制を構築する方向です。さらに、マルチクラウド構成としてOCIとAWSを併用する場合の、ネットワーク接続やアイデンティティ連携の設計を深掘りする方向もあります。

実務での次の一歩として、着手しやすい順に整理しておきます。

• まずBasic Clusterで検証環境を作り、4章のノードプール設計・5章のkubectl接続・7章のストレージ/LB連携を一通り手を動かして体験する
• 本番運用を見据える段階で、Custom Create・Enhanced Cluster・プライベートエンドポイントといった本番向け構成へ切り替える(2章・3章)
• ワーカーノードのシェイプ選定はVol4の内容と、永続ボリュームの性能設計はVol5の内容と、それぞれ本記事の内容と突き合わせて見直す
• IaC化・可観測性整備・マルチクラウド連携といった発展課題は、基礎的な運用に慣れたうえで段階的に取り組む

OCI入門シリーズはここで一区切りとなりますが、OKEクラスターの上でどのようなアプリケーションを実際に運用していくかは、読者それぞれの実務次第です。本シリーズで得た判断軸を土台に、実際の環境でOCIを活用していただければ幸いです。

← Vol5(OCIストレージ入門)を読む
OCI入門シリーズの一覧を見る →