Cluster Autoscalerを使うなら、ノードグループはAZごとに作る
遭遇した問題
Topology Spread Constraintsを設定したPodに対してCluster Autoscalerがノードのスケールを「させない」判断を下すことがあった。その結果PodがPendingのまま配置されないことがあった。
アプリケーション開発チームがリリースを行なった際、DeploymentのRollingUpdateによりPodが増加したが、そのPodが配置されないままになったことで発見された。
（当該Deploymentには対応するHorizontal Pod Autoscalerも存在していたので、そちら経由のPod増加で発生する可能性もあったが、その前に原因を取り除けたため発生を回避した）
原因
ノードグループが複数のアベイラビリティゾーンにまたがるように設定されていた（複数のゾーンのサブネットが割り当てられていた）。
Cluster Autoscalerを利用する場合、ノードグループはAZごとに作ることが推奨されていた。
ノードグループはAZ単位で作成することを推奨する公式Doc
To allow CA to take advantage of topological scheduling, use separate node groups per zone. This way CA knows exactly which node group will create nodes in the required zone rather than relying on the cloud provider choosing a zone for a new node in a multi-zone node group. When using separate node groups per zone, the
--balance-similar-node-groupsflag will keep nodes balanced across zones for workloads that dont require topological scheduling.
We recommend that you configure multiple node groups, scope each group to a single Availability Zone, and enable the
--balance-similar-node-groupsfeature. If you only create one node group, scope that node group to span over more than one Availability Zone.
ページの頭の方にはcan still consist of more than one Availability Zone or instance type.と書いてあるので紛らわしい（複数AZにまたがるノードグループを作れるのは本当なので嘘は言っていない）。
どうしてノードグループが複数AZまたぐとスケールしなくなるのか
- 前提）ノードグループが複数AZにまたがる＝各ノードの
topology.kubernetes.io/zoneの値には複数のパターンがありえる - CAが「どのノードグループを増やせばPodが置けるようになるかな？」と考えるときに、ノードグループごとに1台だけがサンプルとして取り上げられ、ラベル等の情報が記憶される
- ここで以下の諸条件がマッチしてしまう
- ノードグループは
ap-northeast-1aとap-northeast-1cにまたがっている - Podは
ap-northeast-1aへの配置を求めている - 「ノードグループごとに1台」取り上げられたノードは
ap-northeast-1cだった
- ノードグループは
- ここで以下の諸条件がマッチしてしまう
- Podが求める条件に合うノードが無いと誤解し、スケールしないという判断になる
詳細は以下のIssue作成者により解説されている。
Discussion