Container Service for Kubernetes:Aktifkan overcommitment sumber daya dinamis

Kelas QoS dan sumber daya Batch

Kubernetes menetapkan kelas quality of service (QoS) untuk setiap pod berdasarkan konfigurasi sumber dayanya. Sumber daya Batch dirancang khusus untuk kelas BestEffort:

Untuk menggunakan overcommitment sumber daya dinamis, atur koordinator.sh/qosClass: "BE" pada pod dan ganti bidang sumber daya standar dengan kubernetes.io/batch-cpu dan kubernetes.io/batch-memory.

Langkah 1: Buat ConfigMap

Buat file bernama configmap.yaml dengan konten berikut:

apiVersion: v1
kind: ConfigMap
metadata:
  name: ack-slo-config
  namespace: kube-system
data:
  # colocation-config mengontrol perhitungan dan pembaruan sumber daya Batch dinamis.
  # Fitur terkait: Dynamic resource overcommitment, load-aware scheduling.
  colocation-config: |
    {
      "enable": true,                        # Wajib: mengaktifkan pembaruan sumber daya Batch. Mengatur ke false akan mereset sumber daya reclaimed ke 0.
      "metricAggregateDurationSeconds": 60,  # Frekuensi agregasi metrik node (dalam detik). Gunakan nilai default.
      "cpuReclaimThresholdPercent": 60,      # Ambang batas reklaim untuk batch-cpu, dalam % dari CPU yang dapat dialokasikan. Default: 65.
      "memoryReclaimThresholdPercent": 70,   # Ambang batas reklaim untuk batch-memory, dalam % dari memori yang dapat dialokasikan. Default: 65.
      "memoryCalculatePolicy": "usage"       # Cara kapasitas batch-memory dihitung: "usage" (default) atau "request".
    }

Nilai cpuReclaimThresholdPercent dan memoryReclaimThresholdPercent dalam contoh ini (60 dan 70) hanya sebagai sampel. Nilai default aktualnya adalah 65 untuk kedua parameter tersebut.

Tabel berikut menjelaskan setiap parameter secara detail:

Hitung kapasitas sumber daya Batch

ack-koordinator menerapkan rumus berikut untuk menghitung jumlah sumber daya Batch yang tersedia di setiap node.

Perhitungan berbasis penggunaan (default, memoryCalculatePolicy: "usage"):

nodeBatchAllocatable = nodeAllocatable × thresholdPercent − podUsage(non-BE) − systemUsage

Perhitungan berbasis permintaan (memoryCalculatePolicy: "request", hanya berlaku untuk batch-memory):

nodeBatchAllocatable = nodeAllocatable × thresholdPercent − podRequest(non-BE) − systemUsage

Di mana:

Langkah 2: Terapkan ConfigMap

Periksa apakah ConfigMap ack-slo-config sudah ada di namespace kube-system:

• Jika sudah ada, gunakan kubectl patch untuk menggabungkan perubahan Anda tanpa menimpa pengaturan lain:

  kubectl patch cm -n kube-system ack-slo-config --patch "$(cat configmap.yaml)"

• Jika tidak ada, buatlah:

  kubectl apply -f configmap.yaml

Langkah 1: Periksa sumber daya Batch yang tersedia di node

# Ganti $nodeName dengan nama node sebenarnya.
kubectl get node $nodeName -o yaml

Cari bagian status.allocatable dalam output:

status:
  allocatable:
    # Satuan: millicore. Contoh berikut menunjukkan 50 core tersedia.
    kubernetes.io/batch-cpu: 50000
    # Satuan: byte. Contoh berikut menunjukkan 50 GB tersedia.
    kubernetes.io/batch-memory: 53687091200

Langkah 2: Konfigurasikan pod untuk menggunakan sumber daya Batch

Tambahkan label koordinator.sh/qosClass: "BE" ke metadata pod dan atur kubernetes.io/batch-cpu dan kubernetes.io/batch-memory di bidang resources kontainer:

metadata:
  labels:
    # Wajib: mengatur kelas QoS pod menjadi BestEffort.
    koordinator.sh/qosClass: "BE"
spec:
  containers:
  - resources:
      requests:
        # Satuan: millicore. "1k" = 1000 millicore = 1 core.
        kubernetes.io/batch-cpu: "1k"
        # Satuan: byte.
        kubernetes.io/batch-memory: "1Gi"
      limits:
        kubernetes.io/batch-cpu: "1k"
        kubernetes.io/batch-memory: "1Gi"

Setelah upgrade dari ack-slo-manager ke ack-koordinator, apakah konfigurasi overcommitment lama masih berfungsi?

Ya. ack-koordinator kompatibel mundur dengan protokol ack-slo-manager sebelumnya. Penjadwal kluster ACK Pro dapat menghitung sumber daya yang diminta dan tersedia menggunakan format protokol lama dan baru secara simultan, sehingga Anda dapat melakukan upgrade tanpa mengonfigurasi ulang workload yang ada.

Protokol sebelumnya menggunakan:

• Anotasi pod alibabacloud.com/qosClass

• Bidang alibabacloud.com/reclaimed untuk permintaan dan batas sumber daya

ack-koordinator mendukung protokol ini hingga versi bertanggal tidak lebih baru dari 30 Juli 2023. Migrasikan workload yang ada ke protokol koordinator.sh kapan pun memungkinkan.

Tabel berikut menunjukkan kompatibilitas lintas versi komponen:

Mengapa penggunaan memori melonjak tepat setelah pod dimulai?

Gejala: Penggunaan memori melonjak segera setelah kontainer dimulai, melebihi batas kubernetes.io/batch-memory yang diharapkan.

Penyebab: Saat kontainer dibuat, ack-koordinator mengatur batas memori cgroup berdasarkan kubernetes.io/batch-memory. Beberapa aplikasi membaca batas cgroup saat startup untuk menentukan berapa banyak memori yang akan dialokasikan secara internal. Jika aplikasi membaca cgroup sebelum ack-koordinator menulis batas tersebut, aplikasi mungkin mengalokasikan lebih banyak memori daripada yang dimaksudkan. Sistem operasi tidak segera mereklaim memori tersebut, sehingga penggunaan tetap tinggi hingga akhirnya turun di bawah batas yang dikonfigurasi.

Periksa: Jalankan perintah berikut di dalam kontainer untuk memastikan batas memori telah diatur dengan benar:

# Satuan: byte
cat /sys/fs/cgroup/memory/memory.limit_in_bytes
# Contoh output yang diharapkan
1048576000

Perbaikan: Konfigurasikan batas memori aplikasi dalam skrip startup sebelum proses utama dimulai. Hal ini memastikan batas sudah diterapkan sebelum aplikasi membaca cgroup.

Mengapa pod BestEffort tetap dalam status Pending?

Gejala: Pod yang dikonfigurasi dengan sumber daya Batch tetap dalam status Pending dan tidak dapat dijadwalkan.

Periksa: Jalankan kubectl describe pod <pod-name> dan cari event kegagalan penjadwalan.

Penyebab umum dan solusi: