【Amazon EKS】第五回 EKSをバージョンアップしてみた！
投稿者：高橋慶多
はじめに
こんにちは！ハイブリッドクラウド部の高橋です。
ハイブリッドクラウド部では、Amazon EKSについてのテックブログを投稿しています！
そして今回がEKSシリーズの最終回になります！
前回記事では「Cluster AutoscalerでEKSノードのAuto Scalingを実行する」手順をまとめました。
今回は「EKSをバージョンアップする」手順を解説します。
現在、環境上にver 1.26のEKSクラスターとノードグループがデプロイされているため、
それをver 1.27へアップグレードしていきます。
まずクラスターのバージョンアップ手順、次にノードグループのバージョンアップ手順を解説します。
最後にノードグループ更新時のノードの動きを観察した結果も記載していますので、ぜひご覧ください！
目次
EKSのバージョンアップについて
EKSは数か月に一度、新しいマイナーバージョンがリリースされます。
バージョンアップを行うことで、セキュリティ上のリスク削減や、新機能の導入が可能です。
ユーザーは、EKSの計画的なバージョンアップを実施することが求められています。
古いバージョンのまま利用していると、クラスターは自動的にバージョンアップされます。しかし、ノードグループは自動的にバージョンアップされません。そのためバージョンアップをしないままでいると、クラスターとノードグループ間でバージョン差異が生まれてしまいます。バージョン差異が生まれた場合、Kubernetesコンポーネントの動作に影響を及ぼす可能性があります。クラスターとノードグループ間でバージョン差異が生まれないようにするためにも、計画的に双方のバージョンアップを行うことが重要になります。
また、バージョンアップの留意点として、一度バージョンアップしてしまうと、以前のバージョンにダウングレードすることは不可能なことがあります。
※詳細なEKSバージョンアップの詳細な情報については、下記サイトをご参照ください。
公式：Amazon EKS Kubernetes のバージョン
https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/kubernetes-versions.html#available-versions
バージョンアップ前の確認
先ほど述べた理由から、基本的にはクラスターのバージョンアップ時にノードもバージョンアップすることが推奨されます。
事前に、コントロールプレーンの Kubernetes バージョンと、ノードの Kubernetes バージョンが一致していることを確認します。もしノードのバージョンがコントロールプレーンのバージョンよりも低い場合、コントロールプレーンのバージョンアップをする前に、ノードのバージョンをコントロールプレーンのものに合わせる必要があります。
※クラスターのバージョンによっては追加の確認が必要になる場合があります。詳細は下記の公式サイトからご確認いただけます。
公式：Amazon EKS クラスターの Kubernetes バージョンの更新
https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/update-cluster.html
コントロールプレーンのKubernetesバージョン確認
まず最初に、コントロールプレーンのバージョンを確認します。
kubectl version コマンドを実行します。
[ec2-user@ip-10-0-0-120 ~]$ kubectl version --short
Flag --short has been deprecated, and will be removed in the future. The --short output will become the default.
Client Version: v1.27.1-eks-2f008fe
Kustomize Version: v5.0.1
Server Version: v1.26.11-eks-8cb36c9Server Versionの項目から、コントロールプレーンがv1.26であることが確認できます。
ノードのKubernetesバージョン確認
続いて、ノードのバージョンを確認します。
kubectl get nodes コマンドを実行します。
[ec2-user@ip-10-0-0-120 ~]$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
ip-10-0-20-9.ap-northeast-1.compute.internal Ready <none> 11m v1.26.6-eks-a5565ad
ip-10-0-21-177.ap-northeast-1.compute.internal Ready <none> 11m v1.26.6-eks-a5565ad
ip-10-0-21-180.ap-northeast-1.compute.internal Ready,SchedulingDisabled <none> 11m v1.26.6-eks-a5565adノードのバージョンがv1.26であり、コントロールプレーンと一致していることが確認できました！
クラスターのバージョンアップ
今回は、クラスターのバージョンアップをコンソールから実施します！
バージョンアップしたいクラスターの画面を開くと、Kubernetesバージョンが1.26であることが確認できます。
画面右上の、「Update version」ボタンをクリックします。
バージョンは1.27にアップデートします。
※クラスターはマイナーバージョンを一つずつしかアップデートできません。
クラスターのステータスが「更新中」になります。
クラスターのステータスが「アクティブ」になりました。
Kubernetes バージョンも1.27に更新されていることが確認できます。
今回の場合、20分ほどで完了しました。
実際にkubectl versionコマンドを実行してバージョンが更新されているか確認してみます。
[ec2-user@ip-10-0-0-120 ~]$ kubectl version --short
Flag --short has been deprecated, and will be removed in the future. The --short output will become the default.
Client Version: v1.27.1-eks-2f008fe
Kustomize Version: v5.0.1
Server Version: v1.27.8-eks-8cb36c9Server Versionの項目を見ると、v1.27.8になっていることが確認できます。
EKSにおけるクラスターのバージョンアップ手順は以上になります。
ノードグループのバージョンアップ
バージョンアップ時の動き
今回は、ノードグループのローリングアップデートを実施します。
ローリングアップデートは、ノードを一つずつ順番に更新することでダウンタイムを縮小する更新方法です。
更新時、ノードとポッドがどのような動きをするのか図で説明します。
・バージョンアップ前
クラスター内に v1.26 のノードが二つ存在しています。
・ バージョンアップ開始
v1.27 の新しいノードが二つ作成されます。
片方の古いノードが drain され、ノード上で動いていたポッドが、新しく作成されたノードに移行します。
移行が完了した古いノードは削除されます。
上記の移行が完了するともう片方のノード上のポッドが移行し始めます。
古いノードは削除され、ノードが新しいバージョンにアップデートされます。
ノードグループのバージョンアップ手順
コントロールプレーンのバージョンアップに引き続き、ノードグループのバージョンアップを行っていきます！
バージョンアップしたいノードグループの画面から、画面右上の「今すぐ更新」をクリックします。
更新戦略は「ローリング更新」を選択します。
「更新」をクリックします。
ノードグループのステータスが「更新中」になったことを確認します。
ステータスが「アクティブ」になりました。
Kubernetes バージョンが 1.27 になっていることが確認できます。
今回の構成では、15分ほどで完了しました。
ローリングアップデート時のノードの動きを確認してみた
今回はノードグループをローリングアップデート方式で更新しました。
ノードグループのローリングアップデート中に、ノードがどのような動きをするのかを確認してみました。
まず、ノードグループのバージョンアップ前のノードの状態です。
ノードは v1.26 の10.0.20.171と10.0.21.214の二つが存在しています。
[ec2-user@ip-10-0-0-120 ~]$ kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
ip-10-0-20-171.ap-northeast-1.compute.internal Ready <none> 5m18s v1.26.6-eks-a5565ad 10.0.20.171 <none> Amazon Linux 2 5.10.184-175.749.amzn2.x86_64 containerd://1.6.19
ip-10-0-21-214.ap-northeast-1.compute.internal Ready <none> 5m33s v1.26.6-eks-a5565ad 10.0.21.214 <none> Amazon Linux 2 5.10.184-175.749.amzn2.x86_64 containerd://1.6.19少し待ってみると、v1.27の10.0.20.10と10.0.21.24という新しい二つのノードが作成されました。
[ec2-user@ip-10-0-0-120 ~]$ kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
ip-10-0-20-10.ap-northeast-1.compute.internal Ready <none> 22s v1.27.7-eks-e71965b 10.0.20.10 <none> Amazon Linux 2 5.10.201-191.748.amzn2.x86_64 containerd://1.7.2
ip-10-0-20-171.ap-northeast-1.compute.internal Ready <none> 30m v1.26.6-eks-a5565ad 10.0.20.171 <none> Amazon Linux 2 5.10.184-175.749.amzn2.x86_64 containerd://1.6.19
ip-10-0-21-214.ap-northeast-1.compute.internal Ready <none> 30m v1.26.6-eks-a5565ad 10.0.21.214 <none> Amazon Linux 2 5.10.184-175.749.amzn2.x86_64 containerd://1.6.19
ip-10-0-21-24.ap-northeast-1.compute.internal Ready <none> 22s v1.27.7-eks-e71965b 10.0.21.24 <none> Amazon Linux 2 5.10.201-191.748.amzn2.x86_64 containerd://1.7.2古いノードのステータスが Ready, SchedulingDisabled に、新しいノードのステータスが Ready に変化しました。
古いノードは一つずつ drain され、新しいノードにポッドを移行します。
[ec2-user@ip-10-0-0-120 ~]$ kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
ip-10-0-20-10.ap-northeast-1.compute.internal Ready <none> 4m27s v1.27.7-eks-e71965b 10.0.20.10 <none> Amazon Linux 2 5.10.201-191.748.amzn2.x86_64 containerd://1.7.2
ip-10-0-20-171.ap-northeast-1.compute.internal Ready,SchedulingDisabled <none> 34m v1.26.6-eks-a5565ad 10.0.20.171 <none> Amazon Linux 2 5.10.184-175.749.amzn2.x86_64 containerd://1.6.19
ip-10-0-21-214.ap-northeast-1.compute.internal Ready,SchedulingDisabled <none> 34m v1.26.6-eks-a5565ad 10.0.21.214 <none> Amazon Linux 2 5.10.184-175.749.amzn2.x86_64 containerd://1.6.19
ip-10-0-21-24.ap-northeast-1.compute.internal Ready <none> 4m27s v1.27.7-eks-e71965b 10.0.21.24 <none> Amazon Linux 2 5.10.201-191.748.amzn2.x86_64 containerd://1.7.210.0.20.171のノードが削除されました。
したがって、この段階で 10.0.20.171 のノード上にあったポッドは全て移行が完了しています。
[ec2-user@ip-10-0-0-120 ~]$ kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
ip-10-0-20-10.ap-northeast-1.compute.internal Ready <none> 6m50s v1.27.7-eks-e71965b 10.0.20.10 <none> Amazon Linux 2 5.10.201-191.748.amzn2.x86_64 containerd://1.7.2
ip-10-0-21-214.ap-northeast-1.compute.internal Ready,SchedulingDisabled <none> 36m v1.26.6-eks-a5565ad 10.0.21.214 <none> Amazon Linux 2 5.10.184-175.749.amzn2.x86_64 containerd://1.6.19
ip-10-0-21-24.ap-northeast-1.compute.internal Ready <none> 6m50s v1.27.7-eks-e71965b 10.0.21.24 <none> Amazon Linux 2 5.10.201-191.748.amzn2.x86_64 containerd://1.7.210.0.21.214のノードも削除されました。
ポッドが全て新しいノードに移行しました。
[ec2-user@ip-10-0-0-120 ~]$ kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
ip-10-0-20-10.ap-northeast-1.compute.internal Ready <none> 8m16s v1.27.7-eks-e71965b 10.0.20.10 <none> Amazon Linux 2 5.10.201-191.748.amzn2.x86_64 containerd://1.7.2
ip-10-0-21-24.ap-northeast-1.compute.internal Ready <none> 8m16s v1.27.7-eks-e71965b 10.0.21.24 <none> Amazon Linux 2 5.10.201-191.748.amzn2.x86_64 containerd://1.7.2以上の動きを経て、ノードグループのバージョンが v1.26 から v1.27 に更新されました！
まとめ
今回は、「EKSをバージョンアップする」手順をまとめました。
- クラスターのバージョンアップ
- ノードグループのバージョンアップ
これらのステップにより、EKSをバージョンアップすることが出来ました。この記事が皆さまのEKSの設定に役立つ一助となれば幸いです。この機会に、皆さまもぜひEKSを触ってみてください！
Amazon EKSに関する記事は、本稿が最後になります。
みなさん、お楽しみいただけたでしょうか。今後もAmazon EKS以外の記事も投稿していく予定なので楽しみにお待ちください！
AWS社とのAWSソリューションプロバイダープログラム契約を結び、AWSのアカウントの手配から設計、環境構築、システム運用までワンストップのソリューションを提供いたします。
コンテナ技術には特に力を入れており、Amazon EKSだけでなく、Red Hat OpenShiftのソリューションもございます。
OpenShiftのソリューションページや、運用ソリューションであるNI+C Multicloud MSPの紹介ページもありますので、一読していただけますと幸いです。
