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. GKE Service Steering 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 mana pun dari model OSI yang dimulai dari Lapisan 2 (lapisan data link).

Fungsi Layanan dapat dikategorikan secara luas sebagai berikut:

  • Firewall untuk keamanan
  • Proxy untuk mengontrol akses
  • Akselerasi WAN untuk meningkatkan kecepatan,
  • Deep Packet Inspection (DPI) untuk menganalisis konten
  • Lawful Intercept (LI) untuk pengawasan dan investigasi
  • Network Address Translator (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
  • Peralatan virtual
  • Fungsi jaringan tervirtualisasi (NFV)
  • Fungsi jaringan dalam container (CNF)
  • Fungsi jaringan berbasis cloud (CNF)

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

Rantai Fungsi Layanan (SFC)

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

Rantai Fungsi Layanan (SFC) juga disebut Rantai Layanan (SC).

Dalam Service Steering, objek ServiceFunctionChain mewakili Rantai Fungsi Layanan (SFC).

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

Service Steering

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

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 menjadi kelebihan beban.
  • Mendukung afinitas alur 5-tuple (semua hop perantara harus stabil untuk alur tertentu): Alur 5-tuple adalah cara untuk mengidentifikasi aliran traffic jaringan tertentu berdasarkan alamat IP sumber, port sumber, alamat IP tujuan, port tujuan, dan protokol. Service Steering membantu memastikan bahwa semua paket dalam alur yang sama secara konsisten diarahkan ke kumpulan Fungsi Layanan (hop) yang sama.
  • Mengaktifkan datapath kembali simetris: Datapath kembali simetris berarti traffic respons mengikuti jalur yang sama kembali ke sumber seperti traffic permintaan asli. Service Steering membantu memastikan simetri ini, yang penting untuk beberapa protokol jejaring dan aplikasi.

Untuk traffic jaringan tertentu yang diarahkan oleh layanan, Pod Fungsi Layanan perantara menangani semua paket traffic jaringan tertentu yang memastikan hop perantara yang konsisten dan rute yang dapat diprediksi. Pod Fungsi Layanan yang sama menerima traffic kembali untuk memastikan alur traffic simetris. Jika traffic asli dikirim ke tujuan dalam cluster yang sama, traffic kembali akan otomatis menemukan cara untuk kembali melalui Rantai Layanan yang sama. Jika traffic asli berada di luar cluster, Fungsi Layanan terakhir dalam rantai akan menarik traffic kembali ke dirinya sendiri menggunakan terjemahan 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 membangun infrastruktur keamanan mereka sendiri menggunakan fungsi jaringan dalam container (CNF) seperti firewall virtual (vFW), firewall virtual generasi berikutnya (vNG-FW), dan sistem deteksi penyusupan virtual (vIDS). Service Steering membantu 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 Rantai Layanan keamanan berbasis cloud mereka. Hal ini memungkinkan mereka menawarkan solusi keamanan yang komprehensif, termasuk fungsi Secure Web Gateways (SWG), SASE (Secure Access Service Edge), dan 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), pengontrol batas sesi virtual (vSBC), dan fungsi jaringan inti 5G untuk memastikan pengelolaan traffic yang efisien, load balancing, dan penerapan kebijakan kualitas layanan atau keamanan tertentu.

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 dari alamat IP sumber paket, port sumber, alamat IP tujuan, port tujuan, dan protokol.

  2. Membantu memastikan afinitas alur: Service Steering membantu memastikan afinitas alur dengan mengarahkan semua paket dengan ID alur yang sama melalui jalur Fungsi Layanan (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 alur 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 dihilangkan 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 menyadarinya. Paket didekapsulasi sebelum memasuki Pod, sehingga 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. Koneksi ini akan mengalihkan paket dari koneksi ini ke fungsi layanan yang sesuai. Fungsi Layanan itu sendiri bertanggung jawab untuk mengelola koneksi yang sedang berlangsung ini. Pendekatan umum adalah menghilangkan 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 akan segera dihapus setelah ditandai untuk dihapus. Tidak ada webhook atau finalizer 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 Service Steering 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 melewati NetworkPolicy. Kebijakan keluar di Pod sumber dan kebijakan masuk di Pod tujuan masih berlaku untuk traffic yang dipilih untuk Service Steering. Namun, kebijakan ini tidak tunduk pada penerapan NetworkPolicy di traffic masuk atau keluar Fungsi Layanan. Hal ini karena aturan masuk atau keluar dari NetworkPolicy ditentukan dengan baik untuk Pod sumber dan tujuan, tetapi tidak untuk penerus paket.

Manfaat

Penerapan GKE Service Steering, yang dipadukan dengan transisi ke teknologi berbasis cloud, memiliki manfaat berikut:

  • Penawaran Marketplace: Pihak Ketiga dapat menawarkan produk dalam container mereka di Google Cloud Marketplace dan menggunakan Service Steering API. Mereka dapat memberikan panduan deployment berdasarkan API bawaan Kubernetes yang disediakan dan dikelola oleh GKE.
  • Granularitas Kubernetes: Anda dapat mengontrol traffic dalam cluster Kubernetes. Anda dapat mengklasifikasikan traffic yang ingin Anda arahkan. Anda dapat memilih workload tempat Anda ingin menerapkan Service Steering secara selektif.
  • Bidireksionalitas: Service Steering GKE bersifat bidireksional. Artinya, untuk alur tertentu, jalur kembali simetris dengan jalur penerusan. Hal ini penting saat Fungsi Layanan (SF) di-deploy sebagai grup replika. Pastikan alur yang sama melewati Replika kumpulan yang sama untuk mempertahankan status.
  • Dukungan Multi-Jaringan: Sebagian besar Fungsi Layanan memerlukan beberapa antarmuka Pod untuk memisahkan bidang data dari bidang kontrol dan pengelolaan. Beberapa Fungsi Layanan memiliki beberapa antarmuka sebagai bagian dari arsitekturnya. Service Steering GKE mencakup integrasi dengan Multi-Jaringan di Pod. Dengan demikian, pengguna dapat membuat Service Steering di Jaringan Pod tertentu.
  • Pengiriman Paket Mentah ke Aplikasi: Service Steering GKE mengenkapsulasi 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 berikutnya