Panduan untuk menjalankan gateway yang dihost sendiri di Kubernetes dalam produksi

  • Artikel

BERLAKU UNTUK: Pengembang | Premium

Untuk menjalankan gateway yang dihost sendiri dalam produksi, ada berbagai aspek yang perlu dipertimbangkan. Misalnya, harus disebarkan dengan cara yang sangat tersedia, menggunakan cadangan konfigurasi untuk menangani pemutusan sementara dan banyak lagi.

Artikel ini menyediakan panduan tentang cara menjalankan gateway yang dihost sendiri di Kubernetes untuk beban kerja produksi guna memastikan bahwa gateway tersebut akan berjalan dengan lancar dan andal.

Penting

Dukungan untuk gateway yang dihost sendiri Azure API Management versi 0 dan gambar kontainer versi 1 berakhir pada 1 Oktober 2023, bersama dengan Api Konfigurasi v1 yang sesuai. Gunakan panduan migrasi kami untuk menggunakan gateway yang dihost sendiri v2.0.0 atau yang lebih tinggi dengan Configuration API v2. Pelajari lebih lanjut dalam dokumentasi penghentian kami

Token akses

Tanpa token akses yang valid, gateway yang dihost sendiri tidak akan dapat mengakses dan mengunduh data konfigurasi dari titik akhir layanan API Management terkait. Token akses dapat berlaku selama maksimal 30 hari. Token akses harus diregenerasi, dan klaster yang dikonfigurasi dengan token segar, baik secara manual atau melalui otomatisasi sebelum kedaluwarsa.

Saat Anda mengotomatiskan refresh token, gunakan operasi API Management ini untuk menghasilkan token baru. Untuk informasi tentang pengelolaan rahasia Kubernetes, lihat situs web Kubernetes.

Tip

Anda juga dapat menyebarkan gateway yang dihost sendiri ke Kubernetes dan mengaktifkan autentikasi ke instans API Management dengan menggunakan ID Microsoft Entra.

Penskalaan otomatis

Meskipun kami memberikan panduan mengenai jumlah minimum replika untuk gateway yang dihost sendiri, kami sarankan Anda menggunakan penskalaan otomatis untuk gateway yang dihost sendiri untuk memenuhi permintaan lalu lintas Anda secara lebih proaktif.

Terdapat dua cara untuk menskalakan otomatis gateway yang dihost sendiri secara horizontal:

  • Penskalaan otomatis berdasarkan penggunaan sumber daya (CPU dan memori)
  • Penskalaan otomatis berdasarkan jumlah permintaan per detik

Hal ini dimungkinkan melalui fungsionalitas Kubernetes asli, atau menggunakan Penskalaan otomatis berbasis Peristiwa Kubernetes (KEDA). KEDA adalah proyek Inkubasi CNCF yang berusaha menyederhanakan penskalaan otomatis aplikasi.

Catatan

KEDA adalah teknologi sumber terbuka yang tidak didukung oleh dukungan Azure dan perlu dioperasikan oleh pelanggan.

Penskalaan otomatis berbasis sumber daya

Kubernetes memungkinkan Anda untuk menskalakan gateway yang dihost sendiri secara otomatis berdasarkan penggunaan sumber daya menggunakan Horizontal Pod Autoscaler. Ini memungkinkan Anda untuk menentukan ambang CPU dan memori, serta jumlah replika untuk peluasan atau penyempitan skala.

Alternatifnya adalah menggunakan Penskalaan Otomatis Berbasis Peristiwa Kubernetes (KEDA) yang memungkinkan Anda menskalakan beban kerja berdasarkan berbagai penskala, termasuk CPU dan memori.

Tip

Jika Anda sudah menggunakan KEDA untuk menskalakan beban kerja lainnya, kami sarankan untuk menggunakan KEDA sebagai penskala otomatis aplikasi terpadu. Jika tidak demikian, kami sangat menyarankan untuk mengandalkan fungsionalitas Kubernetes asli melalui Horizontal Pod Autoscaler.

Penskalaan otomatis berbasis lalu lintas

Kubernetes tidak menyediakan mekanisme out-of-the-box untuk penskalaan otomatis berbasis lalu lintas.

Penskalaan Otomatis Berbasis Peristiwa Kubernetes (KEDA) menyediakan beberapa cara yang dapat membantu penskalaan otomatis berbasis lalu lintas:

  • Anda dapat menskalakan berdasarkan metrik dari ingress Kubernetes jika tersedia di Prometheus atau Azure Monitor dengan menggunakan scaler out-of-the-box
  • Anda dapat menginstal add-on HTTP, yang tersedia dalam versi beta, dan menskalakan berdasarkan jumlah permintaan per detik.

Cadangan konfigurasi

Konfigurasikan volume penyimpanan lokal untuk kontainer gateway yang dihost sendiri, sehingga dapat bertahan pada salinan cadangan konfigurasi terbaru yang diunduh. Jika konektivitas mati, volume penyimpanan dapat menggunakan salinan cadangan saat dihidupkan ulang. Jalur pemasangan volume harus /apim/config dan harus dimiliki oleh ID grup 1001. Lihat contoh yang ada di GitHub. Untuk mempelajari tentang penyimpanan di Kubernetes, lihat situs web Kubernetes. Untuk mengubah kepemilikan jalur yang dipasang, lihat pengaturan securityContext.fsGroup di situs web Kubernetes.

Catatan

Untuk mempelajari tentang perilaku gateway yang dihost sendiri di hadapan pemadaman konektivitas Azure sementara, lihat Gambaran umum gateway yang dihost sendiri.

Tag gambar kontainer

File YAML yang disediakan di portal Microsoft Azure menggunakan tag terbaru. Tag ini selalu mereferensikan versi paling terbaru dari gambar kontainer gateway yang dihost sendiri.

Pertimbangkan untuk menggunakan tag versi tertentu dalam produksi untuk menghindari peningkatan yang tidak disengaja ke versi yang lebih baru.

Anda dapat mengunduh daftar lengkap tag yang tersedia.

Tip

Saat menginstal dengan Helm, pemberian tag citra dioptimalkan untuk Anda. Versi aplikasi bagan Helm menyematkan gateway ke versi tertentu dan tidak bergantung pada latest.

Pelajari selengkapnya cara menginstal gateway API Management yang dihost sendiri di Kubernetes dengan Helm.

Sumber daya kontainer

Secara default, file YAML yang disediakan di portal Microsoft Azure tidak menentukan permintaan sumber daya kontainer.

Tidak mungkin untuk secara andal memprediksi dan merekomendasikan jumlah CPU per kontainer dan sumber daya memori serta jumlah replika yang diperlukan untuk mendukung beban kerja tertentu. Banyak faktor yang sedang dimainkan, seperti:

  • Perangkat keras tertentu yang menjalankan klaster.
  • Kehadiran dan jenis virtualisasi.
  • Jumlah dan tingkat koneksi klien bersamaan.
  • Tingkat permintaan.
  • Jenis dan jumlah kebijakan yang dikonfigurasi.
  • Ukuran payload dan apakah payload buffered atau di-streaming.
  • Latensi layanan backend.

Kami merekomendasikan pengaturan permintaan sumber daya ke dua inti dan 2 GiB sebagai titik awal. Lakukan uji beban dan skala atas/keluar atau turun/masuk berdasarkan pada hasilnya.

Nama domain kustom dan sertifikat SSL

Jika Anda menggunakan nama domain kustom untuk titik akhir API Management, terutama jika Anda menggunakan nama domain kustom untuk titik akhir Manajemen, Anda mungkin perlu memperbarui nilai config.service.endpoint dalam< file gateway-name.yaml> untuk mengganti nama domain default dengan nama domain kustom. Pastikan titik akhir Manajemen dapat diakses dari pod gateway yang dihost sendiri di klaster Kubernetes.

Dalam skenario ini, jika sertifikat SSL yang digunakan oleh titik akhir Manajemen tidak ditandatangani oleh sertifikat CA terkenal, Anda harus memastikan bahwa sertifikat CA dipercaya oleh pod gateway yang dihost sendiri.

Catatan

Dengan gateway v2 yang dihost sendiri, API Management menyediakan titik akhir konfigurasi baru: <apim-service-name>.configuration.azure-api.net. Nama host kustom didukung untuk titik akhir ini dan dapat digunakan alih-alih nama host default.

Kebijakan DNS

Resolusi nama DNS memainkan peran penting dalam kemampuan gateway yang dihost sendiri untuk menyambungkan ke dependensi di Azure dan mengirim panggilan API ke layanan backend.

File YAML yang disediakan di portal Microsoft Azure menerapkan kebijakan ClusterFirst default. Kebijakan ini menyebabkan permintaan resolusi nama tidak diselesaikan oleh DNS klaster untuk diteruskan ke server DNS hulu yang diwarisi dari node.

Untuk mempelajari resolusi nama di Kubernetes, lihat situs web Kubernetes. Pertimbangkan untuk mengustomisasi kebijakan DNS atau konfigurasi DNS yang sesuai untuk penyiapan Anda.

Kebijakan lalu lintas eksternal

File YAML yang disediakan di bidang set portal Microsoft Azure externalTrafficPolicy pada objek Layanan ke Local. Ini mempertahankan alamat IP penelepon (dapat diakses di konteks permintaan) dan menonaktifkan penyeimbangan beban node silang, menghilangkan hop jaringan yang disebabkan olehnya. Perlu diketahui, bahwa pengaturan ini dapat menyebabkan distribusi lalu lintas asimetris dalam penyebaran dengan jumlah pod gateway yang tidak sama per node.

Ketersediaan tinggi

Gateway yang dihost sendiri adalah komponen penting dalam infrastruktur dan harus memiliki ketersediaan tinggi. Namun, kegagalan akan dan dapat terjadi.

Pertimbangkan untuk melindungi gateway yang dihost sendiri terhadap gangguan.

Tip

Saat menginstal dengan Helm, aktifkan penjadwalan dengan ketersediaan tinggi dengan mudah dengan mengaktifkan opsi konfigurasi highAvailability.enabled.

Pelajari selengkapnya cara menginstal gateway API Management yang dihost sendiri di Kubernetes dengan Helm.

Melindungi terhadap kegagalan node

Untuk mencegah pengaruh dari kegagalan pusat data atau node, pertimbangkan untuk menggunakan kluster Kubernetes yang menggunakan zona ketersediaan untuk mencapai ketersediaan tinggi pada tingkat node.

Zona ketersediaan memungkinkan Anda menjadwalkan pod gateway yang dihost sendiri pada node yang tersebar di seluruh zona menggunakan:

Catatan

Jika Anda menggunakan Azure Kubernetes Service, pelajari cara menggunakan zona ketersediaan di artikel ini.

Melindungi terhadap gangguan pod

Pod dapat mengalami gangguan akibat berbagai alasan seperti penghapusan pod manual, pemeliharaan node, dll.

Pertimbangkan untuk menggunakan Anggaran Gangguan Pod untuk memberlakukan jumlah minimum pod yang akan tersedia pada waktu tertentu.

Proksi HTTP(S)

Gateway yang dihost sendiri menyediakan dukungan untuk proksi HTTP dengan menggunakan variabel lingkungan , HTTPS_PROXY dan NO_PROXY tradisionalHTTP_PROXY.

Setelah dikonfigurasi, gateway yang dihost sendiri akan secara otomatis menggunakan proksi untuk semua permintaan HTTP keluar ke layanan backend.

Dimulai dengan versi 2.1.5 atau lebih tinggi, gateway yang dihost sendiri memberikan pengamatan yang terkait dengan proksi permintaan:

  • Pemeriksa API akan menampilkan langkah-langkah tambahan saat proksi HTTP sedang digunakan dan interaksi terkait.
  • Log verbose disediakan untuk memberikan indikasi perilaku proksi permintaan.

Catatan

Karena masalah yang diketahui dengan proksi HTTP menggunakan autentikasi dasar, menggunakan validasi daftar pencabutan sertifikat (CRL) tidak didukung. Pelajari selengkapnya di referensi pengaturan Gateway yang Dihost sendiri cara mengonfigurasinya dengan tepat.

Peringatan

Pastikan bahwa persyaratan infrastruktur telah terpenuhi dan gateway yang dihost sendiri masih dapat terhubung ke mereka atau fungsionalitas tertentu tidak akan berfungsi dengan baik.

Log dan metrik lokal

Gateway yang dihost sendiri mengirimkan telemetri ke Azure Monitor dan Azure Application Insights sesuai dengan pengaturan konfigurasi di layanan API Management terkait. Ketika konektivitas ke Azure hilang sementara, aliran telemetri ke Azure terganggu dan data hilang selama durasi pemadaman.

Pertimbangkan untuk menggunakan Azure Monitor Container Insights untuk memantau kontainer Anda atau menyiapkan pemantauan lokal untuk memastikan kemampuan untuk mengamati lalu lintas API dan mencegah hilangnya telemetri selama pemadaman konektivitas Azure.

Ruang nama

Namespace Kubernetes membantu membagi satu klaster di antara beberapa tim, proyek, atau aplikasi. Namespace menyediakan lingkup untuk sumber daya dan nama. Mereka dapat dikaitkan dengan kuota sumber daya dan kebijakan kontrol akses.

Portal Microsoft Azure menyediakan perintah untuk membuat sumber daya gateway yang dihost sendiri di namespace default. Namespace ini secara otomatis dibuat, ada di setiap klaster, dan tidak dapat dihapus. Pertimbangkan untuk membuat dan menyebarkan gateway yang dihosti sendiri ke dalam namespace terpisah dalam produksi.

Jumlah replika

Jumlah minimum replika yang cocok untuk produksi adalah tiga, sebaiknya dikombinasikan dengan penjadwalan instans dengan ketersediaan tinggi.

Secara default, gateway yang dihost sendiri disebarkan dengan strategi penyebaran RollingUpdate. Tinjau nilai default dan pertimbangkan secara eksplisit untuk menyetel bidang maxUnavailable dan maxSurge, terutama bila Anda menggunakan jumlah replika yang tinggi.

Performa

Sebaiknya kurangi log kontainer ke peringatan (warn) untuk meningkatkan performa. Pelajari selengkapnya di referensi konfigurasi gateway yang dihost sendiri.

Minta pembatasan

Pembatasan permintaan di gateway yang dihost sendiri dapat diaktifkan dengan menggunakan kebijakan batas tarif API Management atau batas kecepatan demi kunci. Konfigurasikan jumlah batas laju untuk disinkronkan di antara instans gateway di seluruh node kluster dengan mengekspos port berikut dalam penyebaran Kubernetes untuk penemuan instans:

  • Port 4290 (UDP), untuk sinkronisasi pembatasan tarif
  • Port 4291 (UDP), untuk mengirim heartbeat ke instans lain

Catatan

Jumlah batas laju dalam gateway yang dihost sendiri dapat dikonfigurasi untuk disinkronkan secara lokal (di antara instans gateway di seluruh node kluster), misalnya, melalui penyebaran bagan Helm untuk Kubernetes atau menggunakan templat penyebaran portal Azure. Namun, jumlah batas laju tidak disinkronkan dengan sumber daya gateway lain yang dikonfigurasi dalam instans API Management, termasuk gateway terkelola di cloud.

Keamanan

Gateway yang dihost sendiri dapat berjalan sebagai non-root di Kubernetes yang memungkinkan pelanggan untuk menjalankan gateway dengan aman.

Berikut adalah contoh konteks keamanan untuk kontainer gateway yang dihost sendiri:

securityContext:
  allowPrivilegeEscalation: false
  runAsNonRoot: true
  runAsUser: 1001       # This is a built-in user, but you can use any user ie 1000 as well
  runAsGroup: 2000      # This is just an example
  privileged: false
  capabilities:
    drop:
    - all

Peringatan

Menjalankan gateway yang dihost sendiri dengan sistem file baca-saja (readOnlyRootFilesystem: true) tidak didukung.

Peringatan

Saat menggunakan sertifikat CA lokal, gateway yang dihost sendiri harus berjalan dengan ID pengguna (UID) 1001 untuk mengelola sertifikat CA, jika tidak gateway tidak akan dimulai.

Langkah berikutnya