皆さん、こんにちは。いつまでバルセロナ気分!?と言われそうなぐらいこのシリーズが長引いてしまい、申し訳ありません。このシリーズでは第3のプラットフォームと呼ばれるアプリケーションが主体のプラットフォームから生まれてきたテクノロジーとVMwareの製品を並べてご紹介しています。
その1では第3のプラットフォームではContainerという軽量な隔離プラットフォームが台頭してきており、Dockerというアプリケーションのレイヤリングをうまく自動化したテクノロジーによって、環境を開発者フレンドリーに迅速に展開、更新できるようになっているというお話をさせていただきました。
その2ではDockerの更にアプリケーションのレイヤリングにフォーカスを当てて、なぜContainerがVMよりも開発者に好まれているのか?それに対してVMwareはどのような回答を出したのかを述べています。
その3ではDockerが提供する俊敏性に対して、VMwareが全く別のアプローチで実現を図ろうとするProject Fargoについてご紹介しました。
その4はProject Fargoを補完するものとして、アプリケーションのリアルタイムレイヤリングであるAppVolumesテクノロジーをご紹介し、WindowsでもContainerと同じかそれ以上に迅速にアプリケーションを展開できるようにしようとしているという構想をお話しています。
さて、今回、その5は最終回です。VMwareが実現しようとしている｢VMでもContainerでも関係なく、ユーザーが求める俊敏性を実現できる｣という構想に対して、Googleがオープンソースで公開している｢Kubernetes｣というフレームワークについてご紹介していきます。
なんと読む?
まず、｢Kubernetes｣どのように発音するのでしょうか?
kubernetes {koo-ber-nay’-tace}(クーベルネイテイス)
調べたところ、どもギリシャ語のようで、操舵手という意味のようです。Docker(船)の操舵手という意味なのですね。バルセロナのセッションでは｢クーベルネティス｣｢クーバーネーティス｣など人によって発音が異なっていましたし、VMwareの社員のセッションでも｢なんだっけ?あれ、忘れちゃった、Dockerをコントロールするアレだよ!｣ みたいなことになっていました。とにかく操舵手という意味だということを覚えておいてください。
何をしてくれるもの?
DockerがContainerを自動化してくれる、というお話を以前させて頂いていますが、自動化してくれるのはContainerイメージの内部のみです。起動したいたくさんのコンテナーイメージをどのホストに配置して、どのように死活監視、運用管理していくのか?という部分を担うのがこのKubernetesです。
語弊を覚悟で無理にVMwareのテクノロジーに当てはめるとDockerはテンプレート、スナップショット、クローンなどのハイパーバイザーのテクノロジーでしたが、KubernetesはvCenter、DRS、ゆくゆくはHAやvMotionなども? のクラスタテクノロジーです。
ちょっと技術的な解説(さわりのみ)
KubernetesではPodという単位が最小の単位です。PodはDockerで作成されたコンテナをグループにするものとおぼえてください。もちろん、コンテナ1つでもPodを構成可能です。このPodを定義したファイルを作成するのですが、この定義ファイルに記載された状態を｢Desired State(あるべき状態)｣と呼びます。万が一コンテナが障害を起こすなどした場合はKubernetesが自動的にコンテナをDesired Stateとして再起動します。
Kubernetesによってコンテナの死活監視と自動最適展開がおこなれていることになり、ちょうどVMwareでHAとDRSが有効になったような状態といえるかもしれません。
コンテナ内のデータはコンテナが終了すると同時に消滅します。Pod内にデータを永続的に保存したい場合はVolumesという考え方を利用します。このVolumesをコンテナにマウントさせるところまでをDesired Stateとすることで、永続的なデータを利用するコンテナを作成可能です。
上の図はコンテナがひとつの場合ですが、Web/Apps/DBなどのアプリケーションが組み合わさったPodを作ることも可能です。ドンドンドンドンPodを起動させていくと、Podがグループになったらいいなぁと思うようになってきます。KubernetesではPodをグループにするためにLabelという単位を利用します。グループというよりはタグ付けのイメージになりますので、検索して必要なコンテナを見つけ出すのも簡単です。
もっとPodがドンドンドンドン多くなっていきます。一気にPodを多数起動して、巨大なアプリケーションを起動しようとしています。ここで問題になるのはどのホストでどのPodを起動すべきなのか?リソースの無駄を防ぐために必要以上にPodを起動しないようにするには?逆に要求されているパフォーマンスを満たすためにどれだけのPodを起動すべきなのか?もしくはホストの負荷が均一に保たれているか?などの問題です。KubernetesではReplication Controllerというものが用意されています。Relication ControllerではPodのテンプレートと必要なレプリカ数を指定できます。これで全く同じ状態のContainerが複数起動続ける状態を作ることが可能です。
また、Serviceというロードバランサーのような機能も用意されており、Replication Controllerで構成されたレプリカ間で負荷分散するような構成をDesired Stateにすることも可能です。
これ以外にもContainerの死活監視にhttpアクセスや特定のコマンドを利用したりするようなHealth Checkの機能であったりも組み込まれています。
まとめ
Kubernetesを利用するためにはスクロールアイコンで図の中に記載したような定義ファイルが必要ですが、逆にそれさえ出来てしまえば常に起動状態(Desired State)を保ってくれますし、Replication ControllerとServiceを利用してContainerをアプリケーションに近いレベルで冗長化すればHAやFTにも変わる耐障害機能になります。Containerをどこに配置するのかもインテリジェントに決定されるため、負荷分散/DRSなどを考える必要もなく、開発者は完全にロジックの開発だけにフォーカスすることが可能です。
そして、この技術はGoogleだけではなく、VMwareはもちろん、Microsoft、RedHat、IBM、HPと言った主要なメーカーによって共同でメンテナンスされており、VMwareはこの技術を近い将来vSphereの中で(仮想マシンの中で?)利用できるようにしていくと表明しています。VMはVMの、ContainerにはContainerの得意分野、不得意分野がありますが、それぞれの利点をよく理解した上で、ハードウェアインフラ、ソフトウェアインフラ、アプリケーションインフラのどの技術を使うべきなのか、判断していく時代なのかもしれません。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
