Container Service for Kubernetes:FAQ Penjadwalan

Bagaimana cara mencegah kegagalan startup Pod akibat alamat IP yang tidak mencukupi di virtual switch?

Penjadwal Kubernetes native tidak memiliki visibilitas terhadap jumlah alamat IP yang tersedia pada suatu Node. Akibatnya, Pod dapat dijadwalkan ke Node yang telah kehabisan sumber daya IP, sehingga gagal saat startup—sering kali menghasilkan sejumlah besar Pod abnormal dalam waktu singkat.

ACK Scheduler mengatasi masalah ini melalui penjadwalan yang memperhatikan IP (IP-aware scheduling). Fitur ini membaca anotasi k8s.aliyun.com/max-available-ip pada setiap Node, yang menandai jumlah maksimum alamat IP yang tersedia, lalu menggunakan nilai tersebut untuk membatasi jumlah Pod yang memerlukan alamat IP independen pada Node tersebut. Ketika sumber daya IP pada suatu Node habis, ACK Scheduler menetapkan kondisi SufficientIP pada status Node, sehingga mencegah penjadwalan Pod baru yang memerlukan alamat IP independen ke Node tersebut.

Fitur ini diaktifkan secara otomatis oleh add-on kube-scheduler. Kluster Anda harus memenuhi persyaratan berikut:

• Kluster ini merupakan Kluster ACK yang dikelola Edisi Pro dengan plug-in jaringan Terway v1.5.7 atau versi yang lebih baru. Lihat Buat kluster ACK yang dikelola.

• Versi kube-scheduler memenuhi persyaratan berikut:

Apa kebijakan penjadwalan default dari ACK Scheduler?

ACK Scheduler mengikuti kebijakan default yang sama seperti penjadwal Kubernetes komunitas. Penjadwalan Pod melibatkan dua langkah utama:

• [Filter](https://kubernetes.io/docs/concepts/scheduling-eviction/scheduling-framework/#filter): Mengeliminasi Node tempat Pod tidak dapat berjalan. Jika tidak ada Node yang lolos filter, Pod tetap tidak dapat dijadwalkan.

• [Score](https://kubernetes.io/docs/concepts/scheduling-eviction/scheduling-framework/#scoring): Memberi peringkat Node yang tersisa dan memilih Node yang paling sesuai untuk Pod tersebut.

Untuk daftar lengkap plug-in Filter dan Score yang diaktifkan pada versi terbaru ACK Scheduler, lihat kube-scheduler.

Bagaimana cara menghindari penjadwalan Pod ke Node dengan pemanfaatan resource tinggi?

Penjadwal Kubernetes native membuat keputusan berdasarkan *request* resource, bukan pemanfaatan aktual. Akibatnya, beberapa Node bisa menjadi kelebihan beban sementara yang lain menganggur. ACK menyediakan tiga pendekatan untuk mengatasi hal ini:

• Tetapkan request dan limit resource yang akurat. Gunakan fitur profiling resource untuk mendapatkan rekomendasi spesifikasi kontainer berdasarkan data penggunaan historis. Lihat Profiling resource.

• Aktifkan load-aware scheduling. ACK Scheduler dapat mempertimbangkan beban aktual node saat membuat keputusan penjadwalan. Fitur ini menganalisis data beban historis, memperkirakan kebutuhan sumber daya untuk Pod yang masuk, dan menempatkannya secara preferensial pada node dengan pemanfaatan lebih rendah. Lihat Penjadwalan yang memperhatikan beban.

• Aktifkan descheduling hotspot berbasis beban. Pemanfaatan Node berubah seiring waktu akibat fluktuasi lalu lintas dan beban kerja. Fitur descheduling ACK mendeteksi hotspot dan mengusir (evict) Pod dari Node yang kelebihan beban untuk memulihkan keseimbangan. Lihat Menggunakan descheduling hotspot berbasis beban.

Node baru ditambahkan ke kluster. Mengapa Pod tidak dijadwalkan ke sana?

Periksa hal-hal berikut secara berurutan:

1. Status Node: Jika Node berada dalam status NotReady, penjadwal tidak akan menempatkan Pod di sana. Tunggu hingga Node menjadi Ready.

2. Batasan penjadwalan pada Pod: Periksa apakah Pod memiliki aturan nodeSelector, nodeAffinity, atau podAffinity, atau apakah Node memiliki taint yang tidak ditoleransi oleh Pod. Batasan ini dapat mencegah Pod ditempatkan pada Node baru meskipun Node tersebut tampak sehat.

3. Ketidakseimbangan request resource: Penjadwal Kubernetes native menempatkan Pod berdasarkan request resource, bukan pemanfaatan aktualnya. Jika node yang sudah ada memiliki kapasitas request gratis yang mencukupi, penjadwal mungkin tidak menggunakan node baru. Lihat Bagaimana cara menghindari penjadwalan Pod ke node dengan pemanfaatan resource tinggi? untuk solusinya.

Mengapa penjadwalan gagal karena CPU atau memori tidak mencukupi padahal pemanfaatan keseluruhan kluster tidak tinggi?

Penjadwal mengevaluasi resource yang direquest, bukan konsumsi aktual. Suatu Node mungkin memiliki penggunaan CPU aktual yang rendah tetapi tetap tampak "penuh" dari perspektif penjadwal jika Pod-nya memiliki request resource yang tinggi. Meskipun pemanfaatan kluster secara keseluruhan rendah, penjadwalan dapat gagal jika tidak ada satu pun Node yang memiliki kapasitas *request* yang cukup untuk menampung Pod baru tersebut.

Lihat Cara menghindari penjadwalan Pod ke Node dengan pemanfaatan resource tinggi untuk solusinya.

Apa yang perlu saya ketahui sebelum menggunakan descheduling di ACK? Apakah fitur ini me-restart Pod?

ACK menyediakan descheduling melalui Koordinator Descheduler. Dua hal yang perlu diperhatikan:

• Descheduling hanya mengusir (evict) Pod. Koordinator Descheduler mengusir Pod yang sedang berjalan tetapi tidak membuat ulang Pod tersebut. Pembuatan ulang ditangani oleh controller workload (Deployment, StatefulSet, dan sebagainya), sedangkan penjadwalan Pod baru ditangani oleh penjadwal.

• Pertahankan jumlah replika yang cukup. Selama proses descheduling, Pod lama diusir sebelum Pod baru dibuat. Pastikan workload Anda memiliki jumlah replika (replicas) yang cukup agar tetap tersedia selama jendela pengusiran.

Lihat Descheduling.

Bagaimana cara menjadwalkan aplikasi ke Node tertentu?

Tambahkan label ke node target dan sertakan nodeSelector yang sesuai dalam spesifikasi Pod aplikasi Anda. Lihat Jadwalkan aplikasi ke node tertentu.

Dalam Deployment, bagaimana cara menjadwalkan jumlah Pod tertentu ke ECS dan jumlah tertentu ke ECI?

Gunakan UnitedDeployment untuk menentukan subset terpisah untuk resource ECS dan ECI. Misalnya, tetapkan replicas: 10 pada subset ECS dan replicas: 10 pada subset ECI dalam spesifikasi UnitedDeployment. Lihat Skalakan workload berdasarkan UnitedDeployment.

Bagaimana cara memastikan ketersediaan tinggi untuk Pod workload selama penjadwalan?

Gunakan podAntiAffinity untuk menyebarkan Pod ke zona atau Node yang berbeda. Sebagai contoh, konfigurasi berikut mencoba menjadwalkan Pod dengan label security=S2 ke zona yang berbeda. Jika batasan tersebut tidak dapat dipenuhi, penjadwal akan menggunakan Node lain sebagai cadangan.

spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2
          topologyKey: topology.kubernetes.io/zone

Untuk opsi tambahan, lihat Pod affinity dan anti-affinity serta Pod topology spread constraints dalam dokumentasi Kubernetes.

Bagaimana cara memigrasikan ack-descheduler ke Koordinator Descheduler?

Add-on ack-descheduler tidak lagi dipelihara. Migrasikan ke Koordinator Descheduler yang aktif dikembangkan. Proses migrasi mengikuti langkah-langkah yang sama seperti migrasi Kubernetes Descheduler ke Koordinator Descheduler. Lihat Migrasikan Kubernetes Descheduler ke Koordinator Descheduler dan pemberitahuan migrasi di \[Pemberitahuan\] Migrasi ack-descheduler.

Add-on ack-descheduler yang tersedia di pasar ACK didasarkan pada Kubernetes Descheduler open source. Versi 0.20.0 dan 0.27.1 tersedia dan berfungsi sama seperti versi open source-nya.

Mengapa tidak semua Pod dalam batch dijadwalkan ke Node dengan beban terendah?

Menempatkan semua Pod baru pada Node dengan beban terendah saat ini akan menciptakan hotspot baru saat Pod tersebut mulai mengonsumsi resource. Untuk mencegah hal ini, plug-in penjadwalan yang memperhatikan beban menyesuaikan skor Node ketika Node tersebut sudah memiliki Pod yang baru dijadwalkan namun pemanfaatannya belum dilaporkan. Hal ini mencegah konsentrasi berlebihan dan menyeimbangkan beban lebih merata di seluruh Node.

Selain beban Node, faktor apa saja yang memengaruhi hasil penjadwalan?

Penjadwal Kubernetes menggunakan banyak plug-in yang semuanya berkontribusi pada peringkat akhir Node. Aturan afinitas, batasan penyebaran topologi, dan plug-in lainnya masing-masing menambah atau mengurangi skor Node. Penempatan akhir mencerminkan bobot gabungan dari semua plug-in yang aktif. Sesuaikan bobot penilaian setiap plug-in berdasarkan kebutuhan Anda.

Setelah melakukan upgrade penjadwal, apakah fitur penjadwalan yang memperhatikan beban dengan protokol lama masih didukung?

Protokol lama memerlukan anotasi alibabacloud.com/loadAwareScheduleEnabled: "true" pada Pod. ACK Scheduler kompatibel mundur dengan protokol ini, sehingga upgrade penjadwal tidak merusak Pod yang sudah ada. Setelah upgrade, beralihlah ke kebijakan penjadwalan yang memperhatikan beban secara global untuk menghindari pengelolaan anotasi per-Pod.

Tabel berikut merangkum dukungan protokol berdasarkan versi kluster.

Setelah mengaktifkan konfigurasi CPU Burst, mengapa Pod saya tetap mengalami throttling?

Beberapa kondisi dapat menyebabkan throttling CPU tetap terjadi:

• Format konfigurasi salah. Jika kebijakan CPU Burst tidak diformat dengan benar, kebijakan tersebut tidak akan diterapkan. Verifikasi format konfigurasi. Lihat Konfigurasi parameter lanjutan.

• Pemanfaatan CPU mencapai batas. Jika penggunaan CPU aktual mencapai batas cfsQuotaBurstPercent, throttling tetap terjadi karena tidak ada cukup resource CPU fisik. Sesuaikan nilai request dan limit agar sesuai dengan kebutuhan aktual aplikasi Anda.

• Latensi dalam penyesuaian `cpu.cfs_quota_us`. CPU Burst memodifikasi dua parameter cgroup: cpu.cfs_quota_us dan cpu.cfs_burst_us. Parameter cpu.cfs_quota_us hanya diperbarui setelah ack-koordinator mendeteksi throttling, yang menyebabkan sedikit penundaan. Parameter cpu.cfs_burst_us langsung diatur berdasarkan konfigurasi. Untuk hasil terbaik, gunakan fitur ini dengan Alibaba Cloud Linux.

• Ambang batas keamanan Node terpicu. CPU Burst mencakup mekanisme perlindungan yang mengatur ulang cpu.cfs_quota_us ke garis dasarnya jika pemanfaatan Node secara keseluruhan melebihi ambang batas sharePoolThresholdPercent. Tetapkan ambang batas keamanan Node berdasarkan kebutuhan aplikasi Anda untuk menghindari hal ini.

Apakah Alibaba Cloud Linux diperlukan untuk kebijakan CPU Burst?

Tidak. Kebijakan CPU Burst ack-koordinator berfungsi pada semua kernel open source Alibaba Cloud Linux dan CentOS. Namun, Alibaba Cloud Linux direkomendasikan karena ack-koordinator dapat memanfaatkan fitur tingkat kernel untuk menyediakan manajemen elastisitas CPU yang lebih granular. Lihat Aktifkan fitur CPU Burst pada antarmuka cgroup v1.

Setelah aplikasi menggunakan resource Batch, mengapa penggunaan memorinya tiba-tiba meningkat?

Untuk kontainer yang dikonfigurasi dengan limit memori Batch (kubernetes.io/batch-memory), ack-koordinator menetapkan limit memori cgroup setelah kontainer dimulai. Jika aplikasi membaca dan bertindak berdasarkan limit cgroup saat startup—sebelum ack-koordinator menerapkannya—aplikasi tersebut mungkin mengalokasikan lebih banyak memori daripada limit Batch yang dimaksudkan. Sistem operasi tidak segera mereklaim memori tersebut, sehingga limit cgroup tidak dapat diberlakukan sampai penggunaan aktual turun di bawah limit tersebut secara alami.

Untuk mengatasi hal ini, sesuaikan aplikasi agar penggunaan memorinya tetap di bawah limit Batch, atau periksa skrip startup aplikasi untuk memastikan parameter limit memori ditetapkan sebelum aplikasi diinisialisasi.

Jalankan perintah berikut di dalam kontainer untuk melihat limit memori saat ini (dalam byte):

# Satuannya adalah byte.
cat /sys/fs/cgroup/memory/memory.limit_in_bytes
# Output yang diharapkan.
1048576000

Setelah menambah jumlah core CPU, mengapa performa menurun dan CPU throttling meningkat?

Apakah fitur overcommitment resource dinamis dari protokol legacy ack-slo-manager akan didukung setelah upgrade ke ack-koordinator?

Ya. ack-koordinator kompatibel dengan protokol lama. Protokol lama menggunakan dua komponen dalam spesifikasi Pod:

• Anotasi alibabacloud.com/qosClass

• Resource alibabacloud.com/reclaimed dalam request dan limit

ack-koordinator mengenali protokol lama dan baru serta menghitung request dan ketersediaan resource secara seragam untuk keduanya. Upgrade add-on Anda tanpa perlu segera memperbarui konfigurasi Pod yang sudah ada.

Dukungan untuk protokol lama berakhir pada 30 Juli 2023. Perbarui parameter resource ke versi terbaru sesegera mungkin.

Tabel berikut menunjukkan dukungan protokol berdasarkan versi penjadwal dan ack-koordinator:

Apakah fitur CPU Burst dari protokol legacy ack-slo-manager akan didukung setelah upgrade ke ack-koordinator?

Ya. Protokol lama memerlukan anotasi alibabacloud.com/cpuBurst pada Pod. ack-koordinator sepenuhnya kompatibel dengan anotasi ini dan menangani upgrade secara mulus.

Dukungan untuk protokol lama berakhir pada 30 Juli 2023. Segera perbarui ke protokol terkini.

Apakah fitur CPU QoS dari protokol legacy ack-slo-manager akan didukung setelah upgrade ke ack-koordinator?

Ya. Protokol lama (versi 0.8.0 dan sebelumnya) mengaktifkan CPU QoS dengan menambahkan anotasi alibabacloud.com/qosClass pada Pod. ack-koordinator tetap kompatibel dan mendukung migrasi bertahap ke protokol koordinator.sh.

Kompatibilitas mundur berakhir pada 30 Juli 2023. Segera migrasikan Pod Anda ke protokol baru.

Apakah fitur QoS memori kontainer akan didukung setelah upgrade dari protokol legacy ack-slo-manager ke ack-koordinator?

Ya. Protokol lama (versi 0.8.0 dan sebelumnya) menggunakan anotasi alibabacloud.com/qosClass dan alibabacloud.com/memoryQOS. ack-koordinator kompatibel mundur dengan keduanya.

Kompatibilitas mundur berakhir pada 30 Juli 2023. Segera migrasikan ke protokol terkini.

Pemanfaatan Node telah mencapai ambang batas, tetapi Pod tidak diusir. Apa yang harus saya lakukan?

Mengapa descheduler sering restart?

Hal ini biasanya menandakan bahwa ConfigMap descheduler tidak ditemukan atau memiliki kesalahan format. Periksa isi ConfigMap dan perbaiki masalah yang ada. Untuk informasi selengkapnya, lihat Parameter konfigurasi lanjutan. Setelah memperbaiki ConfigMap, restart descheduler.

Bagaimana cara menggunakan penjadwalan yang memperhatikan beban dan descheduling hotspot secara bersamaan?

Aktifkan kedua fitur tersebut dan selaraskan ambang batasnya. Ketika beban Node melebihi nilai highThresholds descheduler, Pod diusir dari Node tersebut. Tetapkan parameter loadAwareThreshold dalam penjadwalan yang memperhatikan beban ke nilai yang sama dengan highThresholds. Hal ini mencegah Pod yang diusir dijadwalkan kembali segera ke Node yang sama yang kelebihan beban—terutama penting dalam kluster dengan jumlah Node kecil yang memiliki tingkat pemanfaatan serupa.

Lihat Gunakan penjadwalan yang memperhatikan beban dan Deskripsi kebijakan.

Algoritma pemanfaatan apa yang digunakan descheduler?

Descheduler merata-ratakan pemanfaatan sumber daya dalam jendela bergulir dan hanya memicu descheduling ketika rata-rata tersebut tetap berada di atas ambang batas selama periode berkelanjutan (default: sekitar 10 menit). Untuk memori, perhitungan mengecualikan page cache karena sistem operasi dapat mereklaimnya. Sebaliknya, kubectl top node menyertakan page cache dalam angka memorinya. Untuk melihat garis dasar memori aktual yang digunakan Descheduler, gunakan Alibaba Cloud Prometheus.

Saat uji stres dengan wrk, hasilnya menunjukkan "Socket errors: connect 54,". Apa yang harus saya lakukan?

Error ini berarti klien wrk telah kehabisan koneksi TCP yang tersedia. Perbaiki dengan mengaktifkan reuse koneksi TCP pada mesin uji stres.

1. Periksa apakah reuse koneksi TCP diaktifkan:

   sudo sysctl -n net.ipv4.tcp_tw_reuse

   Output 0 atau 2 berarti reuse koneksi TCP tidak sepenuhnya diaktifkan.

2. Aktifkan reuse koneksi TCP:

   sudo sysctl -w net.ipv4.tcp_tw_reuse=1

3. Jalankan kembali uji wrk. Pesan Socket errors: connect 54, ... seharusnya tidak muncul lagi.

Perintah-perintah ini hanya dijalankan pada mesin uji stres—tidak diperlukan perubahan pada mesin target. Setelah pengujian, kembalikan pengaturan aslinya dengan sysctl -w net.ipv4.tcp_tw_reuse=<original_value>.

Mengapa tidak ada data yang ditampilkan di bagian manfaat colocation kluster pada tab k8s-reclaimed-resource?

1. Verifikasi bahwa ack-koordinator telah diinstal:

   1. Masuk ke Konsol ACK. Di panel navigasi kiri, klik Clusters.

   2. Klik nama kluster. Di panel navigasi kiri, pilih Applications > Helm.

   3. Di halaman Helm, periksa apakah ack-coordinator terdaftar. Jika belum, instal terlebih dahulu. Lihat Instal dan kelola add-on.

2. Periksa apakah dasbor colocation menampilkan data: Jika tidak, verifikasi bahwa metrik kube_node_labels sedang dikumpulkan:

   1. Masuk ke Konsol ARMS.

   2. Di panel navigasi kiri, pilih Managed Service for Prometheus > Instances.

   3. Pilih wilayah, klik nama instans Prometheus, lalu klik Metric Management.

   4. Klik tombol Metrics, cari kube_node_labels, dan verifikasi bahwa metrik tersebut memiliki data.

Apakah saya dapat menggunakan spot instans berbasis Arm?

Ya. Lihat Gunakan spot instans.

Apa saja keterbatasan penggunaan Node berbasis Arm di kluster ACK?

Di halaman Add-ons, hanya kategori add-on berikut yang mendukung arsitektur Arm:

• Komponen inti

• Pencatatan log dan pemantauan

• Penyimpanan

• Jaringan

Add-on dari pasar tidak mendukung arsitektur Arm.