Praktik terbaik penskalaan untuk Cloud Service Mesh di GKE

Panduan ini menjelaskan praktik terbaik untuk menyelesaikan masalah penskalaan untuk arsitektur Cloud Service Mesh terkelola di Google Kubernetes Engine. Sasaran utama rekomendasi ini adalah untuk memastikan performa, keandalan, dan penggunaan resource yang optimal untuk aplikasi microservice Anda seiring pertumbuhannya.

Skalabilitas Cloud Service Mesh di GKE bergantung pada operasi yang efisien dari dua komponen utamanya, yaitu data plane dan control plane. Dokumen ini terutama berfokus pada penskalaan bidang data.

Mengidentifikasi masalah penskalaan bidang kontrol versus bidang data

Di Cloud Service Mesh, masalah penskalaan dapat terjadi di bidang kontrol atau bidang data. Berikut cara mengidentifikasi jenis masalah penskalaan yang Anda hadapi:

Gejala masalah penskalaan bidang kontrol

Penemuan layanan lambat: Layanan atau endpoint baru memerlukan waktu lama untuk ditemukan dan tersedia.

Penundaan konfigurasi: Perubahan pada aturan pengelolaan traffic atau kebijakan keamanan memerlukan waktu lama untuk diterapkan.

Peningkatan latensi dalam operasi bidang kontrol: Operasi seperti membuat, memperbarui, atau menghapus resource Cloud Service Mesh menjadi lambat atau tidak responsif.

Error terkait Traffic Director: Anda mungkin mengamati error dalam log Cloud Service Mesh atau metrik plane kontrol yang menunjukkan masalah terkait konektivitas, kehabisan resource, atau throttling API.

Cakupan dampak: Masalah bidang kontrol biasanya memengaruhi seluruh mesh, sehingga menyebabkan penurunan performa yang luas.

Gejala masalah penskalaan bidang data

Peningkatan latensi dalam komunikasi layanan ke layanan: Permintaan ke layanan dalam mesh mengalami latensi atau waktu tunggu yang lebih tinggi, tetapi tidak ada peningkatan penggunaan CPU/memori dalam penampung layanan.

Penggunaan CPU atau memori yang tinggi di proxy Envoy: Penggunaan CPU atau memori yang tinggi dapat menunjukkan bahwa proxy kesulitan menangani beban traffic.

Dampak terlokalisir: Masalah bidang data biasanya memengaruhi layanan atau workload tertentu, bergantung pada pola traffic dan penggunaan resource proxy Envoy.

Menskalakan bidang data

Untuk menskalakan bidang data, coba teknik berikut:

Mengonfigurasi Penskalaan Otomatis Pod Horizontal (HPA) untuk workload

Gunakan Horizontal Pod Autoscaling (HPA) untuk menskalakan workload secara dinamis dengan pod tambahan berdasarkan penggunaan resource. Pertimbangkan hal berikut saat mengonfigurasi HPA:

  • Gunakan parameter --horizontal-pod-autoscaler-sync-period ke kube-controller-manager untuk menyesuaikan frekuensi polling pengontrol HPA. Rasio polling default adalah 15 detik dan Anda dapat mempertimbangkan untuk menetapkannya lebih rendah jika memperkirakan lonjakan traffic yang lebih cepat. Untuk mempelajari lebih lanjut kapan harus menggunakan HPA dengan GKE, lihat Penskalaan otomatis Pod horizontal.

  • Perilaku penskalaan default dapat menyebabkan sejumlah besar pod di-deploy (atau dihentikan) sekaligus, yang dapat menyebabkan lonjakan penggunaan resource. Pertimbangkan untuk menggunakan kebijakan penskalaan untuk membatasi kecepatan deployment pod.

  • Gunakan EXIT_ON_ZERO_ACTIVE_CONNECTIONS untuk menghindari koneksi yang terputus selama penskalaan ke bawah.

Untuk mengetahui detail selengkapnya tentang HPA, lihat Penskalaan Otomatis Pod Horizontal dalam dokumentasi Kubernetes.

Mengoptimalkan Konfigurasi Proxy Envoy

Untuk mengoptimalkan konfigurasi proxy Envoy, pertimbangkan rekomendasi berikut:

Batas resource

Anda dapat menentukan permintaan dan batas resource untuk sidecar Envoy dalam spesifikasi Pod. Hal ini mencegah pertentangan resource dan memastikan performa yang konsisten.

Anda juga dapat mengonfigurasi batas resource default untuk semua proxy Envoy di mesh menggunakan anotasi resource.

Batas resource yang optimal untuk proxy Envoy Anda bergantung pada faktor-faktor, seperti volume traffic, kompleksitas workload, dan resource node GKE. Terus pantau dan sesuaikan mesh layanan Anda untuk memastikan performa yang optimal.

Pertimbangan Penting:

  • Kualitas Layanan (QoS): Menetapkan permintaan dan batas memastikan proxy Envoy Anda memiliki kualitas layanan yang dapat diprediksi.

Cakupan dependensi layanan

Pertimbangkan untuk memangkas grafik dependensi mesh dengan mendeklarasikan semua dependensi melalui Sidecar API. Hal ini membatasi ukuran dan kompleksitas konfigurasi yang dikirim ke beban kerja tertentu, yang penting untuk mesh yang lebih besar.

Sebagai contoh, berikut adalah grafik traffic untuk aplikasi contoh butik online.

Hierarki grafik traffic aplikasi contoh Butik Online dengan banyak cabang

Banyak dari layanan ini adalah node daun dalam grafik, sehingga tidak perlu memiliki informasi keluar untuk layanan lain di mesh. Anda dapat menerapkan resource Sidecar yang membatasi cakupan konfigurasi sidecar untuk layanan leaf ini seperti yang ditunjukkan dalam contoh berikut.

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: leafservices
  namespace: default
spec:
  workloadSelector:
    labels:
      app: cartservice
      app: shippingservice
      app: productcatalogservice
      app: paymentservice
      app: emailservice
      app: currencyservice
  egress:
  -   hosts:
    -   "~/*"

Lihat Aplikasi contoh Butik Online untuk mengetahui detail tentang cara men-deploy aplikasi contoh ini.

Manfaat lain dari cakupan sidecar adalah mengurangi kueri DNS yang tidak perlu. Menentukan cakupan dependensi layanan memastikan bahwa sidecar Envoy hanya membuat kueri DNS untuk layanan yang benar-benar akan dikomunikasikan, bukan setiap cluster dalam mesh layanan.

Untuk deployment skala besar yang mengalami masalah dengan ukuran konfigurasi yang besar di sidecar, cakupan dependensi layanan sangat direkomendasikan untuk skalabilitas mesh.

Memantau dan menyesuaikan

Setelah menetapkan batas resource awal, Anda harus memantau proxy Envoy untuk memastikannya berperforma optimal. Gunakan dasbor GKE untuk memantau penggunaan CPU dan memori serta menyesuaikan batas resource sesuai kebutuhan.

Untuk menentukan apakah proxy Envoy memerlukan peningkatan batas resource, pantau penggunaan resource-nya dalam kondisi traffic normal dan puncak. Berikut yang harus dicari:

  • Penggunaan CPU Tinggi: Jika penggunaan CPU Envoy secara konsisten mendekati atau melebihi batasnya, Envoy mungkin kesulitan memproses permintaan, sehingga menyebabkan peningkatan latensi atau permintaan yang terputus. Pertimbangkan untuk meningkatkan batas CPU.

    Dalam hal ini, Anda mungkin cenderung melakukan penskalaan menggunakan penskalaan horizontal, tetapi jika proxy sidecar secara konsisten tidak dapat memproses permintaan secepat penampung aplikasi, menyesuaikan batas CPU dapat menghasilkan hasil terbaik.

  • Penggunaan Memori Tinggi: Jika penggunaan memori Envoy mendekati atau melebihi batasnya, Envoy dapat mulai kehilangan koneksi atau mengalami error kehabisan memori (OOM). Tingkatkan batas memori untuk mencegah masalah ini.

  • Log Error: Periksa log Envoy untuk menemukan error yang terkait dengan kehabisan resource, seperti error upstream connect error atau disconnect or reset before headers atau error too many open files. Error ini dapat menunjukkan bahwa proxy memerlukan lebih banyak resource. Lihat dokumen pemecahan masalah penskalaan untuk mengetahui error lain yang terkait dengan masalah penskalaan.

  • Metrik Performa: Memantau metrik performa utama seperti latensi permintaan, rasio error, dan throughput. Jika Anda melihat penurunan performa yang berkorelasi dengan penggunaan resource yang tinggi, Anda mungkin perlu meningkatkan batas.

Dengan menetapkan dan memantau batas resource untuk proxy bidang data secara aktif, Anda dapat memastikan bahwa service mesh Anda diskalakan secara efisien di GKE.

Membangun ketahanan

Anda dapat menyesuaikan setelan berikut untuk menskalakan panel kontrol:

Deteksi outlier

Deteksi pencilan memantau host di layanan upstream dan menghapusnya dari kumpulan load balancing setelah mencapai beberapa nilai minimum error.

  • Konfigurasi Kunci:
    • outlierDetection: Setelan yang mengontrol penghapusan host yang tidak responsif dari kumpulan load balancing.
  • Manfaat: Mempertahankan kumpulan host yang sehat di kumpulan load balancing.

Untuk mengetahui informasi selengkapnya, lihat Deteksi Pengecualian dalam dokumentasi Istio.

Upaya coba lagi

Mitigasi error sementara dengan mencoba ulang permintaan yang gagal secara otomatis.

  • Konfigurasi Kunci:
    • attempts: Jumlah upaya percobaan ulang.
    • perTryTimeout: Waktu tunggu per upaya percobaan ulang. Tetapkan waktu tunggu ini lebih singkat dari waktu tunggu keseluruhan Anda. Ini menentukan berapa lama Anda akan menunggu setiap upaya percobaan ulang.
    • retryBudget: Percobaan ulang serentak maksimum.
  • Manfaat: Rasio keberhasilan yang lebih tinggi untuk permintaan, mengurangi dampak kegagalan intermiten.

Faktor yang Perlu Dipertimbangkan:

  • Idempoten: Pastikan operasi yang dicoba ulang bersifat idempoten, yang berarti operasi tersebut dapat diulang tanpa efek samping yang tidak diinginkan.
  • Percobaan Ulang Maksimum: Batasi jumlah percobaan ulang (misalnya, maksimal 3 percobaan ulang) untuk menghindari loop tanpa henti.
  • Circuit Breaking: Mengintegrasikan percobaan ulang dengan pemutus sirkuit untuk mencegah percobaan ulang saat layanan terus gagal.

Untuk informasi selengkapnya, lihat Percobaan ulang dalam dokumentasi Istio.

Waktu tunggu

Gunakan waktu tunggu untuk menentukan waktu maksimum yang diizinkan untuk pemrosesan permintaan.

  • Konfigurasi Kunci:
    • timeout: Waktu tunggu permintaan habis untuk layanan tertentu.
    • idleTimeout: Waktu koneksi dapat tetap tidak ada aktivitas sebelum ditutup.
  • Manfaat: Peningkatan responsivitas sistem, pencegahan kebocoran resource, hardening terhadap traffic berbahaya.

Faktor yang Perlu Dipertimbangkan:

  • Latensi Jaringan: Perhitungkan waktu bolak-balik (RTT) yang diharapkan antara layanan. Biarkan beberapa buffer untuk keterlambatan yang tidak terduga.
  • Grafik Dependensi Layanan: Untuk permintaan berantai, pastikan waktu tunggu layanan panggilan lebih singkat daripada waktu tunggu kumulatif dependensinya untuk menghindari kegagalan beruntun.
  • Jenis Operasi: Tugas yang berjalan lama mungkin memerlukan waktu tunggu yang jauh lebih lama daripada pengambilan data.
  • Penanganan Error: Waktu tunggu harus memicu logika penanganan error yang sesuai (misalnya, percobaan ulang, penggantian, pemutusan sirkuit).

Untuk mengetahui informasi selengkapnya, lihat Waktu tunggu dalam dokumentasi Istio.

Memantau dan menyesuaikan

Pertimbangkan untuk memulai dengan setelan default untuk waktu tunggu, deteksi outlier, dan percobaan ulang, lalu secara bertahap menyesuaikannya berdasarkan persyaratan layanan spesifik dan pola traffic yang diamati. Misalnya, lihat data dunia nyata tentang berapa lama layanan Anda biasanya merespons. Kemudian, sesuaikan waktu tunggu agar sesuai dengan karakteristik spesifik dari setiap layanan atau endpoint.

Telemetri

Gunakan telemetri untuk terus memantau mesh layanan dan menyesuaikan konfigurasinya untuk mengoptimalkan performa dan keandalan.

  • Metrik: Gunakan metrik yang komprehensif, khususnya, volume permintaan, latensi, dan tingkat error. Berintegrasi dengan Cloud Monitoring untuk visualisasi dan pemberitahuan.
  • Pelacakan Terdistribusi: Aktifkan integrasi pelacakan terdistribusi dengan Cloud Trace untuk mendapatkan insight mendalam tentang alur permintaan di seluruh layanan Anda.
  • Logging: Konfigurasikan logging akses untuk mengambil informasi mendetail tentang permintaan dan respons.

Bacaan Tambahan