Menguasai Autoscaling Kapasiti Awan: Operasi Kubernetes yang Efisien Kos

Pengenalan

Pemindahan ke awan sering membawa janji keanjalan—bayar hanya untuk apa yang anda gunakan. Namun, banyak organisasi mendapati bil awan mereka melonjak selepas berpindah ke Kubernetes. Mengapa? Kerana autoscaling tidak dikonfigurasi dengan betul, atau tidak sejajar dengan tadbir urus kos. Artikel ini membincangkan senario sebenar autoscaling kapasiti awan, dari gejala hingga penyelesaian, menggunakan alat asli Kubernetes dan integrasi penyedia awan.

Senario

Anda menjalankan platform e-dagang besar di AWS menggunakan Amazon EKS. Semasa pemindahan baru-baru ini dari mesin maya, anda mengaktifkan Horizontal Pod Autoscaler (HPA) dan Cluster Autoscaler Kubernetes. Trafik meningkat semasa jualan kilat, tetapi juga mempunyai tempoh tenang. Selepas dua bulan, bil awan anda 40% lebih tinggi daripada infrastruktur statik sebelumnya, walaupun purata penggunaan CPU dalam kluster berada di bawah 15%. Anda mengesyaki peruntukan berlebihan dan keputusan skala yang tidak cekap.

Gejala

1. Perbelanjaan awan tinggi: Bil AWS bulanan menunjukkan kos EC2 yang tinggi, terutamanya untuk instance yang sering terbiar.
2. Penggunaan sumber rendah: kubectl top nodes menunjukkan kebanyakan nod di bawah 20% penggunaan CPU dan memori sepanjang masa.
3. Gegaran skala: Cluster Autoscaler kerap menambah dan mengeluarkan nod, menyebabkan pengebilan EC2 setiap jam menjadi sia-sia.
4. Tindak balas perlahan terhadap beban: Semasa lonjakan trafik kecil, HPA menunggu terlalu lama untuk menskala pod, menyebabkan lonjakan latensi.
5. Gangguan instance Spot: Jika anda menggunakan instance Spot, penggantian kerap mengganggu kerja kelompok.

Diagnosis

Mula dengan memeriksa persediaan autoscaling semasa:

# Semak penggunaan sumber nod
kubectl top nodes

# Senarai semua konfigurasi HPA
kubectl get hpa --all-namespaces

# Dapatkan butiran HPA tertentu
kubectl describe hpa -n <namespace> <hpa-name>

# Semak status Cluster Autoscaler (jika digunakan sebagai pod)
kubectl get pods -n kube-system -l app=cluster-autoscaler
kubectl logs -n kube-system deployment/cluster-autoscaler --tail=50

Dalam senario ini, kita menemui perkara berikut:

• HPA ditetapkan untuk skala berdasarkan CPU pada sasaran 70%, tetapi penggunaan CPU aplikasi adalah berkedip dan tidak berkorelasi dengan beban sebenar (cth., pemprosesan kelompok).
• HPA mempunyai minReplicas 10 dan maxReplicas 50, tetapi walaupun pada minimum, kapasiti kluster keseluruhan sangat besar, menyebabkan purata penggunaan rendah.
• Cluster Autoscaler dikonfigurasi untuk berkembang dari 3 hingga 20 nod, tetapi menggunakan scale-down-utilization-threshold 0.5 (50%), bermakna ia tidak akan mengurangkan nod sehingga penggunaan di bawah 50% untuk tempoh yang berterusan. Ini menghalang pengurangan yang tepat pada masanya.

Juga, semak metrik CloudWatch untuk mengaitkan peristiwa skala dengan kos:

# Dapatkan senarai instance EC2 dalam kluster EKS (menggunakan AWS CLI)
aws ec2 describe-instances --filters "Name=tag:eks:cluster-name,Values=<cluster-name>" --query "Reservations[*].Instances[*].{ID:InstanceId,Type:InstanceType,LaunchTime:LaunchTime}" --output table

Semak sejarah skala dalam kumpulan Auto Scaling AWS:

aws autoscaling describe-scaling-activities --auto-scaling-group-name <asg-name> --max-items 10

Ini akan menunjukkan sama ada nod ditambah dan dikeluarkan terlalu kerap.

Arahan dan Penyelesaian

Berdasarkan diagnosis, kami melaksanakan pembaikan berlapis.

1. Saiz Tepat HPA Anda

Beralih daripada hanya CPU kepada metrik tersuai atau luaran yang selaras dengan beban perniagaan. Untuk aplikasi e-dagang, pertimbangkan untuk menskala berdasarkan permintaan sesaat (RPS) atau panjang giliran. Gunakan Kubernetes Metrics Server dan Prometheus Adapter.

Contoh: Pasang Prometheus Adapter dan tentukan HPA berdasarkan RPS:

# Andaikan anda mempunyai metrik luaran untuk RPS daripada ingress controller anda
kubectl create hpa my-app --from=custom-metric:nginx_ingress_controller_requests_per_second --target=1000 --min=5 --max=20

Atau edit HPA sedia ada:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app
spec:
  minReplicas: 5
  maxReplicas: 20
  metrics:
  - type: External
    external:
      metric:
        name: nginx_ingress_controller_requests_per_second
      target:
        type: AverageValue
        averageValue: "1000"

2. Tala Cluster Autoscaler

Kemas kini deployment Cluster Autoscaler untuk membolehkan skala turun yang lebih pantas dan menghormati belanjawan gangguan pod.

Di AWS, jika anda menggunakan CA pada EKS, edit deployment:

kubectl edit deployment/cluster-autoscaler -n kube-system

Parameter utama:

• --scale-down-utilization-threshold=0.35 – Skala turun nod hanya jika penggunaan di bawah 35%.
• --scale-down-delay-after-add=10m – Tunggu 10 minit selepas nod ditambah sebelum mempertimbangkan untuk dialih keluar.
• --max-nodes-total=50 – Lindungi daripada pengembangan di luar kawalan.

3. Laksanakan Vertical Pod Autoscaler (VPA) untuk Pelarasan Awal

Sebelum anda mempunyai autoscaling yang stabil berdasarkan beban, gunakan VPA dalam mod cadangan untuk menetapkan saiz permintaan dan had pod dengan betul. Ini mengurangkan pembaziran dan meningkatkan pembungkusan bin.

kubectl apply -f - <<EOF
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-app-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: my-app
  updatePolicy:
    updateMode: "Auto"
  recommenders:
  - name: VPAReccomender
EOF

4. Gunakan Instance Spot untuk Beban Kerja Tanpa Keadaan

Untuk penjimatan kos, konfigurasikan kumpulan nod berasingan dengan Instance Spot. Gunakan nodeSelectors dan taints untuk menjadualkan beban kerja tanpa keadaan di sana. Pastikan autoscaler kluster anda boleh mempelbagaikan jenis instance.

5. Tetapkan Amaran Belanjawan

Gunakan AWS Budgets untuk memantau perbelanjaan. Buat belanjawan dengan ambang amaran pada 80% daripada jumlah yang dijangkakan.

Kawalan Risiko

• Belanjawan Gangguan Pod (PDB): Pastikan skala turun tidak mengganggu perkhidmatan kritikal. Tentukan PDB untuk beban kerja anda.
• Gerbang Ketersediaan: Tangguhkan pemadaman pod sehingga pod bersedia menerima trafik.
• Penutupan Anggun: Laksanakan cangkuk preStop untuk mengendalikan saliran.
• Penggulungan Berperingkat: Uji perubahan autoscaling dalam persekitaran pementasan dahulu.
• Had CPU dan Memori: Tetapkan had sumber untuk mengelakkan kontena daripada menghabiskan semua sumber nod.

Rollback

Jika konfigurasi baharu menyebabkan isu, anda boleh kembali ke keadaan sebelumnya dengan cepat.

• Untuk perubahan HPA, gunakan kubectl apply -f dengan fail YAML sebelumnya, atau edit semula di tempat.
• Untuk Cluster Autoscaler, kembalikan bendera deployment.
• Untuk VPA, keluarkan objek VPA dan kemas kini deployment kepada permintaan/had sebelumnya.

Pastikan anda menyimpan sandaran manifest di Git.

Pengesahan

Selepas melaksanakan perubahan, pantau selama seminggu:

• Periksa sama ada kos awan telah menurun. Gunakan AWS Cost Explorer untuk membandingkan sebelum/selepas.
• Sahkan penggunaan kluster: kubectl top nodes sepatutnya menunjukkan purata penggunaan yang lebih tinggi (40-60%).
• Lihat peristiwa HPA dan log Cluster Autoscaler untuk memastikan tiada gegaran.
• Sahkan bahawa latensi aplikasi dan kadar ralat kekal stabil.

Arahan:

kubectl get hpa --all-namespaces
kubectl get vpa --all-namespaces
kubectl logs -n kube-system deployment/cluster-autoscaler --tail=50
aws cloudwatch get-metric-statistics --namespace AWS/EC2 --metric-name CPUUtilization --dimensions Name=InstanceId,Value=<instance-id> --start-time <date> --end-time <date> --period 86400 --statistics Average

Bila untuk Hantar Tiket OpsGlobal

Salah konfigurasi autoscaling boleh menelan belanja ribuan ringgit setiap bulan. Jika anda menghadapi mana-mana yang berikut, sudah tiba masanya untuk melibatkan pakar SRE OpsGlobal:

• Autoscaling kompleks dengan pelbagai beban kerja dan perkhidmatan yang saling bergantung.
• Integrasi metrik tersuai (Prometheus, CloudWatch, Datadog) dan dasar autoscaling.
• Tadbir urus kos dan penyelarasan FinOps merentas pelbagai akaun awan.
• Pemantauan 24/7 dan tindak balas insiden proaktif untuk kegagalan berkaitan skala.
• Anda memerlukan pandangan kedua pada kluster pengeluaran anda.

OpsGlobal boleh mengaudit persediaan semasa anda, melaksanakan amalan terbaik, dan memantau infrastruktur anda supaya anda boleh fokus pada membina produk.

Kesimpulan

Autoscaling bukan operasi "tetapkan dan lupakan". Ia memerlukan penalaan berterusan dan penyelarasan dengan operasi kos. Dengan mensaizkan HPA dengan tepat, menala autoscaler kluster, menggunakan VPA, dan melaksanakan amaran belanjawan, anda boleh mencapai keanjalan dan kecekapan kos. Ingat untuk sentiasa mempunyai pelan rollback dan libatkan pakar apabila kerumitan melebihi kapasiti pasukan anda.