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

BERLAKU UNTUK: Semua tingkatAN API Management

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

Latar belakang

Saat menerbitkan layanan mikro sebagai API untuk dikonsumsi, mungkin sulit untuk mengelola komunikasi antara layanan mikro dan klien yang mengonsumsinya. Ada banyak masalah lintas pemotongan seperti autentikasi, otorisasi, pembatasan, penembolokan, transformasi, dan pemantauan. Kekhawatiran ini valid terlepas dari apakah layanan mikro terpapar pada klien internal atau eksternal.

Pola API Gateway membahas masalah ini. Sebuah gateway API berfungsi sebagai pintu depan untuk layanan mikro, memisahkan klien dari layanan mikro, menambahkan lapisan keamanan tambahan, dan mengurangi kerumitan layanan mikro Anda dengan menghilangkan beban penanganan masalah lintas sektoral.

Azure 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. Dalam artikel ini, kita akan membahas beberapa opsi penyebaran 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 mati, Pod yang berjalan pada node akan hilang. Oleh karena itu, alamat IP sebuah Pod dapat berubah kapan saja. Kita tidak dapat mengandalkannya untuk berkomunikasi dengan pod.

Untuk mengatasi masalah ini, Kubernetes memperkenalkan konsep Layanan. Sebuah Layanan Kubernetes adalah layer abstraksi yang mendefinisikan grup logika dari Pod dan memungkinkan eksposur lalu lintas eksternal, penyeimbang beban, dan temuan layanan untuk Pod-Pod tersebut.

Ketika kami telah siap untuk mempublikasikan layanan mikro kami sebagai API melalui API Management, kami perlu memikirkan cara memetakan Layanan kami di Kubernetes ke API dalam API Management. Tidak ada aturan yang ditetapkan. Aturan tersebut tergantung pada bagaimana Anda merancang dan mempartisi kemampuan bisnis atau domain Anda menjadi layanan mikro di awal. Misalnya, jika pod di belakang Layanan bertanggung jawab atas semua operasi pada sumber daya tertentu (misalnya, Pelanggan), Layanan dapat dipetakan ke satu API. Jika operasi pada sumber daya dipartisi ke dalam beberapa layanan mikro (misalnya, GetOrder, PlaceOrder), maka beberapa Layanan dapat dikumpulkan secara logis ke dalam satu API tunggal dalam manajemen API (Lihat Gambar 1).

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

Menyebarkan API Management di depan AKS

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

Meskipun kluster AKS selalu disebarkan dalam jaringan virtual (VNet), instans API Management tidak perlu disebarkan di VNet. Ketika API Management tidak berada dalam kluster VNet, kluster AKS harus menerbitkan titik akhir publik untuk disambungkan oleh API Management. Dalam hal ini, ada kebutuhan untuk mengamankan koneksi antara API Management dan AKS. Dengan kata lain, kita perlu memastikan klaster hanya dapat diakses secara eksklusif melalui API Management. Mari kita lihat opsinya.

Opsi 1: Mengekspos Layanan secara publik

Layanan dalam klaster AKS dapat diekspos secara publik menggunakan Jenis layanan NodePort, LoadBalancer, atau ExternalName. Dalam hal ini, Layanan dapat diakses secara langsung dari internet publik. Setelah menyebarkan API Management di depan klaster, kita perlu memastikan semua lalu lintas masuk melalui 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 bertanggung jawab untuk memvalidasi token sebelum memproses permintaan.

Ini mungkin opsi termudah untuk menyebarkan API Management di depan AKS, terutama jika Anda sudah memiliki logika autentikasi yang diterapkan di layanan mikro Anda.

Pro:

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

Kontra:

• Potensi risiko keamanan dikarenakan visibilitas publik dari titik akhir
• Tidak ada titik masuk tunggal untuk lalu lintas kluster masuk
• Mempersulit layanan mikro dengan logika autentikasi duplikat

Opsi 2: Instal Pengontrol Ingress

Meskipun Opsi 1 terlihat lebih mudah, opsi ini memiliki kelemahan penting seperti yang disebutkan di atas. Jika instans API Management tidak berada di VNet kluster, autentikasi TLS Bersama (mTLS) adalah cara yang kuat untuk memastikan lalu lintas aman dan tepercaya pada kedua arah antara instans API Management dan kluster AKS.

Autentikasi TLS Timbal Balik didukung secara asli oleh API Management dan dapat diaktifkan di Kubernetes dengan menginstal Ingress Controller (Gbr. 3). Akibatnya, autentikasi akan dilakukan di Ingress Controller, yang menyederhanakan layanan mikro. Selain itu, Anda dapat menambahkan alamat IP API Management ke daftar yang diizinkan oleh Ingress untuk memastikan hanya API Management yang memiliki akses ke klaster.

Pro:

• Konfigurasi mudah di sisi API Management karena tidak perlu disuntikkan ke dalam kluster VNet dan mTLS didukung secara asli
• Memusatkan perlindungan untuk lalu lintas klaster masuk di lapisan Ingress Controller
• Mengurangi risiko keamanan dengan meminimalkan titik akhir kluster yang terlihat secara publik

Kontra:

• Meningkatkan kompleksitas konfigurasi klaster karena kerja ekstra untuk menginstal, mengonfigurasi, dan memelihara Ingress Controller serta mengelola sertifikat yang digunakan untuk mTLS
• Risiko keamanan karena visibilitas publik dari titik akhir Ingress Controller

Saat Anda memublikasikan API melalui API Management, mudah dan umum 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 back-end.

Untuk mendapatkan kunci langganan untuk mengakses API, diperlukan langganan. Langganan pada dasarnya adalah kontainer yang dinamai untuk sepasang kunci langganan. Pengembang yang perlu menggunakan API yang dipublikasikan bisa mendapatkan langganan. Mereka pun tidak membutuhkan persetujuan dari penerbit API. Penerbit API juga dapat membuat langganan secara langsung untuk konsumen API.

Opsi 3: Menyebarkan APIM di dalam klaster VNet

Dalam beberapa kasus, pelanggan dengan batasan peraturan atau persyaratan keamanan yang ketat mungkin menganggap Opsi 1 dan 2 sebagai solusi yang tidak layak dikarenakan titik akhir yang terbuka secara publik. Di lain, kluster AKS dan aplikasi yang mengonsumsi layanan mikro mungkin berada dalam VNet yang sama, sehingga tidak ada alasan untuk mengekspos kluster secara publik karena semua lalu lintas API akan tetap berada dalam VNet. Untuk skenario ini, Anda dapat menyebarkan API Management ke dalam klaster VNet. Pengembang API Management dan tingkat Premium mendukung penyebaran VNet.

Terdapat dua mode penyebaran API Management ke sebuah VNet – Eksternal dan Internal.

Jika konsumen API tidak berada di dalam klaster VNet, mode Eksternal (Gbr. 4) harus digunakan. Dalam mode ini, gateway API Management disuntikkan ke klaster VNet tetapi dapat diakses dari internet publik melalui balancer muatan eksternal. Ini membantu menyembunyikan klaster sepenuhnya sementara masih memungkinkan klien eksternal untuk mengonsumsi layanan mikro. Sebagai tambahan, Anda dapat menggunakan kemampuan jaringan Azure seperti Network Security Groups (NSG) untuk membatasi lalu lintas jaringan.

Jika semua konsumen API berada dalam klaster VNet, maka mode Internal (Gbr. 5) bisa digunakan. Dalam mode ini, gateway API Management disuntikkan ke dalam VNET kluster dan hanya dapat diakses dari dalam VNet ini melalui balancerg beban internal. Tidak ada cara untuk menjangkau gateway API Management atau kluster AKS dari internet publik.

Dalam kedua kasus, kluster AKS tidak terlihat secara publik. Dibandingkan dengan Opsi 2, Ingress Controller mungkin tidak diperlukan. Bergantung pada skenario dan konfigurasi Anda, autentikasi mungkin masih diperlukan antara API Management dan layanan mikro Anda. Misalnya, jika Jala Layanan diadopsi, itu selalu memerlukan autentikasi TLS bersama.

Pro:

• Opsi yang paling aman karena klaster AKS tidak memiliki titik akhir publik
• Menyederhanakan konfigurasi klaster karena tidak memiliki titik akhir publik
• Kemampuan untuk menyembunyikan API Management dan AKS di dalam VNet menggunakan mode Internal
• Kemampuan untuk mengontrol lalu lintas jaringan menggunakan kemampuan jaringan Azure seperti Network Security Groups (NSG)

Kontra:

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

Langkah berikutnya

• Pelajari selengkapnya tentang Konsep jaringan untuk aplikasi di AKS
• Pelajari selengkapnya tentang Cara menggunakan API Management dengan jaringan virtual