コンテナイメージキャッシュサーバの本番導入｜障害時フォールバックと切り戻し設計

コンテナイメージキャッシュサーバが本番環境で必要になる背景

Kubernetes クラスタが大規模になるほど、外部レジストリへのイメージ Pull が運用上のボトルネックになりやすくなります。Docker Hub が 2020 年代前半から段階的に強化してきた Pull Rate Limit は、2026 年現在もフリープランで IP アドレスごとに厳格な上限が設けられており、CI/CD パイプラインとプロダクション環境が同一 NAT 出口を共有している構成では、営業時間帯に 429 Too Many Requests が頻発するケースが現場で報告されています。

また、パブリッククラウドのリージョン間通信コストやデータセンターのインターネット帯域を節約する観点からも、社内 LAN 内にイメージキャッシュサーバを配置することは費用対効果が高いとされています。さらに、サプライチェーンセキュリティの観点から「Pull するイメージを一度内部レジストリで精査してから配布する」というポリシーを持つ組織も増えており、単なる帯域節約以上の役割がキャッシュサーバに求められるようになっています。

こうした背景から、キャッシュサーバの導入自体は普及しつつある一方、障害時の設計が後回しになったまま本番投入されるケースは少なくありません。本記事では、導入手順とあわせて「キャッシュサーバが落ちたとき」を前提とした設計・切り戻しまでを一貫して整理します。

2026年現在の主要 OSS と選択の考え方

キャッシュ・プロキシレジストリとして実績のある OSS は複数存在しており、それぞれ適した用途が異なります。

• CNCF Distribution（旧 Docker Registry）：シンプルな Pull-through キャッシュとして最小構成で動かせます。追加機能は少ないものの、containerd のミラー設定と相性がよく、軽量な社内キャッシュ用途に適しています。
• Harbor：CNCF 卒業プロジェクトで、脆弱性スキャン（Trivy 統合）・ロールベースアクセス制御・レプリケーションを備えます。エンタープライズ向けの標準的な選択肢となっています。
• Zot：OCI ネイティブの実装で、OCI Distribution Spec への準拠度が高く、2024 年に CNCF サンドボックスに入ってから採用例が増えています。Harbor よりも軽量で、OCI アーティファクト全般を扱う環境に向いています。
• Nexus Repository OSS：コンテナに限らず Maven・npm・PyPI なども一元管理したい組織で引き続き採用されています。

純粋な「Pull-through キャッシュ」だけが目的であれば CNCF Distribution が最も小さく始められます。セキュリティスキャンや権限管理が必要になった段階で Harbor や Zot への移行を検討するのが、段階的な導入として現実的です。

containerd / Kubernetes へのミラー設定と本番導入手順

containerd 1.7 以降では、/etc/containerd/config.toml の [plugins."io.containerd.grpc.v1.cri".registry] セクションにミラーを定義する方式が安定しています。2026 年時点で主流の Kubernetes ディストリビューション（kubeadm 構成・EKS Managed Node・GKE Autopilot など）はいずれも containerd をランタイムとして使用しているため、以下の設定が広く通用します。

# /etc/containerd/config.toml（抜粋）
[plugins."io.containerd.grpc.v1.cri".registry]
  config_path = "/etc/containerd/certs.d"

config_path を指定することで、レジストリごとのディレクトリベース設定が有効になります。Docker Hub のミラーを設定する場合は以下のようなファイルを配置します。

# /etc/containerd/certs.d/docker.io/hosts.toml
server = "https://registry-1.docker.io"

[host."https://cache.example.internal:5000"]
  capabilities = ["pull", "resolve"]
  skip_verify = false

設定後は systemctl restart containerd で反映します。Kubernetes ノードへの適用は DaemonSet と init コンテナを使って自動化するか、Ansible などの構成管理ツールで全ノードに展開します。ローリングで適用するときは、ノードを一台ずつ kubectl drain してから設定を変更し、kubectl uncordon で戻す手順が安全です。

キャッシュサーバ側（CNCF Distribution を例にすると）の Pull-through 設定はシンプルです。

# config.yml（CNCF Distribution）
version: 0.1
proxy:
  remoteurl: https://registry-1.docker.io
  username: ""   # Docker Hub 認証が必要な場合は設定
  password: ""
storage:
  filesystem:
    rootdirectory: /var/lib/registry
  cache:
    blobdescriptor: inmemory
http:
  addr: :5000
  tls:
    certificate: /certs/server.crt
    key: /certs/server.key

TLS は本番環境では必須です。内部 CA で発行した証明書を使う場合は、containerd の hosts.toml の ca フィールドに CA 証明書パスを指定します。

障害時フォールバックの設計と実装

最も重要なのが、キャッシュサーバがダウンした場合の動作設計です。containerd のミラー設定では、hosts.toml に複数のホストを記述することでフォールバックチェーンを構成できます。

# /etc/containerd/certs.d/docker.io/hosts.toml
server = "https://registry-1.docker.io"

[host."https://cache-primary.example.internal:5000"]
  capabilities = ["pull", "resolve"]

[host."https://cache-secondary.example.internal:5000"]
  capabilities = ["pull", "resolve"]

# 上記がすべて失敗した場合、server（Docker Hub）に直接フォールアウト

containerd はリスト上位から順に試行し、失敗した場合は次のエントリへ移ります。最終的に server として指定したオリジンへのフォールアウトが有効になっているため、キャッシュが全滅してもオリジンから Pull できる構成になります。ただし、この「フォールアウト」が意図しない外部通信を許容することになるため、ネットワークポリシーや Egress 制御との整合性を事前に確認しておく必要があります。

フォールバックの実効性はヘルスチェックにも依存します。キャッシュサーバの前段にロードバランサ（HAProxy や NGINX、あるいはクラウドの内部 LB）を置き、パッシブヘルスチェックでダウンノードを自動的に除外する構成が堅牢です。キャッシュサーバ自身の冗長化については、CNCF Distribution の場合は複数インスタンスが同一のストレージ（NFS・S3 互換オブジェクトストレージ）を参照するか、あるいはキャッシュはステートレスと割り切って各ノードが独立してオリジンへフォールアウトする設計のいずれかが現場では選ばれています。

Kubernetes レベルでは、imagePullPolicy: IfNotPresent を標準にすることで、ノードローカルのイメージキャッシュが存在する限りレジストリへのアクセス自体が発生しない点も障害耐性に寄与します。初回の Pull さえ成功すれば、その後はキャッシュサーバが落ちてもワークロードの再スケジュールは問題なく行えます。

切り戻し手順と確認ポイント

キャッシュサーバを撤去・変更する際の切り戻しは、設定ファイルを元に戻して containerd を再起動するだけでほぼ完結しますが、いくつか確認すべき点があります。

• キャッシュサーバの除去：hosts.toml からミラーエントリを削除し、systemctl restart containerd を実行します。設定ファイルのバックアップを事前に取っておくことで、誤削除からの復旧が素早く行えます。
• ノードごとの設定確認：crictl info | grep -A 20 registry で containerd が認識している設定を確認できます。ローリング適用後は代表ノードで必ず確認します。
• Pull 動作の検証：設定変更後に crictl pull docker.io/library/alpine:latest を実行し、ミラーを経由しているかどうかをキャッシュサーバのアクセスログで確認します。
• イメージキャッシュのクリア：テスト目的でノードローカルのキャッシュを消したい場合は crictl rmi --prune を使います。誤って全ノードで実行すると次の Pod 起動時に一斉に外部 Pull が発生するため、本番では慎重に行います。

切り戻し後に Rate Limit に抵触する懸念がある場合は、一時的に Pod のスケールダウンや新規デプロイの停止を検討し、トラフィックを分散させながら切り戻しを進めます。

2026年現行環境での注意点と環境差分

2026 年時点で留意すべきいくつかの変化点を整理します。

containerd の設定形式の変遷：containerd 1.6 以前では config.toml の [plugins."io.containerd.grpc.v1.cri".registry.mirrors] セクションに直接記述する形式が使われていましたが、1.7 以降は config_path によるディレクトリベース形式が推奨されており、旧形式はデプリケーション扱いとなっています。古いドキュメントを参照して旧形式を使い続けている環境では、将来バージョンアップ時に設定が無効になるリスクがあるため、棚卸しが必要です。

OCI Image Index と Multi-arch への対応：arm64 ノードが混在するクラスタが増えた結果、キャッシュサーバが OCI Image Index（マルチアーキテクチャマニフェスト）を正しくプロキシできるかどうかが重要になっています。CNCF Distribution の比較的新しいバージョンと Harbor 2.x 以降は対応していますが、古いバージョンのままアップデートを怠っている場合は manifest unknown エラーが arm64 ノードだけで発生するという問題が起きやすいです。

Kubernetes の ImagePullSecret とキャッシュサーバの認証：プライベートレジストリのイメージをキャッシュ経由で引っ張る場合、認証情報をどこで処理するかの設計が複雑になります。キャッシュサーバ側でオリジンの認証情報を保持する方式と、クライアント（kubelet）側の credential helper を経由する方式があります。Harbor の場合はレプリケーションルールで事前に Pull & キャッシュしておく方式が運用上シンプルです。

Sigstore / Cosign によるイメージ署名検証：2026 年現在、イメージ署名の検証を Admission Controller（Policy Controller や Kyverno）で強制する組織が増えています。キャッシュサーバが署名検証に必要な Rekor ログや Fulcio 証明書のエンドポイントへの疎通を遮断しないよう、Egress ポリシーの設計時に考慮が必要です。署名検証をキャッシュサーバより後段で行う構成では、キャッシュされたイメージのダイジェストが変わらないことを前提とするため、Pull-through キャッシュがダイジェストを改変しないことを確認しておく必要があります。

キャッシュサーバは「あると便利」から「止まると困る」インフラへと位置づけが変わりつつあります。フォールバックと切り戻しを設計の一部として組み込み、定期的に障害シナリオをドリルしておくことが、長期安定運用の鍵です。