ack-koordinator は、サービス品質 (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-koordinator を ACK コンソール にインストールする必要があります。 その後、ConfigMap を構成するか、関連するポッドアノテーションを追加して機能を有効にします。
アーキテクチャ
ack-koordinator は、2 つのコントロールプレーン (Koordinator Manager と Koordinator Descheduler) と 1 つの DaemonSet コンポーネント (Koordlet) で構成されています。
Koordinator Manager: Koordinator Manager はデプロイメントとしてデプロイされ、プライマリポッドとセカンダリポッドで実行されて高可用性を確保します。
SLO Controller: SLO Controller は、リソースのオーバーコミットを管理し、オーバーコミットされるリソースの量を動的に調整します。 SLO Controller は、各ノードの SLO ポリシーも管理します。
Recommender: Recommender はリソースプロファイリング機能を提供し、ワークロードのピークリソース需要を推定します。 Recommender は、コンテナのリソースリクエストと制限の構成を簡素化します。
Koordinator Descheduler: Koordinator Descheduler はデプロイメントとしてデプロイされ、デスケジューリングを実行するために使用されます。
Koordlet: Koordlet は DaemonSet としてデプロイされ、コロケーションシナリオでの動的リソースオーバーコミット、負荷対応スケジューリング、および QoS 対応スケジューリングをサポートするために使用されます。
Koord-Scheduler は ack-koordinator に含まれていません。 ack-koordinator に必要な関連するスケジューリング機能は、ACK スケジューラによって提供されます。
ACK Serverless クラスター では、ack-koordinator は Koordinator Manager コンポーネントのみで構成され、リソースプロファイリング機能をサポートしています。
バージョン記述
ack-koordinator v1.1.1-ack.1 以降では、バージョン番号は x.y.z-ackn 形式を使用します。
x.y.z: 対応するオープンソース Koordinator バージョンを示します。 これは、ack-koordinator がこのオープンソースバージョンで提供されるすべての機能をサポートしていることを意味します。ackn: オープンソース Koordinator バージョンに基づく機能強化と最適化を示します。
用語
機能
ack-koordinator のコンポーネントは、対応するオープンソース Koordinator バージョンの機能をサポートしています。 ack-koordinator のコンポーネントをインストールして構成すると、デフォルトでは基本的なフィーチャーゲートのみが有効になります。 オープンソース Koordinator でサポートされている高度な機能を使用するには、ack-koordinator の対応するフィーチャーゲートを手動で有効にする必要があります。 オープンソース Koordinator でサポートされている高度な機能の詳細については、「Koordinator 公式ドキュメント」をご参照ください。
カテゴリ | 参照 | 説明 | 機能がオープンソース 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(R) Data Streaming Accelerator (DSA) に基づいてノード上のデータ集約型ワークロードのデータ処理パフォーマンスを向上させ、近傍メモリアクセスアクセラレーションのパフォーマンスを最適化します。 | いいえ | ||
この機能は、CPU バウンドアプリケーションのリモート NUMA ノード上のメモリを、安全な方法でローカル NUMA ノードに移行します。 これにより、ローカルメモリのヒット率が向上し、メモリ集約型アプリケーションのパフォーマンスが向上します。 | いいえ | ||
この機能は、クラスタリソース使用率の不均一、ノードの過負荷、新しいスケジューリングポリシーの需要などのシナリオに適しています。 デスケジューリングとは、ノード上のエビクションルールに一致するポッドを別のノードにスケジューリングするプロセスのことです。 これにより、クラスタの正常性を維持し、リソース使用量を最適化し、ワークロードの QoS を向上させることができます。 | はい | ||
この機能は、ノードの負荷の変化を動的に監視し、負荷しきい値を超えるノードを自動的に最適化して、ノードの過負荷を防ぎます。 | はい | ||
GPU トポロジー認識 | この機能は、ポッドを最適な NUMA ノードにスケジューリングします。 これにより、NUMA ノード間のメモリアクセスが削減され、アプリケーションのパフォーマンスが最適化されます。 | いいえ | |
この機能は、履歴リソース使用量データを分析し、コンテナのリソース仕様の推奨事項を提供します。 これにより、コンテナのリソースリクエストと制限の構成が大幅に簡素化されます。 | いいえ | ||
インストールと管理
ack-koordinator は、ACK コンソール の [アドオン] ページで使用できます。 [アドオン] ページでは、ack-koordinator をインストール、更新、およびアンインストールできます。
前提条件
Kubernetes 1.18 以降を実行する ACK クラスタが作成されていること。クラスタを更新する方法の詳細については、「クラスタを手動でアップグレードする」をご参照ください。
Helm コンポーネントがインストールされており、コンポーネントのバージョンが 3.0 以降であること。 Helm バージョンの更新方法の詳細については、「[コンポーネントの更新] Helm V2 から V3 に更新する」および「Helm を手動で更新するにはどうすればよいですか。」をご参照ください。
ack-koordinator のインストールと管理
ACK コンソール の [アドオン] ページで ack-koordinator をインストールできます。 ack-koordinator がインストールされた後、[アドオン] ページで ack-koordinator を更新したり、ack-koordinator の構成を変更したりできます。
使用している ack-koordinator のバージョンが 0.7 より前の場合、ack-koordinator は [マーケットプレイス] ページからインストールされます。移行については、「ack-koordinator をマーケットプレイスページからアドオンページに移行する」をご参照ください。
ack-koordinator のインストール: ack-koordinator をインストールするには、次の手順を実行します。インストールの進捗状況は [アドオン] ページで確認できます。
ack-koordinator 構成の変更: ack-koordinator の構成を変更すると、ACK は新しい構成に基づいて ack-koordinator を自動的に再インストールします。
ack-koordinator の更新: 他の方法を使用して、デプロイ済みの ack-koordinator コンポーネントのモジュールを手動で変更した場合、ack-koordinator の更新後に変更が上書きされます。
ACK コンソール にログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターを見つけて、その名前をクリックします。左側のナビゲーションウィンドウで、[アドオン] をクリックします。
[アドオン] ページで、ack-koordinator を見つけてクリックします。 [ack-koordinator (ack-slo-manager)] カードで、[インストール] をクリックします。
[ack-koordinator (ack-slo-manager) のインストール] ダイアログボックスで、パラメーターを構成し、[OK] をクリックします。
任意: クラスター管理ページの左側のナビゲーションウィンドウで、 を選択し、ack-koordinator のステータスを表示します。
[ステータス] 列に [デプロイ済み] と表示されている場合、ack-koordinator はインストールされています。
ack-koordinator をアンインストールする
既存ノードのトポロジー ConfigMap を削除する
トポロジー対応 CPU スケジューリング機能は、ACK クラスタの各ノードの kube-system 名前空間 にトポロジー ConfigMap を作成します。ack-koordinator 0.5.1 以降では、クラスタから削除されたノードのトポロジー ConfigMap を自動的に削除できます。ack-koordinator をアンインストールすると、クラスタ内の既存ノードのトポロジー ConfigMap は保持されます。保持されたトポロジー ConfigMap は他の機能には影響しませんが、ストレージ容量を占有します。これらの ConfigMap はできるだけ早く削除することをお勧めします。
[アドオン] ページで、ack-koordinator を見つけて、画面の指示に従って ack-koordinator をアンインストールします。
トポロジー ConfigMap を削除します。
左側のナビゲーションウィンドウで、 を選択します。表示されるページで、[名前空間] ドロップダウンリストから [kube-system] を選択します。
[名前] 検索ボックスに -numa-info と入力し、
${NODENAME}-numa-infoという命名規則に一致する ConfigMap をリストから選択します。次に、[削除] 列の [アクション] をクリックして、ConfigMap を削除します。
CRD を削除する
ack-koordinator をアンインストールした後、ack-koordinator で使用される一部のカスタムリソース定義 (CRD) が保持される場合があります。保持された CRD は他の機能には影響しませんが、ストレージ容量を占有します。ただし、ack-koordinator を再インストールすると、保持された CRD が ack-koordinator の機能に影響を与える可能性があります。この場合、保持された ConfigMap はできるだけ早く削除することをお勧めします。次の表に、CRD を示します。
autoscaling.alibabacloud.com | slo.koordinator.sh |
|
|
課金
ack-koordinator コンポーネントのインストールまたは使用に料金はかかりません。 ただし、以下のシナリオでは料金が発生する場合があります。
ack-koordinator は、インストール後にワーカーノードリソースを占有する非マネージドコンポーネントです。 コンポーネントをインストールするときに、各モジュールによってリクエストされるリソースの量を指定できます。
デフォルトでは、ack-koordinator は、リソースプロファイリングや詳細スケジューリングなどの機能の監視メトリックを Prometheus メトリックとして公開します。 ack-koordinator の Prometheus メトリックを有効にすると Managed Service for Prometheus を使用する場合、これらのメトリックは カスタムメトリック と見なされ、これらのメトリックに対して料金が発生します。 料金は、クラスタのサイズやアプリケーションの数などの要因によって異なります。 Prometheus メトリックを有効にする前に、Managed Service for Prometheus の 課金 トピックを読んで、カスタムメトリックの無料枠と課金ルールについて理解することをお勧めします。 リソース使用量を監視および管理する方法の詳細については、「監視可能なデータ量と請求額を照会する」をご参照ください。
次のステップ
ack-koordinator と ack-slo-manager の関係
ack-koordinator は以前は ack-slo-manager として知られており、オープンソースの Koordinator のインキュベーションを促進します。 また、ack-slo-manager は、Koordinator が成熟して安定するにつれて、Koordinator のテクノロジーの恩恵も受けています。 したがって、ack-koordinator はオープンソース Koordinator の機能をサポートし、他の機能も提供します。 ack-koordinator の最新の機能とバグ修正を使用するには、「ack-koordinator を [マーケットプレイス] ページから [アドオン] ページに移行する」に記載されている手順に従って、ack-koordinator を最新バージョンに更新してください。
ack-koordinator を [マーケットプレイス] ページから [アドオン] ページに移行する
使用している ack-koordinator のバージョンが 0.7 より前の場合、ack-koordinator はマーケットプレイスからインストールされます。 再インストールする前に、マーケットプレイスからアンインストールする必要があります。 次の手順を実行して、ack-koordinator をマーケットプレイスから [アドオン] ページに移行します。
[マーケットプレイス] ページで 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.yamlvim slo-config.yamlコマンドを実行して、上記のファイルの ConfigMap の名前空間をkube-systemに変更し、ConfigMap のnameをack-slo-configに変更してから、更新によってこれらの設定が自動的に上書きされる場合に備えて、ConfigMap 内のすべてのannotationsとlabelsを削除します。次のコマンドを実行して、変更された ConfigMap をクラスターに適用します。
kubectl apply -f slo-config.yaml
ACK コンソール
ConfigMap のキーと値のペアを記録します。
左側のナビゲーションウィンドウで、 を選択します。 ページの上部ナビゲーションバーで、[マーケットプレイス] から ack-koordinator をインストールするときに指定した [名前空間] を選択します。 デフォルトの名前空間は kube-system です。
ConfigMap 名 ack-slo-manager-config を検索ボックスに入力し、表示される ConfigMap の名前をクリックして、キーと値のペアを記録します。
記録されたキーと値のペアを使用して別の ConfigMap を作成します。
左側のナビゲーションウィンドウで、 を選択します。 上部ナビゲーションバーで、[すべての名前空間] を選択します。
[ConfigMap] ページの右上隅にある [作成] をクリックします。 表示されるパネルで、[ConfigMap 名] フィールドに ack-slo-config と入力し、kube-system 名前空間を選択し、[+ 追加] をクリックし、記録されたキーと値のペアを入力して、[OK] をクリックします。
[クラスター] ページの左側のナビゲーションウィンドウで、 を選択し、[ack-slo-manager] のステータスを確認します。 次に、[アクション] 列の [削除] をクリックして、マーケットプレイスからインストールされた [ack-slo-manager] をアンインストールします。
[アドオン] ページで、ack-koordinator を最新バージョンに更新します。
重要マーケットプレイスページで ack-koordinator の ConfigMap を変更した場合は、[ack-koordinator パラメータ] ダイアログボックスの手順 1 で作成したバックアップ ConfigMap の名前を指定する必要があります。
resource-controller から ack-koordinator にアップグレードする
resource-controller コンポーネントは廃止されました。ack-koordinator は、resource-controller のすべての機能をサポートしています。たとえば、ack-koordinator を使用すると、トポロジーを意識した CPU スケジューリングの有効化やポッドのリソースパラメーターの動的な変更などが可能です。お使いのクラスターで resource-controller が使用されている場合は、次の手順に従って resource-controller から ack-koordinator にアップグレードしてください:
resource-controller を最新バージョンに更新します。
ACK コンソール にログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターを見つけて名前をクリックします。 左側のナビゲーションウィンドウで、[アドオン] をクリックします。
[アドオン] ページで resource-controller を見つけ、画面の指示に従って resource-controller を更新します。
ack-koordinator をインストールして構成します。
[アドオン] ページで、ack-koordinator を見つけてクリックします。 ack-koordinator カードで、[インストール] をクリックします。
[ack-koordinator (ack-slo-manager) をインストールする] ダイアログボックスで、必要に応じて [agentFeatures] (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 をアンインストールします。
FAQ
コンポーネントのインストールエラー: バージョン「monitoring.coreos.com/v1」に種類「ServiceMonitor」に一致するものがないため、最初に CRD がインストールされていることを確認してください
Managed Service for Prometheus がクラスターにインストールされていません。 Managed Service for Prometheus を使用する の手順に従って Prometheus コンポーネントをインストールするか、ACK コンソールの [アドオン] ページで ack-koordinator をインストールするときに [ack-koordinator の Prometheus メトリックを有効にする] をオフにします。
コンポーネントのインストールエラー: タスク install-addons-xxx タイムアウト、エラー install addons map[ack-slo-manager:エラーのあるリリースをインストールできない: ... 関数「lookup」が定義されていない
Helm を V3.0 以降に更新します。 詳細については、「[コンポーネントの更新] Helm V2 から V3 に更新する」をご参照ください。
リリースノート
2025 年 7 月
バージョン | イメージアドレス | リリース日 | 説明 | 影響 |
v1.6.1-ack1.18 |
| 2025-07-30 |
| ワークロードへの影響はありません |
v1.6.1-ack1.17 |
| 2025-07-14 |
| ワークロードへの影響はありません |
v1.6.1-ack1.16 |
| 2025-07-04 |
| ワークロードへの影響はありません |
2024 年 9 月
バージョン | イメージアドレス | リリース日 | 説明 | 影響 |
v1.5.0-ack1.14 |
| 2024-09-12 |
| ワークロードへの影響はありません |
2024 年 7 月
バージョン | イメージアドレス | リリース日 | 説明 | 影響 |
v1.5.0-ack1.12 |
| 2024-07-29 | 内部 API 操作が最適化されました。 | ワークロードへの影響はありません |
2024 年 1 月
バージョン | イメージアドレス | リリース日 | 説明 | 影響 |
v1.3.0-ack1.8 |
| 2024-01-24 |
| ワークロードへの影響はありません |
2023 年 12 月
バージョン | イメージアドレス | リリース日 | 説明 | 影響 |
v1.3.0-ack1.7 |
| 2023-12-21 |
| ワークロードへの影響はありません |
2023 年 10 月
バージョン | イメージアドレス | リリース日 | 説明 | 影響 |
v1.3.0-ack1.6 |
| 2023-10-19 | 内部 API 操作が最適化されました。 | ワークロードへの影響はありません |
2023 年 6 月
バージョン | イメージアドレス | リリース日 | 説明 | 影響 |
v1.2.0-ack1.3 |
| 2023-06-09 | 内部 API 操作が最適化されました。 | ワークロードへの影響はありません |
2023 年 4 月
バージョン | イメージアドレス | リリース日 | 説明 | 影響 |
v1.2.0-ack1.2 |
| 2023-04-25 |
| ワークロードへの影響はありません |
2023 年 3 月
バージョン | イメージアドレス | リリース日 | 説明 | 影響 |
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.{REGION}.aliyuncs.com/acs/ack-slo-manager:v0.7.2 | 2022-09-16 | 0.7.1 によって発生した次の問題が修正されました: トポロジー対応スケジューリングがポッドで有効にならない。 | ワークロードへの影響はありません |
v0.7.1 | registry.{REGION}.aliyuncs.com/acs/ack-slo-manager:v0.7.1 | 2022-09-02 |
| ワークロードへの影響はありません |
2022 年 8 月
バージョン | イメージアドレス | リリース日 | 説明 | 影響 |
v0.7.0 | registry.{REGION}.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.{REGION}.aliyuncs.com/acs/ack-slo-manager:v0.6.0 | 2022-07-26 | 内部 API 操作が最適化され、コンポーネント構成が簡素化されました。 | ワークロードへの影響はありません |
2022 年 6 月
バージョン | イメージアドレス | リリース日 | 説明 | 影響 |
v0.5.2 | registry.{REGION}.aliyuncs.com/acs/ack-slo-manager:v0.5.2 | 2022-06-14 |
| ワークロードへの影響はありません |
v0.5.1 | registry.{REGION}.aliyuncs.com/acs/ack-slo-manager:v0.5.1 | 2022-06-02 |
| ワークロードへの影響はありません |
2022 年 4 月
バージョン | イメージアドレス | リリース日 | 説明 | 影響 |
v0.5.0 | registry.{REGION}.aliyuncs.com/acs/ack-slo-manager:v0.5.0 | 2022-04-29 |
| ワークロードへの影響はありません |
v0.4.1 | registry.{REGION}.aliyuncs.com/acs/ack-slo-manager:v0.4.1 | 2022-04-14 |
| ワークロードへの影響はありません |
v0.4.0 | registry.{REGION}.aliyuncs.com/acs/ack-slo-manager:v0.4.0 | 2022-04-11 | slo-agent のメモリ消費量が削減されました。 | ワークロードへの影響はありません |
2022 年 2 月
バージョン | イメージアドレス | リリース日 | 説明 | 影響 |
v0.3.0 | registry.{REGION}.aliyuncs.com/acs/ack-slo-manager:v0.3.0 | 2022-02-25 |
| ワークロードへの影響はありません |
2021 年 12 月
バージョン | イメージアドレス | リリース日 | 説明 | 影響 |
v0.2.0 | registry.{REGION}.aliyuncs.com/acs/ack-slo-manager:v0.2.0 | 2021-12-10 |
| ワークロードへの影響はありません |
2021 年 9 月
バージョン | イメージアドレス | リリース日 | 説明 | 影響 |
v0.1.1 | registry.{REGION}.aliyuncs.com/acs/ack-slo-manager:v0.1.1-c2ccefa | 2021-09-02 | 内部 API 操作が最適化されました。 | ワークロードへの影響はありません |
2021 年 7 月
バージョン | イメージアドレス | リリース日 | 説明 | 影響 |
v0.1.0 | registry.{REGION}.aliyuncs.com/acs/ack-slo-manager:v0.1.0-09766de | 2021-07-08 | 負荷対応ポッドスケジューリング がサポートされるようになりました。 | ワークロードへの影響はありません |