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

2018年12月19日


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氏。

fig

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

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

fig

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

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

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

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

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

Kubernetesは退屈なものになった

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

fig

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

fig

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

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

fig

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

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

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

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

fig

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

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

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

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

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

fig

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

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

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

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

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

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

fig

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

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

最後にまとめましょう。

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


このエントリーをはてなブックマークに追加
follow us in feedly


≫次の記事
Red Hat、Windows版OpenJDKの長期商用サポート提供を発表

≪前の記事
Rustが過去最大のバージョンアップ、「Rust 2018 Edition」正式リリース


カテゴリ



Blogger in Chief

photo of jniino Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed



新着記事 10本


PR - Books


fig

fig

fig