こんにちは。現場の最前線で「いかに楽をして、いかに堅牢なシステムを作るか」に命をかけているエンジニアです。
これまで、CI/CDといえば「GitLabからKubernetesへ、SSHやkubectlで無理やり叩き込む」というスタイルが主流でした。しかし、これには「踏み台サーバーのセキュリティリスク」や「クラスターの認証情報がGitLab側に漏れる恐怖」という常に付きまとう呪縛がありました。
今日紹介する「GitLab Agent for Kubernetes (KAS)」は、その悪夢を終わらせるゲームチェンジャーです。GitLabとクラスターを「Pull型」で直接つなぐこの技術、一度導入すればもう昔のデプロイ方法には戻れません。
さあ、次世代のGitOpsの世界へ足を踏み入れましょう。
—
1. なぜ「Agent」なのか？ Pull型デプロイの極意
従来のPush型デプロイ（CIがkubectlを実行する方式）には致命的な弱点があります。それは、「GitLab側にクラスターの管理者権限が必要」ということです。
一方で、GitLab Agentを使う「Pull型デプロイ」は、クラスターの内側から「GitLabに何が変わったか見に行く」方式です。
- 強固なセキュリティ: クラスターの認証情報をGitLab側に預ける必要がありません。
- 通信の最適化: 外から内への穴あけ（Firewall設定）が不要です。
- GitOpsの完成: Gitリポジトリの状態が、そのままクラスターの真実（Single Source of Truth）になります。
—
2. さあ、構築しよう：Agentのインストール
まずは、GitLab側でAgentを認識させ、クラスターにインストールします。
ステップ①：GitLab側でAgentを登録
1. GitLabプロジェクトのサイドバーから [Infrastructure] > [Kubernetes clusters] を選択。
2. [Connect a cluster] をクリックし、適当な名前（例: `prod-agent`）でAgentを作成します。
3. 表示される「登録用トークン」をコピーしてください。これが唯一の秘密鍵です。
ステップ②：クラスター側へインストール
クラスターにHelmを使ってAgentをインストールします。
GitLab AgentのHelmリポジトリを追加
helm repo add gitlab https://charts.gitlab.io
helm repo update
インストール（
helm install gitlab-agent gitlab/gitlab-agent \
–namespace gitlab-agent-system \
–create-namespace \
–set config.token=
–set config.kasAddress=wss://kas.gitlab.com # GitLab.comの場合のURL
これで、クラスターはGitLabという「司令塔」と安全なパイプラインで繋がりました。
—
3. Hello World：GitOpsでマニフェストを同期する
Agentが動いたら、次は「GitにあるYAMLを、自動的にクラスターに反映させる」設定を行います。リポジトリのルートに `.gitlab/agents/
.gitlab/agents/prod-agent/config.yaml
gitops:
manifest_projects:
- id: path/to/your-manifest-repo # マニフェスト管理用リポジトリのパス
paths:
- glob: ‘manifests/.yaml’ # このディレクトリ内のYAMLを監視
これだけで、`manifests/` ディレクトリにマニフェストをPushすると、数秒後にはクラスターが自動的に追従して変更を適用します。kubectlコマンドを叩く必要すらありません。
—
4. 現場で震えるほど役立つ「運用の極意」
初めて導入するあなたが、必ずぶつかる壁を先に壊しておきましょう。
- マニフェストとアプリの分離: アプリコードのリポジトリと、マニフェストのリポジトリは分けるのが鉄則です。CIはビルドだけを行い、マニフェストリポジトリのイメージタグを書き換える。これがクリーンなGitOpsの作法です。
- カオスを防ぐ「マージリクエスト」: 本番環境への反映は、必ずGit上のMRで行ってください。「誰が、いつ、何を」変えたのかがGitの履歴として残るため、障害時の切り戻し（Revert）が驚くほど簡単になります。
- デバッグは「Agentログ」から: もし同期が動かないときは `kubectl logs -n gitlab-agent-system -l app=gitlab-agent` を見てください。Agent自身がGitLabと通信できているか、YAMLのパースでエラーが出ていないかがすべてそこに書かれています。
—
最後に：あなたを待っている未来
これを導入すると、デプロイ業務が「作業」から「承認」へと変わります。
「デプロイのために深夜まで待機」なんて、もう過去の遺物です。GitLab Agentは、あなたのクラスターを、常にGitの状態と同期し続ける「自律的な生き物」に変えてくれます。
まずは小さなPod一つから、このPull型デプロイを試してみてください。その瞬間、インフラとアプリケーションの境界線が消え去る感動を味わえるはずです。
何か詰まったら、いつでも聞いてください。あなたのDevOpsジャーニーを全力で応援しています。それでは、快適なGitOpsライフを！