連載の 1 回目では、Miles Ward、Google Cloud Platform の Global Head of Solutions が、コンテナや Docker、Kubernetes について大枠のコンセプトを説明しました。次に Senior Staff Engineer であり、Kubernetes プロジェクトを始めた 1 人である Joe Beda が Google のビジネスでコンテナを運用してきた 10 年の経験を基に、コンテナ クラスター マネージメントの主要コンポーネントについて説明しました。今回は Martin Buhr、Kubernetes オープンソース プロジェクトの Product Manager が、Kubernetes についてと Google Cloud Platform でのコンテナのサポートについて、疑問を持っている皆さんも多いであろう質問に答えます。
2014 年 6 月にオープンソース プロジェクトとして Kubernetes を公開してから、直ぐ大きなコミュニティが作られていき、これにはワクワクさせられました。Red Hat や VMware、CoreOS などが、Kubernetes をもの凄いペースで成長させ、成熟させることを手伝ってくれていますし、また、拡大しているユーザー コミュニティでも、どちらもコンテナ クラスターを運用していくために Kubernetes を活用し、多くの場合にはプロジェクトにコントリビュートしてくれています。
このようなコミュニティがあるおかげで、多くの人と出会うことができました。その中で、皆さんが同じような疑問を持っていることに気づきました:
このポストは、こういった質問に答えるもので、それと Kubernetes G+ ページで見逃したかもしれないことにも答えていきたいと思います。
Google はすでに成熟した強力なクラスター マネージメント システムを持っているのに、なぜ Kubernetes を作ったのか、と気になる人は他にもいると思います。理由は 2 つあります。
1 つ目は、利他的な理由です。過去 10 年、Google で開発者の生産性を劇的に高め、また提供するサービスが増加しても、オペレーション上のオーバーヘッドの増加に比例した投資をすることなくサービスを提供できるようにし、また、ワークロードのポータビリティ（1 つのリソース プールから直ぐに取り出して別のプールへと移動させる）をもたらしたことを Kubernetes として体系化されたモデルへと移行させることで、驚くほどの成果があったことを楽しんでいます。これまでにコミュニティに共有してきた他のテクノロジーやコンセプトのように、Kubernetes で世界をより良い場所にし、そして皆さんにも同じような成果を得てもらいたいと考えています。他にも例を挙げると、Android、Chromium や Linux コンテナへの人気の高まりを支える多くのテクノロジー（memcg、Docker で使われている Go プログラミング言語、cgroups、それに cadvisor）があります。
2 つ目は、Google Cloud Platform をアプリケーションを構築し、ホストする Web 上で最高のプラットフォームにしたいという、実際的な理由です。去年の 3 月に、Google の Senior Vice President for Technical Infrastructure である、Urs Hölzle が伝えたように、Google のコア インフラストラクチャーと Google Cloud Platform とを統合していく程に GCP の中に Google にとって大きな商機を見ています。Google が独自のコンテナ ベースのワークロードを構築してきた同じパターンとベスト プラクティスを使えるようにすることで、私たちは、皆さんのワークロードを最も考えるべきレイテンシーやコスト、他のサービスといったことへ向けられるようにします。このように GCP でコンテナを深く広範囲にサポートしていくことで、コンテナベースのアプリケーションのマーケットで重力井戸を作り出すことができれば、そのマーケットのほとんどが GCP を使うようになるだろうと、時間をかけて考えてきました。
“Docker” と言うとき、Docker コンテナのイメージ フォーマットと、Docker イメージを動作させるための Docker エンジンを使うことを指しますよね（Docker というコンセプトを普及させた Docker Inc. ではなく）。Kubernetes は、この Docker コンテナを管理します。
この Docker コンテナ 1 つひとつが、荷箱であると想像してください。これらの箱は、同じ場所に運んだり、同じものをまとめるために一緒に置いて、同じ運送用のコンテナに積まれます。このアナロジーで、荷箱が Docker コンテナ、運送用コンテナが Kubernetes の Pod となります。
このような Pod から、最終的にアプリケーションが作り上げられます。
この船が、インターネットの嵐のような海で彷徨うことは避けたいですよね。Kubernetes は、船の船長です。船を最適な経路で航行させて、アプリケーションをその指揮で効果的に運用し、正常に保つ責任を持ちます。
少しのコンテナを使う状況から、もっと先に進んだとき、特にアプリケーションが成長して 1 つのホストで許容できない程になってきたら、Kubernetes を使うことを強くお勧めします（最近お伝えした理由で）。
Kubernetes が今あるコンテナ マネージメント システム（例えば Swarm）とどう違うのかという観点で見ると、3 度目のイテレーションにあるクラスター マネージャーだと言えます。Swarm をはじめとしたシステムは、単一ノードのモデルであり、ユースケースによっては効果的ですが、プロダクション レベルのユースケースに移行する際に要求される、いくつかの重大なアーキテクチャー パターンが欠けています（前回の Joe のポストで説明しています）。Kubernetes は、Google の 10 年にわたるプロダクションでのコンテナ運用の経験から積み重ねたきたことを取り入れ、コンテナ ベースのアプリケーションを開発してデプロイし、運用していく最適解としてのクラスター中心のモデルを具体化したものです。
皆さんからも、パートナーからも次のような質問を受けます: “自分のプロジェクト/アプリケーション/ビジネスの今後を、Kubernetes が長く継続するものとして、そこに賭けようとする。そのとき Google がこれからも関心を失わず、プロジェクトの先行きが不透明になる状況を避けられる保証があるのか？”
まず、先ほども書きましたが、Google は Kubernetes をクラウド戦略の中心と捉え、Google 全体のビジネスの中で Google Cloud Platform が重要な役割を担うように社内的にもコミットしています。Google が、コンテナ化されたワークロードを実施していく中で得てきたことは Google Cloud Platform に大きな優位性となります。だからこそ、Kubernetes をより強力に、より成熟したものにしていくための投資を続けることは Google にとっても意味のあることなのです。その証明として Google の中でも最も経験豊富で才能あるエンジニアの数名がプロジェクトに従事し、その中には、Google のクラスター マネージメント システムとプロセスの開発と改善に数年来取り組んでいる Googler も含まれます。
次に Kubernetes から、幸運にも活気があり経験のあるコントリビューターのコミュニティをが生まれたことです。多くのコントリビューターは、自社製品に Kubernetes を組み入れているので、結果として Kubernetes の現状と継続に対し利害関係を持つことになります。例えば、Red Hat は Kubernetes を OpenShift バージョン 3 の中の不可欠なものとして使うなど、このポストの時点では、コントリビューターのトップ 10 のうち 2 人が Red Hat の Kubernetes 担当のチームからです。なので、たとえ Google が隕石で吹っ飛んでしまったとしても、大きなコントリビューターのコミュニティが、プロジェクトを引き続き前進させてくれるでしょう。
ここまでに伝えたように、Google Cloud Platform は、Google の重要なビジネスです。そして Google Cloud Platform を、コンテナを使う上で Web で最高の場所にできる確信があります（10 年にわたりビジネスを動かすためにコンテナを使い続けてきた経験と、その中で養われた多くの技術面、オペレーション面での知見をもとに）。そして Kubernetes は、そのコンテナ ベースのワークロードを作成し、実行させてきた中で努力して手にしてきた経験からの、ベスト プラクティスとパターンを具体化させたものです。
Kubernetes が、開発者が運用時のオペレーションにかかるオーバーヘッドを最小化した、優れたコンテナ ベースのアプリケーションを構築するために効果的であり、それがコンテナを使う流れを加速させることになるだろうと、私たちは考えています。そして、Kubernetes で運用するコンテナ ベースのアプリケーションに備わっているポータビリティによって、全ての新しく作られるコンテナベースのアプリケーションは、GCP 上で動作する候補になります。
期待しているのは、コンテナ ベースのアプリケーションが、Kubernetes を使うことで（どこで使われているかにかかわらず）もっと凄いものになること。そして目標としているのは、Kubernetes ベースのアプリケーションが、GCP で並外れて凄いものになることです。市場のどのくらいがコンテナへと移行するのか、そこで GCP へと呼び寄せる負担がどれほどのものになるのかは、まだわかりません。ですが、私たちは、広範囲に採用されることに賭けています。
成功への戦略のために、Kubernetes をどこであっても、それが他のクラウドや自社のデータセンターでアプリケーションを動作させるためであったとしても、最高のものにする必要があります。このことからも、私たちの Kubernetes における目標はユビキティです。コンテナ ベースのアプリケーションをどこで動かすのであっても、望むのは、Kubernetes が使われるということ。Google が長年改善してきたことの（失敗から学んだ多くの教訓も含め）全てを皆さんが利用できるようになるように。仮に自社のデータセンターから移行することをまったく計画していないとしても、想定している範囲で今後も1現在のクラウド プロパイダーだけを使い続けるのだとしても、なぜ Kubernetes が、コンテナ戦略の土台とすべきものであるのか、これからも是非皆さんと話していきたいです。
ここまでのことから、Google Container Engine へと至ります。GKE は、マネージド コンテナ ホスティングの提供であり、Google Cloud Platform 上での Kubernetes の具体化です。私たちは、それぞれの必要性にあわせて、Google の現場でテストされて証明されているパターンを使い、コンテナ ベースのアプリケーションを構築できるように Kubernetes を使ってもらいたいと考えています。同時に Google のコンテナ クラスターを使い運用していった経験に加えて GCP の他の全てのサービスも含めた総合的な価値を提供することで Google Cloud Platform を、コンテナ ベースのアプリケーションを動かす最高の場所になるようにしていきます。今のところ、Google Container Engine は単に Kubernetes をホストしているだけですが、さらに有用性を高めていくために必要な機能と、他の Google Cloud Platform サービスとの連携機能の導入を進めています。期待していてください。
それにしても、アプリケーション開発者になるには本当に面白い時ですよね！これまで見てきたように、Google は Kubernetes に広範囲に深くコミットしていて、コントリビューターの皆さんから作られるエコシステムと一緒に、どこでクラスターを動かすかにかかわらず、コンテナ クラスターを構築し運用していくためのベストなツールになるように取り組んでいます。私たちの見方では、コンテナ ベースのアプリケーションを動かすために、まず検討すべきベストな選択は Google Container Engine を使うことです。2 番目は Google Compute Engine 上で Kubernetes を使うことで、最後は、どこか別の場所で Kubernetes を使うことです。
個人的に Kubernetes で最も興奮するのが、多くの人が力を入れて熱心にプロジェクトにコントリビュートしてくれていること、そしてその頻度の高さです。Kubernetes から、このように拡大したチームが生まれたことを本当に誇りに思っています。前回のポストで Joe Beda 伝えてくれたことは、それをまさに言い表してくれていると思います:
私たちは、この分野で多くの経験があるものの、Google がすべての答を持っているわけではありません。Google の中にはない必要条件であったり、検討事項があります。それをふまえて、私たちが何を構築しているのか確かめて、そして参加してください！
この領域で多くの経験を積んでいるとはいえ、 Google がすべての答えにたどり着いたわけではありません。社内での取り組みからは見えてこない要件や検討事項があるからです。それを踏まえた上で、 Google が構築に取り組んでいる内容をチェックしてみてください。
まずは試して、バグがあればレポート、わからないことは聞いて、あるいはプルリクエスト(PR) を送ってください。
-Posted by Martin Buhr, Product Manager, Kubernetes
0 件のコメント :
コメントを投稿