Belajar GitOps - FluxCD - Integrasi Service Mesh (Istio, Linkerd, AWS App Mesh)

#Pendahuluan

Di episode 17 kalian sudah mempelajari blue/green dan A/B testing dengan Flagger — trafik dipecah ke dua versi aplikasi, diuji, lalu dipromosikan. Saat itu Flagger menangani routing, tapi ada pertanyaan tersisa: ke mana trafik dialirkan dan bagaimana observasi koneksi antar service, retry, timeout, hingga mTLS dikelola? Jawabannya adalah service mesh.

Episode ini membahas integrasi service mesh dengan FluxCD. Kuncinya: mesh adalah aplikasi Kubernetes biasa — operator, CRD, dan control plane — sehingga ia bisa diinstal dan dikonfigurasi sepenuhnya lewat Git. Artinya seluruh kebijakan routing dan telemetry ikut di-versioning seperti manifest lain.

#Mengapa Service Mesh

Service mesh adalah lapisan infrastruktur untuk komunikasi antar service. Setiap pod diberi sidecar proxy yang menyadap trafik masuk dan keluar, sehingga aplikasi tidak perlu tahu cara retry, load balancing, TLS, atau observability. Dua komponen utamanya:

Data plane: kumpulan proxy (Envoy pada Istio, linkerd-proxy pada Linkerd) yang memindahkan trafik.
Control plane: komponen yang membaca kebijakan dan menyebarkannya ke proxy (istiod, linkerd control plane).

Aspek	Istio	Linkerd	AWS App Mesh
Model	Open source, self-hosted	Open source, ringan	Terkelola AWS
Fitur	Kaya (traffic, mTLS, observability)	Sederhana dan fokus	Native AWS, X-Ray
Instalasi	Beberapa chart	Dua file manifest	AWS CLI + controller
Metrics	Prometheus	Prometheus (addon viz)	CloudWatch
Weight routing	VirtualService	TrafficSplit (SMI)	VirtualRouter

#Integrasi Istio

Instalasi Istio paling GitOps-friendly lewat chart resmi istio-base, istiod, dan gateway, yang dideklarasikan sebagai HelmRepository dan HelmRelease. Dengan enablePrometheusMerge: true, metrik mesh otomatis masuk pipeline Prometheus.

Tip

Urutan instalasi penting: istio-base (CRD) dulu, lalu istiod, lalu gateway. Atur dengan dependsOn pada Kustomization seperti di episode 10, atau pakai dependsOn pada HelmRelease.

Setelah chart masuk, aktifkan sidecar injection dengan label istio-injection: enabled pada namespace, dan routing dideklarasikan lewat VirtualService (ke mana trafik per host dialirkan) serta DestinationRule (policy seperti mTLS dan load balancing per subset):

clusters/prod/apps/api/virtualservice.yaml

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: api
  namespace: apps
spec:
  hosts:
    - api.apps.svc.cluster.local
  http:
    - route:
        - destination:
            host: api
            subset: stable
          weight: 90
        - destination:
            host: api
            subset: canary
          weight: 10
---
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: api
  namespace: apps
spec:
  host: api
  subsets:
    - name: stable
      labels:
        version: stable
    - name: canary
      labels:
        version: canary
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

Important

Flagger (episode 15-17) mendukung Istio dan justru mengelola VirtualService serta DestinationRule ini secara otomatis untuk canary. Timbangan 90/10 di atas adalah contoh yang bisa dihasilkan Flagger. Aktifkan enablePrometheusMerge: true agar metrik mesh masuk pipeline observability.

Verifikasi cepat instalasi memakai CLI:

Verifikasi instalasi dan sidecar

istioctl version
istioctl proxy-status
istioctl analyze --namespace apps

#Integrasi Linkerd

Linkerd jauh lebih ringan. Manifest instalasinya bisa di-generate dan di-commit langsung ke Git:

Generate manifest Linkerd

linkerd install --crds > install/linkerd/crds.yaml
linkerd install > install/linkerd/control-plane.yaml

FluxCD cukup menunjuk satu Kustomization ke folder install/linkerd. Ini contoh paling langsung dari "mesh sebagai kode" — murni YAML dari repo, tanpa installer interaktif.

Linkerd memakai ServiceProfile untuk menggambarkan API sebuah service dan TrafficSplit untuk membagi trafik antar versi di level service:

clusters/prod/apps/api/trafficsplit.yaml

apiVersion: split.smi-spec.io/v1alpha2
kind: TrafficSplit
metadata:
  name: api
  namespace: apps
spec:
  service: api
  backends:
    - service: api-stable
      weight: 900m
    - service: api-canary
      weight: 100m

Untuk observability, tambahkan addon linkerd-viz sebagai HelmRelease. Dashboard bisa diakses lewat linkerd viz dashboard, dan linkerd viz top deploy/api menampilkan latensi real-time per deployment.

#Integrasi AWS App Mesh

Di AWS, App Mesh menawarkan mesh terkelola: control plane dipegang AWS, proxy tetap Envoy di dalam cluster. Setup dimulai dari mesh dan virtual node yang di-deploy FluxCD:

clusters/prod/appmesh/mesh.yaml

apiVersion: appmesh.k8s.aws/v1beta2
kind: Mesh
metadata:
  name: dev-null-mesh
spec:
  namespaceSelector:
    matchLabels:
      mesh: dev-null
---
apiVersion: appmesh.k8s.aws/v1beta2
kind: VirtualNode
metadata:
  name: api
  namespace: apps
spec:
  meshName: dev-null-mesh
  listeners:
    - portMapping:
        port: 8080
        protocol: http
  backends:
    - virtualService:
        virtualServiceName: orders.apps.svc.cluster.local

Router dan route configuration menentukan kemana trafik menuju:

clusters/prod/appmesh/router.yaml

apiVersion: appmesh.k8s.aws/v1beta2
kind: VirtualRouter
metadata:
  name: api-router
  namespace: apps
spec:
  meshName: dev-null-mesh
  listeners:
    - portMapping:
        port: 8080
        protocol: http
  routes:
    - name: api-route
      httpRoute:
        match:
          prefix: /
        action:
          weightedTargets:
            - virtualNodeName: api
              weight: 100

Tip

App Mesh cocok untuk organisasi yang sudah hidup di ekosistem AWS: metrik otomatis masuk CloudWatch dengan dimensi meshName dan virtualNodeName, tracing terintegrasi AWS X-Ray, dan IAM mengontrol siapa yang boleh mengubah mesh.

#Observability Multi-Mesh

Mesh tanpa observability hanya menambah kompleksitas. Empat lapisan yang perlu dipikirkan:

Distributed tracing: Istio berintegrasi dengan Jaeger, Linkerd dengan OpenTelemetry, App Mesh dengan X-Ray. Trace menghubungkan request lintas service sehingga root cause ditemukan tanpa menebak.
Service graphs: Kiali untuk Istio, "tap" dan dashboard viz untuk Linkerd. Keduanya menunjukkan siapa bicara ke siapa.
Metrics dashboards: semua mesh meng-expose metrik Prometheus. Dashboard Grafana juga di-versioning di Git dan disinkronkan FluxCD.
Canary analysis visualization: saat canary berjalan, bandingkan latensi dan error rate kedua subset langsung di dashboard — keputusan promotion jadi berbasis data.

#Penutup

Episode ini menunjukkan bahwa service mesh bukan sesuatu yang terpisah dari GitOps — mesh hanyalah aplikasi Kubernetes lain yang diinstal dan dikonfigurasi lewat Git. Kita membahas instalasi Istio dengan HelmRelease, otomatisasi VirtualService dan DestinationRule, Linkerd yang ringan dengan TrafficSplit, AWS App Mesh dengan virtual node dan router, serta observability berupa tracing, service graphs, dan dashboards.

Inti yang harus dibawa pulang:

Mesh sebagai kode: instalasi dan kebijakan mesh dideklarasikan di Git, FluxCD yang menyinkronkannya.
Pilih sesuai kebutuhan: Istio untuk fitur kaya, Linkerd untuk kesederhanaan, App Mesh untuk yang tinggal di AWS.
Traffic management ter-versioning: VirtualService, TrafficSplit, dan route config ikut di-review lewat pull request.
Observability wajib: tanpa tracing dan metrik, keputusan canary tidak punya dasar.
Flagger berjalan di atas mesh: canary analysis episode 15-17 memakai VirtualService atau TrafficSplit sebagai mekanisme routing.

Dengan mesh, trafik kini bisa diatur halus — tetapi ini membuka permukaan serangan baru. Di episode 19 selanjutnya kita membahas securing Flux: autentikasi, RBAC, network security, hingga supply chain security dengan Cosign dan admission controller. Sampai jumpa di episode 19!