Praktik terbaik penskalaan untuk Cloud Service Mesh di GKE

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

Untuk memahami batasan skalabilitas, lihat Batas skalabilitas Cloud Service Mesh

Skalabilitas Cloud Service Mesh di GKE bergantung pada pengoperasian yang efisien dari dua komponen utamanya, bidang data dan bidang kontrol. 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 melihat error dalam log Cloud Service Mesh atau metrik bidang kontrol yang menunjukkan masalah konektivitas, kehabisan resource, atau pembatasan API.

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

Gejala masalah penskalaan bidang data

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

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

Dampak terlokalisasi: 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 Penskalaan Otomatis Pod Horizontal (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. Frekuensi polling default adalah 15 detik dan Anda dapat mempertimbangkan untuk menetapkannya lebih rendah jika mengharapkan 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 pod dapat di-deploy.

  • Gunakan EXIT_ON_ZERO_ACTIVE_CONNECTIONS untuk menghindari koneksi yang terputus selama penurunan skala.

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 resource batas untuk file bantuan 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.

Mencakup dependensi layanan

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

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

Pohon grafik traffic aplikasi contoh Butik Online dengan banyak daun

Banyak layanan ini merupakan leaf dalam grafik, dan oleh karena itu, tidak perlu memiliki informasi keluar untuk layanan lain di mesh. Anda dapat menerapkan resource Sidecar yang membatasi cakupan konfigurasi file bantuan 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 Contoh aplikasi Butik Online untuk mengetahui detail tentang cara men-deploy contoh aplikasi ini.

Manfaat lain dari cakupan file bantuan adalah mengurangi kueri DNS yang tidak perlu. Mencakup dependensi layanan memastikan bahwa file bantuan Envoy hanya membuat kueri DNS untuk layanan yang akan berkomunikasi dengannya, bukan setiap cluster di mesh layanan.

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

Untuk membatasi cakupan konfigurasi untuk semua workload dalam satu namespace, buat satu resource Sidecar di namespace tersebut. Hal ini menginstruksikan semua proxy Envoy dalam namespace tersebut untuk hanya menerima konfigurasi untuk layanan di namespace-nya sendiri.

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: sidecar
  namespace: my-app
spec:
  egress:
  -   hosts:
    -   "my-app/*"

Anda dapat menerapkan perilaku default untuk setiap namespace di mesh dengan menerapkan satu resource Sidecar ke namespace root, biasanya istio-system.

Sidecar berikut membatasi traffic keluar dari setiap file bantuan di mesh ke layanan yang berada dalam namespace-nya sendiri.

apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: sidear
  namespace: istio-system
spec:
  egress:
  -   hosts:
    -   "./*"

Perhatikan bahwa Cloud Service Mesh memberlakukan batas pada jumlah total resource Sidecar yang dapat dibuat dalam satu mesh. Karena batasan ini, membuat Sidecar tingkat namespace adalah praktik yang direkomendasikan.

Memantau dan menyempurnakan

Setelah menetapkan batas resource awal, Anda harus memantau proxy Envoy untuk memastikan performanya 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 konsumsi resource-nya dalam kondisi traffic normal dan puncak. Berikut hal yang perlu diperhatikan:

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

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

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

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

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

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

Menskalakan bidang kontrol

Bagian ini menjelaskan setelan yang akan disesuaikan untuk menskalakan bidang kontrol.

Pemilih penemuan

Pemilih penemuan adalah kolom di MeshConfig yang memungkinkan Anda menentukan kumpulan namespace yang dipertimbangkan bidang kontrol saat menghitung update konfigurasi untuk file bantuan.

Secara default, Cloud Service Mesh memantau semua namespace di cluster. Hal ini dapat menjadi bottleneck untuk cluster besar yang tidak perlu memantau semua resource.

Gunakan discoverySelectors untuk mengurangi beban komputasi pada bidang kontrol dengan membatasi jumlah resource Kubernetes (seperti layanan, pod, dan endpoint) yang dipantau dan diproses.

Saat menggunakan implementasi bidang kontrol TRAFFIC_DIRECTOR, Cloud Service Mesh hanya membuat Google Cloud resource, seperti Layanan Backend dan Grup Endpoint Jaringan, untuk resource Kubernetes di namespace yang ditentukan dalam discoverySelectors.

Untuk mengetahui informasi selengkapnya, lihat Pemilih penemuan dalam dokumentasi Istio.

Membangun ketahanan

Anda dapat menyesuaikan setelan berikut untuk membangun ketahanan ke dalam mesh layanan:

Deteksi outlier

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

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

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

Upaya coba lagi

Mengurangi error sementara dengan otomatis mencoba lagi permintaan yang gagal.

  • Konfigurasi Utama:
    • attempts: Jumlah upaya coba lagi.
    • perTryTimeout: Waktu tunggu per upaya coba lagi. Tetapkan waktu tunggu ini lebih singkat dari waktu tunggu keseluruhan. Waktu tunggu ini menentukan durasi waktu tunggu untuk setiap upaya coba lagi.
    • retryBudget: Upaya coba lagi serentak maksimum.
  • Manfaat: Tingkat keberhasilan permintaan yang lebih tinggi, dampak kegagalan intermiten yang lebih rendah.

Faktor yang Perlu Dipertimbangkan:

  • Idempotensi: Pastikan operasi yang dicoba lagi bersifat idempoten, yang berarti dapat diulang tanpa efek samping yang tidak diinginkan.
  • Upaya Coba Lagi Maksimum: Batasi jumlah upaya coba lagi (misalnya, maksimum 3 upaya coba lagi) untuk menghindari loop tak terbatas.
  • Pemutus Sirkuit: Integrasikan upaya coba lagi dengan pemutus sirkuit untuk mencegah upaya coba lagi saat layanan terus gagal.

Untuk mengetahui informasi selengkapnya, lihat Upaya Coba Lagi dalam dokumentasi Istio.

Waktu tunggu

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

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

Faktor yang Perlu Dipertimbangkan:

  • Latensi Jaringan: Perhitungkan waktu pulang pergi (RTT) yang diharapkan antara layanan. Sisakan beberapa buffer untuk penundaan 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, coba lagi, penggantian, pemutus sirkuit).

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

Memantau dan menyempurnakan

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

Telemetri

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

  • Metrik: Gunakan metrik komprehensif, khususnya, volume permintaan, latensi, dan tingkat error. Integrasikan 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: Konfigurasi logging akses untuk menangkap informasi mendetail tentang permintaan dan respons.

Bacaan Tambahan