CNDT2021、クラスター運用自動化をGitOps的に行う方法論をサイバーエージェントのエンジニアが解説

CNDT2021からサイバーエージェントの青山昌也氏による「Kubernetesのアップデートとクラスターに対する細かな設定変更をどのように行うか？」を解説したセッションを紹介する。タイトルは「Kubernetesエコシステムのバージョン追従と柔軟な管理への挑戦」というものだ。

このセッションではサイバーエージェントが社内向けに開発したKubernetes-as-a-ServiceであるAKE（Adtech Kubernetes Engine）と称されているプラットフォームに対して、インフラストラクチャーのアップデートと構成情報をGitで一元管理するGitOpsを実践する形でサイバーエージェントが経験した知見を共有する内容となっている。

動画：Kubernetesエコシステムのバージョン追従と柔軟な管理への挑戦

なおセッションで使用したスライドは以下から参照できる。

スライド：Kubernetesエコシステムのバージョン追従と柔軟な管理への挑戦

プレゼンテーションを行う青山氏

このセッションは、ユーザー目線でKubernetesのプラットフォーム側をクラウドネイティブにするためのチャレンジに関する解説と言っても良いだろう。「ユーザー目線」という意味はツールを開発するベンダーやコミュニティではなく、あくまでもツールを使う側としてArgo CDをContinuous Deliveryのためのツールとして選択した上での工夫を公開しているからだ。KustomizeやHelm、そしてArgo CDの拡張機能を使いながら、GitOpsとしては微妙な使い方を紹介しているのが興味深い。

Kubernetesを利用する上での悩みを紹介

Kubernetes自体が頻繁に更新され、ここではエコシステムと称されている関連するツールなども拡大し続けていることから、アップグレードは確認なども含めて工数がかかること、関連ツール自体の管理にも注意を払う必要があることなどを挙げて説明した。問題点として、一度完成したシステムを更新せずに塩漬けにして使い続けるケースなどを指摘している。つまりアプリケーション自体はクラウドネイティブなモノとして更新頻度を上げて開発から実装までの速度を加速したとしても、インフラストラクチャー自体は安定を指向するがゆえに固定化してしまっていると指摘している。

サイバーエージェントが理想とするGitOpsの解説

ここでGitOpsの定義を確認した上で「構成情報を格納するマニフェストをどうやって管理するのか」というポイントと、「サイバーエージェントのニーズに合わせて自動調整を行うエージェントをどのように稼働させるのか」、以上2つのトピックを前後半に分けて解説することを説明した。

マニフェストの管理

Kubernetesのマニフェスト自動更新の理想の姿とは

GitOpsの前半、つまり「（Kubernetesが利用する構成情報である）マニフェストをどうやって管理するべきか」に関する理想とする姿は、構成情報を格納するリポジトリーに対して変更を記述したプルリクエストを送ることで、Kubernetes本体とツール群に対して自動でアップデートするリクエストが生成されて実行されるというものを目指していることを説明した。

ArgoCDにおけるマニフェスト管理の方法を解説

その上でArgo CDを前提としてどのようにYAMLファイルが更新管理できるか？ の解説に移った。ここでは生のYAMLファイルによる管理、Kustomizeを使った管理、Helmチャートによる管理を挙げて、変更の起点となるGitHubから最新のリリースを取り込んで、それぞれの管理方法ごとの概要を解説した。その上で任意のバージョンに依存したモジュールをどうやってコード化するのかなどの問題点にも触れて解説を行った。

AKEで複数のクラスターをGitOps的に管理する方法を解説

構成情報から自動的にクラスターを配備

ここから後半の、「GitOpsでコード化された構成情報をどうやって自動的にクラスターの配備に応用するのか？」という部分の解説に移った。

AKEにおけるクラスター管理の必須要件

Kubernetes-as-a-Serviceを実装する上で必須となる要件として、「複数のクラスターを管理できること」「各クラスターに対して任意のバージョンのKubernetesを構成できること」「各クラスターについてツールなどに対してON/OFFを切り替えられること」の3点を挙げた。運用管理する側として、なるべくマニュアルでのコマンド投入などをせずにGitOps的にコードの修正によってクラスターの作成から構成の変更、ツールの実装などが行えることが望ましいことを前提にして、Argo CDでどこまでできるのか？ を解説する内容となっている。

そしてインフラストラクチャー担当が運用する管理クラスターと、社内のデベロッパーが利用するユーザークラスターに分けて解説。管理クラスターについては、Gitリポジトリーのディレクトリー構造に沿ってCert-managerやExternal-DNSなどが定義されることを説明した。

ユーザークラスターに対するエコシステムの管理方法は2種類

ユーザークラスターについてはユーザークラスター自体に配備される場合と、ユーザークラスターを管理するために管理クラスターに配備される形の2種類が必要となることを説明した。

自作コントローラーを使ってクラスターを配備

Argo CDを使って複数のクラスターを配備するコマンドを例に挙げて登録を行う場合と、サイバーエージェントが開発したコントローラーを使ってCluster APIの利用するCRDを監視することでKubernetesのReconciliation Loopを回す方法を解説。

ここではApplicationというカスタムリソースを使って、クラスターに対して任意のツール（例えばPrometheusなど）をインストールするケース、ユーザークラスターを運用するためのツールを管理クラスターにインストールするケースなどを解説した。

Applicationリソースを使ってApplication自体を管理する方法

またApplicationリソースを使ってApplicationを管理する方法、App of App Patternについても解説したが、そもそも複数のクラスターに対してGitOps的に柔軟なApplicationの設定を行うことが難しいという本音を漏らしているところが興味深い。このトピックに関するスライドには「この構成がGitOpsか否かはここでは取り扱いません」とコメントが書かれているように、すべてをConfigリポジトリーに対するコードの変更だけで行うことには無理があると感じていることの現れだろう。

Argo CDのApplicationSetとGeneratorを解説

続いて、Argo CDが持つ機能であるApplicationSetとGeneratorをベースに、構成情報を動的に生成する方法について解説を解説した。

ここからは複数のKubernetesのバージョンをそれぞれのクラスターにおいて利用するための方法の解説に移った。そしてそのためには、組織として周期が速いKubernetesのアップデートを利用するための戦略が必要であるとして、サイバーエージェントにおけるリリースごとのConfigリポジトリーの作り方、タグを使った自動更新の組み込み方の解説を行った。

構成情報をカスタマイズしたい時にどうやって変数を渡すのか？ を考察

リポジトリー戦略に続いて3つ目の要件「アドオンやアプリケーションのON/OFFの設定を自在に行いたい」の解説に移り、変数を渡すことで設定を変更できるとしてその方法を解説した。KustomizeとHelmにおいて変数を渡す方法による長所・短所を考察し、加えてArgo CDの変数を利用する機能についても解説した。

Argo CDで構成情報の中に変数を使う方法

最後にまとめとして、アプリケーションだけではなくインフラストラクチャーに相当するKubernetesのコア部分とここではエコシステムと呼ばれる拡張機能にあたるツール群についても、クラウドネイティブらしく自動化を行おうと呼びかけている。ここで紹介されたように構成情報をオーバーレイやテンプレートから内容を変えつつ生成するような方法論がGitOpsと呼べるのかどうかについては議論があるだろうと語る。その上で原理に拘るのではなく、運用担当の負担を軽減できるツールを使いながらも可読性を維持した上で効率化、自動化を目指すことを解説してセッションを終えた。

どこまでGitOpsの原則に従うべきかは悩ましい問題

サイバーエージェントにとっても、どこまでGitOpsに沿いながらも自動化を実装するのかについては悩ましい問題であるということが垣間見えたセッションとなった。