Menggunakan Objek-Objek Kubernetes

• 1: Memahami Konsep Objek-Objek yang ada pada Kubernetes
• 2: Pengaturan Objek Kubernetes
• 3: Nama
• 4: Namespace
• 5: Label dan Selektor
• 6: Anotasi
• 7: Selektor Field
• 8: Label yang Disarankan

1 - Memahami Konsep Objek-Objek yang ada pada Kubernetes

Laman ini menjelaskan bagaimana objek-objek Kubernetes direpresentasikan di dalam API Kubernetes, dan bagaimana kamu dapat merepresentasikannya di dalam format .yaml.

Memahami Konsep Objek-Objek yang Ada pada Kubernetes

Objek-objek Kubernetes adalah entitas persisten di dalam sistem Kubernetes. Kubernetes menggunakan entitas ini untuk merepresentasikan state yang ada pada klaster kamu. Secara spesifik, hal itu dapat dideskripsikan sebagai:

• Aplikasi-aplikasi kontainer apa sajakah yang sedang dijalankan (serta pada node apa aplikasi tersebut dijalankan)
• Resource yang tersedia untuk aplikasi tersebut
• Policy yang mengatur bagaimana aplikasi tersebut dijalankan, misalnya restart, upgrade, dan fault-tolerance.

Objek Kubernetes merupakan sebuah "record of intent"--yang mana sekali kamu membuat suatu objek, sistem Kubernetes akan bekerja secara konsisten untuk menjamin bahwa objek tersebut akan selalu ada. Dengan membuat sebuah objek, secara tak langsung kamu memberikan informasi pada sistem Kubernetes mengenai perilaku apakah yang kamu inginkan pada workload klaster yang kamu miliki; dengan kata lain ini merupakan definisi state klaster yang kamu inginkan.

Untuk menggunakan objek-objek Kubernetes--baik membuat, mengubah, atau menghapus objek-objek tersebut--kamu harus menggunakan API Kubernetes. Ketika kamu menggunakan perintah kubectl, perintah ini akan melakukan API call untuk perintah yang kamu berikan. Kamu juga dapat menggunakan API Kubernetes secara langsung pada program yang kamu miliki menggunakan salah satu library klien yang disediakan.

Spec dan Status Objek

Setiap objek Kubernetes memiliki field berantai yang mengatur konfigurasi sebuah objek: spec dan status. Spec, merupakan field yang harus kamu sediakan, field ini mendeskripsikan state yang kamu inginkan untuk objek tersebut--karakteristik dari objek yang kamu miliki. Status mendeskripsikan state yang sebenarnya dari sebuah objek, dan hal ini disediakan dan selalu diubah oleh sistem Kubernetes. Setiap saat, Control Plane Kubernetes selalu memantau apakah state aktual sudah sesuai dengan state yang diinginkan.

Sebagai contoh, Deployment merupakan sebuah objek yang merepresentasikan sebuah aplikasi yang dijalankan di klaster kamu. Ketika kamu membuat sebuah Deployment, kamu bisa saja memberikan spec bagi Deployment untuk memberikan spesifikasi berapa banyak replica yang kamu inginkan. Sistem Kubernetes kemudian akan membaca konfigurasi yang kamu berikan dan mengaktifkan tiga buah instans untuk aplikasi yang kamu inginkan--mengubah status yang ada saat ini agar sesuai dengan apa yang kamu inginkan. Jika terjadi kegagalan dalam instans yang dibuat, sistem Kubernetes akan memberikan respons bahwa terdapat perbedaan antara spec dan status serta melakukan penyesuaian dengan cara memberikan instans pengganti.

Informasi lebih lanjut mengenai spec objek, status, dan metadata dapat kamu baca di Konvensi API Kubernetes.

Mendeskripsikan Objek Kubernetes

Ketika kamu membuat sebuah objek di Kubernetes, kamu harus menyediakan spec objek yang mendeskripsikan state yang diinginkan, serta beberapa informasi tentang objek tersebut (seperti nama). Ketika kamu menggunakan API Kubernetes untuk membuat objek tersebut (baik secara langsung atau menggunakan perintah kubectl), request API yang dibuat harus mencakup informasi seperti request body dalam format JSON. Apabila kamu memberikan informasi dalam bentuk .yaml ketika menggunakan perintah kubectl maka kubectl akan mengubah informasi yang kamu berikan ke dalam format JSON ketika melakukan request API.

Berikut merupakan contoh file .yaml yang menunjukkan field dan spec objek untuk Deployment:

application/deployment.yaml

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # tells deployment to run 2 pods matching the template
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.7.9
          ports:
            - containerPort: 80

Salah satu cara untuk membuat Deployment menggunakan file .yaml seperti yang dijabarkan di atas adalah dengan menggunakan perintah kubectl apply pada command-line interface kubectl kamu menerapkan file .yaml sebagai sebuah argumen. Berikut merupakan contoh penggunaannya:

kubectl apply -f https://k8s.io/examples/application/deployment.yaml --record

Keluaran yang digunakan kurang lebih akan ditampilkan sebagai berikut:

deployment.apps/nginx-deployment created

Field-Field yang dibutuhkan

Pada file .yaml untuk objek Kubernetes yang ingin kamu buat, kamu perlu menyediakan value untuk field-field berikut:

• apiVersion - Version API Kubernetes mana yang kamu gunakan untuk membuat objek tersebut
• kind - Objek apakah yang ingin kamu buat
• metadata - Data yang dapat kamu gunakan untuk melakukan identifikasi objek termasuk name dalam betuk string, UID, dan namespace yang bersifat opsional

Kamu juga harus menyediakan field spec. Format spesifik dari spec sebuah objek akan berbeda bergantung pada objek apakah yang ingin kamu buat, serta mengandung field berantai yang spesifik bagi objek tersebut. Referensi API Kubernetes memberikan penjelasan lebih lanjut mengenai format spec untuk semua objek Kubernetes yang dapat kamu buat. Misalnya saja format spec untuk Pod dapat kamu temukan di sini, dan format spec untuk Deployment dapat ditemukan di sini.

Selanjutnya

• Pelajari lebih lanjut mengenai dasar-dasar penting bagi objek Kubernetes, seperti Pod.

2 - Pengaturan Objek Kubernetes

Perangkat kubectl mendukung beberapa cara untuk membuat dan mengatur objek-objek Kubernetes. Laman ini menggambarkan berbagai macam metodenya. Baca Kubectl gitbook untuk penjelasan pengaturan objek dengan Kubectl secara detail.

Metode pengaturan

Perintah imperatif

Ketika menggunakan perintah-perintah imperatif, seorang pengguna menjalankan operasi secara langsung pada objek-objek live dalam sebuah klaster. Pengguna menjalankan operasi tersebut melalui argumen atau flag pada perintah kubectl.

Ini merupakan cara yang paling mudah untuk memulai atau menjalankan tugas "sekali jalan" pada sebuah klaster. Karena metode ini dijalankan secara langsung pada objek live, tidak ada history yang menjelaskan konfigurasi-konfigurasi terkait sebelumnya.

Contoh

Menjalankan sebuah instans Container nginx dengan membuat suatu objek Deployment:

kubectl run nginx --image nginx

Melakukan hal yang sama menggunakan sintaks yang berbeda:

kubectl create deployment nginx --image nginx

Kelebihan dan kekurangan

Beberapa kelebihan metode ini dibandingkan metode konfigurasi objek:

• Sederhana, mudah dipelajari dan diingat.
• Hanya memerlukan satu langkah untuk membuat perubahan pada klaster.

Beberapa kekurangan metode ini dibandingkan metode konfigurasi objek:

• Tidak terintegrasi dengan proses peninjauan (review) perubahan.
• Tidak menyediakan jejak audit yang terkait dengan perubahan.
• Tidak menyediakan sumber record kecuali dari apa yang live terlihat.
• Tidak menyediakan templat untuk membuat objek-objek baru.

Konfigurasi objek imperatif

Pada konfigurasi objek imperatif, perintah kubectl menetapkan jenis operasi (create, replace, etc.), flag-flag pilihan dan minimal satu nama berkas. Berkas ini harus berisi definisi lengkap dari objek tersebut dalam bentuk YAML atau JSON.

Lihat referensi API untuk info lebih detail mengenai definisi objek.

Contoh

Membuat objek yang didefinisikan pada sebuah berkas konfigurasi:

kubectl create -f nginx.yaml

Menghapus objek-objek yang didefinisikan pada dua berkas konfigurasi:

kubectl delete -f nginx.yaml -f redis.yaml

Memperbarui objek yang didefinisikan pada sebuah berkas konfigurasi dengan menimpa konfigurasi live:

kubectl replace -f nginx.yaml

Kelebihan dan kekurangan

Beberapa kelebihan dibandingkan metode perintah imperatif:

• Konfigurasi objek dapat disimpan pada suatu sistem kontrol kode seperti Git.
• Konfigurasi objek dapat diintegrasikan dengan proses-proses, misalnya peninjauan (review) perubahan sebelum push dan jejak audit.
• Konfigurasi objek dapat menyediakan templat untuk membuat objek-objek baru.

Beberapa kekurangan dibandingkan metode perintah imperatif:

• Konfigurasi objek memerlukan pemahaman yang mendasar soal skema objek.
• Konfigurasi objek memerlukan langkah tambahan untuk menulis berkas YAML.

Beberapa kelebihan dibandingkan metode konfigurasi objek deklaratif:

• Konfigurasi objek imperatif memiliki perilaku yang lebih sederhana dan mudah dimengerti.
• Sejak Kubernetes versi 1.5, konfigurasi objek imperatif sudah lebih stabil.

Beberapa kekurangan dibandingkan metode konfigurasi objek deklaratif:

• Konfigurasi objek imperatif bekerja dengan baik untuk berkas-berkas, namun tidak untuk direktori.
• Pembaruan untuk objek-objek live harus diterapkan pada berkas-berkas konfigurasi, jika tidak, hasil perubahan akan hilang pada penggantian berikutnya.

Konfigurasi objek deklaratif

Ketika menggunakan konfigurasi objek deklaratif, seorang pengguna beroperasi pada berkas-berkas konfigurasi objek yang disimpan secara lokal, namun pengguna tidak mendefinisikan operasi yang akan dilakukan pada berkas-berkas tersebut. Operasi create, update, dan delete akan dideteksi secara otomatis per-objek dengan kubectl. Hal ini memungkinkan penerapan melalui direktori, dimana operasi yang berbeda mungkin diperlukan untuk objek-objek yang berbeda.

Contoh

Melakukan pemrosesan pada semua berkas konfigurasi objek di direktori configs, dan melakukan create atau patch untuk objek-objek live. Kamu dapat terlebih dahulu melakukan diff untuk melihat perubahan-perubahan apa saja yang akan dilakukan, dan kemudian terapkan:

kubectl diff -f configs/
kubectl apply -f configs/

Melakukan pemrosesan direktori secara rekursif:

kubectl diff -R -f configs/
kubectl apply -R -f configs/

Kelebihan dan kekurangan

Beberapa kelebihan dibandingkan konfigurasi objek imperatif:

• Perubahan-perubahan yang dilakukan secara langsung pada objek-objek live akan dipertahankan, bahkan jika perubahan tersebut tidak digabungkan kembali pada berkas-berkas konfigurasi.
• Konfigurasi objek deklaratif memiliki dukungan yang lebih baik dalam mengoperasikan direktori dan secara otomatis mendeteksi tipe operasi (create, patch, delete) per-objek.

Beberapa kekurangan dibandingkan konfigurasi objek imperatif:

• Konfigurasi objek deklaratif lebih sulit untuk di-debug dan hasilnya lebih sulit dimengerti untuk perilaku yang tidak diinginkan.
• Pembaruan sebagian menggunakan diff menghasilkan operasi merge dan patch yang rumit.

Selanjutnya

• Mengatur Objek Kubernetes menggunakan Perintah Imperatif
• Mengatur Objek Kubernetes menggunakan Konfigurasi Objek (Imperatif)
• Mengatur Objek Kubernetes menggunakan Konfigurasi Objek (Deklaratif)
• Mengatur Objek Kubernetes menggunakan Kustomize (Deklaratif)
• Referensi Perintah Kubectl
• Kubectl Gitbook
• Referensi API Kubernetes

3 - Nama

Seluruh objek di dalam REST API Kubernetes secara jelas ditandai dengan nama dan UID.

Apabila pengguna ingin memberikan atribut tidak unik, Kubernetes menyediakan label dan anotasi.

Bacalah dokumentasi desain penanda agar kamu dapat memahami lebih lanjut sintaks yang digunakan untuk Nama dan UID.

Nama

String yang dihasilkan oleh klien yang mengacu pada sebuah objek dalam suatu URL resource, seperti /api/v1/pods/some-name.

Sebuah objek dengan kind yang sama tidak boleh memiliki nama yang sama pada suatu waktu tertentu. Meskipun begitu, apabila kamu menghapus sebuah objek, kamu membuat sebuah objek baru (yang memiliki kind yang sama) dengan nama yang sama dengan objek yang kamu hapus sebelumnya.

Berdasarkan ketentuan, nama dari resources Kubernetes memiliki panjang maksimum 253 karakter yang terdiri dari karakter alfanumerik huruf kecil, -, dan ., tetapi resources tertentu punya lebih banyak batasan yang spesifik

UID

String yang dihasilkan oleh sistem Kubernetes untuk mengidentifikasi objek secara unik.

Setiap objek yang ada pada klaster Kubernetes memiliki UID yang unik. Hal ini dilakukan untuk membedakan keberadaan historis suatu entitas dengan kind dan nama yang serupa.

4 - Namespace

Kubernetes mendukung banyak klaster virtual di dalam satu klaster fisik. Klaster virtual tersebut disebut dengan namespace.

Kapan menggunakan banyak Namespace

Namespace dibuat untuk digunakan di environment dengan banyak pengguna yang berada di dalam banyak tim ataupun proyek. Untuk sebuah klaster dengan beberapa pengguna saja, kamu tidak harus membuat ataupun memikirkan tentang namespace. Mulai gunakan namespace saat kamu membutuhkan fitur dari namespace itu sendiri.

Namespace menyediakan ruang untuk nama objek. Nama dari resource atau objek harus berbeda di dalam sebuah namespace, tetapi boleh sama jika berbeda namespace. Namespace tidak bisa dibuat di dalam namespace lain dan setiap resource atau objek Kubernetes hanya dapat berada di dalam satu namespace.

Namespace merupakan cara yang digunakan untuk memisahkan resource klaster untuk beberapa pengguna (dengan resource quota).

Dalam versi Kubernetes yang akan datang, objek di dalam satu namespace akan mempunyai access control policies yang sama secara default.

Tidak perlu menggunakan banyak namespace hanya untuk memisahkan sedikit perbedaan pada resource, seperti perbedaan versi dari perangkat lunak yang sama: gunakan label untuk membedakan resource di dalam namespace yang sama.

Bekerja dengan Namespace

Pembuatan dan penghapusan namespace dijelaskan di dokumentasi panduan admin untuk namespace.

Melihat namespace

Kamu dapat melihat daftar namespace di dalam klaster menggunakan:

kubectl get namespace

NAME          STATUS    AGE
default       Active    1d
kube-system   Active    1d
kube-public   Active    1d

Kubernetes berjalan dengan tiga namespace awal:

• default, namespace default untuk objek yang dibuat tanpa mencantumkan namespace pada spesifikasinya.
• kube-system, namespace yang digunakan untuk objek yang dibuat oleh sistem Kubernetes.
• kube-public, namespace ini dibuat secara otomatis dan dapat diakses oleh semua pengguna (termasuk yang tidak diautentikasi). Namespace ini disediakan untuk penggunaan klaster, jika beberapa resouce harus terlihat dan dapat dibaca secara publik di seluruh klaster. Aspek publik dari namespace ini hanya sebuah konvensi, bukan persyaratan.

Mengkonfigurasi namespace untuk request

Untuk mengkonfigurasi sementara request untuk menggunakan namespace tertentu, gunakan --namespace flag.

Sebagai contoh:

kubectl --namespace=<insert-namespace-name-here> run nginx --image=nginx
kubectl --namespace=<insert-namespace-name-here> get pods

Mengkonfigurasi preferensi namespace

Kamu dapat menyimpan konfigurasi namespace untuk semua perintah kubectl dengan perintah:

kubectl config set-context --current --namespace=<insert-namespace-name-here>
# Cek namespace
kubectl config view | grep namespace:

Namespace dan DNS

Saat kamu membuat sebuah Service, Kubernetes membuat Entri DNS untuk service tersebut. Entri DNS ini berformat <service-name>.<namespace-name>.svc.cluster.local, yang berarti jika sebuah kontainer hanya menggunakan <service-name>, kontainer tersebut akan berkomunikasi dengan service yang berada di dalam satu namespace. Ini berguna untuk menggunakan konfigurasi yang sama di beberapa namespace seperti Development, Staging, dan Production. Jika kamu ingin berkomunikasi antar namespace, kamu harus menggunakan seluruh fully qualified domain name (FQDN).

Tidak semua objek di dalam Namespace

Kebanyakan resource di Kubernetes (contohnya pod, service, replication controller, dan yang lain) ada di dalam namespace. Namun resource namespace sendiri tidak berada di dalam namespace. Dan low-level resource seperti node dan persistentVolume tidak berada di namespace manapun.

Untuk melihat resource di dalam kubernetes yang berada di dalam namespace ataupun tidak:

# Di dalam namespace
kubectl api-resources --namespaced=true

# Tidak di dalam namespace
kubectl api-resources --namespaced=false

5 - Label dan Selektor

Label merupakan pasangan key/value yang melekat pada objek-objek, misalnya pada Pod. Label digunakan untuk menentukan atribut identitas dari objek agar memiliki arti dan relevan bagi para pengguna, namun tidak secara langsung memiliki makna terhadap sistem inti. Label dapat digunakan untuk mengatur dan memilih sebagian dari banyak objek. Label-label dapat ditempelkan ke objek-objek pada saat dibuatnya objek-objek tersebut dan kemudian ditambahkan atau diubah kapan saja setelahnya. Setiap objek dapat memiliki satu set label key/value. Setiap Key harus unik untuk objek tersebut.

"metadata": {
  "labels": {
    "key1" : "value1",
    "key2" : "value2"
  }
}

Label memungkinkan untuk menjalankan kueri dan pengamatan dengan efisien, serta ideal untuk digunakan pada UI dan CLI. Informasi yang tidak digunakan untuk identifikasi sebaiknya menggunakan anotasi.

Motivasi

Label memungkinkan pengguna untuk memetakan struktur organisasi mereka ke dalam objek-objek sistem yang tidak terikat secara erat, tanpa harus mewajibkan klien untuk menyimpan pemetaan tersebut.

Service deployments dan batch processing pipelines sering menjadi entitas yang berdimensi ganda (contohnya partisi berganda atau deployment, jalur rilis berganda, tingkatan berganda, micro-services berganda per tingkatan). Manajemen seringkali membutuhkan operasi lintas tim, yang menyebabkan putusnya enkapsulasi dari representasi hierarki yang ketat, khususnya pada hierarki-hierarki kaku yang justru ditentukan oleh infrastruktur, bukan oleh pengguna.

Contoh label:

• "release" : "stable", "release" : "canary"
• "environment" : "dev", "environment" : "qa", "environment" : "production"
• "tier" : "frontend", "tier" : "backend", "tier" : "cache"
• "partition" : "customerA", "partition" : "customerB"
• "track" : "daily", "track" : "weekly"

Ini hanya contoh label yang biasa digunakan; kamu bebas mengembangkan caramu sendiri. Perlu diingat bahwa Key dari label harus unik untuk objek tersebut.

Sintaksis dan set karakter

Label merupakan pasangan key/value. Key-key dari Label yang valid memiliki dua segmen: sebuah prefiks dan nama yang opsional, yang dipisahkan oleh garis miring (/). Segmen nama wajib diisi dan tidak boleh lebih dari 63, dimulai dan diakhiri dengan karakter alfanumerik ([a-z0-9A-Z]) dengan tanda pisah (-), garis bawah (_), titik (.), dan alfanumerik di antaranya. Sedangkan prefiks bersifat opsional. Jika ditentukan, prefiks harus berupa subdomain DNS: rangkaian label DNS yang dipisahkan oleh titik (.), dengan total tidak lebih dari 253 karakter, yang diikuti oleh garis miring (/).

Jika prefiks dihilangkan, Key dari label diasumsikan privat bagi pengguna. Komponen sistem otomatis (contoh kube-scheduler, kube-controller-manager, kube-apiserver, kubectl, atau otomasi pihak ketiga lainnya) yang akan menambah label ke objek-objek milik pengguna akhir harus menentukan prefiks.

Prefiks kubernetes.io/ dan k8s.io/ dikhususkan untuk komponen inti Kubernetes.

Nilai label yang valid tidak boleh lebih dari 63 karakter dan harus kosong atau diawali dan diakhiri dengan karakter alfanumerik ([a-z0-9A-Z]) dengan tanda pisah (-), garis bawah (_), titik (.), dan alfanumerik di antaranya.

Contoh di bawah ini merupakan berkas konfigurasi untuk Pod yang memiliki dua label environment: production dan app: nginx :

apiVersion: v1
kind: Pod
metadata:
  name: label-demo
  labels:
    environment: production
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.7.9
    ports:
    - containerPort: 80

Selektor label

Tidak seperti nama dan UID, label tidak memberikan keunikan. Secara umum, kami memperkirakan bahwa banyak objek yang akan memiliki label yang sama.

Menggunakan sebuah label selector, klien/pengguna dapat mengidentifikasi suatu kumpulan objek. Selektor label merupakan alat/cara pengelompokan utama pada Kubernetes.

Saat ini API mendukung dua jenis selektor: equality-based dan set-based. Sebuah selektor label dapat dibuat dari kondisi berganda yang dipisahkan oleh koma. Pada kasus kondisi berganda, semua kondisi harus dipenuhi sehingga separator koma dapat bertindak sebagai operator logika AND (&&).

Makna dari selektor yang kosong atau tidak diisi tergantung dari konteks, dan tipe API yang menggunakan selektor harus mendokumentasikan keabsahan dan arti dari selektor yang kosong tersebut.

Kondisi Equality-based

Kondisi Equality-based atau inequality-based memungkinkan untuk melakukan filter dengan menggunakan key dan value dari label. Objek yang cocok harus memenuhi semua batasan label yang telah ditentukan, meskipun mereka dapat memiliki label tambahan lainnya. Terdapat tiga jenis operator yang didukung yaitu =,==,!=. Dua operator pertama menyatakan kesamaan (keduanya hanyalah sinonim), sementara operator terakhir menyatakan ketidaksamaan. Contoh:

environment = production
tier != frontend

Kondisi pertama akan memilih semua sumber daya dengan key environment dan nilai key production. Kondisi berikutnya akan memilih semua sumber daya dengan key tier dan nilai key selain frontend, dan semua sumber daya yang tidak memiliki label dengan key tier. Kamu juga dapat memfilter sumber daya dalam production selain frontend dengan menggunakan operator koma: environment=production,tier!=frontend

Salah satu skenario penggunaan label dengan kondisi equality-based yaitu untuk kriteria pemilihan Node untuk Pod-Pod. Sebagai contoh, Pod percontohan di bawah ini akan memilih Node dengan label "accelerator=nvidia-tesla-p100".

apiVersion: v1
kind: Pod
metadata:
  name: cuda-test
spec:
  containers:
    - name: cuda-test
      image: "registry.k8s.io/cuda-vector-add:v0.1"
      resources:
        limits:
          nvidia.com/gpu: 1
  nodeSelector:
    accelerator: nvidia-tesla-p100

Kondisi Set-based

Kondisi label Set-based memungkinkan memfilter key terhadap suatu kumpulan nilai. Terdapat tiga jenis operator yang didukung, yaitu: in,notin, dan exists (hanya key-nya saja). Contoh:

environment in (production, qa)
tier notin (frontend, backend)
partition
!partition

Contoh pertama akan memilih semua sumber daya dengan key environment dan nilai production atau qa. Contoh kedua akan memilih semua sumber daya dengan key tier dan nilai selain frontend dan backend, serta semua sumber daya yang tidak memiliki label dengan key tier. Contoh ketiga akan memilih semua sumber daya yang memiliki key dari labelpartition; nilainya tidak diperiksa. Sedangkan contoh keempat akan memilih semua sumber daya yang tidak memiliki label dengan key partition; nilainya tidak diperiksa. Secara serupa, operator koma bertindak sebagai operator AND. Sehingga penyaringan sumber daya dengan key partition (tidak peduli nilai dari key) dan environment yang tidak sama dengan qa dapat dicapai dengan partition,environment notin (qa). Selektor label set-based merupakan bentuk umum persamaan karena environment=production sama dengan environment in (production); demikian pula != dan notin.

Kondisi Set-based dapat digabungkan dengan kondisi equality-based. Contoh: partition in (customerA, customerB),environment!=qa.

API

Penyaringan LIST dan WATCH

Operasi LIST dan WATCH dapat menentukan selektor label untuk memfilter suatu kumpulan objek yang didapat dengan menggunakan parameter kueri. Kedua jenis kondisi diperbolehkan (ditampilkan sebagai berikut, sama seperti saat tampil pada string kueri di URL):

• Kondisi equality-based: ?labelSelector=environment%3Dproduction,tier%3Dfrontend
• Kondisi set-based: ?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29

Kedua jenis selektor label dapat digunakan untuk menampilkan (list) dan mengamati (watch) sumber daya melalui klien REST. Contohnya, menargetkan apiserver dengan kubectl dan menggunakan equality-based kamu dapat menuliskan:

kubectl get pods -l environment=production,tier=frontend

atau menggunakan kondisi set-based:

kubectl get pods -l 'environment in (production),tier in (frontend)'

Seperti yang telah disebutkan sebelumnya, kondisi set-based lebih ekspresif. Sebagai contoh, mereka dapat digunakan untuk mengimplementasi operator OR pada nilai:

kubectl get pods -l 'environment in (production, qa)'

atau membatasi pencocokan negatif dengan operator notin:

kubectl get pods -l 'environment,environment notin (frontend)'

Mengatur referensi pada objek API

Pada beberapa objek Kubernetes, seperti Service dan ReplicationController, juga menggunakan selektor label untuk menentukan kumpulan dari sumber daya lain, seperti Pod.

Service dan ReplicationController

Kumpulan Pod yang ditargetkan oleh sebuah service ditentukan dengan selektor label. Demikian pula kumpulan Pod yang harus ditangani oleh replicationcontroller juga ditentukan dengan selektor label.

Selektor label untuk kedua objek tersebut ditentukan dalam berkas json atau yaml menggunakan maps, dan hanya mendukung kondisi equality-based:

"selector": {
    "component" : "redis",
}

atau

selector:
    component: redis

selektor ini (baik dalam bentuk json atau yaml) sama dengan component=redis atau component in (redis).

Sumber daya yang mendukung kondisi set-based

Sumber daya yang lebih baru, seperti Job, Deployment, ReplicaSet, dan DaemonSet, juga mendukung kondisi set-based.

selector:
  matchLabels:
    component: redis
  matchExpressions:
    - {key: tier, operator: In, values: [cache]}
    - {key: environment, operator: NotIn, values: [dev]}

matchLabels merupakan pemetaan dari pasangan {key,value}. Sebuah {key,value} pada pemetaan matchLabels adalah sama dengan elemen dari matchExpressions, yang nilai key nya adalah "key", dengan operator "In", dan array values hanya berisi "value". matchExpressions merupakan daftar kondisi untuk selektor Pod. Operator yang valid termasuk In, NotIn, Exists, dan DoesNotExist. Kumpulan nilai ini tidak boleh kosong pada kasus In dan NotIn. Semua kondisi, baik dari matchLabels dan matchExpressions di-AND secara sekaligus -- mereka harus memenuhi semua kondisi agar cocok.

Memilih kumpulan Node

Salah satu contoh penggunaan pemilihan dengan menggunakan label yaitu untuk membatasi suatu kumpulan Node tertentu yang dapat digunakan oleh Pod. Lihat dokumentasi pada pemilihan Node untuk informasi lebih lanjut.

6 - Anotasi

Kamu dapat menggunakan fitur anotasi dari Kubernetes untuk menempelkan sembarang metadata tanpa identitas pada suatu objek. Klien, seperti perangkat dan library, dapat memperoleh metadata tersebut.

Mengaitkan metadata pada objek

Kamu dapat menggunakan label maupun anotasi untuk menempelkan metadata pada suatu objek Kubernetes. Label dapat digunakan untuk memilih objek dan mencari sekumpulan objek yang memenuhi kondisi tertentu. Sebaliknya, anotasi tidak digunakan untuk mengenali atau memilih objek. Metadata dalam sebuah anotasi bisa berukuran kecil atau besar, terstruktur atau tidak terstruktur, dan dapat berisikan karakter-karakter yang tidak diperbolehkan oleh label.

Anotasi, seperti label, merupakan pemetaan key/value:

"metadata": {
  "annotations": {
    "key1" : "value1",
    "key2" : "value2"
  }
}

Berikut merupakan beberapa contoh informasi yang dapat dicatat dengan menggunakan anotasi:

• Field-field yang dikelola secara deklaratif oleh layer konfigurasi. Menempelkan field-field tersebut sebagai anotasi membedakan mereka dari nilai default yang ditetapkan oleh klien ataupun server, dari field-field yang otomatis di-generate, serta dari field-field yang ditetapkan oleh sistem auto-sizing atau auto-scaling.

• Informasi mengenai build, rilis, atau image, seperti timestamp, rilis ID, git branch, nomor PR, hash suatu image, dan alamat registri.

• Penanda untuk logging, monitoring, analytics, ataupun repositori audit.

• Informasi mengenai library klien atau perangkat yang dapat digunakan untuk debugging: misalnya, informasi nama, versi, dan build.

• Informasi yang berhubungan dengan pengguna atau perangkat/sistem, seperti URL objek yang terkait dengan komponen dari ekosistem lain.

• Metadata untuk perangkat rollout yang ringan (lightweight): contohnya, untuk konfigurasi atau penanda (checkpoint).

• Nomor telepon atau pager dari orang yang bertanggung jawab, atau entri direktori yang berisi informasi lebih lanjut, seperti website sebuah tim.

• Arahan dari pengguna (end-user) untuk melakukan implementasi, perubahan perilaku, ataupun untuk interaksi dengan fitur-fitur non-standar.

Tanpa menggunakan anotasi, kamu dapat saja menyimpan informasi-informasi dengan tipe di atas pada suatu basis data atau direktori eksternal, namun hal ini sangat mempersulit pembuatan library klien dan perangkat yang bisa digunakan sama-sama (shared) untuk melakukan deploy, pengelolaan, introspeksi, dan semacamnya.

Sintaksis dan sekumpulan karakter

Anotasi merupakan key/value pair. Key dari sebuah anotasi yang valid memiliki dua segmen: segmen prefiks yang opsional dan segmen nama, dipisahkan oleh sebuah garis miring (/). Segmen nama bersifat wajib dan harus terdiri dari 63 karakter atau kurang, dimulai dan diakhiri dengan karakter alfanumerik ([a-z0-9A-Z]) dengan tanda minus (-), garis bawah (_), titik (.), dan alfanumerik di tengahnya. Jika terdapat prefiks, prefiks haruslah berupa subdomain DNS: urutan dari label DNS yang dipisahkan oleh titik (.), totalnya tidak melebihi 253 karakter, diikuti dengan garis miring (/).

Jika tidak terdapat prefiks, maka key dari anotasi diasumsikan hanya bisa dilihat oleh pengguna (privat). Komponen sistem otomasi (seperti kube-scheduler, kube-controller-manager, kube-apiserver, kubectl, ataupun otomasi pihak ketiga) yang menambahkan anotasi pada objek-objek pengguna harus memiliki sebuah prefiks.

Prefiks kubernetes.io/ dan k8s.io/ merupakan reservasi dari komponen inti Kubernetes.

Selanjutnya

Pelajari lebih lanjut tentang Label dan Selektor.

7 - Selektor Field

Selektor field memungkinkan kamu untuk memilih (select) resource Kubernetes berdasarkan nilai dari satu atau banyak field resource. Di bawah ini merupakan contoh dari beberapa query selektor field:

• metadata.name=my-service
• metadata.namespace!=default
• status.phase=Pending

Perintah kubectl di bawah ini memilih semua Pod dengan field status.phase yang bernilai Running:

kubectl get pods --field-selector status.phase=Running

kubectl get pods
kubectl get pods --field-selector ""

Field yang didukung

Selektor-selektor field yang didukung oleh Kubernetes bervariasi tergantung dari tipe resource. Semua tipe resource mendukung field metadata.name dan metadata.namespace. Jika kamu menggunakan selektor field yang tidak didukung, maka akan terjadi error. Contohnya:

kubectl get ingress --field-selector foo.bar=baz

Error from server (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace"

Operator yang didukung

Kamu dapat menggunakan operator =, ==, dan != pada selektor field (= dan == punya arti yang sama). Sebagai contoh, perintah kubectl ini memilih semua Kubernetes Service yang tidak terdapat pada namespace default:

kubectl get services --field-selector metadata.namespace!=default

Selektor berantai

Seperti halnya label dan selektor-selektor lainnya, kamu dapat membuat selektor field berantai (chained) dengan list yang dipisahkan oleh koma. Perintah kubectl di bawah ini memilih semua Pod dengan status.phase tidak sama dengan Running dan field spec.restartPolicy sama dengan Always:

kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always

Resource dengan beberapa tipe

Kamu dapat menggunakan selektor-selektor field dengan beberapa tipe resource sekaligus. Perintah kubectl di bawah ini memilih semua Statefulset dan Service yang tidak terdapat pada namespace default:

kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default

8 - Label yang Disarankan

Kamu dapat melakukan visualisasi dan mengatur objek Kubernetes dengan lebih banyak tools dibandingkan dengan perintah kubectl dan dasbor. Sekumpulan label mengizinkan tools untuk bekerja dengan interoperabilitas, mendeskripsikan objek dengan cara yang umum yang dapat dipahami semua tools.

Sebagai tambahan bagi tooling tambahan, label yang disarankan ini mendeskripsikan aplikasi sehingga informasi yang ada diapat di-query.

Metadata ini diorganisasi berbasis konsep dari sebuah aplikasi. Kubernetes bukan merupakan sebuah platform sebagai sebuah service (platform as a service/PaaS) dan tidak mewajibkan sebuah gagasan formal dari sebuah aplikasi. Sebagai gantinya, aplikasi merupakan suatu hal informal yang dideskripsikan melalui metadata. Definisi yang dimiliki oleh sebuah aplikasi merupakan sebuah hal yang cukup longgar.

Label yang digunakan secara umum serta anotasi memiliki prefiks yang serupa: app.kubernetes.io. Label tanpa sebuah prefiks bersifat privat khusus pengguna saja. Prefiks yang digunakan secara umum tadi menjamin bahwa label tadi tidak akan mengganggu label custom yang diberikan oleh pengguna.

Label

Untuk mendapatkan keuntungan menyeluruh dari penggunaan label ini, label harus digunakan pada seluruh objek sumber daya.

Untuk memberikan ilustrasi dari penggunaan label, bayangkan sebuah objek StatefulSet yang didefinisikan sebagai berikut:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app.kubernetes.io/name: mysql
    app.kubernetes.io/instance: wordpress-abcxzy
    app.kubernetes.io/version: "5.7.21"
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
    app.kubernetes.io/managed-by: helm

Aplikasi dan Instans Aplikasi

Sebuah aplikasi dapat diinstal sekali atau beberapa kali di dalam klaster Kubernetes dan, pada beberapa kasus, di dalam sebuah namespace yang sama. Misalnya, wordpress dapat diinstal lebih dari satu kali dimana situs web yang berbeda merupakan hasil instalasi yang berbeda.

Nama dari sebuah aplikasi dan nama instans akan dicatat secara terpisah. Sebagai contoh, WordPress memiliki wordpress sebagai nilai dari app.kubernetes.io/name dimana nama instans yang digunakan adalah wordpress-abcxzy yang merupakan nilai dari app.kubernetes.io/instance. Hal ini memungkinkan aplikasi dan instans aplikasi untuk dapat diidentifikasi. Setiap instans dari aplikasi haruslah memiliki nama yang unik.

Contoh

Untuk memberikan ilustrasi dengan cara yang berbeda pada penggunaan label, contoh di bawah ini memiliki tingkat kompleksitas yang cukup beragam.

Sebuah Aplikasi Stateless Sederhana

Bayangkan sebuah kasus dimana sebuah aplikasi stateless di-deploy menggunakan Deployment dan Service. Di bawah ini merupakan contoh kutipan yang merepresentasikan bagaimana label dapat digunakan secara sederhana.

Deployment digunakan untuk memastikan Pod dijalankan untuk aplikasi itu sendiri.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: myservice
    app.kubernetes.io/instance: myservice-abcxzy
...

Service digunakan untuk mengekspos aplikasi.

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: myservice
    app.kubernetes.io/instance: myservice-abcxzy
...

Sebuah Aplikasi Web dengan Basis Data

Bayangkan sebuah aplikasi yang lebih kompleks: sebuah aplikasi web (WordPress) yang menggunakan basis data (MySQL), yang diinstal menggunakan Helm. Kutipan berikut merepresentasikan objek yang di-deploy untuk aplikasi ini.

Berikut merupakan konfigurasi Deployment yang digunakan untuk WordPress:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: wordpress
    app.kubernetes.io/instance: wordpress-abcxzy
    app.kubernetes.io/version: "4.9.4"
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/component: server
    app.kubernetes.io/part-of: wordpress
...

Service yang digunakan untuk mengekspos WordPress:

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: wordpress
    app.kubernetes.io/instance: wordpress-abcxzy
    app.kubernetes.io/version: "4.9.4"
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/component: server
    app.kubernetes.io/part-of: wordpress
...

MySQL diekspos sebagai StatefulSet dengan metadata yang digunakan untuk StatefulSet tersebut serta aplikasi yang menggunakannya:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  labels:
    app.kubernetes.io/name: mysql
    app.kubernetes.io/instance: mysql-abcxzy
    app.kubernetes.io/version: "5.7.21"
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
...

Service yang digunakan untuk mengekspos MySQL sebagai bagian dari WordPress:

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: mysql
    app.kubernetes.io/instance: mysql-abcxzy
    app.kubernetes.io/version: "5.7.21"
    app.kubernetes.io/managed-by: helm
    app.kubernetes.io/component: database
    app.kubernetes.io/part-of: wordpress
...

Dengan StatefulSet MySQL dan Service kamu dapat mengetahui informasi yang ada pada MySQL dan Wordpress.