Container Instances / OKE

解決する課題

• サーバー（コンピュートインスタンス）を用意・パッチ・管理したくない → Container Instances
• バッチ・CI ジョブ・短時間の処理をコンテナで手軽に回したい → 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 側

• クラスタ / ノードプール: コントロールプレーン（マネージド）と、ワーカーノードの集合
• マネージドノード / 仮想ノード: 自分で管理する VM ベースの マネージドノード と、サーバーレスにワーカーを提供する 仮想ノード（Virtual Nodes）
• 拡張クラスタ / 基本クラスタ: SLA・機能が異なる2つのクラスタタイプ
• 動的グループ + インスタンスプリンシパル: コンテナ／ノードに OCI 権限を渡す仕組み（AWS のタスクロール / IRSA 相当）

仕様・制限・クォータ

• Container Instances は追加コストなしで利用でき、課金は割り当てた OCPU・メモリ × 時間のみ（基盤の管理費は不要）
• 1つのコンテナインスタンスに複数コンテナを載せられ、各コンテナに resource share（CPU 割合）を指定可能
• シェイプは Flex が中心で、OCPU とメモリを独立して指定（OCPU は仮想コアではなく物理コア相当）
• OKE はリージョン内の複数 可用性ドメイン / フォルトドメインにノードを分散して冗長化
• OKE のコントロールプレーンはマネージド（拡張クラスタは SLA 付き）。ワーカーはコンピュート / Block Volume のクォータを消費
• テナンシ／リージョンごとに **サービス制限（リミット）**があり、コンソールから引き上げ申請が可能

内部の仕組み

Container Instances は、ユーザーが指定したシェイプ（OCPU/メモリ）に対して OCI 側がサーバーレスにコンピュートを確保し、コンテナを起動します。基盤の VM・ホスト OS・パッチは OCI が管理するため、ユーザーはコンテナ定義（イメージ・環境変数・ポート・ボリューム）だけに集中できます。同一インスタンス内のコンテナはネットワークとエフェメラルストレージを共有します。

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

• マネージドノード: 自分のテナンシ内の コンピュートインスタンスがワーカーになる。ノードのサイズ・OS・スケールを自分で制御でき、コスト最適化や特殊要件に強い
• 仮想ノード（Virtual Nodes）: ワーカーをサーバーレスに提供。Pod 単位の課金で、ノードのキャパシティ管理が不要

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

• 運用を最小化したい単発処理は Container Instances、継続運用・複雑な構成は OKE
• OKE でもサーバー管理を減らすなら仮想ノード、コスト最適化・特殊要件はマネージドノード
• 権限は インスタンスプリンシパル（+ 動的グループ） で最小限に付与し、資格情報をイメージに埋め込まない
• イメージは OCIR に置き、イメージスキャンで脆弱性を検出してからデプロイ
• OKE は 複数フォルトドメインにノードプールを分散し、ロードバランサでローリングデプロイ

運用・監視

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

コスト

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

セキュリティ

• インスタンスプリンシパルを使い、コンテナ／ノードに OCI 権限を渡す（資格情報のハードコードを排除）
• イメージは 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 で作成
oci ce cluster create \
  --compartment-id "ocid1.compartment.oc1..xxxx" \
  --name "demo-oke" \
  --kubernetes-version "v1.30.1" \
  --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"