【TECH BLOG #52】Jenkins（EKS）のバージョンアップ

こんにちは
グリーエンターテインメント株式会社のエンジニアマネージャーのYSです。

弊社で運営しているプロダクトでは、「Amazon ElasticKubernetes Serveice (EKS)」を使用しているものがあります。APIサーバーだけでなく、開発に使用しているJenkinsもEKS上に構築しています。EKSを利用している場合、避けては通れないものとして、EKSのバージョンアップ対応があります。今回はこの「Jenkins（EKS）のバージョンアップ対応」について紹介します。

EKSのバージョンアップ概要

まず最初にEKSのバージョンアップの概要についてです。AWSからの案内の抜粋ですが、下記のようになっています。

・基本的に4ヶ月に1度、マイナーバージョンアップがある
・リリース後、14ヶ月間が標準サポート対象となる
・標準サポート終了日を過ぎたバージョンは、自動的に次の 12 か月間の延長サポートに入る
・・延長サポートでは、クラスター時間あたりの追加料金で、所定の Kubernetes バージョンをより長く使用することができる
・・Kubernetes バージョンの延長サポートは現在プレビュー中であり、プレビュー期間中は追加料金は発生しない
・・延長サポート期間が終了する前にクラスターを更新しなかった場合、クラスターは現在サポートされている最も古い延長バージョンに自動的にアップグレードされる

また、現在（2023年10月末）の標準サポートされているバージョンは「1.23 〜 1.28」となっています。

今回の対象システム

今回お話するシステムは、ある運営中のプロダクトの開発環境になります。

EKS
開発環境で使用しているEKSのバージョンは「1.21」となっていました。プロダクトの開発中に一度バージョンアップは実施しているのですが、マイナーバージョンアップの期間が4ヶ月ごとかつ、開発のフェーズもローンチに近づくにつれてバージョンアップのための時間を割けずにいたために、標準サポート対象外という状態になってしまっていました。
ちなみに、「1.21」の標準サポート終了は「2023/02/15」のようなので、現在は延長サポートという扱いになっているのかと思いましたが、公式の記述では現在延長サポートとなっているバージョンは「1.23」のみのようです。

Jenkins
Jenkinsについては、helmfileを用いて管理しています。
Jenkinsのdockerイメージは「jenkins/jenkins:2.319.3-slim」を使用しており、helm charttは「jenkins/jenkins」の「2.3.0」を使用していました。

バージョンアップ方針

EKSのバージョンアップはAWSのコンソール上から、「in-place」方式でバージョンアップすることができます。お手軽ではあるのですが、

・1つずつしかバージョンを上げられない
・切り戻し不可

といったデメリットもあります。
何かあった場合は開発が止まってしまうので、今回は下記のように実施していきます。

・新規で「1.24」のクラスタを作成し、そこにJenkins / API pod等を構築
・動作確認完了後、「in-place」方式でバージョンを上げていく
・その後、Route53で稼働中の開発環境と切り替える

最初から、もっと新しいバージョンのEKSクラスタを作成すれば？という声も聞こえてきそうですが、「in-place」方式でのバージョンアップを実施してみたいという思いもあり、このような手順で実施しようと思います。

Jenkinsの更新

「1.24」のEKSクラスタ作成後、既存のJenkinsのhelmfileを適用したところエラーが出たので対応していきます。

Error: Failed to render chart: exit status 1: Error: unable to build kubernetes objects from release manifest: unable to recognize “”: no matches for kind “Ingress” in version “networking.k8s.io/v1beta1”

Jenkinsのhelm chartで使用しているIngressのapiVersionが「networking.k8s.io/v1beta1」になっているのですが、このバージョンは「1.24」のEKSバージョンでは廃止になっているために、Jenkinsのhelm chartのバージョンを上げます。公式ドキュメントを見ると、「3.1.0」から対応されているようなので、Jenkinsのhelm chartはこのバージョンを使用することにします。「2.3.0」から「3.1.0」へのメジャーバージョンアップなので、合わせて公式ドキュメントに2系からのマイグレーション方法が記載されているので、そこを参考にyamlファイルを更新していきます。これらの対応で、「1.24」のEKSクラスタで無事Jenkinsのpodは立ち上がりました。

API Podの更新

つづいて、API用のpodを立ち上げていきます。こちらは一つのEKSクラスタ内に「dev1」「dev2」というように開発環境毎にnamespaceを作成し、それぞれpodを立ち上げています。この辺りはkustomizeで管理しているのですが、今回は特に変更することなく既存の設定ファイルそのままで起動することができたので、特段書くようなことはなかったです。

in-placeでバージョンアップしてみる

新しく立ち上げた「1.24」のクラスタでの動作確認が済んだので、AWSコンソール上から「1.25」にバージョンアップしてみます。

※キャプチャとり忘れていてバージョン違います

更新自体は10分ほどで完了しました。

この更新でクラスタのバージョンアップが完了しました。このバージョンアップはコントロールプレーンのバージョンアップなので、他にノードのバージョンアップも必要なので実施していきます。
※コントロールプレーンとノードのバージョンが違っていても動作はしますが、当然といえば当然ですが揃えておくのが推奨されています。

ノードのバージョンアップもAWSコンソールから実施していきます。

更新すると、新規にノードが起動し、新ノード上にpod等が立ち上がります。

その他 / Tips

これでひとまず、バージョンアップは完了したのですが、残った課題やtipsがあるので紹介していこうと思います。

in-placeでの更新後のhelmchart

Jenkinsのhelmfilechartですが、記載した通りapplyしたのはEKSのバージョンが「1.24」の時にapplyしています。その後、in-placeで「1.25」以降に上げた後に同じ設定でapplyすると、apiVersion周りのエラーが発生しました。これからわかることはin-placeで正常に動作したからといって、使用していた設定ファイルがそのまま使用できるわけではないようです。そのため、今後修正をする必要がありそうです。

Jenkinsのjobのビルドバージョン

Jenkinsのjobのビルドバージョンですが、アプリビルド時に使用していたりすることがあると思います。その場合、Jenkinsを再構築した際にビルドバージョンがリセットされると、アプリのビルドバージョンも巻き戻ってしまい不都合が出る時があると思います。下記コマンドをJenkisのスクリプトコンソールで実行すると、ビルドバージョンを任意のものに変更できるので、アプリビルド等のjobに関しては旧Jenkinsでのビルドバージョンを引き継ぐ形で更新しておくとよさそうです。

※ 「YourJobName」という名称のjobのビルドバージョンを1000にする

まとめ

Jenkinsが止まると、開発が止まってしまうので、新しくEKSクラスタを構築して動作確認した後に切り替えることでEKSのバージョンアップを実施しました。基本、in-placeで問題なくバージョンアップできることは確認できたのですが、新たにapplyした場合はエラーになってしまうことがあることもわかりましたので、設定ファイルの更新は随時必要そうです。今回の対応で、古いバージョンのEKSクラスタが残っている状態ですので、そこを今後のバージョンアップの検証環境として、使っていくといいかもしれないと思いました。システムを運営している限りは、各種ソフトウェアのバージョンアップ対応は避けて通れないものですので、検証をしやすい環境であったり、手法についてはこれからも検討を続けていきたいと思います。

以上、最後まで読んでいただきありがとうございました。