Belajar HAProxy - HAProxy on Kubernetes & Container Environments

#Pendahuluan

HAProxy lahir sebagai daemon Linux, tapi ekosistem modern memintanya hidup dalam container dan di bawah orkestrasi Kubernetes. Episode 19 menjembatani keduanya.

Kalian akan melihat tiga pola deployment, memahami posisi ingress controller, dan belajar menyimpan konfigurasi serta rahasia sebagai objek Kubernetes. Di akhir episode, kalian bisa menjalankan HAProxy di klaster dengan keyakinan penuh.

#Pola Deployment di Kubernetes

#Deployment: HAProxy sebagai Service Berstatus

Pola paling umum: menjalankan HAProxy sebagai Deployment yang dikelola ReplicaSet:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: haproxy-edge
spec:
  replicas: 2
  selector:
    matchLabels:
      app: haproxy
  template:
    metadata:
      labels:
        app: haproxy
    spec:
      containers:
        - name: haproxy
          image: haproxy:2.9-alpine
          volumeMounts:
            - name: config
              mountPath: /usr/local/etc/haproxy
      volumes:
        - name: config
          configMap:
            name: haproxy-config

kind: Deployment memberi kalian replika, rolling update, dan self-healing. Volume config me-mount ConfigMap haproxy-config ke direktori konfigurasi. Deployment ini lalu dihubungkan ke dunia luar lewat Service bertipe LoadBalancer.

#DaemonSet: Satu Pod di Setiap Node

Untuk routing berbasis node, DaemonSet menempatkan satu pod HAProxy di setiap node:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: haproxy-node
spec:
  template:
    metadata:
      labels:
        app: haproxy-node
    spec:
      hostNetwork: true
      containers:
        - name: haproxy
          image: haproxy:2.9-alpine

hostNetwork: true membuat pod memakai network namespace node, sehingga bind port HAProxy langsung terlihat di IP node. Pola ini dipakai arsitektur yang ingin melewati Service layer.

#Sidecar: HAProxy di Samping Aplikasi

Sebagai sidecar, HAProxy berbagi pod dengan aplikasi dan menjadi proksi lokal: aplikasi bisa di-proxy lewat localhost. Cukup tambahkan container kedua dengan argumen yang mengganti titik konfigurasi default:

containers:
  - name: app
    image: myapp:v1
  - name: haproxy-sidecar
    image: haproxy:2.9-alpine
    args: ["-f", "/etc/haproxy/haproxy.cfg"]
    volumeMounts:
      - name: config
        mountPath: /etc/haproxy

#Ingress Controller vs Standalone

#Ingress Controller HAProxy

Ekosistem HAProxy menyediakan ingress controller resmi yang mengelola konfigurasi dari objek Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  ingressClassName: haproxy
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-svc
                port: 8080

Objek Ingress di atas otomatis diterjemahkan ingress controller menjadi konfigurasi HAProxy. Kalian tidak perlu menulis haproxy.cfg manual lagi. Meski begitu, HAProxy standalone tetap unggul saat kalian butuh kontrol penuh atas setiap direktif atau sudah punya pipeline konfigurasi sendiri — pilihannya bergantung pada berapa banyak kendali yang mau diserahkan ke controller.

#Mengelola Konfigurasi dengan ConfigMap dan Secrets

#Konfigurasi di ConfigMap

Seluruh haproxy.cfg disimpan sebagai ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: haproxy-config
data:
  haproxy.cfg: |
    global
        log stdout format raw local0
    defaults
        mode http
        timeout server 30s
    frontend web
        bind *:80
        default_backend app
    backend app
        server s1 10.0.0.11:8080 check

Direktif log stdout format raw local0 mengarahkan log ke stdout agar bisa ditangkap kubectl logs — praktik standar untuk aplikasi container.

#Rahasia di Secrets

Data sensitif seperti sertifikat TLS disimpan sebagai Secret:

kubectl create secret generic haproxy-secrets \
  --from-file=tls=fullchain.pem

kubectl create secret generic haproxy-secrets membuat Secret berisi sertifikat TLS, lalu di-mount sebagai file:

volumes:
  - name: tls
    secret:
      secretName: haproxy-secrets

Mount berubah menjadi file yang bisa dirujuk di direktif crt. Sertifikat tidak pernah menginjak git atau image.

Saat ConfigMap diperbarui, file di pod berubah, tapi proses HAProxy tidak otomatis reload. Pola umum: sidecar reloader yang memantau file, atau restart deployment:

#Penutup

Episode 19 menjembatani HAProxy dengan Kubernetes: pola deployment yang fleksibel, ingress controller untuk otomasi penuh, dan penyimpanan konfigurasi serta rahasia yang sesuai praktik cloud native.

Inti yang harus dibawa pulang:

• Deployment untuk replika dan rolling update; DaemonSet untuk satu pod per node.
• Sidecar menjadikan HAProxy proksi lokal bagi aplikasi.
• Ingress controller menerjemahkan objek Ingress menjadi konfigurasi.
• ConfigMap menyimpan konfigurasi; Secret menyimpan data sensitif.
• Log ke stdout agar mudah dibaca dengan kubectl logs.

Di episode 20 selanjutnya kita akan membahas CI/CD & configuration management — memvalidasi konfigurasi HAProxy di pipeline, deployment otomatis dan strategi rollout, serta pengujian perubahan konfigurasi sebelum menyentuh produksi.