【図解OpenShift】コア4大リソースの協調関係とHelm×ArgoCDによる多層Valuesカスケード配信アーキテクチャ

Posted at 2026-10-21

📌 はじめに

Kubernetes（K8s）や OpenShift の学習および本番運用において、個々のリソース定義（Deployment、Service、Route、ConfigMap）の仕様を単体で理解していても、それらが「実際のクラスタ内でどのように協調して動いているのか」「Helm と ArgoCD によってどのように多環境へ安全に展開されているのか」という全体像を俯瞰できていないと、本番障害時の迅速な切り分けが難しくなります。

本記事では、OpenShift におけるコア4大リソースの協調関係を直感的な「近代レストランの運営体系」に例えて整理するとともに、エンタープライズ共通基盤で標準採用される**「4層構造の Values カスケードオーバーライド機構」および日常運用における変更箇所の特定マトリクス**を体系的にまとめます。

1. コア4大リソースの協調関係と全体トポロジー

OpenShift 内で動作する主要リソースの役割は、以下のような「レストランの運営組織」に例えて捉えることができます。

Deployment（厨房と料理人の体制）: 実際に計算処理を担う Pod のライフサイクルや多重度を維持・管理する。
ConfigMap（壁掛けのマニュアル）: コードやイメージに焼き込まず、外部から差し替え可能な設定値や静的テキストファイル。
Service（内部の配膳・受付カウンター）: 揮発性の高い Pod 群の前面に立ち、不変の内部 VIP と L4 負荷分散を提供する。
Route（通りに面した正面玄関の看板）: クライアントを社内ネットワークや外部から迎え入れる L7（HTTP/HTTPS）のエントリポイント。
Helm ＋ ArgoCD（標準設計図面と自動施工ロボット）: これらの一式をパラメータ化し、異なる環境（Namespace）へ自律的に複製・同期する。

リソース間のトラフィック＆参照トポロジー

  [ 外部ネットワーク / クライアントブラウザ ]
             │
             ▼
  ┌────────────────────────────────────────────────────────┐
  │ 1. Route (templates/route.yaml)                        │
  │    【正面玄関】：外部公開用の HTTP/HTTPS ドメイン・パス  │
  └──────────────────────────┬─────────────────────────────┘
                             │ (内部受付カウンターへトラフィック転送)
                             ▼
  ┌────────────────────────────────────────────────────────┐
  │ 2. Service (templates/service.yaml)                    │
  │    【配膳窓口】：クラスタ内固定 VIP ＆ 内部 DNS 名前解決 │
  └──────────────────────────┬─────────────────────────────┘
                             │ (実稼働中の Pod へラウンドロビン転送)
                             ▼
  ┌────────────────────────────────────────────────────────┐
  │ 3. Deployment (templates/deployment.yaml)              │
  │    【厨房体制】：Pod の生命周期、冗長レプリカ数、配置管理│
  │                                                        │
  │    ┌──────────────────────────────────────────────┐    │
  │    │ Pod (コンテナ実稼働体)                       │    │
  │    │  - 内部ポート監視 (例: 8080)                  │    │
  │    │  - 環境変数 / マウント設定を参照 ◄─────────┐ │    │
  │    └──────────────────────────────────────│───────┘    │
  └───────────────────────────────────────────│────────────┘
                                              │ (静的設定の注入)
  ┌───────────────────────────────────────────┴────────────┐
  │ 4. ConfigMap (templates/configmap.yaml)                │
  │    【業務マニュアル】：nginx.conf 等の非機密設定テキスト│
  └────────────────────────────────────────────────────────┘

各リソースの技術的責務

① Deployment

責務: アプリケーションプロセスの高可用性と自己修復を担保します。
動作特性: 単体で直接外部トラフィックを処理するのではなく、Pod の期待数（Desired Replicas）やリソース制限（CPU/メモリの Requests・Limits）、ローリングアップデートの挙動を監視・制御するコントローラとして機能します。

② ConfigMap

責務: 「コードと設定の分離（The Twelve-Factor App: Config）」を実現します。
動作特性: コンテナイメージの再ビルドを伴わずに環境固有の挙動を変更するため、nginx.conf などの設定ファイルをボリュームとしてマウントしたり、環境変数として Pod 起動時に注入します。

③ Service

責務: クラスタ内部における安定した名前解決と負荷分散を提供します。
動作特性: Pod は障害や更新のたびに動的に IP が変動します。Service は特定のラベル（Label Selector）を持つ Pod 群を束ね、クラスタ内部で恒久的に変わらない仮想 IP（ClusterIP）と DNS 名（例: backend-svc.ns.svc.cluster.local）を提供します。

④ Route

責務: クラスタ外部からのリクエストを内部 Service へ橋渡しします。
動作特性: 標準 K8s の Ingress に相当する OpenShift 固有のコアリソースです。クラスタ境界に位置する HAProxy ルーターによって管理され、ドメイン名（FQDN）のルーティング、TLS/SSL 暗号化終端、URL パスベースの振り分けを実行します。

2. デリバリーパイプライン：Helm テンプレートと多層 Values のカスケード機構

エンタープライズ基盤におけるマニフェストファイル群は、静的な YAML を直接適用するのではなく、「骨組みの共通化（Chart） ➔ 階層的パラメータ補完（Values） ➔ GitOps 自動同期（ArgoCD）」 という一連のパイプラインによって処理されます。

[ 1. アプリケーションコードリポジトリ ]
  ソースコード + Multi-stage Dockerfile ──► 実行バイナリのみを含む軽量イメージを ECR/Harbor へ登録
                                             │
                                             ▼
[ 2. 統合 Helm Chart リポジトリ ]
  templates/ 配下のマニフェストは【空欄のある共通骨格】：
  - deployment.yaml : image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
  - route.yaml      : host:  {{ .Values.route.host }}
                                             │
                                             ▼ (4層構造のカスケード値マージ)
  Layer 1: values.yaml                     (全社・全環境共通のベースライン規定値)
  Layer 2: env/base-platform.yaml          (基盤・インフラ種別ごとの標準ネットワーク・セキュリティ設定)
  Layer 3: env/target-stage.yaml           (環境ステージ別の差分設定: dev / stg / prod)
  Layer 4: project/tenant-workload.yaml    (案件・個別テナント固有の最末端オーバーライド値)
                                             │
                                             ▼ (Go Template エンジンが完全な K8s YAML をレンダリング)
[ 3. ArgoCD (GitOps デリバリーエンジン) ]
  Git リポジトリのコミット差分を常時検知 ──► 対象 Namespace へ宣言的自動同期（Reconcile）

なぜ4層の Values 構造を採用するのか？

DRY（Don't Repeat Yourself）の徹底:
コンテナのヘルスチェック（Liveness/Readiness Probe）のパラメータや標準ディレクトリ構造など、90% 以上の共通定義は最上位の values.yaml に集約し、テンプレートの重複作成を排除します。
環境差異と個別案件要件の直交分離:
環境レイヤー（Dev/Prod）: 開発環境では CPU/メモリの低割り当てとデバッグログの有効化を行い、本番環境では高多重度と詳細監視を強制します。
案件・テナントレイヤー: 特定の接続先データベースエンドポイント、固有のサブドメイン名、個別ポートマッピングといった案件特有の差分のみを最末端の YAML（project/xxxx.yaml）でピンポイントに上書きします。

ArgoCD による自動同期の意義

構成ドリフト（Configuration Drift）の物理的遮断:
人手によるクラスタへの直接コマンド実行（oc apply や kubectl edit）を禁止し、Git を唯一の真実（Single Source of Truth） として維持します。
監査証跡と即時復元:
すべてのパラメータ変更履歴が Git コミットログとして記録され、万が一設定ミスによる障害が発生した際も、該当コミットの revert だけで数秒以内に健全な状態へロールバックが完了します。

3. 実務クイックリファレンス：要件別の変更対象特定マトリクス

運用現場で仕様変更やトラブルシューティングが発生した際、影響範囲とリポジトリ内の編集対象ファイルを即座に特定するための対応表です。

変更・調査要件	担当するアーキテクチャ層	リポジトリ内の主要編集・確認対象
リバースプロキシのルーティング規則や静的設定の変更	設定管理層（ConfigMap）	`templates/configmap.yaml` または参照元の設定テキスト
外部公開 URL、FQDN、TLS 証明書、パスルーティングの調整	境界ルーティング層（Route）	`templates/route.yaml` および各環境の Route 変数設定
コンテナ起動ポート、環境変数、CPU/メモリ枠、探針の調整	プロセスオーケストレーション層（Deployment）	`templates/deployment.yaml`
特定プロジェクト/個別環境のみに対する接続先・固有値の変更	最末端パラメータ層（Project Values）	`project/<target-workload>.yaml`

4. まとめ

リソースの役割分担:

アプリの実行ライフサイクルは Deployment、設定の外部化は ConfigMap、クラスタ内通信の固定化は Service、外部からの入口は Route がそれぞれ独立して担当する。

階層化デリバリーの必然性:

Helm のテンプレート共通化と多層 Values（共通 ➔ プラットフォーム ➔ 環境 ➔ 個別案件）を組み合わせることで、コードの重複を最小化しつつ柔軟な環境分離を実現する。

GitOps による統制:

すべての構成変更を Git リポジトリ経由に限定し、ArgoCD による自動調和を行うことで、人的作業ミスを排除した高可用・高監査性なエンタープライズ共通基盤を確立する。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up