Belajar GitOps dengan ArgoCD - Service Mesh Integration

#Pendahuluan

Di episode 19 sebelumnya kita membahas progressive delivery dengan Argo Rollouts, dan beberapa kali menyebut service mesh sebagai mekanisme traffic splitting — khususnya untuk canary berbasis header dan A/B testing. Pada episode ini kita membedah lapisan itu: apa itu service mesh, bagaimana Istio bekerja, dan — yang paling penting bagi kalian — bagaimana mengelola seluruh konfigurasi mesh secara GitOps dengan ArgoCD.

Mengapa topik ini penting? Begitu arsitektur kalian bertumbuh dari belasan menjadi ratusan service, dua masalah muncul bersamaan: trafik antar service tidak terlihat (error di mana? lambatnya di hop mana?) dan komunikasi antar service tidak dipercaya (siapa boleh bicara ke siapa?). Service mesh menjawab keduanya lewat sidecar proxy yang menyelinap di antara service — dan karena seluruh konfigurasi mesh hanyalah manifest Kubernetes biasa, ia menjadi kandidat sempurna untuk dikelola GitOps.

#Gambaran Service Mesh

Service mesh menaruh proxy (biasanya sidecar) di samping setiap pod. Semua trafik masuk dan keluar lewat proxy, sehingga mesh punya kendali penuh tanpa mengubah kode aplikasi. Tiga opsi utama di ekosistem:

Pilihan di antara ketiganya sering ditentukan oleh kurva belajar: Istio paling kuat namun paling berat; Linkerd adalah keseimbangan terbaik untuk tim kecil; Consul menarik ketika kalian juga butuh service discovery di luar Kubernetes. Prinsip GitOps yang akan kita bahas tetap sama untuk semuanya.

#Istio + ArgoCD

Istio memperkenalkan beberapa resource kustom yang menjadi titik kendali trafik dan keamanan. Karena semuanya hanyalah YAML, ArgoCD bisa mengelola istio-system (control plane) dan resource per-aplikasi secara terpisah.

#Mengelola Resource Istio lewat Git

Tiga resource utama yang paling sering kalian kelola:

• Gateway — pintu masuk mesh: port, host, dan TLS yang dibuka di edge.
• VirtualService — routing: ke mana trafik dengan host dan path tertentu diarahkan, termasuk weight dan header.
• DestinationRule — kebijakan tujuan: subset, load balancing, connection pool, dan mTLS.

Semuanya disimpan di Git dan diterapkan sebagai Application biasa:

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: api-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 443
        name: https
        protocol: HTTPS
      tls:
        mode: SIMPLE
        credentialName: api-tls
      hosts:
        - api.org.dev
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: api
spec:
  hosts:
    - api.org.dev
  gateways:
    - istio-system/api-gateway
  http:
    - route:
        - destination:
            host: api
            subset: stable
          weight: 100
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: api
spec:
  host: api
  subsets:
    - name: stable
      labels:
        version: v1
    - name: canary
      labels:
        version: v2

Perhatikan bagaimana VirtualService merujuk subset: stable dan subset: canary yang didefinisikan DestinationRule. Ini adalah titik di mana Argo Rollouts (episode 19) menyuntikkan weight canary: ia menulis ulang weight pada VirtualService sesuai langkah promosi, sementara ArgoCD tetap menjaga seluruh resource sinkron dengan Git.

#Traffic Splitting untuk Canary

Ketika versi v2 diluncurkan, VirtualService berubah menjadi split 90-10. Argo Rollouts bisa melakukan ini otomatis dengan menambahkan istio ke bagian trafficRouting pada Rollout:

Rollout dengan trafficRouting Istio

spec:
  strategy:
    canary:
      trafficRouting:
        managedRoutes:
          - name: canary
        istio:
          virtualService:
            name: api
            routes:
              - primary
      steps:
        - setWeight: 10
        - pause: {duration: 5m}

Rollout akan mengelola weight pada route primary di VirtualService secara langsung — tanpa manusia, tanpa script. ArgoCD memastikan resource ada di cluster; Rollout menggerakkan trafik di dalamnya.

#Observability dengan Mesh

Keuntungan terbesar service mesh bagi operasional adalah observabilitas yang "gratis". Karena setiap hop melewati Envoy, mesh tahu persis jalur yang ditempuh setiap request.

#Distributed Tracing

Envoy menyuntikkan header tracing ke setiap request; Jaeger atau Tempo menggabungkannya menjadi satu jejak end-to-end:

for i in $(seq 1 100); do
  curl -s http://api.org.dev/hello -o /dev/null
done

Dari jejak, kalian melihat waktu yang dihabiskan di setiap hop: gateway, api, auth, sampai database. Ini mengubah debugging dari "mencoba-coba" menjadi memeriksa satu peta. Di GitOps, konfigurasi sampling tracing juga bagian dari manifest — misalnya MeshConfig Istio disimpan di repo istio-system.

#Metrik dan Service Graph

Kiali (pendamping Istio) menampilkan service graph: node adalah service, sisi adalah komunikasi, warna menunjukkan error dan latensi. Metrik yang sama bisa dialirkan ke Prometheus untuk analisis Rollout (episode 19) dan dasbor Grafana (episode 22). Semua ini membaca metrik Envoy — yang dinyalakan cukup dengan MeshConfig di Git.

#Security Policies

Service mesh juga merupakan alat keamanan. Dua fitur inti:

#mTLS

Dengan PeerAuthentication bersifat MESH_WIDE, semua trafik antar service terenkripsi dan saling dipercaya via mTLS — tanpa mengubah kode:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT

Mode STRICT memaksa semua komunikasi dalam namespace memakai mTLS. Ini menghilangkan kelas serangan "eavesdropping antar pod" yang biasanya tidak mungkin dideteksi.

#Authorization Policies

AuthorizationPolicy menentukan siapa boleh berbicara ke siapa — kontrol akses di tingkat jaringan:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: api-allow-frontend
spec:
  selector:
    matchLabels:
      app: api
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - cluster.local/ns/frontend/sa/frontend
      to:
        - operation:
            methods: ["GET", "POST"]

Karena PeerAuthentication dan AuthorizationPolicy adalah manifest biasa, keduanya bisa dimasukkan ke Application ArgoCD yang sama dengan aplikasi yang dilindungi, atau ke project khusus security yang hanya boleh diubah oleh platform team (konsep dari episode 10).

#Penutup

Episode ini menghubungkan service mesh dengan GitOps: perbandingan Istio, Linkerd, dan Consul Connect; pengelolaan Gateway, VirtualService, dan DestinationRule sebagai manifest; traffic splitting canary dengan trafficRouting Istio di Argo Rollouts; observability lewat tracing, metrik, dan service graph; serta kebijakan keamanan mTLS dan authorization yang semuanya didorong dari Git.

Poin yang harus kalian bawa:

• Service mesh memberi kontrol trafik dan keamanan tanpa mengubah kode aplikasi.
• Seluruh konfigurasi mesh adalah manifest Kubernetes yang dikelola ArgoCD.
• VirtualService dan DestinationRule menjadi tempat Argo Rollouts menyuntikkan weight canary.
• Tracing dan metrik Envoy membuat observability end-to-end menjadi gratis.
• mTLS dan AuthorizationPolicy diterapkan dengan alur pull request, bukan akses ad hoc.

Sekarang arsitektur sudah tangguh dan bisa menggelar versi baru dengan aman. Namun ada satu hal yang sering dilupakan sampai bencana terjadi: bagaimana kalau seluruh cluster hilang? Di episode 21 selanjutnya kita membahas disaster recovery & backup — strategi backup ArgoCD, prosedur pemulihan cluster, DR multi-cluster, dan pengujian RTO/RPO. Sampai jumpa di episode 21!