Kubernetes and Cloud Native Associate (KCNA) #7 Cloud Native Application Delivery (8%): GitOps、CI/CD
#6 Cloud Native Observability では、動いているシステムをどう覗き込むかを整理しました。ここで視線を 1 段階手前に移します。開発者が書いたアプリケーションがどんな経路を通ってクラスターまで 安全に届けられるのか が、この記事のテーマです。
Domain 5 Cloud Native Application Delivery は比重 8% の小さなドメインですが、CI/CD と GitOps という現代のクラウドネイティブ運用の核となる語彙が集まっています。コードがコミットされる瞬間からクラスターで実際に動くまでの流れ、その流れを自動化し信頼できるものにする原則を、この記事でまとめます。
デリバリーという問題 #
開発者がコードを書くことと、そのコードがクラスターでユーザーに提供されることの間には長い距離があります。その間を埋めるすべての段階、すなわちビルド・テスト・イメージ生成・デプロイ・検証をまとめて Application Delivery と呼びます。クラウドネイティブの世界では、このデリバリーの単位は常に コンテナイメージ です。
ソースコードではなくイメージがデリバリーの単位であるという点が核心です。一度ビルドされたイメージはイミュータブル (immutable) であり、開発・ステージング・本番の各環境に 同一のイメージ が流れていきます。「私の PC では動いたのに」という問題を構造的になくす出発点が、このイミュータブルなイメージです。
CI/CD の基礎 #
CI/CD は、2 つの分離した概念を 1 つの塊として呼ぶ表現です。試験では両者の境界を正確に切り分ける設問がよく出るため、分けて覚えておく必要があります。
CI (Continuous Integration) #
CI は コードを統合して検証する 段階です。開発者がコミットをプッシュすると、自動的に次の作業が走ります。
- ソースコードのビルド
- ユニットテスト・統合テストの実行
- 静的解析・リント
- コンテナイメージのビルドとレジストリへのプッシュ
CI の成果物は テストを通過したコンテナイメージ です。ここまでではまだクラスターに何もデプロイされていません。
CD (Continuous Delivery / Deployment) #
CD は、CI が作り出したイメージを 実際の環境にデプロイする 段階です。CD はさらに 2 つに分かれます。
- Continuous Delivery。本番デプロイの直前までを自動化しつつ、本番反映は人が承認ボタンを押してトリガーします。
- Continuous Deployment。本番反映まで人の介入なく完全に自動で進めます。
CI と CD を分ける基準は明確です。イメージを作るところまでが CI、そのイメージをクラスターに立ち上げるところからが CD です。
パイプライン #
CI と CD をつなぎ合わせた自動化の流れがパイプライン (pipeline) です。コミット 1 回が、ビルド・テスト・イメージプッシュ・デプロイ・検証へと自動で連結されます。Jenkins、GitLab CI、GitHub Actions、Tekton といったツールがこのパイプラインを構成します。その中で Tekton は Kubernetes ネイティブな CI/CD フレームワークであり、CNCF プロジェクトです。
GitOps #
GitOps は CD を実装する 運用パラダイム です。クラウドネイティブデリバリーで最もよく出題される概念なので、定義と原則を正確に押さえる必要があります。
定義 #
GitOps は Git を単一の信頼できる情報源 (single source of truth) として システムの desired state を宣言型マニフェストで管理し、その状態をクラスターに自動で反映する方式です。一文に縮めると「望む状態を Git に書き、クラスターをその状態に合わせる」となります。
4 大原則 #
OpenGitOps プロジェクトが整理した GitOps の 4 つの原則は試験の常連です。
| 原則 | 意味 |
|---|---|
| 宣言型 (Declarative) | システムの desired state を宣言型で記述する |
| バージョン管理・不変 (Versioned and Immutable) | desired state を Git に保存してバージョン管理し、変更履歴を不変で保持する |
| 自動適用 (Pulled Automatically) | 承認された desired state をソフトウェアエージェントが自動で取得して適用する |
| 継続的な調整 (Continuously Reconciled) | エージェントが実際の状態を desired state と絶えず比較して一致させる |
push ベースと pull ベース #
GitOps の核となる差別化点は pull ベースのデリバリー です。両者の違いを正確に区別する設問がよく出ます。
- push ベース。CI パイプラインがクラスターの外から
kubectl applyのようなコマンドでクラスターに変更を押し込みます。外部のパイプラインがクラスターの認証情報を持っていなければなりません。 - pull ベース (GitOps)。クラスター内に常駐するエージェントが Git リポジトリを定期的に観察し、変更を検知すると自ら取り込んで適用します。認証情報がクラスターの外に出ません。
GitOps は基本的に pull ベースを志向し、この点がセキュリティと一貫性の面での強みにつながります。
GitOps の利点 #
| 利点 | 説明 |
|---|---|
| 監査可能性 | すべての変更が Git コミットとして残り、誰が・いつ・何を変えたかを追跡できる |
| 容易なロールバック | 以前のコミットに戻せばクラスターの状態もその時点に復元される |
| 再現性 | 同じマニフェストで同一のクラスターをいつでも再構成できる |
| drift の自動補正 | 誰かがクラスターを直接いじっても Git の状態に戻す |
GitOps ツール #
KCNA は 2 つのツールの役割と立ち位置を認識するレベルを問います。
- ArgoCD。最も広く使われている GitOps ツールです。ウェブ UI が強力で、アプリケーションの sync 状態とリソースツリーを視覚的に見せてくれます。CNCF Graduated プロジェクトです。
- Flux。コントローラーの集まりとして動作する GitOps ツールです。Kubernetes ネイティブに設計されており、ほかのツールと組み合わせやすいです。こちらも CNCF Graduated プロジェクトです。
両ツールとも動作原理は同じです。Git に定義された desired state とクラスターの 実際の state を絶えず比較 (diff) し、両者がずれると drift として検知して desired state に合わせて sync します。この desired state と cluster state の比較・一致のプロセスが reconciliation の本質です。
実務の流れは 実務トラック上級 #6 GitOps で ArgoCD と Flux を使って直接扱います。
デプロイ戦略 #
新しいバージョンを既存のバージョンとどう入れ替えるかがデプロイ戦略です。KCNA は各戦略の概念とトレードオフを問います。
| 戦略 | 方式 | トレードオフ |
|---|---|---|
| Recreate | 既存の Pod をすべて落として新しいバージョンを立ち上げる | 最も単純だが入れ替えの間にダウンタイムが発生する |
| Rolling update | 既存の Pod を少しずつ新しいバージョンへ段階的に入れ替える (Kubernetes デフォルト) | ダウンタイムなしで段階的に入れ替える。2 つのバージョンが一時的に共存する |
| Blue-green | 本番 (blue) と同一の新環境 (green) を立ち上げ、トラフィックを一気に切り替える | 即時ロールバックが可能。2 倍のリソースが必要 |
| Canary | 新しいバージョンにトラフィックの一部だけを先に送って検証し、段階的に拡大する | リスクを小さく露出させる。トラフィック分配の制御が必要 |
Kubernetes Deployment の デフォルト戦略が rolling update である点が試験によく出ます。blue-green と canary は Deployment 単独では限界があるため、Service Mesh や Argo Rollouts のようなツールの助けを借りるケースが多いです。
マニフェスト管理 #
環境ごとに異なる設定値を繰り返し書かずにマニフェストを効率的に管理する、2 つの代表的なツールです。
Helm #
Helm は Kubernetes の パッケージマネージャー です。核となる語彙は次の通りです。
- チャート (Chart)。Kubernetes マニフェストを束ねたパッケージ
- テンプレート (Template)。変数を差し込めるマニフェストの型
- values。テンプレートに注入する環境ごとの設定値
- リリース (Release)。チャートをクラスターにインストールした 1 つのインスタンス
Helm はテンプレートに values を注入して環境ごとのマニフェストを刷り出し、リリース単位でインストール・アップグレード・ロールバックを管理します。CNCF Graduated プロジェクトです。
Kustomize #
Kustomize は テンプレートなしで マニフェストをカスタマイズするツールです。核となる語彙は base と overlay です。
- base。共通マニフェストの基準
- overlay。base の上に環境ごとの差分 (イメージタグ・レプリカ数など) だけを被せるパッチ
Kustomize は変数置換ではなく 純粋な YAML マージ 方式で動作し、kubectl に内蔵されているため別途インストールせずに kubectl apply -k で使えます。
Helm vs Kustomize #
一行で区別すると、Helm はテンプレートと values でパッケージングするパッケージマネージャー であり、Kustomize はテンプレートなしで base に overlay を被せる YAML マージツール です。
サプライチェーンセキュリティの基礎 #
デリバリーの流れが自動化されるほど「どのイメージを信頼できるのか」が重要になります。KCNA はサプライチェーンセキュリティを認識レベルでのみ扱います。
- イメージの出所の信頼。検証されたレジストリから受け取ったイメージか、ビルド過程が改ざんされていないかを確認します。
- イメージの署名 (cosign)。Sigstore プロジェクトの cosign でイメージに署名し、出所と完全性を保証します。
- SBOM (Software Bill of Materials)。イメージがどの構成要素・依存関係から作られたかを一覧化した仕様です。脆弱性追跡の基準になります。
この 3 つの用語が「サプライチェーンセキュリティ」の語彙として束ねられるという事実さえ知っていれば、KCNA レベルでは十分です。
試験ポイント #
- CI vs CD。イメージを作るところまでが CI、そのイメージをクラスターに立ち上げるところからが CD。Continuous Delivery は本番反映に承認が必要で、Continuous Deployment は完全自動
- GitOps 4 大原則。宣言型、バージョン管理・不変、自動適用、継続的な調整
- pull ベース。GitOps はクラスター内のエージェントが Git を取り込んで適用する。認証情報がクラスターの外に出ない
- drift と reconciliation。desired state と cluster state を比較してずれたら戻す
- デプロイ戦略。Deployment のデフォルトは rolling update。recreate (ダウンタイム)・blue-green (即時切り替え・2 倍のリソース)・canary (一部トラフィックを先に) を区別する
- Helm vs Kustomize。Helm はテンプレート・values ベースのパッケージマネージャー、Kustomize はテンプレートなしの base・overlay マージ
- ArgoCD・Flux。どちらも GitOps ツールであり CNCF Graduated プロジェクト
実務のパイプライン構成は 実務トラック #4 CI/CD で直接扱います。
まとめ #
この記事で押さえたこと:
- デリバリーの単位はコンテナイメージ。一度ビルドしたイミュータブルなイメージがすべての環境に同一に流れる
- CI はビルド・テスト・イメージ生成、CD はデプロイ。Continuous Delivery は承認トリガー、Continuous Deployment は完全自動
- GitOps は Git を single source of truth とする pull ベースの CD パラダイム。4 大原則 (宣言型・バージョン管理・自動適用・継続的な調整) と drift 補正
- GitOps ツールは ArgoCD と Flux。desired state と cluster state を比較して sync する
- デプロイ戦略。rolling update (デフォルト)・recreate・blue-green・canary のトレードオフ
- マニフェスト管理。Helm (パッケージマネージャー) と Kustomize (YAML マージ)
- サプライチェーンセキュリティ。イメージの出所の信頼、cosign 署名、SBOM (認識レベル)
次へ: 試験のコツ #
5 つのドメインをすべて一周しました。ここからは試験会場で点数に変える段階です。
#8 試験のコツとよく間違えるパターン では、ドメインごとに混同しやすい概念のペア、択一問題を読むコツ、時間配分、複数回答の罠まで、合格線を超えるための実戦的な戦略をまとめます。