Ambient Mesh: Pengertian, Cara Kerja, Arsitektur, Komponen, Manfaat, Kelebihan, Kekurangan, dan Implementasinya | Dewa234
Ambient Mesh: Pengertian, Cara Kerja, Arsitektur, Komponen, Manfaat, Kelebihan, Kekurangan, dan Implementasinya
Dalam arsitektur cloud-native modern, aplikasi Dewa234 biasanya terdiri dari banyak service yang saling berkomunikasi. Kubernetes dapat digunakan untuk menjalankan workload tersebut, sedangkan Service Mesh menyediakan berbagai kemampuan tambahan seperti traffic management, security, dan observability.
Pada pembahasan sebelumnya, Distributed Tracing digunakan untuk memahami perjalanan request melalui berbagai service. Sementara itu, Service Mesh menyediakan lapisan infrastruktur yang membantu mengatur komunikasi antar-service.
Seiring berkembangnya kebutuhan aplikasi cloud-native, pendekatan Service Mesh berbasis sidecar mulai memiliki alternatif arsitektur. Salah satunya adalah Ambient Mesh, yaitu model data plane Istio yang memisahkan fungsi Layer 4 dan Layer 7 sehingga workload tidak harus menjalankan proxy sidecar di dalam setiap Pod.
Dalam ambient mode, ztunnel berfungsi sebagai proxy Layer 4 yang berjalan per-node untuk secure overlay, sedangkan waypoint proxy dapat digunakan secara opsional ketika workload membutuhkan kemampuan Layer 7 seperti traffic management, authorization, dan telemetry yang lebih lengkap.
Apa Itu Ambient Mesh?
Ambient Mesh adalah pendekatan data plane pada Istio yang memungkinkan workload menggunakan kemampuan Service Mesh tanpa membutuhkan sidecar proxy di setiap Pod.
Pada model sidecar tradisional, setiap workload yang masuk ke mesh biasanya mendapatkan sebuah proxy Envoy yang berjalan berdampingan dengan container aplikasi. Proxy tersebut menangani traffic masuk dan keluar dari workload.
Ambient mode menggunakan pendekatan berlapis. Lapisan dasar menggunakan ztunnel untuk menangani fungsi Layer 4 seperti secure communication, mTLS, autentikasi, authorization Layer 4, dan telemetry. Jika diperlukan kemampuan Layer 7, traffic dapat diarahkan melalui waypoint proxy.
Dengan pendekatan tersebut, penggunaan Istio dapat dilakukan secara bertahap, mulai dari secure Layer 4 overlay hingga pemrosesan Layer 7 secara lebih lengkap. :contentReference[oaicite:1]{index=1}
Mengapa Ambient Mesh Dibutuhkan?
Service Mesh berbasis sidecar memberikan banyak kemampuan, tetapi setiap workload yang masuk ke mesh membutuhkan proxy tambahan. Pada cluster dengan jumlah Pod yang besar, jumlah proxy dapat meningkat secara signifikan.
Setiap proxy juga membutuhkan CPU, memory, konfigurasi, lifecycle management, dan monitoring. Ambient Mesh mencoba mengurangi kebutuhan tersebut dengan memisahkan fungsi data plane menjadi komponen yang dapat digunakan sesuai kebutuhan.
- Mengurangi kebutuhan sidecar proxy pada setiap Pod.
- Menyediakan secure communication antar-workload.
- Mendukung mutual TLS atau mTLS.
- Memisahkan fungsi Layer 4 dan Layer 7.
- Menyediakan kemampuan Layer 7 melalui waypoint proxy jika diperlukan.
- Mendukung penerapan Service Mesh secara bertahap.
- Menyediakan observability untuk traffic mesh.
Perbedaan Sidecar Mesh dan Ambient Mesh
| Aspek | Sidecar Mesh | Ambient Mesh |
|---|---|---|
| Proxy | Proxy berjalan sebagai sidecar di dalam Pod. | Proxy utama Layer 4 berjalan sebagai komponen per-node. |
| Layer 4 | Ditangani oleh sidecar proxy. | Ditangani oleh ztunnel. |
| Layer 7 | Dapat ditangani oleh sidecar Envoy. | Dapat ditangani oleh waypoint proxy. |
| mTLS | Dapat diterapkan melalui sidecar. | Dapat diterapkan melalui ztunnel dan secure overlay. |
| Deployment Proxy | Mengikuti jumlah workload. | ztunnel berjalan per-node dan waypoint digunakan sesuai kebutuhan. |
| Penerapan | Umumnya membutuhkan sidecar injection. | Dapat diaktifkan pada namespace atau workload menggunakan ambient mode. |
Konsep Dasar Ambient Mesh
Ada beberapa komponen dan konsep penting yang perlu dipahami sebelum menggunakan Ambient Mesh.
| Komponen | Fungsi |
|---|---|
| ztunnel | Proxy Layer 4 per-node yang menangani secure overlay, mTLS, autentikasi, authorization Layer 4, dan telemetry. |
| Waypoint Proxy | Proxy Layer 7 berbasis Envoy yang digunakan ketika workload membutuhkan fitur Layer 7. |
| Ambient Data Plane | Lapisan data plane Istio yang menyediakan fungsi mesh tanpa sidecar pada setiap workload. |
| HBONE | Mekanisme tunneling berbasis HTTP CONNECT yang digunakan dalam secure overlay ambient. |
| mTLS | Mengamankan komunikasi antar-workload dengan autentikasi dan enkripsi. |
| Istiod | Control plane yang menyediakan konfigurasi dan discovery untuk komponen data plane. |
Bagaimana Cara Kerja Ambient Mesh?
Ambient Mesh bekerja dengan membagi kemampuan Service Mesh menjadi dua lapisan utama. Lapisan pertama adalah secure Layer 4 overlay yang ditangani oleh ztunnel. Lapisan kedua adalah Layer 7 processing yang dapat diberikan oleh waypoint proxy.
- Workload berjalan pada Kubernetes.
- Namespace atau workload dimasukkan ke ambient mesh.
- Traffic workload diarahkan ke ztunnel pada node.
- ztunnel menangani komunikasi Layer 4.
- Traffic antar-workload dapat diamankan menggunakan mTLS.
- Jika workload membutuhkan fitur Layer 7, traffic dapat diteruskan menuju waypoint proxy.
- Waypoint proxy melakukan pemrosesan Layer 7 sesuai konfigurasi.
- Traffic kemudian diteruskan menuju tujuan.
- Telemetry dapat dikumpulkan untuk monitoring dan observability.
Istio menggunakan secure overlay dengan ztunnel untuk mengamankan dan mengarahkan traffic. Pada transport layer, mekanisme tersebut menggunakan protokol tunneling berbasis HTTP CONNECT yang disebut HBONE. :contentReference[oaicite:2]{index=2}
Ilustrasi Cara Kerja Ambient Mesh
Client
│
▼
Kubernetes
│
┌─────────┴─────────┐
▼ ▼
Workload A Workload B
│ │
▼ ▼
ztunnel ztunnel
│ │
└─────────┬─────────┘
│
Secure Overlay
│
▼
Waypoint Proxy
│
▼
Layer 7 Policy
│
▼
Destination
Arsitektur Ambient Mesh
+------------------------------------------------------+
| Kubernetes Cluster |
+------------------------------------------------------+
│
▼
+------------------------------------------------------+
| Ambient Data Plane |
+------------------------------------------------------+
│ │
▼ ▼
+-----------+ +-----------+
| ztunnel | | ztunnel |
| Node A | | Node B |
+-----------+ +-----------+
│ │
└────────────┬────────────┘
│
▼
Secure Overlay
HBONE
│
▼
+------------------+
| Waypoint Proxy |
| Layer 7 |
+------------------+
│
▼
Application
│
▼
Observability
Apa Itu ztunnel?
ztunnel atau Zero Trust Tunnel merupakan komponen penting dalam Ambient Mesh. Istio menjelaskan ztunnel sebagai proxy Layer 4 yang dirancang khusus untuk ambient data plane dan berjalan secara per-node.
ztunnel menangani fungsi seperti mTLS, autentikasi, authorization Layer 4, dan telemetry. ztunnel tidak dirancang untuk mengakhiri traffic HTTP aplikasi atau membaca header HTTP workload.
Dengan membatasi tanggung jawab pada Layer 3 dan Layer 4, ztunnel dapat menjadi komponen bersama pada node tanpa membutuhkan Envoy sidecar di setiap Pod. :contentReference[oaicite:3]{index=3}
Fungsi ztunnel
- Menangani secure Layer 4 overlay.
- Mendukung mTLS antar-workload.
- Mendukung autentikasi workload.
- Menerapkan authorization Layer 4.
- Menghasilkan telemetry Layer 4.
- Mengamankan dan meneruskan traffic antar-workload.
- Mengarahkan traffic menuju waypoint proxy ketika diperlukan.
Apa Itu Waypoint Proxy?
Waypoint Proxy adalah proxy Layer 7 berbasis Envoy yang digunakan dalam Ambient Mesh ketika workload membutuhkan fitur application layer.
Waypoint proxy berjalan di luar Pod aplikasi sehingga tidak menambahkan container proxy ke dalam workload. Waypoint dapat dipasang, di-upgrade, dan di-scale secara independen dari aplikasi.
Waypoint dibutuhkan untuk berbagai fitur Layer 7 seperti HTTP routing, load balancing, circuit breaking, rate limiting, fault injection, retries, timeout, authorization berbasis HTTP, HTTP metrics, access logging, dan tracing. :contentReference[oaicite:4]{index=4}
Perbedaan ztunnel dan Waypoint Proxy
| Aspek | ztunnel | Waypoint Proxy |
|---|---|---|
| Layer | Layer 3 dan Layer 4. | Layer 7. |
| Teknologi | Proxy khusus ambient. | Envoy Proxy. |
| mTLS | Ya. | Bekerja sebagai bagian dari arsitektur ambient. |
| HTTP Routing | Tidak menjadi fokus utama. | Ya. |
| HTTP Authorization | Tidak memproses atribut HTTP. | Ya. |
| Tracing | Telemetry Layer 4. | Mendukung observability Layer 7. |
| Kebutuhan | Komponen dasar ambient. | Opsional sesuai kebutuhan Layer 7. |
Ambient Mesh dan mTLS
Security merupakan salah satu manfaat penting Ambient Mesh. Dalam ambient mode, traffic TCP antar-workload dalam mesh dapat diamankan menggunakan mTLS melalui HBONE, ztunnel, dan sertifikat X.509.
Dengan mTLS, workload memiliki identitas yang digunakan untuk membangun koneksi terenkripsi. Hal tersebut membantu memastikan bahwa komunikasi antar-service tidak hanya mengandalkan jaringan internal sebagai batas keamanan.
Workload A
│
│ mTLS
▼
ztunnel
│
│ HBONE
▼
ztunnel
│
│ mTLS
▼
Workload B
Istio menjelaskan bahwa traffic L4 antar-workload dalam ambient mesh diamankan melalui mTLS menggunakan HBONE, ztunnel, dan sertifikat X.509. :contentReference[oaicite:5]{index=5}
Ambient Mesh dan Service Mesh
Ambient Mesh bukan teknologi yang terpisah dari konsep Service Mesh. Ambient merupakan salah satu pendekatan data plane Istio untuk menjalankan fungsi Service Mesh tanpa sidecar pada setiap workload.
Service Mesh secara umum menyediakan kemampuan seperti:
- Service-to-service communication.
- Security.
- mTLS.
- Authorization.
- Traffic management.
- Observability.
- Distributed tracing.
- Telemetry.
Ambient Mesh mengatur kemampuan tersebut dengan membaginya ke lapisan L4 dan L7.
Ambient Mesh dan Kubernetes
Ambient Mesh dirancang untuk lingkungan cloud-native dan sangat erat dengan Kubernetes. Workload dapat dimasukkan ke ambient mesh menggunakan label pada namespace atau workload.
Istio menggunakan label berikut untuk mengaktifkan ambient mode:
istio.io/dataplane-mode=ambient
Label tersebut dapat diterapkan pada namespace maupun workload tertentu. :contentReference[oaicite:6]{index=6}
Kubernetes Cluster
│
├── Namespace A
│ │
│ ├── Service A
│ └── Service B
│
├── Namespace B
│ │
│ ├── Service C
│ └── Service D
│
└── Ambient Mesh
│
├── ztunnel
└── Waypoint Proxy
Ambient Mesh dan Observability
Observability tetap menjadi bagian penting dalam Ambient Mesh. Administrator perlu mengetahui bagaimana traffic bergerak, apakah terjadi error, dan bagaimana latency antar-service.
Pada penggunaan ztunnel saja, telemetry yang tersedia terutama berupa metrics Layer 4. Ketika waypoint proxy digunakan, observability Layer 7 seperti HTTP metrics, access logging, dan tracing dapat tersedia sesuai konfigurasi. :contentReference[oaicite:7]{index=7}
| Observability | Fokus |
|---|---|
| Metrics L4 | Traffic TCP, koneksi, dan bytes. |
| HTTP Metrics | Informasi traffic application layer. |
| Access Logs | Detail request yang diproses proxy. |
| Tracing | Perjalanan request antar-service. |
Ambient Mesh dan Distributed Tracing
Distributed tracing yang dibahas pada artikel sebelumnya tetap relevan dalam Ambient Mesh. Namun, administrator perlu memahami bahwa kemampuan observability yang tersedia berbeda antara ztunnel dan waypoint.
Jika service hanya menggunakan secure L4 overlay, metrics yang tersedia berfokus pada traffic Layer 4. Untuk kebutuhan observability HTTP dan tracing yang lebih lengkap, waypoint proxy dapat digunakan.
Client │ ▼ Gateway │ ▼ Order Service │ ▼ ztunnel │ ▼ Waypoint Proxy │ ▼ Payment Service │ ▼ Database Tracing / Telemetry ├── Service ├── Waypoint └── Application Layer
Ambient Mesh dan Authorization Policy
Authorization Policy dapat digunakan untuk mengatur workload mana yang diperbolehkan berkomunikasi dengan workload lainnya.
Pada ambient mode, ztunnel dapat menerapkan policy Layer 4. Jika policy membutuhkan atribut Layer 7 seperti HTTP method, path, atau header, workload membutuhkan waypoint proxy agar policy dapat diproses pada application layer.
Hal ini penting diperhatikan ketika melakukan migrasi dari sidecar mode ke ambient mode karena policy berbasis L7 tidak dapat diperlakukan sama seperti policy L4. :contentReference[oaicite:8]{index=8}
Ambient Mesh untuk Traffic Management
Traffic management merupakan salah satu alasan utama penggunaan waypoint proxy. Waypoint dapat menangani fitur Layer 7 seperti HTTP routing, load balancing, retries, timeouts, circuit breaking, rate limiting, dan fault injection.
Request │ ▼ Service A │ ▼ ztunnel │ ▼ Waypoint Proxy │ ├────► Service B v1 │ └────► Service B v2
Dengan model tersebut, fungsi Layer 7 dapat diterapkan hanya pada workload yang membutuhkan fitur tersebut.
Ambient Mesh dan Gateway API
Ambient Mesh memiliki hubungan yang erat dengan Gateway API. Waypoint proxy sendiri dapat didefinisikan menggunakan resource Kubernetes Gateway API dengan GatewayClass istio-waypoint.
Artinya, Gateway API bukan hanya digunakan untuk traffic masuk ke aplikasi, tetapi juga menjadi bagian dari cara Istio mengelola waypoint proxy pada ambient mode. :contentReference[oaicite:9]{index=9}
External Client
│
▼
Gateway API
│
▼
Kubernetes Service
│
▼
Ambient Mesh
│
├── ztunnel
│
└── Waypoint Proxy
│
▼
Microservices
Manfaat Ambient Mesh
- Mengurangi kebutuhan sidecar proxy pada setiap Pod.
- Menyediakan secure communication antar-workload.
- Mendukung mTLS.
- Menyediakan keamanan Layer 4 melalui ztunnel.
- Mendukung fitur Layer 7 melalui waypoint proxy.
- Mendukung penerapan Service Mesh secara bertahap.
- Waypoint dapat digunakan bersama beberapa workload sesuai security boundary.
- Mendukung observability cloud-native.
- Dapat digunakan pada lingkungan microservices Kubernetes.
- Mengurangi kebutuhan menjalankan Envoy sidecar di setiap workload.
Kelebihan Ambient Mesh
- Tidak membutuhkan sidecar proxy pada setiap workload.
- Memisahkan fungsi Layer 4 dan Layer 7.
- ztunnel dirancang sebagai proxy per-node.
- Waypoint proxy dapat digunakan hanya ketika fitur Layer 7 dibutuhkan.
- Mendukung mTLS dan secure overlay.
- Dapat diterapkan secara bertahap.
- Workload sidecar dan ambient dapat hidup berdampingan dalam mesh.
- Waypoint dapat dikelola secara independen dari aplikasi.
Kekurangan Ambient Mesh
- Arsitekturnya membutuhkan pemahaman terhadap ztunnel dan waypoint.
- Fitur Layer 7 membutuhkan komponen tambahan.
- Debugging jalur traffic dapat menjadi lebih kompleks.
- Policy L4 dan L7 perlu dibedakan dengan baik.
- Perubahan arsitektur membutuhkan pengujian sebelum production.
- Observability perlu disesuaikan dengan lapisan data plane yang digunakan.
- Tim operasional perlu memahami interaksi antara Kubernetes, Istio, Gateway API, ztunnel, dan waypoint.
Instalasi Istio dengan Ambient Profile
Untuk mencoba Ambient Mesh, Istio menyediakan profile ambient. Instalasi menggunakan istioctl dapat dilakukan dengan perintah berikut.
istioctl install --set profile=ambient --skip-confirmation
Profile tersebut memasang komponen yang dibutuhkan untuk ambient mode, termasuk Istiod, Istio CNI, dan ztunnel. :contentReference[oaicite:10]{index=10}
Memeriksa Komponen Ambient
kubectl get pods -n istio-system
Administrator dapat menggunakan perintah tersebut untuk memeriksa komponen Istio yang berjalan pada namespace istio-system.
Memasukkan Namespace ke Ambient Mesh
Namespace dapat dimasukkan ke ambient mesh dengan menambahkan label berikut:
kubectl label namespace production istio.io/dataplane-mode=ambient
Setelah label diterapkan, workload pada namespace tersebut dapat menggunakan ambient data plane sesuai konfigurasi Istio yang digunakan. :contentReference[oaicite:11]{index=11}
Memeriksa Status Namespace
kubectl get namespace production --show-labels
Perintah tersebut membantu administrator memastikan bahwa label ambient telah diterapkan pada namespace.
Memeriksa Workload Ambient
istioctl ztunnel-config workloads -n istio-system
Perintah tersebut dapat digunakan untuk melihat informasi workload yang diketahui oleh ztunnel.
Membuat Waypoint Proxy
Jika workload membutuhkan fitur Layer 7, waypoint proxy dapat dibuat menggunakan istioctl.
istioctl waypoint apply -n production
Istio menggunakan Kubernetes Gateway API untuk mendefinisikan waypoint proxy. Waypoint yang dibuat akan dikelola oleh Istiod sebagai komponen data plane ambient. :contentReference[oaicite:12]{index=12}
Menghubungkan Namespace dengan Waypoint
Setelah waypoint tersedia, namespace dapat diarahkan untuk menggunakan waypoint dengan label berikut:
kubectl label namespace production istio.io/use-waypoint=waypoint
Dengan konfigurasi tersebut, workload ambient yang berkomunikasi menuju service pada namespace tersebut dapat menggunakan waypoint untuk pemrosesan Layer 7. :contentReference[oaicite:13]{index=13}
Memeriksa Waypoint
kubectl get gateway waypoint -n production
Status READY dapat digunakan untuk memastikan waypoint telah tersedia dan siap digunakan.
Contoh Alur Implementasi
1. Install Istio Ambient
│
▼
2. Enable Ambient Namespace
│
▼
3. ztunnel Menangani L4
│
▼
4. Aktifkan mTLS
│
▼
5. Deploy Waypoint jika perlu
│
▼
6. Gunakan L7 Policy
│
▼
7. Monitor Metrics / Logs / Traces
Best Practice Ambient Mesh
- Mulai dari namespace yang memiliki kebutuhan jelas.
- Pahami perbedaan L4 dan L7 sebelum membuat policy.
- Gunakan mTLS untuk mengamankan komunikasi antar-workload.
- Gunakan waypoint hanya ketika workload membutuhkan fitur Layer 7.
- Monitor resource ztunnel dan waypoint.
- Gunakan metrics, logs, dan tracing untuk observability.
- Uji policy pada staging sebelum production.
- Dokumentasikan namespace yang menggunakan ambient mode.
- Periksa kompatibilitas fitur dengan versi Istio yang digunakan.
- Gunakan migrasi bertahap jika berpindah dari sidecar mode.
Ambient Mesh untuk Microservices
Microservices dapat memiliki puluhan hingga ratusan service yang saling berkomunikasi. Pada skala tersebut, penggunaan proxy sidecar pada setiap Pod dapat menambah jumlah komponen yang harus dikelola.
Ambient Mesh memberikan pendekatan berbeda dengan menempatkan fungsi dasar pada ztunnel dan menyediakan waypoint hanya untuk workload yang membutuhkan kemampuan Layer 7.
Microservices
│
├── User Service
├── Product Service
├── Order Service
├── Payment Service
└── Inventory Service
│
▼
Ambient Mesh
│
┌─────┴─────┐
▼ ▼
ztunnel Waypoint
│ │
▼ ▼
L4 Security L7 Policy
Ambient Mesh dan High Availability
Ambient Mesh dapat menjadi bagian dari arsitektur cloud-native yang membutuhkan availability tinggi. Namun, Ambient Mesh sendiri bukan pengganti strategi High Availability.
High Availability tetap membutuhkan desain Kubernetes yang baik, termasuk replica workload, distribusi Pod, node availability, resource management, monitoring, dan recovery strategy.
Ambient Mesh membantu menyediakan lapisan komunikasi dan security, sedangkan availability keseluruhan tetap bergantung pada desain infrastruktur dan aplikasi.
Ambient Mesh dan DevOps
Dalam workflow DevOps, konfigurasi Ambient Mesh dapat menjadi bagian dari proses deployment infrastructure dan aplikasi.
Konfigurasi namespace, waypoint, policy, dan routing dapat dikelola sebagai bagian dari infrastructure as code sehingga perubahan dapat ditinjau, diuji, dan dilacak.
Setelah deployment, metrics, logs, dan tracing dapat digunakan untuk memantau perubahan latency, error, dan perilaku traffic.
Ambient Mesh dan CI/CD
Ambient Mesh juga dapat mendukung proses CI/CD dengan menyediakan observability dan security setelah deployment.
Contohnya, setelah versi baru aplikasi dirilis, tim dapat memeriksa apakah terdapat peningkatan latency, error rate, atau perubahan perilaku traffic.
Jika workload menggunakan waypoint, observability Layer 7 dapat membantu memberikan informasi yang lebih detail mengenai request HTTP.
Ambient Mesh dan Security Zero Trust
Konsep keamanan Ambient Mesh berkaitan erat dengan pendekatan Zero Trust. Komunikasi antar-workload tidak hanya mengandalkan posisi service di jaringan internal, tetapi dapat diamankan dengan identitas workload dan mTLS.
Workload A
│
│ Identity
▼
ztunnel
│
│ mTLS / HBONE
▼
ztunnel
│
│ Identity
▼
Workload B
Security
├── Authentication
├── Encryption
├── Authorization
└── Telemetry
Perbedaan Ambient Mesh dan Gateway API
| Aspek | Ambient Mesh | Gateway API |
|---|---|---|
| Fokus | Komunikasi dan security antar-workload. | Traffic routing dan gateway. |
| Komponen | ztunnel dan waypoint proxy. | Gateway, HTTPRoute, dan resource Gateway API lainnya. |
| Layer | L4 dan L7. | Traffic application dan gateway. |
| mTLS | Bagian penting secure overlay. | Bukan fokus utama. |
| Use Case | Service-to-service communication. | Traffic entry dan routing. |
Alur Lengkap Ambient Mesh
Internet
│
▼
Gateway API
│
▼
Kubernetes
│
▼
Ambient Mesh
│
┌─────────┴─────────┐
▼ ▼
Workload A Workload B
│ │
▼ ▼
ztunnel ztunnel
│ │
└─────────┬─────────┘
│
mTLS / HBONE
│
▼
Waypoint Proxy
│
┌─────────┼─────────┐
▼ ▼ ▼
Routing Security Policy
│
▼
Observability
│
┌─────────┼─────────┐
▼ ▼ ▼
Metrics Logs Tracing
Contoh Kasus Penggunaan Ambient Mesh
Misalnya sebuah perusahaan memiliki aplikasi e-commerce yang terdiri dari User Service, Product Service, Order Service, Inventory Service, dan Payment Service.
Administrator ingin semua komunikasi antar-service menggunakan mTLS, tetapi hanya beberapa service yang membutuhkan routing HTTP dan authorization berbasis request.
Dengan Ambient Mesh, kebutuhan tersebut dapat dipisahkan. Semua workload dapat menggunakan secure L4 overlay melalui ztunnel, sedangkan service yang membutuhkan pemrosesan L7 dapat diarahkan melalui waypoint proxy.
E-Commerce
│
├── User Service
│ └── ztunnel
│
├── Product Service
│ └── ztunnel
│
├── Order Service
│ ├── ztunnel
│ └── Waypoint
│
└── Payment Service
├── ztunnel
└── Waypoint
L4 Security
+
L7 Traffic Management
+
Observability
Tantangan Implementasi Ambient Mesh
- Memahami perbedaan arsitektur sidecar dan ambient.
- Memahami batas kemampuan L4 dan L7.
- Menentukan workload yang membutuhkan waypoint.
- Memastikan policy L4 dan L7 diterapkan pada komponen yang tepat.
- Memahami jalur traffic melalui ztunnel dan waypoint.
- Melakukan monitoring terhadap komponen data plane.
- Memastikan konfigurasi kompatibel dengan versi Istio.
Baca Juga
Untuk artikel seperti Gateway API, Linkerd, Telemetry Istio, AuthorizationPolicy, RequestAuthentication, PeerAuthentication, dan mTLS, tambahkan URL artikel Anda yang sudah aktif pada bagian ini setelah slug Blogger diverifikasi.
Artikel Selanjutnya
Setelah memahami Ambient Mesh, pembahasan berikutnya dapat dilanjutkan lebih spesifik ke Waypoint Proxy. Topik tersebut akan memperdalam bagaimana proxy Layer 7 digunakan dalam Ambient Mesh untuk menangani traffic management, security policy, dan observability.
Alur pembahasan dapat dilanjutkan menjadi:
Gateway API
│
▼
Ambient Mesh
│
├── ztunnel
│ ├── L4
│ ├── mTLS
│ └── Secure Overlay
│
└── Waypoint Proxy
│
├── L7 Routing
├── Authorization
├── Telemetry
└── Observability
Pertanyaan yang Sering Diajukan (FAQ)
Apa itu Ambient Mesh?
Ambient Mesh adalah pendekatan data plane Istio yang memungkinkan workload menggunakan kemampuan Service Mesh tanpa membutuhkan sidecar proxy pada setiap Pod.
Apa itu ztunnel?
ztunnel adalah proxy Layer 4 per-node yang digunakan oleh Istio ambient mode untuk secure overlay, mTLS, autentikasi, authorization Layer 4, dan telemetry.
Apa itu Waypoint Proxy?
Waypoint Proxy adalah proxy Layer 7 berbasis Envoy yang digunakan ketika workload membutuhkan fitur application layer seperti HTTP routing, authorization, telemetry, dan traffic management.
Apa perbedaan Ambient Mesh dengan Service Mesh berbasis sidecar?
Service Mesh berbasis sidecar menjalankan proxy pada setiap workload, sedangkan Ambient Mesh menggunakan ztunnel sebagai proxy Layer 4 per-node dan waypoint proxy secara opsional untuk Layer 7.
Apakah Ambient Mesh menggunakan mTLS?
Ya. Ambient mode menggunakan mTLS sebagai bagian dari secure communication antar-workload melalui ztunnel dan HBONE. :contentReference[oaicite:14]{index=14}
Apakah semua workload membutuhkan Waypoint Proxy?
Tidak. Workload yang hanya membutuhkan secure Layer 4 overlay dapat menggunakan ztunnel. Waypoint diperlukan ketika workload membutuhkan fitur Layer 7 seperti HTTP routing, L7 authorization, dan observability HTTP. :contentReference[oaicite:15]{index=15}
Apakah Ambient Mesh membutuhkan Kubernetes?
Implementasi Ambient Mesh dalam artikel ini menggunakan lingkungan Kubernetes dan komponen Istio yang terintegrasi dengan Kubernetes.
Apakah Ambient Mesh sama dengan Istio?
Tidak. Istio adalah platform Service Mesh, sedangkan Ambient Mesh adalah salah satu mode data plane Istio yang menggunakan pendekatan tanpa sidecar pada setiap workload.
Apakah Ambient Mesh menggantikan Gateway API?
Tidak. Gateway API dan Ambient Mesh memiliki fokus berbeda. Gateway API digunakan untuk mendefinisikan dan mengelola traffic gateway, sedangkan Ambient Mesh menangani komunikasi dan security antar-workload. Gateway API juga digunakan untuk mendefinisikan waypoint proxy pada Istio ambient mode. :contentReference[oaicite:16]{index=16}
Apakah Ambient Mesh cocok untuk microservices?
Ya. Ambient Mesh dirancang untuk lingkungan cloud-native dan dapat digunakan untuk mengamankan serta mengelola komunikasi antar-workload pada arsitektur microservices Kubernetes.
Apakah Ambient Mesh menghilangkan semua proxy?
Tidak. Ambient Mesh menghilangkan kebutuhan sidecar proxy pada setiap workload, tetapi tetap menggunakan ztunnel sebagai proxy Layer 4 per-node dan dapat menggunakan waypoint proxy untuk fitur Layer 7.
Apakah ztunnel memproses HTTP?
Tidak sebagai fungsi utamanya. ztunnel dirancang untuk Layer 3 dan Layer 4 serta tidak mengakhiri workload HTTP atau membaca header HTTP. Pemrosesan Layer 7 dilakukan oleh waypoint proxy ketika diperlukan. :contentReference[oaicite:17]{index=17}
Kesimpulan
Ambient Mesh merupakan pendekatan data plane Service Mesh pada Istio yang dirancang untuk menyediakan kemampuan mesh tanpa mengharuskan sidecar proxy berada di setiap Pod.
Konsep utamanya adalah pemisahan kemampuan berdasarkan layer. ztunnel menjadi komponen dasar pada Layer 4 yang menangani secure overlay, mTLS, autentikasi, authorization Layer 4, dan telemetry. Sementara itu, waypoint proxy digunakan secara opsional ketika workload membutuhkan fitur Layer 7.
Pendekatan tersebut memungkinkan organisasi menerapkan Service Mesh secara lebih bertahap. Workload dapat dimulai dengan secure Layer 4 overlay, kemudian mendapatkan kemampuan Layer 7 ketika memang dibutuhkan. Istio juga memungkinkan workload dengan sidecar mode dan ambient mode hidup berdampingan dalam mesh yang sama. :contentReference[oaicite:18]{index=18}
Ambient Mesh juga memiliki hubungan erat dengan Kubernetes, mTLS, Gateway API, Service Mesh, observability, dan distributed tracing. Gateway API dapat digunakan untuk mendefinisikan waypoint proxy, sementara ztunnel dan waypoint menangani kebutuhan data plane pada layer yang berbeda. :contentReference[oaicite:19]{index=19}
Walaupun memiliki berbagai kelebihan, implementasi Ambient Mesh tetap membutuhkan perencanaan. Administrator perlu memahami perbedaan L4 dan L7, menentukan workload yang membutuhkan waypoint, mengatur authorization policy, memantau ztunnel dan waypoint, serta memastikan konfigurasi sesuai dengan versi Istio yang digunakan.
Dengan memahami Ambient Mesh, pembahasan mengenai Service Mesh menjadi semakin lengkap. Setelah mempelajari Ingress Gateway, Egress Gateway, ServiceEntry, mTLS, PeerAuthentication, RequestAuthentication, AuthorizationPolicy, Telemetry, Distributed Tracing, Linkerd, dan Gateway API, Ambient Mesh menjadi langkah lanjutan untuk memahami pendekatan Service Mesh modern tanpa sidecar.
