Ikhtisar

• 1: Apa itu Kubernetes?
• 2: Komponen-Komponen Kubernetes
• 3: API Kubernetes
• 4: Menggunakan Objek-Objek Kubernetes
• 4.1: Memahami Konsep Objek-Objek yang ada pada Kubernetes
• 4.2: Pengaturan Objek Kubernetes
• 4.3: Nama
• 4.4: Namespace
• 4.5: Label dan Selektor
• 4.6: Anotasi
• 4.7: Selektor Field
• 4.8: Label yang Disarankan

1 - Apa itu Kubernetes?

Laman ini merupakan ikhtisar Kubernetes.

Kubernetes merupakan platform open-source yang digunakan untuk melakukan manajemen workloads aplikasi yang dikontainerisasi, serta menyediakan konfigurasi dan otomatisasi secara deklaratif. Kubernetes berada di dalam ekosistem yang besar dan berkembang cepat. Service, support, dan perkakas Kubernetes tersedia secara meluas.

Google membuka Kubernetes sebagai proyek open source pada tahun 2014. Kubernetes dibangun berdasarkan pengalaman Google selama satu setengah dekade dalam menjalankan workloads bersamaan dengan kontribusi berupa ide-ide terbaik yang diberikan oleh komunitas.

Mengapa Kubernetes dan hal apa saja yang dapat dilakukan oleh Kubernetes?

Kubernetes memiliki sejumlah fitur yang dapat dijabarkan sebagai berikut:

• platform kontainer
• platform microservices
• platform cloud yang tidak mudah dipindahkan

Kubernetes menyediakan manajemen environment yang berpusat pada kontainer. Kubernetes melakukan orkestrasi terhadap computing, networking, dan inftrastruktur penyimpanan. Fitur inilah yang kemudian membuat konsep Platform as a Service (PaaS) menjadi lebih sederhana dilengkapi dengan fleksibilitas yang dimiliki oleh Infrastructure as a Service (IaaS).

Lalu apa yang menyebabkan Kubernetes disebut sebagai sebuah platform?

Meskipun Kubernetes menyediakan banyak fungsionalitas, selalu ada keadaan dimana hal tersebut membutuhkan fitur baru. Workflow spesifik yang terkait dengan proses pengembangan aplikasi dapat ditambahkan pada streamline untuk meningkatkan produktivitas developer. Orkestrasi ad-hoc yang dapat diterima biasanya membutuhkan desain otomatisasi yang kokoh agar bersifat scalable. Hal inilah yang membuat Kubernetes juga didesain sebagai platform untuk membangun ekosistem komponen dan dan perkakas untuk memudahkan proses deployment, scale, dan juga manajemen aplikasi.

Labels memudahkan pengguna mengkategorisasikan resources yang mereka miliki sesuai dengan kebutuhan. Annotations memungkinkan pengguna untuk menambahkan informasi tambahan pada resource yang dimiliki.

Selain itu, Kubernetes control plane dibuat berdasarkan API yang tersedia bagi pengguna dan developer. Pengguna dapat mengimplementasikan kontroler sesuai dengan kebutuhan mereka, contohnya adalah schedulers, dengan API kustom yang mereka miliki, kontroler kustom ini kemudian dapat digunakan pada command-line tool generik yang ada.

Desain inilah yang memungkinkan beberapa sistem lain untuk dapat dibangun di atas Kubernetes.

Lalu hal apakah yang tidak termasuk di dalam Kubernetes?

Kubernetes bukanlah sebuah PaaS (Platform as a Service) yang biasanya. Meskipun Kubernetes dijalankan pada tingkatan kontainer dan bukan pada tingkatan perangkat keras, Kubernetes menyediakan beberapa fitur yang biasanya disediakan oleh Paas, seperti deployment, scaling, load balancing, logging, dan monitoring. Akan tetapi, Kubernetes bukanlah sistem monolitik, melainkan suatu sistem yang bersifat sebagai bulding block dan pluggable yang dapat digunakan untuk membangun sebuah platform yang dibutuhkan oleh developer dengan tetap mengutamakan konsep fleksibilitas.

Kubernetes:

• Tidak melakukan limitasi terhadap aplikasi yang di-support. Kubernetes bertujuan untuk mendukung berbagai variasi workloads, termasuk stateless, stateful, dan data-processing. Jika sebuah aplikasi dapat dijalankan di atas kontainer, maka aplikasi tersebut juga dapat dijalankan di atas Kubernetes.
• Tidak menyediakan mekanisme untuk melakukan deploy kode sumber maupun mekanisme build sebuah aplikasi. Continuous Integration, Delivery, and Deployment (CI/CD) workflows ditentukan oleh preferensi serta kebutuhan teknis organisasi.
• Tidak menyediakan application-level services, seperti middleware (e.g., message buses), data-processing frameworks (for example, Spark), databases (e.g., mysql), caches, maupun cluster storage systems (e.g., Ceph) sebagai suatu built-in services. Komponen tersebut dapat dijalankan di atas Kubernetes, dan/atau dapat diakses oleh aplikasi yang dijalankan di atas Kubernetes melalui sebuah mekanisme tidak mudah dipindahkan misalnya saja Open Service Broker.
• Tidak membatasi penyedia layanan logging, monitoring, maupun alerting yang digunakan. Kubernetes menyediakan proof of concept dan mekanisme integrasi yang dapat digunakan untuk mengumpulkan serta mengekspor metriks yang ada.
• Tidak menyediakan atau mengharuskan penggunaan configuration language/system (e.g., jsonnet). Kubernetes menyediakan suatu API deklaratif yang dapat digunakan oleh berbagai jenis spesifikasi deklaratif.
• Tidak menyediakan atau mengadaptasi sebuah konfigurasi, maintenance, manajemen, atau self-healing mesin dengan spesifikasi khusus.

Sebagai tambahan, Kubernetes bukanlah sebuah sitem orkestrasi biasa. Bahkan pada kenyataannya, Kubernetes menghilangkan kebutuhan untuk melakukan orkestrasi. Definisi teknis dari orkestrasi merupakan eksekusi dari sebuah workflow yang sudah didefinisikan sebelumnya: pertama kerjakan A, kemudian B, dan terakhir C. Sebaliknya, Kubernetes disusun oleh seperangkat proses kontrol yang dapat idekomposisi yang selalu menjalankan state yang ada saat ini hingga sesuai dengan state yang dinginkan. Kita tidak perlu peduli proses apa saja yang perlu dilakukan untuk melakukan A hingga C. Mekanisme kontrol yang tersentralisasi juga tidak dibutuhkan. Dengan demikian, sistem yang dihasilkan lebih mudah digunakan lebih kokoh, serta lebih extensible.

Mengapa kontainer?

Mencari alasan kenapa kita harus menggunakan kontainer?

Cara Lama untuk melakukan mekanisme deploy suatu aplikasi adalah dengan cara instalasi aplikasi tersebut pada sebuah mesin dengan menggunakan package manager yang dimiliki oleh sistem operasi mesin tersebut. Hal ini menciptakan suatu ketergantungan antara executables, konfigurasi, serta ketergantungan lain yang dibutuhkan aplikasi dengan sistem operasi yang digunakan oleh mesin. Untuk mengatasi hal ini, tentunya bisa saja kita melakukan mekanisme build suatu image VM yang immutable untuk mendapatkan mekanisme rollouts dan rollback yang dapat diprediksi. Meskipun demikian, VM masih dianggap "berat" dan tidak tidak mudah dipindahkan.

Cara Baru adalah dengan melakukan mekanisme deploy kontainer pada tingkatan virtualisasi di level sistem operasi (OS) bukan pada tingkatan virtualisasi perangkat keras. Kontainer ini berada dalam lingkungan yang terisolasi satu sama lain serta terisolasi dengan mesin dimana kontainer ini berada. Kontainer ini memiliki filesystems masing-masing. Selain itu, setiap kontainer tidak dapat "melihat" process yang sedang dijalankan di kontainer lain. Selain itu resource komputasi yang digunakan oleh kontainer ini juga dapat dibatasi. Kontainer juga dapat dengan lebih mudah di-build jika dibandingkan dengan VM, karena kontainer tidak bergantung pada filesystem yang dimiliki mesin, serta dengan mudah dapat didistribusikan.

Karena kontainer ukurannya kecil dan lebih cepat, sebuah aplikasi dapat dibangun di setiap image kontainer. Mekanisme pemetaan satu-satu antara kontainer dan aplikasi inilah yang membuka keuntungan secara meyeluruh yang dapat diberikan oleh kontainer. Dengan menggunakan kontainer, image kontainer dapat dibuat diwaktu rilis aplikasi. Pembuatan image ini memungkinkan aplikasi secara konsisten dirilis pada environment development maupun production. Selain itu, kontainer juga memiliki transparasi yang lebih tinggi dibandingkan dengan VM. Maksudnya, infrastruktur punya tugas untuk mengatur lifecycle seluruh process yang ada di dalam kontainer. Ini bukanlah lagi tugas sebuah supervisor process yang tersembunyi di dalam kontainer.

Secara garis besar, penggunaan kontainer memiliki keuntungan sebagai berikut:

• Mekanisme pembuatan aplikasi serta proses deployment yang lebih efektif: Kontainer dapat meningkatkan kemudahan dan efisiensi jika dibandingkan dengan penggunaan VM.
• Continuous development, integration, and deployment: Digunakan untuk melakukan proses build dan deploy yang sering dilakukan serta kemudahan mekanisme rollback karena image yang ada sifatnya immutable.
• Pemisahan kepentingan antara Dev dan Ops: Pembuatan image container dilakukan pada saat rilis dan bukan pada saat deploy mengurangi ketergantungan aplikasi dan infrastruktur.
• Observabilitas Tidak hanya informasi dan metriks pada level OS, tapi juga kesehatan aplikasi dan signal lain.
• Konsistensi environment pada masa pengembangan , testing, dan production: Memiliki perilaku yang sama baik ketika dijalankan di mesin lokal maupun penyedia layanan cloud.
• Portabilitas antar penyedia layanan cloud maupun distribusi OS: Dapat dijalankan pada Ubuntu, RHEL, CoreOS, on-prem, Google Kubernetes Engine, dan dimanapun.
• Manajemen yang bersifat Aplikasi sentris: Meningkatkan level abstraksi dari proses menjalankan OS pada perangkat keras virtual ke proses menjalankan aplikasi pada sebuah OS dengan menggunakan resource logis.
• Mikroservis yang renggang (loosely coupled), terdistribusi, elastis, dan terliberasi: Aplikasi dapat dipecah menjadi komponen yang lebih kecil yang independen dan dapat di-deploy dan diatur secara dinamis -- bukan sebuah sistem monolitik yang dijalankan pada sebuah mesin yang hanya punya satu tujuan.
• Isolasi resource: Performa aplikasi yang bisa diprediksi.
• Utilisasi resource: Efisiensi yang tinggi

Apakah arti Kubernetes? K8s?

Nama Kubernetes berasal dari Bahasa Yunani, yang berarti juru mudi atau pilot, dan merupakan asal kata gubernur dan cybernetic. K8s merupakan sebuah singkatan yang didapat dengan mengganti 8 huruf "ubernete" dengan "8".

Selanjutnya

• Siap untuk memulai?
• Untuk penjelasan lebih rinci, silahkan lihat Dokumentasi Kubernetes.

2 - Komponen-Komponen Kubernetes

Dokumen ini merupakan ikhtisar yang mencakup berbagai komponen yang dibutuhkan agar klaster Kubernetes dapat berjalan secara fungsional.

Komponen Master

Komponen master menyediakan control plane bagi klaster. Komponen ini berperan dalam proses pengambilan secara global pada klaster (contohnya, mekanisme schedule), serta berperan dalam proses deteksi serta pemberian respons terhadap events yang berlangsung di dalam klaster (contohnya, penjadwalan pod baru apabila jumlah replika yang ada pada replication controller tidak terpenuhi).

Komponen master dapat dijalankan di mesin manapun yang ada di klaster. Meski begitu, untuk memudahkan proses yang ada, script inisiasi awal yang dijalankan biasanya memulai komponen master pada mesin yang sama, serta tidak menjalankan kontainer bagi pengguna di mesin ini. Contoh konfigurasi multi-master VM dapat dilihat di modul [Membangun Klaster HA] (/docs/admin/high-availability/).

kube-apiserver

Komponen control plane yang mengekspos API Kubernetes. Merupakan front-end dari control plane Kubernetes.

Komponen ini didesain agar dapat diskalakan secara horizontal. Lihat Membangun Klaster HA.

etcd

Penyimpanan key value konsisten yang digunakan sebagai penyimpanan data klaster Kubernetes.

Selalu perhatikan mekanisme untuk mem-backup data etcd pada klaster Kubernetes kamu. Untuk informasi lebih lanjut tentang etcd, lihat dokumentasi etcd.

kube-scheduler

Komponen control plane yang bertugas mengamati Pod baru yang belum ditempatkan di node manapun dan kemudian memilihkan Node di mana Pod baru tersebut akan dijalankan.

Faktor-faktor yang dipertimbangkan untuk keputusan penjadwalan termasuk: kebutuhan sumber daya secara individual dan kolektif, batasan perangkat keras/perangkat lunak/peraturan, spesifikasi afinitas dan nonafinitas, lokalisasi data, interferensi antar beban kerja dan tenggat waktu.

kube-controller-manager

Komponen control plane yang menjalankan pengontrol.

Secara logis, setiap pengontrol adalah sebuah proses yang berbeda, tetapi untuk mengurangi kompleksitas, kesemuanya dikompilasi menjadi sebuah biner (binary) yang dijalankan sebagai satu proses.

Kontroler-kontroler ini meliputi:

• Kontroler Node : Bertanggung jawab untuk mengamati dan memberikan respons apabila jumlah node berkurang.
• Kontroler Replikasi : Bertanggung jawab untuk menjaga jumlah pod agar jumlahnya sesuai dengan kebutuhan setiap objek kontroler replikasi yang ada di sistem.
• Kontroler Endpoints : Menginisiasi objek Endpoints (yang merupakan gabungan Pods dan Services).
• Kontroler Service Account & Token: Membuat akun dan akses token API standar untuk setiap namespaces yang dibuat.

cloud-controller-manager

Cloud-controller-manager merupakan kontroler yang berinteraksi dengan penyedia layanan cloud. Kontroler ini merupakat fitur alfa yang diperkenalkan pada Kubernetes versi 1.6.

Cloud-controller-manager hanya menjalankan iterasi kontroler cloud-provider-specific . Kamu harus menonaktifkan iterasi kontroler ini pada kube-controller-manager. Kamu dapat menonaktifka iterasi kontroler ini dengan mengubah nilai argumen --cloud-provider dengan external ketika menginisiasi kube-controller-manager.

Adanya cloud-controller-manager memungkinkan kode yang dimiliki oleh penyedia layanan cloud dan kode yang ada pada Kubernetes saling tidak bergantung selama masa development. Pada versi sebelumnya, Kubernetes bergantung pada fungsionalitas spesifik yang disediakan oleh penyedia layanan cloud. Di masa mendatang, kode yang secara spesifik dimiliki oleh penyedia layanan cloud akan dipelihara oleh penyedia layanan cloud itu sendiri, kode ini selanjutnya akan dihubungkan dengan cloud-controller-manager ketika Kubernetes dijalankan.

Kontroler berikut ini memiliki keterkaitan dengan penyedia layanan cloud:

• Kontroler Node : Melakukan pengecekan pada penyedia layanan cloud ketika menentukan apakah sebuah node telah dihapus pada cloud apabila node tersebut berhenti memberikan respons.
• Kontroler Route : Melakukan pengaturan awal route yang ada pada penyedia layanan cloud
• Kontroler Service : Untuk membuat, memperbaharui, menghapus load balancer yang disediakan oleh penyedia layanan cloud
• Kontroler Volume : Untuk membuat, meng-attach, dan melakukan mount volume serta melakukan inetraksi dengan penyedia layanan cloud untuk melakukan orkestrasi volume

Komponen Node

Komponen ini ada pada setiap node, fungsinya adalah melakukan pemeliharaan terhadap pod serta menyediakan environment runtime bagi Kubernetes.

kubelet

Agen yang dijalankan pada setiap node di klaster yang bertugas untuk memastikan kontainer dijalankan di dalam Pod.

kube-proxy

kube-proxy membantu abstraksi service Kubernetes melakukan tugasnya. Hal ini terjadi dengan cara memelihara aturan-aturan jaringan (network rules) serta meneruskan koneksi yang ditujukan pada suatu host.

Container Runtime

Container runtime adalah perangkat lunak yang bertanggung jawab dalam menjalankan kontainer. Kubernetes mendukung beberapa runtime, diantaranya adalah: Docker, containerd, cri-o, rktlet dan semua implementasi Kubernetes CRI (Container Runtime Interface).

Addons

Addons merupakan pod dan service yang mengimplementasikan fitur-fitur yang diperlukan klaster.

Beberapa addons akan dijelaskan selanjutnya.

DNS

Meskipun tidak semua addons dibutuhkan, semua klaster Kubernetes hendaknya memiliki DNS klaster. Komponen ini penting karena banyak dibutuhkan oleh komponen lainnya.

Klaster DNS adalah server DNS, selain beberapa server DNS lain yang sudah ada di environment kamu, yang berfungsi sebagai catatan DNS bagi Kubernetes services

Kontainer yang dimulai oleh kubernetes secara otomatis akan memasukkan server DNS ini ke dalam mekanisme pencarian DNS yang dimilikinya.

Web UI (Dasbor)

Dasbor adalah antar muka berbasis web multifungsi yang ada pada klaster Kubernetes. Dasbor ini memungkinkan user melakukan manajemen dan troubleshooting klaster maupun aplikasi yang ada pada klaster itu sendiri.

Container Resource Monitoring

Container Resource Monitoring mencatat metrik time-series yang diperoleh dari kontainer ke dalam basis data serta menyediakan antar muka yang dapat digunakan untuk melakukan pencarian data yang dibutuhkan.

Cluster-level Logging

Cluster-level logging bertanggung jawab mencatat log kontainer pada penyimpanan log terpusat dengan antar muka yang dapat digunakan untuk melakukan pencarian.

3 - API Kubernetes

Secara keseluruhan standar yang digunakan untuk API dijelaskan di dalam dokumentasi API standar.

Endpoints API, resource types serta contoh penggunaan dijelaskan di dalam API Reference.

Akses remote penggunaan API dijelaskan di dalam dokumentasi akses API.

API Kubernetes juga berperan sebagai skema konfigurasi yang deklaratif di dalam sistem.. Sementara itu, kubectl merupakan command-line yang dapat digunakan untuk membuat, menmperbaharui, menghapus, dan mendapatkan obyek API.

Kubernetes menyimpan bentuk terserialisasi dari obyek API yang dimilikinya di dalam etcd.

Kubernetes sendiri dibagi menjadi beberapa komponen yang saling dapat saling interaksi melalui API.

Perubahan API

Berdasarkan pengalaman kami, semua sistem yang berhasil memerlukan kebutuhan untuk terus tumbuh dan berkembang seiring dengan bertambahnya kebutuhan yang ada. Dengan demikian, kami berekspektasi bahwa API akan selalu berubah seiring dengan bertambahnya kebutuhan yang ada. Meski begitu, perubahan yang ada akan selalu kompatibel dengan implementasi sebelumnya, untuk jangka waktu tertentu. Secara umum, penambahan pada sebuah resource API atau field resource bisa sering terjadi.. Penghapusan resource API atau suatu field, di sisi lain, diharapkan untuk dapat memenuhi kaidah deprecation API.

Hal-hal apa saja yang perlu diperhatikan untuk menjamin kompatibilitas API secara rinci dibahas di dalam dokumentasi perubahan API.

Swagger and OpenAPI Definition

Detail mengenai API didokumentasikan dengan menggunakan OpenAPI.

Semenjak Kubernetes versi 1.10, Kubernetes menghadirkan spesifikasi OpenAPI melalui endpoint /openapi/v2. Format request dapat diterapkan dengan cara menambahkan header HTTP:

Sebelum versi 1.14, terdapat 4 buah endpoint yang menyediakan spesifikasi OpenAPI dalam format berbeda yang dapat digunakan (/swagger.json, /swagger-2.0.0.json, /swagger-2.0.0.pb-v1, /swagger-2.0.0.pb-v1.gz). Endpoint ini bersifat deprecated dan akan dihapus pada Kubernetes versi 1.14.

Cara mendapatkan spesifikasi OpenAPI:

Kubernetes juga menyediakan alternatif mekanisme serialisasi lain, yaitu dengan menggunakan Protobuf, yang secara umum digunakan untuk mekanisme komunikasi intra-klaster, hal ini didokumentasikan di dalam proposal desain serta berkas IDL sebagai bentuk spesifikasi skema berada dalam package Go

Sebelum Kubernetes versi 1.14, apiserver Kubernetes juga mengekspos API yang dapat digunakan untuk mendapatkan spesifikasi Swagger v1.2 pada endpoint /swaggerapi. Endpoint ini akan sudah bersifat deprecated dan akan dihapus pada Kubernetes versi 1.14.

Pemberian Versi pada API

Untuk memudahkan restrukturisasi field dan resource yang ada, Kubernetes menyediakan beberapa versi API yang berada pada path yang berbeda, misalnya /api/v1 atau /apis/extensions/v1beta1.

Kita dapat memilih versi yang akan digunakan pada tingkatan API dan bukan pada tingkatan field atau resource untuk memastikan API yang digunakan memperlihatkan gambaran yang jelas serta konsisten mengenai resoure dan sifat sistem yang ada.

Perhatikan bahwa pemberian versi pada API dan pemberian versi pada API dan perangkat lunak memiliki keterkaitan secara tak langsung. Proposal API and release versioning memberikan deskripsi keterkaitan antara pemberian versi pada API dan pemberian versi pada perangkat lunak.

API dengan versi yang berbeda menunjukan tingkatan kestabilan dan ketersediaan yang diberikan pada versi tersebut. Kriteria untuk setiap tingkatan dideskripsikan secara lebih detail di dalam dokumentasi perubahan API. They are summarized here:

• Tingkatan Alpha:
  • Nama dari versi ini mengandung string alpha (misalnya, v1alpha1).
  • Bisa jadi terdapat bug. Secara default fitur ini tidak diekspos.
  • Ketersediaan untuk fitur yang ada bisa saja dihilangkan pada suatu waktu tanpa pemberitahuan sebelumnya.
  • API yang ada mungkin saja berubah tanpa memperhatikan kompatibilitas dengan versi perangkat lunak sebelumnya.
  • Hanya direkomendasikan untuk klaster yang digunakan untuk tujuan testing.
• Tingkatan Beta:
  • Nama dari versi ini mengandung string beta (misalnya v2beta3).
  • Kode yang ada sudah melalui mekanisme testing yang cukup baik. Menggunakan fitur ini dianggap cukup aman. Fitur ini diekspos secara default.
  • Ketersediaan untuk fitur secara menyeluruh tidak akan dihapus, meskipun begitu detail untuk suatu fitur bisa saja berubah.
  • Skema dan/atau semantik dari suatu obyek mungkin saja berubah tanpa memerhatikan kompatibilitas pada rilis beta selanjutnya. Jika hal ini terjadi, kami akan menyediakan suatu instruksi untuk melakukan migrasi di versi rilis selanjutnya. hal ini bisa saja terdiri dari penghapusan, pengubahan, ataupun pembuatan obyek API. Proses pengubahan mungkin saja membutuhkan pemikiran yang matang. Dampak proses ini bisa saja menyebabkan downtime aplikasi yang bergantung pada fitur ini.
  • Disarankan hanya untuk digunakan untuk penggunaan yang untuk penggunaan yang tidak berdampak langsung pada bisnis kamu.
  • Kami mohon untuk mencoba versi beta yang kami sediakan dan berikan masukan terhadap fitur yang kamu pakai! Apabila fitur tersebut sudah tidak lagi berada di dalam tingkatan beta perubahan yang kami buat terhadap fitur tersebut bisa jadi tidak lagi dapat digunakan
• Tingkatan stabil:
  • Nama dari versi ini mengandung string vX dimana X merupakan bilangan bulat.
  • Fitur yang ada pada tingkatan ini akan selalu muncul di rilis berikutnya.

API groups

Untuk memudahkan proses ekstensi suatu API Kubernetes, kami mengimplementasikan API groups. API group ini dispesifikasikan di dalam path REST serta di dalam field apiVersion dari sebuah obyek yang sudah diserialisasi.

Saat ini, terdapat beberapa API groups yang digunakan:

1. Kelompok core, seringkali disebut sebagai legacy group, berada pada path REST /api/v1 serta menggunakan apiVersion: v1.

2. Named groups berada pada path REST /apis/$GROUP_NAME/$VERSION, serta menggunakan apiVersion: $GROUP_NAME/$VERSION (misalnya apiVersion: batch/v1). Daftar menyeluruh mengenai apa saja API groups dapat dilihat di Kubernetes API reference.

Ekstensi API dengan custom resources dapat dilakukan melalui dua buah path:

1. CustomResourceDefinition digunakan jika memerlukan seluruh set semantik Kubernetes API, pengguna boleh implementasi apiserver sendiri dengan menggunakan aggregator.
2. Pengguna yang membutuhkan seperangkat semantik API Kubernetes API dapat mengimplementasikan apiserver mereka sendiri. dengan menggunakan aggregator untuk membuat integrasi dengan klien menjadi lebih mudah.

Mengaktifkan API groups

Beberapa resources dan API groups sudah diaktifkan secara default. Resource dan API groups ini dapat diaktifkan dan dinonaktifkan dengan mengatur penanda --runtime-config pada apiserver. --runtime-config menerima nilai yang dipisahkan oleh koma. Sebagai contoh: untuk menonaktifkan batch/v1, tetapkan --runtime-config=batch/v1=false, untuk mengaktifkan batch/v2alpha1, tetapkan --runtime-config=batch/v2alpha1. Penanda menerima nilai yang dipisahkan oleh pasangan key=value yang mendeskripsikan konfigurasi runtime pada apiserver.

PENTING: Melakukan proses mengaktifkan atau menonaktifkan groups atau resources membutuhkan mekanisme restart apiserver dan controller-manager agar apiserver dapat menerima perubahan --runtime-config.

Mengaktifkan resources di dalam groups

DaemonSets, Deployments, HorizontalPodAutoscalers, Ingresses, Jobs, dan ReplicaSets diaktifkan secara default. Ekstensi lain dapat diaktifkan penanda --runtime-config pada apiserver. Penanda --runtime-config menerima nilai yang dipisahkan oleh koma. Sebagai contoh untuk menonaktifkan deployments dan ingress, tetapkan. --runtime-config=extensions/v1beta1/deployments=false,extensions/v1beta1/ingresses=false

4 - Menggunakan Objek-Objek Kubernetes

4.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.

4.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

Peringatan: Sebuah objek Kubernetes hanya boleh diatur dengan menggunakan satu metode saja. Mengkombinasikan beberapa metode untuk objek yang sama dapat menghasilkan perilaku yang tidak diinginkan.

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.

Peringatan: Perintah imperatif replace menggantikan spek yang sudah ada dengan spek yang baru, membuang semua perubahan terhadap objek tersebut yang tidak didefinisikan pada berkas konfigurasi. Metode ini sebaiknya tidak dilakukan pada tipe sumber daya yang spek-nya diperbarui secara independen di luar berkas konfigurasi. Service dengan tipe LoadBalancer, sebagai contoh, memiliki field externalIPs yang diperbarui secara independen di luar konfigurasi, dilakukan oleh klaster.

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.

Catatan: Konfigurasi objek deklaratif mempertahankan perubahan yang dibuat oleh penulis lainnya, bahkan jika perubahan tidak digabungkan (merge) kembali pada berkas konfigurasi objek. Hal ini bisa terjadi dengan menggunakan operasi API patch supaya hanya perbedaannya saja yang ditulis, daripada menggunakan operasi API replace untuk menggantikan seluruh konfigurasi objek.

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

4.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.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

4.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.

Catatan: Untuk beberapa tipe API, seperti ReplicaSet, selektor label untuk dua objek tidak boleh tumpang tindih dengan Namespace, jika tidak maka controller akan melihatnya sebagai instruksi yang menyebabkan konflik dan akan gagal menentukan berapa banyak replika yang seharusnya tersedia.

Perhatian: Untuk kedua kondisi equality-based dan set-based tidak ada logika operator OR (||). Pastikan struktur pernyataan filter kamu ikut disesuaikan.

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: "k8s.gcr.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 exists:

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.

4.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.

4.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

Catatan:

Pada dasarnya, selektor field merupakan filter dari resource. Secara default, tidak ada selektor/filter apapun yang diterapkan. Artinya, semua resource dengan tipe apapun akan terpilih. Akibatnya, query dengan perintah kubectl di bawah ini akan memberikan hasil yang sama:

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

4.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.

Catatan: Berikut merupakan label yang disarankan. Label ini mempermudah proses manajemen aplikasi tetapi tidak dibutuhkan untuk tooling utama apa pun.

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.