Container Engine for Kubernetes (OKE)

解決する課題

コンテナを本番で安定運用するには、コンテナの配置・自己修復・スケール・ローリング更新といったオーケストレーションが必要です。Kubernetes はその標準ですが、コントロールプレーン（API サーバー・etcd・スケジューラ）を自前で構築・運用するのは負担が大きく、可用性やバージョン管理も難所になります。OKE はこのコントロールプレーンを Oracle がマネージドで提供することで、その負担を引き受けます。

• Kubernetes のコントロールプレーンを自分で構築・パッチ・冗長化したくない
• マイクロサービスを本番で安定運用したい（落ちたら再起動、負荷で増減、無停止で更新）
• 既存の Kubernetes 資産（マニフェスト / Helm チャート / kubectl 運用） をそのまま OCI に持ち込みたい
• ワーカーのキャパシティ管理すら省きたい（仮想ノードでサーバーレス運用）

主要概念と用語

• クラスタ（Cluster）: OKE の管理単位。マネージドなコントロールプレーンと、ワークロードを動かすワーカーノードの集合で構成される
• コントロールプレーン: API サーバー・etcd・スケジューラなど Kubernetes の頭脳。Oracle が運用し、複数の可用性ドメインに分散して冗長化される
• ノードプール（Node Pool）: 同一構成（シェイプ・イメージ・サイズ）のワーカーノードをまとめて管理する単位。プール単位でスケールやアップグレードを行う
• マネージドノード（Managed Node）: 自分のテナンシ内のコンピュートインスタンスがワーカーになる方式。OS・シェイプ・スケールを自分で制御でき、コスト最適化や特殊要件に強い
• 仮想ノード（Virtual Node）: ワーカーをサーバーレスに提供する方式。ノードのプロビジョニングやパッチが不要で、Pod 単位で課金される
• 基本クラスタ / 拡張クラスタ（Basic / Enhanced Cluster）: 機能と SLA が異なる2つのクラスタタイプ。拡張クラスタは追加機能と財務的に裏付けられた SLA を持つ
• OCIR（Oracle Cloud Infrastructure Registry）: コンテナイメージの格納先レジストリ（AWS の ECR に相当）
• 動的グループ + ワークロード ID: Pod やノードに OCI 権限を渡す仕組み（AWS の IRSA / ノードロールに相当）
• アドオン（Add-on）: CoreDNS や kube-proxy などのクラスタ付帯コンポーネント。拡張クラスタではライフサイクルを OKE が管理する

仕様・制限・クォータ

• 提供される Kubernetes はアップストリーム互換で、kubectl・Helm・標準マニフェストがそのまま使える
• サポートされる Kubernetes バージョンは複数並行で提供され、順次更新・廃止される。最新のサポート状況は公式ドキュメントで確認する（特定バージョンを断定しない）
• 基本クラスタは無料のコントロールプレーン、拡張クラスタはクラスタ管理料が発生し、より多くのノードや追加機能、SLA をサポートする
• ワーカーはマネージドノード（コンピュート / Block Volume のクォータを消費）か仮想ノード（Pod 単位）から選択する
• ノード・Pod・サービスの数や、クラスタあたりの規模には上限がある。クラスタタイプによって扱える規模が異なる
• テナンシ／リージョンごとに**サービス制限（リミット）**があり、コンソールから引き上げ申請が可能
• ワーカーは複数の可用性ドメイン / フォルトドメインに分散配置して冗長化できる

内部の仕組み

OKE のコントロールプレーンは Oracle が運用し、リージョン内で冗長化されています。ユーザーはコントロールプレーンの構築・パッチ・etcd のバックアップを意識せず、ワークロードとワーカーの設計に集中できます。ワーカー方式は2つあります。

• マネージドノード: 自分のテナンシ内のコンピュートインスタンスがワーカーになる。ノードのシェイプ・OS イメージ・スケール戦略を自分で制御でき、GPU やベアメタルなど特殊シェイプも選べる。OS パッチやノードのアップグレードはユーザー側の管理範囲に含まれる
• 仮想ノード: ワーカーをサーバーレスに提供する。ノードのキャパシティ管理・パッチが不要で、Pod 単位で課金される。運用負荷を最小化したい場合に向く

ネットワークは VCN 上に構築され、ワーカーや Pod はサブネットに配置されます。Pod 間通信には CNI が使われ、用途に応じてフランネル系か VCN ネイティブ Pod ネットワーキング（Pod に VCN の IP を直接割り当てる方式）を選べます。外部公開には OCI のロードバランサと連携し、Kubernetes の Service / Ingress からプロビジョニングできます。

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

• ノードプールを複数の可用性ドメイン / フォルトドメインに分散し、単一障害点を避ける
• 役割の異なるワークロードはノードプールを分ける（汎用・GPU・スポット相当など）。taint / toleration と nodeSelector で配置を制御する
• Cluster Autoscaler でノード数を、Horizontal Pod Autoscaler で Pod 数を自動調整し、負荷追従とコスト最適化を両立する
• 無停止更新のため Deployment のローリング更新と Readiness/Liveness プローブを必ず設定する
• 権限は OKE ワークロード ID（Pod 単位の OCI 認証）で最小限に付与し、資格情報をイメージに埋め込まない
• イメージは OCIR に置き、イメージスキャンで脆弱性を検出してからデプロイする
• 本番は SLA を持つ拡張クラスタを基本とし、検証や小規模は基本クラスタで足りる場合がある

運用・監視

• メトリクスは OCI Monitoring、コンテナの標準出力やノードのログは OCI Logging で収集する
• 日常操作は kubectl。kubeconfig は OCI CLI で取得し、トークンベースで認証する
• ノードやクラスタのアップグレードは、コントロールプレーンを先に上げてからノードプールを更新するのが基本。マネージドノードは入れ替え（cordon / drain）を伴う
• Pod が起動しない → イメージ取得権限（OCIR / ポリシー）、シェイプ（OCPU・メモリ）、サブネット容量や IP 枯渇、セキュリティリスト / NSG を確認する
• 外部公開がつながらない → Service / Ingress とロードバランサのヘルスチェック、サブネットとセキュリティルールを確認する
• 監視・ログ・アラームを Connector Hub などと組み合わせ、可観測性とアラート通知を整える

コスト

課金はおおむねクラスタタイプとワーカー方式で決まります。基本クラスタはコントロールプレーンが無料、拡張クラスタはクラスタ管理料が加わります。ワーカーはマネージドノードならコンピュートと Block Volume の費用、仮想ノードなら Pod 単位の費用が発生します。変動する単価は断定せず、最新の料金は公式情報で確認してください。

セキュリティ

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

Well-Architected の観点

• 信頼性（reliability）: コントロールプレーンはマネージドで冗長化され、ワーカーを複数の可用性ドメイン / フォルトドメインに分散できる。自己修復・ローリング更新・オートスケールで継続稼働を支える
• 運用上の優秀性（operational excellence）: アップストリーム互換なので既存の kubectl / Helm 運用やマニフェストがそのまま使える。仮想ノードを選べばワーカーのパッチ・キャパシティ管理まで省ける
• パフォーマンス効率（performance efficiency）: ワークロードごとにノードプールやシェイプ（GPU・ベアメタル含む）を最適化し、HPA / Cluster Autoscaler で負荷に追従できる。VCN ネイティブ Pod ネットワーキングでネットワーク性能も確保できる

試験で問われるポイント

関連サービス・比較

OKE は AWS の EKS にあたるマネージド Kubernetes です。周辺サービスとあわせて対応関係を押さえておくと理解が進みます。

ハンズオン / CLI例

# OKE: マネージドノードプール付きのクラスタを作成（バージョンは環境に合わせる）
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"

# 作成したクラスタを一覧して OCID と状態を確認
oci ce cluster list \
  --compartment-id "ocid1.compartment.oc1..xxxx" \
  --query "data[].{Name:name, State:\"lifecycle-state\", Version:\"kubernetes-version\"}" \
  --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