Kubernetesはいいぞ

さて、ここ最近いわゆるラーメン代稼ぎとしてインフラ関連のお仕事をいただいている中、Kubernetes(K8S)をなんとか使えるレベルにまでなってきたのでVMwareや一般的なベアメタルインフラを触ってきたエンジニアの視点でメモを書いてみる。

高い学習コスト

K8Sの世界は、極めて高度な抽象化がされているため、まずK8S固有の概念(Pod,service,ingress,persistent volume etc..)を理解した上で手を動かす事が必要になってくる。

基本的に、インフラレイヤとして意識するのはdockerより上位の層が中心となってくるためlow-levelでの理解はむしろ足枷にしかならず、K8Sの美味しい部分をいかに普段のインフラ構築運用上の課題解決に取り込めるかの観点で学習するのがモチベーションを維持する意味でも良いのではないかと思う。

Yamlを乗りこなせ

 K8Sでは、構成に関する全てをyamlマニフェストに定義（宣言）し、オブジェクトの作成やスケールアウトの定義までファイルとして宣言しなければならない。

このyamlをkubectlコマンドに渡して、作成、更新を繰り返していく事になる。　

例えば、ingressコントローラをインストールしたい場合、最低でもingress本体、設定(configmap)、Role、default backendのpod作成などに必要な複数のyamlファイルが必要になる。

ただ、yamlに関してはyumのような依存性を解決してくれるパッケージマネージャーのようなhelmというものがあり、これを活用する事でyaml地獄から幾らかの負担低減にはなるだろう。

Scale out/Rollingupdateが素晴らしい

宣言的インフラの意味するところ、yamlマニフェストに最小Pod（コンテナの単位）や最大Podを記述しておけば、クラスタの総リソース内で自動的にPodのScale out/inが行われる。

そして、Deploymentとして作成したPod定義のコンテナイメージのtagを書き換えれば、全Podのイメージが自動的にRollingupdateして最終的に指定通りのコンテナイメージがdeployされる。

頻繁にdeployが繰り返されるCI/CDのトレンドと最高の組み合わせではないだろうか。

まとめ

私は、Google Cloud Platformが用意するマネージドK8SであるGKEで概念を学んだが、さすがにGKE自体が純度の高いK8S環境なので、オンプレK8S環境でもGKEとほとんど変わらない感覚で操作することができた。ただ、LoadBalancer周りはクラウドプロバイダごとに固有の違いがあるので、この点だけは留意しておきたい。
総じて、K8S自体の学習コスト自体は高いものの、これからはK8Sがコンテナオーケストレーションの主流になることはもはや疑いもなく、クラウドに関わるエンジニアであれば是非とも触ってみてほしい。