Googleのエンタープライズ向けソリューションAnthosの中で、私が特に魅力的だと感じている機能のひとつが Anthos Config Management(ACM)です。Gitリポジトリを用意して複数のクラスタを接続するだけで、構成が標準化され、GitOpsの流儀でドリフトを防げます。さまざまなホスティング拠点で数百〜数千のクラスタを運用する大規模エンタープライズにとっては、特に価値の大きい仕組みです。
Argo CDで自動化するKubernetesマルチクラスタ構成
このACMに着想を得て、別のGitOpsツールである Argo CD で同等の仕組みを再現できないか試してみました。結果は期待どおりで、Gitリポジトリ上の構成ファイルを変更すると、両方のクラスタにシームレスに反映されました。
アーキテクチャ概要
セットアップ
シンプルに進めるため、Google Cloudのマネージド KubernetesサービスであるGKE上に、East / Westを想定して2つのリージョンにクラスタを1つずつ作成しました。もちろん、Argo CDはどこにあるクラスタにもインストールでき、Gitリポジトリにアクセスできれば問題ありません。
すべてをブートストラップするために以下のシェルスクリプトを用意しましたが、本番環境では可能な限りTerraformでインフラを管理することをおすすめします。
ブートストラップ済みクラスタ
8〜10分ほどで両方のクラスタがアクティブになり、Argo CDのworkloadsもデプロイされました。
EastリージョンとWestリージョンのKubernetesクラスタ
各クラスタにデプロイされたArgo CD
App of Apps
このセットアップのポイントは、各クラスタにArgo CDをインストールする際、App of Appsパターンを使ってGitHubリポジトリを参照する初期Applicationを併せて構成している点です。これにより、後から好きな数の構成をリポジトリに追加でき、クラスタやデプロイするアプリも柔軟にカスタマイズできます。
自動同期(automated sync)はあくまで任意の設定です。クラスタ数が膨大になる場合は、自己修復とドリフト管理のために有効化することをおすすめします。ただし、auto-syncには欠点もあり、ロールバック機能が使えなくなる点には注意が必要です。
applications/フォルダ(パス)には、現時点でk8s-config.yamlというアプリが1つだけ含まれており、これがさらに別のArgoアプリとして、Kubernetes構成が置かれた別フォルダを参照する形になっています。
k8s-config/フォルダ(パス)には、Kubernetesクラスタに適用したいYAMLファイルがすべて入っています。整理したいファイルが多い場合は、構成を再帰的に適用するアプリを宣言することもできます。
ソースコードリポジトリ
今回の検証では、GitHubに mikesparr/multi-cluster-argo-demo というソースコードリポジトリを公開しています。ディレクトリ構成は以下のとおりです。
ソースコードリポジトリの構造
この例ではすべてを単一のリポジトリにまとめていますが、リポジトリを分けてチームごとに編集権限を付与し、関心事を分離することもできます。
Argo UI
コマンドラインからargo-serverサービスにポートフォワードします。
kubectl -n argocd port-forward svc/argo-server 8080:443
ブラウザで http://localhost:8080 にアクセスし、セキュリティ警告が表示されたら例外として許可してください(httpsではありません)。ヒント:デフォルトでは、ユーザー名adminと、argocdサーバーPodのフルネームでログインします。
argocd-server-XXXXXXXをコピーし、デフォルトパスワードとして使用
同期されるまでは、applications(app of apps)のみが表示されます
App of Apps(applications)が同期されると、最初のアプリk8s-configが認識されます。
両方のアプリケーションが同期された状態
k8s-configアプリのパネルをクリックすると、サーバーにインストールされたリソースを詳細に確認できます。
リポジトリの/k8s-configディレクトリにあるYAMLファイルがすべてサーバーに適用されます
クラスタ構成の確認
kubectlのコンテキストを各クラスタに切り替え、test-namespaceのnamespaces、serviceaccounts、roles、rolebindingsを確認してみてください。両方のクラスタにすべてインストールされているはずです。お疲れさまでした!
Gitリポジトリからworkloadsが自動でインストールされたクラスタ
動画デモ
GitHubリポジトリからNginx Podを追加し、複数クラスタへ自動デプロイするライブデモ
無限の可能性
たとえば、スタックにAPIゲートウェイを追加したいとして、CRDとYAMLで構成するAmbassadorやKongを選んだとします。フォルダかリポジトリを追加し、applications/フォルダ内にアプリのYAMLを1つ置くだけで、ArgoCDが自動的にインストールと構成を行ってくれます。
エンジニアリングチームが公開するアプリケーションごとに、DeploymentマニフェストのDockerイメージのバージョンを編集してプルリクエストを作成すれば、人によるレビューと職務分掌が自然に組み込まれた運用になります。PRがマージされれば、Argo CDが該当のクラスタと環境にデプロイします。
別のユースケースとしては、マルチクラウドデプロイをサポートしつつDNSでトラフィックを分散させ、真のアクティブ・アクティブ構成を実現する方法も考えられます。さらに、あるクラウドから別のクラウドへの移行にも応用できます。
今後もさまざまな可能性を試していくのが楽しみです。複数環境にまたがるクラスタ構成を同期するもうひとつのアプローチとして、本記事を楽しんでいただけたら幸いです。
クリーンアップ
本記事のスクリプトやリポジトリをご利用いただいた場合は、不要な課金を避けるため、リソースの削除を忘れずに行ってください。最も簡単な方法は、以下のコマンドでクラスタを削除することです(またはプロジェクトごと削除します)。
gcloud container clusters delete west --zone us-west2-b
gcloud container clusters delete east --zone us-east1-c