「Kubernetes へのデプロイを kubectl apply の手作業でやっていて、誰がいつ何を変えたのか分からなくなってきた」——そんな悩みを解決するのが GitOps です。結論から言うと、Ubuntu 上の Kubernetes に Flux CD を入れれば、Git に push するだけで本番が自動更新され、手で壊した設定も勝手に元へ戻る仕組みが作れます。
本記事では Ubuntu 24.04 LTS の環境で、kind（Kubernetes in Docker）で本物のクラスタを立て、Flux CD を実際にインストールして GitHub 上のリポジトリから自動デプロイするところまでを全部動かしました。さらに「自己修復」が本当に効くのか、Flux が管理する Service をわざと kubectl delete で消して、何秒で復元するかまで計測しています。
Flux 自体はコマンドライン中心のツールですが、Flux コミュニティ製のダッシュボード Capacitor も GitOps でデプロイして、ブラウザで状態を見られる画面も実際に撮影しました。「コマンドの結果が本当にこうなるのか」を端から端まで確かめた、実データ中心の記事です。
この記事のポイント
- GitOps とは「Git を唯一の正（Single Source of Truth）」とし、Flux がクラスタをそれに合わせ続ける運用方式
- Ubuntu への Flux CLI 導入は
curl -s https://fluxcd.io/install.sh | bashの1行。実行時点の最新はflux 2.8.8 - 実測: GitHub の podinfo リポジトリを登録するだけで Service・Deployment・HPA の3リソースが自動展開された
- 実測: Flux 管理下の Service を手で削除しても、reconcile で平均2.06秒で Git の定義どおりに復元された（自己修復）
- Flux はクラスタ内から定期的に Git を pull するpull 型。外部 CI にクラスタの認証情報を渡さずに済む
Flux CDとGitOpsとは：Gitを唯一の正にする運用方式
Flux CD（以下 Flux）は、Kubernetes 向けの GitOps ツールです。GitOps とは、クラスタにデプロイしたい状態（マニフェスト）をすべて Git リポジトリに置き、Git の内容こそが本番のあるべき姿だと決めてしまう運用のやり方です。マニフェストとは、Deployment や Service など Kubernetes のリソース定義を書いた YAML ファイルのことです。
従来の「CI から kubectl apply を叩く」やり方（push 型）と違い、Flux はクラスタの内側から定期的に Git を pull し、Git とクラスタの実状態を照合し続けます（pull 型）。差分があれば Flux が自動で埋めにいきます。
この仕組みの嬉しいところは大きく2つです。1つは、人間が本番クラスタを kubectl で直接いじらなくなること。変更はすべて Git の Pull Request を通すので、誰がいつ何を変えたかが Git の履歴に残ります。もう1つは、外部の CI サービスにクラスタの管理者権限（kubeconfig）を渡さずに済むことです。Flux はクラスタの中で動くので、認証情報がクラスタの外に出ません。
用語の整理
Flux には主に2つの導入方法があります。flux install はコントローラだけをクラスタに入れる方法（お試し向き）、flux bootstrap は Flux 自身の設定も Git リポジトリで管理する本番向きの方法です。本記事ではまず flux install で仕組みを体験し、最後に flux bootstrap につながる SSH デプロイキーの作り方まで触れます。
動作確認済み環境
| 項目 | 環境・バージョン |
|---|---|
| ベースOS | Ubuntu 24.04.4 LTS（Docker 公式イメージ ubuntu:24.04） |
| Kubernetes | kind v0.23.0 で構築（Kubernetes v1.30.0） |
| Flux CLI | ラボ構築に flux 2.3.0 / Ubuntu への新規導入は最新の 2.8.8 |
| Flux コントローラ | source/kustomize/notification v1.3.0・helm v1.0.1 |
| デプロイ対象 | podinfo（github.com/stefanprodan/podinfo, master） |
| 計測日 | 2026年6月15日 |
kind は Docker コンテナの中に Kubernetes クラスタを作るツールで、ノートPCでも本物の Kubernetes API を相手に検証できます。VPS の Ubuntu でも同じ手順がそのまま通ります。
手順1：UbuntuにFlux CLIをインストールする
まずは手元の Ubuntu に Flux のコマンドラインツール（CLI）を入れます。公式のインストールスクリプトを使うのが一番手軽です。Docker 公式の Ubuntu 24.04 イメージで、実際に実行したログがこちらです。
1行のコマンドで、実行時点の最新版 flux 2.8.8（linux/arm64）が /usr/local/bin/flux に入りました。ここで flux install --export を実行すると、クラスタへ投入する前のマニフェストを標準出力に書き出すだけなので、中身を確認してから入れたい場合に便利です。
flux version 2.8.8
$ flux completion bash > /etc/bash_completion.d/flux
# ↑ タブ補完を有効にしておくと flux のサブコマンドが楽になります
注意
CLI のバージョンとクラスタに入れるコントローラのバージョンは連動します。本記事のラボは検証時点で導入済みだった flux 2.3.0 系（コントローラ v1.0.1〜v1.3.0）で計測しています。これから新規に入れる場合は最新の 2.8.8 系が入るので、出力のバージョン番号は読み替えてください。
手順2：クラスタにFluxをインストールしてGitOpsの土台を作る
CLI が入ったら、Kubernetes クラスタ側に Flux のコントローラ群を入れます。コントローラとは、特定の役割を持ってクラスタ内で常駐するプログラムのことです。まず flux check --pre でクラスタが要件を満たすか確認し、問題なければ flux install でコントローラを展開します。
Flux は役割ごとに4つのコントローラに分かれています。Git や OCI からマニフェストを取得する source-controller、取得した内容をクラスタに適用する kustomize-controller、Helm チャートを扱う helm-controller、Slack 通知などを担う notification-controller です。flux install を打つと、これらが flux-system という名前空間にまとめて作られ、すべて deployment ready になりました。
最初は「コントローラが4つもあって難しそう」と感じますが、普段意識するのは source と kustomize の2つだけです。Git を見るのが source、それをクラスタに反映するのが kustomize、と覚えておけば十分です。
手順3：GitリポジトリをソースにアプリをGitOpsデプロイする
ここからが GitOps の本番です。kubectl apply を一切使わず、Git リポジトリを登録するだけでアプリをデプロイします。流れは2段階です。まず flux create source git で「どの Git リポジトリのどのブランチを見るか」を登録し、次に flux create kustomization で「そのリポジトリのどのパスをクラスタに適用するか」を指定します。
今回は Flux の定番サンプルである podinfo のリポジトリを使いました。実際のセッションがこちらです。
注目してほしいのは、一度も kubectl apply を打っていないのに、default 名前空間に Service・Deployment・HorizontalPodAutoscaler の3つのリソースが展開されている点です。Flux が GitHub からマニフェストを取得（リビジョン 13e4ded7）し、自動で適用してくれました。flux tree kustomization podinfo を使うと、この Kustomization が何のリソースを管理しているのかが一覧できます。
一度この状態を作ってしまえば、あとは Git にコミットして push するだけです。たとえばリポジトリ側でレプリカ数やイメージのタグを書き換えて push すれば、次の reconcile（本記事では --interval=1m なので最大1分後）に Flux が自動で反映します。
デプロイしたアプリとFluxの状態をWebUIで見る
Flux 本体にはダッシュボード UI が付いていませんが、コミュニティ製の Capacitor という Flux 用 Web UI があります。面白いのは、この Capacitor 自身も GitOps で（OCIRepository をソースに）デプロイできることです。つまり「Flux を見るためのツールを Flux でデプロイする」わけです。
Capacitor をデプロイしてブラウザで開いた画面がこちらです。podinfo と capacitor の2つの Kustomization が「Applied」になっていて、画面下に SOURCES: Ready(2/2) KUSTOMIZATIONS: Ready(2/2) と出ているのが分かります。
各 Kustomization の「Sync」欄には Applied 1 minute ago と、適用した Git リビジョン（podinfo は 13e4ded7）が表示されます。どのコミットがクラスタに反映されているかが一目で分かるので、GitOps の状態確認にぴったりです。
そして、Flux が GitHub から取ってきて自動デプロイした podinfo アプリ本体も、ちゃんと動いています。Service 経由でアクセスすると、podinfo の Web 画面が表示されました。
「greetings from podinfo v6.13.0」と、デプロイされたバージョンとホスト名（Pod 名）が表示されています。Git にマニフェストを置いただけで、ここまで本物のアプリが立ち上がっているわけです。
GitOpsの真価：自己修復（ドリフト補正）を実測する
GitOps が単なる「自動デプロイ」と決定的に違うのが、自己修復（ドリフト補正）です。クラスタの実状態が Git と食い違うと、Flux がそれを検知して Git のとおりに戻します。これを実際に試すため、Flux が管理している Service をわざと kubectl delete で削除し、復元までの時間を3回計測しました。
結果は3回とも 2.05〜2.06秒、平均2.06秒で Service が復活しました。今回は flux reconcile を手で叩いて即時に照合させましたが、実運用では interval=1m の設定で1分ごとに自動でこの照合が走るため、誰かが手で本番をいじっても放置で勝手に元へ戻ります。クラスタの「正」は常に Git にある、という GitOps の核心が体感できる瞬間です。
補足：HPAが絡む場合
podinfo には HorizontalPodAutoscaler（HPA）が含まれており、レプリカ数は HPA（min 2 / max 4）が制御します。そのため「レプリカ数を手で変える」ドリフトは HPA の管轄になり、単純な比較がしにくいです。今回はリソースそのものを削除する分かりやすいシナリオで計測しました。
SSHデプロイキーで本番運用につなげる
お試しの flux install から一歩進んで、Flux 自身の設定も Git で管理する本番運用（flux bootstrap）に進むと、Flux が Git リポジトリへ読み書きするための SSH デプロイキーが必要になります。デプロイキーは、特定のリポジトリ1つだけにアクセスを限定できる SSH 鍵です。実際に ed25519 鍵を生成してみました。
生成した公開鍵（ssh-ed25519 AAAA...flux@linuxlab）を GitHub のリポジトリ設定 → Deploy keys に「Allow write access」を付けて登録すれば、Flux はそのリポジトリへ自分の管理する状態（HelmRelease の更新など）を書き戻せるようになります。秘密鍵はクラスタ内の Secret として保管され、外には出ません。
注意：鍵の種類
デプロイキーはリポジトリ単位で権限が閉じるため、個人のアカウント鍵を使うより安全です。flux bootstrap github コマンドを使うと、リポジトリ作成・鍵生成・登録までを自動でやってくれますが、その裏側でやっているのは今回手で確認したのと同じ ed25519 デプロイキーの登録です。
Fluxを動かすホストに必要なスペックとVPS選び
Flux のコントローラ群は常駐しますが、消費リソースは控えめです。とはいえ Kubernetes クラスタそのものを動かすには、ある程度の CPU とメモリが必要です。参考までに、今回 kind クラスタを動かしたホストの素の CPU 性能を sysbench で計測しました。
自宅で Kubernetes を学ぶなら kind や minikube で十分ですが、本番に近い形で常時動かすなら VPS が現実的です。シングルノードの k3s や kind を載せるなら、最低でも 2vCPU / 4GB RAM は欲しいところです。主要 VPS の最小〜中位プランを比較しました。
| VPS | 2vCPU/4GBの目安 | 東京リージョン | 日本語サポート | 評価 |
|---|---|---|---|---|
| Vultr | $20/月前後 | あり | なし（英語） | ★★★★★ |
| DigitalOcean | $24/月前後 | なし（最寄シンガポール） | なし（英語） | ★★★★☆ |
| Linode (Akamai) | $24/月前後 | あり | なし（英語） | ★★★★☆ |
| ConoHa VPS | 月3,000円前後 | あり（国内） | あり（日本語） | ★★★★☆ |
時間単位課金で東京リージョンもある Vultr は、「数時間だけ Kubernetes を立てて GitOps を試す」用途と相性が良いです。検証が終わったらインスタンスを削除すれば課金も止まります。日本語サポートを重視するなら ConoHa VPS も選択肢になります。
よくあるエラーと解決策
実際に動かしてみてつまずきやすかったポイントを挙げます。
flux get kustomizations で READY が False のまま
MESSAGE 欄を必ず確認します。path not found なら --path の指定がリポジトリの構造と合っていません。flux logs --kind Kustomization --name <名前> でコントローラのログを見ると、YAML の構文エラーなのか権限不足なのか切り分けられます。
flux check –pre で Kubernetes バージョンが弾かれる
Flux の新しめのバージョンは Kubernetes 1.28 以上を要求します。古いクラスタだと <1.28.0-0 で止まるので、クラスタ側を上げるか、対応する古い Flux を使います。今回の v1.30.0 は ✔ Kubernetes 1.30.0 >=1.28.0-0 で通りました。
source は OK なのに反映されない
source（Git の取得）と kustomization（適用）は別物です。flux get sources git が Ready でも、kustomization が作られていなければクラスタには何も起きません。両方を flux get all で確認するのが確実です。
まとめ
Ubuntu 上の Kubernetes に Flux CD を入れて、GitOps による継続的デプロイを実際に動かしました。要点を整理します。
この記事のまとめ
- Flux CLI は curl の1行で導入でき、最新は flux 2.8.8（Ubuntu 24.04 で確認）
- flux install で source/kustomize/helm/notification の4コントローラが入る
- Git リポジトリを登録するだけで、kubectl を使わずに Service・Deployment・HPA が自動展開された
- 自己修復は実測で平均2.06秒。手で消したリソースが Git の定義どおりに戻る
- 本番運用は ed25519 のデプロイキーで Git と連携する flux bootstrap に進む
GitOps は「自動デプロイ」だけでなく、クラスタの状態を常に Git に一致させ続けるところに価値があります。まずは手元の kind や minikube で本記事の手順をなぞり、慣れてきたら東京リージョンのある VPS に持っていって、自分のリポジトリで本番運用を始めてみてください。
コメント