Kubernetesはオープンな標準と拡張性にフォーカスしている。KubeCon + CloudNativeCon North America 2018

12月10日から13日まで、米ワシントン州シアトルでCloud Native Computing Foundation主催のイベント「KubeCon + CloudNativeCon North America 2018」が開催されました。

すでにYouTubeには300本を超える同イベントのセッション動画が大量に公開されています。本記事ではキーノートの1つとして行われたGoogleのソフトウェアエンジニア Janet Kuo氏による「Keynote: Kubernetes Project Update」をダイジェストで紹介しましょう。

Keynote: Kubernetes Project Update

Googleのソフトウェアエンジニア Janet Kuo氏。

ここでは最新機能を紹介するよりも、まずは現在のKubernetesの人気がどれほどのものかを紹介したいと思います。

Google Trendsによると、2014年にKubernetesがスタートしてからトレンドは一貫して上昇を続けています。

2015年に私がコントリビュートを始めたとき、最初のコミットはドキュメントの修正でした。当時はまだ周囲にKubernetesは何かを説明したり、スペルを説明したりしていました。

その後Kubernetes 1.0がリリースされ、CNCFが立ち上げられました。

初期のKubernetesの開発では迅速に新しい機能を追加することが重視されていましたが、その後、スケーラビリティやユーザー体験などを重視するようになり、よりスケーラブルでシンプルなクラスタ構築を実現してきました。

これによりアーリーアダプターや企業の本番環境でも使われるようになってきました。

私たちはさらにユーザーの声に耳を傾け、より効率的なデプロイや運用が実現できるように開発を進めていきます。

Kubernetesは退屈なものになった

CNCFの調査では58％がすでにKubernetesを本番環境で利用しており、5000人以上の大企業でも40％がKubernetesを本番環境で使っているとされています。

つまりKubernetesは明らかにアーリーアダプターからメインストリーム市場のアーリーマジョリティへと移行してきたわけです。

アーリーマジョリティはKubernetesの細かい機能のことよりも、それが十分に機能することを重視しています。

そしてKubernetesは以前より成熟し、より良いものになったことで、とてもとても退屈なものとなりました。

勘違いしていただきたくないのは、退屈であるということはよいことだということです。

これは、ビジネスバリューを届けることにフォーカスしたいと考えているメインストリームのユーザーが望んでいることなのです。

Kubernetesは標準と拡張性にフォーカス

Kubernetesは2つの機能にフォーカスしています。オープンな標準と拡張性です。

オープンな標準について。Kubernetesは標準のAPIが多数組み込まれており、これらAPIはインフラの上位レイヤとして多くの機能を提供しています。そのため、ユーザーはハイブリッドクラウドやマルチクラウドなどのさまざまな環境でKubernetesを利用できます。

ある米国のレストランチェーンでは、2000の店舗それぞれでKubernetesを動かしているそうです。

もう1つの標準はコンフォーマンス（適合性）です。さまざまな環境で実行されているKubernetesが正しく実装されデプロイされているのか、適合性が保証されていればいちいちテストして確認する必要はありません。そこで「認証Kubernetesロゴマーク」が確認できれば、異なる環境であっても一貫して適合したKubernetes環境が利用できることが分かるでしょう。

次は拡張性についてです。

拡張性は2つに分かれています。インフラの拡張性とAPIの拡張性です。

インフラの拡張性とは、Kubernetesがインフラをどう活用するかをカスタマイズできる機能です。例えばKubernetesは複数の異なるクラウドに対応しますし、プラグインによってさまざまなネットワークベンダやストレージベンダを対応させることができます。

これらプラグインはプラグインAPIによって標準化されています。例えばコンテナランタイムは「Container Runtime Interface」（CRI）があり、ストレージは「Container Storage Interface」（CSI）があるといった具合です。

こうしたプラグインなどによってユースケースの80％は満たせると考えられます。

では残りの20％にはどう対応すべきでしょうか？

KubernetesIにはAPIをカスタマイズするためのAPIがあります。これによってタスクを自動化するようなカスタムコントローラなどが構築できるのです。

また独自のAPIポリシーも設定可能で、これによってカスタムAPIの検証なども可能です。

Istioはこの代表的な例で、Kubernetes上にデプロイされたIstioはAPIの拡張機能を用いてIstio独自のAPIリソースを構成。これを用いてトラフィックの任意の割合についてルーティングを変更する、といったことを実現しています。

APIの拡張性によってあらゆるものがKubernetes上で構成され、管理できるようになっていますし、それだけでなくKuberenetesの外側でも管理できるのです。

最後にまとめましょう。

Kubernetesは退屈なものになりました。しかしこの退屈は成熟したプラットフォームには必要なものでもあります。