こんにちは、サーバーサイドエンジニアのT.Tanakaです。
私はサーバーサイドの開発エンジニアとして働いていましたが、経験の幅を広げられるようにサーバーサイドの開発エンジニアからローテーションでプラットフォーム運用部に異動する取り組みがあり、その一環で現在はプラットフォーム運用部でCLOMOのリリース作業やシステム監視機能の改善やエスカレーション調査を実施しています。
今回はそのプラットフォーム運用部で2021年4月に実施した「Azure Kubernetes Service v1.19 Upgradeプロジェクト」についてお話をさせていただきたいと思います。
プロジェクト発足の経緯とバージョンアップ方法の選択肢
本プロジェクトが発足した経緯はCLOMOの運用に利用しているAzure Kubernetes Service(以下、「AKS」といいます)を当時最新のv1.19系にアップグレードするというものでした。
このとき、AKSのバージョンアップ方法は２つの案から検討していました。
- ① AKSのクラスターアップデート機能を利用する。（自動でバッファノードを追加し順次ノードをアップグレードする機能）
- ② 最新バージョンのAKSクラスター環境を再構築し、DNSの切り替えにより新環境に切り替える。
通常はAKSにアップデートを任せることができる①の方法を採用しますが、今回は以下の理由により②の方法を採用しました。
- 今回のアップデートにより、Kubernetesの設定(deployment等)に修正が必要。
- AKSクラスターを新規作成することで以下の設定が可能となる。
- 1ノードで起動できる最大pod数を増加。リソースをあまり必要としないpodをこれまでより凝集することができ、ノード数を減らしコスト削減が可能。
- 利用できるノードが1種類に固定されていた状況から、複数種類のノードを混在させることが可能となる。リソース消費の大きいpod用に専用のノードを用意する等の対応が可能となる。
- Spinnaker等のAKSに関わるツールのアップグレードも現行環境に影響を与えずアップグレード・検証が可能となる。
Spinnakerのアップグレード
CLOMOが利用するAKSのデプロイにはSpinnakerを利用しています。SpinnakerはNetflix社が開発したCD(Continuous Delivery)ツールであり、弊社ではAKS上にCLOMOのサーバーサイドアプリケーションをデプロイするために利用しています。GUIでKubernetesのデプロイが可能となるため、Kubernetesの習熟度に関わらずデプロイが可能となり、CUIツールに比べてもデプロイミスが起きにくい状況ではないかと恩恵を感じています。
このSpinnakerについても最新バージョンにアップグレードする予定でしたが、Kubernetesデプロイ機能に大きな変更点があることがわかりました。
Kubernetes V1 Provider から V2 Provider への変更
これまで利用していたV1 Provider形式がSpinnaker 1.21で削除され、最新版にアップグレードするためには新たなV2 Provider形式に対応する必要があることがわかりました。それぞれの特徴は以下となります。
V1 Provider形式
- SpinnakerのWebUI上にKubernetesデプロイに必要な設定値を入力しておく。入力値はデプロイ設定に必要な主要な設定値をSpinnaker側で定義しており、Kubernetesのyaml定義と比べると設定できない値も存在する。
- SpinnakerのWebUI上にKubernetesデプロイに必要な設定値を入力しておく。入力値はデプロイ設定に必要な主要な設定値をSpinnaker側で定義しており、Kubernetesのyaml定義と比べると設定できない値も存在する。
V2 Provider形式
- Kubernetesのyaml形式のテキストをSpinnaker上やGitHub上で管理し、それをもとにデプロイする。yamlにプレースホルダを指定しGUI上でパラメータをデプロイ時に入力することも可能。後述するKustomize等のツールにも対応している。
- Kubernetesのyaml形式のテキストをSpinnaker上やGitHub上で管理し、それをもとにデプロイする。yamlにプレースホルダを指定しGUI上でパラメータをデプロイ時に入力することも可能。後述するKustomize等のツールにも対応している。
既にSpinnaker V1 Providerでは入力ができない値をkubectlで変更して運用をしている箇所がある状況もあり、GitHub上でのyamlでの管理が可能なV2 Provider形式に変更することにしました。
GitHub上でファイルを管理するようにしたため、変更履歴も追えるようになり、また、Spinnakerが無くてもyamlを直接kubectlを使用してデプロイすることも可能となったため、デプロイがSpinnakerに強く依存している状況も解消することができました。
一方でDockerイメージのタグ等のデプロイのタイミングで指定が必要なパラメータはGUIから指定できるように設定し、現在もGUIによる恩恵を享受した環境でデプロイを実施しています。
Kustomizeの導入
KustomizeはKubernetesのyamlファイルの環境（開発・試験・本番環境など）毎の差分を効率よく管理することを可能にしてくれるツールです。CLOMOの動作する環境も用途に応じて少なくない数の環境があり、yamlファイルを効率よく管理したいと考えていました。そこで、Spinnaker V2 ProviderはKustomizeに対応していることがわかり、利用することにしました。
本番環境の設定をbaseとし、その他の環境の設定ファイルは本番環境との差分のみを記述しています。環境毎の設定の把握が容易となり、設定変更も実施しやすい状況になったと感じています。
まとめ＆感想
今回、AKSやSpinnakerをアップグレードすることで、ノード数減少によるコスト削減やSpinnaker V2 Provider&Kustomize導入による運用効率の向上が実現できました。 また、私個人としてもCLOMOが動作する規模のAKSクラスターの構築に関わるという貴重な経験ができました。基本的にはyamlベースでの設定でありますが、設定の内容を確認しながら環境構築を実施することで、また深くCLOMOの環境を知ることができました。
初となるAKSクラスターとSpinnakerサーバーの構築ということで、当然多くのことにハマり、いくつかの不具合も出してしまいました。その度に色々なメンバーのご協力があり、プロジェクトを無事完了することができました。
今後もAKSの最新バージョンへの追随はもちろんのこと、今回のSpinnakerやKustomizeのように関連ツールで良いものがあればアップグレード＆導入をしていきたいと思います。
さいごに、私達は一緒に働く仲間を募集しています！
