HelmでGitLab Runnerを導入する際にレプリカ数は指定できるが、どのノードで上がるかや分散させるかなどの冗長化に関する直接的な設定項目はない。
そのため、同一ノードで起動することも考えられ、冗長化観点からは嬉しくない。
ここでは、podAntiAffinityを利用してGitLab Runnerを別々のノードであげるように設定する。
なお、Kubernetesの1.18以降だとPodを分散してあげるにはtopologySpreadConstraintsを使うとよいのだが、まだGitLab RunnerのChartには実装されていないため利用できない。
Add support for topologySpreadConstraints
設定と確認
Helmのvaluesでaffinityの設定項目があるので、こちらを利用して分散させる。
values.yamlに以下を記載する。
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- gitlab-runner-test
topologyKey: kubernetes.io/hostname
podAntiAffinityにおける各項目の意味は以下となる。
-
requiredDuringSchedulingIgnoredDuringExecution：ルールを満たさない場合、Podをスケジュールしない。なお、ルールを満たさなくてもPodをスケジュールしたい場合はpreferredDuringSchedulingIgnoredDuringExecutionを指定する。 -
labelSelector：対象Podのラベル。helmでデプロイする際、helmがapp=<リリース名>というラベルを付与するので、予定しているリリース名を指定する。 -
topologyKey：対象ノードのラベル。今回はノード間で分散したいためkubernetes.io/hostnameとした。EKSでAZで分散したいとかならtopology.kubernetes.io/zoneを指定する
AntiAffinityルールの場合、該当するPodが存在したらデプロイしない。topologyKeyにノードを指定しているため、これにより同一ノードへのデプロイが行われなくなる。
また、values.yamlにレプリカ数も設定する。現在4ノードで動いているため、ノード数+1で定義して、1Podだけ起動できないことを確認する。
replicas: 5
これを使ってRunnerをインストールする。
helm install -n gitlab gitlab-runner-test gitlab/gitlab-runner -f ./runner-values.yaml
インストール後に分散していること、5つ目のPodがAntiAffinityにより起動できないことが分かる。
$ kubectl get pod -n gitlab -o wide -l app=gitlab-runner-test
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
gitlab-runner-test-8bd6cdbb6-7nfsr 1/1 Running 0 102s 192.168.75.200 ip-192-168-77-42.ec2.internal <none> <none>
gitlab-runner-test-8bd6cdbb6-95ddb 1/1 Running 0 102s 192.168.69.222 ip-192-168-79-93.ec2.internal <none> <none>
gitlab-runner-test-8bd6cdbb6-jxtt8 1/1 Running 0 102s 192.168.108.218 ip-192-168-98-54.ec2.internal <none> <none>
gitlab-runner-test-8bd6cdbb6-pcqtr 0/1 Pending 0 102s <none> <none> <none> <none>
gitlab-runner-test-8bd6cdbb6-sdlf5 1/1 Running 0 102s 192.168.110.244 ip-192-168-97-139.ec2.internal <none> <none>