ack − コーディネーターは、サービス品質 (QoS) 認識スケジューリングシステムである。 ack-koordinatorは、CPUバーストや動的リソースのオーバーコミットメントなどの機能を使用して、アプリケーションのパフォーマンスを確保しながらリソース使用率を向上させます。 これにより、クラスターの安定性も向上する。 さらに、ack-koordinatorはリソースのプロファイリングとスケジューリング解除をサポートします。 このトピックでは、ack-koordinatorを紹介し、ack-koordinatorのリリースノートについて説明します。
ack-koordinatorのリリースノートを表示するには、「リリースノート」をご参照ください。
ack-koordinatorとは
ack-koordinatorは、QoSを認識したスケジューリングシステムです。 ack-koordinatorは、リソース利用を改善し、QoSクラスに基づいてアプリケーションのリソース供給を保証します。 これにより、リソースの競合によるパフォーマンスの低下を防ぎます。 たとえば、ack-koordinatorは、サービス指向アプリケーションとバッチ処理タスクを同じノードに配置できます。 ack-koordinatorは、CPUバーストや動的リソースオーバーコミットメントなどの機能を使用して、サービス指向アプリケーションのパフォーマンスを確保しながら、リソース使用率を向上させます。 ack-koordinatorは、バッチ処理、ハイパフォーマンスコンピューティング (HPC) 、AI、および機械学習のシナリオに適しています。 ack-koordinatorは、Container Service for Kubernetes (ACK) がQoS対応スケジューリングの実装に使用する重要なコンポーネントです。 ack-koordinatorは、次の機能を有効にするためにも使用されます。CPU抑制、トポロジ認識スケジューリング、動的リソースオーバーコミットメント、負荷認識スケジューリング、デスケジューリング、およびリソースプロファイリング。
上記の機能を有効にするには、まずackコンソールにACK-koordinatorをインストールする必要があります。 次に、ConfigMapを設定するか、関連するポッド注釈を追加して、機能を有効にします。
アーキテクチャ
ack-koordinatorは、2つのコントロールプレーン (Koordinator ManagerとKoordinator Descheduler) と1つのDaemonSetコンポーネント (Koordlet) で構成されています。
Koordinator Manager: Koordinator Managerはデプロイとしてデプロイされ、高可用性を確保するためにプライマリポッドとセカンダリポッドで実行されます。
SLOコントローラ: SLOコントローラは、リソースのオーバーコミットを管理し、オーバーコミットされるリソースの量を動的に調整します。 SLO Controllerは、各ノードのSLOポリシーも管理します。
Recommender: Recommenderは、リソースプロファイリング機能を提供し、ワークロードのピークリソース需要を推定します。 Recommenderは、リソース要求の設定とコンテナの制限を簡素化します。
Koordinator Descheduler: Koordinator Deschedulerはデプロイとしてデプロイされ、スケジューリング解除を実行するために使用されます。
Koordlet: KoordletはDaemonSetとしてデプロイされ、コロケーションシナリオで動的なリソースのオーバーコミットメント、負荷認識スケジューリング、およびQoS認識スケジューリングをサポートするために使用されます。
Koord-Schedulerはack-koordinatorに含まれていません。 ack − コーディネータによって要求される関連するスケジューリング能力は、ACKスケジューラによって提供される。
ACKサーバーレスクラスターでは、ack-koordinatorはKoordinator Managerコンポーネントのみで構成され、リソースプロファイリング機能をサポートします。
バージョンの説明
ack-koordinator v1.1.1-ack.1以降では、バージョン番号はx.y.z-ackn
形式を使用します。
x.y.z
: 対応するオープンソースのコーディネーターのバージョンを示します。 つまり、ack-koordinatorはこのオープンソースバージョンで提供されるすべての機能をサポートしています。ackn
: オープンソースのコーディネーターのバージョンに基づく機能強化と最適化を示します。
条件
機能
ack-koordinatorのコンポーネントは、対応するオープンソースのKoordinatorバージョンの機能をサポートしています。 ack-koordinatorのコンポーネントをインストールして構成すると、デフォルトでは基本機能ゲートのみが有効になります。 オープンソースのコーディネーターでサポートされている高度な機能を使用するには、ack-Koordinatorの対応する機能ゲートを手動で有効にする必要があります。 オープンソースのコーディネーターでサポートされている高度な機能の詳細については、「コーディネーターの公式ドキュメント」をご参照ください。
カテゴリ | 関連ドキュメント | 説明 | 機能がオープンソースのコーディネーターバージョンと同じかどうか |
この機能は、ノードの負荷を監視し、負荷の低いノードにポッドをスケジュールして、負荷分散を実装できます。 これは、ノードの過負荷を回避する。 | 必須 | ||
この機能は、CPUスロットリングイベントを自動的に検出し、CPU制限を適切な値に自動的に調整します。 この機能を有効にすると、CPU需要が急増すると、コンテナーによって使用されるCPUリソースがCPU制限を超えてバーストする可能性があります。 これにより、コンテナのCPU供給が保証されます。 | 必須 | ||
この機能は、ポッドをノード上のCPUコアに固定します。 これは、頻繁なCPUコンテキストの切り替えと、非均一メモリアクセス (NUMA) ノード間のメモリアクセスによって引き起こされるアプリケーションのパフォーマンス低下の問題に対処します。 | 選択可能 | ||
この機能は、ノードの負荷をリアルタイムで監視し、ポッドに割り当てられているが使用されていないリソースをスケジュールします。 これにより、BEワークロード間で公平なメモリスケジューリングを確保しながら、BEワークロードのリソース要件を満たすことができます。 | 必須 | ||
動的リソースのオーバーコミットメントを有効にすると、この機能により、ノード上のBEポッドのCPU使用率を適切な範囲内に制限して、LSポッドのCPU要求に優先順位を付けることができます。 | 必須 | ||
この機能は、異なるQoSクラスを有するアプリケーション間のリソース競合を防止し、LSアプリケーションのCPU要求に優先順位を付ける。 | 必須 | ||
この機能により、ビジネス要件に基づいて異なるQoSクラスを異なるコンテナーに割り当てることができます。 これにより、公平なメモリ割り当てを確保しながら、QoSクラスの高いアプリケーションのメモリ要求に優先順位を付けることができます。 | 必須 | ||
この機能は、異なるQoSクラスのアプリケーション間のL3キャッシュ (最終レベルキャッシュ) およびメモリ帯域幅のリソース競合を防ぎ、LSアプリケーションのメモリ要求に優先順位を付けます。 | 必須 | ||
この機能により、cgroup構成ファイルを使用してポッドのリソースパラメーターを変更できます。 これにより、ポッドまたはデプロイを再起動することなく、ポッドまたはデプロイのCPUパラメータ、メモリパラメータ、およびディスクIOPSの制限を一時的に調整できます。 | 選択可能 | ||
この機能により、Intelベースのノードでのデータ集約型ワークロードのデータ処理パフォーマンスが向上します。®データストリーミングアクセラレータ (DSA) は、近くのメモリアクセスアクセラレーションのパフォーマンスを最適化します。 | 選択可能 | ||
この機能は、CPUバインドアプリケーションのリモートNUMAノード上のメモリをローカルNUMAノードに安全に移行します。 これにより、ローカルメモリのヒット率が向上し、メモリ集約型アプリケーションのパフォーマンスが向上します。 | 選択可能 | ||
この機能は、不均一なクラスターリソース使用率、高負荷ノード、新しいスケジューリングポリシーの需要などのシナリオに適しています。 スケジュール解除とは、ノードの削除ルールに一致するポッドを別のノードにスケジュールするプロセスを指します。 これにより、クラスターの健全性を維持し、リソース使用量を最適化し、ワークロードのQoSを改善できます。 | 必須 | ||
この機能は、ノードの負荷の変化を動的に監視し、負荷しきい値を超えるノードを自動的に最適化して、ノードの過負荷を防ぎます。 | 必須 | ||
GPUトポロジ認識 | この機能は、最適なNUMAノードにポッドをスケジュールします。 これにより、NUMAノード間のメモリアクセスが削減され、アプリケーションのパフォーマンスが最適化されます。 | 選択可能 | |
この機能は、履歴リソース使用量データを分析し、コンテナのリソース仕様の推奨事項を提供します。 これにより、リソース要求の設定とコンテナの制限が大幅に簡素化されます。 | 選択可能 |
インストールと管理
ack-koordinatorは、ACKコンソールの [アドオン] ページで使用できます。 [アドオン] ページで、ack-koordinatorをインストール、更新、およびアンインストールできます。
前提条件
Kubernetes 1.18以降を実行するACKクラスターが作成されます。 クラスターの更新方法の詳細については、「ACKクラスターの手動更新」をご参照ください。
Helmコンポーネントがインストールされ、コンポーネントのバージョンが3.0以降になります。 Helmバージョンを更新する方法の詳細については、「 [コンポーネント更新] Helm V2をV3に更新」および「Helmを手動で更新する方法」をご参照ください。
ack-koordinatorのインストールと管理
ack-koordinatorは、ACKコンソールのアドオンページにインストールできます。 ack-koordinatorをインストールしたら、[アドオン] ページでack-koordinatorを更新したり、ack-koordinatorの設定を変更したりできます。
ack-koordinatorをインストールするには、次の手順を実行します。 インストールの進行状況は、[アドオン] ページで確認できます。
ack-koordinator設定の変更: ack-koordinatorの設定を変更すると、ACKは新しい設定に基づいてack-koordinatorを自動的に再インストールします。
ack-koordinatorの更新: 他のメソッドを使用して、デプロイされたack-koordinatorコンポーネントのモジュールを手動で変更した場合、ack-koordinatorの更新後に変更が上書きされます。
ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
On theクラスターページで、管理するクラスターを見つけて選択します。 で、アクションクラスターの列です。
アドオンページで、ack-koordinatorを見つけてクリックします。 ack-koordinatorカードで、[インストール] をクリックします。
[ack-koordinatorのインストール] ダイアログボックスでパラメーターを設定し、[OK] をクリックします。
オプション: クラスター管理ページの左側のナビゲーションウィンドウで、[ack-koordinator] のステータスを表示します。
を選択し、[ステータス] 列に [デプロイ済み] が表示されている場合、ack-koordinatorがインストールされます。
ack-koordinatorをアンインストールする
既存のノードのトポロジConfigMapsの削除
トポロジ認識CPUスケジューリング機能は、ACKクラスター内の各ノードのkube-system名前空間にトポロジConfigMapを作成します。 ack-koordinator 0.5.1以降では、クラスターから削除されたノードのトポロジConfigMapsを自動的に削除できます。 ack-koordinatorをアンインストールすると、クラスター内の既存のノードのトポロジConfigMapsが保持されます。 保持されたトポロジConfigMapsは他の機能に影響を与えませんが、ストレージスペースを占有します。 これらのConfigMapsは、できるだけ早く削除することを推奨します。
アドオンページで、ack-koordinatorを見つけ、画面の指示に従ってack-koordinatorをアンインストールします。
トポロジConfigMapsを削除します。
左側のナビゲーションウィンドウで、
を選択します。 表示されるページで、[名前空間] ドロップダウンリストから [kube-system] を選択します。名前検索ボックスに-numa-infoと入力し、リストから
${NODENAME}-numa-info
命名規則に一致するConfigMapを選択します。 次に、[操作] 列の [削除] をクリックして、ConfigMapを削除します。
CRDの削除
ack-koordinatorをアンインストールした後、ack-koordinatorによって使用される一部のCustomResourceDefinitions (CRD) が保持される場合があります。 保持されたCRDは、他の特徴に影響を与えないが、記憶スペースを占める。 ただし、ack-koordinatorを再度インストールすると、保持されているCRDがack-koordinatorの機能に影響を与える可能性があります。 この場合、できるだけ早く、保持されているConfigMapsを削除することをお勧めします。 次の表にCRDを示します。
autoscaling.alibabacloud.com | slo.koordinator.sh |
課金
ack-koordinatorコンポーネントをインストールまたは使用する場合、料金はかかりません。 ただし、次のシナリオでは料金が請求される場合があります。
ack-koordinatorは、インストール後にワーカーノードリソースを占有する管理対象外のコンポーネントです。 コンポーネントのインストール時に、各モジュールが要求するリソースの量を指定できます。
既定では、ack-koordinatorは、リソースプロファイリングや細粒度スケジューリングなどの機能のモニタリングメトリックをPrometheusメトリックとして公開します。 ack-koordinatorのPrometheusメトリクスを有効にし、PrometheusのManaged Serviceを使用する場合、これらのメトリクスはカスタムメトリクスと見なされ、料金が課金されます。 料金は、クラスターのサイズやアプリケーションの数などの要因によって異なります。 Prometheusメトリクスを有効にする前に、Prometheusのマネージドサービスの課金トピックを読んで、カスタムメトリクスの無料クォータと課金ルールについて確認することをお勧めします。 リソース使用量を監視および管理する方法の詳細については、「観察可能なデータ量と請求書の照会」をご参照ください。
次のステップ
ack-koordinatorとack-slo-managerの関係
ack-koordinatorは、以前はack-slo-managerとして知られており、オープンソースのKoordinatorのインキュベーションを容易にします。 ack-slo-managerは、コーコーディネーターが成熟と安定に達すると、テクノロジーの面でもコーコーディネーターの恩恵を受けます。 したがって、ack-koordinatorはオープンソースのKoordinatorの機能をサポートし、他の機能も提供します。 ack-koordinatorの最新機能とバグ修正を使用するには、「ack-koordinatorをMarketplaceページからAdd-onsページに移行」で説明されている手順に従って、ack-koordinatorを最新バージョンに更新します。
Marketplaceページからアドオンページへのack-koordinatorの移行
使用しているack-koordinatorのバージョンがV0.7より前の場合、ack-koordinatorはマーケットプレイスからインストールされます。 ack-koordinatorをマーケットプレイスからアドオンページに移行するには、次の手順を実行します。
Marketplaceページでack-koordinatorのConfigMapを変更した場合は、ack-koordinatorを更新する前にConfigMapをバックアップしてください。 ConfigMapが変更されていない場合は、ステップ2に進みます。
ackコンソールまたはkubectlを使用して、ACK-koordinatorのConfigMapをバックアップします。
kubectl
次のコマンドを実行して、ConfigMapをslo-config.yamlファイルに保存します。 この例では、ConfigMapの名前空間はkube-systemで、ConfigMapの名前はack-slo-manager-configです。それらを実際の値に置き換えます。
kubectl get cm -n kube-system ack-slo-manager-config -o yaml > slo-config.yaml
vim slo-config.yaml
コマンドを実行して、上記のファイルのConfigMapの名前空間をkube-system
に変更し、ConfigMapの名前
をack-slo-config
に変更し、更新によってこれらの設定が自動的に上書きされる場合は、ConfigMap内のすべてのアノテーション
とラベル
を削除します。次のコマンドを実行して、変更されたConfigMapをクラスターに適用します。
kubectl apply -f slo-config.yaml
ACKコンソール
キーと値のペアをConfigMapに記録します。
左側のナビゲーションウィンドウで、ack-koordinatorをインストールするときに指定される名前空間を選択します。 デフォルトの名前空間はkube-systemです。
を選択します。 ページの上部のナビゲーションバーで、marketplaceから検索ボックスにConfigMap名ack-slo-manager-configを入力し、表示されたConfigMapの名前をクリックして、キーと値のペアを記録します。
記録されたキーと値のペアを使用して、別のConfigMapを作成します。
左側のナビゲーションウィンドウで、
を選択します。 上部のナビゲーションバーで、[すべての名前空間] を選択します。ConfigMapページの右上隅にある [作成] をクリックします。 表示されるパネルで、ConfigMap Nameフィールドにack-slo-configと入力し、kube-system名前空間を選択し、[+ Add] をクリックして、記録されたキーと値のペアを入力し、[OK] をクリックします。
アドオンページで、ack-koordinatorを最新バージョンに更新します。
重要Marketplaceページでack-koordinatorのConfigMapを変更した場合は、ack-koordinatorパラメーターダイアログボックスのステップ1で作成したバックアップConfigMapの名前を指定する必要があります。
resource-controllerからack-koordinatorへのアップグレード
リソースコントローラコンポーネントは段階的に廃止されます。 ack-koordinatorは、resource-controllerのすべての機能をサポートします。 たとえば、ack-koordinatorを使用して、トポロジ対応のCPUスケジューリングを有効にし、ポッドのリソースパラメーターを動的に変更できます。 リソースコントローラーがクラスターで使用されている場合は、次の手順を実行してリソースコントローラーからack-koordinatorにアップグレードします。
resource-controllerを最新バージョンに更新します。
ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。 左側のナビゲーションウィンドウで、 を選択します。
[アドオン] ページで、resource-controllerを見つけ、画面の指示に従ってresource-controllerを更新します。
ack-koordinatorをインストールして設定します。
[アドオン] ページで、[ack-koordinator] を見つけてクリックします。 ack-koordinatorカードで、[インストール] をクリックします。
[ack-koordinatorのインストール] ダイアログボックスで、必要に応じてagentFeatureGates (ack-slo-agentの機能ゲートスイッチ) を変更し、その他のパラメーターを設定します。 そして、[OK] をクリックします。
クラスターが「ポッドのリソースパラメーターを動的に変更する」で説明されているCPUバースト機能を使用しているかどうかを確認します。 この機能を使用すると、CRDを作成したり、ポッド注釈を追加してcpu.cfs_quota_usという名前のcgroup構成ファイルを変更できます。 この機能を使用する場合は、ステップiiを実行します。 この機能を使用しない場合は、手順cを実行します。
次のコマンドを実行して、ack-koordlet DaemonSetのYAMLファイルからfeature-gate設定を取得します。
kubectl get daemonset -n kube-system ack-koordlet -o yaml |grep feature-gates - --feature-gates=AllAlpha=false,AllBeta=false,...,CPUBurst=true,....
次のコマンドを実行して、ack-koordletのfeature-gate設定を変更します。
CPUBurst=false
を指定してCPUバーストを無効にします。 複数のパラメーターはコンマ (,) で区切ります。 その他の設定は変更しないでください。CPUバーストを無効にすると、クラスター内のすべてのコンテナーでCPUバーストが使用できなくなります。 これにより、cgroup構成ファイルcpu.cfs_quota_usが2つのモジュールによって同時に変更されるのを防ぎます。
AllAlpha=false,AllBeta=false,...,CPUBurst=false,....
コンテナーのCPUリソースを動的にスケーリングする場合は、CPUバースト機能を有効にすることを推奨します。 この機能により、ポッドのCPU制限を自動的に調整できます。 詳細については、「CPUバーストの有効化」をご参照ください。
クラスター管理ページの左側のナビゲーションウィンドウで、[ack-koordinator] のステータスを表示します。
を選択し、[ステータス] 列に [デプロイ済み] が表示されている場合、ack-koordinatorがインストールされます。
[アドオン] ページで、resource-controllerを見つけ、画面の指示に従ってresource-controllerをアンインストールします。
よくある質問
コンポーネントのインストールエラー: バージョン「monitoring.coreos.com/v1」の種類「ServiceMonitor」に一致するものは、CRDが最初にインストールされていることを確認します
Prometheusのマネージドサービスがクラスターにインストールされていません。 Prometheusの手順に従ってPrometheusコンポーネントをインストールするか、ackコンソールのアドオンページでack-koordinatorをインストールするときにEnable Prometheus Metrics for ACK-koordinatorをオフにします。
コンポーネントのインストールエラー: タスクのインストール-アドオン-xxxタイムアウト、エラーインストールアドオンマップ [ack-slo-manager: エラー付きリリースをインストールできません:... 関数 "lookup" が定義されていません
HelmをV3.0以降に更新します。 詳細については、「 [コンポーネントの更新] Update Helm V2 to V3」をご参照ください。
リリースノート
9月2024
バージョン | 画像アドレス | リリース日 | 説明 | 影響 |
v1.5.0-ack1.14 |
| 2024-09-12 |
| ワークロードへの影響なし |
7月2024日
バージョン | 画像アドレス | リリース日 | 説明 | 影響 |
v1.5.0-ack1.12 |
| 2024-07-29 | 内部API操作が最適化されています。 | ワークロードへの影響なし |
January 2024
バージョン | 画像アドレス | リリース日 | 説明 | 影響 |
v1.3.0-ack1.8 |
| 2024-01-24 |
| ワークロードへの影響なし |
12月2023
バージョン | 画像アドレス | リリース日 | 説明 | 影響 |
v1.3.0-ack1.7 |
| 2023-12-21 |
| ワークロードへの影響なし |
10月2023
バージョン | 画像アドレス | リリース日 | 説明 | 影響 |
v1.3.0-ack1.6 |
| 2023-10-19 | 内部API操作が最適化されています。 | ワークロードへの影響なし |
6月2023
バージョン | 画像アドレス | リリース日 | 説明 | 影響 |
v1.2.0-ack1.3 |
| 2023-06-09 | 内部API操作が最適化されています。 | ワークロードへの影響なし |
April 2023
バージョン | 画像アドレス | リリース日 | 説明 | 影響 |
v1.2.0-ack1.2 |
| 2023-04-25 |
| ワークロードへの影響なし |
3月2023日
バージョン | 画像アドレス | リリース日 | 説明 | 影響 |
v1.1.1-ack.2 |
| 2023-03-23 | 内部API操作が最適化されています。 | ワークロードへの影響なし |
2023 年 1 月
バージョン | 画像アドレス | リリース日 | 説明 | 影響 |
v1.1.1-ack.1 |
| 2023-01-11 |
| ワークロードへの影響なし |
2022 年 11 月
バージョン | 画像アドレス | リリース日 | 説明 | 影響 |
v0.8.0 |
| 2022-11-17 |
| ack-slo-managerの更新後に負荷対応のポッドスケジューリングを使用する場合は、クラスターのKubernetesバージョンを1.22.15-ack-2.0に更新する必要があります。 その他の機能は影響を受けません。 |
2022 年 9 月
バージョン | 画像アドレス | リリース日 | 説明 | 影響 |
v0.7.2 | registry.cn-hangzhou.aliyuncs.com/acs/ack-slo-manager:v0.7.2 | 2022-09-16 | 0.7.1によって引き起こされる次の問題が修正されました。トポロジ認識スケジューリングがポッドで有効になりません。 | ワークロードへの影響なし |
v0.7.1 | registry.cn-hangzhou.aliyuncs.com/acs/ack-slo-manager:v0.7.1 | 2022-09-02 |
| ワークロードへの影響なし |
2022 年 8 月
バージョン | 画像アドレス | リリース日 | 説明 | 影響 |
v0.7.0 | registry.cn-hangzhou.aliyuncs.com/acs/ack-slo-manager:v0.7.0 | 2022-08-08 | ack-slo-managerは、マーケットプレイスからACKコンソールの [アドオン] ページに移行されます。 ack-slo-managerをインストールする場合は、[アドオン] ページに移動します。 | ワークロードへの影響なし |
2022 年 7 月
バージョン | 画像アドレス | リリース日 | 説明 | 影響 |
v0.6.0 | registry.cn-hangzhou.aliyuncs.com/acs/ack-slo-manager:v0.6.0 | 2022-07-26 | 内部API操作が最適化され、コンポーネント設定が簡素化されます。 | ワークロードへの影響なし |
2022 年 6 月
バージョン | 画像アドレス | リリース日 | 説明 | 影響 |
v0.5.2 | registry.cn-hangzhou.aliyuncs.com/acs/ack-slo-manager:v0.5.2 | 2022-06-14 |
| ワークロードへの影響なし |
v0.5.1 | registry.cn-hangzhou.aliyuncs.com/acs/ack-slo-manager:v0.5.1 | 2022-06-02 |
| ワークロードへの影響なし |
2022 年 4 月
バージョン | 画像アドレス | リリース日 | 説明 | 影響 |
v0.5.0 | registry.cn-hangzhou.aliyuncs.com/acs/ack-slo-manager:v0.5.0 | 2022-04-29 |
| ワークロードへの影響なし |
v0.4.1 | registry.cn-hangzhou.aliyuncs.com/acs/ack-slo-manager:v0.4.1 | 2022-04-14 |
| ワークロードへの影響なし |
v0.4.0 | registry.cn-hangzhou.aliyuncs.com/acs/ack-slo-manager:v0.4.0 | 2022-04-11 | slo − agentのメモリ消費は減少する。 | ワークロードへの影響なし |
2022 年 2 月
バージョン | 画像アドレス | リリース日 | 説明 | 影響 |
v0.3.0 | registry.cn-hangzhou.aliyuncs.com/acs/ack-slo-manager:v0.3.0 | 2022-02-25 |
| ワークロードへの影響なし |
2021 年 12 月
バージョン | 画像アドレス | リリース日 | 説明 | 影響 |
v0.2.0 | registry.cn-hangzhou.aliyuncs.com/acs/ack-slo-manager:v0.2.0 | 2021-12-10 |
| ワークロードへの影響なし |
2021 年 9 月
バージョン | 画像アドレス | リリース日 | 説明 | 影響 |
v0.1.1 | registry.cn-hangzhou.aliyuncs.com/acs/ack-slo-manager:v0.1.1-c2ccefa | 2021-09-02 | 内部API操作が最適化されています。 | ワークロードへの影響なし |
7月2021日
バージョン | 画像アドレス | リリース日 | 説明 | 影響 |
v0.1.0 | registry.cn-hangzhou.aliyuncs.com/acs/ack-slo-manager:v0.1.0-09766de | 2021-07-08 | 負荷認識型ポッドスケジューリングがサポートされています。 | ワークロードへの影響なし |