Eric Brewer による Kubernetes の過去、現在、未来

※この投稿は米国時間 2021 年 12 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。

Kubernetes という名前がテクノロジー業界に初めて響き渡ったのは、2014 年のことでした。当時はまず「どのように発音するのだろう」と思われる程度でしたが、それから 7 年が経ち、世界最大級のオープンソース プロジェクトとなりました。Kubernetes の初期の世話役に、Google Fellow の Eric Brewer がいました。Eric は 10 年以上にわたり、Google でテクノロジーの推進、構築、外部化を率いています。現在は Kubernetes、サーバーレス、DevOps、Istio、サービスなど、Google Cloud サービスを幅広く担当していますが、以前はストレージとコンピューティングの切り離し、VM の大規模なライブ マイグレーションの推進、分離のための設備使用の具体化など、画期的な取り組みを主導していました。Eric の長年の経験から学ぶために、またクラウド コンピューティングの未来を決定づけたと Eric がいう Kubernetes とオープンソースの 4 つの知見について掘り下げるために、一連のセッションで話し合う機会が得られました。

1. Kubernetes がクラウド ネイティブ コンピューティングの中心となったのはオープンソースだったからであり、引き続きオープンソース技術に投資する必要があります。

Eric は、カリフォルニア大学バークレー校の教員になったとき、後にクラウド コンピューティングとなる、多くのプロセス、サービス、API を使用する汎用サーバーのクラスタに基づくモデルに着目しました。2011 年に Google に入社すると、この考え方を持ち込み、高度な抽象化を中心とした新しい種類のクラウドを開発しました。これは、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するオープンソース システムである Kubernetes につながる、初期のプロトタイプとよくかみ合っていました。

クラウドがまだ形作られていなかった 2010 年代初頭、Eric は、Google の内部のコンテナベースのアプローチが、VM とディスクだけでない、さらにパワフルなクラウドにつながるということを知っていました。Google では比較的簡単に支持者を集めることができましたが、新規性が高く実績のないアイデアの場合、業界で広く受け入れられるまでには時間がかかりがちです。先見の明があった Eric は、プロジェクトをオープンソース化することが、クラウド コンピューティングに革命をもたらす Kubernetes の可能性を実現する、唯一の実施可能な方法だということを知っていました。

もちろん、抵抗に遭いました。2012 年までに、Google Cloud ではすでに App Engine と VM を利用できるようになっていました。評論家からよく出された質問は、「なぜコンピューティングに第 3 の方法が必要なのか」というものでした。Google は、Kubernetes が登場する前からすでに毎週何十億ものコンテナを運用していました。Eric は、業界の他社のためにこの技術をさらに発展させることに大きな価値を見出していました。Kubernetes の自動化と柔軟性により、素の VM や素のディスクよりもはるかに運用しやすくなります。

何年にもわたってオープンソースに支えられてきた Kubernetes は、クラウドでアプリケーションを実行するための事実上の手段となり、その上で動作する Knative や Kubeflow のような独自の垂直的なサービスが増えています。このプロジェクトは、クラウド コンピューティングにおける別の重要な変化に直面している今でもまだ成熟の途上です。Eric は現在、Kubernetes を支える哲学と、セキュリティに敏感な業界が必要とする厳格な保護を組み合わせる取り組みを指揮しています。Eric はオープンソースとソフトウェア サプライ チェーンのセキュリティに注目し、攻撃点を最小限に抑えるために、ソースコードからデプロイまで、独自性の高いツールを作成することを目標としています。

2. ソフトウェア開発で使用される依存関係の数が増えるにつれ、セキュリティ上のリスクも増大します。ソフトウェア サプライ チェーンのセキュリティに対する投資は不可欠であり、マネージド サービスへの移行はセルフマネージド ソリューションよりも実際に安全です。

SolarWinds や CodeCov への攻撃など、最近の攻撃は、ソフトウェア業界全体での再利用や開発速度の向上が攻撃の余地を増やしているということを示しています。Eric は、地球全体の P0 だと考える課題に対処するための基礎を築いています。

オープンソース ソフトウェアや、ソフトウェア開発における依存関係の使用が増加しているため、組織にとっては、どのソフトウェアを採用するのかとその理由を理解することが重要です。検証されていないソフトウェアの依存関係をコードに含めるのではなく、組織は時間をかけてソフトウェアを評価し、水準に達していない、またはメンテナンスが不十分な要素を特定する必要があります。

数百ものソフトウェア依存関係のある Kubernetes に Google はどのように投資しているのかという問いかけに対し、Eric は、Google Cloud が 2015 年に Cloud Native Computing Foundation（CNCF）の設立を支援し、Kubernetes、Prometheus、Envoy など、急成長している多くのオープンソース プロジェクトの、ベンダーに依存しない本拠として機能していると説明しました。この財団の使命は、クラウド ネイティブ コンピューティングをユビキタスにし、エコシステムの成長を促進することです。CNCF の主導で Google がプロジェクトに追加してきたコントリビューションは 680,000 件を超えており、そのうち 123,000 件は 2020 年に追加したものです。

Google には、オープンソースに関与してきた長い歴史があります。実際、Google は最近、オープンソースのセキュリティを支える第三者の財団に1 億ドルを追加で拠出しました。さらに Eric は、Open Source Security Foundation（OpenSSF）の設立を支援しました。OpenSSF は、組織のセキュリティ担当者がオープンソースの依存関係チェーンのセキュリティを理解し検証できるよう、オープンソースのセキュリティ ツールとベスト プラクティスに注力しています。Eric は、前例を作るためにこの作業が絶対に不可欠だと考えています。オープンソースを可能な限り安全にするためには日常的な作業がたくさん必要になりますが、この作業は必須であり、財政的な支援を必要とします。

サービスがさらに高度な抽象化へと移行し続ける中で、マネージド サービスは、安全なソフトウェア デリバリーのための強固な基盤を確立します。マネージド サービスにより、プロバイダはセキュリティの予防的な管理や証明を自動的に行うことができます。たとえば GKE Autopilot は、ノードやノードプールなど、クラスタの基盤となるインフラストラクチャのプロビジョニングと管理を行います。また、ユーザーによる操作が不要な最適化されたクラスタを実現します。これは Google Kubernetes Engine

（GKE）のベスト プラクティスと、クラスタやワークロードの設定とセキュリティの推奨事項に沿っており、コンテナの分離を強化する設定も適用します。Eric によれば、このモデルは今後も主流であり続けます。プロバイダは長年にわたって築き上げてきた実証済みのプロトコルとベスト プラクティスを最大限に活用しながら、ユーザーが自分で管理したくない機能の管理を引き受け、次第に多くの機能（セキュリティなど）を管理するようになります。

3. プラットフォーム事業者は、企業が重視するガイドラインを課しながら、GKE を汎用プラットフォームとして運用する必要があります。

Eric が長年にわたって受けてきたよくある質問として、企業は GKE のようなマネージド Kubernetes プラットフォームをどのように使用すべきか、というものがあります。まず覚えておくべきことは、クラウド プロバイダは、デベロッパーに実際に使用してもらいたいものより多くの方法、オプション、機能を提供しているということです。しかし、プラットフォームの所有者はこうした方法によって、最新のアプリを動かすための、安全かつメンテナンスしやすいプラットフォームを作成できます。たとえば、デフォルトでバックアップを適用することや、ポリシーを適用することで、ルートファイル システム アクセスや、バックエンド システムのパブリック IP の作成を防止するとよいでしょう。クレジット カード取引を処理する場合、社内の開発者に裁量を与えるのではなく、行う取引がサービスの構造によって保証され、事業地の規制を遵守するようなプラットフォームを提供します。

Kubernetes は、プロジェクトの作成、使用するノード、利用するライブラリやリポジトリを制御することで、企業が重視するルールを適用する、カスタマイズされたプラットフォームを構築する方法だと考えてください。通常、バックグラウンド コントロールはアプリ デベロッパーが管理するものではありません。管理された安全なフレームワークがデベロッパーに提供され、その中で運用されます。

マネージド サービスは多くの場合、プラットフォーム事業者が容易に活用できる、自動化されたポリシー コントロールやベスト プラクティスを提供するか、サポートしています。たとえば Anthos Service Mesh は、サービス間のトラフィック フローと API 呼び出しの制御に役立ちます。サービスを自動的かつ宣言的に保護する機能により、開発者は生産性を高めることができ、組織はさらに多くの機能を迅速に提供できます。同時に、会社のポリシーや政府の規制に反するような機能をリリースすることを防止できます。

Google Cloud は、Dockerfile なしでソースコードから安全な本番環境用コンテナ イメージを素早く簡単に作成できるオープンソース技術である、Buildpacks をサポートしています。Artifact Registry を使用すると、安全なプライベート ビルドのアーティファクト ストレージを Google Cloud 上に設定でき、アーティファクトのアクセス、表示、ダウンロードを行えるユーザーを管理できます。Container Analysis は、Artifact Registry と Container Registry のイメージの脆弱性スキャンを提供します。

4. Kubernetes は引き続き、エッジへの拡大、コプロセッサの活用、パブリック クラウドとプライベート クラウドにわたる効率的な運用を行います。

最後に、エッジでの Kubernetes、コプロセッサでの Kubernetes、パブリック クラウドとプライベート クラウドの間の適切なバランスを見つけることなど、いくつかのテーマが挙げられた分野からの質問を集めました。

エッジでの Kubernetes

Kubernetes の可能性は、すでにエッジで実現されています。たとえば、Kubernetes は通信業界や小売業界のエッジで使用されています。エッジのセキュリティが懸念されていることに対し、Eric は「Kubernetes は効果的に保護することはできますが、結局フルスタックになります」と説明しました。ルート オブ トラストを通じてハードウェアを保護し、そこで動作するスタックをすべて保護することで、セキュリティを強化できます。

Google Cloud はこの分野への投資を続けています。Google は Next 2021 で、Google Cloud のインフラストラクチャとサービスをエッジに拡張する、ハードウェアとソフトウェアのフルマネージド ソリューションのポートフォリオである Google Distributed Cloud を発表しました。これは、GKE が主要なコンポーネントとなっている Anthos で実現します。ローカルデータ処理、エッジ コンピューティング、オンプレミス モダナイゼーションや、主権、厳格なデータ セキュリティ、プライバシーについての要件を満たすために最適です。エッジでの Kubernetes を安全に使用するために、Distributed Cloud は、Google のエッジ ネットワーク、オペレータ エッジ（通信サービス プロバイダ パートナーが提供する 5G と LTE のサービス）、または小売店、工場現場、支店などの独自のエッジで、クラスタの設定と管理を集中的に行います。

コプロセッサで動作する Kubernetes

また Google は NVIDIA と提携し、エッジで Anthos を運用するための、GPU アクセラレーションによるコンピューティングとネットワーキングのソリューションを提供しています。これは Kubernetes におけるコプロセッサの可能性を示しています。Eric は、コプロセッサがコンピューティングの未来にとって重要な役割を果たすと考えています。ムーアの法則の終焉を迎えつつある中で、それを補うために、業界はグラフィックス処理（GPU によるもの）または機械学習（TPU によるもの）などのユースケース向けに高速化された、ドメイン固有のハードウェアを採用しています。

パブリック クラウドとプライベート クラウドの間の適切なバランス

こうした急速なイノベーションがあっても、企業はパブリック クラウドとプライベート ソブリン クラウドでの運用のバランスを取るうえで難しい問題に直面しています。Eric は、パブリック クラウドの方が多くのメリットをもたらすことについて明確な理由を説明しています。

とはいえ、パブリック クラウド プロバイダを利用するということは、クラウド プロバイダと、そのプロバイダの拠点の政府（現在、通常は米国）を信頼しなければならないということになります。信頼できない場合やリスクが高すぎると思われる場合、自国において、プライベートなソブリン クラウド上で運用することをおすすめします。素晴らしいことに、Kubernetes はプライベート クラウドでの運用に適しています。Eric が構築を支援した Anthos は Kubernetes を、ハイブリッド環境とマルチクラウド環境向けに GKE で運用したり、ベアメタルで運用したりできます。ベンダー ロックインが心配な場合は、Anthos から移行して、オンプレミスの Kubernetes で引き続きアプリケーションを運用できます。

Google Cloud の次の外部化プロダクトに関する Eric の予測やクラウド コンピューティングの未来については、上の動画をご覧ください。Eric の Google での研究内容については、Twitter（@eric_brewer）をフォローすることで最新情報を確認できます。  

また、@stephr_wong で最新のコンテンツについての情報を確認できます。

-デベロッパー アドボケイト Stephanie Wong