Gunakan Azure API Management dengan layanan mikro yang disebarkan di Azure Kubernetes Service

Berlaku untuk: Semua tingkat API Management

Layanan mikro sangat cocok untuk membangun API. Anda dapat menggunakan Azure Kubernetes Service (AKS) untuk menyebarkan dan mengoperasikan arsitektur berbasis layanan mikro dengan cepat di cloud. Anda kemudian dapat menggunakan Azure API Management untuk menerbitkan layanan mikro Anda sebagai API untuk konsumsi internal dan eksternal. Artikel ini menjelaskan opsi untuk menggunakan API Management untuk menerbitkan arsitektur berbasis layanan mikro AKS sebagai API. Ini mengasumsikan pengetahuan dasar tentang jaringan Kubernetes, API Management, dan Azure.

Latar belakang

Ketika Anda menerbitkan layanan mikro sebagai API untuk dikonsumsi, mungkin sulit untuk mengelola komunikasi antara layanan mikro dan klien yang mengonsumsinya. Masalah lintas proses termasuk autentikasi, otorisasi, pembatasan, penyimpanan sementara, transformasi, dan pemantauan. Kekhawatiran ini berlaku terlepas dari apakah layanan mikro diekspos ke klien internal atau eksternal.

Pola API Gateway membahas masalah ini. Gerbang API berfungsi sebagai gerbang untuk layanan mikro, memisahkan klien dari layanan mikro Anda, menambahkan lapisan keamanan lain, dan mengurangi kompleksitas layanan mikro Anda dengan menghapus beban penanganan masalah lintas-fungsi.

API Management adalah solusi turnkey untuk menyelesaikan kebutuhan gateway API Anda. Anda dapat dengan cepat membuat gateway yang konsisten dan modern untuk layanan mikro Anda dan menerbitkannya sebagai API. Sebagai solusi manajemen API siklus hidup penuh, solusi ini juga menyediakan kemampuan tambahan, termasuk portal pengembang layanan mandiri untuk penemuan API, manajemen siklus hidup API, dan analitik API.

Saat digunakan bersama-sama, AKS dan API Management menyediakan platform untuk menyebarkan, menerbitkan, mengamankan, memantau, dan mengelola API berbasis layanan mikro Anda. Artikel ini menjelaskan beberapa opsi untuk menyebarkan AKS bersama dengan API Management.

Layanan dan API Kubernetes

Dalam klaster Kubernetes, kontainer disebarkan dalam Pod, yang sangat singkat dan memiliki siklus hidup. Ketika node pekerja gagal, Pod yang berjalan pada node menjadi tidak aktif. Oleh karena itu, alamat IP pod dapat berubah kapan saja. Anda tidak dapat mengandalkannya untuk berkomunikasi dengan pod.

Untuk mengatasi masalah ini, Kubernetes memperkenalkan konsep Layanan. Layanan Kubernetes adalah lapisan abstraksi yang mendefinisikan sekelompok Pod logis dan memungkinkan paparan lalu lintas eksternal, penyeimbangan beban, dan penemuan layanan untuk Pod tersebut.

Ketika Anda siap untuk menerbitkan layanan mikro sebagai API dengan menggunakan API Management, Anda perlu memikirkan cara memetakan Layanan Anda di Kubernetes ke API di API Management. Tidak ada aturan yang ditetapkan untuk pemetaan ini. Itu tergantung pada bagaimana Anda merancang dan mempartisi kemampuan atau domain bisnis Anda menjadi microservices pada awalnya. Misalnya, jika Pod di belakang Layanan bertanggung jawab atas semua operasi pada sumber daya tertentu (misalnya, Pelanggan), Anda dapat memetakan Layanan ke satu API. Jika operasi pada sumber daya dipartisi ke dalam beberapa layanan mikro (misalnya, GetOrder dan PlaceOrder), Anda mungkin menggabungkan beberapa Layanan ke dalam satu API dalam API Management. (Lihat diagram berikut.)

Pemetaan juga dapat berkembang. Karena API Management membuat fasad di depan layanan mikro, API Management memungkinkan Anda untuk merefaktor dan menyesuaikan ukuran layanan mikro Anda dari waktu ke waktu.

Diagram yang memperlihatkan pemetaan layanan yang berbeda ke API.

Menyebarkan API Management di muka AKS

Ada beberapa opsi untuk menyebarkan API Management di depan kluster AKS.

Kluster AKS selalu disebarkan dalam jaringan virtual, tetapi instans API Management belum tentu disebarkan dalam jaringan virtual. Ketika API Management tidak berada dalam jaringan virtual kluster, kluster AKS perlu menerbitkan titik akhir publik agar API Management dapat terhubung. Dalam hal ini, Anda perlu mengamankan koneksi antara API Management dan AKS. Dengan kata lain, Anda perlu memastikan bahwa kluster hanya dapat diakses melalui API Management. Bagian berikut menjelaskan opsi untuk menyebarkan API Management di depan AKS.

Opsi 1: Mengekspos Layanan secara publik

Anda dapat mengekspos Layanan secara publik di kluster AKS dengan menggunakan jenis NodePort, LoadBalancer, atau ExternalName Service. Ketika Anda melakukannya, Layanan dapat diakses langsung dari internet publik. Setelah menyebarkan API Management di depan kluster, Anda perlu memastikan bahwa semua lalu lintas masuk melewati API Management dengan menerapkan autentikasi di layanan mikro. Misalnya, API Management dapat menyertakan token akses dalam setiap permintaan yang dibuat ke klaster. Setiap layanan mikro harus memvalidasi token sebelum memproses permintaan.

Opsi ini mungkin menyediakan cara term mudah untuk menyebarkan API Management di depan AKS, terutama jika Anda sudah memiliki logika autentikasi yang diterapkan di layanan mikro Anda.

Diagram yang memperlihatkan arsitektur untuk layanan penerbitan secara langsung.

Kelebihan:

  • Konfigurasi mudah di sisi API Management karena API Management tidak perlu disuntikkan ke jaringan virtual kluster
  • Tidak ada perubahan pada sisi AKS jika Layanan sudah diekspos secara publik dan logika autentikasi sudah ada dalam layanan mikro

Kontra:

  • Mengakibatkan potensi risiko keamanan karena terlihatnya titik akhir secara publik
  • Tidak membuat satu titik masuk untuk lalu lintas gugus masuk
  • Mempersulit layanan mikro dengan logika autentikasi duplikat

Opsi 2: Memasang pengontrol ingress

Meskipun opsi 1 mungkin lebih mudah, opsi ini memiliki kelemahan penting, seperti yang disebutkan sebelumnya. Jika instans API Management tidak berada di jaringan virtual kluster, autentikasi TLS bersama (mTLS) adalah cara yang kuat untuk memastikan bahwa lalu lintas aman dan tepercaya pada kedua arah antara instans API Management dan kluster AKS.

Autentikasi TLS bersama didukung secara bawaan oleh API Management. Anda dapat mengaktifkannya di Kubernetes dengan menginstal pengontrol ingress. (Lihat diagram berikut.) Akibatnya, autentikasi dilakukan di pengontrol ingress, yang menyederhanakan layanan mikro. Selain itu, dalam tingkat layanan yang mendukung alamat IP khusus, Anda dapat menambahkan alamat IP API Management ke daftar izin masuk untuk memastikan bahwa hanya API Management yang memiliki akses ke kluster.

Diagram yang menampilkan arsitektur untuk penerbitan melalui controller ingress.

Kelebihan:

  • Mengaktifkan konfigurasi mudah di sisi API Management karena API Management tidak perlu disuntikkan ke jaringan virtual kluster dan mTLS didukung secara asli
  • Memusatkan perlindungan untuk lalu lintas kluster yang masuk pada tingkat kontrol masuk
  • Mengurangi risiko keamanan dengan meminimalkan titik akhir kluster yang terlihat secara publik

Kontra:

  • Meningkatkan kompleksitas konfigurasi kluster karena Anda perlu menginstal, mengonfigurasi, dan memelihara pengontrol ingress dan mengelola sertifikat yang digunakan untuk mTLS
  • Menambahkan risiko keamanan karena titik akhir ingress controller terekspose secara publik, kecuali Anda menggunakan API Management Standard v2 atau versi Premium.

Saat Anda menerbitkan API melalui API Management, mudah dan khas untuk mengamankan akses ke API tersebut dengan menggunakan kunci langganan. Pengembang yang perlu menggunakan API yang diterbitkan harus menyertakan kunci langganan yang valid dalam permintaan HTTP ketika mereka melakukan panggilan ke API tersebut. Jika tidak, panggilan akan langsung ditolak oleh gateway API Management. Mereka tidak diteruskan ke layanan backend.

Untuk mendapatkan kunci langganan untuk mengakses API, pengembang memerlukan langganan. Langganan pada dasarnya adalah wadah bernama untuk dua kunci langganan. Pengembang yang perlu menggunakan API yang dipublikasikan bisa mendapatkan langganan. Mereka tidak memerlukan persetujuan dari penerbit API. Penerbit API juga dapat membuat langganan secara langsung untuk konsumen API.

Opsi 3: Menyebarkan API Management di dalam jaringan virtual kluster

Dalam beberapa kasus, pelanggan yang memiliki batasan peraturan atau persyaratan keamanan ketat mungkin menemukan Opsi 1 dan 2 tidak layak karena titik akhir yang terekspos secara publik. Di lain, kluster AKS dan aplikasi yang mengonsumsi layanan mikro mungkin berada dalam jaringan virtual yang sama, jadi tidak ada alasan untuk mengekspos kluster secara publik karena semua lalu lintas API tetap berada dalam jaringan virtual. Dalam skenario ini, Anda dapat menyebarkan API Management ke jaringan virtual kluster. Tingkat Pengembang API Management, Premium, dan Premium v2 (pratinjau) mendukung injeksi ke kluster jaringan virtual.

Ada dua mode penyebaran API Management ke jaringan virtual: eksternal dan internal. Saat ini, mode eksternal hanya tersedia di tingkat klasik API Management.

Jika konsumen API tidak berada di jaringan virtual kluster, Anda harus menggunakan mode eksternal. (Lihat diagram berikut.) Dalam mode ini, gateway API Management disuntikkan ke jaringan virtual kluster yang dapat diakses dari internet publik melalui pengimbang muatan eksternal. Arsitektur ini membantu menyembunyikan kluster sepenuhnya sambil tetap memungkinkan klien eksternal untuk mengonsumsi layanan mikro. Selain itu, Anda dapat menggunakan kemampuan jaringan Azure seperti Network Security Groups (NSG) untuk membatasi lalu lintas jaringan.

Diagram yang memperlihatkan arsitektur yang menggunakan mode jaringan virtual eksternal.

Jika semua konsumen API berada dalam jaringan virtual kluster, Anda dapat menggunakan mode internal. (Lihat diagram berikut.) Dalam mode ini, gateway API Management disuntikkan ke jaringan virtual kluster dan hanya dapat diakses dari dalam jaringan virtual ini melalui load balancer internal. Tidak ada cara untuk menjangkau gateway API Management atau kluster AKS dari internet publik.

Diagram yang memperlihatkan arsitektur yang menggunakan mode jaringan virtual internal.

Kluster AKS tidak terlihat secara publik dalam kedua kasus. Berbeda dengan Opsi 2, pengontrol ingress mungkin tidak diperlukan. Bergantung pada skenario dan konfigurasi Anda, autentikasi mungkin masih diperlukan antara API Management dan layanan mikro Anda. Misalnya, jika Anda menggunakan jala layanan, Anda selalu memerlukan autentikasi TLS bersama.

Kelebihan:

  • Menyediakan opsi yang paling aman karena kluster AKS tidak memiliki titik akhir publik
  • Menyederhanakan konfigurasi kluster karena tidak ada titik akhir publik
  • Menyediakan kemampuan untuk menyembunyikan API Management dan AKS di dalam jaringan virtual dengan menggunakan mode internal
  • Menyediakan kemampuan untuk mengontrol lalu lintas jaringan dengan menggunakan kemampuan jaringan Azure seperti NSG

Kontra:

  • Meningkatkan kompleksitas penyebaran dan konfigurasi API Management untuk bekerja di dalam jaringan virtual

Konten terkait

  • Last updated on