orangeitems’s diary

クラウドで働くインフラエンジニアの日々の感想です(ほぼ毎日更新)。

コンテナのサーバー周りはまだまだ発展途上

f:id:orangeitems:20191002111844j:plain

 

サーバーでコンテナを動かすときに考えること

コンテナを動かすことについてはかなり安定期に入っていると思います。コンテナランタイムがDockerであろうがなかろうが、そんなに特別なことさえしなければコンテナ単体ではどこでも動くのはピンと来ます。

じゃあサーバーにDockerを入れてその上でコンテナ動かせば・・となると困ったことになり、どのサーバーにどのコンテナが動いているのかさっぱりわからない。これは一時期無償のVMware ESXiが大流行りしてデータセンターの物理サーバーにたくさんバラまかれたのですが、そのうちどの物理サーバーにどの仮想マシンが動いているかわからん。という状態になったのを覚えています。

もちろんvSphereやらvCenterやらでちゃんとクラスタを組んでいればそんなことにはならないのですが、無償・フリーライドは非常に魅力的でたくさんのサーバー管理者は障害発生時に、Excelで仮想サーバー一覧.xlsxみたいなファイルを開いて、あたりをつけてESXiにvSphereクライアントでアクセスするも、ファイルの内容通りではなくてブチ切れながらサーバー管理していた人もたくさんいるでしょう。私ですが。

さて、そのころの大きな反省のもと現在、VMwareを本番で動かす場合は有償ライセンスを買う流れになっていますしストレージを後ろにつけてvMotionができたり、vSANやNSXなどで脇を固めてオンプレミスの仮想化においてはVMwareが王様です。

一方でコンテナにおいても同様です。単にOSのコンテナランタイム上にコンテナを置くだけでは、どこのサーバーにコンテナが動いているか訳が分からなくなります。どう考えても複数のコンテナを管理するオーケストラレーションの役割が必要です。そこでDocker社がVMware社のような位置になるかと思いきや、コンテナ技術そのものを有力ベンダー共同で標準化されてしまいそのうえでvSphereの位置づけになるはずだったDocker SwarmはKubernetesにその座を奪われてしまいました。RedHatもOpenShiftというソフトウェアでその座を狙っていたのですが結局Kubernetesを取り込む形を取りました。

 

Kuberenetesならバラ色・・ではない

ただKubernetesがオープンソースである宿命で、各有力ベンダーがパブリッククラウドにて並列で実装していくこととなり、どのベンダーについていくのが安全だ?という状態が現在地点であると認識しています。仮想マシンであれば、むしろパブリッククラウドを使う場合はもうそのクラウドから逃げられない気持ちで使うしかない。EC2のAMIイメージを引き抜いて他のパブリッククラウドにそのまま持っていけるわけではない。逆もそう。だからもうパブリックベンダーと一心同体でシステムを移したり構築しよう、と。何かあったら他のパブリッククラウドやオンプレミスでOSから作り直すかぐらいの気持ちなのが仮想マシンの世界だと思います。

ただコンテナの場合は事情が違っていて、どうも各ベンダーがどんなKubernetesを使っても動くようにしたいと思っている。でも本当か?みたいな疑心暗鬼状態です。

この仮想マシンとサーバーサイドのコンテナの差はどこにあるかというと、ロードバランサーやファイアウォール、ストレージなどのサービスをKuberenetesが含めてしまったところにあります。仮想マシン自体はあくまでもOSであり、コンテナ自身も軽量のOSと言っても差し支えないと思うのですが、コンテナのオーケストレーターであるKubernetesは、OS周辺のインフラ基盤の抽象化まで行っています。したがって、そのKubernetesを動かすインフラ基盤の仕様やパブリッククラウドポータルのUIに引きずられるのは当然の話です。

昔はLinuxと言ってもいろんなLinuxがありましたよね。どんなLinuxを使っても同じプログラムが動くというのは乱暴です。Redhat系とDebian系はコマンドの文法やディレクトリの配置、パッケージ管理方法が全然違います。Kubernetesはそこまでの分化はしていないですが、ユーザー目線から言えば似たような状況にあります。

こんなニュースを見ました。

 

www.publickey1.jp

Google Cloudは、Google Kubernetes Engine(GKE)でコンテナネイティブなロードバランス機能を正式版としたことを発表しました。

従来、コンテナに対するロードバランス機能は、コンテナが属するインスタンスのiptablesを経由してコンテナに到達していました(下図上)。

コンテナネイティブなロードバランス機能では、KubernetesのIngressコントローラに新しくNetwork Endpoint Groups(NEG)と呼ばれるレイヤが組み込まれ、これがコンテナを直接認識することで、コンテナに到達するまでのホップ数を減らし、効率的なトラフィック分散を実現しています(下図下)。

 

Google Cloudを使う人は便利になっていいのですが、他のクラウドのマネージドKubernetesでは上記はまだもちろん実装されていません。

したがって、今はどのベンダーのKubernetes実装を使うかを選ぶことにリスクポイントが存在します。

 

VMwareが新しい動き

一方で、オンプレミスの世界ではVMwareがESXi上でKubernetesを動かすと宣言してくれて、これがインフラエンジニアに刺さるんではないかと期待されています。ESXiはまだまだたくさん世の中に存在していますから。

 

tech.nikkeibp.co.jp

 ネット企業やスタートアップを中心に活用が進んできたコンテナ技術が、一般の企業システムでも当たり前になる。その起爆剤となりそうなのが、米ヴイエムウェア(VMware)が同社の仮想マシンに組み込むコンテナ技術だ。同社製品のユーザーはチェックボタン1つで手軽にコンテナを利用できる。

 米IBMのように、ユーザーの既存システムを含めてコンテナ化を支援する動きも普及を後押しする。同社は、アプリケーションサーバーやデータベース(DB)など主要ミドルウエアをコンテナ対応に改造し、企業システムに利用を促す。コンテナの利用環境が一気に充実する2020年、まずはコンテナが使えないかを考える「コンテナファースト」の波が、企業システムに押し寄せる。

 

仮想マシンの歴史と違い、Kubernetesがいきなりパブリッククラウドから話が始まったのでややこしくなってしまったのですが、VMwareがサポートしてくれるとまずはオンプレで動かす人が急増するというのはよくわかります。

まずはVMware上のKuberenetesの動作がデファクトスタンダートとなり、それをパブリッククラウドにシフトするという流れが2020年以降の目玉になるのではないかと思います。

もし、VMware主導でKuberenetesがオンプレで評価され、この上のコンテナをパブリッククラウドに持っていくという発想が現実のものとなれば、今の業界の歴史・仕組みや流れと一致しそうです。

2019年の今はまだコンテナのサーバー周りはまだまだ発展途上で本番に持っていくにはチャレンジングなのですが、来年あたりからxTECHの記事の通り本格化してもおかしくないなと言うところです。