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 dapat melihat alamat IP yang tersedia pada suatu Node. Pod yang dijadwalkan ke Node dengan sumber daya IP habis akan gagal saat startup, sering kali menghasilkan banyak Pod abnormal.

ACK Scheduler mengatasi hal ini dengan penjadwalan berbasis kesadaran IP (IP-aware scheduling). Fitur ini membaca anotasi k8s.aliyun.com/max-available-ip pada setiap Node untuk membatasi jumlah Pod yang memerlukan IP independen. Ketika sumber daya IP pada suatu Node habis, ACK Scheduler menetapkan kondisi SufficientIP pada status Node tersebut, sehingga mencegah penjadwalan Pod baru yang bergantung pada IP ke Node tersebut.

Add-on kube-scheduler mengaktifkan fitur ini secara otomatis. Kluster Anda harus memenuhi persyaratan berikut:

• Kluster merupakan kluster ACK yang dikelola Edisi Pro dengan Terway v1.5.7 atau 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 dengan penjadwal Kubernetes komunitas. Penjadwalan melibatkan dua langkah:

• Filter: Mengeliminasi Node tempat Pod tidak dapat berjalan. Jika tidak ada Node yang lolos filter, Pod tetap tidak dapat dijadwalkan.

• Score: Memberi peringkat Node yang tersisa dan memilih Node terbaik untuk Pod tersebut.

Semua plug-in Filter dan Score yang diaktifkan dalam ACK Scheduler terbaru tercantum di kube-scheduler.

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

Penjadwal Kubernetes native menggunakan permintaan resource (resource requests), bukan pemanfaatan aktual. Hal ini dapat menyebabkan beberapa Node kelebihan beban sementara yang lain menganggur. ACK menyediakan tiga pendekatan:

• Tetapkan permintaan dan batas resource yang akurat. Gunakan profil resource untuk rekomendasi spesifikasi kontainer berdasarkan penggunaan historis.

• Aktifkan penjadwalan berbasis beban (load-aware scheduling). ACK Scheduler mempertimbangkan beban aktual Node, menganalisis data historis, memperkirakan kebutuhan Pod yang masuk, dan menempatkan Pod pada Node dengan pemanfaatan lebih rendah. Lihat Penjadwalan berbasis beban.

• Aktifkan descheduling hotspot berbasis beban. Seiring perubahan trafik dan workload, beberapa Node menjadi kelebihan beban. Descheduler ACK mendeteksi hotspot dan mengusir (evict) Pod untuk mengembalikan keseimbangan. Lihat Menggunakan descheduling hotspot berbasis beban.

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

Periksa hal berikut secara berurutan:

1. Status Node: Penjadwal melewati Node dengan status NotReady. Tunggu hingga Node menjadi Ready.

2. Batasan penjadwalan pada Pod: Periksa aturan nodeSelector, nodeAffinity, atau podAffinity pada Pod, atau taint pada Node yang tidak ditoleransi oleh Pod tersebut.

3. Ketidakseimbangan permintaan resource: Penjadwal menggunakan permintaan resource, bukan pemanfaatan aktual. Jika Node yang sudah ada memiliki kapasitas permintaan bebas yang cukup, Node baru mungkin tetap tidak digunakan. Lihat Bagaimana cara menghindari penjadwalan Pod ke Node dengan pemanfaatan resource tinggi?.

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

Penjadwal mengevaluasi resource yang diminta, bukan konsumsi aktual. Node dengan penggunaan CPU rendah dapat tampak "penuh" jika Pod-nya memiliki permintaan resource tinggi. Penjadwalan gagal ketika tidak ada satu pun Node yang memiliki kapasitas permintaan cukup untuk Pod baru, meskipun pemanfaatan kluster secara keseluruhan rendah.

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

Apa yang perlu saya ketahui sebelum menggunakan descheduling di ACK? Apakah fitur ini merestart 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. Kontroler workload (Deployment, StatefulSet, dan sebagainya) yang menangani pembuatan ulang, dan penjadwal menempatkan Pod baru tersebut.

• Pertahankan jumlah replika yang cukup. Pod lama diusir sebelum Pod baru dimulai. Pastikan workload Anda memiliki jumlah replicas yang cukup agar tetap tersedia selama proses pengusiran.

Lihat Descheduling.

Bagaimana cara menjadwalkan aplikasi ke Node tertentu?

Tambahkan label ke Node target dan nodeSelector yang sesuai ke 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 ECS dan ECI. Misalnya, tetapkan replicas: 10 pada subset ECS dan replicas: 10 pada subset ECI. Lihat Skalakan workload berdasarkan UnitedDeployment.

Bagaimana cara memastikan ketersediaan tinggi untuk Pod workload selama penjadwalan?

Gunakan podAntiAffinity untuk menyebarkan Pod ke berbagai zona atau Node. Misalnya, konfigurasi berikut menjadwalkan Pod dengan label security=S2 ke zona yang berbeda. Jika batasan tidak dapat dipenuhi, penjadwal akan menggunakan Node lain sebagai fallback.

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

Dokumentasi Kubernetes juga mencakup Pod affinity dan anti-affinity serta batasan penyebaran topologi Pod.

Bagaimana cara migrasi ack-descheduler ke Koordinator Descheduler?

Add-on ack-descheduler telah ditinggalkan. Migrasikan ke Koordinator Descheduler menggunakan langkah-langkah yang sama seperti untuk Kubernetes Descheduler. Lihat Migrasi Kubernetes Descheduler ke Koordinator Descheduler dan \[Pemberitahuan\] migrasi ack-descheduler.

Add-on ack-descheduler di pasar ACK didasarkan pada Kubernetes Descheduler open source. Versi 0.20.0 dan 0.27.1 sesuai dengan versi open source-nya masing-masing.

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

Menempatkan semua Pod baru pada Node dengan beban terendah akan menciptakan hotspot. Plug-in penjadwalan berbasis beban menyesuaikan skor Node ketika Node tersebut memiliki Pod yang baru dijadwalkan namun pemanfaatannya belum dilaporkan, sehingga mencegah konsentrasi berlebihan dan menyeimbangkan beban di seluruh Node.

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

Penjadwal Kubernetes menggunakan banyak plug-in—aturan affinity, batasan penyebaran topologi, dan lainnya—yang semuanya berkontribusi pada peringkat akhir Node. Sesuaikan bobot skor plug-in berdasarkan kebutuhan Anda.

Setelah meningkatkan penjadwal, apakah fitur penjadwalan berbasis beban yang menggunakan protokol lama masih didukung?

Protokol lama memerlukan anotasi alibabacloud.com/loadAwareScheduleEnabled: "true" pada Pod. ACK Scheduler kompatibel mundur, sehingga peningkatan tidak merusak Pod yang sudah ada. Setelah peningkatan, beralihlah ke kebijakan penjadwalan berbasis beban 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. Kebijakan CPU Burst yang dikonfigurasi secara salah tidak berpengaruh. Verifikasi formatnya. Lihat Konfigurasi parameter lanjutan.

• Penggunaan CPU mencapai batas maksimum. Jika penggunaan CPU aktual mencapai batas cfsQuotaBurstPercent, throttling tetap terjadi karena sumber daya CPU fisik tidak mencukupi. Sesuaikan nilai request dan limit agar sesuai dengan kebutuhan aktual.

• Latensi dalam penyesuaian cpu.cfs_quota_us. CPU Burst memodifikasi cpu.cfs_quota_us dan cpu.cfs_burst_us. Nilai cpu.cfs_quota_us hanya diperbarui setelah ack-koordinator mendeteksi throttling, sehingga menimbulkan keterlambatan. Nilai cpu.cfs_burst_us diatur segera. Untuk hasil terbaik, gunakan fitur ini bersama Alibaba Cloud Linux.

• Ambang batas keamanan node terpicu. CPU Burst mengembalikan cpu.cfs_quota_us ke garis dasar jika penggunaan node melebihi ambang batas sharePoolThresholdPercent. Sesuaikan ambang batas tersebut sesuai kebutuhan Anda.

Apakah Alibaba Cloud Linux wajib digunakan untuk kebijakan CPU Burst?

Tidak. CPU Burst berfungsi pada semua kernel Alibaba Cloud Linux dan CentOS. Alibaba Cloud Linux direkomendasikan karena ack-koordinator memanfaatkan fitur tingkat kernel untuk elastisitas CPU yang lebih granular. Lihat Aktifkan fitur CPU Burst pada antarmuka cgroup v1.

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

Untuk kontainer dengan batas memori Batch (kubernetes.io/batch-memory), ack-koordinator mengatur batas memori cgroup setelah startup kontainer. Jika aplikasi membaca batas cgroup saat startup—sebelum ack-koordinator menerapkannya—aplikasi tersebut mungkin mengalokasikan lebih banyak memori daripada yang dimaksudkan. Sistem operasi tidak segera mereklaim memori tersebut, sehingga batas tidak diberlakukan hingga penggunaan turun di bawah batas tersebut.

Untuk mengatasi hal ini, sesuaikan aplikasi agar tetap berada di bawah batas Batch, atau pastikan parameter batas memori telah ditetapkan sebelum aplikasi diinisialisasi.

Lihat batas memori saat ini (dalam byte) di dalam kontainer:

# Satuan dalam byte.
cat /sys/fs/cgroup/memory/memory.limit_in_bytes
# Output yang diharapkan.
1048576000

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

Apakah fitur dynamic resource overcommitment dari protokol legacy ack-slo-manager tetap didukung setelah melakukan upgrade ke ack-koordinator?

Iya. ack-koordinator kompatibel. Protokol lama menggunakan dua komponen dalam spesifikasi Pod:

• Anotasi alibabacloud.com/qosClass

• Resource alibabacloud.com/reclaimed dalam requests dan limits

ack-koordinator mengenali kedua protokol tersebut dan menghitung permintaan serta ketersediaan resource secara seragam. Lakukan upgrade add-on tanpa perlu segera memperbarui konfigurasi Pod yang sudah ada.

Dukungan terhadap protokol lama berakhir pada 30 Juli 2023. Segera perbarui parameter resource ke versi terbaru.

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

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

Iya. Protokol lama menggunakan anotasi alibabacloud.com/cpuBurst. ack-koordinator sepenuhnya kompatibel dan menangani upgrade secara mulus.

Dukungan terhadap protokol lama berakhir pada 30 Juli 2023. Segera beralih ke protokol saat ini.

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

Iya. Protokol lama (versi 0.8.0 dan sebelumnya) mengaktifkan CPU QoS melalui anotasi alibabacloud.com/qosClass. 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 container memory QoS tetap didukung setelah melakukan upgrade dari protokol legacy ack-slo-manager ke ack-koordinator?

Iya. 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 saat ini.

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

Mengapa descheduler sering restart?

Hal ini biasanya menandakan bahwa ConfigMap descheduler hilang atau salah konfigurasi. Perbaiki ConfigMap tersebut dan restart descheduler. Lihat Parameter konfigurasi lanjutan.

Bagaimana cara menggunakan load-aware scheduling dan hotspot descheduling secara bersamaan?

Aktifkan kedua fitur tersebut dan selaraskan ambang batasnya. Saat beban suatu Node melebihi highThresholds, Pod akan dievict. Atur loadAwareThreshold ke nilai yang sama dengan highThresholds untuk mencegah Pod yang dievict dijadwalkan ulang ke Node yang sama yang sedang kelebihan beban—terutama penting pada kluster dengan sedikit Node yang memiliki tingkat pemanfaatan serupa.

Lihat Gunakan load-aware scheduling dan Deskripsi kebijakan.

Algoritma pemanfaatan apa yang digunakan oleh descheduler?

Descheduler menghitung rata-rata pemanfaatan dalam jendela waktu bergulir dan hanya memicu tindakan ketika rata-rata tersebut melebihi ambang batas selama periode berkelanjutan (default: ~10 menit). Perhitungan memori tidak memasukkan page cache, karena sistem operasi dapat mereklamasi page cache tersebut. Sebaliknya, kubectl top node mencakup page cache. Untuk melihat garis dasar memori yang digunakan descheduler, gunakan Alibaba Cloud Prometheus.

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

Klien wrk kehabisan koneksi TCP. Aktifkan penggunaan ulang koneksi TCP pada mesin uji stres.

1. Periksa apakah penggunaan ulang koneksi TCP telah diaktifkan:

   sudo sysctl -n net.ipv4.tcp_tw_reuse

   Output 0 atau 2 menunjukkan bahwa penggunaan ulang TCP belum sepenuhnya diaktifkan.

2. Aktifkan penggunaan ulang koneksi TCP:

   sudo sysctl -w net.ipv4.tcp_tw_reuse=1

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

Perintah-perintah ini hanya berlaku untuk mesin uji stres. Setelah pengujian selesai, kembalikan pengaturan awal 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 tersebut. Di panel navigasi kiri, pilih Applications > Helm.

   3. Pada halaman Helm, periksa apakah ack-koordinator terdaftar. Jika tidak, instal add-on tersebut. Lihat Install and manage add-ons.

2. Jika dasbor colocation tidak menampilkan data, 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 Metrics, cari kube_node_labels, dan pastikan metrik tersebut memiliki data.

Apakah saya dapat menggunakan instans preemptible berbasis Arm?

Ya. Lihat Use spot instances.

Apa saja batasan penggunaan Node berbasis Arm dalam kluster ACK?

Pada 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.