Topik ini menjelaskan cara menggunakan ack-koordinator untuk menyiapkan lingkungan colocation secara cepat bagi workload online (latency-sensitive) dan offline (best-effort), serta cara mengonfigurasi aplikasi agar berjalan dalam mode workload campuran ini.
Prasyarat
Hanya berlaku untuk kluster Container Service for Kubernetes (ACK) Pro.
ack-koordinator (sebelumnya dikenal sebagai ack-slo-manager) versi 0.8.0 atau yang lebih baru telah terinstal.
Untuk mengoptimalkan kinerja aplikasi yang dideploy dalam mode colocation, kami merekomendasikan penggunaan Instans bare metal ECS dan sistem operasi Alibaba Cloud Linux.
Prioritas resource dan QoS
Prioritas resource dan kelas Quality of Service (QoS) merupakan konsep utama dari fitur colocation berbasis service-level objective (SLO) yang disediakan oleh ACK.
Prioritas resource digunakan untuk membatasi jenis-jenis resource yang berbeda pada suatu node. Prioritas resource dapat mengatasi masalah di mana tingkat pemanfaatan resource tetap rendah meskipun alokasi resource meningkat. Tabel berikut menjelaskan perbedaan antara berbagai prioritas resource.
Jumlah resource prioritas rendah bergantung pada jumlah resource prioritas tinggi yang diminta dan digunakan oleh Pod. Misalnya, resource Product yang telah dialokasikan tetapi tidak sedang digunakan akan diturunkan spesifikasinya menjadi resource Batch, lalu dialokasikan ulang.
Cara Anda menetapkan prioritas resource memengaruhi jumlah resource kluster yang dapat di-overcommit serta ketersediaan resource pada node tersebut.
Resource untuk overcommit dijelaskan dan diperbarui sebagai extended resource standar dalam metadata node.
Tabel berikut menjelaskan prioritas resource yang digunakan di ACK.
Resource Priority | Perhitungan jumlah resource | Nama Sumber Daya |
Product | Umumnya, jumlah resource Product sama dengan jumlah resource fisik yang disediakan oleh node. | Resource yang dapat dialokasikan pada node, termasuk resource CPU dan memori. |
Batch | Jumlah resource Batch sama dengan jumlah resource yang di-overcommit, yang dihitung secara dinamis berdasarkan pemanfaatan resource pada node. Jumlah resource untuk overcommit dihitung berdasarkan rumus berikut: Jumlah resource untuk overcommit = Total jumlah resource fisik pada node – Jumlah resource Product yang digunakan. Untuk informasi selengkapnya, lihat Dynamic resource overcommitment. | Resource Batch dijelaskan dan diperbarui sebagai extended resource dalam metadata node menggunakan parameter |
Kelas QoS menggambarkan sensitivitas resource aplikasi. Pod dengan kelas QoS berbeda berjalan pada tingkat kinerja yang berbeda untuk memenuhi SLO yang berbeda. Kelas QoS yang berbeda memiliki parameter isolasi resource yang berbeda pula. Saat resource pada node tidak mencukupi, resource lebih diutamakan dialokasikan ke Pod dengan kelas QoS prioritas tinggi. Tabel berikut menjelaskan kelas QoS yang digunakan di ACK.
Kelas QoS | Workload yang sesuai | Deskripsi |
LS (Latency Sensitive) | Layanan online (workload LS) | Workload LS diprioritaskan dalam penjadwalan time slice CPU dan alokasi resource memori, termasuk resource cache L3 (last level cache) dan bandwidth memori. Sistem lebih memilih untuk mereklaim memori dari workload BE dan menyisihkan resource memori untuk workload LS saat proses reclaim memori dipicu. |
BE (Best Effort) | Pekerjaan intensif resource (workload BE) | Workload BE memiliki prioritas lebih rendah dibandingkan workload LS dalam penjadwalan time slice CPU. Resource cache L3 dan bandwidth memori yang dapat digunakan oleh workload BE dibatasi. Dibandingkan dengan workload LS, sistem lebih memilih mereklaim memori dari workload BE saat proses reclaim memori dipicu. |
Prioritas resource dan kelas QoS bersifat independen satu sama lain dan dapat digunakan secara kombinasi. Namun, karena keterbatasan model colocation dan kebutuhan bisnis, hanya kombinasi berikut yang digunakan:
Product + LS: Kombinasi ini cocok untuk aplikasi online yang memerlukan latensi rendah dan harus diprioritaskan dalam alokasi resource, seperti aplikasi web dan pekerjaan stream computing yang sensitif terhadap latensi.
Batch + BE: Kombinasi ini cocok untuk aplikasi offline yang memiliki prioritas lebih rendah dibandingkan aplikasi online dalam alokasi resource, seperti pekerjaan batch Spark, pekerjaan batch MapReduce, dan pekerjaan pelatihan AI.
Mengelola kebijakan colocation
ACK menyediakan ConfigMap yang dapat Anda gunakan untuk mengelola kebijakan colocation ack-koordinator. Untuk mengaktifkan semua kebijakan colocation ack-koordinator, lakukan langkah-langkah berikut:
Buat file bernama configmap.yaml berdasarkan konten ConfigMap berikut:
# Contoh ConfigMap ack-slo-config. 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 } }Tabel berikut menjelaskan parameter yang menentukan kebijakan colocation berbeda dalam contoh di atas.
Parameter
Deskripsi
colocation-config
Saat kebijakan ini ditentukan, ack-slo-config mengumpulkan data pemantauan waktu nyata tentang beban node, lalu menganalisis data tersebut untuk mengidentifikasi resource yang dapat di-overcommit. Jika resource dialokasikan ke Pod tetapi tidak sedang digunakan, resource tersebut dapat di-overcommit. Untuk informasi selengkapnya, lihat Dynamic resource overcommitment.
resource-qos-config
Saat kebijakan ini ditentukan, ack-slo-config mengelola berbagai jenis resource secara detail halus dan memastikan bahwa resource lebih diutamakan dialokasikan ke Pod dengan kelas QoS prioritas tinggi. Untuk informasi selengkapnya, lihat CPU QoS, Memory QoS untuk kontainer, dan Resource isolation based on the L3 cache and MBA.
resource-threshold-config
Saat kebijakan ini ditentukan, ack-slo-config secara dinamis membatasi resource yang dapat digunakan oleh Pod dengan kelas QoS prioritas rendah berdasarkan watermark pemanfaatan resource pada node. Untuk informasi selengkapnya, lihat Elastic resource limit.
Jalankan perintah berikut untuk membuat ConfigMap:
kubectl apply -f configmap.yaml
Deploy aplikasi
Buat file bernama nginx-ls-pod.yaml dan salin konten berikut ke dalam file tersebut.
Tetapkan kelas QoS aplikasi latency-sensitive ke
LS. Pada contoh ini,koordinator.sh/qosClass: LSditentukan dalam bagianlabelspada konfigurasi Pod yang dibuat untuk aplikasi NGINX.--- # Konfigurasi aplikasi Nginx apiVersion: v1 data: config: |- user nginx; worker_processes 80; # Jumlah proses worker Nginx, yang memengaruhi konkurensi. events { worker_connections 1024; # Nilai default adalah 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 --- # Manifest untuk 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 # Port host yang akan menerima permintaan untuk pengujian beban. 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: configBuat file bernama ffmpeg-be-pod.yaml dan salin konten berikut ke dalam file tersebut:
Tetapkan kelas QoS aplikasi intensif resource ke
BEdan konfigurasikan overcommit resource dengan menentukan parameterkubernetes.io/batch-cpudankubernetes.io/batch-memory. Pada contoh ini,koordinator.sh/qosClass: BEditentukan dalam bagianlabelspada konfigurasi Pod yang dibuat untuk aplikasi transkoding.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: # Satuan: millicores. kubernetes.io/batch-cpu: "70k" kubernetes.io/batch-memory: "22Gi" requests: # Satuan: millicores. kubernetes.io/batch-cpu: "70k" kubernetes.io/batch-memory: "22Gi"Jalankan perintah berikut untuk mendeploy Pod untuk aplikasi latency-sensitive dan aplikasi intensif resource:
kubectl apply -f nginx-ls-pod.yaml kubectl apply -f ffmpeg-be-pod.yaml
Langkah selanjutnya
Setelah aplikasi dideploy, Anda dapat menggunakan fitur colocation yang disediakan oleh ACK. Untuk informasi selengkapnya, lihat Colocate online services and video transcoding applications.
Untuk informasi lebih lanjut mengenai fitur colocation, lihat topik-topik berikut: