Google Cloud Platform

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

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 CatalogMetrics 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 OppenheimerBorg 論文共著者)が実装した 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 を提出し、メンバーになるために頑張っています。

Kubernetes Engine でも 1.10 が利用可能に

4 月上旬、Kubernetes 1.10 の Kubernetes Engine アルファ クラスタへの提供が開始されました。いち早く本番クラスタで最新バージョンを使いたい方は、今すぐ早期試用プログラムにご参加ください。

Google Cloud Platform(GCP)と Kubernetes Engine をまだ試したことのない方は、300 ドル分の無料クレジットを活用して、ぜひお試しください。

* この投稿は米国時間 3 月 26 日、Google の Cloud Native Advocacy Lead である Craig Box によって投稿されたもの(投稿はこちら)の抄訳です。

- By Craig Box, Cloud Native Advocacy Lead, Google