orangeitems’s diary

クラウドではたらくエンジニアの日々の感想です。

Kubernetesは良くできている①

f:id:orangeitems:20181020000813j:plain

 

Kubernetesが仕事に降りかかる

Kubernetesがついに仕事に降りかかってきて集中的に勉強しているのですが、触れば触るほどすごい技術であることがようやくわかりました。パブリッククラウド勢がこぞって採用するのもよくわかります。これまでの物理サーバーや仮想サーバーを中心にした、伝統的な構成は今後の開発現場において少しずつ衰え、コンテナでの開発が中心になるのは間違いないと思いました。これはついていかないとマズいレベルで、完成度がものすごく高くて少しショックです。

 

普及へのカギ

普及のボトルネックは決定版のGUIがないことです。全部GUIになったらきっと爆発的に広まるでしょう。VMwareの圧倒的な使いやすさは、vSphere Clientがリードしました。今はWeb化で苦労していますが何しろGUIが標準であること。Kubernetesはまだコマンドベースです。多数のコマンドやyaml形式のファイルなど学習の敷居はまだ高いです。しかし、GUIができるのももう時間の問題だと思います。今まさに誰かが一生懸命作ってたりするのでしょう。

Windows95の前のMS-DOS(Windows 3.1はあったけど)の状況が今に近く、近未来に、完全GUIのKubernetesが市場を席巻しそうです。

 

何がすごいか

まだ勉強中の身なのでKubernetesのすべてを味わっていないこともあり今日のタイトルは①としました。

・永続ストレージと、プログラムを実行するコンテナが分離しているため、コンテナごとのデータの同期を考えなくてもいい。

・ロードバランサー、冗長化、スケールアウトの概念が実行環境に取り込まれているので、実装する必要がなく構築工数が削減できる。

・開発者PCローカルのDockerと、クラウドのKubernetesがネイティブにリンクしている。開発者が任意のタイミングでクラウド側にアップロードし実行状態まで持っていける。

・アップロードしたコンテナに問題があった場合、前の版にすぐ戻せる。

・1つのコンテナを複製して、複数のノードで動かすことができる。かつそれらはすべて同じプログラムであることが保証され差分の心配がない。コンテナの大元を変更すれば複製も同時に反映される。

・コンテナの中で使っている通信ポートの番号は、公開するときに別の番号で公開できる(ロードバランサーのVirtual Serverのような原理)。

・コンテナは、クラウドベンダーでロックインしない。例えばGCPで動かしたコンテナは、AmazonでもAzureでもIBMでも動く。オンプレのKubernetesでも動く。

とりあえず触っただけでもその破壊力は十分にわかったので、あとはどうやって、監視やバックアップの最適化をするかを確立していきたいな、と思います。

また、もっと具体的に、上記にない良さが見つかっていきそうですので、まとまったら②を書きたいと思います。

 

インフラの仕事は無くなるか

Kubernetesをこのまま触り続けて、オンプレ構築や普通のVM+OS構築みたいな仕事が減っていったとして。じゃあKubernetesがあるからインフラのことを知らなくていいかというと全く逆で、Kubernetes自体はインフラの事柄が満載です。おそらく、開発者にそのまま開放してしまうと、インフラ面からいろんなトラブルが待っていそうな気がしています。

・デプロイされたコンテナが多すぎて、ワーカーノードのリソースがひっ迫する。古いバージョンが溜まっていく。

・デプロイしたがうまく動かないという開発者への問題切り分け

・ワーカーノード不足になり全体障害発生

・永続ストレージの容量不足

・勝手コンテナが増殖しすぎてわけが分からなくなる

・kubectl get servicesと入力したら、数百行表示されて萎える(本当に全部動いているのか?)

VMware上の勝手VMの整理や、Amazon EC2のクラウド上のOSの増殖など、やはり運用管理の手を入れないと、無駄なリソースが発生したり、不意にトラブルに発展しかねません。これまでの運用上のガバナンスはコンテナ時代になっても必要だと思いました。

Kubernetesに特化した運用プラクティスがそろそろ出てくるとは思うのですが、まずはインフラが詳しい人が環境をリードしないと、無法地帯になりかねないと思いひとまずは知識を深めていきたいと思います。

 

Kubernetes完全ガイド (impress top gear)