Affinity dan Anti-Affinity

Secara sederhana, affinity dan anti-affinity adalah aturan yang Anda berikan kepada Kubernetes untuk menentukan di mana sebuah Pod harus (atau tidak boleh) ditempatkan.

Pikirkan ini seperti memberi "preferensi" pada Pod Anda:

  • Affinity (Atraksi): "Saya ingin Pod ini ditempatkan dekat dengan..."

  • Anti-Affinity (Repulsi): "Saya ingin Pod ini ditempatkan jauh dari..."

Ini adalah alat yang sangat penting untuk mengontrol ketersediaan tinggi (High Availability), performa, dan biaya.

Ada dua jenis utama:

  1. Node Affinity: Aturan tentang Node.

  2. Pod Affinity / Anti-Affinity: Aturan tentang Pod lain.

Mari kita bahas satu per satu.

1. Node Affinity (Atraksi ke Node)

Konsep: "Tempatkan Pod ini pada Node yang memiliki label tertentu."

Ini adalah cara Anda memberi tahu Pod untuk berjalan di server fisik (Node) yang spesifik.

Kapan digunakan?

  • Hardware Khusus: "Aplikasi machine learning ini harus berjalan di Node yang memiliki GPU."

  • Lokasi Geografis: "Pod ini sebaiknya berjalan di Node yang ada di zona us-east-1a untuk latensi rendah."

  • Performa Storage: "Tempatkan Pod database ini di Node yang menggunakan SSD."

Contoh: Anda memiliki beberapa server. Anda memberi label hardware=gpu pada server yang memiliki kartu grafis. Dengan Node Affinity, Anda bisa memaksa Pod TensorFlow Anda untuk hanya berjalan di server-server tersebut.

2. Pod Affinity (Atraksi antar Pod)

Konsep: "Tempatkan Pod ini di Node yang sudah menjalankan Pod lain dengan label tertentu."

Ini adalah tentang co-location (menempatkan Pod berdekatan).

Kapan digunakan?

  • Performa Tinggi: Ini adalah kasus penggunaan utamanya.

  • Contoh: Anda memiliki aplikasi web (frontend) dan cache (redis). Untuk komunikasi yang super cepat dan latensi minimal, Anda ingin keduanya selalu berada di server fisik yang sama.

  • Aturan: Anda akan memberi tahu Pod frontend: "Temukan Node di mana Pod dengan label app=redis sedang berjalan, dan jalankan saya di sana juga."

3. Pod Anti-Affinity (Repulsi antar Pod)

Konsep: "JANGAN tempatkan Pod ini di Node yang sudah menjalankan Pod lain dengan label tertentu."

Ini adalah kebalikan dari Pod Affinity dan sangat penting untuk High Availability (HA).

Kapan digunakan?

  • High Availability (HA): Ini adalah kasus penggunaan paling umum dan paling penting.

  • Contoh: Anda menjalankan 3 replika dari api-server Anda. Jika Kubernetes menempatkan ketiganya di satu Node yang sama, dan Node itu mati (misalnya, hardware failure), seluruh layanan Anda akan mati.

  • Aturan: Anda memberi tahu Kubernetes: "Untuk setiap replika api-server baru, JANGAN pernah tempatkan di Node yang sudah menjalankan Pod lain dengan label app=api-server."

  • Hasil: Kubernetes akan menyebar 3 Pod Anda ke 3 Node fisik yang berbeda. Jika satu Node mati, Anda masih memiliki 2 Pod lain yang berjalan dan layanan Anda tetap hidup.

Aturan "Keras" vs. "Lunak"

Baik Affinity maupun Anti-Affinity memiliki dua mode aturan yang harus Anda pahami:

  1. Hard Rule (requiredDuringScheduling...)

    • Artinya: "HARUS". Ini adalah aturan yang kaku.

    • Scheduler Kubernetes wajib mematuhi aturan ini.

    • Jika tidak ada Node yang memenuhi aturan (misalnya, Anda meminta GPU tapi tidak ada Node GPU yang tersedia), Pod tersebut tidak akan pernah berjalan. Pod akan terjebak dalam status Pending.

    • Contoh: required... Pod Anti-Affinity untuk HA.

  2. Soft Rule (preferredDuringScheduling...)

    • Artinya: "SEBAIKNYA" atau "JIKA BISA". Ini adalah preferensi.

    • Scheduler Kubernetes akan berusaha sebaik mungkin untuk mematuhi aturan ini.

    • Jika tidak ada Node yang memenuhi aturan, scheduler akan mengabaikan aturan tersebut dan menempatkan Pod di Node terbaik yang tersedia.

    • Contoh: preferred... Pod Affinity untuk web server dan cache. Sebaiknya mereka di satu Node, tapi jika cluster penuh dan tidak memungkinkan, lebih baik aplikasi tetap berjalan (meskipun di Node terpisah) daripada tidak berjalan sama sekali.

Ringkasan

Jenis

Konsep

Contoh Kasus Penggunaan Utama

Node Affinity

"Saya suka Node ini"

Perlu hardware khusus (misalnya GPU, SSD).

Pod Affinity

"Saya suka Pod itu"

Performa, co-location (misal: web + cache).

Pod Anti-Affinity

"Saya tidak suka Pod itu"

High Availability (HA), menyebar replika.

Tentu. Berikut adalah dua contoh YAML lengkap yang paling umum digunakan.

1. Contoh: Pod Anti-Affinity (Untuk High Availability)

Skenario ini adalah yang paling penting. Kita akan membuat 3 replika dari Nginx, dan kita akan memaksa Kubernetes untuk menempatkan ketiganya di Node (server) yang berbeda.

Ini mencegah layanan Anda mati total jika satu Node gagal.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-ha-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-ha # <-- Selector ini harus cocok dengan label di template
  template:
    metadata:
      labels:
        app: nginx-ha # <-- Label ini yang akan digunakan untuk aturan anti-affinity
    spec:
      containers:
      - name: nginx
        image: nginx:1.27
        ports:
        - containerPort: 80
      
      # --- INI BAGIAN PENTINGNYA ---
      affinity:
        podAntiAffinity:
          # Ini adalah aturan "keras". HARUS dipatuhi.
          requiredDuringSchedulingIgnoredDuringExecution: 
          - labelSelector:
              matchExpressions:
                - key: app       # Cari Pod lain...
                  operator: In   # ...yang memiliki key "app"...
                  values:        # ...dengan value "nginx-ha"
                  - "nginx-ha"
            # "topologyKey" adalah "batas" di mana aturan ini berlaku.
            # "kubernetes.io/hostname" berarti "di dalam satu Node yang sama".
            # Jadi, aturan ini dibaca:
            # "JANGAN jadwalkan Pod ini di Node (hostname) yang SUDAH ADA 
            #  Pod lain dengan label app=nginx-ha."
            topologyKey: "kubernetes.io/hostname"
      # --- AKHIR DARI BAGIAN PENTING ---

Penjelasan Sederhana:

  1. replicas: 3: Kita meminta 3 Pod.

  2. podAntiAffinity: Kita memberi tahu Kubernetes untuk menjauhkan Pod satu sama lain.

  3. required...: Aturan ini "wajib". Jika Kubernetes tidak dapat menemukan 3 Node yang berbeda, Pod ke-3 akan tetap Pending (tertunda) sampai ada Node baru yang tersedia.

  4. labelSelector: Aturan ini mencari Pod lain yang memiliki label app: nginx-ha.

  5. topologyKey: "kubernetes.io/hostname": Ini adalah kunci utamanya. Ini memberi tahu Kubernetes, "batas pemisah" antar Pod adalah nama host (yaitu, Node fisik/virtual).

Hasilnya, Pod-1 akan ditempatkan di Node A, Pod-2 di Node B, dan Pod-3 di Node C.

2. Contoh: Node Affinity (Untuk Hardware Khusus)

Skenario ini adalah yang paling umum kedua. Kita akan menjalankan sebuah Pod yang harus berjalan di Node yang memiliki hardware spesifik, misalnya GPU.

Langkah 1: Beri Label pada Node Anda

Pertama, Anda (sebagai admin) harus memberi label pada Node yang memiliki GPU.

# Ganti <nama-node-gpu> dengan nama Node Anda
kubectl label nodes <nama-node-gpu> hardware=nvidia-gpu

Langkah 2: Buat Pod dengan Aturan Node Affinity

Sekarang, kita buat Pod yang "mencari" label tersebut.

apiVersion: v1
kind: Pod
metadata:
  name: pod-butuh-gpu
spec:
  containers:
  - name: cuda-container
    image: nvidia/cuda:12.5.0-base-ubuntu22.04
    command: ["sleep", "3600"] # Hanya tidur agar Pod tetap berjalan
  
  # --- INI BAGIAN PENTINGNYA ---
  affinity:
    nodeAffinity:
      # Ini adalah aturan "keras". HARUS dipatuhi.
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
            - key: hardware      # Cari Node...
              operator: In       # ...yang memiliki label "hardware"...
              values:            # ...dengan value "nvidia-gpu"
              - "nvidia-gpu"
  # --- AKHIR DARI BAGIAN PENTING ---

Penjelasan Sederhana:

  1. nodeAffinity: Kita memberi tahu Kubernetes untuk "tertarik" pada Node tertentu.

  2. required...: Aturan ini "wajib". Jika tidak ada satupun Node di cluster yang memiliki label hardware=nvidia-gpu, Pod ini akan tetap Pending (tertunda) selamanya.

  3. matchExpressions: Ini adalah aturan pencariannya. Ia mencari Node yang memiliki label hardware dengan nilai nvidia-gpu.

Hasilnya, Pod pod-butuh-gpu ini dijamin hanya akan dijadwalkan di Node yang telah Anda beri label hardware=nvidia-gpu.

Ringkasan Perbedaan:

  • Contoh 1 (Anti-Affinity): Menggunakan podAntiAffinity. Aturan ini tentang Pod vs Pod lain. Tujuannya menyebar Pod.

  • Contoh 2 (Affinity): Menggunakan nodeAffinity. Aturan ini tentang Pod vs Node. Tujuannya mengelompokkan Pod ke Node spesifik.

PreviousMy Daily UsesNextIngress vs LoadBalancer: Kapan Harus Digunakan di Kubernetes?

Last updated