この記事は「Extending Kubernetes for a new developer experience(2019年2月8日公開)」の翻訳です。

Istio と Knative are が Kubernetes の開発手法を変えつつある理由

Kubernetes がコンテナー・ベースのアプリケーションをホストするプラットフォームとして事実上の標準になっているのは周知の事実です。Kubernetes クラスターを管理していて、カスタイマイズを加えたことがあるとすればご存知だと思いますが、Kubernetes には多くの拡張ポイントがあります。あるいは、カスタム・スケジューラーなどの機能を独自に開発することもできます。さらに独自のカスタム・リソース定義 (CRD) を作成して Kubernetes リソース・モデルを拡張し、新しいカスタム・リソースを管理するコントローラーを作成することだって可能です。このように、Kubernetes を拡張する方法はさまざまに用意されていますが、そのほとんどで目的とされているのは、ホスティング環境としての Kubernetes 自体のメリット、つまり Kubernetes 内で実行されているアプリケーションを管理しやすくすることです。最近、Kubernetes アプリケーション開発者向けの 2 つの新しいプロジェクトが登場しました。この 2 つが組み合わさると、Kubernetes の使い方と見方は大幅に変わってくるはずです。

両方のプロジェクトを探り、これらのプロジェクトが Kubernetes アプリケーション開発者の日々の作業に大きな変化をもたらす可能性がある理由を明かにしましょう。

Istio: 次世代のマイクロサービス・ネットワーク管理

Istio は 2017 年に IBM、Google、Lyft の共同開発によって誕生しました。Istio は、言語に依存せずにマイクロサービスを接続、保護、管理、モニタリングできるようにすることを目的としたオープンソース・プロジェクトです。Envoy、Prometheus、Grafana、Jaeger などのオープン・テクノロジーを採り入れて作成された Istio は、サービス・メッシュとして次の機能を提供します。

  • トラフィックの管理 (カナリア・デプロイメント、A/B テストなど)
  • さまざまなマイクロサービス全体にわたる詳細なメトリックとトレースの収集、視覚化、エキスポート
  • サービスの認証、許可、自動トラフィック暗号化
  • メッシュ全体のポリシー適用 (レート制限、ホワイト/ブラックリスト登録など)

Istio では以上をはじめとする多数の機能を、アプリケーション自体に変更を加えることなく使用できるようになっています。Istio では Kubernetes を拡張する手段として、新しく導入された CRD と Envoy プロキシー・サイドカーの注入を使用します。アプリケーションの隣りで稼動するサイドカーで、アプリケーションを制御および管理するという仕組みです。

Istio 内部の仕組みを見ると、Istio のアーキテクチャーは次の 2 つのプレーンに分かれていることがわかります。

  • データ・プレーンは一連のインテリジェント・プロキシー (Envoy) からなります。Envoy がサイドカーとしてデプロイされて、マイクロサービス間のネットワーク通信を一貫して調整、管理します。
  • コントロール・プレーンは実行時にプロキシーを管理、構成し、トラフィックのルーティングとポリシーの適用に対処します。

Istio のアーキテクチャーには次のコンポーネントも含まれています。

  • Envoy – プロキシーとしてアプリケーションと並んで実行されるサイドカー
  • Pilot – Envoy を構成してシステム全体に伝播するコンポーネント
  • Mixer – ポリシーとアクセス制御を担当し、テレメトリー・データを収集するコンポーネント
  • Citadel – ID、暗号化、資格情報を管理するコンポーネント
  • Galley – Istio API 構成を作成したユーザーを検証するコンポーネント

どの 1 つだけをとってもかなり画期的なコンポーネントの数々です (このことから、業界では Istio が大きな話題となっています)。けれどもすべてのコンポーネントは共通して、Kubernetes クラスターとアプリケーションの管理タスクを担当する DevOps エンジニア/オペレーターをターゲットとしています。実に、ごく普通のソフトウェア開発者でも自力で Istio のルーティングとポリシーを構成できるようになっていますが、実際のところ平均的な開発者がこうした構成を行うことはないでしょう。そうしようと思っても、実際には手をつけないはずです。開発者が望むのは、アプリケーションのコードに集中することであって、ネットワーク構成の管理に伴うあらゆる詳細を扱うことではありません。

そうとは言え、Istio は、Kubernetes には欠けていた、マイクロサービスを管理するために必要な数多くの機能を追加するのは確かです。実際、Istio は Kubernetes に目立った変化をもたらしていて、Kubernetes を、開発者が構成を一切行わずにコードをデプロイできるシームレスなプラットフォームへと変身させつつあります。Kubernetes と同じく、Istio は明確な目的を持ち、その目的を上手く果たしています。Istio を 1 つのビルティング・ブロック、あるいはスタックを構成する 1 つのレイヤーとして捉えると、Istio をベースに新たなテクノロジーを生み出すことができます。そのために必要となってくるのが Knative です。

Knative: アプリケーションを管理するための新たな手段

Istio と同じように、Knative は次の重要な機能を新に追加して Kubernetes を拡張します。

  • 新しい抽象化によるアプリケーション・デプロイメントの定義。「ゼロまでのスケーリング」をはじめ、アプリケーションのリソース使用率の最適化を目的とした一連のリッチな機能を使用可能にします。
  • Kubernetes クラスター内でコンテナー・イメージをビルドする機能。
  • イベント・ソース登録の簡易化。アプリケーションでイベント・ソースを簡単に登録して、そのイベントを受信できます。

上記の最初の項目から説明すると、Knative では「Serving」と呼ばれるコンポーネントによって、アプリケーションを実行、公開、スケーリングします。これを可能にするために、「Service」という名前の新しい Knative リソースが定義されています (Kubernetes のコア・リソース「Service」と混同しないでください)。Knative の「Service」はアプリケーション用に実行するイメージとそのイメージを管理するメタデータを定義するという点で、実際には Kubernetes の「Deployment」に近いものです。

Knative Service と Deployment の重要な違いは、Service が使用されていないことをシステムが検出すると、インスタンス数 0 にまで Service をスケールダウンできるという点です。サーバーレス・プラットフォームを十分に理解している方にとって、このコンセプトは「ゼロまでのスケールダウン」機能と同じです。つまり、常に少なくとも 1 つのインスタンスを稼動させる必要がなくなるため、その分のコストを節約できます。このことから、Knative はサーバーレス・ホスト環境として話題に上ることがよくあります。実際のところ、Knative は (「Functions」だけでなく) あらゆるタイプのアプリケーションをホストできますが、サーバーレスは Knative の設計自体を強く推し進めている使用ケースの 1 つです。

Knative Service 内には、アプリケーションのバージョンを切り替える「ロールアウト」戦略を指定することもできます。例えば、最初はアプリケーションの新しいバージョンに着信ネットワーク・リクエストのごくわずかな割合だけをルーティングして、徐々にその割合を増やしていくことができます。それには、Istio を使用してこの動的なネットワーク・ルーティングを管理します。これに加え、Service に「ルート」またはエンドポイント URL を組み込むこともできます。このエンドポイントに関連する Kubernetes と Istio のネットワーキング、負荷分散、トラフィック分割は、実質的に Knative がすべてセットアップすることになります。

Knative Service の最大の特徴の 1 つは、デプロイメントに使用するイメージの数を指定してビルドできることです。Kubernetes Deployment では、イメージがすでにビルドされていて、何らかのコンテナー・イメージ・レジストリーから取得できることが前提とされます。けれどもこの前提を満たすためには、開発者がアプリケーションのデプロイメントとは別にビルド・プロセスを用意しなければなりません。Knative Service を使用すれば、このすべてのプロセスを 1 つに結合できるため、開発者の時間とリソースが節約されます。

Service から参照されるこの「ビルド」コンポーネントが、Knative プロジェクトの 2 つ目の重要なコンポーネントです。開発者は必要に応じて、どのようなタイプのビルド・プロセスでも柔軟に定義できますが、ビルドのステップは開発者が現在行っている方法とほとんど変わりません。つまり、アプリケーション・コードをリポジトリー (GitHub など) から抽出し、それをコンテナー・イメージにビルドした後、イメージ・レジストリーにプッシュするという方法です。けれども Knative の場合、このすべてのビルド・ステップを Service リソース内で完了できるため、別途管理するワークフローが不要になります。

こうしたプロセスの自動化に関連してくるのが、3 つ目に紹介する Knative プロジェクトの最後のコンポーネント、「Eventing」です。このコンポーネントを使用すれば、イベント・プロデューサーへのサブスクリプションを定義して管理し、受信したイベントをアプリケーションの間で割り振る方法を制御できます。たとえば、受信イベントを該当する 1 つのアプリケーションに直接送信することも、関連する複数のアプリケーションに送信することもできます。さらに、複数のイベント・コンシューマーが関与する複雑なワークフローに組み込むことさえ可能です。

以上の説明をすべて踏まえると、これらすべてのコンポーネントを連動させることで、アプリケーションのライフサイクル全体のワークフローを定義できることは明らかです。

最も単純なシナリオは次のようになります。

  1. 開発者がコードの新しいバージョンを GitHub リポジトリーにプッシュします。
  2. コードがプッシュされた結果として、GitHub イベントが生成されます。
  3. Knative がプッシュ・イベントを受信します。このイベントがコードと一緒に渡されて、新しいリビジョン/バージョンのアプリケーションが定義されます。
  4. 新しいリビジョンのアプリケーションに応じた新しいバージョンのコンテナー・イメージがビルドされます。
  5. ビルドが完了すると、この新しいイメージがカナリア・テスト用の環境にデプロイされます。その後は、古いバージョンのアプリケーションをシステムから削除できるようになるまで、新しいバージョンへの負荷が徐々に増やされていきます。

このワークフロー全体を Kubernetes 内で実行して管理することができるため、アプリケーションと併せてコードのバージョン管理を実施できます。開発者の観点からは、アプリケーションを定義する 1 つの Knative Service リソースだけを扱うだけで済みます。Kubernetes を単独で使用する場合、開発者は一般に多数のリソース・タイプを定義しなければなりませんが、Knative によってその負担がなくなるのです。

以上で説明した Knative の一連の機能はかなり見事なものですが、Knative 自体は (Kubernetes と同じく) コミュニティーで利用できるように用意された単なるビルディング・ブロックのセットです。Knative は一連の拡張ポイントを使用してカスタマイズや高度なツールを開発できるように設計されているだけに過ぎません。

今後の展望

Istio と Knative の開発を差別化する理由は、この 2 つは互いに補完して、アプリケーション開発者の日々の作業を楽にすることに重点を置いているという点です。Kubernetes と同じで、多くの開発者 (特に CloudFoundry などの他のプラットフォームを扱った経験がある場合) は初めて取り組む時点でそのコンセプトの多さに怖気づいてしまうでしょう。ポッド、replicaSet、Deployment、Ingress、Endpoint、Service、Helm の全体にわたり、学習して理解しなければならない数多くのコンセプトがあります。コードをホストすることだけが目的の開発者にとっては、その価値以上に苦労が多いように思えるかもしれません。けれども Knative を導入し、Knative で Istio を利用すれば、開発者は DevOps のエキスパートではなく本来のアプリケーション開発者に戻る上で大きな前進となります。この 2 つのプロジェクトが成熟するにつれ、コミュニティーがどのような反応を見せるのか楽しみです。

ディスカッションに参加する

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です