このトピックでは、ack-koordinatorを使用して、レイテンシに敏感な (LS) ワークロードおよびベストエフォート型 (BE) ワークロード用のコロケーション環境を構築する方法について説明します。 このトピックでは、アプリケーションを配置する方法についても説明します。
前提条件
Container Service for Kubernetes (ACK) Proクラスターが作成されました。 ACK ProクラスターのみがLSとBEワークロードのコロケーションをサポートしています。 詳細については、「ACK Proクラスターの作成」をご参照ください。
ack-koordinator (FKA ack-slo-manager) 0.8.0以降がインストールされています。 詳細については、「ack-koordinator (ack-slo-manager) 」をご参照ください。
コロケーションモードでデプロイされるアプリケーションのパフォーマンスを最適化するために、ECSベアメタルインスタンスとAlibaba Cloud Linuxオペレーティングシステムを使用することを推奨します。
リソースの優先度とQoS
リソース優先度およびサービス品質 (QoS) クラスは、ACKによって提供されるサービスレベル目標 (SLO) 認識コロケーション機能の重要な概念である。
リソース優先度は、ノード上の異なるタイプのリソースを制限するために使用される。 リソース優先度は、リソース割り当てが増加したときにリソース利用が依然として低いレベルに留まるという問題を解決することができる。 次の表に、異なるリソース優先度の違いを示します。
低優先度リソースの量は、ポッドによって要求および使用される高優先度リソースの量によって異なります。 たとえば、割り当てられたが使用されていない製品リソースは、バッチリソースにダウングレードされ、再割り当てされます。
リソースの優先順位を設定する方法は、オーバーコミットできるクラスターリソースの量とノードのリソース可用性に影響します。
オーバーコミットメントのリソースは、ノードメタデータ内の標準拡張リソースとして記述および更新されます。
次の表に、ACKで使用されるリソースの優先度を示します。
リソース優先度 | リソース量の計算 | リソース名 |
プロダクト | 通常、Productリソースの量は、ノードによって提供される物理リソースの量に等しい。 | CPUおよびメモリリソースを含む、ノード上の割り当て可能なリソース。 |
バッチ | バッチリソースの量は、ノードのリソース使用率に基づいて動的に計算される、過剰にコミットされたリソースの量に等しくなります。 オーバーコミットのリソースの量は、次の式に基づいて計算されます。オーバーコミットのリソースの量=ノード上の物理リソースの合計量-使用されている製品リソースの量。 詳細については、「動的リソースのオーバーコミットメント」をご参照ください。 | バッチリソースは、 |
QoSクラスは、アプリケーションのリソース感度を記述する。 異なるQoSクラスが割り当てられたポッドは、異なるSLOを満たすために異なる性能レベルで動作する。 異なるQoSクラスは、異なるリソース分離パラメータに対応する。 ノード上のリソースが不十分な場合、優先度の高いQoSクラスを有するポッドにリソースを割り当てることが好ましい。 次の表に、ACKで使用されるQoSクラスを示します。
QoSクラス | 該当するワークロード | 説明 |
LS (レイテンシに敏感) | オンラインサービス (LSワークロード) | LSワークロードは、CPUタイムスライススケジューリングと、L3キャッシュ (ラストレベルキャッシュ) およびメモリ帯域幅リソースを含むメモリリソースの割り当てで優先されます。 システムは、メモリ再利用がトリガされると、BEワークロードからメモリを再利用し、LSワークロード用のメモリリソースを予約することが好ましい。 |
BE (ベストエフォート) | リソース集約型ジョブ (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という名前のファイルを作成します。
# Example of the 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 } }
次の表では、前述の例に含まれるさまざまなコロケーションポリシーを指定するパラメーターについて説明します。
パラメーター
説明
collocation-config
このポリシーが指定されている場合、ack-slo-configは、ノードの負荷に関するリアルタイムのモニタリングデータを収集し、モニタリングデータを分析して、オーバーコミット可能なリソースを特定します。 リソースがポッドに割り当てられているが使用されていない場合、リソースはオーバーコミットされる可能性があります。 詳細については、「動的リソースのオーバーコミットメント」をご参照ください。
リソース-qos-config
このポリシーが指定されると、ack-slo-configは、さまざまなタイプのリソースをきめ細かく管理し、優先度の高いQoSクラスを持つポッドにリソースが割り当てられることを保証します。 詳細については、「CPU QoS」、「コンテナーのメモリQoS」、および「L3キャッシュとMBAに基づくリソースの分離」をご参照ください。
resource-threshold-config
このポリシーが指定されている場合、ack-slo-configは、ノードのリソース使用率透かしに基づいて、優先度の低いQoSクラスを持つポッドが使用できるリソースを動的に制限します。 詳細については、「Elastic resource limit」をご参照ください。
次のコマンドを実行して、ConfigMapを作成します。
kubectl apply -f configmap.yaml
アプリケーションのデプロイ
nginx-ls-pod.yamlという名前のファイルを作成し、次の内容をファイルにコピーします。
レイテンシに敏感なアプリケーションのQoSクラスを
LS
に設定します。 この例では、NGINXアプリケーション用に作成されたポッドの構成のlabels
セクションで、koordinator.sh/qosClass: LS
が指定されています。# Example of the nginx-ls-pod.yaml file. apiVersion: v1 kind: Pod metadata: labels: koordinator.sh/qosClass: LS app: nginx name: nginx spec: containers: - image: 'koordinatorsh/nginx:v1.18-koord-exmaple' imagePullPolicy: IfNotPresent name: nginx ports: - containerPort: 8000 hostPort: 8000 # The port that is used to perform stress tests. 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: config
ffmpeg-be-pod.yamlという名前のファイルを作成し、次の内容をファイルにコピーします。
リソース集約型アプリケーションのQoSクラスを
BE
に設定し、kubernetes.io/batch-cpu
およびkubernetes.io/batch-memory
パラメーターを指定してリソースオーバーコミットメントを設定します。 この例では、koordinator.sh/qosClass: BE
が、トランスコーディングアプリケーション用に作成されたポッドの設定のlabels
セクションで指定されています。# Example of the ffmpeg-be-pod.yaml file. 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: # Unit: millicores. kubernetes.io/batch-cpu: "70k" kubernetes.io/batch-memory: "22Gi" requests: # Unit: millicores. kubernetes.io/batch-cpu: "70k" kubernetes.io/batch-memory: "22Gi"
次のコマンドを実行して、遅延に敏感なアプリケーションとリソース集約型アプリケーションのポッドをデプロイします。
kubectl apply -f nginx-ls-pod.yaml kubectl apply -f ffmpeg-be-pod.yaml
次のステップ
アプリケーションのデプロイ後、ACKで提供されるコロケーション機能を使用できます。 詳細については、「オンラインサービスとビデオコード変換アプリケーションの連携」をご参照ください。
コロケーション機能の詳細については、以下のトピックを参照してください。