InfoQは企業向けにKubernetesをサポートしているKismatic IncのJoseph Jacks氏とPatrick Reilly氏にインタビューをした。最近のKubernetes v1.0のリリースや、プロジェクトの歴史、将来このプラットフォームがマイクロサービスの配置に与える影響について話を聞いた。
Kubernetesの企業向けのサポートを提供するKismaticはDockerと密に協力してKubernetesのエコシステムに関わっている。ファンダのひとりはCloud Native Computing Foundation (CNCF)を立ち上げている。Patrick Reilly氏はKismaticのCEOであり、長きにわたって、クラスタリングやコンテナ技術に携わってきた。また、KubernetesのウェブベースのUIである‘kube-ui’や他のオープンソースプロジェクトにも貢献している。Kismaticで技術戦略担当のバイスプレジデントを務めるJoseph Jacks氏もKubernetesに携わっている。また、財団に対する支援することで、この技術の普及を推進することを公にしている。
InfoQは両氏に話を聞き、Kubernetesの歴史や現時点での使われ方、将来について話を聞いた。
InfoQ: Kubernetesは、GoogleのBorgと"The Datacenter as a Computer"に関する研究に影響を受けていることは有名です。他のソリューションと比べ、この影響はKubernetesにどんな特徴をもたらしているのでしょうか。
Kismatic: 過去7年にわたり、多くのオープンソース分散システムのプロジェクトがこれらの研究結果を踏まえて誕生しました。例えば、GoogleがなければCloud Foundry (CF)はないでしょう。CFのふたりの創業者エンジニアは(Derek CollisonとVadim Spivak)はGoogleで働いており、VMwareでCFを開発する前にBorgを使い込んでいました。また、Mesosは産業界ではなく、UCバークレーのコンピュータ科学の博士論文から生まれたオープンソースプロジェクトです。Apache Mesosの主要な開発者であるBen HindmanはGoogleでインターンをして、Googleのエンジニアと議論してBorgのクラスタスケジューリングから学び、Mesosを実装しました。MesosもGoogleなしでは存在しなかったでしょう。そして、私たちがKubernetesに熱狂しているのは、Google内部で10年以上Borgを開発しスケールし、管理していた休み知らずのエンジニアたちが、GitHub上で、誰からでも連絡を取れるような形で活動しているからです。Kubernetesは10年以上に渡る大規模分散クラウドインフラへの理解を圧縮したものです。Urs Hölzle氏がいうように“15年以上クラウドインフラで働けば、何ができて何ができないのかわかる”のです。
InfoQ: 他のIaaS/PaaSのプリミティブよりもKubernetesが提供するプリミティブ(ポッド、レプリケーションコントローラ、サービス)のほうが開発者が理解しやすいという声を聞きます。これについてはどう思いますか。
Kismatic: これはその通りだと思います。中核のパッケージングと分離の仕組みとしてのLinuxコンテナの観点から、Kubernetesは分散マイクロサービスのライフサイクルを管理するための素晴らしい構成要素を提供します。Kismaticで企業の顧客とやりとりをする中で、Kubernetesのプリミティブは開発者に正しいレベルの自動化を提供し、開発者がサービスの高可用性を確保する方法を探れることがわかりました。アプリケーションのさまざまなコンポーネントへトラフィックを直感的に流し、さまざまな度合いの柔軟さを提供して、サービスの構成や管理をしやすくします。Kubernetesによって、開発者はマシンの構成ファイルではなく、データセンターのリソースや(マイクロ)サービスの観点から考えることができます。それゆえ、Kubernetesはデータセンターを管理するひとつのAPIであると考えてもよいでしょう。
InfoQ: Kubernetesはマイクロサービス構築へたくさんの利点を提供することが知られていますが、便利なパターンやリファレンスはありますか。
Kismatic: もちろんです。Kismaticが推奨しているたくさんの強力なパターンはKubernetesの開発者であるBrendan Burnsから着想を得ています。Brendanは最近DockerConで話した内容を元にブログを書いています。ここで読めます。この記事で氏は、Kubernetesを使ってマイクロサービスアーキテクチャを効果的に設計と開発をする方法を理解するのに便利なパターンをいくつか示しています。Brendanはサービス志向アーキテクチャ(SOA)がアプリケーションをモジュラーに分解し、サービスに注力できるようにすることを指摘しています。同じように、コンテナはこれらのサービスをより密接に協力するモジュラーコンテナに分解します。そして、Brendanは、“境界を確立することで、ユーザはコンテナによって、モジュールと再利用可能なコンポーネントを使ってサービスを構築できます。一枚岩のコンテナより拡張可能で、より素早く構築ができるのです”と書いています。そして、最後に、Kubernetesの3つの人気のパターンを示しています。
InfoQ: アプリケーションを拡張し管理するのを簡単にするため、Kubernetesによって従来の開発と運用が一緒に働くのが混乱する可能性があります。フルスタック開発者やプラットフォームチーム、SREに求められるスキルセットは将来どうなるのでしょうか。
Kismatic: 将来、データセンターと分散システムの構成要素としてKubernetesが使われるようになったら、ひとつ大きなことが起こると思います。それは、開発者がさらに生産的になるということです。Kubernetesの本当のゴールはアプリケーションをインフラと疎結合にして、開発者にエレガントな抽象を提供し、インフラの構成の些細な点から遠ざけることです。顧客から、Kubernetesを使う前は開発者が70%以上の時間をインフラに費やしていたという話も聞きました。Kubernetesでコアサービスを定義して新しいモデルを導入できるようになったら、90%以上の時間を新しい機能の開発やコーディングに使えるようになり、バックエンドに費やす時間は10%以下になりました。プラットフォームエンジニアとSREもより生産的になります。というのは、大量の時間が必要な手動のタスク(構成管理のクックブックやレシピの更新のような)は完全になくなるからです。GoogleのBorgの論文ではBorgのSREが巨大な数のマシンを管理する方法を示しています。
InfoQ: Kubernetes v1.0が最近リリースされました。Kubernetesのエコシステムでこのマイルストンはどのような重要さがあるのでしょうか。このリリースで実現した機能(実現しなかった機能)についてどのように考えていますか。
Kismatic: Kubernetesがバージョン1.0になったのは、大きなことです。たった1年で15,000を超えるコミット、420を超えるコントリビュータがいます。当のDocker以外に、この短い期間でここまでの状況に到達したオープンソースプロジェクトは私は知りません。今年の2月、Kubernetesのコミュニティの多くのコントリビュータがサンフランシスコに集まり、バージョン1.0のリリースのスコープについて議論しました。ここで計画したことの多くが今、現実になっています。GoogleのCraig McLuckie氏はKubernetesの主要な機能を示していますが、今回のリリースは、数百のノード(物理、仮想の両方)でテストし、数千のコンテナで動作します。もちろん、これは始まりにすぎません。
アプリのサービス、ネットワーク、ストレージ
- 配置とワークロードの管理にとって重要な機能。DNSやロードバランシング、スケーリング、アプリケーションレベルのヘルスチェック、サービスアカウント。
- 状態を持つアプリケーションがさまざまな種類のローカルまたはネットワークベースのボリュームをサポートする。例えば、Google Compute Engineの永続化ディスク、AWS Elastic Block Store、NFSなど。
- 関連するコンテナを集めるpodsの中にコンテナを配置する。こうすることで更新やロールバックが簡単にできる。
- コマンドの実行、ポートフォワーディング、ログコレクションを使ってアプリケーションを調査、デバッグできる。CLIとUIを使ってリソースを監視する。
クラスタマネジメント:
- ライブでクラスタを更新、スケールできる
- 名前空間でクラスタを分離し、リソースを深く制御する。例えば、クラスタを異なるアプリケーション、テスト環境、プロダクション環境でセグメントに分離できる。
パフォーマンスと安定性
- APIのレスポンスが早い。平均して5秒以下でスケジューリングされるコンテナ
- 1クラスタごとに1000コンテナ、100ノードまでテストされているスケーリング
- 公式の非推奨ポリシーを持つ安定したAPI
今回のリリースに含まれない機能については、ロードマップで示したいと思います。
InfoQ: この2年でDockerは驚異的な成長をしました。Kubernetesはこの成長をなぞることができると思いますか。
Kismatic: もちろんです。前述した通り、Kubernetesは、ほとんどDockerの1年目と同じ成長メトリクスを示しています。
InfoQ: GoogleやRed Hat、そしてあなたの会社であるKismaticなど、多くの企業がKubernetesを支持しており、Open Container Initiative (OCI)とともにCloud Native Computing Foundation (CNCF)の設立が発表されたのは、とても面白い動きです。組織の協賛を得るのはどの程度うまくいっていますか。この商業的、または、非商業的な動きはコミュニティにどのような利点があるのでしょうか。
Kismatic: エコシステムが育つにつれ、多くの大企業、重要な企業がKubernetesの周囲に集まってきてくれます。また、OCIとCNCFの設立メンバになったことにはとても興奮しています。今年の始めから、GoogleとKubernetesの結合を弱めようとしてきました。そうすることで、プロジェクトの進化を見通す自然な組織が生まれ、業界に良い影響があると思ったからです。これが、CNCFという形で実現できたのは素晴らしいことです。
InfoQ: Kismaticは何を提供するのでしょうか。他のベンダとは何が違うのですか。
Kismatic: 設立以来、Kismaticは企業としての第一の戦略に注力してきました。その戦略とは、Kubernetesのアーリーアダプターと企業ユーザの話を聞き、フィードバックをもらい、実利用の要件を学ぶことに大半の時間を費やすという戦略です。アーリーアダプターの話を聞くという戦略は大きな利点がありました。Kubernetesを使っている人の作業を単純化することが、より普及のスピードを速めることがわかり、Googleと協力してネイティブのWebUIコンソールを開発し、Kubernetesを視覚化したのです。そして、このダッシュボードはポッドやクラスタの利用度合いを一目で確認する方法としてすぐに標準的なものになりました。
先週、私たちは、KismaticのコマーシャルサポートサブスクリプションとオープンソースのKubernetes向けのプラグインを発表しました。顧客にヒヤリングをしたところ、彼らが断片化のリスクとベンダロックインを心配していることがわかったので、完全にオープンソースのKubernetesの周辺でサポートと商用化戦略を構築することに決めたのです。Kubernetesはどこでも動くべきなので、私たちは、下層のLinuxディストリビューションに制限をかけたくなかったのです。特にKubernetesをフォークするのは避けようと考えていました。
Kismaticの企業向けのサポートサブスクリプションは、5つのメジャーなLinuxディストリビューションから始めるつもりです。すなわち、RHEL、CentOS、Debian、Fedora、Ubuntuです。顧客は24/7の保証されたサポートSLAをKubernetesのプロダクション配置環境で活用できます。
また、ディストリビューションに依存しないKubernetesのサポートを提供するために、Kismaticはマイクロサービスクラスタにしっかりとしたセキュリティと管理、監査、アクセスコントロールを統合したいと考えている企業向けにβプログラムを実施しています。まずは、RBACサポート、LDAP/AD連携、Kerberos暗号化、コンプライアンスのためのしっかりとした監査とロギングの永続化を実現するプラグインの提供に注力するつもりです。
InfoQ:ありがとうございました。最後にInfoQの読者に何か伝えたいことはありますか。
Kismatic: このような機会をいただきありがとうございました。とても楽しかったです。
Kubernetesについての詳しい情報はkubernetes.ioとGitHubのリポジトリで確認できる。Kismaticのウェブサイトと同社のGitHubには、Kubernetes周辺のサービスやオープンソースのコントリビューションの情報もある。