Menguruskan Autoscaling Kapasiti Awan: Buku Panduan Kos-Ops untuk Beban Kerja yang Dimigrasikan

Scenario:

Pasukan anda baru-baru ini memindahkan persekitaran Kubernetes pengeluaran ke perkhidmatan awan terurus. Anda mengaktifkan autoscaling pada hari pertama: Horizontal Pod Autoscaler (HPA) untuk beban kerja aplikasi, Cluster Autoscaler (CA) untuk menambah nod, dan mungkin Vertical Pod Autoscaler (VPA) untuk penyelarasan saiz. Tiga bulan kemudian, CFO bertanya mengapa bil awan melonjak 40%, dan jurutera on-call anda dipanggil pada 3 pagi kerana pesanan tamat masa. Ini adalah perangkap pemindahan autoscaling klasik: sama ada anda lebihan peruntukan untuk mengelakkan gangguan, atau pengurangan skala anda terjejas oleh ambang konservatif.

Symptoms:

Gejala tipikal termasuk: penggunaan nod yang berterusan di bawah 20%, peristiwa Pod 'CPU Tidak Mencukupi' secara berkala, gangguan nod spot yang berlarutan, metrik HPA yang tidak pernah menumpu, dan anomali kos yang mengikuti lonjakan trafik tetapi tidak pernah kembali ke garis dasar.

Diagnosis:

Mulakan dengan memeriksa pandangan cluster autoscaler. kubectl get configmap -n kube-system cluster-autoscaler-status -o yaml menunjukkan sasaran dan kiraan nod semasa. Untuk autoscaler terurus awan, dapatkan log: kubectl logs -n kube-system cluster-autoscaler-xxxxx | grep -E 'scale-down|expander'. Seterusnya, semak sasaran HPA: kubectl get hpa -A. Jika HPA menunjukkan metrik 'Tidak Diketahui', pelayan metrik atau API tersuai tidak sihat. Kemudian, analisis tekanan nod dengan kubectl top nodes. Nod di atas 90% CPU mungkin menyebabkan pendikit, tetapi nod di bawah 10% mencadangkan pengurangan skala tidak dicetuskan. Akhir sekali, petakan kos kepada beban kerja: anotasikan pod dengan app dan department, kemudian gunakan penyemak kos pembekal awan atau alat seperti Kubecost untuk melihat punca.

Commands:

Berikut ialah urutan diagnostik yang boleh diulang:

# List all nodes and their resource requests/limits
kubectl describe nodes | grep -E 'Name:|cpu:|memory:' | head -60

# Check HPA status and events
kubectl get hpa -A -o custom-columns='NAME:.metadata.name,NAMESPACE:.metadata.namespace,REFERENCE:.spec.scaleTargetRef.name,TARGET:.status.targetAverage,ACTUAL:.status.currentAverage,MIN/MAX:.spec.minReplicas/.spec.maxReplicas'

# Check cluster autoscaler status
kubectl get configmap cluster-autoscaler-status -n kube-system -o jsonpath='{.data.status}'

# Inspect pending pods
kubectl get pods -o wide | grep Pending

# Verify cluster autoscaler is not throttled
kubectl logs -n kube-system $(kubectl get pods -n kube-system -l app=cluster-autoscaler -o jsonpath='{.items[0].metadata.name}') | tail -50

Jika anda menggunakan EKS, gunakan eksctl get nodegroup; GKE, gcloud container clusters describe; AKS, az aks show. Ini mendedahkan keutamaan scalingConfig dan autoscale.

Risk Controls:

Autoscaling sangat berkuasa tetapi berbahaya tanpa kawalan. Tetapkan perkara berikut:

• Had CPU/memori pada setiap pod untuk mengelakkan gangguan jiran.
• Saiz maksimum Cluster Autoscaler: contohnya, spec dalam kumpulan nod terurus anda, biasanya ditandakan dalam API pembekal.
• Belanjawan Gangguan Pod (PDB) untuk melindungi perkhidmatan kritikal semasa pengusiran: kubectl create pdb critical-pdb --selector=app=critical --min-available=2.
• Gunakan VPA dalam mod 'Cadangan' sebelum menerapkan melalui kubectl apply -f vpa-offer.yaml.
• Untuk contoh spot, gunakan pelbagai jenis contoh dalam kumpulan nod dan topologySpreadConstraints untuk terus berfungsi semasa gangguan.
• Tetapkan amaran belanjawan: aws budgets atau gcloud budgets untuk memberi amaran pada 80% dan 100% daripada ramalan.

Rollback:

Setiap keputusan penskalaan harus boleh diterbalikkan. Simpan manifes HPA/VPA/CA dalam Git. Untuk rollback, kubectl apply -f previous-version.yaml untuk HPA. Jika anda perlu melumpuhkan HPA buat sementara waktu, kubectl delete hpa your-hpa. Untuk Cluster Autoscaler, untuk menghentikan tingkah laku pengurangan skala tanpa mengeluarkan autoscaler, tetapkan anotasi cluster-autoscaler.kubernetes.io/scale-down-disabled=true pada nod tertentu, atau tukar bendera baris arahan --scale-down-enabled=false jika anda menguruskan penggunaan. Dalam persekitaran awan terurus, gunakan konsol awan untuk mengemas kini saiz min/maks kumpulan nod. Jangan sekali-kali memadam nod secara langsung; biarkan autoscaler menguruskannya. Sentiasa uji rollback dalam persekitaran pementasan dahulu.

Verification:

Selepas sebarang perubahan, sahkan metrik berikut:

• Pendikit CPU: kubectl top pods dan bandingkan dengan ambang.
• Penggunaan nod: sepatutnya 30-70% (sasaran 50%).
• Kos: semak sisihan anomali kos harian, bukan sahaja agregat.
• Peristiwa autoscaler: kubectl get events --sort-by=.lastTimestamp | grep autoscaler.
• Penumpuan HPA: kubectl describe hpa menunjukkan kiraan replika yang stabil.

Juga, jalankan ujian beban dengan hey atau k6 untuk mengesahkan autoscaler bertindak dengan sesuai.

When to Submit an OpsGlobal Ticket:

Jika pasukan anda menghabiskan lebih daripada seminggu menala kawalan ini dan masih melihat penskalaan tidak stabil, atau jika anda berhijrah ke persekitaran berbilang kluster dan berbilang awan, sudah tiba masanya untuk menghubungi OpsGlobal. Kami mengendalikan dasar autoscaling lanjutan, HPA metrik tersuai, pengesanan anomali kos dengan ML, dan kami menyediakan pemerhatian 24/7 semasa tingkap migrasi utama. Hantar tiket melalui portal kami dan kami akan memeriksa akaun awan anda (dengan kelulusan anda) untuk membina model kos-per-permintaan dan menyelaraskan semua perkara.