Belajar Apache Kafka - Deployment Kubernetes dengan Strimzi

#Pendahuluan

Menjalankan Kafka di Kubernetes secara manual — StatefulSet, service, secret TLS, dan rolling update — adalah pekerjaan yang rawan kesalahan. Strimzi menghadirkan Kubernetes Operator yang mengotomatiskan semuanya: kalian mendeskripsikan cluster dengan Custom Resource, dan operator mewujudkannya beserta operasi pemeliharaannya.

Episode 28 ini akan membahas pola operator dan CRD, resource utama Strimzi (Kafka, KafkaConnect, KafkaUser), cara kerja StatefulSet dan storage, manajemen TLS dan ACL otomatis, serta pertimbangan produksi seperti anti-affinity, storage class, dan multi-zone.

#Strimzi Kafka Operator

#Kubernetes Operator Pattern

Operator adalah aplikasi yang menangani siklus hidup resource kustom: ia memantau deklarasi (CRD), mewujudkannya menjadi resource K8s, dan terus menyelaraskan keadaan aktual dengan yang diinginkan. Strimzi berisi beberapa operator: Cluster Operator (broker, Connect, MirrorMaker), Topic Operator (topic), dan User Operator (user dan ACL).

#CRDs Strimzi

Resource utama yang kalian tulis:

• Kafka: mendefinisikan cluster — broker, controller, storage, dan listener.
• KafkaConnect: cluster worker Kafka Connect.
• KafkaTopic: definisi topic secara deklaratif.
• KafkaUser: user dan ACL-nya.
• KafkaBridge: jembatan REST untuk klien non-Kafka.

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    replicas: 3
    version: 3.7.1
    storage:
      type: persistent-claim
      size: 100Gi
    listeners:
      - name: tls
        port: 9093
        type: internal
        tls: true

spec.kafka.replicas: 3 mendeklarasikan tiga broker, dan storage: persistent-claim meminta PersistentVolume per pod. Operator menciptakan StatefulSet, service, dan secret sesuai deklarasi ini.

#Deployment di K8s

#StatefulSets untuk Broker

Broker Kafka berjalan sebagai StatefulSet karena setiap pod membutuhkan identitas stabil (nama pod = identitas broker) dan storage terpisah. Strimzi membuat satu pod per broker dengan volume sendiri. Rolling update dilakukan satu per satu oleh operator — broker tidak pernah turun bersamaan.

#PersistentVolume Management

Storage dideklarasikan per cluster:

storage:
  type: persistent-claim
  size: 100Gi
  class: gp3
  deleteClaim: false

class: gp3 memilih storage class (misalnya EBS gp3 di AWS); deleteClaim: false menjaga volume tetap ada saat cluster dihapus — mencegah kehilangan data accidental. Pilih storage class dengan IOPS yang cukup untuk tulis Kafka.

#Service dan Configuration

Strimzi membuat service untuk akses broker: satu service untuk komunikasi internal antar pod, dan satu per listener untuk klien. Konfigurasi broker (misalnya log segment, retention) ditentukan dalam spec.kafka.config. Kredensial dan sertifikat TLS disimpan sebagai Secrets yang di-mount otomatis ke pod broker.

#Fitur Strimzi

#Rolling Updates dan TLS Automation

Operator menangani rolling update saat versi broker atau konfigurasi berubah, termasuk pemeliharaan partition selama proses. Yang paling berharga: manajemen TLS otomatis — Strimzi membuat CA, menerbitkan dan merotasi sertifikat untuk broker dan klien, sehingga kalian tidak perlu mengelola sertifikat manual seperti di episode 18.

#User dan ACL via CRD

Kontrol akses dideklarasikan, bukan dengan CLI:

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: app-producer
spec:
  authentication:
    type: tls
  authorization:
    type: simple
    acls:
      - resource:
          type: topic
          name: orders
          patternType: literal
        operation: Write

authentication.type: tls memberi user sertifikat untuk mutual TLS, dan authorization.acls menggantikan kafka-acls.sh — operator menerapkan ACL ke cluster secara otomatis.

#Monitoring dan Cruise Control

Strimzi mengekspos metrik untuk Prometheus (episode 22) dan bisa mengintegrasikan Cruise Control (episode 20) untuk rebalancing otomatis — keduanya cukup diaktifkan lewat deklarasi CRD.

#Pertimbangan Produksi

#Pod Anti-Affinity

Satu broker per node fisik agar kegagalan node tidak merobohkan beberapa broker sekaligus:

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - topologyKey: kubernetes.io/hostname
        labelSelector:
          matchLabels:
            strimzi.io/name: my-cluster-kafka

podAntiAffinity mencegah dua pod broker dijadwalkan di node yang sama. Kombinasikan dengan topology.kubernetes.io/zone untuk menyebar broker lintas AZ (rack awareness, episode 24).

#Storage Class, Network Policy, dan Multi-Zone

• Storage class: pilih penyedia volume yang menawarkan IOPS konsisten (gp3, io2) untuk produksi.
• Network policies: batasi akses jaringan antar namespace; hanya pod aplikasi tertentu yang boleh menjangkau listener broker.
• Multi-zone: gunakan topology spread constraints dan broker.rack berbasis label zone agar replica tersebar antar AZ.
• Disaster recovery: pikirkan MirrorMaker dan pemulihan volume; backup volume berkala untuk protection tambahan.

#Penutup

Di episode 28 ini kalian sudah memahami deployment Kafka di Kubernetes dengan Strimzi: pola operator dan CRD, StatefulSet dan storage, TLS dan user management otomatis, serta pertimbangan produksi seperti anti-affinity, storage class, dan multi-zone.

Inti yang harus dibawa pulang:

• Strimzi mengotomatiskan lifecycle Kafka lewat CRD dan operator.
• Broker berjalan sebagai StatefulSet dengan PersistentVolume per pod.
• Strimzi mengelola CA, sertifikat, user, dan ACL secara otomatis.
• deleteClaim: false mencegah kehilangan data saat cluster dihapus.
• Anti-affinity menyebar broker ke node dan zone berbeda.
• Monitoring dan Cruise Control diaktifkan lewat deklarasi CRD.

Di episode 29 selanjutnya kita akan membahas Docker dan container best practices — image resmi dan Confluent, Docker Compose untuk multi-broker dengan Schema Registry dan ksqlDB, serta pertimbangan JVM, memori, health check, dan volume dalam container.