Container Service for Kubernetes：FAQ Penjadwalan

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

Cara memigrasikanack-descheduler ke Koordinator Descheduler?

Komponen ack-descheduler tidak lagi dipelihara. Untuk informasi lebih lanjut, lihat Pengumuman Komponen: Migrasi Komponen ack-descheduler. Kami menyarankan Anda bermigrasi ke komponen Koordinator Descheduler, yang aktif dipelihara. Proses migrasi mirip dengan migrasi Kubernetes Descheduler ke Koordinator Descheduler. Untuk informasi lebih lanjut, lihat Migrasi Kubernetes Descheduler ke Koordinator Descheduler.

Container Service for Kubernetes (ACK) menyediakan komponen ack-descheduler di pasar. Komponen ini berbasis pada Kubernetes Descheduler open source. Versi 0.20.0 dan 0.27.1 dari ack-descheduler tersedia. Keduanya menyediakan fitur yang sama dan digunakan dengan cara yang sama seperti versi Kubernetes Descheduler open source yang sesuai.

Apa kebijakan penjadwalan default dari ACK Scheduler?

Dalam kluster ACK, kebijakan penjadwalan default dari ACK Scheduler konsisten dengan penjadwal Kubernetes komunitas. Saat penjadwal Kubernetes memutuskan cara menjadwalkan pod ke node, prosesnya biasanya melibatkan dua langkah utama: Filter dan Score.

• Filter: Menyaring node tempat pod dapat dijadwalkan. Jika daftar hasil filter kosong, pod tidak dapat dijadwalkan.

• Score: Setelah penyaringan, penjadwal memberi skor dan mengurutkan node yang dapat dijadwalkan untuk memilih node paling sesuai bagi pod tersebut.

Untuk informasi lebih lanjut tentang plug-in Filter dan Score yang diaktifkan dalam versi terbaru ACK Scheduler, lihat Pengantar plug-in Filter dan Score.

Bagaimana cara menghindari node dengan pemanfaatan sumber daya tinggi selama penjadwalan pod?

Dalam kebijakan penjadwalan Kubernetes asli, penjadwal membuat keputusan berdasarkan permintaan sumber daya node, bukan pemanfaatan sumber daya aktualnya. Selain itu, berbagai plug-in Filter dan Score memengaruhi hasil penjadwalan. Anda dapat menggunakan fitur berikut yang disediakan oleh kluster ACK untuk mencegah pod dijadwalkan ke node dengan pemanfaatan sumber daya tinggi.

• Konfigurasikan permintaan dan batas sumber daya yang sesuai untuk setiap pod serta rencanakan redundansi sumber daya. Anda dapat menggunakan fitur profiling sumber daya untuk mendapatkan rekomendasi spesifikasi kontainer berdasarkan data historis penggunaan sumber daya. Untuk informasi lebih lanjut, lihat Profiling sumber daya.

• Aktifkan fitur penjadwalan pod berbasis beban. Fitur penjadwalan pod berbasis beban dari komponen kube-scheduler yang disediakan oleh ACK didasarkan pada framework penjadwalan Kubernetes. Berbeda dengan kebijakan penjadwalan Kubernetes asli, ACK Scheduler dapat merasakan pemanfaatan sumber daya aktual node. Fitur ini menganalisis data beban historis node, memperkirakan kebutuhan sumber daya untuk pod baru, lalu menjadwalkan pod tersebut secara preferensial ke node dengan beban lebih rendah untuk mencapai keseimbangan beban. Untuk informasi lebih lanjut, lihat Penjadwalan berbasis beban.

• Aktifkan descheduling hot spot berbasis beban. Pemanfaatan node berubah secara dinamis seiring waktu karena variasi lingkungan kluster, lalu lintas beban kerja, atau permintaan. Hal ini dapat mengganggu keseimbangan beban di antara node dalam kluster. Untuk mengatasi hal ini, ACK Scheduler menyediakan kemampuan descheduling untuk mencegah ketidakseimbangan beban ekstrem. Untuk informasi lebih lanjut, lihat Menggunakan descheduling hot spot berbasis beban.

Node baru ditambahkan ke kluster. Mengapa pod tidak dijadwalkan ke node tersebut?

Masalah ini dapat terjadi karena beberapa alasan. Anda dapat melakukan pemecahan masalah sebagai berikut.

1. Periksa apakah status node normal. Jika node berada dalam keadaan `NotReady`, node tersebut tidak dapat menerima pod.

2. Periksa apakah pod memiliki kebijakan penjadwalan, seperti `NodeSelector`, `NodeAffinity`, atau `PodAffinity`, atau memiliki taint yang mencegahnya dijadwalkan ke node baru tersebut.

3. Evaluasi apakah masalah ini terkait dengan kebijakan penjadwalan Kubernetes asli. Dalam kebijakan penjadwalan Kubernetes asli, penjadwal membuat keputusan berdasarkan permintaan sumber daya node, bukan pemanfaatan sumber daya aktualnya. Hal ini dapat menyebabkan beberapa node menjalankan banyak pod sementara yang lain menjalankan sedikit atau tidak ada pod sama sekali.

   Untuk informasi lebih lanjut tentang solusi masalah ini, lihat Bagaimana cara menghindari node dengan pemanfaatan sumber daya tinggi selama penjadwalan pod?

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

Dalam kebijakan penjadwalan Kubernetes asli, penjadwal membuat keputusan berdasarkan permintaan sumber daya node, bukan pemanfaatan sumber daya aktualnya. Oleh karena itu, meskipun pemanfaatan CPU aktual kluster tidak tinggi, penjadwalan pod dapat gagal karena CPU atau memori tidak mencukupi.

Untuk informasi lebih lanjut tentang solusi masalah ini, lihat Bagaimana cara menghindari node dengan pemanfaatan sumber daya tinggi selama penjadwalan pod?

Apa yang perlu saya ketahui saat menggunakan fitur descheduling di ACK? Apakah fitur ini akan me-restart pod?

ACK menyediakan fitur descheduling melalui Koordinator Descheduler. Saat menggunakan fitur descheduling, perhatikan hal-hal berikut.

• Koordinator Descheduler hanya bertanggung jawab untuk mengevakuasi pod yang sedang berjalan, bukan untuk membuat ulang atau menjadwalkannya kembali. Pembuatan ulang pod setelah evakuasi ditangani oleh controller beban kerja yang sesuai, seperti Deployment atau StatefulSet. Penjadwalan ulang pod yang dibuat ulang ditangani oleh penjadwal.

• Saat descheduling, pod lama dievakuasi sebelum pod baru dibuat. Pastikan aplikasi Anda memiliki jumlah replika yang cukup (replicas) untuk menghindari dampak pada ketersediaan aplikasi selama evakuasi.

Untuk informasi lebih lanjut, lihat Descheduling.

Bagaimana cara menjadwalkan aplikasi ke node tertentu?

Anda dapat menambahkan label ke node lalu menambahkan nodeSelector yang sesuai ke file YAML aplikasi Anda untuk menjadwalkan aplikasi ke node tertentu. Untuk informasi lebih lanjut, lihat Jadwalkan aplikasi ke node tertentu.

Dalam deployment, bagaimana cara menjadwalkan jumlah pod tertentu ke ECS dan jumlah tertentu ke ECI?

Dalam skenario di mana sumber daya ECS dan ECI digunakan bersama, Anda dapat menggunakan UnitedDeployment untuk mendefinisikan subset guna mengelola beban kerja. Misalnya, dalam file YAML UnitedDeployment, Anda dapat mengatur replicas menjadi 10 di subset-ecs dan replicas menjadi 10 di subset-eci. Untuk informasi lebih lanjut, lihat Skalakan beban kerja berdasarkan UnitedDeployment.

Bagaimana cara memastikan ketersediaan tinggi untuk pod beban kerja selama penjadwalan?

Anda dapat menggunakan afinitas pod untuk mendistribusikan pod beban kerja di zona atau node yang berbeda. Misalnya, Anda dapat menambahkan bidang berikut ke file YAML pod untuk mendeklarasikan aturan preferredDuringSchedulingIgnoredDuringExecution. Aturan ini berusaha menjadwalkan pod dengan label security=S2 ke zona yang berbeda. Jika kondisi ini tidak dapat dipenuhi, penjadwal akan berusaha menjadwalkan pod ke node lain.

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

Untuk informasi lebih lanjut, lihat podAffinity dan podAntiAffinity serta Pod Topology Spread Constraints dalam dokumentasi Kubernetes.

Untuk sejumlah pod yang baru dibuat, mengapa tidak semuanya dijadwalkan ke node dengan beban terendah?

Jika penjadwal menjadwalkan sejumlah pod yang baru dibuat ke node dengan beban terendah saat ini, node tersebut mungkin dengan cepat menjadi hot spot karena pod baru akan meningkatkan beban node setelah mulai berjalan.

Oleh karena itu, saat plug-in penjadwalan berbasis beban menghitung skor node, skor tersebut disesuaikan jika sebuah node memiliki pod baru yang pemanfaatannya belum dilaporkan. Hal ini mencegah penjadwalan berlebihan dan pembentukan hot spot baru.

Selain tingkat beban node, faktor apa lagi yang memengaruhi hasil penjadwalan?

Penjadwal Kubernetes terdiri dari banyak plug-in. Selama penjadwalan, banyak plug-in berpartisipasi dalam memberi skor dan mengurutkan node, seperti plug-in afinitas dan plug-in penyebaran topologi. Peringkat akhir node dipengaruhi oleh semua plug-in ini. Anda dapat menyesuaikan bobot skor setiap plug-in sesuai kebutuhan.

Setelah penjadwal ditingkatkan ke versi baru, apakah fitur penjadwalan berbasis beban yang menggunakan protokol lama masih didukung?

Untuk menggunakan versi lama fitur penjadwalan berbasis beban, Anda harus menambahkan anotasi alibabacloud.com/loadAwareScheduleEnabled: "true" ke pod.

Tabel berikut menjelaskan dukungan protokol dan persyaratan versi komponen.

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

Masalah ini dapat terjadi karena beberapa alasan. Rujuk solusi berikut untuk melakukan penyesuaian.

• Format konfigurasi salah, sehingga kebijakan CPU Burst tidak berlaku. Untuk informasi lebih lanjut, lihat Konfigurasi parameter lanjutan untuk memodifikasi dan memverifikasi konfigurasi.

• Jika pemanfaatan CPU mencapai batas atas yang ditentukan oleh cfsQuotaBurstPercent, throttling CPU tetap terjadi karena sumber daya CPU tidak mencukupi.

  Sesuaikan nilai request dan limit berdasarkan kebutuhan aktual aplikasi Anda.

• Kebijakan CPU Burst menyesuaikan dua parameter cgroup untuk pod: cpu.cfs_quota_us dan cpu.cfs_burst_us. Untuk informasi lebih lanjut, lihat Konfigurasi Parameter Lanjutan. Parameter cpu.cfs_quota_us hanya diatur setelah ack-koordinator mendeteksi throttling CPU, yang menyebabkan latensi ringan. Sebaliknya, parameter cpu.cfs_burst_us diatur langsung berdasarkan konfigurasi dan lebih responsif.

  Untuk performa yang lebih baik, gunakan fitur ini dengan sistem operasi Alibaba Cloud Linux.

• Kebijakan CPU Burst mencakup mekanisme perlindungan untuk menyesuaikan cpu.cfs_quota_us, yang menggunakan parameter sharePoolThresholdPercent untuk menentukan ambang batas keamanan mesin. Jika pemanfaatan mesin secara keseluruhan menjadi terlalu tinggi, cpu.cfs_quota_us diatur ulang ke nilai awalnya untuk mencegah satu pod menyebabkan gangguan berlebihan.

  Anda harus mengatur ambang batas keamanan node berdasarkan kebutuhan aplikasi Anda untuk mencegah pemanfaatan node yang tinggi memengaruhi performa aplikasi.

Apakah Alibaba Cloud Linux diperlukan untuk mengaktifkan kebijakan CPU Burst?

Kebijakan CPU Burst ack-koordinator kompatibel dengan semua kernel open source Alibaba Cloud Linux dan CentOS. Namun, kami menyarankan Anda menggunakan Alibaba Cloud Linux. Dengan memanfaatkan fitur kernel Alibaba Cloud Linux, ack-koordinator dapat menyediakan mekanisme manajemen elastisitas CPU yang lebih detail halus. Untuk informasi lebih lanjut, lihat Aktifkan fitur CPU Burst pada antarmuka cgroup v1.

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

Untuk aplikasi yang dikonfigurasi dengan batas memori Batch (kubernetes.io/batch-memory), ack-koordinator mengatur batas memori cgroup kontainer setelah kontainer dibuat. Beberapa aplikasi meminta memori berdasarkan batas cgroup saat startup. Jika aplikasi dimulai sebelum ack-koordinator mengonfigurasi batas cgroup, penggunaan memori aktualnya mungkin melebihi batas memori Batch yang dimaksudkan. Sistem operasi tidak segera mengurangi penggunaan memori proses tersebut. Akibatnya, batas memori cgroup tidak dapat diterapkan hingga penggunaan aktual turun di bawah batas memori Batch.

Dalam kasus ini, Anda dapat menyesuaikan parameter konfigurasi aplikasi untuk mengontrol penggunaan memorinya agar tetap di bawah batas Batch. Atau, Anda dapat memeriksa parameter batas memori dalam skrip startup aplikasi dan memastikannya diatur sebelum aplikasi dimulai. Hal ini membantu memastikan bahwa penggunaan memori aplikasi dibatasi secara wajar dan mencegah masalah seperti error kehabisan memori (OOM).

Anda dapat menjalankan perintah berikut di dalam kontainer untuk melihat parameter batas sumber daya memori.

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

Setelah jumlah core CPU ditingkatkan, mengapa performa menurun dan pod mengalami masalah CPU throttling?

Apakah fitur overselling sumber daya dinamis dari protokol legacy ack-slo-manager akan didukung setelah upgrade ke komponen ack-koordinator?

Versi lama protokol overcommitment sumber daya dinamis mencakup dua bagian:

• Anotasi alibabacloud.com/qosClass di pod.

• Sumber daya alibabacloud.com/reclaimed di request dan limit pod.

ack-koordinator kompatibel dengan protokol lama di atas dan secara seragam menghitung request sumber daya dan sumber daya yang tersedia untuk protokol lama maupun baru di penjadwal kluster ACK Pro managed cluster. Anda dapat melakukan upgrade komponen ke ack-koordinator secara mulus.

Penjadwal di Kluster ACK Pro yang dikelola dan ack-koordinator mendukung versi protokol yang berbeda sebagai berikut.

Jika fitur CPU Burst digunakan dengan protokol lama ack-slo-manager, apakah fitur ini masih didukung setelah upgrade ke ack-koordinator?

Versi sebelumnya dari protokol Pod mengharuskan Anda menentukan alibabacloud.com/cpuBurst di Annotation. ack-koordinator sepenuhnya kompatibel dengan versi sebelumnya ini, memungkinkan Anda melakukan upgrade komponen ke versi baru secara mulus.

Kompatibilitas ack-koordinator dengan versi protokol yang berbeda adalah sebagai berikut.

Saya menggunakan fitur CPU QoS dengan protokol lama ack-slo-manager. Apakah fitur ini masih didukung setelah saya upgrade ke ack-koordinator?

Dalam protokol pod lama (versi 0.8.0 dan sebelumnya), CPU QoS diaktifkan dengan menambahkan anotasi alibabacloud.com/qosClass ke pod.

ack-koordinator tetap kompatibel dengan protokol lama. Anda dapat melakukan upgrade komponen ke ack-koordinator secara mulus dan secara bertahap beralih Pod Anda ke protokol koordinator.sh. ack-koordinator akan tetap kompatibel dengan protokol lama ini hingga 30 Juli 2023. Kami menyarankan Anda segera mengupgrade field sumber daya protokol asli ke versi baru.

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

Protokol pod lama (versi 0.8.0 dan sebelumnya) mencakup:

• Anotasi alibabacloud.com/qosClass di pod.

• Anotasi alibabacloud.com/memoryQOS di pod.

ack-koordinator kompatibel dengan versi protokol sebelumnya, memungkinkan Anda melakukan upgrade komponen ke ack-koordinator secara mulus. Kompatibilitas mundur didukung hingga 30 Juli 2023. Kami menyarankan Anda segera mengupgrade field sumber daya protokol asli ke versi baru.

ack-koordinator mendukung fitur QoS memori di berbagai versi sebagai berikut.

Pemanfaatan node telah mencapai ambang batas, tetapi pod di node tersebut tidak dievakuasi. Apa yang harus saya lakukan?

Masalah ini dapat terjadi karena beberapa alasan. Rujuk solusi berikut untuk melakukan penyesuaian.

Mengapa descheduler sering restart?

Hal ini dapat terjadi jika format ConfigMap descheduler salah atau ConfigMap tidak ada. Periksa konten dan format file ConfigMap dan lakukan koreksi yang diperlukan. Untuk informasi lebih lanjut, lihat Parameter konfigurasi lanjutan. Setelah memodifikasi ConfigMap, Anda harus me-restart descheduler. Untuk informasi lebih lanjut tentang cara me-restart descheduler, lihat Langkah 2: Aktifkan plug-in descheduling untuk mendistribusikan pod di node dengan pemanfaatan sumber daya tinggi.

Bagaimana cara menggunakan penjadwalan berbasis beban dan descheduling hot spot secara bersamaan?

Setelah Anda mengaktifkan descheduling untuk node dengan pemanfaatan sumber daya tinggi, pod di node tersebut dievakuasi. Penjadwal kemudian menjadwalkan pod baru, yang dibuat oleh controller induk seperti Deployment, ke node yang sesuai berdasarkan konfigurasinya. Untuk mencapai keseimbangan beban yang lebih baik, Anda juga harus mengaktifkan penjadwalan berbasis beban untuk penjadwal. Untuk informasi lebih lanjut, lihat Gunakan penjadwalan berbasis beban.

Saat mengonfigurasi fitur-fitur ini, atur parameter loadAwareThreshold untuk fungsi penyaringan node dalam penjadwalan berbasis beban ke nilai yang sama dengan parameter highThresholds di descheduler. Untuk informasi lebih lanjut, lihat Deskripsi kebijakan. Saat beban node melebihi highThresholds, descheduler mengevakuasi pod dari node tersebut. Penjadwal kemudian menggunakan loadAwareThreshold untuk mencegah pod baru dijadwalkan kembali ke node tersebut. Jika tidak, pod yang dievakuasi mungkin dijadwalkan ulang ke node asalnya, terutama jika pod memiliki ruang lingkup penjadwalan node yang ditentukan dengan jumlah node kecil yang memiliki tingkat pemanfaatan serupa.

Apa algoritma pemanfaatan yang digunakan untuk descheduling?

Descheduler terus memantau pemanfaatan sumber daya selama periode tertentu dan menghitung nilai rata-rata. Descheduling hanya dipicu jika nilai rata-rata tetap di atas ambang batas selama durasi tertentu. Durasi default sekitar 10 menit. Untuk sumber daya memori, perhitungan penggunaan memori descheduler mengecualikan page cache karena memori ini dapat ditarik kembali oleh sistem operasi. Namun, nilai pemanfaatan yang dikembalikan oleh kubectl top node mencakup page cache. Anda dapat menggunakan Pemantauan dengan Prometheus Alibaba Cloud untuk melihat penggunaan memori aktual.

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

Problem Description

Selama uji stres dengan wrk, hasilnya menunjukkan Socket errors: connect 54,. Klien wrk gagal membuat koneksi dengan server Nginx, dan hasil pengujian tidak valid.

Cause

Error ini biasanya terjadi karena jumlah koneksi yang tersedia di klien terbatas, yang menyebabkan upaya koneksi gagal.

Solution

Untuk mengatasi error ini, periksa konfigurasi koneksi TCP di mesin uji stres dan aktifkan reuse koneksi TCP.

1. Login ke mesin uji stres dan jalankan perintah berikut untuk memeriksa apakah reuse koneksi TCP diaktifkan.

   sudo sysctl -n net.ipv4.tcp_tw_reuse

   Output 0 atau 2 menunjukkan bahwa sistem belum sepenuhnya mengaktifkan reuse koneksi TCP.

2. Jalankan perintah berikut untuk mengaktifkan reuse koneksi TCP.

   sudo sysctl -w net.ipv4.tcp_tw_reuse=1

3. Gunakan alat wrk untuk mengirim permintaan uji stres lagi.

   Verifikasi bahwa hasil pengujian tidak lagi mencakup pesan error Socket errors: connect 54, ..., yang menunjukkan bahwa hasilnya valid.

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

1. Periksa apakah komponen ack-koordinator diinstal.

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

   2. Di halaman Clusters, temukan kluster yang Anda inginkan dan klik namanya. Di panel sebelah kiri, pilih Applications > Helm.

   3. Di halaman Helm, periksa apakah komponen ack-koordinator ada.

      • Jika tidak ada, lihat Instalasi dan pengelolaan komponen, instal komponen ack-koordinator, lalu ikuti langkah-langkah di bawah.

      • Jika ada, lanjutkan ke langkah berikutnya.

2. Periksa apakah dasbor colocation beban kerja multi-tipe menampilkan data yang relevan.

   Jika tidak, lakukan langkah-langkah berikut:

   1. Login ke Konsol ARMS.

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

   3. Di pojok kiri atas halaman, pilih wilayah tujuan, klik nama instans Prometheus, lalu klik Metrics Management di panel navigasi sebelah kiri.

   4. Klik tombol biru Metrics, cari dan pilih kube_node_labels seperti yang diminta, lalu lihat detail data metrik tersebut.

Dapatkah saya menggunakan instans spot berbasis Arm?

Ya, instans spot berbasis Arm tersedia. Untuk informasi lebih lanjut tentang cara menggunakannya, lihat Gunakan instans spot.

Apa saja batasan penggunaan node berbasis Arm dalam kluster ACK?