Arsitektur teknis, model resource hibrida, dan QoS tingkat node untuk colocation - Container Service for Kubernetes

Topik ini menjelaskan arsitektur teknis, model resource hibrida, dan QoS tingkat node untuk menempatkan workload online dan offline dalam satu kluster yang sama, guna membantu Anda memahami dan menggunakan colocation di ACK.

Latar Belakang

Colocation menempatkan berbagai jenis workload dalam kluster dan node yang sama untuk meningkatkan pemanfaatan resource. Workload diklasifikasikan berdasarkan Service Level Objective (SLO): workload latency-sensitive (LS) biasanya memiliki target QPS atau waktu respons (RT) serta menerima QoS prioritas tinggi, sedangkan workload best-effort (BE) bersifat komputasi-intensif, toleran terhadap kegagalan, dan menerima QoS prioritas rendah.

Peran yang berbeda fokus pada aspek colocation yang berbeda:

Administrator resource kluster: memantau batas resource, alokasi, dan penggunaan per workload untuk meningkatkan pemanfaatan dan mengurangi biaya.
Administrator workload LS: mengurangi gangguan kontainer akibat konflik sumber daya yang dapat menyebabkan peningkatan latensi persentil ke-90/99 dan menurunkan kualitas layanan.
Administrator workload BE: memanfaatkan overcommitment resource terklasifikasi untuk memenuhi SLO workload.

ACK menyediakan mekanisme colocation berikut:

Menyediakan model QoS colocation dengan prioritas resource yang dapat dikonfigurasi.
Menyediakan overcommitment resource yang stabil dan andal.
Mendukung orkestrasi dan isolasi resource Kubernetes yang detail halus.
Menyediakan penjadwalan workload yang ditingkatkan.

Arsitektur

ACK menggunakan ack-koordinator untuk memenuhi SLO workload dalam skenario colocation. ack-koordinator terdiri dari SLO controller (ekstensi Kubernetes yang dideploy sebagai Deployment) dan SLO agent (dideploy sebagai DaemonSet) yang memperluas kubelet dengan kemampuan colocation.

Solusi colocation yang sadar SLO menggunakan CRD untuk mencatat metrik node, konfigurasi QoS, dan penerapan kebijakan, serta melacak resource yang tersedia untuk overcommitment dinamis sebagai extended resource standar. Setiap komponen menyediakan fitur berikut:

SLO controller: memantau beban node, melakukan overcommit resource, dan menjamin SLO berdasarkan profil resource.
Recommender: membuat profil resource dan memperkirakan permintaan puncak workload untuk menyederhanakan konfigurasi resource kontainer.
Koordlet: memantau beban node, mendeteksi anomali, dan secara dinamis mengisolasi resource untuk menekan gangguan dalam loop tertutup.
Penjadwal ACK: mengoptimalkan colocation yang sadar SLO, seperti menyebarkan Pod selama overcommitment dinamis.
Koordinator Descheduler: dideploy sebagai Deployment untuk penjadwalan ulang Pod.

Model Resource

Kubernetes mengelola resource kontainer melalui requests dan limits. Untuk mencegah konflik, administrator sering kali over-provision workload LS, sehingga resource yang diminta menjadi kurang dimanfaatkan.

resource over-provisioning

Blok hijau menunjukkan resource yang tersedia untuk overcommitment dinamis. Resource ini dialokasikan ke workload BE untuk memenuhi SLO dan meningkatkan pemanfaatan keseluruhan.

ack-koordinator mengkuantifikasi resource yang dapat di-overcommit, menghitung resource yang direklaim secara real time, dan menyinkronkannya sebagai extended resource standar ke metadata node Kubernetes.

Contoh templat YAML node:

status:
  allocatable:
    # milli-core
    kubernetes.io/batch-cpu: 50000
    # bytes
    kubernetes.io/batch-memory: 50000
  capacity:
    kubernetes.io/batch-cpu: 50000
    kubernetes.io/batch-memory: 100000

Pod BE memiliki prioritas lebih rendah daripada pod LS. Untuk menggunakan resource yang direklaim, tambahkan bidang qos dan batch ke YAML pod BE. qos: LS menetapkan prioritas tinggi; qos: BE menetapkan prioritas rendah. batch-cpu dan batch-memory menentukan permintaan resource pod tersebut. Lihat Aktifkan overcommitment resource dinamis.

Contoh templat YAML pod BE:

metadata:
  labels:
    koordinator.sh/qosClass: "BE" # Tetapkan kelas QoS ke BE atau LS. 
spec:
  containers:
  - resources:
      limits:
        kubernetes.io/batch-cpu: 1000
        kubernetes.io/batch-memory: 2048
      requests:
        kubernetes.io/batch-cpu: 1000
        kubernetes.io/batch-memory: 2048

QoS Tingkat Node

CPU QoS

CPU QoS, berbasis Alibaba Cloud Linux, menyisihkan resource CPU untuk pod LS dengan mengonfigurasi prioritas penjadwalan Linux melalui fitur group identity ack-koordinator. Di lingkungan colocation, pod LS menerima prioritas tinggi dan pod BE menerima prioritas rendah, sehingga mencegah konflik sumber daya dan menjamin kualitas layanan LS.

Manfaat CPU QoS:

Meminimalkan latensi wake-up task untuk workload LS.
Wake-up task BE tidak memengaruhi performa pod LS.
Task BE tidak dapat menggunakan penjadwal SMT untuk berbagi core CPU, sehingga lebih lanjut mengurangi dampak terhadap performa pod LS.

CPU Suppress

Jumlah resource yang dapat di-overcommit secara dinamis bervariasi sesuai penggunaan pod LS dan dapat dialokasikan ke pod BE. CPU Suppress membatasi penggunaan CPU pod BE untuk memastikan pod LS di node memiliki resource yang cukup.

Pada gambar, CPU Threshold adalah ambang batas penggunaan CPU node, Pod (LS).Usage adalah penggunaan CPU pod LS, dan CPU Restriction for BE adalah penggunaan CPU pod BE. Alokasi CPU pod BE menyesuaikan diri seiring fluktuasi penggunaan pod LS, memungkinkan pod BE memanfaatkan resource idle sekaligus mencegah konflik saat beban LS meningkat.

CPU Burst

Batas CPU Kubernetes membatasi penggunaan CPU kontainer per periode waktu. Misalnya, CPU Limit=2 membatasi kontainer hingga 200 ms waktu CPU per periode 100 ms.

Gambar menunjukkan alokasi thread untuk kontainer aplikasi web pada node empat-vCore dengan CPU limit diatur ke 2. Meskipun pemanfaatan CPU keseluruhan rendah, Thread 2 tidak dapat dilanjutkan hingga periode 100 ms ketiga karena throttling CPU terjadi pada periode kedua. Hal ini meningkatkan waktu respons (RT) dan menyebabkan latensi ekor panjang.

long-tail RT latency

CPU Burst mengatasi latensi ekor panjang pada workload LS dengan memungkinkan kontainer mengumpulkan potongan waktu CPU idle untuk menangani lonjakan permintaan. ACK mendukung CPU Burst pada semua versi kernel yang kompatibel. Untuk kernel yang tidak kompatibel, ACK memantau throttling CPU dan secara dinamis menyesuaikan batas CPU kontainer untuk mencapai efek serupa.

CPU Burst

Memory QoS

Kontainer tunduk pada batas memori berikut:

Batas memori kontainer: saat penggunaan memori (termasuk page cache) mendekati batas, kernel OS memicu reclaim memori, yang dapat mencegah aplikasi meminta atau melepas memori seperti yang diharapkan.
Batas memori node: saat batas memori kontainer melebihi request-nya, kontainer dapat melakukan overcommit memori. Jika memori node yang tersedia menjadi tidak mencukupi, kernel OS akan mereclaim memori dari kontainer, yang dapat sangat menurunkan performa aplikasi dalam skenario colocation.

ack-koordinator bekerja sama dengan Alibaba Cloud Linux untuk mengaktifkan Memory QoS bagi pod. Fitur ini secara otomatis mengonfigurasi memcg berdasarkan pengaturan kontainer dan mengaktifkan fitur memcg QoS, reclaim asinkron backend, serta rating watermark minimum global. Hal ini mengoptimalkan performa aplikasi yang sensitif terhadap memori sekaligus menjamin penjadwalan memori yang adil.

Fitur Memory QoS:

Saat penggunaan memori pod mendekati batasnya, memcg melakukan reclaim memori secara asinkron untuk menghindari reclaim penuh sinkron, sehingga meminimalkan dampak terhadap performa aplikasi.
Saat memori node tidak mencukupi, memori direclaim secara prioritas dari pod yang penggunaannya melebihi request-nya, mencegah pod yang overcommit menurunkan performa pod lain.
Request memori pod LS diprioritaskan, mengurangi kemungkinan pemicuan reclaim memori penuh di node.
- memory.limit_in_bytes: batas atas memori yang dapat digunakan oleh pod.
- memory.high: ambang batas throttling memori.
- memory.wmark_high: ambang batas reclaim memori.
- memory.min: ambang batas lock memori.

Isolasi Resource Berbasis Cache L3 dan MBA

Kontainer yang ditempatkan bersama berbagi cache L3 node (last-level cache), dengan bandwidth memori dikendalikan oleh Memory Bandwidth Allocation (MBA). ECS Bare Metal Instance (EBM) menyediakan fitur LLC untuk menyesuaikan cache CPU pod secara dinamis dan fitur MBA untuk mengontrol distribusi bandwidth memori. ack-koordinator lebih lanjut membatasi resource pod BE secara detail halus untuk melindungi performa pod LS.

Langkah Selanjutnya

Lihat Memulai untuk membangun lingkungan colocation LS dan BE dengan ack-koordinator. Fitur colocation terkait: