成熟期を迎えようとするKubernetes、期待にどう応えていくのか：KubeCon + CloudNativeCon 2018詳報（1）

2018年12月中旬に米ワシントン州シアトルで開催された「KubeCon + CloudNativeCon 2018」は、8000人の参加者を集めた。期待の高まりに、CNCFおよびKubernetesコミュニティーはどう応えていくのか。

[三木泉，＠IT]

　Cloud Native Computing Foundation（CNCF）が米ワシントン州シアトルで開催した「KubeCon + CloudNativeCon 2018」は、8000の事前登録チケットが約1カ月前に売り切れ、約2000人のウエイティングリストができる状況となった。

　CNCFが来場者を予測しきれなかったのも無理はない。2017年12月の北米におけるカンファレンスの参加者は4100人。2018年の参加希望者1万人は、その2.5倍に近い数字だからだ。

　CNCFのCOO（最高執行責任者）、クリス・アニズィック（Chris Aniszczyk）氏にとって、喜びと困惑が半々といった感じのようだ。CNCFの今後に向けた課題を同氏に聞いたところ、「急成長期にあるCNCFに対する人々の期待をマネージすること」を真っ先に挙げた。

参照記事：
コンテナ運用環境を標準化？ CNCFは何をやろうとしているか
コンテナストレージの共通仕様にも着手、あらためて、CNCFは何をどうしようとしているのか

　「どんな技術でもいつかピークが来る。CNCFにとって、それがいつかは分からない。少なくとも今後2、3年は成長が続くはずだ。ますます多くの企業が（クラウドネイティブに）インフラを動かすやり方を学ぶ必要を感じつつあるからだ。CNCFが生まれたタイミングは完璧だったともいえる。だが、さまざまな人々を満足させ続けながら成長を続けていくのは大きな挑戦だ」

Kubernetesの広がりと進化の現状

　コンテナオーケストレーションにおいて、Kubernetesは事実上の標準になった。CNCFはKubernetesソリューションを認定しているが、本稿執筆時点で82のサービスあるいはディストリビューションが認定を受けている。

　「最も誇りに思っているのは、ハイパースケールクラウドから、より小規模のクラウドまで、あらゆるクラウドが基本的にKubernetesを受け入れたことだ。もう、Kubernetesに対抗しようとするところはない。こうした統合の動きにより、人々はもうコンテナオーケストレーションのレイヤーで火花を散らす必要がなくなり、より高いレイヤーに専念できるようになった」

　CNCFでは当初、オーケストレーションレイヤーのKubernetesへの統一を、5年で進める戦略を練っていたという。それがおよそ半分の期間で実現した。「こんなに早く進んでしまったことに、私はまだ少しショックを受けている」ともアニズィック氏は言う。

AWSという当初の仮想敵が、CNCFで活発に活動しているという事実

　3大クラウドでいえば、Google Cloud Platform（GCP）が率先してKubernetesを使ったコンテナサービスを提供しているのは当然として、近年OSSのサポートを鮮明にしているMicrosoft Azureも、いち早くサービスを提供開始した。Amazon Web Services（AWS）も2017年末、既存の独自コンテナサービス「Amazon ECS」に加えて、Kubernetesをベースとした「Amazon EKS」を2017年11月に発表した。

　今回のイベントで、Kubernetesプロジェクトを始めた一人であるクレイグ・マクラッキー（Craig McLuckie）氏は、あらためて当時を振り返り、「パブリッククラウドでAWSが独り勝ちの状況を打開するため、新たな競争の場を作りたかった」と語った。その「仮想敵」ともいえるAWSも、今ではKubernetesを支持している。しかも、同社は2017年にOSS専任チームを発足し、OSSに貢献する活動を強化しているが、こうした活動における主要な注力分野の1つは、Kubernetesと関連プロジェクトだ。

　Kubernetesの支持は、プラットフォーム製品においても、その広さと深さを増している。比較的最近の動きでは、Dockerが2018年4月に発表した「Docker Enterprise Edition 2.0」で、Docker Swarmに加えKubernetesへの完全対応を発表した。

　Cloud Foundry Foundationは2017年、従来のCloud FoundryであるCloud Foundry Application Runtime（CFAR）に加え、CFARとの統合運用の下でKubernetes環境を提供するCloud Foundry Container Runtime（CFCR）のプロジェクトを開始した。その後、CFARをKubernetes上で動かすCF Containerization、CFARのオーケストレーションエンジンとしてデフォルトで使われてきたDiegoをKubernetesに置き換えられるようにするEiriniといったプロジェクトを通じ、複数レイヤーでのKubernetesとの連携を図っている。その上で、後述のIstioなど、Kubernetesと共通のツールを活用していく。このように、Cloud Foundry FoundationはKubernetesに飲み込まれるのではなく、CNCFの姉妹団体として独特の存在になっている。

サーバレスとサービスメッシュが注目を集める

　KubeCon + CloudNativeCon 2018で特に注目を集めていたトピックは、サーバレスとサービスメッシュだ。特に、Googleが2018年7月に始めたサーバレスのコンポーネント群Knativeと、こちらもGoogleが中心になって推進しているIstioの2つのプロジェクトが関心を呼んでいる（サーバレスとサービスメッシュに関する動きについては、別記事でも紹介する）。

参照記事：
【完訳】CNCF Serverless Whitepaper v1.0
「サービスメッシュ」「Istio」って何？　どう使える？　どう役立つ？

　Knativeに関してはGoogle（Google Kubernetes Engine）をはじめ、Pivotal、Red Hat、IBM、SAPが、自社の製品／サービスにおける採用を今回のイベントに合わせて発表した。

　サーバレスは、コンテナ（CaaS）とPaaSに続く第3のアプリケーション基盤技術として注目されている。そのメリットは、「AWS Lambda」が象徴している。軽量コードを書いておきさえすれば、イベントを受けてこれが自動的に起動し、作業が終われば自動的に停止する。ユーザーは、コードの実行分だけ料金を支払えばいい。

　こうしたメリットをもたらすサーバレスの要素技術を、Kubernetes上で提供するのがKnativeの狙いだ。「KubernetesがIaaS++なら、KnativeはPaaS--」と表現する人がいるように、Knativeはエンジンとして使うことができる。

　サーバレスはパブリックサービスの間で提供が進んでいる他、幾つかのOSSフレームワークが存在する。これらのサービスやフレームワークがKnativeをベースとして使う動きが広がれば、Knativeはサーバレスの世界における事実上の標準に近づく。例えばIBMはApache OpenWhisk、Pivotalはriffをかぶせて自社製品の構築を進めている。

　サービスメッシュについては、アプリケーションのマイクロサービス化が進む中で生まれる、サービスの可視化、サービスレベルの管理、アプリケーションライフサイクル管理、セキュリティなどといった、複数の課題に対応できる多機能なツールとしての期待が高まっている。ただし、Istioに関しては、これが登場する以前にさまざまなサービスメッシュソリューションがあり、これらとの関係がどうなっていくかは不透明だ。

　KnativeとIstioは、現在のところCNCFのプロジェクトではない。だが、CNCFはこの2つのプロジェクトに対し、参加を働きかけている。

「CNCFはKubernetesだけの組織ではない」ということの重要性

　上記のサーバレスやサービスメッシュへの取り組みにも象徴されるように、CNCFにとって、Kubernetes以外のプロジェクトは今後ますます重要な意味を持ってくる。

　Kubernetesは、3年で業界を揺るがす大きな存在になった。だが、Kubernetesだけでは、ある程度の期間は熱狂を生み出しこそすれ、そのうち「開発者にとっても運用担当者にとっても扱いの難しいツール」ということになりかねない。

　「開発者や運用担当者が最終的に求めているのは、『クラウドネイティブなアプリケーションの開発や運用のための使いやすい環境』であり、このようなニーズを満たすことを考えた場合、Kubernetesだけでは足りない。CNCFが当初から、さまざまなプロジェクトをホストする活動を展開してきたのは。こうした理由がある」（アニズィック氏）

KubernetesはOpenStackと似た状況にあるのか

　今回のイベントの基調講演では、Kubernetesが「アーリーマジョリティーへの本格的な普及が始まる時期を迎えている」との発言があった。これからのユーザーはKubernetesの詳細を学びたいとは考えず、問題なく動くことを当然のように期待しているとする。

　そこで、「状況は、数年前のOpenStackに似ているのではないか」とアニズィック氏に聞いた。KubernetesはOpenStackに比べ、開発者との距離が近いという違いはあるが、インフラであることには変わりがないからだ。

　アニズィック氏はOpenStackとの違いについて、2つの点を指摘した。

　第1にOpenStackと異なり、Kubernetesは全てのハイパースケールクラウドが採用してサービスを提供している。

　「そこでオンプレミスにおけるKubernetes運用の複雑さを回避したいユーザーは、単純にこうした主要クラウドや地域クラウドを活用することもできる。GCPの「GKE On-Prem」やAWSの「AWS Outpost」で、オンプレミスにおけるKubernetesもマネージドに近い状況になる。一方、RancherやRed Hatなどのソリューションを使ってもいい。Kubernetesには82の認定ソリューション／サービスがある。この選択肢の多さは、大きな魅力になっている」

　第2に、CNCFはKubernetes以外に多数のプロジェクトをホストしている。ベンダーはこうしたプロジェクトを取捨選択して活用し、さまざまな製品・サービスを生み出して差別化を図れる。一方ユーザーは、自らのニーズやユースケースに応じた製品やサービスを選び、必要に応じてカスタマイズを加えるなどができるという。

　「ハイプ期にその勢いをどう活用し、次に人々が導入して課題を感じる時期になったとき、これをどう助けるか、期待にどう応えていくのかを真剣に考えてきた。CNCFがさまざまなユーザーを持つプロジェクトをホストすべく、最大限の努力を重ねてきたのはそのためだ。私たちはKubernetesだけではない。提供する技術のポートフォリオで差別化を進めていく」

　ただし、デベロッパーエクスペリエンスの改善は、今回のイベントでもさまざまな参加者が指摘する大きな課題となっている。本連載の次回は、これを含めたKubernetesコミュニティーおよびCNCFの取り組みについてお届けする。

（取材協力：Cloud Native Computing Foundation）