Arsitektur teknis, model sumber daya hibrid, dan QoS tingkat node dari penyatuan - Container Service for Kubernetes

Tema ini menjelaskan arsitektur, model sumber daya, dan Kualitas Layanan (QoS) tingkat node yang digunakan untuk membantu Anda menyatukan beban kerja sensitif-latensi (LS) dan usaha terbaik (BE).

Informasi latar belakang

Dari perspektif kluster, penyatuan mengacu pada penyebaran berbagai jenis beban kerja di kluster yang sama, serta menganalisis karakteristik beban kerja dan memprediksi lonjakan permintaan sumber daya untuk meningkatkan pemanfaatan sumber daya kluster. Dari perspektif node, penyatuan mengacu pada penyebaran beberapa kontainer pada node yang sama. Kontainer-kontainer ini digunakan untuk berbagai jenis beban kerja, termasuk beban kerja LS dan BE. Beban kerja dapat diklasifikasikan menjadi beban kerja LS dan BE berdasarkan Tujuan Tingkat Layanan (SLO) mereka. Beban kerja LS biasanya memiliki tujuan permintaan per detik (QPS) atau waktu respons (RT) dan diberi kelas QoS prioritas tinggi. Sebagian besar beban kerja BE adalah beban kerja komputasi-intensif dengan toleransi kesalahan tinggi. Beban kerja ini biasanya diberi kelas QoS prioritas rendah.

Berikut ini menjelaskan fokus peran yang berbeda selama proses penyatuan:

Administrator sumber daya kluster: ingin menyederhanakan manajemen sumber daya kluster dan memantau batas sumber daya, alokasi sumber daya, serta penggunaan sumber daya setiap beban kerja untuk meningkatkan pemanfaatan sumber daya kluster dan mengurangi biaya TI.
Administrator beban kerja LS: fokus pada interferensi antar kontainer dari berbagai jenis beban kerja karena penyatuan dapat dengan mudah menyebabkan persaingan sumber daya. Beban kerja tersebut dapat merespons dengan latensi persentil ke-90 atau persentil ke-99. Ini menunjukkan bahwa sejumlah permintaan tertentu diproses dengan latensi jauh lebih tinggi daripada rata-rata. Akibatnya, kualitas layanan menurun.
Administrator beban kerja BE: ingin menggunakan overcommitment sumber daya yang terklasifikasi dan andal untuk memenuhi SLO dari berbagai beban kerja.

Container Service for Kubernetes (ACK) menggunakan mekanisme berikut untuk memenuhi persyaratan sebelumnya dalam skenario penyatuan:

Menyediakan model QoS untuk penyatuan dan memungkinkan Anda menetapkan prioritas sumber daya.
Menyediakan overcommitment sumber daya yang stabil dan andal.
Mendukung orkestrasi dan isolasi granular halus dari sumber daya Kubernetes.
Menyediakan kemampuan penjadwalan beban kerja yang ditingkatkan.

Arsitektur

ACK menggunakan komponen ack-koordinator untuk memenuhi SLO dari berbagai beban kerja yang disatukan dalam kluster yang sama. ack-koordinator terdiri dari kontroler SLO dan agen SLO. Kontroler SLO adalah ekstensi standar Kubernetes. Kontroler SLO diterapkan menggunakan Deployment dan agen SLO diterapkan menggunakan DaemonSet. Agen SLO mendukung semua kemampuan kubelet dan menyediakan berbagai kemampuan penyatuan.

Gambar di atas menunjukkan arsitektur penyatuan. Solusi penyatuan sadar-SLO dari ACK mendefinisikan beberapa protokol. Protokol-protokol ini memungkinkan ACK mencatat data deret waktu dari node, konfigurasi kebijakan QoS, dan penegakan kebijakan QoS menggunakan definisi sumber daya kustom (CRD), serta mencatat jumlah sumber daya yang tersedia untuk overcommitment dinamis menggunakan sumber daya ekstensi standar. Komponen dalam gambar menyediakan fitur-fitur berikut:

Kontroler SLO: memantau beban setiap node, melakukan overcommitment sumber daya, dan menjamin SLO berdasarkan profil sumber daya.
Recommender: menyediakan fitur profil sumber daya dan memperkirakan permintaan sumber daya puncak dari beban kerja. Recommender menyederhanakan konfigurasi permintaan dan batas sumber daya untuk kontainer.
Koordlet: memantau beban setiap node, mendeteksi anomali, mengisolasi sumber daya secara dinamis, dan menekan interferensi dalam loop tertutup.
Penjadwal ACK: mengoptimalkan penyatuan sadar-SLO. Misalnya, penjadwal ACK dapat menyebarkan pod saat sumber daya secara dinamis diovercommit.
Descheduler Koordinator: diterapkan sebagai Deployment dan digunakan untuk penjadwalan ulang.

Model sumber daya

Mekanisme manajemen sumber daya yang digunakan oleh Kubernetes mengharuskan kontainer untuk mengajukan permohonan sumber daya berdasarkan permintaan dan batas sumber daya. Untuk mencegah persaingan sumber daya, administrator biasanya menetapkan permintaan dan batas sumber daya kontainer ke nilai yang lebih besar untuk beban kerja LS. Akibatnya, sejumlah besar sumber daya diminta tetapi pemanfaatan sumber daya aktual masih rendah.

Blok hijau pada gambar berikut menunjukkan jumlah sumber daya yang dapat diovercommit secara dinamis. Sumber daya tersebut dialokasikan ke beban kerja BE untuk memastikan bahwa berbagai beban kerja dapat memenuhi SLO mereka dan meningkatkan pemanfaatan sumber daya secara keseluruhan.

ack-koordinator dapat menghitung sumber daya yang dapat diovercommit secara dinamis, menghitung jumlah sumber daya yang direklaim secara real-time, dan menyinkronkan informasi tersebut sebagai sumber daya ekstensi standar ke metadata node Kubernetes.

Kode sampel berikut memberikan contoh template YAML dari 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

Prioritas pod BE lebih rendah daripada pod LS. Untuk mengonfigurasi pod BE agar menggunakan sumber daya yang direklaim, Anda hanya perlu menambahkan bidang qos dan batch ke template YAML pod BE. qos: LS menunjukkan prioritas tinggi dan qos: BE menunjukkan prioritas rendah. batch-cpu dan batch-memory menunjukkan jumlah sumber daya yang diminta oleh pod. Untuk informasi lebih lanjut, lihat Aktifkan Overcommitment Sumber Daya Dinamis.

Kode sampel berikut memberikan contoh template YAML dari pod BE:

metadata:
  labels:
    koordinator.sh/qosClass: "BE" # Setel 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

Untuk memesan sumber daya CPU untuk pod LS dan mencegah pod BE bersaing untuk sumber daya, Anda dapat menggunakan fitur CPU QoS yang disediakan oleh komponen ack-koordinator. Fitur CPU QoS didasarkan pada Alibaba Cloud Linux. Komponen ack-koordinator memungkinkan Anda menggunakan fitur identitas grup untuk mengonfigurasi prioritas penjadwalan Linux untuk pod. Dalam lingkungan di mana pod LS dan BE disatukan, Anda dapat menyetel prioritas pod LS ke tinggi dan prioritas pod BE ke rendah untuk mencegah persaingan sumber daya. Pod LS diprioritaskan untuk menggunakan sumber daya CPU yang terbatas. Ini memastikan kualitas layanan dari beban kerja LS.

Manfaat berikut tersedia setelah Anda mengaktifkan fitur CPU QoS:

Latensi bangun tugas untuk beban kerja LS diminimalkan.
Membangunkan tugas untuk beban kerja BE tidak memengaruhi kinerja pod LS secara negatif.
Tugas untuk beban kerja BE tidak dapat menggunakan penjadwal SMT untuk berbagi inti CPU. Ini lebih lanjut mengurangi dampak pada kinerja pod LS.

CPU Suppress

Dalam model sumber daya penyatuan, jumlah total sumber daya yang dapat diovercommit secara dinamis bervariasi berdasarkan penggunaan sumber daya pod LS. Sumber daya tersebut dapat dialokasikan ke pod BE. Untuk memastikan sumber daya CPU yang cukup untuk pod LS pada node, Anda dapat menggunakan fitur CPU Suppress dari ack-koordinator untuk membatasi penggunaan sumber daya pod BE pada node. Fitur CPU Suppress dapat membatasi jumlah sumber daya CPU yang dapat digunakan oleh pod BE ketika penggunaan sumber daya keseluruhan node berada di bawah ambang batas. Ini memastikan bahwa kontainer pada node memiliki sumber daya yang cukup untuk berjalan secara stabil.

Pada gambar berikut, CPU Threshold menunjukkan ambang batas penggunaan CPU suatu node. Pod (LS).Usage menunjukkan penggunaan CPU pod LS. CPU Restriction for BE menunjukkan penggunaan CPU pod BE. Jumlah sumber daya CPU yang dapat digunakan oleh pod BE disesuaikan berdasarkan fluktuasi penggunaan CPU pod LS. Ini memungkinkan pod BE memanfaatkan sumber daya idle dan meningkatkan throughput beban kerja BE. Ini juga mencegah pod BE bersaing untuk sumber daya ketika beban beban kerja LS meningkat.

CPU Burst

Kubernetes memungkinkan Anda menggunakan batas sumber daya untuk mengelola sumber daya Kubernetes. Anda dapat menetapkan batas CPU untuk memungkinkan kernel OS membatasi jumlah sumber daya CPU yang dapat digunakan oleh kontainer dalam periode waktu tertentu. Misalnya, Anda dapat menentukan CPU Limit=2. Kernel OS membatasi irisan waktu CPU yang dapat digunakan oleh kontainer menjadi 200 milidetik dalam setiap periode 100-milidetik.

Gambar berikut menunjukkan alokasi utas dari kontainer aplikasi web yang berjalan pada node dengan empat vCore. Batas CPU kontainer diatur ke 2. Pemanfaatan CPU keseluruhan dalam satu detik terakhir rendah. Namun, Thread 2 tidak dapat dilanjutkan hingga periode 100-milidetik ketiga dimulai karena pembatasan CPU diberlakukan di suatu tempat dalam periode 100-milidetik kedua. Ini meningkatkan waktu respons (RT) dan menyebabkan masalah latensi ekor panjang dalam kontainer.

RT长尾

Fitur CPU Burst dapat secara efisien menyelesaikan masalah latensi ekor panjang dalam beban kerja LS. Fitur ini memungkinkan kontainer mengumpulkan irisan waktu CPU ketika kontainer sedang idle. Irisan waktu CPU ini dapat digunakan untuk menangani lonjakan permintaan sumber daya dan meningkatkan kinerja kontainer. ACK memungkinkan Anda menggunakan semua versi kernel yang mendukung CPU Burst. Untuk versi kernel yang tidak mendukung CPU Burst, ACK memantau pembatasan CPU dan menyesuaikan batas CPU kontainer secara dinamis untuk mengoptimalkan kinerja kontainer dengan cara serupa seperti CPU Burst.

CPU Burst

Memory QoS

Batas memori berikut berlaku untuk kontainer:

Batas memori kontainer. Jika jumlah memori yang digunakan oleh kontainer, termasuk memori yang digunakan oleh cache halaman, hampir mencapai batas memori kontainer, mekanisme pengambilan kembali memori kernel OS dipicu. Akibatnya, aplikasi dalam kontainer mungkin tidak dapat meminta atau melepaskan sumber daya memori sesuai harapan.
Batas memori node. Jika batas memori kontainer lebih besar daripada permintaan memori kontainer, kontainer dapat melakukan overcommit sumber daya memori. Dalam kasus ini, memori yang tersedia pada node mungkin menjadi tidak mencukupi. Ini menyebabkan kernel OS mengambil kembali memori dari kontainer. Dalam kasus ekstrem seperti penyatuan, kinerja aplikasi Anda sangat menurun.

Untuk meningkatkan kinerja runtime dan stabilitas node, ack-koordinator bekerja sama dengan Alibaba Cloud Linux untuk mengaktifkan fitur memory QoS untuk pod. ack-koordinator secara otomatis mengonfigurasi memcg berdasarkan konfigurasi kontainer, dan memungkinkan Anda mengaktifkan fitur memcg QoS, fitur pengambilan kembali asinkron memcg backend, dan fitur peringkat watermark minimum global untuk kontainer. Ini mengoptimalkan kinerja aplikasi sensitif-memori sambil memastikan penjadwalan memori yang adil di antara kontainer.

Memory QoS menyediakan fitur-fitur berikut:

Jika memori yang digunakan oleh pod hampir mencapai batas memori pod, memcg mengambil kembali sejumlah memori secara asinkron. Ini mencegah sistem mengambil kembali semua memori yang digunakan oleh pod dan oleh karena itu meminimalkan dampak buruk pada kinerja aplikasi yang disebabkan oleh pengambilan kembali sumber daya memori secara langsung.
Memori dapat diambil kembali secara lebih adil dari pod. Ketika node tidak memiliki sumber daya memori yang cukup, memori diambil kembali dari pod yang penggunaan memorinya lebih besar daripada permintaan memori. Ini membantu mencegah penurunan kinerja yang disebabkan oleh pod yang melakukan overcommit sumber daya memori.
Permintaan memori pod LS diprioritaskan. Dengan cara ini, pod LS lebih kecil kemungkinannya untuk memicu memcg untuk mengambil kembali semua sumber daya memori pada node. Gambar berikut menunjukkan sebuah contoh.
- memory.limit_in_bytes: batas atas memori yang dapat digunakan oleh pod.
- memory.high: ambang batas throttling memori.
- memory.wmark_high: ambang batas pengambilan kembali memori.
- memory.min: ambang batas kunci memori.

Isolasi sumber daya berbasis L3 cache dan MBA

Ketika kontainer dari beban kerja yang berbeda disatukan pada node, kontainer-kontainer tersebut berbagi L3 cache (cache level terakhir) dari node. Bandwidth memori yang didistribusikan di seluruh beban kerja ini dikendalikan oleh Memory Bandwidth Allocation (MBA). Instans bare metal ECS menyediakan fitur last-level cache (LLC) untuk menyesuaikan cache CPU yang dapat digunakan oleh pod secara dinamis dan fitur MBA untuk mengendalikan distribusi bandwidth memori. Selain itu, ack-koordinator membatasi sumber daya yang digunakan oleh pod BE secara halus untuk memastikan kinerja pod LS.

Apa yang harus dilakukan selanjutnya

Anda dapat merujuk ke Memulai dan menggunakan ack-koordinator untuk membangun lingkungan di mana beban kerja LS dan BE disatukan. Untuk informasi lebih lanjut tentang fitur penyatuan, lihat topik berikut: