Knative Servingアーキテクチャ¶
Knative Servingは、サーバーレスプラットフォームの基盤を形成するいくつかのコンポーネントで構成されています。このページでは、Knative Servingのハイレベルなアーキテクチャについて説明します。詳細については、Knative Servingの概要とリクエストフローも参照してください。
図¶
コンポーネント¶
| コンポーネント | 役割 |
|---|---|
| アクティベータ | アクティベータは**データプレーン**の一部です。Knative Serviceがゼロにスケールダウンされている場合、着信リクエストをキューイングする役割を担います。ゼロにスケールダウンされたサービスを再開し、キューイングされたリクエストを転送するために、オートスケーラと通信します。アクティベータは、トラフィックバーストを処理するためのリクエストバッファとしても機能できます。詳細はこちらを参照してください。 |
| オートスケーラ | オートスケーラは、設定、メトリクス、着信リクエストに基づいてKnativeサービスをスケーリングする役割を担います。 |
| コントローラ | コントローラは、クラスタ内のKnativeリソースの状態を管理します。複数のオブジェクトを監視し、依存リソースのライフサイクルを管理し、リソースの状態を更新します。 |
| キュープロキシ | キュープロキシは、KnativeサービスのPod内のサイドカーコンテナです。メトリクスの収集と、ユーザーのコンテナへのリクエスト転送時の必要な同時実行数の強制を担当します。アクティベータと同様に、必要に応じてキューとしても機能できます。 |
| Webhook | Knative Servingには、Knativeリソースの検証と変更を担当する複数のWebhookがあります。 |
ネットワーキングレイヤーとIngress¶
注記
この場合のIngressは、Kubernetes Ingressリソースを指すものではありません。クラスタ上のリソースへの外部アクセスの公開という概念を指します。
Knative Servingは、Knativeネットワーキング仕様を満たすネットワーキングレイヤーに依存します。そのため、Knative Servingは、さまざまな複数のプラグ可能なネットワーキングレイヤーの抽象化として機能する内部KIngressリソースを定義しています。現在、コミュニティによって3つのネットワーキングレイヤーが利用可能でサポートされています。
トラフィックフローとDNS¶
注記
さまざまなネットワーキングレイヤーには微妙な違いがありますが、次のセクションでは一般的な概念について説明します。また、Ingress Gatewayを公開し、DNSを構成する方法は複数あります。詳細については、インストールドキュメントを参照してください。
- 各ネットワーキングレイヤーには、
KIngressリソースを監視し、それに応じてIngress Gatewayを構成するコントローラがあります。また、このリソースを通じてステータス情報を報告します。 Ingress Gatewayは、モード（プロキシ/サーブ、詳細はこちらを参照）に応じて、リクエストをアクティベータにルーティングするか、KnativeサービスPodに直接ルーティングするために使用されます。Ingress Gatewayは、クラスタ内とクラスタ外からのリクエストを処理します。Ingress Gatewayをクラスタの外からアクセスできるようにするには、type: LoadBalancerまたはtype: NodePortのKubernetesサービスを使用して公開する必要があります。コミュニティでサポートされているネットワーキングレイヤーには、インストールの一部としてこれが含まれています。次に、Ingress GatewayのIPまたは名前を指すようにDNSを構成します。
注記
DNSを使用/設定する場合は、Knativeにも同じドメインを設定する必要があることに注意してください。
オートスケーリング¶
オートスケーリングメカニズムの詳細については、こちらを参照してください。