Chuyển đến nội dung chính
ブログコースHL7資格対策ロードマップゲームドメイン私についてMCPNEW
トピック
DevOpsKiến trúc hệ thốngLinuxデータベースプログラミング安全

レッスン5：コンテナランタイムとOCI標準

OCI（Open Container Initiative）、Container Runtime Interface（CRI）。 Docker、containerd、CRI-O。イメージレイヤー、レジストリとイメージライフサイクル。

OCIコンテナランタイムスタック — CRI、containerd、runc

1. OCI — Open Container Initiative

OCIはLinux Foundation傘下のオープン組織で、コンテナのオープンスタンダードを定義しています：

仕様定義実装例
OCI Image Specコンテナイメージの形式（レイヤー、マニフェスト）Dockerイメージ、OCIイメージ
OCI Runtime Specイメージからコンテナを実行する方法（ライフサイクル、ファイルシステム）runc、crun、kata-containers
OCI Distribution Specレジストリからイメージをpush/pullするAPIDockerHub、ECR、GCR

試験のポイント： OCI標準は相互運用性を保証します：Dockerでビルドしたイメージは変更なしでcontainerdやCRI-Oで実行できます。KCNAではクラウドネイティブエコシステムにおけるOCIの役割についてよく出題されます。

2. Container Runtime Interface (CRI)

KubernetesはDockerやcontainerdと直接通信しません。代わりに、kubeletはCRI（Container Runtime Interface）という標準gRPC APIを使用します。

Kubernetes Architecture (Runtime Layer):

  kubelet
     │ CRI (gRPC)
     ├─── containerd ─── runc ─── container
     ├─── CRI-O      ─── runc ─── container
     └─── (Docker)   ─── (deprecated v1.24+)

  OCI Runtime (runc, crun):
  - OCI runtime bundleを読み取り
  - Linuxカーネルを呼び出し（namespaces、cgroups）
  - コンテナプロセスを作成

3. コンテナランタイムの比較

ランタイム種類特徴使用環境
containerdハイレベル（CRI）軽量、安定、CNCF graduatedKubernetes 1.24+のデフォルト
CRI-Oハイレベル（CRI）Kubernetes向けに最適化、軽量OpenShift、Kubernetes
Docker Engineハイレベル（非CRI）K8s 1.24から非推奨（dockershim使用）開発環境
runcローレベル（OCI）OCI参照実装containerd/CRI-Oのバックエンド
gVisor (runsc)ローレベル（サンドボックス）セキュリティサンドボックス、syscallをインターセプトGKEサンドボックス、信頼できないワークロード
Kata Containersローレベル（VMベース）コンテナごとにVM分離マルチテナント、高セキュリティ

試験のポイント： Dockerはv1.24からKubernetesランタイムとして非推奨ですが、Dockerイメージ（OCI互換）はcontainerd/CRI-Oで引き続き実行できます。「Docker非推奨」≠「Dockerイメージ非推奨」。

4. コンテナイメージレイヤー

Layer architecture:
┌──────────────────────────────┐
│  Layer 4: App code (5 MB)    │  ← Writeable (container layer)
├──────────────────────────────┤
│  Layer 3: npm packages       │  ← Read-only
├──────────────────────────────┤
│  Layer 2: Node.js runtime    │  ← Read-only
├──────────────────────────────┤
│  Layer 1: Ubuntu base image  │  ← Read-only (shared across images)
└──────────────────────────────┘

キャッシュの利点: Layer 1-2が同じであれば、Layer 3-4のみダウンロード

5. コンテナレジストリ

レジストリプロバイダー特徴
Docker HubDocker Inc.パブリックデフォルト、プルにレート制限あり
ECR (Elastic Container Registry)AWSプライベート、IAM統合
GCR / Artifact RegistryGCPプライベート、Workload Identity
GHCR (GitHub Container Registry)GitHubパッケージ連携、Actions CI
HarborCNCF（オープンソース）セルフホスト、脆弱性スキャン

6. チートシート

試験の質問回答
OCIが定義する標準は？Image Spec、Runtime Spec、Distribution Spec
K8s 1.24+のデフォルトランタイムは？containerd
CRIとは？Container Runtime Interface — kubeletとランタイム間のgRPC API
DockerのK8sでの非推奨は？v1.24から（dockershim削除）
信頼できないワークロード向けランタイムは？gVisorまたはKata Containers

7. 練習問題

Q1: Kubernetesクラスターがcontainerdをコンテナランタイムとして使用しています。開発者がDocker HubにDockerイメージをプッシュしました。このイメージはクラスターで実行できますか？

  • A) いいえ、Dockerイメージはcontainerdと互換性がない
  • B) はい、DockerイメージはOCI Image Specに準拠しており互換性がある ✓
  • C) クラスターにDocker互換shimをインストールした場合のみ
  • D) いいえ、containerdはCNCFレジストリのイメージのみサポート

解説：DockerイメージはOCI Image Specに準拠しているため、containerdやCRI-Oを含むOCI準拠のランタイムと相互運用可能です。「Docker非推奨」はランタイムを指し、イメージ形式ではありません。

Q2: Container Runtime Interface（CRI）の主な目的は何ですか？

  • A) イメージレイヤー形式を定義する
  • B) kubeletがコンテナランタイムと通信するためのgRPC APIを提供する ✓
  • C) レジストリ間のコンテナイメージ配布を管理する
  • D) クラスターノード間でコンテナをスケジュールする

解説：CRIはkubeletに異なるランタイム（containerd、CRI-O）と実装の詳細を知らずに対話するための安定したAPIを提供します。この分離により、kubeletのコードを変更せずにランタイムを切り替えることができます。

Q3: 高セキュリティのマルチテナントワークロードに対してコンテナごとにVMレベルの分離を提供するコンテナランタイムはどれですか？

  • A) containerd
  • B) CRI-O
  • C) Kata Containers ✓
  • D) runc

解説：Kata Containersは各コンテナを軽量VM内で実行し、標準的なLinux namespaceベースのコンテナよりも強力な分離を提供します。gVisorはsyscallインターセプトによるユーザースペース分離を提供し、これも強力ですがアプローチが異なります。