概要
EKSクラスタをv1.14からv1.15にバージョンアップする検証を開発環境で行なった際にハマったことを紹介します。
バージョンアップ手順は基本的にAWSから提供されている以下の公式ドキュメントにしたがって実施しました。
Amazon EKS クラスターの Kubernetes バージョンの更新
環境情報として、ワーカーノードタイプはマネージド型、コンピューティングタイプはEC2です。
ノードグループ更新時にエラー発生
上記のリンク内の手順の13を見ると、マネージド型ノードグループの更新へのリンクがあるため、これに従ってAWSのマネジメントコンソールからノードグループを更新したところ、以下のようなエラーが発生しました。
エラーコードに PodEvictionFailure とあることから、既存のノードから新しいバージョンのノードにpodを移動する際の排出処理に失敗したのだろう、ということがわかります。
PodDisruptionBudget設定時のpod排出時の挙動
podの排出処理に関わる設定なので、PodDisruptionBudgetにあたりをつけて検証しました。
PodDisruptionBudgetはノードからpodを排出する際、最低限確保したいpod数を保証する設定値です。
関連していそうな当該環境の設定値は以下の通りです。
この設定値は開発環境のものであるため、コスト重視でpod数は控えめに設定しています。
| オブジェクト種別 | 設定項目 | 設定値 |
|---|---|---|
| HorizontalPodAutoscaler | maxReplicas | 2 |
| HorizontalPodAutoscaler | minReplicas | 1 |
| PodDisruptionBudget | minAvailable | 1 |
| Deployment | strategy | rollingUpdate |
| Deployment | strategy.rollingUpdate.maxSurge | 1 |
| Deployment | strategy.rollingUpdate.maxUnavailable | 0 |
この設定でpodの排出時に以下のような挙動になることを期待しました。
期待した挙動（実際にはならなかった）
1.更新前のノードに1podが起動中、更新後ノードが起動
2.更新前ノードのpodが起動したまま、更新後ノードに新規podが起動
3.更新前ノードのpodが停止
しかし実際にはこのような挙動にはならず、上述のエラーが発生しました。
（エラーになるまで1時間半程度かかったので、すごく徒労感を感じました。）
PodDisruptionBudgetのminAvailableはpodの最低数を保証するもので、保証できなければそのままエラーで排出処理を停止する、という挙動になりました。決してpodの数を保証するためにスケールアウトしたりはしないようです。
事前にpod数を増やして再度実行
podの排出が可能な余白を作ってあげれば良さそうなので、minReplicasを1から2に増やして再度実行しました。
設定値としては以下のようになります。赤字箇所が変更点です。
| オブジェクト種別 | 設定項目 | 設定値 |
|---|---|---|
| HorizontalPodAutoscaler | maxReplicas | 2 |
| HorizontalPodAutoscaler | minReplicas | 2 |
| PodDisruptionBudget | minAvailable | 1 |
| Deployment | strategy | rollingUpdate |
| Deployment | strategy.rollingUpdate.maxSurge | 1 |
| Deployment | strategy.rollingUpdate.maxUnavailable | 0 |
期待した挙動（実際にそうなった）
この設定をいれて再度ワーカーノードを更新しました。
期待した挙動としては以下のようになります。
1.pod数を2にして再実行
2.PodDisruptionBudgetで指定した1podを残して排出
3.更新後ノードでpodが起動したら残りのpodを排出
上記の通り、正常にpodが排出され、ワーカーノードのバージョンを更新することができました。
最後に
PodDisruptionBudgetは普段の運用の中ではあまり意識することなかったのですが、今回の作業で詳しい挙動を知るいい機会になりました。