GitLab Agent for Kubernetes (KAS): Push型デプロイの呪縛から脱却し、真のGitOpsへ到達せよ
かつて、我々はCI/CDパイプラインの中で `kubectl` を叩き、クラスターの認証情報を環境変数に埋め込み、ファイアウォールを突破するために血眼になっていた。だが、それはもう過去の遺物だ。
GitLab Agent for Kubernetes (KAS) を導入した瞬間、君のパイプラインから「デプロイ用クレデンシャル」という名の時限爆弾は消滅する。今回は、単なる導入ガイドではない。現場で運用し、泥沼を経験した者だけが知る「GitOpsの極致」を共有する。
—
1. なぜ「Agent」なのか？ —— Push型の限界を超えて
従来のPush型（CIジョブからクラスターを操作する方式）には致命的な欠陥がある。
- セキュリティ: クラスターの認証情報（Kubeconfig）をGitLabのCI変数で管理する必要がある（漏洩のリスク）。
- ネットワーク: クラスターに対して外部からアクセスを許可しなければならない（攻撃面が増える）。
- 状態の乖離: 手動で `kubectl edit` した変更がCIの状態と食い違い、次のデプロイで競合する。
KASは Pull型 だ。クラスター内部に常駐するエージェントが、GitLabサーバーへ「逆方向に」接続を確立し、リポジトリの状態をクラスターへ同期し続ける。外部からのインバウンドアクセスは不要。これぞ真のGitOpsである。
—
2. 構築の「勘所」：Agent設定のベストプラクティス
Agentの構成ファイルは `.gitlab/agents/
.gitlab/agents/my-cluster-agent/config.yaml
gitops:
manifest_projects:
- id: path/to/your/manifest-repo # マニフェストリポジトリを指定
default_namespace: production # デフォルトのネームスペース
paths:
- glob: ‘apps/prod//.yaml’ # 監視対象を限定して同期負荷を低減
- glob: ‘base/.yaml’
flux_configuration:
# Flux V2連携を有効化する場合の記述
# 大規模環境ではここを使いこなすと非常に強力
現場で震えるほど役立つTips
- `paths` の厳格化: プロジェクト全体を監視対象にするな。必ずディレクトリを絞れ。同期対象を限定することで、意図しないリソースの削除や誤った同期を防げる。
- 名前空間の分離: チームごとにエージェントを分けるか、`default_namespace` を適切に設定せよ。
—
3. 実践：チームの生産性を加速する「GitOpsフロー」
KASを導入したら、以下のようなディレクトリ構成を推奨する。
.
├── base/ # 全環境共通の定義（Base）
├── overlays/
│ ├── prod/ # 本番環境固有のパッチ
│ └── staging/ # ステージング環境固有のパッチ
└── apps/
└── my-web-app/
└── kustomization.yaml # Kustomizeで環境ごとの差分を吸収
チーム開発のルール：マージ戦略
1. Direct Commit禁止: マニフェストは必ずMR（Merge Request）を通すこと。
2. CODEOWNERSの活用: `infra/` 以下の変更には必ずテックリードの承認を必須にする。
3. 自動化のフック: GitLab CIで `kube-linter` や `polaris` を実行し、マニフェストがベストプラクティスから外れていないかをMR段階で弾く。
—
4. プロのための隠れたハック＆生産性向上ツール
開発を劇的に速くするコマンドショートカット
`.bashrc` または `.zshrc` に以下のエイリアスを仕込め。
Agentのステータス確認を瞬時に行う
alias kget-agent=’kubectl get pods -n gitlab-kubernetes-agent’
alias klogs-agent=’kubectl logs -n gitlab-kubernetes-agent -l app=agentk -f’
GitLabへの現在の認証情報を確認
alias gl-ctx=’glab auth status’
導入すべき神プラグイン（VS Code）
- [Kubernetes](https://marketplace.visualstudio.com/items?itemName=ms-kubernetes-tools.vscode-kubernetes-tools): 言わずもがな。Agent経由のデプロイ状況をGUIで追える。
- [GitLens](https://marketplace.visualstudio.com/items?itemName=eamodio.gitlens): GitOpsでは「誰が・いつ・なぜその設定を変えたか」の追跡がすべて。必須。
- [YAML (Red Hat)](https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml): K8sのスキーマ定義を読み込ませることで、YAMLの記述ミスをタイピング中に検知せよ。
—
5. 最後に：テックリードからの提言
GitOpsへの移行は、単なるツールの入れ替えではない。「クラスターの状態」を「Gitのコミット履歴」という信頼できる情報源（Single Source of Truth）に委ねるという思想への転換だ。
最初はPush型から移行することに恐怖を感じるかもしれない。だが、一度KASによる「自動追従」の体験をしてしまえば、二度と手動で `kubectl apply` を叩く世界には戻れないはずだ。
君たちのチームが、デプロイの恐怖から解放され、価値ある機能開発に集中できる環境を構築できることを期待している。もし構築中に詰まったら、まずは `agentk` のログを追え。答えは必ずそこにある。
—
次回のトピック: 「GitLab RunnerのオートスケーリングをK8s上で極限まで最適化する：スポットインスタンスを賢く使い倒すテクニック」について深掘りする予定だ。期待していてくれ。