このトピックでは、Container Service for Kubernetes (ACK) クラスターで Knative を使用する際のよくある質問 (FAQ) とその回答を記載しています。
目次
Alibaba Cloud Knative とオープンソース Knative の違い
Alibaba Cloud Knative はオープンソース Knative と互換性があり、O&M、ユーザビリティ、弾力性、ゲートウェイ、イベント駆動アーキテクチャ、モニタリングとアラートに関して、さまざまな拡張機能を提供します。詳細については、「Alibaba Cloud Knative とオープンソース Knative の比較」をご参照ください。
Knative の Ingress の選択
Alibaba Cloud Knative は、Application Load Balancer (ALB)、Alibaba Cloud Service Mesh (ASM)、Kourier の 3 種類の Ingress をサポートしています。ALB はアプリケーション層のロードバランシングシナリオに重点を置いています。ASM はサービスメッシュ (Istio) 機能を提供します。基本的な Ingress 機能のみが必要な場合は、Kourier を選択してください。詳細については、「Knative の Ingress の選択」をご参照ください。
RAM ユーザーまたはロールに必要な権限
クラスター内のすべての名前空間にアクセスする権限が必要です。次の手順で必要な権限を付与します。
ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[権限付与] をクリックします。
RAM ユーザー タブをクリックします。RAM ユーザーのリストで、対象の RAM ユーザーを見つけ、アクセス権限の管理 列の アクセス権限の管理 をクリックします。
ロール権限の追加 セクションで、対象のクラスターを選択し、ロール権限の追加 で ロール権限の追加 を選択して、権限付与を完了します。
Pod のゼロへのスケール時間
Pod がゼロにスケールするまでにかかる時間は、次の 3 つのパラメーターによって決まります。
stable-window：スケールイン操作が実行される前にメトリクスが監視および評価される時間枠です。システムは、この時間枠の間は即座にアクションを実行しません。scale-to-zero-grace-period：ゼロにスケールする前の猶予期間です。この期間中、システムは新しいリクエストが受信されなくても、最後の Pod をすぐに停止または削除しません。これは、突然のトラフィックバーストを処理するのに役立ちます。scale-to-zero-pod-retention-period：最後の Pod がゼロにスケールするまでの保持期間です。これにより、システムはコールドスタートなしで突然のトラフィックバーストに迅速に応答できます。
Pod がゼロにスケールするには、トラフィックがない状態が一定期間続く必要があります。このプロセスには、以下の3つの主要な条件が関わっています。
stable-windowの期間、リクエストが受信されない。scale-to-zero-pod-retention-periodで指定された保持期間が経過する。scale-to-zero-grace-periodで指定された猶予期間が経過する。
Pod が保持される期間は、計算式 stable-window + Max("scale-to-zero-grace-period", "scale-to-zero-pod-retention-period") の結果を超えません。最後の Pod に特定の保持期間を適用するには、scale-to-zero-pod-retention-period パラメーターを使用します。
Knative での GPU リソースの使用
Knative Service の spec で、spec.template.metadata.annotations の下に k8s.aliyun.com/eci-use-specs アノテーションを追加して、GPU インスタンスタイプを指定します。次に、spec.containers.resources.limits の下にある nvidia.com/gpu を使用して GPU リソース制限を宣言します。
詳細については、「GPU リソースの使用」をご参照ください。
Knative での GPU 共有の使用
「GPU 共有スケジューリングの例の実行」をご参照のうえ、ノードの GPU 共有スケジューリングを有効にします。次に、Knative Service で、aliyun.com/gpu-mem フィールドを使用してリソース制限を設定します。詳細については、「GPU 共有スケジューリングの有効化」をご参照ください。
コールドスタートレイテンシーの削減
デフォルトでは、オープンソース Knative は受信リクエストがない場合にアプリケーションインスタンスの数をゼロにスケールします。これにより、アイドル状態のインスタンスを実行するコストを削減できます。新しいリクエストが到着すると、新しいインスタンスがアプリケーションに割り当てられます。このプロセスには、IaaS リソースの割り当てとスケジューリング、アプリケーションイメージのプル、アプリケーションの起動が含まれ、コールドスタートとして知られる長いレイテンシーが発生します。
ビジネスがコールドスタートレイテンシーの影響を受けやすい場合は、次の 2 つのソリューションのいずれかを使用できます。
リザーブドインスタンスの設定：低コスト、低仕様の バーストパフォーマンスインスタンス を実行し続けることで、コストとコールドスタートレイテンシーのバランスを取ります。最初のリクエストが到着すると、リザーブドインスタンスがリクエストを処理する間に、デフォルト仕様のインスタンスがスケールアップされます。デフォルトのインスタンスの準備が整うと、すべての新しいリクエストはそこにルーティングされます。リザーブドインスタンスは、リクエストの処理後に自動的に解放されます。詳細については、「リザーブドインスタンスの設定」をご参照ください。
Elastic Container Instance (ECI) のイメージキャッシュ機能の使用：事前にイメージのキャッシュスナップショットを作成し、そのスナップショットに基づいて ECI インスタンス (Pod) を作成することで、イメージレイヤーのダウンロードを回避または削減できます。これにより、インスタンスの作成が高速化されます。詳細については、「イメージ高速化によるインスタンス作成の高速化」をご参照ください。
Activator コンポーネントの課金
はい。Activator コンポーネントはデータプレーンコンポーネントであり、Pod として実行されてインスタンスリソースを消費します。
リッスンポートの設定
アプリケーションのリッスンポートは、Knative Service の containerPort と一致している必要があります。デフォルトは 8080 です。カスタムリッスンポートを設定するには、「カスタムリッスンポートの設定」をご参照ください。