Google Cloud

Google メンバーが語る Kubernetes 1.10 の新機能

2018年5月7日

Google Cloud Japan Team

Kubernetes が CNCF インキュベーションを卒業してから数週間後に、Kubernetes コミュニティは Kubernetes 1.10 を発表しました。CNCF の創設者で Kubernetes 開発の主要メンバーでもある Google は、Kubernetes 1.10 でも最大のコントリビューターであると同時に、コントリビューションの査読者、コミュニティメンバーに対するメンターであり続けています。

活気のあるコミュニティを育てれば、オープンでポータブルなプラットフォームを提供するのに役立ちます。それによってどこでも同じようにワークロードを実行できるようになれば、それは結果的にユーザーのためになります。

この投稿では、私たち Google も開発に貢献した Kubernetes 1.10 の新機能について紹介します。

コンテナストレージプラグイン

Kubernetes 1.10 における CSI（Container Storage Interface）の Kubernetes 実装はベータに移行しました。サードパーティのストレージプロバイダーにとっては、CSI を使用すれば Kubernetes コードベースの外でソリューションを開発できるようになります。これらのストレージプラグインはコアコードベースから切り離されているため、それらをインストールすることは、クラスタにポッドをデプロイするのと同じくらい簡単です。

CSI 仕様とその Kubernetes 実装の両方を主導した Saad Ali（SIG-Storage 議長）は、「Kubernetes は、さまざまなタイプのブロック / ファイルストレージを簡単に使えるようにする強力なボリュームプラグインシステムを持っています。新しいボリュームプラグインのサポートは難しい作業でしたが、CSI の採用により、Kubernetes のボリュームレイヤは最終的に真に拡張可能になりました。サードパーティは、Kubernetes のコアコードベースに触れることなく、新しいストレージシステムを Kubernetes に認識させるプラグインを作り、デプロイできるようになりました。これで、Kubernetes と Kubernetes Engine のお客様は、ステートフルなコンテナワークロードを支えるストレージをさまざまな製品から選べるようになるはずです」と語っています。

カスタムリゾルバーの設定

複雑な外部ディスカバリシステムを使わず、単純な DNS 名でサービスを参照できることは、Kubernetes の大きな特徴の 1 つです。この機能は内部名にとっては非常に大きな意味がありますが、Kubernetes Engine をお使いの一部のお客様からは、主として外部名をルックアップするワークロードのために内部 DNS サーバーに過負荷がかかる原因になっているとのご指摘がありました。

そこで、Kubernetes 1.10 ではポッド単位でリゾルバーをカスタマイズできるようになりました。担当者の Zihong Zheng は「Kubernetes のユーザーは望み次第でこのトレードオフを避け、使いやすさと柔軟性を両立させられるようになりました」と述べています。この機能は上流で作られているため、どこで実行するかにかかわらず、すべての Kubernetes ユーザーが利用できます。

Device Plugins と GPU サポート

デバイスベンダーが Kubernetes コアコードに変更を加えずに自社リソースの存在を kubelet に通知できる Device Plugins 機能も、1.10 でベータ段階へと進みました。Device Plugins の主要なユースケースは Kubernetes への GPU の接続です。

Google で Device Plugins の feature lead を務める Jiaying Zhang は、デバイスベンダーと密接に連携して彼らのニーズを理解し、共通要件を洗い出したうえで実行プランを立て、本番使用に耐えるシステムを OSS コミュニティと共同で構築しました。

Kubernetes Engine の GPU サポートは Device Plugins フレームワークの上に構築されており、Kubernetes 1.10 でのベータへの移行に際しては早期試用ユーザーの意見が反映されています。

API エクステンション

Google の Daniel Smith（SIG-API Machinery 共同議長）が初めて API エクステンションのアイデアを提案したのは、Kubernetes がオープンソース化されてから 2 か月後のことでした。今では、Kubernetes API の拡張方法は Custom Resource Definitions（CRD : 旧称 Third-Party Resources）と API Aggregation（Kubernetes 1.10 で GA に移行）の 2 つになっています。

Service Catalog や Metrics Server などのエコシステム拡張で使われている Aggregation は、独立した形で構築された API サーバーバイナリを、Kubernetes マスター経由でホスティングできるようにするものです。API サーバーはマスターと同じ認可、認証、セキュリティ設定を使用できます。

Daniel は今後のスケジュールについて、「私たちは、1.7 以降のすべての Google Kubernetes Engine クラスタで難なく Aggregation レイヤを動かしてきているので、このメカニズムを GA に移行する潮時が来たと考えています。完成された拡張ソリューションを提供するための仕事にも取り組んでおり、年末までに CRD と Admission Control Webhooks を GA に進めるつもりです」と語っています。

Kubernetes を使った Spark ワークロードの実行

Google のオープンな Kubernetes エコシステムへのコントリビューションは、Kubernetes プロジェクト本体を超えて広がっています。Anirudh Ramanathan（SIG-Big Data 議長）は、Apache Spark 2.3 の目玉機能であるネイティブ Kubernetes サポートの上流部分の実装を主導しました。また、私たちは Yinan Li とともに、Kubernetes 流のやり方で Spark ワークロードを実行できるようにする Spark Operator の開発にも熱心に取り組んでいます。

Bobby Salamat（SIG-Scheduling 議長）と David Oppenheimer（Borg 論文共著者）が実装した Priority と Preemption 機能を組み合わせれば、クラスタの効率向上にもつながるでしょう。クラスタにフリーリソースがあるときに限り、Spark でバッチ処理をスケジューリングするようにすれば、クラスタの使用効率を高めることができます。

コミュニティの育成

Google は Kubernetes プロジェクトの啓蒙活動にも力を注いでいます。その 1 つが Outreachy で、IT では伝統的に少数派だったグループの人々の技術スキル習得を、オープンソースプロジェクトへのコントリビューションを通じて支援するというインターンシッププログラムです。

Kubernetes の SIG-CLI は、Kubernetes 1.10 のタイムフレームに合わせて、Google の Antoine Pelisse をメンターとする Outreachy に参加しました。そして、彼の指導のもとで、カメルーンの Yolande Amate とブラジルの Ellen Korbes が、“kubectl create” と “kubectl set” コマンドの改良という課題に取り組みました。

インターンシップ終了後、Ellen は栄えある Kubernetes プロジェクトメンバーとなりました（コントリビューションまでの道筋の連載記事をこちらのブログに書いています）。一方、Yolande は引き続き PR を提出し、メンバーになるために頑張っています。