このトピックでは、ack-koordinator を使用して、オンライン (高遅延感度) ワークロードとオフライン (ベストエフォート) ワークロードの両方に対応するコロケーション環境を迅速にセットアップする方法と、この混合ワークロードモードでアプリケーションを実行するための設定方法について説明します。
前提条件
ack-koordinator (旧 ack-slo-manager) 0.8.0 以降がインストールされていること。
コロケーションモードでデプロイされたアプリケーションのパフォーマンスを最適化するために、ECS ベアメタルインスタンスと Alibaba Cloud Linux オペレーティングシステムを使用することを推奨します。
リソース優先度と QoS
リソース優先度と Quality of Service (QoS) クラスは、ACK が提供するサービスレベル目標 (SLO) を意識したコロケーション機能の基本概念です。
リソース優先度は、ノード上のさまざまなタイプのリソースを制限するために使用されます。リソース優先度は、リソース割り当てが増加してもリソース使用率が低いレベルにとどまるという問題を解決できます。次の表に、さまざまなリソース優先度の違いを示します。
低優先度リソースの量は、Pod によって要求および使用される高優先度リソースの量に依存します。たとえば、割り当て済みだが使用されていない Product リソースは Batch リソースにダウングレードされてから再割り当てされます。
リソース優先度の設定方法は、クラスターリソースのオーバーコミット可能な量とノードのリソース可用性に影響します。
オーバーコミット用のリソースは、ノードメタデータ内で標準の拡張リソースとして記述および更新されます。
次の表に、ACK で使用されるリソース優先度を示します。
リソース優先度 | リソース量の計算 | リソース名 |
Product | 通常、Product リソースの量は、ノードによって提供される物理リソースの量と等しくなります。 | ノード上の割り当て可能なリソースで、CPU およびメモリリソースを含みます。 |
Batch | Batch リソースの量は、オーバーコミットされたリソースの量と等しく、ノードのリソース使用率に基づいて動的に計算されます。オーバーコミット用のリソース量は、次の数式に基づいて計算されます: オーバーコミット用のリソース量 = ノード上の物理リソースの合計量 - 使用されている Product リソースの量。詳細については、「動的リソースオーバーコミット」をご参照ください。 | Batch リソースは、 |
QoS クラスは、アプリケーションのリソース感度を記述します。異なる QoS クラスが割り当てられた Pod は、異なる SLO を満たすために異なるパフォーマンスレベルで実行されます。異なる QoS クラスは、異なるリソース分離パラメーターに対応します。ノード上のリソースが不足している場合、リソースは優先的に高優先度の QoS クラスを持つ Pod に割り当てられます。次の表に、ACK で使用される QoS クラスを示します。
QoS クラス | 適用可能なワークロード | 説明 |
LS (Latency Sensitive) | オンラインサービス (LS ワークロード) | LS ワークロードは、CPU タイムスライススケジューリングおよび L3 キャッシュ (最終レベルキャッシュ) やメモリ帯域幅リソースを含むメモリリソースの割り当てにおいて優先されます。メモリ回収がトリガーされると、システムは BE ワークロードから優先的にメモリを回収し、LS ワークロードのためにメモリリソースを予約します。 |
BE (Best Effort) | リソース集約型ジョブ (BE ワークロード) | BE ワークロードは、CPU タイムスライススケジューリングにおいて LS ワークロードよりも優先度が低くなります。BE ワークロードが使用できる L3 キャッシュとメモリ帯域幅リソースは制限されます。LS ワークロードと比較して、メモリ回収がトリガーされると、システムは BE ワークロードから優先的にメモリを回収します。 |
リソース優先度と QoS クラスは互いに独立しており、組み合わせて使用できます。ただし、コロケーションモデルとビジネス要件の制約により、次の組み合わせのみが使用されます:
Product + LS: この組み合わせは、Web アプリケーションや高遅延感度のストリームコンピューティングジョブなど、低遅延を必要とし、リソース割り当て時に優先される必要があるオンラインアプリケーションに適しています。
Batch + BE: この組み合わせは、バッチ Spark ジョブ、バッチ MapReduce ジョブ、AI トレーニングジョブなど、リソース割り当てにおいてオンラインアプリケーションよりも優先度が低いオフラインアプリケーションに適しています。
コロケーションポリシーの管理
ACK は、ack-koordinator のコロケーションポリシーを管理するために使用できる ConfigMap を提供します。ack-koordinator のすべてのコロケーションポリシーを有効にするには、次の手順を実行します:
次の ConfigMap コンテンツに基づいて、configmap.yaml という名前のファイルを作成します:
# ack-slo-config ConfigMap の例。 apiVersion: v1 kind: ConfigMap metadata: name: ack-slo-config namespace: kube-system data: colocation-config: |- { "enable": true } resource-qos-config: |- { "clusterStrategy": { "lsClass": { "cpuQOS": { "enable": true }, "memoryQOS": { "enable": true }, "resctrlQOS": { "enable": true } }, "beClass": { "cpuQOS": { "enable": true }, "memoryQOS": { "enable": true }, "resctrlQOS": { "enable": true } } } } resource-threshold-config: |- { "clusterStrategy": { "enable": true } }次の表に、上記の例に含まれるさまざまなコロケーションポリシーを指定するパラメーターを示します。
パラメーター
説明
colocation-config
このポリシーが指定されると、ack-slo-config はノードの負荷に関するリアルタイムモニタリングデータを収集し、そのモニタリングデータを分析してオーバーコミット可能なリソースを特定します。リソースが Pod に割り当てられているが使用されていない場合、そのリソースはオーバーコミット可能です。詳細については、「動的リソースオーバーコミット」をご参照ください。
resource-qos-config
このポリシーが指定されると、ack-slo-config はさまざまなタイプのリソースを詳細に管理し、リソースが高優先度の QoS クラスを持つ Pod に優先的に割り当てられるようにします。詳細については、「CPU QoS」、「コンテナーのメモリ QoS」、および「L3 キャッシュと MBA に基づくリソース分離」をご参照ください。
resource-threshold-config
このポリシーが指定されると、ack-slo-config はノードのリソース使用率のウォーターマークに基づいて、低優先度の QoS クラスを持つ Pod が使用できるリソースを動的に制限します。詳細については、「弾性的なリソース制限」をご参照ください。
次のコマンドを実行して ConfigMap を作成します:
kubectl apply -f configmap.yaml
アプリケーションのデプロイ
nginx-ls-pod.yaml という名前のファイルを作成し、次の内容をファイルにコピーします。
高遅延感度アプリケーションの QoS クラスを
LSに設定します。この例では、NGINX アプリケーション用に作成された Pod の設定のlabelsセクションでkoordinator.sh/qosClass: LSが指定されています。--- # Nginx アプリケーション設定 apiVersion: v1 data: config: |- user nginx; worker_processes 80; # Nginx ワーカープロセスの数。同時実行性に影響します。 events { worker_connections 1024; # デフォルト値は 1024 です。 } http { server { listen 8000; gzip off; gzip_min_length 32; gzip_http_version 1.0; gzip_comp_level 3; gzip_types *; } } #daemon off; kind: ConfigMap metadata: name: nginx-conf --- # nginx-ls-pod のマニフェスト。 apiVersion: v1 kind: Pod metadata: labels: koordinator.sh/qosClass: LS app: nginx name: nginx spec: containers: - image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6 imagePullPolicy: IfNotPresent name: nginx ports: - containerPort: 8000 hostPort: 8000 # 負荷テストのリクエストを受信するホストポート。 protocol: TCP resources: limits: cpu: '8' memory: 1Gi requests: cpu: '8' memory: 1Gi volumeMounts: - mountPath: /apps/nginx/conf name: config hostNetwork: true restartPolicy: Never volumes: - configMap: items: - key: config path: nginx.conf name: nginx-conf name: configffmpeg-be-pod.yaml という名前のファイルを作成し、次の内容をファイルにコピーします:
リソース集約型アプリケーションの QoS クラスを
BEに設定し、kubernetes.io/batch-cpuおよびkubernetes.io/batch-memoryパラメーターを指定してリソースのオーバーコミットを設定します。この例では、トランスコーディングアプリケーション用に作成された Pod の設定のlabelsセクションでkoordinator.sh/qosClass: BEが指定されています。apiVersion: v1 kind: Pod metadata: labels: koordinator.sh/qosClass: BE name: be-ffmpeg spec: containers: - command: - start-ffmpeg.sh - '30' - '2' - /apps/ffmpeg/input/HD2-h264.ts - /apps/ffmpeg/ image: 'registry.cn-zhangjiakou.aliyuncs.com/acs/ffmpeg-4-4-1-for-slo-test:v0.1' imagePullPolicy: Always name: ffmpeg resources: limits: # 単位:ミリコア。 kubernetes.io/batch-cpu: "70k" kubernetes.io/batch-memory: "22Gi" requests: # 単位:ミリコア。 kubernetes.io/batch-cpu: "70k" kubernetes.io/batch-memory: "22Gi"次のコマンドを実行して、高遅延感度アプリケーションとリソース集約型アプリケーションの Pod をデプロイします:
kubectl apply -f nginx-ls-pod.yaml kubectl apply -f ffmpeg-be-pod.yaml
次のステップ
アプリケーションがデプロイされた後、ACK が提供するコロケーション機能を使用できます。詳細については、「オンラインサービスとビデオトランスコーディングアプリケーションのコロケーション」をご参照ください。
コロケーション機能の詳細については、次のトピックをご参照ください: