kubernetesちょっと別でこの手で実際に触れる機会あって感覚的に慣れた気になったので、自分でも手の中でkubernetsクラスタをお試ししてみたくなった。環境の当ては、半年くらい前購入したintelベアボーン XCY J1900、当初からもう一台追加購入して、OSは4月にubuntu20.04を入れなおしていた。CPU速くもないし、ハードは癖があるし*1、ただ最低必要なリソースには多分なんとか足りてるので、これでトライ。
そのkubernetes伏線の際に目を通した本二冊。
O'Reilly Japan - 入門 Kubernetes
O'Reilly Japan - Kubernetesで実践するクラウドネイティブDevOps
以前もminikubeで、web-serverのpodのサンプルとか動かしてみても、クラスタを動かした実感はなかった。kubernetesをVPSで試すのは費用対満足予測面でやるきがおきなかった。*2。最近レガシーツールを一つpodとしてdeployさせる機会あって*3、自前コンテナを動かしてみたらstatusがcrashloopbackoffとかになって進まないなどとか、尻に火が付いた状態になると、色々と書き物とかにある情報が頭の中で実際につながってくれるようになった。
今回自分環境で到達したのは、
kubernetsで作業リソースの分散が効いてくれるのかの初歩を見てみる程度の達成度。
4CPU 8Gメモリ・OS ubuntu20.04２台に対して、片方一台をコントローラ相当・両方をノードとして動かしてみる。
以下ページを起点として読みつないでいくと、なんちゃって２台構成クラスタできた気がします。
kubeadmを使用したシングルコントロールプレーンクラスターの作成 | Kubernetes
この単純な構築条件下に対しては、ほとんど必要なことが書いてあって*4今回やったこととしての補足は以下なところ。
$ kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml
ここの部分は、一度別にkubernetesクラスタ触って勘が効いたところ。Podネットワークアドオンがそれ自身podで構成されているというのかな、というのをコマンドを見て感じ取った。kubectr get podでstatusはrunningになるのだけど、restartカウントが上がっていくのでうまくないと判断できて、それで179,9099のポートを開けてみた。
これでもって、２台とも作業ノードとして動いてくれるはず。一応、リソース量(メモリ)による配置先ノードの選択動作をみることができた。具体的にこの例で少しresourceとか追記してみて試してみた。
XCY J1900って癖のある(怪しい？)HWで、kubeadmのインストール | Kubernetesでproduct_uuidがユニークであることを見ておけよ、っとあったのだけども、うちのこの２台は同じ（テキトーな）product_uuidを返してきた。BIOSで変えられるのか見てみたけどもダメだった。物理ポートのMACアドレスはすべてちゃんと違ってたのでそのままやってみたらとりあえず今のところうまくいっていそう。（リソース量を見てちゃんと狙ったnodeにdeployとかしてる感じ、２台の間だけだけども)
最後）
CloudNative DevOps with Kubernetesの書籍では「まずはマネージドサービスから」って記述がありました。kubernetesは極めて複雑なことを取り扱っていて適切な管理を行っていくということを理解していけるようになるのはコストが必要、といった趣旨のことが書かれてる節がありました。
スケールさせる必要性の低いレガシーツール程度を動かす場合はそれを乗せようとする従来のオンプレミスサーバ（あるいはそれをクラウドに配備する）の管理量もそれに相応する分で収まりまりそうな推測ができます。kubernetesはスケール可能な分、そのインフラの管理負担も大きくなる可能性がありますよ、ってことを書いてあるのだと思います。
kubernetesのマネージドサービスについて、数例紹介されていて、課金方法とか、提供される操作方法とか、いろいろいわゆる差別要素があるのだと思いました。見方のひとつとしては、クラスタ環境をよくしていく側面でも想像力を掻き立てられる部分ありと。ビジネス側面だと単にkubeクラスタが使える、というだけでは物足りなさそう。