Kesadaran Service Mesh

Topik ini membahas service mesh, yaitu lapisan infrastruktur yang mengurus komunikasi antara service secara terpisah dari kode aplikasi. Lingkupnya mencakup cara kerja sidecar dan mTLS, pengaturan trafik pada lapisan mesh, posisi Istio dan Linkerd, serta pertimbangan kapan mesh sepadan dengan biayanya. Pembahasan bersifat konseptual karena pemasangan mesh menuntut sumber daya tambahan yang berada di luar lab lokal.

Lapisan yang ditambahkan service mesh#

Sebuah kluster yang tumbuh dari beberapa service menjadi puluhan service menghadapi masalah yang berulang pada setiap service, seperti enkripsi antara service, pengulangan permintaan yang gagal, dan pengukuran trafik. Menyelesaikannya di dalam kode setiap aplikasi berarti menyalin logika yang sama ke banyak bahasa dan banyak tim. Service mesh menjawab masalah itu dengan memindahkan pekerjaan tersebut ke lapisan infrastruktur yang terpisah dari kode.

Lapisan tersebut bekerja tanpa mengubah kode aplikasi. Setiap permintaan antara Pod diteruskan melalui proxy yang menyertai Pod, dan seluruh aturan enkripsi, pengulangan, serta pengukuran ditetapkan pada proxy tersebut. Aplikasi tetap berkomunikasi seperti biasa, sedangkan mesh memastikan setiap koneksi terenkripsi dan tercatat. Karena aturannya terpusat, kebijakan yang sama berlaku seragam pada seluruh service tanpa penyeragaman kode.

Fitur inti mesh dirangkum menjadi tiga kelompok, yaitu keamanan antara service melalui mTLS, pengaturan trafik seperti pembagian persentase dan pengulangan, serta observabilitas berupa metrik dan jejak trafik antara service. Tiga kelompok inilah yang dipertimbangkan pada penilaian apakah mesh sepadan atau tidak pada bagian akhir topik.

Sidecar proxy dan mTLS#

Bentuk penerapan mesh yang lazim adalah sidecar, yaitu container proxy tambahan yang ditempatkan di samping container aplikasi dalam Pod yang sama. Keduanya berbagi jaringan Pod, dan lalu lintas masuk maupun keluar aplikasi dialihkan melewati proxy. Kedua proxy pada Pod yang saling berkomunikasi kemudian membangun sambungan terenkripsi satu sama lain, sehingga aplikasi tidak pernah menangani pengaturan keamanan jaringannya sendiri.

Sambungan antara proxy menggunakan mTLS, yaitu TLS dua arah yang saling memverifikasi sertifikat kedua pihak sebelum data dikirim. Mesh menerbitkan sertifikat untuk setiap service account dan memutarnya secara otomatis, sehingga identitas setiap service terverifikasi tanpa pengurusan sertifikat manual. Akibatnya, trafik antara service terenkripsi secara bawaan bahkan pada jaringan yang tidak terpercaya, dan kebijakan yang menyebut identitas service dapat ditegakkan pada lapisan jaringan.

Overhead dari pola ini terletak pada sumber daya dan jeda. Setiap Pod membawa satu container tambahan yang mengonsumsi CPU dan memori, dan setiap permintaan melewati satu proxy tambahan. Pada kluster kecil, overhead tersebut terasa besar dibandingkan manfaatnya, sedangkan pada kluster dengan banyak service, biayanya tersebar ke banyak beban kerja.

Pengaturan trafik pada lapisan mesh#

Karena semua permintaan melewati proxy, mesh dapat menerapkan aturan pengaturan trafik secara seragam. Aturan yang lazim mencakup pembagian persentase trafik antara versi, pengulangan otomatis ketika permintaan gagal, batas waktu permintaan, dan pemutusan sirkuit ketika sebuah service menunjukkan kegagalan beruntun. Pada Istio, aturan dinyatakan sebagai objek CRD sendiri, misalnya VirtualService, sehingga perubahan penugasan trafik menjadi perubahan manifest yang dapat ditinjau di git.

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: catatan-api
spec:
  hosts:
    - catatan-api
  http:
    - route:
        - destination:
            host: catatan-api
            subset: v1
          weight: 90
        - destination:
            host: catatan-api
            subset: v2
          weight: 10

Aturan di atas mengirim 90 persen permintaan menuju versi v1 dan 10 persen menuju v2, pola yang lazim disebut rilis canary. Proxy yang menjalankan aturan ini tidak perlu diubah ketika persentase dinaikkan bertahap, karena perubahannya hanya berupa pembaruan manifest. Kemampuan serupa seperti pengulangan dan batas waktu ditulis pada aturan yang sama, sehingga kebijakan antara service terbaca pada satu tempat. Karena aturan berada di luar kode, penambahan versi baru tidak menuntut perubahan pada aplikasi yang berjalan, cukup pembaruan aturan pada lapisan mesh. Perubahan semacam itu dapat ditinjau di git dan dikembalikan apabila distribusi trafiknya tidak sesuai harapan.

Kapan mesh sepadan dan kapan tidak#

Keputusan memasang mesh pada dasarnya adalah keputusan biaya dan manfaat. Manfaat mesh tumbuh seiring jumlah service karena kebijakan ditulis satu kali dan berlaku seragam, sedangkan biayanya berupa container proxy per Pod, jeda pada setiap permintaan, dan kerumitan operasional lapisan tambahan yang ikut ditingkatkan versinya. Kluster dengan banyak service lintas tim memindahkan biaya tersebut ke banyak beban kerja, sehingga manfaatnya mudah melebihi biayanya.

Kluster kecil dengan dua atau tiga service biasanya belum membutuhkan mesh. Kebutuhan keamanan dapat dipenuhi dengan NetworkPolicy, metrik dapat dikelola per aplikasi, dan pengulangan permintaan dapat ditulis pada library client. Keputusan mesh juga tidak bersifat permanen, karena mesh dapat ditambahkan kemudian saat jumlah service bertambah, dan aturannya selalu berada di luar kode aplikasi.

Posisi Istio dan Linkerd#

Istio dan Linkerd adalah dua proyek open source yang paling sering disebut pada kategori mesh. Istio menonjol pada keluasan fitur, dengan banyak kelompok CRD pengaturan trafik dan keamanan, sehingga lazim dipilih pada kluster besar dengan kebijakan yang rumit. Linkerd menonjol pada ringannya jejak sumber daya dan sederhananya pengoperasian, sehingga lazim dipilih ketika kebutuhan mesh masih dasar.

Keduanya menerapkan model yang sama, yaitu proxy yang menyertai beban kerja dan kendali yang terpusat. Perbedaannya terletak pada keluasan fitur dan bobot komponen, bukan pada konsep dasar yang dijelaskan pada topik ini. Perbandingan yang lebih rinci antara alat mesh dapat ditelusuri pada CNCF Landscape yang tercantum pada referensi, karena peta ekosistem tersebut mengelompokkan proyek mesh beserta tingkat kematangannya.

Pertimbangan terakhir berada di luar daftar fitur, yaitu siapa yang mengoperasikan mesh. Lapisan tambahan ini perlu ditingkatkan versinya, dipantau, dan dipahami saat insiden, sehingga pemilihan alat juga menyangkut kemampuan tim pengelola kluster, bukan hanya keluasan fiturnya.

Ringkasan#

• Service mesh memindahkan enkripsi, pengaturan trafik, dan pengukuran komunikasi antara service ke lapisan infrastruktur yang terpisah dari kode aplikasi.
• Sidecar proxy pada setiap Pod meneruskan trafik dan membangun sambungan mTLS antara service, dengan identitas dan sertifikat yang dikelola mesh.
• Aturan trafik seperti pembagian persentase, pengulangan, dan batas waktu dinyatakan sebagai manifest pada lapisan mesh, contohnya VirtualService pada Istio.
• Mesh sepadan pada kluster dengan banyak service dan kebutuhan mTLS menyeluruh, sedangkan kluster kecil dapat memenuhi kebutuhan serupa dengan NetworkPolicy.

Referensi#

• Istio Documentation — Istio — Dokumentasi resmi Istio, mencakup konsep sidecar, mTLS, dan pengaturan trafik.
• Linkerd Documentation — Linkerd — Dokumentasi resmi Linkerd beserta panduan penerapan dan operasinya.
• CNCF Landscape — CNCF — Peta ekosistem cloud native yang mengelompokkan proyek service mesh beserta tingkat kematangannya.