ついに誰かがKnativeをわかりやすく説明してくれた

基本情報は表2-2に示します。

▼表2-2 Knative基本情報

Knative の非常に重要な目標は、クラウドネイティブでクロスプラットフォームのサーバーレス オーケストレーション標準を開発することです。 Knative は、コンテナ構築 (または機能)、ワークロード管理 (および動的スケーリング)、およびイベント モデルを統合することで、サーバーレス標準を実装します。 Knative コミュニティの主な貢献者には、Google、Pivo​​tal、IBM、Red Hat などがあります。 CloudFoundryやOpenShiftなどのPaaSプロバイダーがKnativeの構築に積極的に参加しています。

1. 動作原理

図 2-14 に示すように、Knative は Kubernetes と Istio プラットフォーム上に構築され、Kubernetes が提供するコンテナ管理コンポーネント (デプロイメント、レプリカセット、ポッドなど) と Istio が提供するネットワーク管理コンポーネント (イングレス、LB、動的ルートなど) を使用します。

Knative には、トラフィックを提供する Serving コンポーネントと、アプリケーションがイベントを簡単に生成および消費できるようにする Event コンポーネントという 2 つの重要なコンポーネントがあります。

その中で、Serving コンポーネントは、負荷に基づいて自動的にスケーリングされ、負荷がない場合にはゼロに削減されるなど、複数のリビジョン アプリケーションのトラフィック ポリシーを作成して、URL 経由でターゲット アプリケーションに簡単にルーティングできます。また、イベント コンポーネントを使用すると、イベントの生成と使用が容易になり、オペレーターは任意のメッセージング レイヤーを使用できるようになります。

Serving および Event コンポーネントに加えて、Build も Kantive のコンポーネントの 1 つです。 「完了まで実行」表示機能を提供します。これは、CI/CD ワークフローの作成や、柔軟なプラグイン ビルド システムを通じてユーザー ソース コードをコンテナーにビルドする場合に役立ちます。

現在、Docker Daemon を実行せずに Kubernetes クラスター上でコンテナ イメージを構築できる Google の Kaniko など、複数のビルド システムをすでにサポートしています。 Serving はこれを使用して、ソース リポジトリをアプリケーションを含むコンテナー イメージに変換します。

多くのサーバーレス オープンソース プロジェクトの中で、Knative の利点も非常に明白です。一方、Knative は Kubernetes を基盤フレームワークとして使用し、Kubernetes エコシステムとより密接に統合されています。クラウド上の Kubernetes サービスでも、独自に構築した Kubernetes クラスターでも、Knative プラグインをインストールすることで、サーバーレス プラットフォームをすばやく構築できます。

一方、Knative は CNCF と連携してすべてのイベントを CloudEvent として標準化し、特定の呼び出しメソッドから関数を切り離しながらクロスプラットフォームのイベント実行を提供します。弾力性に関しては、Knative はアプリケーション要求を監視し、容量を自動的に拡張できます。 Istio (Ambassador、Gloo など) の助けを借りて、ブルーグリーンリリースとロールバック機能をサポートし、アプリケーションのリリースを容易にします。

同時に、Knative はログの収集、検索、分析、および VAmetrics データの表示と通話関係の追跡をサポートします。

図2-14はKnativeの動作原理を示しています。

図2-14 Knativeの動作原理

2. 機能と戦略

（1）サービング

Serving モジュールは、Revision、Configuration、Route、Service などの特定のオブジェクト セットを定義します。 Knative は、Kubernetes CRD (カスタム リソース) を通じてこれらの Kubernetes オブジェクトを実装します。すべての Serving コンポーネント オブジェクト間の関係については、図 2-15 を参照してください。

▲図2-15 サービングコンポーネントオブジェクトの関係

Knative Serving は構成から始まります。ユーザーは、構成でデプロイされたコンテナの望ましい状態を定義します。最小限の構成は、少なくとも構成名と、デプロイするコンテナ イメージへの参照で構成されます。

Knative では、定義された参照は Revision です。リビジョンは、特定の時点におけるコードと構成の変更されていないスナップショットを表します。各リビジョンは、特定のコンテナ イメージと、それを実行するために必要な特定のオブジェクト (環境変数やボリュームなど) を参照します。ただし、ユーザーは明示的にリビジョンを作成する必要はありません。リビジョンは不変であり、変更または削除することはできません。

逆に、ユーザーが構成を変更すると、Knative はリビジョンを作成します。これにより、構成はワークロードの現在の状態を反映するとともに、履歴リビジョン リストを維持するために使用できるようになります。

Knative の Route は、実行中のコードにトラフィックをルーティングするメカニズムを提供します。 HTTP アドレス指定可能なエンドポイントを 1 つ以上のリビジョンにマッピングします。構成自体はルートを定義しません。

（２）弾性スケーリング

サーバーレス アーキテクチャの重要な原則は、ニーズに合わせてオンデマンドで拡張し、リソースを節約できることです。サーバーレス負荷は常にゼロまでスケールダウンできる必要があります。つまり、リクエストが届かない場合は、コンテナ インスタンスは実行されません。図 2-16 に示すように、Knative はこの機能を実装するために 2 つの主要コンポーネントを使用します。クラスター内のポッドとして Autoscaler と Activator を実装します。

▲図2-16 Knativeの弾性スケーリング原理図

ユーザーは、これらが他の Serving コンポーネントとともに knative-serving 名前空間で実行されていることを確認できます。オートスケーラーは、リビジョンに到達する同時リクエストの数に関する情報を収集します。これを行うには、Revision Pod 内で queue-proxy と呼ばれるコンテナを実行します。 Pod はユーザーが提供するイメージも実行します。

キュー プロキシは、リビジョンで観察された同時実行性を検出し、このデータを毎秒オートスケーラーに送信します。オートスケーラーはこれらのメトリックを 2 秒ごとに評価し、評価結果に基づいてリビジョンのデプロイメントのサイズを増減します。デフォルトでは、Autoscaler はポッドあたり 1 秒あたり平均 100 件の同時リクエストを維持しようとします。これらの同時実行ターゲットと平均同時実行ウィンドウは両方とも変化する可能性があります。

Autoscaler は、Kubernetes HPA (Horizo​​ntal Pod Autoscaler) を使用してデフォルト構成を置き換えることもできます。これは CPU 使用率に基づいて自動的にスケールされますが、ゼロまでスケールダウンされることはありません。これらの設定は、リビジョン メタデータ注釈を通じてカスタマイズできます。

Autoscaler で使用されるスケーリング アルゴリズムは、2 つの別々の時間間隔のすべてのデータ ポイントの平均を計算します。 60 秒と 6 秒の 2 つの時間ウィンドウを維持します。 Autoscaler は、安定モードとパニック モードの 2 つのモードで動作します。安定モードでは、60 秒間の平均値を使用して、予想される同時実行性を満たすためにデプロイメントをスケーリングする方法を決定します。

6 秒間のウィンドウ内の平均同時実行数が目的のターゲットに 2 回達すると、Autoscaler はパニック モードに切り替わり、6 秒間のウィンドウを使用します。これにより、突然のトラフィックの増加にもより迅速に対応できるようになります。また、ポッド数の急激な変動を防ぐために、パニック モードでのみスケーリングされます。 60 秒以上拡張が行われない場合、Autoscaler は安定モードに戻ります。

（３）ビルド

Knative の Serving コンポーネントはコンテナーから URL にアクセスする方法を解決し、Build コンポーネントはソース コードからコンテナーにアクセスする方法を解決します。ビルド リソースを使用すると、ユーザーはコードをコンパイルしてコンテナーをビルドする方法を定義できます。これにより、コンテナ レジストリに送信される前に、コードが一貫した方法でコンパイルおよびパッケージ化されることが保証されます。ここにいくつかの新しいコンポーネントがあります。

• ビルド: ビルド プロセスを実行するカスタム Kubernetes リソース。ビルドを定義する際、ユーザーはどのように

ソース コードと、コードを実行するためのコンテナー イメージを作成する方法を取得します。

• ビルド テンプレート: 繰り返し可能なビルド ステップをカプセル化し、ビルドをパラメーター化できるようにするテンプレート。
• サービス アカウント: Git リポジトリやコンテナ イメージ ライブラリなどのプライベート リソースへの認証を許可します。

（4）イベント

これまで、基本的な HTTP リクエストをアプリケーションに送信することは、Knative 関数を使用する有効な方法でした。サーバーレスの疎結合の性質は、イベント駆動型アーキテクチャにも適用されます。つまり、ファイルが FTP サーバーにアップロードされるたびに関数を呼び出す必要がある場合があります。または、支払いと在庫の更新を処理するために、商品が販売されるたびに関数を呼び出す必要がある場合もあります。

アプリケーションや関数にイベントをリッスンするロジックを考慮させるのではなく、関心のあるイベントが発生したときに Knative に処理させて通知させる方が適切です。

これらの機能を自分で実装するには、多くの作業と、特定の機能を実装するためのコードの記述が必要になります。幸いなことに、Knative はイベント処理の利用を容易にする抽象化レイヤーを提供します。

Knative は、メッセージ ブローカーを選択するための特定のコードを記述する必要なく、「イベント」を直接提供します。イベントが発生すると、アプリケーションはイベントの発生元や送信先を気にする必要はなく、イベントが発生したことだけを知る必要があります。図 2-17 に示すように、この目標を達成するために、Knative はソース、チャネル、サブスクリプションという 3 つの新しい概念を導入します。

• ソース: イベントの発生元。イベントが生成される場所と、関係者にイベントがどのように配信されるかを定義します。
• チャネル: チャネルはバッファリングと永続性を処理し、サービスがシャットダウンされた場合でもイベントが目的のサービスに配信されるようにします。さらに、チャネルは、コードと基盤となるメッセージング ソリューション間の抽象化レイヤーです。つまり、Kafka や RabbitMQ などの特定のサービス間でメッセージを交換できますが、どちらの場合も特定の実装コードを記述する必要はありません。
• サブスクリプション: ソースはチャネルにイベントを送信し、サービスはそれを処理する準備ができていますが、現在、チャネルからサービスに送信されたイベントを取得する方法はありません。この目的のために、Knative はサブスクリプション機能を設計しました。サブスクリプションはチャネルとサービス間の接着剤であり、システム全体でイベントを管理する方法を Knative に指示します。

▲図2-17 Knativeイベント処理モデル図

Knative のサービスでは、イベントやリクエストがどのように取得されるかは考慮されません。 Ingress ゲートウェイから HTTP リクエストを取得し、チャネルから送信されたイベントも取得できます。取得方法に関係なく、サービスは HTTP リクエストのみを受信します。これは Knative における重要な分離方法です。これにより、最下位レベルでサブスクリプションとチャネルを作成してサービスにイベントを送信するのではなく、コードがアーキテクチャに書き込まれるようになります。

著者について: Liu Yu (ニックネーム: Jiang Yu) は、国立国防科学技術大学で電子情報の博士号を取得しており、Alibaba Cloud のサーバーレス製品のエクスペリエンスを担当しています。長年にわたりサーバーレス関連の業務に従事し、Alibaba Cloud Function Compute (FC)、Serverless Workflow (FNF) などの製品の経験を担当しています。彼は豊富な実務経験を持っています。 Alibaba Cloud の戦略的オープンソース プロジェクト Serverless Devs の発起者および責任者であり、Serverless Framework や Kubevela などのオープンソース プロジェクトへの貢献者であり、コミュニティ プロジェクト Anycodes のオンライン プログラミングの責任者です。

この記事は「Serverless Engineering Practice: From Entry to Advanced」から抜粋したもので、出版社の許可を得ています。