ClusterAutoscaler(以下CA)を使用していて、NodeのCPUやメモリのリソースは余裕なのに全然スケールインされないなーと思ったら
CAにはスケールインしない条件が色々あるようなので調べてみました。
スケールインしない条件とは？
CAのFAQに記載されていました。
https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md#what-types-of-pods-can-prevent-ca-from-removing-a-node
以下のような条件を持つNodeはスケールイン対象外になります
- 対象Nodeに載っているPodがPodDisruptionBudget(以下PDB)によってEvictされることを制限されている
-
kube-systemnamespace配下のPodが存在してかつ- そのPodはデフォルトで起動しないPodである
- そのPodにPDBが設定されていない、またはPDBの制限が厳しすぎる
- DeploymentやStatefulSetなどのController Objectの管理外のPodが存在している
- localStorageを持つPodが存在している
- リソース不足などでPodがEvictできないとき
- 以下のアノテーション付与されているPodが存在している
"cluster-autoscaler.kubernetes.io/safe-to-evict": "false"
スケールインされないのか試してみる
PDBによってPodがEvictされなかったり、リソース不足が理由の場合は想像つくのでいいとして
それ以外の理由の場合の動作を確かめてみたいので、実際に試してみました。
検証する上での前提条件を記載します。
- 環境はEKS
- Kubernetesのバージョンはv1.21.0
- ClusterAutoscalerのオプションは以下
- ./cluster-autoscaler
- --v=4
- --stderrthreshold=info
- --cloud-provider=aws
- --expander=least-waste
- --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/<YOUR CLUSTER NAME>
kube-system namespace配下のPod
以下のようなPodをkube-systemに配置してみて、スケールインするかやってみます。
すべてのNodeで同じPodを起動させたいので topologySpreadConstraints を指定してます。
apiVersion: apps/v1
kind: Deployment
metadata:
name: test-deployment
namespace: kube-system
spec:
selector:
matchLabels:
app: test
replicas: 3
template:
metadata:
labels:
app: test
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app: test
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
しばらく様子を見てみると、CAのログにこのようなものが出てきました。
Fast evaluation: node ip-xxx-xxx-xxx-xxx.ap-northeast-1.compute.internal cannot be removed: non-daemonset, non-mirrored, non-pdb-assigned kube-system pod present: test-deployment-69f99ff6f7-fj7hs
ということで、kube-system にPodを配置しているとEvictされず、そのPodが載っているNodeがスケールインの対象外となります。
それだと困る場合はCAのオプションに --skip-nodes-with-system-pods=false を追加します。
このオプションを追加しておくことで、kube-system 配下のPodもEvictの対象になります。
Controller Objectの管理外のPod
以下のようなPodを用意します。
apiVersion: v1
kind: Pod
metadata:
name: test-pod
namespace: default
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
しばらく様子を見てみると、CAのログにこのようなものが出てきました。
Fast evaluation: node ip-xxx-xxx-xxx-xxx.ap-northeast-1.compute.internal cannot be removed: default/test-pod is not replicated
ということで、Pod単体で起動してるものはEvictされず、そのPodが載っているNodeはスケールインの対象外になってしまいます。
こういうPodを起動しないよう、Deploymentなどを使用してPodを起動するようにしましょう。
またデバッグの目的でPodを起動させる際も、利用後Podが残らないように気をつけましょう。
localStorageを持つPod
これは emptyDir や hostPath を使用しているPodのことです。
これも試してみます。
以下のようなDeploymentを用意します。
apiVersion: apps/v1
kind: Deployment
metadata:
name: test
namespace: default
spec:
selector:
matchLabels:
app: test
replicas: 3
template:
metadata:
labels:
app: test
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app: test
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
しばらく様子を見てみると、CAのログにこのようなものが出てきました。
Fast evaluation: node ip-xxx-xxx-xxx-xxx.ap-northeast-1.compute.internal cannot be removed: pod with local storage present: test-654ccc4768-8tt7p
ということで、localStorageを持つPodを配置しているとEvictされず、そのPodが載っているNodeがスケールインの対象外となります。
それだと困る場合はCAのオプションに --skip-nodes-with-local-storage=false を追加します。
このオプションを追加しておくことで、localStorageを持つPodもEvictの対象になります。