:Ikhtisar

Deskripsi Fitur

Service Mesh (ASM) versi 1.18 atau lebih tinggi mendukung mode Ambient Mesh. Ambient Mesh memperkenalkan data plane tanpa sidecar untuk menyederhanakan integrasi aplikasi dengan service mesh, memberikan pengguna cara menggunakan service mesh secara bertahap, serta mengurangi biaya infrastruktur bagi pengguna Istio.

Ambient Mesh mendukung data plane baik dengan maupun tanpa sidecar. Anda dapat menggunakan salah satu atau keduanya sesuai kebutuhan aplikasi. Pada instance ASM versi 1.18, proxy sidecar mendukung HTTP-Based Overlay Network Environment (HBONE). Oleh karena itu, proxy sidecar tersebut dapat bekerja sama dengan aplikasi tanpa sidecar menggunakan tunnel zero-trust (ztunnels) atau waypoint proxies. Dalam beberapa kasus, ztunnels dan waypoint proxies digunakan bersama-sama. Ztunnels menyediakan lapisan overlay yang aman, sementara waypoint proxies menyediakan kemampuan pemrosesan Lapisan 7.

Filosofi Desain

Ambient Mesh membagi data plane menjadi dua lapisan berbeda: Lapisan 4 dan Lapisan 7. Pemrosesan dasar dilakukan di Lapisan 4, yang menampilkan efisiensi tinggi dan konsumsi sumber daya lebih sedikit. Fitur lanjutan untuk menangani trafik disediakan di Lapisan 7, yang memerlukan lebih banyak sumber daya. Anda dapat mengadopsi teknologi service mesh secara bertahap tergantung pada fitur yang dibutuhkan.

Dalam mode Ambient Mesh, proxy Lapisan 4 (juga disebut ztunnels) dan proxy Lapisan 7 (juga disebut waypoint proxies) dipisahkan. Kemampuan proxy Lapisan 4 diimplementasikan menggunakan plugin Container Network Interface (CNI). Proxy Lapisan 4 berjalan sebagai DaemonSet di setiap node, artinya proxy Lapisan 4 adalah komponen yang dibagi dan menyediakan layanan untuk semua pod yang berjalan di node yang sama.

Proxy Lapisan 7 tidak lagi diterapkan sebagai sidecar, melainkan sebagai pod per-service-account untuk pemrosesan Lapisan 7.

Konfigurasi proxy Lapisan 4 dan Lapisan 7 tetap dikelola oleh komponen control plane ASM. Pemisahan proxy Lapisan 4 dan Lapisan 7 memungkinkan pemisahan lebih lanjut antara aplikasi dan data plane ASM.

Implementasi Ambient Mesh dalam Istio melibatkan tiga bagian berikut:

• Waypoint proxy:

  • Komponen Lapisan 7 yang dipisahkan dari aplikasi, meningkatkan keamanan.

  • Waypoint proxy spesifik disediakan untuk setiap identitas (service account di Kubernetes), menghindari kompleksitas dan ketidakstabilan yang diperkenalkan oleh mode proxy Lapisan 7 multi-penyewa.

  • Waypoint proxy diaktifkan dengan mengonfigurasi CustomResourceDefinition (CRD) gateway Kubernetes.

• Ztunnel: Ztunnel mengimplementasikan pemrosesan Lapisan 4 menggunakan plugin CNI. Trafik dari workload dialihkan ke ztunnel yang sesuai, yang kemudian mengidentifikasi workload dan memilih sertifikat yang sesuai untuk pemrosesan trafik.

• Kompatibilitas dengan sidecar: Data plane dengan proxy sidecar yang dikonfigurasikan masih paling banyak digunakan oleh pengguna saat mereka menggunakan service mesh. Waypoint proxies dapat berkomunikasi dengan workloads di mana proxy sidecar diterapkan.

Dalam mode tradisional, Anda harus menyuntikkan proxy sidecar ke setiap aplikasi. Namun, dalam mode Ambient Mesh, Anda tidak perlu menerapkan ulang atau memodifikasi aplikasi yang ada. Oleh karena itu, Ambient Mesh kurang invasif dibandingkan mode tradisional. Kurangnya invasivitas membantu mengurangi risiko implementasi dan menyederhanakan penggunaan Ambient Mesh.

Ambient Mesh bersifat non-invasif. Dalam mode Ambient Mesh, Anda dapat menambahkan aplikasi ke service mesh dengan menambahkan label tertentu ke namespace tempat aplikasi berada. Setelah aplikasi ditambahkan ke service mesh dalam mode Ambient Mesh, metode mutual transport layer security (mTLS) dan fitur observabilitas yang disediakan oleh Lapisan 4 tersedia untuk aplikasi tersebut.

Routing dalam Mode Ambient Mesh

Dalam mode Ambient Mesh, workload dapat dibagi menjadi tiga kategori berikut:

• Tidak Ditangkap: Pod standar di mana tidak ada fitur mesh yang diaktifkan.

• Ditangkap: Pod di mana trafik diintercept oleh ztunnel. Pod dapat ditangkap dengan menambahkan label istio.io/dataplane-mode=ambient ke namespaces.

• Diaktifkan Waypoint: Pod di mana trafik diintercept oleh ztunnel dan waypoint proxy diterapkan. Secara default, waypoint proxy dibagikan oleh semua pod di namespace yang sama. Anda juga dapat menentukan bahwa waypoint proxy didedikasikan untuk service account tertentu dengan menambahkan anotasi istio.io/for-service-account dalam CRD gateway Kubernetes. Jika baik waypoint proxy spesifik namespace maupun spesifik service account dikonfigurasikan, waypoint proxy spesifik service account akan diutamakan.

Routing Ztunnel

• Arah Keluar

  Ketika aplikasi dalam pod yang ditangkap memulai permintaan arah keluar, permintaan tersebut dialihkan secara transparan ke ztunnel node tempat pod berjalan. Kemudian, ztunnel memilih metode untuk meneruskan permintaan dan tujuan untuk permintaan tersebut. Secara umum, perilaku routing trafik mirip dengan routing trafik default di Kubernetes. Untuk permintaan ke Service di Kubernetes, permintaan dikirim ke endpoint dalam Service. Namun, permintaan ke alamat IP pod langsung dikirim ke alamat IP tersebut. Perilaku routing permintaan bervariasi dengan kemampuan tujuan permintaan. Jika tujuan permintaan juga ditangkap atau memiliki kemampuan Istio proxy (misalnya, proxy sidecar atau Istio gateway diterapkan), permintaan dirutekan menggunakan tunnel HBONE terenkripsi. Jika tujuan memiliki waypoint proxy, selain dirutekan menggunakan tunnel HBONE terenkripsi, permintaan diteruskan ke waypoint proxy tersebut.

  Catatan bahwa ketika permintaan dibuat ke Service, ztunnel pod dari mana permintaan dimulai memilih pod untuk memeriksa apakah waypoint proxy dikonfigurasikan untuk pod tersebut. Jika waypoint proxy dikonfigurasikan untuk pod yang dipilih, permintaan dikirim ke waypoint proxy. Kemudian, waypoint proxy mengirim permintaan ke tujuan. Ini memungkinkan waypoint proxy untuk menerapkan kebijakan berorientasi layanan ke trafik. Untuk sebuah Service, jika waypoint proxy diaktifkan untuk sebagian tetapi tidak semua pod, beberapa permintaan dikirim ke waypoint proxy sementara permintaan lain ke Service yang sama tidak.

• Arah Masuk

  Ketika pod yang ditangkap menerima permintaan arah masuk, permintaan tersebut dialihkan secara transparan ke ztunnel pod. Ketika ztunnel menerima permintaan, ztunnel menerapkan kebijakan otorisasi dan hanya meneruskan permintaan jika permintaan sesuai dengan kebijakan. Pod dapat menerima trafik yang sesuai dengan HBONE atau trafik teks biasa. Secara default, ztunnels akan menerima kedua jenis trafik ini. Karena permintaan teks biasa tidak memiliki identitas peer ketika kebijakan otorisasi dievaluasi, Anda dapat mengonfigurasi kebijakan yang memerlukan identitas (identitas apa pun atau yang spesifik) untuk memblokir semua trafik teks biasa.

  Ketika waypoint proxy diaktifkan untuk tujuan, semua permintaan harus melewati waypoint proxy di mana kebijakan dijalankan. Ztunnel yang sesuai akan memastikan hal ini terjadi. Namun, kasus batas berikut ada: Klien HBONE yang berperilaku baik, seperti ztunnel lain atau Istio sidecar, mengetahui bahwa permintaan harus dikirim ke waypoint proxy, tetapi klien lain seperti workload di luar mesh tidak mengetahui apa pun tentang waypoint proxy dan mengirim permintaan langsung ke pod tujuan. Untuk panggilan langsung semacam itu, ztunnel akan mengirim permintaan yang diterima ke waypoint proxy miliknya sendiri untuk memastikan bahwa kebijakan dijalankan dengan benar.

Routing Waypoint

Waypoint proxy hanya menerima permintaan HBONE. Setelah menerima permintaan, waypoint proxy akan memastikan bahwa tujuan permintaan adalah pod yang dikelolanya atau Service yang berisi pod yang dikelolanya.

Untuk kedua jenis permintaan, waypoint proxy akan menegakkan kebijakan, seperti AuthorizationPolicy, WasmPlugin, dan Telemetry, sebelum meneruskan permintaan.

Untuk permintaan langsung ke pod, permintaan tersebut cukup diteruskan langsung setelah kebijakan diterapkan.

Untuk permintaan ke Service, waypoint proxy juga menerapkan routing dan load balancing. Secara default, Service cukup merutekan trafik ke dirinya sendiri dan melakukan load balancing di antara endpointnya. Anda dapat menimpa perilaku default dengan mengonfigurasi rute untuk Service ini.

Perbedaan dari Arsitektur Sidecar

• Dalam mode Ambient Mesh, kemampuan pemrosesan Lapisan 4 dan Lapisan 7 dipisahkan. Ztunnels berbasis Rust diperkenalkan untuk pemrosesan Lapisan 4. Ztunnels dapat berfungsi sebagai proxy jaringan berperforma tinggi yang mengonsumsi sedikit sumber daya.

• Waypoint proxies berorientasi tujuan. Konfigurasi waypoint proxy hanya perlu berisi informasi tentang cluster dinamis terbatas, endpoint, dan rute yang perlu dihubungkan oleh waypoint proxy, bukan detail semua Service dalam kluster tempat waypoint proxy berjalan. Ini secara efektif menghilangkan kebutuhan untuk mendukung sumber daya sidecar untuk waypoint proxies. Anda tidak perlu mengonfigurasi sumber daya sidecar secara manual.

Manfaat Ambient Mesh

• Proxy mesh berjalan independen dari aplikasi. Saat proxy diperbarui atau di-restart, Anda tidak perlu me-restart aplikasi.

• Ini memperluas dukungan untuk aplikasi, termasuk dukungan untuk Kubernetes Jobs.

• Ambient Mesh menghilangkan persyaratan untuk aplikasi dalam arsitektur sidecar, termasuk batasan untuk protokol server-first.

• Dalam mode Ambient Mesh, Anda dapat mengadopsi teknologi mesh secara bertahap. Misalnya, Anda dapat menggunakan lapisan overlay yang aman pada tahap awal untuk mengimplementasikan mTLS, kebijakan otorisasi Lapisan 4 yang sederhana, dan fitur observabilitas.

• Jika pemrosesan Lapisan 7 tidak diperlukan, lapisan overlay yang aman dapat secara signifikan mengurangi permukaan serangan dan frekuensi pembaruan data plane untuk kerentanan umum dan eksposur (CVE) serta patch lainnya.

• Ambient Mesh memungkinkan Anda menskalakan data plane secara independen dari workload Anda, yang mengurangi biaya infrastruktur.