kubernetesクラスタはDHCPは利用せずstatic ipで作成すべし

件名以上のことはなく、まあ普通の感性ならそうするよね、ということしかない

grugrut.hatenablog.jp

で作ったクラスタだが、残念ながらOS再起動時にぶっこわれてしまった。
手抜きしてDHCPでやっていたら、etcdやらapiserverやらが、元のIPアドレスに探しにいってしまい、必要コンポーネントがまるで起動しない。

ログをみてみると、
```
Jul 3 18:30:56 master01 kubelet[1437]: E0703 18:30:56.729641 1437 controller.go:115] failed to ensure node lease exists, will retry in 7s, error: Get https://lb01.mshome.net:6443/apis/coordination.k8s.io/v1beta1/namespaces/kube-node-lease/leases/master01.mshome.net?timeout=10s: dial tcp: lookup lb01.mshome.net on 192.168.217.225:53: read udp 192.168.217.233:46188->192.168.217.225:53: i/o timeout
```
みたいな感じで古いIPアドレス(192.168.217.233)を使おうとしているのがわかる。

/etc/kubernetes/manifests/etcd.yaml とかを見ると確かにIPアドレスがベタ書きされてるので、修正してみたけども状況あまりかわらず。
ホスト名解決で失敗しているので、coreDNSがあやしいのだけど。

いずれにしても、ipかわるたびにもろもろ修正するの手間でしかないので、static ipで作り直すことにする。
クラスタを構成するノードの情報がどこに、どのように格納されているかは気になるので、正しく動いたらおさえておきたいね。

そもそもDHCPでもいっか、て判断したのが、ドキュメントに
```
It is not recommended to use an IP address directly in a cloud environment.
```
とあったので、クラウドだとたしかにIP制御できないし、ホスト名で解決できる環境ならいいんだなって判断してしまったのだけど、これLoadBalancerの条件だったので、誤読ですね。

やっぱminikubeとかマネージドに頼らない自前クラスタ組んでみると、いろいろ予期せぬところではまって興味深いです