🦋
ArgoCDとKubernetesで実現するマルチリージョン- CDパイプライン構築 -
はじめに
近年のクラウドネイティブな開発において、継続的デリバリー（CD）は不可欠な要素となっています。
その中でも、ArgoCDはKubernetes向けの強力なCDツールとして注目を集めています。
本記事では、ArgoCDを使用してマルチリージョンでのCDパイプラインを構築する方法を、実践的な手順とともに解説します。
ArgoCDとは
ArgoCDは、Kubernetes向けの宣言的なGitOpsツールです。GitリポジトリをSingle Source of Truthとして使用し、アプリケーションの望ましい状態を自動的に同期・維持します。
ArgoCDのメリット
1. GitOpsの実践
ArgoCDは、GitOpsの原則に基づいて設計されています。
- インフラのコード化（IaC）: すべての設定がGitで管理され、透明性が確保されます。
- 変更履歴の追跡: いつ、誰が、何を変更したのかが明確になります。
- 宣言的な構成管理: 望ましい状態を宣言するだけで、ArgoCDが自動的に調整します。
2. デプロイの自動化
効率的なデプロイプロセスを実現します。
- 継続的デリバリー: Gitリポジトリの変更を自動的に検知し、デプロイします。
- 自動同期と自己修復: クラスターの状態が期待される状態から逸脱した場合、自動的に修正します。
- 簡単なロールバック: 以前のバージョンへの切り戻しが容易です。
3. マルチ環境管理の一元化
複数の環境を効率的に管理できます。
- 環境差分の可視化: 各環境の設定の違いが明確になります。
- 標準化されたプロモーション: 開発→テスト→本番環境への展開が統一されます。
- きめ細かな権限管理: 環境ごとに適切なアクセス制御が可能です。
なぜArgoCDを選ぶのか
1. シンプルなアーキテクチャ
- Kubernetes上で動作する軽量なコンポーネント
- 追加のCI/CDツールが不要
- 直感的なWeb UIを提供
2. 高い信頼性
- 状態の継続的な監視と自動修復
- 堅牢なセキュリティ機能
3. 柔軟な拡張性
- カスタムツールとの統合が容易
- 様々なKubernetesリソースに対応
- マルチクラスター管理のサポート
本記事では、これらの特徴を活かしながら、実際のマルチリージョンCDパイプラインを構築していきます。初心者の方でも理解しやすいよう、各ステップを詳細に解説し、発生し得る問題とその解決方法も含めて説明していきます。
前提事項
今回使用するのは、前回と同じくAWS Network FIrewallのルール作成自動化アプリです。
[1] ArgoCDでの自動デプロイ手順
1. 環境準備
# minikubeの起動
minikube start --cpus=2 --memory=2048
# クラスターの状態確認
kubectl cluster-info
2. GitHubリポジトリの準備
2-1. SSHキーの生成
# SSHキーペアを生成
ssh-keygen -t ed25519 -C "argocd" -f ~/.ssh/argocd-key
# 公開キーの表示（これをGitHubに登録）
cat ~/.ssh/argocd-key.pub
# 秘密キーの表示（これをArgoCDに登録）
cat ~/.ssh/argocd-key
2-2. GitHubでの設定
- リポジトリの"Settings" → "Deploy keys"へ移動
- "Add deploy key"をクリック
- 生成した公開キー（argocd-key.pub）を貼り付け
- "Allow write access"にチェック（必要な場合）
- "Add key"をクリック
3. ArgoCDのインストール
# ArgoCDのネームスペース作成
kubectl create namespace argocd
# ArgoCDのインストール
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
# Podの起動確認
kubectl get pods -n argocd -w
4. ArgoCDの認証設定
4-1. SSHキーの登録
# 秘密キーをKubernetesシークレットとして登録
kubectl create secret generic argocd-repo-secret \
--namespace argocd \
--from-file=sshPrivateKey=~/.ssh/argocd-key \
--from-literal=url=git@github.com:your-username/your-repo.git
4-2. 接続テスト用のコマンド
# ArgoCDのRepo Serverポッドを特定
kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-repo-server
# 接続テスト（Podの名前を適宜変更）
kubectl exec -it -n argocd argocd-repo-server-xxxxx -- ssh -T git@github.com
5. ArgoCDへの接続設定
# ポートフォワーディング（別ターミナルで実行）
kubectl port-forward svc/argocd-server -n argocd 8080:443
# 初期パスワードの取得
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
6. アプリケーションのデプロイ
6-1. ArgoCDのログイン
- https://localhost:8080 にアクセス
- ユーザー名: admin
- パスワード: 上記コマンドで取得
7. 同期設定
7-1. 手動同期
画面中央に6つのアプリケーションが表示されていた。
- fw-transfer-tokyo-prod
- fw-transfer-tokyo-nonprod
- fw-transfer-singapore-prod
- fw-transfer-singapore-nonprod
- fw-transfer-virginia-prod
- fw-transfer-virginia-nonprod
ArgoCDの状態が以下であるため、正しくCDパイプラインが動作している。
- 全アプリケーションがHealthy
- 全環境でSynced状態
8. 変更のテスト
8-1. レプリカ数、環境変数、リソース制限の変更
# マニフェストファイルを編集
vi kubernetes/overlays/singapore/nonprod/deployment.yaml
# replicas: 1 → replicas: 2 に変更
# value: "1.0.1" に変更
# limits: memory: "512Mi"
8-2. 変更をGitHubにPUSH
vi .gitignore
# argocd-key, argocd-key.pubを追記
git add .
git commit -m "Update replicas to 2"
git push origin main
8-3. 変更の確認
# Podの状態を確認
kubectl get pods -n singapore-nonprod
[2] Kubernetesアプリケーションのデプロイ【マルチリージョン】
1. トラブルシューティング
1-1. minikubeが起動できない。
minikubeを完全リセットすると解決。
kubectl port-forward svc/fw-transfer-service -n tokyo-nonprod 8501:80
Error:
Unable to connect to the server: net/http: TLS handshake timeout
# 既存のminikubeが応答しないので停止
minikube stop --alsologtostderr -v=8
# Docker Desktopでminikubeコンテナを強制停止・削除 (GUIで実行）
# 既存のプロファイルで再起動
minikube start --driver=docker --kubernetes-version=v1.32.0 --cpus=2 --memory=2048 --cache-images=true
1-2. kubectlのコンテキストの問題
# コンテキストの更新
minikube update-context
🎉 「minikube」コンテキストが更新されて、127.0.0.1:62876 を指すようになりました
💗 現在のコンテキストは「minikube」です
# 確認
kubectl config current-context
minikube
kubectl cluster-info
1-3. ArgoCDのPodの問題
# Podの状態確認
kubectl get pods -n argocd
2.【原因】リソース不足によるもの
(前提) 初期状態の問題
- メモリ使用率が高い（97%）
- 多数のPodがTerminating状態
- イメージプル失敗（ErrImageNeverPull）
kubectl describe node minikube
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource Requests Limits
-------- -------- ------
cpu 2250m (56%) 2800m (70%)
memory 3824Mi (97%) 7508Mi (191%)
ephemeral-storage 0 (0%) 0 (0%)
hugepages-2Mi 0 (0%) 0 (0%)
2-1. クリーンアップ作業
# 全てのTerminating Podを確認
kubectl get pods --all-namespaces | grep Terminating
# ArgoCD Podの強制削除
kubectl delete pod argocd-application-controller-0 -n argocd --force
kubectl delete pod argocd-server-59d65996f9-6d7bt -n argocd --force
kubectl delete pod argocd-repo-server-6bfbff446d-9265g -n argocd --force
# アプリケーションPodの強制削除
kubectl delete pod fw-transfer-app-797d8647b9-k477s -n singapore-nonprod --force
kubectl delete pod fw-transfer-app-f7d6665b8-4pdzs -n singapore-nonprod --force
# 他のPodも同様に削除
2-2. リソース最適化
# レプリカ数を1に減らして負荷軽減
kubectl scale deployment fw-transfer-app --replicas=1 -n tokyo-nonprod
kubectl scale deployment fw-transfer-app --replicas=1 -n tokyo-prod
kubectl scale deployment fw-transfer-app --replicas=1 -n singapore-nonprod
kubectl scale deployment fw-transfer-app --replicas=1 -n singapore-prod
kubectl scale deployment fw-transfer-app --replicas=1 -n virginia-nonprod
kubectl scale deployment fw-transfer-app --replicas=1 -n virginia-prod
# deployment.apps/fw-transfer-app scaled であればOK.
2-3. イメージプル問題の解決
# base/deployment.yamlの修正
spec:
template:
spec:
containers:
- name: fw-transfer
image: fw-transfer:latest # v3からlatestに変更
imagePullPolicy: Never
変更したら、GitHubにコードをPUSHすること。
# イメージの確認
docker images | grep fw-transfer
# minikubeのDockerデーモンにイメージをロード
minikube image load fw-transfer:latest
# minikubeでのイメージロード確認
minikube ssh "docker images | grep fw-transfer"
fw-transfer latest ed806e553981 7 days ago 521MB
# 全てのデプロイメントを再起動
kubectl rollout restart deployment -n tokyo-nonprod fw-transfer-app
kubectl rollout restart deployment -n tokyo-prod fw-transfer-app
kubectl rollout restart deployment -n singapore-nonprod fw-transfer-app
kubectl rollout restart deployment -n singapore-prod fw-transfer-app
kubectl rollout restart deployment -n virginia-nonprod fw-transfer-app
kubectl rollout restart deployment -n virginia-prod fw-transfer-app
2-4. ArgoCDのサービス設定確認
# ArgoCDのポートフォワーディング
kubectl port-forward svc/argocd-server -n argocd 8080:443
2-5. アプリケーションのサービス設定と動作確認
# 各環境のポートフォワーディング
kubectl port-forward svc/fw-transfer-service -n tokyo-nonprod 8501:80
kubectl port-forward svc/fw-transfer-service -n tokyo-prod 8502:80
kubectl port-forward svc/fw-transfer-service -n singapore-nonprod 8503:80
kubectl port-forward svc/fw-transfer-service -n singapore-prod 8504:80
kubectl port-forward svc/fw-transfer-service -n virginia-nonprod 8505:80
kubectl port-forward svc/fw-transfer-service -n virginia-prod 8506:80
2-6. 状態確認
# クラスター全体の状態
kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
argocd argocd-application-controller-0 1/1 Running 0 4m34s
argocd argocd-applicationset-controller-7d9b86f479-6l795 1/1 Running 0 13m
argocd argocd-dex-server-d6f5dc5ff-bd5rx 1/1 Running 0 13m
(省略)
# リソース使用状況
kubectl top nodes
kubectl top pods --all-namespaces
# 特定の問題のあるPodの詳細
kubectl describe pod <pod-name> -n <namespace>
# ArgoCDのPod状態確認
kubectl get pods -n argocd
NAME READY STATUS RESTARTS AGE
argocd-application-controller-0 1/1 Running 0 4m59s
argocd-applicationset-controller-7d9b86f479-6l795 1/1 Running 0 14m
argocd-dex-server-d6f5dc5ff-bd5rx 1/1 Running 0 14m
argocd-notifications-controller-67997f9f4b-28c57 1/1 Running 0 14m
argocd-redis-85986699b9-mbqnh 1/1 Running 0 14m
argocd-repo-server-6bfbff446d-v8xlz 1/1 Running 0 14m
argocd-server-59d65996f9-cpnvd 1/1 Running 0 14m
# 各環境のPod確認
kubectl get pods -n tokyo-nonprod
NAME READY STATUS RESTARTS AGE
fw-transfer-app-678c69f846-hcfws 1/1 Running 0 99m
fw-transfer-app-678c69f846-hpnw9 1/1 Running 0 125m
kubectl get pods -n tokyo-prod
NAME READY STATUS RESTARTS AGE
fw-transfer-app-5dcc44c8b4-fwl64 1/1 Running 0 31m
fw-transfer-app-5dcc44c8b4-fzqrc 1/1 Running 0 40m
kubectl get pods -n singapore-nonprod
NAME READY STATUS RESTARTS AGE
fw-transfer-app-f7d6665b8-gfrlb 1/1 Running 0 101m
fw-transfer-app-f7d6665b8-hfgzw 1/1 Running 0 111m
kubectl get pods -n singapore-prod
NAME READY STATUS RESTARTS AGE
fw-transfer-app-8ff868468-8mndt 1/1 Running 0 111m
fw-transfer-app-8ff868468-tkpnp 1/1 Running 0 102m
kubectl get pods -n virginia-nonprod
NAME READY STATUS RESTARTS AGE
fw-transfer-app-7b7cbdd5d5-2ttbz 1/1 Running 0 112m
fw-transfer-app-7b7cbdd5d5-b5vm4 1/1 Running 0 102m
kubectl get pods -n virginia-prod
NAME READY STATUS RESTARTS AGE
fw-transfer-app-7c6c77f9bf-9j84n 1/1 Running 0 112m
fw-transfer-app-7c6c77f9bf-q5bkj 1/1 Running 0 103m
3.【動作確認】
3-1. ArgoCD の自動デプロイ
3-2. Kubernetesの各環境のアプリケーション
ポート番号ごとにわかれている。
(例) Tokyo/NonProd
4.【結論】リソース管理は大事
システムを安定した状態に回復できた。
無事、安定したマルチリージョンにおける、Kubernetesアプリケーションの運用が可能となった。
Discussion