Label dan Selector

Sistem metadata label dan selector yang menjadi fondasi pemilihan objek di seluruh Kubernetes.

Daftar isi

Label adalah pasangan key dan value yang dilampirkan pada objek Kubernetes untuk menyimpan metadata pengelompokan, sedangkan selector adalah mekanisme pemilihan kumpulan objek berdasarkan label tersebut. Topik ini membahas aturan penulisan label, dua jenis selector yang didukung API server, serta peran keduanya pada Service dan Deployment. Perilaku pencocokan selector disimulasikan dengan Python, sehingga hasil setiap seleksi dapat diamati tanpa kluster.

Label sebagai pasangan key dan value#

Label menyimpan atribut pengelompokan yang bermakna bagi pengguna dan bagi komponen lain di kluster. Identitas sebuah objek ditentukan oleh nama dan UID-nya, sedangkan label bersifat pelengkap: objek tetap berfungsi tanpa satu label pun, namun hampir semua alur kerja nyata menggunakan label untuk memilah, memantau, dan memilih objek. Label dilampirkan pada saat objek dibuat dan tetap dapat diubah sesudahnya melalui perintah kubectl maupun penyuntingan manifest.

Struktur label sederhana, yaitu pasangan key dan value pada kunci metadata.labels. Sebuah Pod dapat memuat beberapa label sekaligus untuk menyatakan dimensi yang berbeda, misalnya aplikasi pemilik, lingkungan penggunaan, dan versi. Tabel berikut menampilkan empat Pod beserta labelnya, dan kumpulan data tersebut menjadi bahan seleksi pada contoh sepanjang topik ini.

Pod	app	lingkungan	versi
web-1	web	produksi	v1
web-2	web	produksi	v2
web-3	web	uji	v2
api-1	api	produksi	v1

Dimensi pada tabel itu bekerja secara independen. Selector yang hanya menuntut aplikasi web menghasilkan tiga Pod, sedangkan selector yang menambahkan syarat lingkungan produksi menyisakan dua Pod. Gabungan dimensi semacam inilah yang menjadi dasar kerja selector pada bagian selanjutnya.

Aturan penulisan label#

API server menegakkan aturan sintaks pada setiap label. Key dapat memuat awalan berupa nama domain DNS yang diakhiri garis miring, misalnya example.com/tim, diikuti bagian nama yang wajib ada. Bagian nama dibatasi maksimal 63 karakter, sedangkan keseluruhan key beserta awalannya dibatasi 253 karakter. Karakter yang diizinkan adalah huruf, angka, tanda hubung, garis bawah, dan titik, dengan huruf atau angka wajib berada di awal dan di akhir.

Value mengikuti aturan yang serupa, yaitu maksimal 63 karakter dengan himpunan karakter yang sama, dan boleh berupa string kosong. Apabila aturan ini dilanggar, API server menolak manifest dengan pesan error validasi, sehingga Pod tidak dibuat sama sekali. Kesalahan semacam ini paling sering muncul pada label yang berisi spasi atau tanda baca yang tidak diizinkan.

Awalan pada key lazim digunakan oleh komponen Kubernetes sendiri, misalnya kubernetes.io, untuk memisahkan label milik sistem dari label milik pengguna. Awalan semacam itu hanya sah apabila pemilik domainnya mengizinkan, sehingga manifest biasa menggunakan key tanpa awalan. Key tanpa awalan sudah cukup untuk kebutuhan pengelompokan sehari-hari dan lebih mudah dibaca pada saat penelusuran.

Selector equality-based dan set-based#

Selector tersedia dalam dua bentuk. Selector equality-based mencocokkan pasangan key dan value secara persis, sedangkan selector set-based mencocokkan keanggotaan daftar dan keberadaan kunci. Semua syarat pada satu selector harus terpenuhi sekaligus, sehingga semantiknya adalah logika DAN antarsyarat.

Bentuk equality-based dinyatakan sebagai daftar pasangan key dan value. Pada kubectl, selector ditulis setelah opsi -l dengan pasangan yang dipisahkan koma, misalnya app=web,lingkungan=produksi. Pada manifest, daftar pasangan yang sama berada di dalam kunci selector.matchLabels. Bentuk ini cocok untuk kasus yang hanya membutuhkan kesamaan nilai.

bash

# tidak-dijalankan
# menampilkan pod yang cocok dengan selector equality-based
kubectl get pods -l app=web,lingkungan=produksi
# melampirkan label baru pada pod yang sedang berjalan
kubectl label pod web-3 lingkungan=produksi

text Contoh keluaran

NAME    READY   STATUS    RESTARTS   AGE
web-1   1/1     Running   0          2d
web-2   1/1     Running   0          2d

pod/web-3 labeled

Bentuk set-based menggunakan matchExpressions dengan empat operator. Operator In memilih Pod yang nilai kuncinya berada di dalam daftar, NotIn sebaliknya, Exists hanya menuntut kunci berada pada label, dan DoesNotExist menuntut kunci tidak berada pada label. Bentuk ini diperlukan apabila pemilihan bergantung pada daftar nilai atau pada keberadaan kunci, bukan pada satu nilai pasti.

Perilaku kedua bentuk tersebut dapat diverifikasi dengan simulasi yang meniru logika pencocokan Kubernetes. Skrip Python berikut menerapkan satu selector equality-based dan dua selector set-based terhadap keempat Pod pada tabel di atas, kemudian mencetak Pod yang lolos setiap seleksi.

python simulasi-selector.py

"""Simulasi pencocokan selector terhadap pod berlabel."""
# Daftar pod beserta labelnya, sama dengan tabel contoh pada topik ini
pods = [
    {"nama": "web-1", "label": {"app": "web", "lingkungan": "produksi", "versi": "v1"}},
    {"nama": "web-2", "label": {"app": "web", "lingkungan": "produksi", "versi": "v2"}},
    {"nama": "web-3", "label": {"app": "web", "lingkungan": "uji", "versi": "v2"}},
    {"nama": "api-1", "label": {"app": "api", "lingkungan": "produksi", "versi": "v1"}},
]


def cocok_match_labels(label, pilihan):
    """Equality-based: seluruh pasangan key/value wajib sama persis."""
    return all(label.get(k) == v for k, v in pilihan.items())


def cocok_match_expressions(label, ekspresi):
    """Set-based: In, NotIn, Exists, dan DoesNotExist."""
    for e in ekspresi:
        k, op = e["key"], e["operator"]
        if op == "In" and label.get(k) not in e["values"]:
            return False
        if op == "NotIn" and label.get(k) in e["values"]:
            return False
        if op == "Exists" and k not in label:
            return False
        if op == "DoesNotExist" and k in label:
            return False
    return True


seleksi_a = {"app": "web", "lingkungan": "produksi"}
print("A. matchLabels: app=web, lingkungan=produksi")
for pod in pods:
    if cocok_match_labels(pod["label"], seleksi_a):
        print(f"   lolos: {pod['nama']}")
print()

seleksi_b = [
    {"key": "versi", "operator": "In", "values": ["v2"]},
    {"key": "lingkungan", "operator": "NotIn", "values": ["uji"]},
]
print("B. matchExpressions: versi In (v2), lingkungan NotIn (uji)")
for pod in pods:
    if cocok_match_expressions(pod["label"], seleksi_b):
        print(f"   lolos: {pod['nama']}")
print()

seleksi_c = [{"key": "versi", "operator": "Exists"}]
print("C. matchExpressions: versi Exists")
for pod in pods:
    if cocok_match_expressions(pod["label"], seleksi_c):
        print(f"   lolos: {pod['nama']}")

text Keluaran

A. matchLabels: app=web, lingkungan=produksi
   lolos: web-1
   lolos: web-2

B. matchExpressions: versi In (v2), lingkungan NotIn (uji)
   lolos: web-2

C. matchExpressions: versi Exists
   lolos: web-1
   lolos: web-2
   lolos: web-3
   lolos: api-1

Keluaran tersebut menegaskan perbedaan kedua bentuk. Seleksi A dan B hanya meloloskan Pod yang seluruh syaratnya terpenuhi, sedangkan seleksi C meloloskan semua Pod yang memiliki kunci versi tanpa memandang nilainya. Pod api-1 tidak pernah lolos seleksi yang menuntut app=web karena labelnya menyatakan aplikasi berbeda.

Peran selector pada Service dan Deployment#

Service menggunakan selector untuk menentukan Pod mana yang menerima trafiknya. Seluruh Pod yang labelnya cocok dengan selector menjadi backend Service, dan Pod yang cocok ditambahkan secara otomatis ketika dibuat serta dikeluarkan ketika tidak cocok lagi. Berkas service.yaml berikut mendeklarasikan Service yang memilih semua Pod berlabel app=web, yaitu web-1, web-2, dan web-3 pada tabel contoh.

yaml service.yaml

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80

Deployment menggunakan selector untuk mengadopsi Pod yang dibuatnya. Template Pod di dalam Deployment membawa sekumpulan label, dan selector Deployment wajib mencocokkan label template tersebut karena Deployment mengelola Pod berdasarkan kecocokan itu. Apabila selector tidak cocok dengan label template, API server menolak manifest dengan pesan error. Fragmen berikut menunjukkan pasangan selector dan label template pada Deployment.

yaml Contoh: selector Deployment wajib mencocokkan label templat

spec:
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web

Selector Deployment juga menerima bentuk set-based melalui matchExpressions, misalnya untuk memilih Pod dari beberapa lingkungan sekaligus. Praktik yang umum adalah menetapkan selector hanya pada dimensi yang tidak berubah, seperti app, dan menaruh dimensi yang sering berubah pada label terpisah. Namun, kesalahan pada satu label dapat menyebabkan Pod berjalan tetapi tidak pernah dipilih Service maupun Deployment, sehingga pemeriksaan label selalu dilakukan sebelum manifest diterapkan.

Ringkasan#

Label menyimpan pasangan key dan value pada metadata, dengan batas 63 karakter untuk bagian nama key maupun value tanpa awalan.
Selector equality-based mencocokkan nilai persis melalui matchLabels, sedangkan selector set-based mencocokkan daftar nilai dan keberadaan kunci melalui In, NotIn, Exists, dan DoesNotExist.
Service memilih Pod backend melalui selector, dan Deployment mengadopsi Pod yang dibuatnya melalui kecocokan selector dengan label template.

Referensi#

Labels and Selectors — Kubernetes Docs — Aturan sintaks label dan selector, termasuk bentuk equality-based dan set-based.
Kubernetes Object Management — Kubernetes Docs — Cara objek Kubernetes dikelola dan hubungan controller dengan objek yang diadopsinya.