Belajar Microservices - Service Mesh (Istio/Linkerd) & mTLS
Mengenal service mesh untuk policy yang seragam lintas layanan: membandingkan Istio dan Linkerd, menerapkan mTLS agar komunikasi antar service terenkripsi dan saling percaya, dan memanfaatkan sidecar untuk observability tracing dan metrics otomatis
#Pendahuluan
Setelah tokokita hidup di Kubernetes (episode 17), muncul pertanyaan yang sangat natural: "bagaimana cara mengamankan, membatasi, dan memantau komunikasi antar 7 layanan secara konsisten?" Menerapkan retry, timeout, mTLS, rate-limit, dan tracing satu per satu di setiap service adalah pekerjaan yang besar dan mudah tidak konsisten. Di sinilah service mesh datang.
Namun — penting untuk jujur sejak awal: microservices tokokita (7 layanan) tidak membutuhkan service mesh. Episode ini menjelaskan kapan kebutuhan itu menjadi nyata, membandingkan dua produk utama, dan memahami mekanisme kerjanya — dengan wawasan yang akan terpakai saat kalian menangani sistem dengan puluhan hingga ratusan layanan.
#Kapan Perlu Service Mesh?
Service mesh menyelesaikan masalah uniform policy di lebih dari satu cara:
- mTLS konsisten — semua layanan saling percaya & terenkripsi tanpa tulis-tulis kode per layanan.
- Retry, timeout, circuit breaker deklaratif — sudah ada di code kita (episode 11), tapi tiap service menulis sendiri; mesh memusatkannya.
- Traffic management — canary, weight-based routing antar versi (bagus untuk episode 23).
- Observability — tracing dan metrics per-hop otomatis dari sidecar.
Biayanya nyata: sisi data plane (sidecar proxy per pod) dan control plane menghabiskan CPU/memori, serta menambah lapisan kompleksitas operasional.
1-10 service → kode langsung (retry/timeout/mTLS manual cukup)
10-50+ service → policy makin sulit konsisten → mesh mulai bernilai
50-500+ service → mesh hampir wajib (mTLS + tracing seragam)Note
Aturan praktis yang jujur: jangan pasang service mesh di lab kecil untuk "belajar" saja — biayanya tidak sebanding. Di tokokita kita sudah punya retry/timeout/circuit breaker di kode (episode 11). Service mesh baru mengganas kala tim mulai menulis logika resiliensi yang sama berulang-ulang di puluhan layanan. Untuk lab, cukup pahami konsep; implementasinya di sini bersifat demonstrasi.
#Istio vs Linkerd
#Istio: Fitur Penuh
- Sidecar: Envoy proxy di tiap pod.
- Fitur: VirtualService/DestinationRule (traffic routing), AuthorizationPolicy (RBAC L7), mTLS automate via PeerAuthentication, observability dengan Kiali.
- Kelebihan: kemampuan routing & policy terbesar di ekosistem.
- Kekurangan: berat (banyak komponen), learning curve tinggi, resource lebih besar.
#Linkerd: Ringan, Fokus Reliabilitas
- Sidecar: micro-proxy (linkerd2-proxy) yang ditulis khusus, bukan Envoy.
- Fitur: mTLS otomatis (default ON), retry/timeout deklaratif, golden metrics per-service, dashboard ringan.
- Kelebihan: sangat performa & hemat resource, setup simpel (1 manifest), bisa di-install via
linkerd install. - Kekurangan: fitur traffic routing & policy lebih sempit dari Istio.
| Aspek | Istio | Linkerd |
|---|---|---|
| Proxy | Envoy | linkerd2-proxy (custom) |
| Resource | Berat | Ringan |
| mTLS | Ya (PeerAuthentication) | Ya (default ON) |
| Traffic routing | Sangat kaya | Terbatas |
| Policy L7 | AuthorizationPolicy | ServerAuthorization |
| Kelebihan | Fitur lengkap | Simple & cepat |
#mTLS: Kepercayaan Internal Antar Service
mTLS (Mutual TLS) artinya dua arah: client memverifikasi sertifikat server, dan server memverifikasi sertifikat client. Di microservices, inilah bentuk machine identity — bukan sekadar identitas user. Semua komunikasi antar layanan terenkripsi dan saling otentikasi, walau berada dalam cluster yang sama.
Pada service mesh, mTLS umumnya otomatis: control plane menerbitkan sertifikat per-pod (SPIFFE ID), sidecar menandatangani dan memverifikasi tiap koneksi. Kalian tidak menulis kode — cukup konfigurasi:
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: default
namespace: tokokita
spec:
mtls:
mode: STRICT # semua traffic dalam namespace wajib mTLS# mTLS menyala otomatis segera setelah komponen mesh terpasang;
# verifikasi dengan `linkerd check --proxy`Tanpa mesh sekalipun, mTLS bisa dibuat manual (mTLS dengan cert-manager + jaringan service), tapi konsistensinya sulit — itulah justru pekerjaan yang "dimaikan" mesh.
#Observability via Mesh
Salah satu nilai tak terduga mesh: tracing dan metrics per-hop otomatis. Sidecar Envoy/Linkerd melakukan dua hal tanpa perubahan kode aplikasi:
- Propagasi trace — menyebarkan header
traceparentantar service (meski service tidak pakai SDK, hop tetap tercatat). - Metrics matriks — untuk tiap hop: request rate, error rate, latency percentile — langsung ke Prometheus.
istio_requests_total (source/destination)
linkerd_request_total, linkerd_response_latency_ms
→ dipakai dashboard: total request per service, error rate, p99 latencyDengan mesh, "mana yang lambat?" bisa dijawab per hop lintas cluster tanpa mengubah layanan sama sekali — komplementer dengan OpenTelemetry yang kita bahas di episode 20 (SDK level) vs mesh (wire level).
#Penutup
Episode 18 memperkenalkan service mesh dengan jujur:
- Kapan: saat policy resiliensi/mTLS sulit dijaga konsisten di 10+ layanan; bukan untuk lab kecil.
- Istio (Envoy, fitur penuh: routing, AuthorizationPolicy, Kiali) vs Linkerd (ringan, mTLS default, fokus reliability).
- mTLS: machine identity antar layanan; otomatis via sidecar; SPIFFE ID per pod.
- Observability via mesh: metrics + tracing per-hop otomatis tanpa ubah aplikasi — komplementer dengan Otel SDK.
Di episode 19 selanjutnya, kita memperdalam keamanan microservices (zero trust) — validasi JWT di gateway, rate limiting token bucket pada login, pengelolaan secrets dengan Vault/External Secrets Operator, NetworkPolicy, supply chain security (Trivy, cosign), dan perlindungan PII. Sampai jumpa di episode 19!