Container Instances / OKE

解決する課題

• サーバー（コンピュートインスタンス）を用意・パッチ・管理したくない → Container Instances
• API、Web、バッチ、CI ジョブをKubernetesなしで直接動かしたい → Container Instances
• マイクロサービスを本番で安定運用したい（落ちたら再起動、負荷で増減、ローリング更新） → OKE
• 既存の Kubernetes 資産（マニフェスト / Helm） をそのまま持ち込みたい → OKE

主要概念と用語

Container Instances 側

• コンテナインスタンス: 1つ以上のコンテナを束ねた実行単位。同一インスタンス内のコンテナは localhost で通信し、ストレージを共有できる（Kubernetes の Pod に近い概念）
• シェイプ: 割り当てる OCPU とメモリの組み合わせ。CI.Standard.E3.Flex / CI.Standard.E4.Flex などフレキシブルシェイプで OCPU・メモリを細かく指定
• 再起動ポリシー: ALWAYS / NEVER / ON_FAILURE でコンテナ終了時の挙動を制御
• コンテナレジストリ（OCIR）: イメージの取得元。Oracle Cloud Infrastructure Registry

OKE 側

• クラスタ / ノードプール: コントロールプレーン（マネージド）と、ワーカーノードの集合
• マネージド / 仮想 / 自己管理ノード: OKEが作成するComputeベースのマネージドノード、Oracle管理の仮想ノード、自分でComputeを作成して参加させる自己管理ノード
• 拡張クラスタ / 基本クラスタ: SLA・機能が異なる2つのクラスタタイプ
• リソースプリンシパル / ワークロードアイデンティティ: Container InstancesやOKEのPodへ、固定APIキーなしでOCI権限を渡す仕組み

仕様・制限・クォータ

• Container Instances は追加コストなしで利用でき、課金は割り当てた OCPU・メモリ × 時間のみ（基盤の管理費は不要）
• 1つのコンテナインスタンスに最大60コンテナを載せられ、各コンテナにCPU・メモリ上限を指定可能
• シェイプは Flex が中心で、OCPU とメモリを指定。x86の1 OCPUは2論理CPU、Armは世代により換算が異なる
• 既定の共有エフェメラル領域は 15GB。イメージ展開、書込みレイヤー、ログ、emptyDir が消費し、停止・再起動・削除で内容を失う
• OKE はノードプールを複数 可用性ドメイン / フォルトドメインへ分散可能
• OKE のコントロールプレーンはマネージド（拡張クラスタは SLA 付き）。ワーカーはコンピュート / Block Volume のクォータを消費
• 仮想ノードと自己管理ノードは拡張クラスタのみ。マネージドノードは基本クラスタと拡張クラスタの両方で利用可能
• テナンシ／リージョンごとに サービス制限（リミット）があり、コンソールから引き上げ申請が可能

内部の仕組み

Container Instances は、ユーザーが指定したシェイプに対して OCI 側がサーバーレスにコンピュートを確保し、1つ以上のコンテナを起動します。基盤の VM・ホスト OS・パッチは OCI が管理します。同一インスタンス内のコンテナはVNIC、IPアドレス、localhost、emptyDirを共有できますが、Replica管理、サービス発見、ローリング更新はKubernetesのように自動化されません。

OKE はアップストリーム互換の Kubernetes を提供します。コントロールプレーン（API サーバー・etcd・スケジューラ）は Oracle がマネージドで運用し、ワーカーは2方式から選べます。

• マネージドノード: 自分のテナンシ内の コンピュートインスタンスがワーカーになる。ノードのサイズ・OS・スケールを自分で制御でき、コスト最適化や特殊要件に強い
• 仮想ノード（Virtual Nodes）: Oracleがワーカーを管理し、Pod単位でCPU・メモリを割り当てる。拡張クラスタ専用
• 自己管理ノード: 自分で作成したComputeインスタンスを拡張クラスタへ参加させる。特殊なOS、GPU、高性能ネットワークなどを細かく管理

横にスクロール

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

• 運用を最小化したい単発処理は Container Instances、継続運用・複雑な構成は OKE
• OKE でもサーバー管理を減らすなら仮想ノード、コスト最適化・特殊要件はマネージドノード
• Container Instancesは動的グループに含めてリソースプリンシパルで権限を付与し、OKEのPodは可能ならワークロードアイデンティティを使う
• イメージは OCIR に置き、イメージスキャンで脆弱性を検出してからデプロイ
• OKE は 複数フォルトドメインにノードプールを分散し、ロードバランサでローリングデプロイ

運用・監視

• OCI Monitoring でメトリクス、OCI Logging でコンテナの標準出力／ログを収集
• OKE は Kubernetes Dashboard / kubectl に加え、Monitoring・Logging と統合して可観測性を確保
• コンテナが起動しない → イメージ取得権限（OCIR / 動的グループ）、シェイプ（OCPU・メモリ）、サブネット／セキュリティリストを確認
• デプロイ失敗 → ヘルスチェック（Readiness/Liveness）とコンテナの起動可否、再起動ポリシーを確認

コスト

Container Instances は管理費ゼロで割り当てリソースのみ課金、OKE はクラスタタイプとワーカー方式で課金が変わります。

セキュリティ

• Container Instancesはリソースプリンシパル、OKEのPodはワークロードアイデンティティを使い、資格情報のハードコードを避ける
• イメージは OCIR に置き、脆弱性スキャンを有効化。プライベートサブネット + セキュリティリスト／NSG で公開範囲を最小化
• シークレットは OCI Vault で管理し、環境変数や Kubernetes Secret 経由で安全に注入
• OKE は RBAC と IAM ポリシーを組み合わせて操作権限を制御

関連サービス・比較（AWS との対応）

ハンズオン / CLI例

# Container Instances: 単一コンテナのインスタンスを作成
# （nginx イメージを E4.Flex シェイプで 1 OCPU / 4GB 起動）
oci container-instances container-instance create \
  --compartment-id "ocid1.compartment.oc1..xxxx" \
  --availability-domain "Uocm:PHX-AD-1" \
  --shape "CI.Standard.E4.Flex" \
  --shape-config '{"ocpus": 1, "memoryInGBs": 4}' \
  --containers '[{"displayName":"web","imageUrl":"phx.ocir.io/mytenancy/web:1.0"}]' \
  --vnics '[{"subnetId":"ocid1.subnet.oc1.phx.xxxx"}]' \
  --display-name "web-ci"

# 作成したコンテナインスタンスを一覧
oci container-instances container-instance list \
  --compartment-id "ocid1.compartment.oc1..xxxx" \
  --query "data.items[].{Name:\"display-name\", State:\"lifecycle-state\"}" \
  --output table

# OKE: マネージドノードプール付きのクラスタを quick-create で作成
# --kubernetes-version は OKE がサポートする最新版を指定（oci ce cluster-options get で確認）
oci ce cluster create \
  --compartment-id "ocid1.compartment.oc1..xxxx" \
  --name "demo-oke" \
  --kubernetes-version "vX.Y.Z" \
  --vcn-id "ocid1.vcn.oc1.phx.xxxx"

# OKE: 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"