Tentang Pengarahan Layanan


Ringkasan

Anda dapat mengontrol aliran 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 . Pengarahan Layanan GKE mirip dengan perutean berbasis kebijakan, di mana Anda mengganti jalur normal dari lalu lintas jaringan.

Terminologi dan konsep

Halaman ini menggunakan konsep berikut:

Fungsi Layanan (SF)

Fungsi Layanan adalah komponen software yang berfungsi pada data yang diterima paket. Lapisan Layanan dapat beroperasi pada setiap lapisan model OSI yang dimulai Lapisan 2 (lapisan {i>data link<i}).

Secara luas, Fungsi Layanan dapat dikategorikan ke dalam:

  • {i>Firewall<i} untuk keamanan
  • {i>Proxy<i} untuk mengontrol akses
  • Akselerasi WAN untuk meningkatkan kecepatan,
  • Deep Packet Inspection (DPI) untuk menganalisis konten
  • Penyadapan yang Sah (LI) untuk pengawasan dan penyelidikan
  • Penerjemah Alamat Jaringan (NAT) untuk alamat IP pribadi dan publik
  • HTTP untuk pengayaan header
  • Load balancer untuk mendistribusikan traffic secara efisien

Istilah alternatif untuk Fungsi Layanan mencakup:

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

Dalam Pengarahan Layanan, objek Service mewakili Service Function (SF).

Rantai Fungsi Layanan (SFC)

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

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

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

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

Pengarahan Layanan

Pengarahan Layanan mengarahkan paket ke Fungsi Layanan yang dipilih dengan cara yang sepenuhnya transparan terhadap sumber dan tujuan. Konsep ini terkadang disebut sebagai "perutean berbasis kebijakan", "pengalihan traffic", atau "Layanan Penerusan fungsi". {i>Service Steering<i} mencapai perutean transparan menggunakan Enkapsulasi Geneve + NSH (lihat RFC 8926, RFC 8300, Geneve + NSH IETF Draf).

Beberapa karakteristik penting dari Pengarahan Layanan antara lain:

  • Load balancing di seluruh Pod backend Fungsi Service: Service Fungsi sering kali berjalan di beberapa Pod untuk skalabilitas dan keandalan. Pengarahan Layanan mendistribusikan traffic jaringan yang masuk secara merata di seluruh jaringan ini Pod 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 tertentu traffic jaringan berdasarkan alamat IP sumber, port sumber, IP tujuan alamat, porta tujuan, dan protokol. Pengarahan Layanan memastikan bahwa semua paket dalam aliran yang sama secara konsisten diarahkan ke kumpulan Fungsi Layanan (hop).
  • Mengaktifkan jalur data pengembalian simetris: Jalur data pengembalian simetris berarti bahwa lalu lintas respons mengikuti jalur yang sama kembali ke sumber dengan traffic permintaan awal. Pengarahan Layanan memastikan ke simetri ini, yang adalah hal penting untuk beberapa protokol dan aplikasi jaringan.

Untuk setiap lalu lintas jaringan yang diarahkan layanan, perantara Pod Fungsi Layanan menangani semua paket traffic jaringan tertentu tersebut memastikan hop perantara yang konsisten dan rute yang dapat diprediksi. Layanan yang sama Pod Fungsi menerima traffic yang ditampilkan untuk memastikan aliran traffic yang simetris. Jika traffic asli dikirim ke tujuan dalam cluster yang sama, lalu lintas kembali secara otomatis menemukan jalan kembali melalui Rantai Layanan yang sama. Jika traffic asli berada di luar cluster, Fungsi Layanan akhir di menarik lalu lintas kembali ke dirinya sendiri menggunakan salah satu penerjemahan (SNAT) atau {i>proxy<i}, yang bertindak sebagai perantara.

Kasus penggunaan

Pengarahan Layanan GKE mengintegrasikan perutean berbasis kebijakan ke dalam klaster. Hal 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 generasi berikutnya (vNG-FW), dan sistem deteksi intrusi virtual (vIDS). Pengarahan Layanan memastikan bahwa lalu lintas dirutekan melalui CNF ini sebelum mencapai tujuan yang dimaksudkan, memberikan lapisan perlindungan dan kontrol.

Penyedia keamanan terkelola (MSP):

MSP dapat menggunakan GKE Service Steering untuk merutekan traffic Anda melalui Rantai Layanan keamanan berbasis {i>cloud<i} mereka. Hal ini memungkinkan mereka untuk menawarkan solusi keamanan komprehensif, termasuk Secure Web Gateways (SWG), SASE, (Secure Access Service Edge), dan SD-WAN (Software-Defined Wide Area Network) fungsionalitas.

Jaringan Telekomunikasi dan 5G:

Service Steering mengelola aliran traffic untuk berbagai fungsi jaringan di dalamnya telekomunikasi dan infrastruktur 5G. Anda dapat mengatur {i> router<i} virtual (vRouters), pengontrol batas sesi virtual (vSBC), dan fungsi jaringan inti 5G untuk memastikan pengelolaan traffic yang efisien, load balancing, dan penerapan kebijakan keamanan atau kualitas Layanan tertentu.

Cara kerja Pengarahan Layanan

Bagian ini menjelaskan cara kerja berbagai komponen Pengarahan Layanan.

Fungsi Layanan

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

  2. Memastikan afinitas alur: Pengarahan Layanan memastikan afinitas alur dengan mengarahkan semua paket dengan ID aliran yang sama melalui jalur Layanan yang sama Fungsi (SF).

  3. Memodifikasi paket untuk membuat alur baru: Jika Fungsi Layanan memodifikasi salah satu dari 5-tuple dalam sebuah paket. Misalnya, NAT mengubah sumber Alamat IP ini, ini akan membuat alur baru.

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

  5. Menangani proxy dan NAT sebagai dua alur: Traffic melalui proxy atau NAT dianggap sebagai dua alur terpisah: sumber ke {i>proxy<i}/NAT dan {i>proxy<i}/NAT ke tujuan. Pengarahan Layanan tidak menjamin jalur yang sama untuk keduanya {i>flow<i} (alur).

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

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

Koneksi yang ada

Saat Anda membuat TrafficSelector, Service Steering akan otomatis menerapkannya ke koneksi yang ada yang cocok dengan kriteria pemilih. Ini mengalihkan paket dari koneksi ini ke fungsi layanan yang sesuai. Layanan Function itu sendiri bertanggung jawab untuk mengelola koneksi saat terbang ini. J pendekatan umumnya adalah melepaskan paket dan mengandalkan klien untuk memulai koneksi jarak jauh, yang kemudian terintegrasi secara mulus ke dalam rantai layanan dari memulai.

Siklus proses resource

Resource TrafficSelector dan ServiceFunctionChain sudah dihapus segera setelah ditandai untuk dihapus. Tidak ada webhook atau finalis yang mencegah atau menunda penghapusan sumber daya.

Traffic Pod-to-Service

Pengarahan Layanan melakukan pemilihan traffic setelah menyelesaikan Layanan Alamat IP virtual. Lalu lintas 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 Virtual IP telah diselesaikan.

Penerapan NetworkPolicy

Pengarahan Layanan tidak mengabaikan NetworkPolicy. Kebijakan traffic keluar di sumber Kebijakan pod dan ingress di Pod tujuan masih berlaku untuk traffic yang dipilih untuk Pengarahan Layanan. Namun, hal tersebut tidak tunduk kepada penegakan NetworkPolicy traffic masuk atau keluar Fungsi Layanan. Hal ini karena traffic masuk atau aturan keluar NetworkPolicy telah ditetapkan dengan baik untuk sumber dan tujuan Pod, tetapi tidak untuk penerus paket.

Manfaat

Adopsi GKE Service Steering, yang disertai dengan transisi untuk teknologi berbasis cloud, memiliki manfaat berikut:

  • Penawaran Marketplace: Pihak Ketiga dapat menawarkan dalam container mereka di Google Cloud Marketplace dan menggunakan Service Steering API. Mereka dapat menyediakan panduan deployment berdasarkan API bawaan Kubernetes yang disediakan dan yang dikelola oleh GKE.
  • Perincian Kubernetes: Anda dapat mengontrol traffic dalam Kubernetes . Anda dapat mengklasifikasikan traffic yang ingin Anda arahkan. Anda dapat memilih workload di mana Anda ingin pengarahan Layanan diterapkan secara selektif.
  • Dua arah: Service Steering GKE bersifat dua arah. Ini berarti bahwa untuk alur tertentu, jalur yang ditampilkan simetris terhadap jalur maju. Hal ini penting dilakukan ketika Layanan Fungsi (SF) di-deploy sebagai sekelompok replika. Pastikan bahwa aliran yang sama melewati Replika kumpulan yang sama untuk mempertahankan stateful.
  • Dukungan Multi-Jaringan: Sebagian besar Fungsi Layanan memerlukan beberapa Antarmuka pod untuk pemisahan dataplane dari kontrol dan pengelolaan pesawat terbang. Beberapa Fungsi Layanan memiliki beberapa antarmuka sebagai bagian dari tentang arsitektur ini. Service Steering GKE mencakup integrasi dengan Multi-Jaringan di Pod. Dengan ini, pengguna dapat membuat {i>Service Steering<i} di Pod-Network tertentu.
  • Pengiriman Paket Mentah ke Aplikasi: Layanan GKE Steering mengenkapsulasi paket asli dan mengirimkannya ke Pod secara langsung. Dengan cara ini Anda tidak perlu melakukan dekapsulasi dan aplikasi dapat bertindak pada paket asli secara langsung.

Langkah selanjutnya