OKE Virtual Nodes

解決する課題

OKE のワーカーをマネージドノードで運用すると、ノードのシェイプ選定・OS パッチ・キャパシティ計画・オートスケールの調整といった「ノードの面倒」が残ります。仮想ノード（Virtual Nodes）は、このワーカー層をサーバーレスに提供することで、その負担そのものを取り除きます。利用者は Pod の定義に集中でき、その下のノードは Oracle が管理します。

• ワーカーノードのプロビジョニング・OS パッチ・サイズ計画を自分でやりたくない
• 負荷が読みにくく、ノードの余剰を抱えたくない（使った Pod の分だけ払いたい）
• Kubernetes の枠組みは維持したまま、運用をできるだけ薄くしたい
• 既存の kubectl 運用やマニフェスト・Helm チャートをそのまま使い続けたい

主要概念と用語

• 仮想ノード（Virtual Node）: ワーカーをサーバーレスに提供する論理的なノード。実体のコンピュートインスタンスを利用者が管理せず、Pod の実行基盤を Oracle が担う方式
• 仮想ノードプール（Virtual Node Pool）: 仮想ノードをまとめて管理する単位。配置するサブネットや可用性ドメイン、Pod の配置ポリシーなどをプール単位で設定する
• マネージドノード（Managed Node）: 対になるもう一つのワーカー方式。自分のテナンシ内のコンピュートインスタンスがワーカーになり、シェイプや OS を自分で制御する
• 拡張クラスタ（Enhanced Cluster）: 仮想ノードを使う前提となるクラスタタイプ。追加機能と SLA を持つ。基本クラスタでは仮想ノードは利用できない
• VCN ネイティブ Pod ネットワーキング: Pod に VCN の IP を直接割り当てるネットワーキング方式。仮想ノードはこの方式を前提とする
• OKE ワークロード ID（Workload Identity）: Pod 単位で OCI の権限を渡す仕組み。仮想ノードでは資格情報の付与にこれを用いる（AWS の IRSA に相当）
• Pod 単位課金: ノードの台数ではなく、Pod が要求した vCPU・メモリのリソース量に応じて課金される考え方

仕様・制限・クォータ

• 仮想ノードは拡張クラスタ（Enhanced Cluster）でのみ利用できる。基本クラスタでは選べない
• ネットワーキングは VCN ネイティブ Pod ネットワーキングが前提で、Pod は VCN のサブネットに IP を持つ
• 提供される Kubernetes はアップストリーム互換で、kubectl・Helm・標準マニフェストがそのまま使える
• ノードを利用者が管理しない方式のため、ノードへの直接アクセス（SSH やデーモンセット的な使い方）や、ノード固有のシェイプ指定に依存するワークロードには制約がある
• GPU やベアメタルなどの特殊シェイプ、ホストレベルの細かな制御が必要な用途はマネージドノードを選ぶ
• Pod が要求するリソース（vCPU・メモリ）は requests に基づいて確保・課金される設計のため、requests を適切に設定することが重要
• テナンシ／リージョンごとに**サービス制限（リミット）**があり、扱える規模はクラスタタイプや上限に依存する。最新の制限値はコンソールの利用状況で確認する（具体的な数値を断定しない）
• 仮想ノードとマネージドノードは同一クラスタ内で併用でき、ワークロードごとに使い分けられる

内部の仕組み

仮想ノードでは、ワーカーノードの実体を Oracle 側で管理します。利用者から見ると Kubernetes 上に通常どおりノードが現れますが、その下のキャパシティ確保・OS パッチ・基盤の冗長化はマネージドサービスとして提供されます。Pod をデプロイすると、必要なリソースが Pod 単位で割り当てられ、ノードの台数や空き容量を利用者が計画する必要はありません。

ネットワークは VCN ネイティブ Pod ネットワーキングで構成され、各 Pod は VCN のサブネットから IP を受け取ります。これにより Pod は VCN 上のリソースやセキュリティリスト・NSG の制御対象として扱われ、ロードバランサや他サービスとの連携も VCN ネットワーキングの枠組みで行えます。Pod への OCI 権限付与は OKE ワークロード ID を用い、資格情報を埋め込まずに最小権限で OCI を呼び出せます。

設計パターン / ベストプラクティス

• Pod の requests / limits を正確に設定する。仮想ノードは requests に基づいて確保・課金されるため、過大設定はコスト増、過小設定は不安定さにつながる
• ノード管理が不要なステートレスなマイクロサービスを仮想ノードに寄せ、特殊要件のものはマネージドノードに分離する
• スケールは Horizontal Pod Autoscaler（HPA） を中心に設計する。ノードの台数計画が不要なので Pod レベルの自動調整に集中できる
• 可用性のため、仮想ノードプールを複数の可用性ドメインにまたがるサブネットへ配置し、Pod を分散させる
• 権限は OKE ワークロード ID で Pod 単位に最小限付与し、資格情報をイメージやマニフェストに埋め込まない
• ノード固有の前提（特権 DaemonSet・ホストパス依存・SSH 運用）を持つワークロードは仮想ノードに載せず、設計段階で切り分ける

運用・監視

• メトリクスは OCI Monitoring、コンテナの標準出力は OCI Logging で収集する。日常操作は通常どおり kubectl で行う
• kubeconfig は OCI CLI で取得し、トークンベースで認証する。マネージドノードのクラスタと操作手順は変わらない
• ノードの OS パッチやアップグレードはマネージドサービス側で扱われるため、ノード入れ替え（cordon / drain）の運用は基本的に不要
• Pod が起動しない → イメージ取得権限（OCIR / ポリシー）、requests と利用可能リソース、サブネットの IP 容量や枯渇、セキュリティリスト / NSG を確認する
• 外部公開がつながらない → Service / Ingress とロードバランサのヘルスチェック、Pod が属するサブネットとセキュリティルールを確認する

コスト

仮想ノードの課金は**ノードの台数ではなく、Pod が要求した vCPU・メモリのリソース量（Pod 単位）**で決まります。アイドルなノードの余剰を抱えにくく、負荷の変動が大きい・読みにくいワークロードでコスト効率を出しやすいのが特徴です。一方で requests を過大に設定すると、その分が確保・課金されるため無駄が生じます。変動する単価は断定せず、最新の料金は公式情報で確認してください。

セキュリティ

• Pod の OCI 認証は OKE ワークロード ID を使い、資格情報のハードコードを排除する（AWS の IRSA に相当）
• 操作権限は Kubernetes の RBAC と OCI の IAM ポリシーを組み合わせて制御する
• Pod は VCN ネイティブ Pod ネットワーキングで VCN 上に配置されるため、NSG / セキュリティリストで通信範囲を最小化する
• イメージは OCIR に格納し、脆弱性スキャンを有効化してからデプロイする
• シークレットは OCI Vault で管理し、Kubernetes Secret や環境変数経由で安全に注入する
• API サーバーへのアクセスはプライベートエンドポイント化や許可 CIDR で絞り、不要な公開を避ける

関連サービス・比較

仮想ノードは、同じ OKE のワーカー方式であるマネージドノードと対になります。どちらを選んでも Kubernetes の枠組みは同じで、同一クラスタ内で併用もできます。

ハンズオン / CLI例

# 仮想ノードプールを作成（拡張クラスタが前提。サブネットや AD は環境に合わせる）
oci ce virtual-node-pool create \
  --compartment-id "ocid1.compartment.oc1..xxxx" \
  --cluster-id "ocid1.cluster.oc1.phx.xxxx" \
  --display-name "demo-vnp" \
  --placement-configurations '[{"availabilityDomain":"Uocm:PHX-AD-1","subnetId":"ocid1.subnet.oc1.phx.xxxx"}]' \
  --pod-configuration '{"subnetId":"ocid1.subnet.oc1.phx.xxxx","shape":"Pod.Standard.E4.Flex"}'

# 仮想ノードプールを一覧して OCID と状態を確認
oci ce virtual-node-pool list \
  --compartment-id "ocid1.compartment.oc1..xxxx" \
  --cluster-id "ocid1.cluster.oc1.phx.xxxx" \
  --query "data.items[].{Name:\"display-name\", State:\"lifecycle-state\"}" \
  --output table

# kubeconfig を取得して kubectl を使えるようにする
oci ce cluster create-kubeconfig \
  --cluster-id "ocid1.cluster.oc1.phx.xxxx" \
  --file "$HOME/.kube/config" \
  --region "us-phoenix-1" \
  --token-version "2.0.0"

# 仮想ノード上に Pod が立つことを確認
kubectl get nodes
kubectl get pods --all-namespaces