会社でオンプレKubernetesクラスタを構築する前にすること

はじめに

　私は最近、オンプレ Kubernetes クラスタの構築・運用を担当することになった会社員です。これまでは仕事内容を考えたときにKubernetesクラスタの導入はその規模・難易度・コストから避けていましたが、ある目的で導入することになりました。
　オンプレKubernetesの構築事例は調べた限り少なく、構築も非常に難易度の高い作業だったので、構築前に検討したほうがいいことをノウハウとして共有したいと思い記事にしました¹。

オンプレKubernetes構築前にすること

　社内でオンプレKubernetesを導入することになったとします。担当者としてすることは概ね以下のとおりです。

• IPアドレスを確保する²
• クラスタの規模を決定する
• インストールするプラグインを選定する

IPアドレスを確保する

　社内でオンプレKubernetesを構築する場合に一番ハードルとなるのは最初にするIPアドレスの確保になるでしょう。自宅でKubernetesを構築する場合はあまり問題にはなりませんが、社内で構築する場合は状況が大きく異なります。Kubernetesで利用するIPアドレスの範囲であるCIDRが社内で利用しているものと競合すると、該当するネットワーク間の通信が成立しなくなるためです³。

　自分や自分の部署がIPアドレスを管理しているなら割り当てやすいですが、別部署だった場合は担当者と交渉して割り当ててもらいます。次のクラスタの規模を考えるときにも影響するので、なるべく広い範囲のCIDRを割り当てるようにします⁴。

　新規で割当が難しそうならKubernetesやその上で動作するアプリケーションを利用する対象者やシステムを洗い出してその場所、組織などで利用されていないCIDRをKubernetesで利用します。つまり、それ以外の利用者やシステムからのアクセスは想定しない、という前提で設計します⁵。

　このような譲歩案を出しつつ、もしクラスタの規模がわかっているのであればそれに合わせたサブネットマスクを提示して交渉します。IPアドレスさえ割り当ててもらえればここで紹介する一番の難関は終了です。

クラスタの規模を決定する

　クラスタの規模の決定とIPアドレスの確保は同時に作業するようにしますが、注意点としては割り当てられたIPアドレスにクラスタの規模が律速されるということです。ここでは例として 10.0.0.0/16 のIPアドレスを確保できたとします。

　まずは構築するクラスタをマルチクラスタにするのかシングルクラスタにするのか決め、マルチクラスタの場合はいくつクラスタを作るのかを決定します。なぜかというとマルチクラスタの場合も各クラスタのCIDRが競合してはいけないからです。例えばクラスタを２つ構築する場合は10.0.0.0/16を10.0.0.0/17と10.0.128.0/17に分割してそれぞれのクラスタに割り当てます⁶ 。このようにマルチクラスタであればその数によって一つのクラスタで利用できるCIDRが狭まります。

　各クラスタに割り当てるCIDRが決まったら次はクラスタを構成するノードの数を決定します。私の場合はkubeletのmaxPodsのデフォルト値から逆算して決めました⁷。maxPodsはノードあたりに起動できるPodの数のことでデフォルト値は110となっています⁸。この数からノードで割り当てられるPodのCIDRは/25となります⁹。ということは256がノードの最大数になります。全部割り当てるとServiceで利用するIPアドレスがなくなるので半分にするとして最大で128のノードでクラスタを構築することにします。そうすると10.0.0.0/17を利用しているクラスタでは10.0.0.0/18をPodに割り当てて、残りの10.0.64.0/18をServiceに割り当てることとなります。
　今回の例の場合はまとめると以下になります。

クラスタの数	2
1クラスタあたりのノードの数(Max)	256台
1クラスタあたり起動できるPodの数(Max)	28,160

	クラスタA	クラスタB
Pod CIDR	10.0.0.0/18	10.0.128.0/18
Service CIDR	10.0.64.0/18	10.0.192.0/18

インストールするプラグインを選定する

　Kubernetesでは様々なプラグインをインストールして目的にあったクラスタを構築していきます。基本的にはOSSを利用することになりますが、ここでポイントとしてインストールするOSSは最小限であるようにします。Kubernetesクラスタの保守運用を専門とするチームが存在しているならいいですが、そうではなく数人のチームで、しかも全員が他の業務の片手間である場合、管理するOSSは少ないほうが望ましいです。また、Kubernetesのマイナーアップデートは相当早いです。Kubernetes上で構築したシステムに影響がないか検証する時間を確保するためにもプラグインは少なくしておいたほうがよいです。
　kubeadmで構築する場合はまずCNIプラグインとCSIプラグインを選定することになります。CNIプラグインでおすすめなのはCiliumでしょう。これ一つで多くのネットワーク要件をCilium単体でカバーできるため、非常に便利です¹⁰。CSIプラグインはRookをおすすめします。Cephという分散ストレージが簡単に利用できるので冗長性が確保されている上、S3互換ストレージも利用できます¹¹。

最後に

　オンプレKubernetesクラスタの構築でネットワーク周りは見落としがちなので今回記事にしました。会社でオンプレKubernetesクラスタを構築することになった人の一助になれば幸いです。

1. おそらくオンプレKubernetesについて一番詳しいのはサイボウズだと思います。 ↩

2. 私が検証したのはIPv4なのでIPv4前提で話を進めます。 ↩

3. これはKubernetesに限った話ではなく、DockerやVMでも発生します。また専用回線でAKSやEKSを利用する場合も発生する場合があります。 ↩

4. なるべく広い範囲とはいえクラスタ構築の目的や利用するであろう人数、将来の見通しからある程度構築するクラスタの規模感については見積もりをしておきます。 ↩

5. 好ましい手段ではないのであくまで最終手段と捉えてください。 ↩

6. 競合していなければ良いので10.0.0.0/18、10.0.64.0/18、10.0.128.0/17の分け方も可能です。 ↩

7. https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/ ↩

8. この数は変更可能です。 ↩

9. /25では128のIPアドレスが利用できるためです。 ↩

10. https://isovalent.com/blog/post/migrating-from-metallb-to-cilium/ ↩

11. ただしデフォルトのレプリカ数が2なのでデータサイズの3倍のストレージ容量を要求します。 ↩