Temu duga reka bentuk sistem: bagaimanakah anda mereka bentuk penjadualan gang peka topologi untuk beban kerja Kubernetes?

Masalah dan senario yang berkenaan

Anda memiliki platform latihan teragih di Kubernetes. Beban kerja diwakili oleh PodGroup, dan Pod-Podnya harus berkongsi rak atau zon untuk mengurangkan kependaman komunikasi. Jika satu domain topologi tidak dapat memuatkan sekurang-kurangnya minCount Pod, beban kerja harus kekal tidak boleh dijadualkan (unschedulable).

Ini sesuai untuk temu duga kejuruteraan platform, SRE, dan reka bentuk sistem. Andaikan Topology-Aware Scheduling Kubernetes v1.36 alpha, dilumpuhkan secara lalai, dengan satu kekangan topologi bagi setiap PodGroup.

Perkara yang dinilai oleh penemu duga

• Sama ada anda membezakan pengimbangan merentas domain dengan penyebaran topologi (topology spread) daripada penempatan domain yang sama untuk satu gang.
• Sama ada PodGroup, label nod, penempatan calon, kebolehlaksanaan sumber, dan pengikatan atomik (atomic binding) membentuk satu aliran data.
• Sama ada anda menerangkan minCount, kekurangan kapasiti, peningkatan skala (scale-up), dan ketiadaan preemption yang dicetuskan oleh topologi.
• Sama ada anda mengenal pasti status alpha, kumpulan heterogen, dan risiko rollback sebelum menyatakan reka bentuk sedia untuk pengeluaran (production-ready).

Soalan penjelasan sebelum menjawab

1. Adakah Pod mesti berkongsi rak, zon, atau domain NUMA? Setiap kunci topologi mengubah andaian kependaman dan kapasiti.
2. Adakah setiap Pod mesti bermula bersama-sama, atau adakah minCount mencukupi untuk membuat kemajuan? Ini menentukan dasar Gang dan keanjalan.
3. Adakah Pod homogen? Permintaan sumber yang berbeza mempengaruhi sama ada penempatan calon boleh ditemui.
4. Bolehkah kluster diskalakan atau melakukan preemption? v1.36 TAS tidak melakukan preemption semata-mata untuk memenuhi topologi.

Rangka jawapan 30 saat

"Saya mentakrifkan matlamat sebagai kebolehlaksanaan peringkat kumpulan di dalam satu domain topologi, bukan penyebaran replika. Templat Workload mencipta PodGroup dengan gang dan minCount; label nod menyediakan kunci topologi. Penjadual menjana subset nod calon, menyemak keseluruhan kumpulan, dan memberi skor kepada penempatan yang boleh dilaksanakan. Jika tiada yang sesuai, kumpulan kekal tidak boleh dijadualkan. Pengawal dan autoscaler menilai keseluruhan bentuk sumber, dan preemption dikendalikan secara berasingan kerana v1.36 TAS tidak mencetuskannya. Saya menguji kapasiti domain, kehilangan nod, dan permintaan heterogen di sebalik feature gate alpha."

Perbincangan mendalam langkah demi langkah

1. Nyatakan ko-lokasi, bukan penyebaran

topologySpreadConstraints menggunakan maxSkew untuk mengimbangi Pod merentas domain; soalan ini memerlukan semua ahli berkongsi satu nilai label topologi. Mencampurkan semantik ini menghasilkan penempatan yang bertentangan, jadi tuliskan invarian sebagai "satu domain mesti memuatkan sekurang-kurangnya minCount."

2. Tentukan kontrak PodGroup

Templat mengisytiharkan dasar Gang, minCount, dan satu kunci topologi. Konfigurasi ilustrasi adalah:

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
spec:
  schedulingPolicy:
    gang:
      minCount: 4
  schedulingConstraints:
    topology:
      - key: topology.example.com/rack

Nod memerlukan nilai label yang stabil dan ditadbir. PodGroup menyatakan penempatan; pengawal Workload masih memiliki penciptaan ahli, versi, dan kitaran hayat.

3. Terangkan penempatan calon

Penjadual terlebih dahulu menjana subset nod calon menggunakan sumber, taints, afiniti, dan kunci topologi. Ia kemudian menyemak sama ada keseluruhan PodGroup muat dalam setiap subset dan memberi skor kepada penempatan yang boleh dilaksanakan. Ini mengelakkan pengikatan awal Pod merentas domain yang menyebabkan baki ahli tidak dapat memenuhi minCount.

4. Kendalikan kapasiti, peningkatan skala, dan preemption

Jika tiada domain calon yang mempunyai kapasiti yang mencukupi, keseluruhan kumpulan kekal tidak boleh dijadualkan. Autoscaler harus mengambil kira bentuk penuh CPU, memori, GPU, dan domain dan bukannya menskalakan untuk Pod Pending yang pertama. v1.36 TAS tidak mencetuskan preemption Pod atau Workload untuk memenuhi topologi, jadi tempahan kapasiti, barisan gilir, atau dasar preemption huluan (upstream) yang eksplisit adalah keperluan berasingan.

5. Kendalikan penciptaan semula ahli dan kelekitan domain (domain stickiness)

Apabila ahli telah dijalankan dalam sesuatu domain, Pod yang dicipta semula dipaksa ke dalam domain yang sama; mereka kekal Pending jika domain itu kekurangan kapasiti walaupun domain lain mempunyai ruang. Dedahkan ini sebagai penantian lekit domain (domain-sticky wait) dan tentukan sama ada untuk menunggu, memulihkan checkpoint, atau mencipta generasi PodGroup baharu dengan kekangan yang berbeza.

6. Nilai had alpha dan heterogen

API v1.36 adalah alpha dan dilumpuhkan secara lalai. Nota keluaran rasmi menyatakan bahawa PodGroup heterogen atau pergantungan antara-Pod tidak dijamin menemui penempatan walaupun penempatan wujud. Pintu pengeluaran harus merangkumi versi, feature gate, pemalam penjadual, autoscaler, dan rollback; satu penjadualan yang berjaya bukanlah jaminan sejagat.

7. Bina gelung pengesahan dan pengunduran (rollback)

Jalankan beban kerja latihan yang sama dengan kapasiti domain yang cukup-cukup sahaja, satu nod hilang, label topologi hilang, jenis GPU berbeza, dan penciptaan semula ahli. Rekodkan domain calon, bilangan ahli yang boleh dilaksanakan, sebab Pending, masa menunggu, trafik merentas domain, dan daya pemprosesan (throughput) latihan. Jika ujian kenari gagal, lumpuhkan feature gate atau kembali kepada penjadualan Gang biasa sambil mengekalkan peristiwa PodGroup untuk audit.

Contoh jawapan berkualiti tinggi

Saya akan mentakrifkan invarian sebagai "sekurang-kurangnya minCount ahli muat secara serentak dalam satu domain topologi," dan bukannya menggunakan kekangan penyebaran untuk keseimbangan. Pengawal Workload mencipta PodGroup dengan Gang, minCount, dan satu kunci topologi, kemudian mencipta Pod yang merujuknya. Penjadual menjana domain calon daripada sumber dan label nod, menyemak kumpulan lengkap, dan hanya memberi skor kepada domain yang boleh dilaksanakan; jika tiada yang berjaya, kumpulan kekal Pending. Autoscaler menskalakan daripada bentuk kumpulan, manakala preemption diasingkan kerana v1.36 TAS tidak mencetuskannya. Ahli yang dicipta semula mengekalkan kelekitan domain; jika domain itu hilang, cipta generasi baharu. Akhir sekali, uji kehilangan nod, label yang hilang, GPU heterogen, dan rollback di sebalik get alpha sambil mengukur masa menunggu, trafik merentas domain, dan daya pemprosesan latihan.

Kesilapan lazim

• Gejala: Menerangkan penempatan domain yang sama dengan maxSkew. Sebab ia gagal: penyebaran menyasarkan pengedaran, bertentangan dengan ko-lokasi Gang. Pembetulan: nyatakan invarian domain tunggal PodGroup terlebih dahulu.
• Gejala: Mengikat Pod satu demi satu. Sebab ia gagal: pengikatan awal menggunakan kapasiti di beberapa domain dan tidak meninggalkan cara untuk mencapai minCount. Pembetulan: nilaikan penempatan calon yang lengkap terlebih dahulu.
• Gejala: Menganggap TAS melakukan preemption secara automatik. Sebab ia gagal: v1.36 menyatakan secara jelas bahawa penjadualan peka topologi tidak mencetuskan preemption. Pembetulan: reka bentuk tempahan, barisan gilir, atau pengawal preemption huluan.
• Gejala: Mengabaikan kumpulan heterogen dan status alpha. Sebab ia gagal: penempatan tidak dijamin dan ciri ini dilumpuhkan secara lalai. Pembetulan: tambah semakan versi, get, pemalam, dan rollback.

Soalan susulan dan jawapan

Bagaimana jika satu rak tidak dapat memuatkan minCount, tetapi dua rak bersama-sama boleh memuatkannya?

Invarian domain yang sama tidak dipenuhi, jadi kekalkan kumpulan dalam keadaan Pending atau kurangkan minCount hanya jika aplikasi membenarkan keanjalan. Jangan berundur secara senyap kepada penempatan merentas rak kerana andaian komunikasi telah berubah.

Bagaimanakah autoscaler harus menskalakan dengan betul?

Anggap permintaan sumber penuh, kunci topologi, dan minCount sebagai satu unit skala. Ramalkan jenis dan bilangan nod yang diperlukan dalam domain sasaran, jana semula calon selepas peningkatan skala, dan laksanakan had masa menunggu (wait deadline).

Mengapakah ahli yang dicipta semula tidak boleh berpindah ke domain lain?

Tingkah laku yang didokumenkan mengekalkan ahli baharu dalam domain tempat ahli sedia ada berjalan; memindahkan satu ahli mengubah kependaman dan andaian sumber kongsi. Jika domain itu hilang secara kekal, cipta generasi PodGroup baharu dan bukannya mengubah yang lama secara senyap.

Bagaimanakah ini boleh wujud bersama dengan kekangan penyebaran topologi (topology spread constraints)?

Gunakan TAS untuk menempatkan ahli bersama dalam satu tugasan latihan; gunakan spread untuk mengedarkan replika merentas pelbagai tugasan. Sebelum meletakkan kedua-duanya pada satu Pod, uji sama ada kekangan ketat (hard constraints) mereka mempunyai persilangan yang tidak kosong atau Pod mungkin kekal Pending.

Bilakah penjadualan Gang biasa lebih baik daripada TAS?

Pilih Gang biasa apabila komunikasi merentas domain adalah murah, kapasiti domain sering ketat, ciri alpha belum bersedia untuk pelancaran anda, atau beban kerja tidak memerlukan rak kongsi. Dayakan TAS hanya apabila peningkatan daya pemprosesan mewajarkan kapasiti dan kos operasi.