Tentang Pengarahan Layanan

Ringkasan

Anda dapat mengontrol alur traffic jaringan dalam cluster GKE menggunakan GKE Service Steering. Anda dapat menentukan aturan untuk mengarahkan jenis traffic tertentu ke fungsi jaringan yang telah Anda deploy di cluster. Pengarah Layanan GKE mirip dengan pemilihan rute berbasis kebijakan, tempat Anda mengganti jalur normal traffic jaringan.

Terminologi dan konsep

Halaman ini menggunakan konsep berikut:

Fungsi Layanan (SF)

Fungsi Layanan adalah komponen software yang berfungsi pada paket data yang diterima. Lapisan Layanan dapat beroperasi di lapisan model OSI mana pun mulai dari Lapisan 2 (lapisan data link).

Fungsi Layanan secara luas dapat dikategorikan menjadi:

  • Firewall untuk keamanan
  • Proxy untuk mengontrol akses
  • Akselerasi WAN untuk meningkatkan kecepatan,
  • Deep Packet Inspection (DPI) untuk menganalisis konten
  • Intersepsi Sah (LI) untuk pengawasan dan investigasi
  • Penafsir Alamat Jaringan (NAT) untuk alamat IP pribadi dan publik
  • HTTP untuk pengayaan header
  • Load balancer untuk mendistribusikan traffic secara efisien

Terminologi alternatif untuk Fungsi Layanan mencakup:

  • Peralatan container
  • Appliance virtual
  • Fungsi jaringan virtual (NFV)
  • Fungsi jaringan dalam container (CNF)
  • Fungsi jaringan (CNF) berbasis cloud

Dalam Service Steering, objek Layanan mewakili Fungsi Layanan (SF).

Service Function Chain (SFC)

Service Function Chain (SFC) adalah serangkaian Fungsi Layanan seperti firewall, proxy, atau load balancer yang ditautkan bersama untuk memproses traffic jaringan dalam urutan tertentu. Rantai ini berfungsi seperti pipeline, dengan setiap Fungsi Layanan melakukan tugas tertentu pada traffic sebelum meneruskannya ke fungsi berikutnya.

Service Function Chain (SFC) juga disebut Service Chain (SC).

Dalam Service Steering, objek ServiceFunctionChain mewakili Service Function Chain (SFC).

Fungsi Layanan beroperasi secara independen dari Rantai Fungsi Layanan apa pun. Fungsi Layanan biasanya tidak mengetahui rantai Fungsi Layanan mana yang menjadi bagiannya.

Pembimbingan Layanan

Service Steering merutekan paket ke Fungsi Layanan yang dipilih dengan cara yang sepenuhnya transparan untuk sumber dan tujuan. Konsep ini terkadang disebut sebagai "rute berbasis kebijakan", "pengalihan traffic", atau "Penerusan Fungsi Layanan". Service Steering mencapai pemilihan rute transparan menggunakan enkapsulasi Geneve + NSH (lihat RFC 8926, RFC 8300, Draf IETF Geneve + NSH).

Beberapa karakteristik penting dari Service Steering meliputi:

  • Load balancing di seluruh Pod backend Fungsi Layanan: Fungsi Layanan sering kali berjalan di beberapa Pod untuk skalabilitas dan keandalan. Service Steering mendistribusikan traffic jaringan masuk secara merata di seluruh Pod ini untuk mencegah satu Pod kelebihan beban.
  • Mendukung afinitas alur 5-tuple (semua hop perantara harus stabil untuk alur tertentu): Alur 5-tuple adalah cara mengidentifikasi aliran traffic jaringan tertentu berdasarkan alamat IP sumber, port sumber, alamat IP tujuan, port tujuan, dan protokol. Service Steering memastikan bahwa semua paket dalam alur yang sama diarahkan secara konsisten ke kumpulan Fungsi Layanan (hop) yang sama.
  • Mengaktifkan jalur data return simetris: Jalur data return simetris berarti traffic respons mengikuti jalur yang sama kembali ke sumber seperti traffic permintaan asli. Service Steering memastikan simetri ini, yang penting untuk beberapa protokol dan aplikasi jaringan.

Untuk traffic jaringan tertentu yang diarahkan layanan, Pod Fungsi Layanan perantara menangani semua paket traffic jaringan tertentu tersebut yang memastikan hop perantara yang konsisten dan rute yang dapat diprediksi. Pod Fungsi Layanan yang sama menerima traffic yang kembali untuk memastikan alur traffic simetris. Jika traffic asli dikirim ke tujuan dalam cluster yang sama, traffic kembali akan otomatis menemukan jalan kembali melalui Rantai Layanan yang sama. Jika traffic asli berada di luar cluster, Fungsi Layanan akhir dalam rantai akan menarik traffic kembali ke dirinya sendiri menggunakan penafsiran alamat jaringan sumber (SNAT) atau proxy, yang bertindak sebagai perantara.

Kasus penggunaan

GKE Service Steering mengintegrasikan pemilihan rute berbasis kebijakan ke dalam cluster Anda. Tindakan ini memungkinkan kasus penggunaan utama berikut:

Layanan keamanan yang dikelola sendiri:

Organisasi dapat membuat infrastruktur keamanan mereka sendiri menggunakan fungsi jaringan dalam penampung (CNF) seperti firewall virtual (vFW), virtual firewall generasi berikutnya (vNG-FW), dan sistem deteksi intrusi virtual (vIDS). Service Steering memastikan bahwa traffic dirutekan melalui CNF ini sebelum mencapai tujuan yang diinginkan, sehingga memberikan lapisan perlindungan dan kontrol.

Penyedia keamanan terkelola (MSP):

MSP dapat menggunakan GKE Service Steering untuk merutekan traffic Anda melalui Service Chain keamanan berbasis cloud mereka. Hal ini memungkinkan mereka menawarkan solusi keamanan yang komprehensif, termasuk Secure Web Gateway (SWG), SASE (Secure Access Service Edge), dan fungsi SD-WAN (Software-Defined Wide Area Network).

Telekomunikasi dan Jaringan 5G:

Service Steering mengelola alur traffic untuk berbagai fungsi jaringan dalam infrastruktur telekomunikasi dan 5G. Anda dapat mengatur router virtual (vRouter), virtual session border controller (vSBC), dan fungsi jaringan inti 5G untuk memastikan pengelolaan traffic, load balancing, dan penegakan kebijakan keamanan atau kualitas Layanan tertentu yang efisien.

Cara kerja Service Steering

Bagian ini menjelaskan cara kerja berbagai komponen Service Steering.

Fungsi Layanan

  1. Mengidentifikasi alur traffic jaringan: GKE Service Steering mengidentifikasi setiap koneksi jaringan menggunakan ID alur unik, hash 5-tuple alamat IP sumber paket, port sumber, alamat IP tujuan, port tujuan, dan protokol.

  2. Memastikan afinitas alur: Service Steering memastikan afinitas alur dengan mengarahkan semua paket dengan ID alur yang sama melalui jalur Service Functions (SF) yang sama.

  3. Mengubah paket untuk membuat alur baru: Jika Fungsi Layanan mengubah salah satu kolom 5-tuple dalam paket. Misalnya, NAT mengubah alamat IP sumber, sehingga membuat alur baru.

  4. Memilih traffic untuk alur baru: Proses pemilihan traffic mengevaluasi alur baru untuk menentukan jalurnya melalui Service Functions yang tersisa, yang berpotensi mengambil rute yang berbeda dari alur asli.

  5. Menangani proxy dan NAT sebagai dua alur: Traffic melalui proxy atau NAT dianggap sebagai dua alur terpisah: sumber ke proxy/NAT dan proxy/NAT ke tujuan. Service Steering tidak menjamin jalur yang sama untuk kedua aliran ini.

  6. Memvalidasi alamat sumber: SF selalu tunduk pada validasi alamat sumber, bahkan untuk traffic yang tidak diarahkan oleh Service Steering. Jika Fungsi Layanan berasal dari alur baru dengan alamat IP sumber yang tidak cocok, paket tersebut akan dihapus kecuali jika diizinkan secara eksplisit.

  7. Mempertahankan transparansi enkapsulasi: Service Steering menggunakan enkapsulasi Geneve untuk traffic antar-SF, tetapi Pod Fungsi Layanan itu sendiri tidak mengetahuinya. Paket didekapsulasi sebelum memasuki Pod, yang menyederhanakan pengembangan Fungsi Layanan.

Koneksi yang ada

Saat Anda membuat TrafficSelector, Service Steering akan otomatis menerapkannya ke koneksi yang ada yang cocok dengan kriteria pemilih. Fungsi ini mengalihkan paket dari koneksi ini ke fungsi layanan yang sesuai. Fungsi Layanan itu sendiri bertanggung jawab untuk mengelola koneksi dalam penerbangan ini. Pendekatan umumnya adalah menghapus paket dan mengandalkan klien untuk memulai koneksi baru, yang kemudian terintegrasi dengan lancar ke dalam rantai layanan sejak awal.

Siklus proses resource

Resource TrafficSelector dan ServiceFunctionChain dihapus segera setelah ditandai untuk dihapus. Tidak ada webhook atau penyelesaian yang mencegah atau menunda penghapusan resource.

Traffic Pod-ke-Layanan

Service Steering melakukan pemilihan traffic setelah me-resolve alamat IP Virtual Layanan. Traffic yang diarahkan ke Layanan menggunakan ClusterIP-nya dapat dipilih untuk Pengarah Layanan jika alamat IP Pod tujuan berada dalam CIDR yang ditentukan di kolom .egress.to.ipBlock setelah alamat IP Virtual di-resolve.

Penerapan NetworkPolicy

Service Steering tidak mengabaikan NetworkPolicy. Kebijakan keluar di Pod sumber dan kebijakan masuk di Pod tujuan masih berlaku untuk traffic yang dipilih untuk Pengarah Layanan. Namun, hal ini tidak tunduk pada penerapan NetworkPolicy pada ingress atau egress Fungsi Layanan. Hal ini karena aturan masuk atau keluar NetworkPolicy ditentukan dengan baik untuk Pod sumber dan tujuan, tetapi tidak untuk penerusan paket.

Manfaat

Penerapan GKE Service Steering, bersama dengan transisi ke teknologi native cloud, memiliki manfaat berikut:

  • Penawaran Marketplace: Pihak Ketiga dapat menawarkan produk dalam penampung mereka di Google Cloud Marketplace dan menggunakan Service Steering API. API ini dapat memberikan panduan deployment berdasarkan API bawaan Kubernetes yang disediakan dan dikelola oleh GKE.
  • Perincian Kubernetes: Anda dapat mengontrol traffic dalam cluster Kubernetes. Anda dapat mengklasifikasikan traffic yang ingin diarahkan. Anda dapat memilih beban kerja tempat Anda ingin Pengarah Layanan diterapkan secara selektif.
  • Bidirectional: Pengarah Layanan GKE bersifat bidirectional. Artinya, untuk alur tertentu, jalur kembali simetris dengan jalur maju. Hal ini penting saat Fungsi Layanan (SF) di-deploy sebagai grup replika. Pastikan bahwa alur yang sama melewati Replika yang ditetapkan sama untuk mempertahankan status.
  • Dukungan Multi-Jaringan: Sebagian besar Fungsi Layanan memerlukan beberapa antarmuka Pod untuk memisahkan dataplane dari bidang kontrol dan pengelolaan. Beberapa Fungsi Layanan memiliki beberapa antarmuka sebagai bagian dari arsitekturnya. Pengarah Layanan GKE mencakup integrasi dengan Multi-Jaringan di Pod. Dengan ini, pengguna dapat membuat Service Steering di Jaringan Pod tertentu.
  • Pengiriman Paket Mentah ke Aplikasi: Service Steering GKE menggabungkan paket asli dan mengirimkannya langsung ke Pod. Dengan cara ini, Anda tidak perlu melakukan dekapsulasi dan aplikasi Anda dapat langsung bertindak pada paket asli.

Langkah selanjutnya