Konsep

• 1: Ikhtisar
• 1.1: Apa itu Kubernetes?
• 1.2: Komponen-Komponen Kubernetes
• 1.3: API Kubernetes
• 1.4: Menggunakan Objek-Objek Kubernetes
• 1.4.1: Memahami Konsep Objek-Objek yang ada pada Kubernetes
• 1.4.2: Pengaturan Objek Kubernetes
• 1.4.3: Nama
• 1.4.4: Namespace
• 1.4.5: Label dan Selektor
• 1.4.6: Anotasi
• 1.4.7: Selektor Field
• 1.4.8: Label yang Disarankan
• 2: Arsitektur Kubernetes
• 2.1: Node
• 2.2: Komunikasi antara Control Plane dan Node
• 2.3: Controller
• 2.4: Konsep-konsep di balik Controller Manager
• 3: Kontainer
• 3.1: Ikhtisar Kontainer
• 3.2: Image
• 3.3: Kontainer Environment
• 3.4: Runtime Class
• 3.5: Lifecyle Hook pada Kontainer
• 4: Workloads
• 4.1: Pods
• 4.1.1: Pengenalan Pod
• 4.1.2: Pod
• 4.1.3: Siklus Hidup Pod
• 4.1.4: Init Container
• 4.1.5: Batasan Persebaran Topologi Pod
• 4.1.6: Pod Preset
• 4.1.7: Disrupsi
• 4.1.8: Kontainer Sementara (Ephemeral)
• 4.2: Controllers
• 4.2.1: ReplicaSet
• 4.2.2: ReplicationController
• 4.2.3: Deployment
• 4.2.4: StatefulSet
• 4.2.5: DaemonSet
• 4.2.6: Garbage Collection
• 4.2.7: Pengendali TTL untuk Sumber Daya yang Telah Selesai Digunakan
• 4.2.8: Jobs
• 4.2.9: CronJob
• 5: Services, Load Balancing, dan Jaringan
• 5.1: Service
• 5.2: Topologi Service (Service Topology)
• 5.3: EndpointSlice
• 5.4: DNS untuk Service dan Pod
• 5.5: Menghubungkan aplikasi dengan Service
• 5.6: Ingress
• 5.7: Kontroler Ingress
• 5.8: NetworkPolicy
• 5.9: Menambahkan Entry pada /etc/hosts Pod dengan HostAliases
• 5.10: Dual-stack IPv4/IPv6
• 6: Storage
• 6.1: Volume
• 6.2: Persistent Volume
• 6.3: VolumeSnapshot
• 6.4: Pengklonaan Volume CSI
• 6.5: StorageClass
• 6.6: VolumeSnapshotClass
• 6.7: Penyediaan Volume Dinamis
• 6.8: Limit Volume yang Spesifik terhadap Node
• 7: Konfigurasi
• 7.1: Konfigurasi dan Penerapan Konsep
• 7.2: Mengatur Sumber Daya Komputasi untuk Container
• 7.3: Secret
• 7.4: Mengatur Akses Klaster Menggunakan Berkas kubeconfig
• 7.5: Prioritas dan Pemindahan Pod
• 8: Keamanan
• 8.1: Ikhtisar Keamanan Cloud Native
• 9: Penjadwalan dan Pengusiran
• 9.1: Bin Packing Sumber Daya untuk Sumber Daya Tambahan
• 9.2: Overhead Pod
• 9.3: Menetapkan Pod ke Node
• 9.4: Taint dan Toleration
• 9.5: Penjadwal Kubernetes
• 9.6: Kerangka Kerja Penjadwalan (Scheduling Framework)
• 9.7: Penyetelan Kinerja Penjadwal
• 10: Policies
• 10.1: LimitRange
• 10.2: Resource Quota
• 10.3: Pod Security Policy
• 11: Administrasi Klaster
• 11.1: Ikhtisar Administrasi Klaster
• 11.2: Sertifikat
• 11.3: Penyedia Layanan Cloud
• 11.4: Mengelola Resource
• 11.5: Jaringan Kluster
• 11.6: Arsitektur Logging
• 11.7: Metrik untuk Komponen Sistem Kubernetes
• 11.8: Konfigurasi Garbage Collection pada kubelet
• 11.9: Federation
• 11.10: Berbagai Proxy di Kubernetes
• 11.11: Metrik controller manager
• 11.12: Instalasi Add-ons
• 11.13: Prioritas dan Kesetaraan API (API Priority and Fairness)
• 12: Memperluas Kubernetes
• 12.1: Memperluas Klaster Kubernetes Kamu
• 12.2: Memperluas API Kubernetes
• 12.2.1: Memperluas Kubernetes API dengan Lapisan Agregasi
• 12.2.2: Custom Resource
• 12.3: Ekstensi Komputasi, Penyimpanan, dan Jaringan
• 12.3.1: Plugin Jaringan
• 12.3.2: Plugin Perangkat
• 12.4: Pola Operator
• 12.5: Service Catalog
• 12.6: Poseidon-Firmament - Sebuah Penjadwal Alternatif

1 - Ikhtisar

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

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

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

1.4 - Menggunakan Objek-Objek Kubernetes

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

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

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

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

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

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

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

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

2 - Arsitektur Kubernetes

2.1 - Node

Node merupakan sebuah mesin worker di dalam Kubernetes, yang sebelumnya dinamakan minion. Sebuah node bisa berupa VM ataupun mesin fisik, tergantung dari klaster-nya. Masing-masing node berisi beberapa servis yang berguna untuk menjalankan banyak pod dan diatur oleh komponen-komponen yang dimiliki oleh master. Servis-servis di dalam sebuah node terdiri dari runtime kontainer, kubelet dan kube-proxy. Untuk lebih detail, lihat dokumentasi desain arsitektur pada Node Kubernetes.

Status Node

Sebuah status node berisikan informasi sebagai berikut:

• Addresses
• Condition
• Capacity
• Info

Masing-masing bagian dijelaskan secara rinci di bawah ini.

Addresses

Penggunaan field-field ini bergantung pada penyedia layanan cloud ataupun konfigurasi bare metal yang kamu punya.

• HostName: Merupakan hostname yang dilaporkan oleh kernel node. Dapat diganti melalui parameter --hostname-override pada kubelet.
• ExternalIP: Biasanya merupakan alamat IP pada node yang punya route eksternal (bisa diakses dari luar klaster).
• InternalIP: Biasanya merupakan alamat IP pada node yang hanya punya route di dalam klaster.

Condition

Field conditions menjelaskan tentang status dari semua node yang sedang berjalan (Running).

Condition pada node direpresentasikan oleh suatu obyek JSON. Sebagai contoh, respon berikut ini menggambarkan node yang sedang sehat (healthy).

"conditions": [
  {
    "type": "Ready",
    "status": "True"
  }
]

Jika status untuk Ready condition bernilai Unknown atau False untuk waktu yang lebih dari pod-eviction-timeout, tergantung bagaimana kube-controller-manager dikonfigurasi, semua pod yang dijalankan pada node tersebut akan dihilangkan oleh Kontroler Node. Durasi eviction timeout yang standar adalah lima menit. Pada kasus tertentu ketika node terputus jaringannya, apiserver tidak dapat berkomunikasi dengan kubelet yang ada pada node. Keputusan untuk menghilangkan pod tidak dapat diberitahukan pada kubelet, sampai komunikasi dengan apiserver terhubung kembali. Sementara itu, pod-pod akan terus berjalan pada node yang sudah terputus, walaupun mendapati schedule untuk dihilangkan.

Pada versi Kubernetes sebelum 1.5, kontroler node dapat menghilangkan dengan paksa (force delete) pod-pod yang terputus dari apiserver. Namun, pada versi 1.5 dan seterusnya, kontroler node tidak menghilangkan pod dengan paksa, sampai ada konfirmasi bahwa pod tersebut sudah berhenti jalan di dalam klaster. Pada kasus dimana Kubernetes tidak bisa menarik kesimpulan bahwa ada node yang telah meninggalkan klaster, admin klaster mungkin perlu untuk menghilangkan node secara manual. Menghilangkan obyek node dari Kubernetes akan membuat semua pod yang berjalan pada node tersebut dihilangkan oleh apiserver, dan membebaskan nama-namanya agar bisa digunakan kembali.

Pada versi 1.12, fitur TaintNodesByCondition telah dipromosikan ke beta, sehingga kontroler lifecycle node secara otomatis membuat taints yang merepresentasikan conditions. Akibatnya, scheduler menghiraukan conditions ketika mempertimbangkan sebuah Node; scheduler akan melihat pada taints sebuah Node dan tolerations sebuah Pod.

Sekarang, para pengguna dapat memilih antara model scheduling yang lama dan model scheduling yang lebih fleksibel. Pada model yang lama, sebuah pod tidak memiliki tolerations apapun sampai mendapat giliran schedule. Namun, pod dapat dijalankan pada Node tertentu, dimana pod melakukan toleransi terhadap taints yang dimiliki oleh Node tersebut.

Perhatian: Mengaktifkan fitur ini menambahkan delay sedikit antara waktu saat suatu condition terlihat dan saat suatu taint dibuat. Delay ini biasanya kurang dari satu detik, tapi dapat menambahkan jumlah yang telah berhasil mendapat schedule, namun ditolak oleh kubelet untuk dijalankan.

Capacity

Menjelaskan tentang resource-resource yang ada pada node: CPU, memori, dan jumlah pod secara maksimal yang dapat dijalankan pada suatu node.

Info

Informasi secara umum pada suatu node, seperti versi kernel, versi Kubernetes (versi kubelet dan kube-proxy), versi Docker (jika digunakan), nama OS. Informasi ini dikumpulkan oleh Kubelet di dalam node.

Manajemen

Tidak seperti pod dan service, sebuah node tidaklah dibuat dan dikonfigurasi oleh Kubernetes: tapi node dibuat di luar klaster oleh penyedia layanan cloud, seperti Google Compute Engine, atau pool mesin fisik ataupun virtual (VM) yang kamu punya. Jadi ketika Kubernetes membuat sebuah node, obyek yang merepresentasikan node tersebut akan dibuat. Setelah pembuatan, Kubernetes memeriksa apakah node tersebut valid atau tidak. Contohnya, jika kamu mencoba untuk membuat node dari konten berikut:

{
  "kind": "Node",
  "apiVersion": "v1",
  "metadata": {
    "name": "10.240.79.157",
    "labels": {
      "name": "my-first-k8s-node"
    }
  }
}

Kubernetes membuat sebuah obyek node secara internal (representasinya), dan melakukan validasi terhadap node. Validasi dilakukan dengan memeriksa kondisi kesehatan node (health checking), berdasarkan field metadata.name. Jika node valid -- terjadi saat semua servis yang diperlukan sudah jalan -- maka node diperbolehkan untuk menjalankan sebuah pod. Namun jika tidak valid, node tersebut akan dihiraukan untuk aktivitas apapun yang berhubungan dengan klaster, sampai telah menjadi valid.

Catatan: Kubernetes tetap menyimpan obyek untuk node yang tidak valid, dan terus memeriksa apakah node telah menjadi valid atau belum. Kamu harus secara eksplisit menghilangkan obyek Node tersebut untuk menghilangkan proses ini.

Saat ini, ada tiga komponen yang berinteraksi dengan antarmuka node di Kubernetes: kontroler node, kubelet, dan kubectl.

Kontroler Node

Kontroler node adalah komponen master Kubernetes yang berfungsi untuk mengatur berbagai aspek dari node.

Kontroler node memiliki berbagai peran (role) dalam sebuah lifecycle node. Pertama, menetapkan blok CIDR pada node tersebut saat registrasi (jika CIDR assignment diaktifkan).

Kedua, terus memperbarui daftar internal node di dalam kontroler node, sesuai dengan daftar mesin yang tersedia di dalam penyedia layanan cloud. Ketika berjalan di dalam environment cloud, kapanpun saat sebuah node tidak lagi sehat (unhealthy), kontroler node bertanya pada penyedia cloud, apakah VM untuk node tersebut masihkah tersedia atau tidak. Jika sudah tidak tersedia, kontroler node menghilangkan node tersebut dari daftar node.

Ketiga, melakukan monitor terhadap kondisi kesehatan (health) node. Kontroler node bertanggung jawab untuk mengubah status NodeReady condition pada NodeStatus menjadi ConditionUnknown, ketika sebuah node terputus jaringannya (kontroler node tidak lagi mendapat heartbeat karena suatu hal, contohnya karena node tidak hidup), dan saat kemudian melakukan eviction terhadap semua pod yang ada pada node tersebut (melalui terminasi halus -- graceful) jika node masih terus terputus. (Timeout standar adalah 40 detik untuk mulai melaporkan ConditionUnknown dan 5 menit setelah itu untuk mulai melakukan eviction terhadap pod.)

Kontroler node memeriksa state masing-masing node untuk durasi yang ditentukan oleh argumen --node-monitor-period.

Pada versi Kubernetes sebelum 1.13, NodeStatus adalah heartbeat yang diberikan oleh node. Setelah versi 1.13, fitur node lease diperkenalkan sebagai fitur alpha (fitur gate NodeLease, KEP-0009). Ketika fitur node lease diaktifasi, setiap node terhubung dengan obyek Lease di dalam namespace kube-node-lease yang terus diperbarui secara berkala. Kemudian, NodeStatus dan node lease keduanya dijadikan sebagai heartbeat dari node. Semua node lease diperbarui sesering mungkin, sedangkan NodeStatus dilaporkan dari node untuk master hanya ketika ada perubahan atau telah melewati periode waktu tertentu (default-nya 1 menit, lebih lama daripada default timeout node-node yang terputus jaringannya). Karena node lease jauh lebih ringan daripada NodeStatus, fitur ini membuat heartbeat dari node jauh lebih murah secara signifikan dari sudut pandang skalabilitas dan performa.

Di Kubernetes 1.4, kami telah memperbarui logic dari kontroler node supaya lebih baik dalam menangani kasus saat banyak sekali node yang tidak bisa terhubung dengan master (contohnya, karena master punya masalah jaringan). Mulai dari 1.4, kontroler node melihat state dari semua node di dalam klaster, saat memutuskan untuk melakukan eviction pada pod.

Pada kasus kebanyakan, kontroler node membatasi rate eviction menjadi --node-eviction-rate (default-nya 0.1) per detik. Artinya, kontroler node tidak akan melakukan eviction pada pod lebih dari 1 node per 10 detik.

Perlakuan eviction pada node berubah ketika sebuah node menjadi tidak sehat (unhealthy) di dalam suatu zona availability. Kontroler node memeriksa berapa persentase node di dalam zona tersebut yang tidak sehat (saat NodeReady condition menjadi ConditionUnknown atau ConditionFalse) pada saat yang bersamaan. Jika persentase node yang tidak sehat bernilai --unhealthy-zone-threshold (default-nya 0.55), maka rate eviction berkurang: untuk ukuran klaster yang kecil (saat jumlahnya lebih kecil atau sama dengan jumlah node --large-cluster-size-threshold - default-nya 50), maka eviction akan berhenti dilakukan. Jika masih besar jumlahnya, rate eviction dikurangi menjadi --secondary-node-eviction-rate (default-nya 0.01) per detik.

Alasan kenapa hal ini diimplementasi untuk setiap zona availability adalah karena satu zona bisa saja terputus dari master, saat yang lainnya masih terhubung. Jika klaster tidak menjangkau banyak zona availability yang disediakan oleh penyedia cloud, maka hanya ada satu zona (untuk semua node di dalam klaster).

Alasan utama untuk menyebarkan node pada banyak zona availability adalah supaya workload dapat dipindahkan ke zona sehat (healthy) saat suatu zona mati secara menyeluruh. Kemudian, jika semua node di dalam suatu zona menjadi tidak sehat (unhealthy), maka kontroler node melakukan eviction pada rate normal --node-eviction-rate. Kasus khusus, ketika seluruh zona tidak ada satupun sehat (tidak ada node yang sehat satupun di dalam klaster). Pada kasus ini, kontroler node berasumsi ada masalah pada jaringan master, dan menghentikan semua eviction sampai jaringan terhubung kembali.

Mulai dari Kubernetes 1.6, kontroler node juga bertanggung jawab untuk melakukan eviction pada pod-pod yang berjalan di atas node dengan taints NoExecute, ketika pod-pod tersebut sudah tidak lagi tolerate terhadap taints. Sebagai tambahan, hal ini di-nonaktifkan secara default pada fitur alpha, kontroler node bertanggung jawab untuk menambahkan taints yang berhubungan dengan masalah pada node, seperti terputus atau NotReady. Lihat dokumentasi ini untuk bahasan detail tentang taints NoExecute dan fitur alpha.

Mulai dari versi 1.8, kontroler node bisa diatur untuk bertanggung jawab pada pembuatan taints yang merepresentasikan node condition. Ini merupakan fitur alpha untuk versi 1.8.

Self-Registration untuk Node

Ketika argumen --register-node pada kubelet bernilai true (default-nya), kubelet akan berusaha untuk registrasi dirinya melalui API server. Ini merupakan pattern yang disukai, digunakan oleh kebanyakan distros.

Kubelet memulai registrasi diri (self-registration) dengan opsi-opsi berikut:

• --kubeconfig - Path berisi kredensial-kredensial yang digunakan untuk registrasi diri pada apiserver.
• --cloud-provider - Cara berbicara pada sebuah penyedia layanan cloud, baca tentang metadata-nya.
• --register-node - Registrasi secara otomatis pada API server.
• --register-with-taints - Registrasi node dengan daftar taints (dipisahkan oleh koma <key>=<value>:<effect>). No-op jika register-node bernilai false.
• --node-ip - Alamat IP dari node dimana kubelet berjalan.
• --node-labels - Label-label untuk ditambahkan saat melakukan registrasi untuk node di dalam klaster (lihat label yang dibatasi secara paksa oleh NodeRestriction admission plugin untuk 1.13+).
• --node-status-update-frequency - Menentukan seberapa sering kubelet melaporkan status pada master.

Ketika mode otorisasi Node dan NodeRestriction admission plugin diaktifkan, semua kubelet hanya punya otoritas untuk membuat/modifikasi resource Node masing-masing.

Administrasi Node secara Manual

Seorang admin klaster dapat membuat dan memodifikasi obyek node.

Jika admin ingin untuk membuat obyek node secara manual, atur argument --register-node=false pada kubelet.

Admin dapat memodifikasi resource-resource node (terlepas dari --register-node). Modifikasi terdiri dari pengaturan label pada node dan membuat node tidak dapat di-schedule.

Label-label pada node digunakan oleh selector node untuk mengatur proses schedule untuk pod, misalnya, membatasi sebuah pod hanya boleh dijalankan pada node-node tertentu.

Menandai sebuah node untuk tidak dapat di-schedule mencegah pod baru untuk tidak di-schedule pada node, tanpa mempengaruhi pod-pod yang sudah berjalan pada node tersebut. Ini berguna sebagai langkah persiapan untuk melakukan reboote pada node. Sebagai contoh, untuk menandai sebuah node untuk tidak dapat di-schedule, jalankan perintah berikut:

kubectl cordon $NODENAME

Catatan: Pod-pod yang dibuat oleh suatu kontroler DaemonSet menghiraukan scheduler Kubernetes dan mengabaikan tanda unschedulable pada node. Hal ini mengasumsikan bahwa daemons dimiliki oleh mesin, walaupun telah dilakukan drain pada aplikasi, saat melakukan persaiapan reboot.

Kapasitas Node

Kapasitas node (jumlah CPU dan memori) adalah bagian dari obyek node. Pada umumnya, node-node melakukan registrasi diri dan melaporkan kapasitasnya saat obyek node dibuat. Jika kamu melakukan administrasi node manual, maka kamu perlu mengatur kapasitas node saat menambahkan node baru.

Scheduler Kubernetes memastikan kalau ada resource yang cukup untuk menjalankan semua pod di dalam sebuah node. Kubernetes memeriksa jumlah semua request untuk kontainer pada sebuah node tidak lebih besar daripada kapasitas node. Hal ini termasuk semua kontainer yang dijalankan oleh kubelet. Namun, ini tidak termasuk kontainer-kontainer yang dijalankan secara langsung oleh runtime kontainer ataupun process yang ada di luar kontainer.

Kalau kamu ingin secara eksplisit menyimpan resource cadangan untuk menjalankan process-process selain Pod, ikut tutorial menyimpan resource cadangan untuk system daemon.

Obyek API

Node adalah tingkatan tertinggi dari resource di dalam Kubernetes REST API. Penjelasan lebih detail tentang obyek API dapat dilihat pada: Obyek Node API.

2.2 - Komunikasi antara Control Plane dan Node

Dokumen ini menjelaskan tentang jalur-jalur komunikasi di antara klaster Kubernetes dan control plane yang sebenarnya hanya berhubungan dengan apiserver saja. Kenapa ada dokumen ini? Supaya kamu, para pengguna Kubernetes, punya gambaran bagaimana mengatur instalasi untuk memperketat konfigurasi jaringan di dalam klaster. Hal ini cukup penting, karena klaster bisa saja berjalan pada jaringan tak terpercaya (untrusted network), ataupun melalui alamat-alamat IP publik pada penyedia cloud.

Node Menuju Control Plane

Kubernetes memiliki sebuah pola API "hub-and-spoke". Semua penggunaan API dari Node (atau Pod dimana Pod-Pod tersebut dijalankan) akan diterminasi pada apiserver (tidak ada satu komponen control plane apa pun yang didesain untuk diekspos pada servis remote). Apiserver dikonfigurasi untuk mendengarkan koneksi aman remote yang pada umumnya terdapat pada porta HTTPS (443) dengan satu atau lebih bentuk autentikasi klien yang dipasang. Sebaiknya, satu atau beberapa metode otorisasi juga dipasang, terutama jika kamu memperbolehkan permintaan anonim (anonymous request) ataupun service account token.

Jika diperlukan, Pod-Pod dapat terhubung pada apiserver secara aman dengan menggunakan ServiceAccount. Dengan ini, Kubernetes memasukkan public root certificate dan bearer token yang valid ke dalam Pod, secara otomatis saat Pod mulai dijalankan. Kubernetes Service (di dalam semua Namespace) diatur dengan sebuah alamat IP virtual. Semua yang mengakses alamat IP ini akan dialihkan (melalui kube-proxy) menuju endpoint HTTPS dari apiserver.

Komponen-komponen juga melakukan koneksi pada apiserver klaster melalui porta yang aman.

Akibatnya, untuk konfigurasi yang umum dan standar, semua koneksi dari klaster (node-node dan pod-pod yang berjalan di atas node tersebut) menujucontrol planesudah terhubung dengan aman. Dan juga, klaster dancontrol planebisa terhubung melalui jaringan publik dan/atau yang tak terpercaya (untrusted).

Control Plane menuju Node

Ada dua jalur komunikasi utama dari control plane (apiserver) menuju klaster. Pertama, dari apiserver ke proses kubelet yang berjalan pada setiap Node di dalam klaster. Kedua, dari apiserver ke setiap Node, Pod, ataupun Service melalui fungsi proksi pada apiserver

Apiserver menuju kubelet

Koneksi dari apiserver menuju kubelet bertujuan untuk:

• Melihat log dari pod-pod.
• Masuk ke dalam pod-pod yang sedang berjalan (attach).
• Menyediakan fungsi port-forward dari kubelet.

Semua koneksi ini diterminasi pada endpoint HTTPS dari kubelet. Secara default, apiserver tidak melakukan verifikasi serving certificate dari kubelet, yang membuat koneksi terekspos pada serangan man-in-the-middle, dan juga tidak aman untuk terhubung melalui jaringan tak terpercaya (untrusted) dan/atau publik.

Untuk melakukan verifikasi koneksi ini, berikan root certificate pada apiserver melalui tanda --kubelet-certificate-authority, sehingga apiserver dapat memverifikasi serving certificate dari kubelet.

Cara lainnya, gunakan tunnel SSH antara apiserver dan kubelet jika diperlukan, untuk menghindari komunikasi melalui jaringan tak terpercaya (untrusted) atau publik.

Terakhir, yang terpenting, aktifkan autentikasi dan/atau otorisasi Kubelet untuk mengamankan API kubelet.

Apiserver menuju Node, Pod, dan Service

Secara default, koneksi apiserver menuju node, pod atau service hanyalah melalui HTTP polos (plain), sehingga tidak ada autentikasi maupun enkripsi. Koneksi tersebut bisa diamankan melalui HTTPS dengan menambahkan https: pada URL API dengan nama dari node, pod, atau service. Namun, koneksi tidak tervalidasi dengan certificate yang disediakan oleh endpoint HTTPS maupun kredensial client, sehingga walaupun koneksi sudah terenkripsi, tidak ada yang menjamin integritasnya. Koneksi ini tidak aman untuk dilalui pada jaringan publik dan/atau tak terpercaya untrusted.

Tunnel SSH

Kubernetes menyediakan tunnel SSH untuk mengamankan jalur komunikasi control plane -> Klaster. Dengan ini, apiserver menginisiasi sebuah tunnel SSH untuk setiap node di dalam klaster (terhubung ke server SSH di port 22) dan membuat semua trafik menuju kubelet, node, pod, atau service dilewatkan melalui tunnel tesebut. Tunnel ini memastikan trafik tidak terekspos keluar jaringan dimana node-node berada.

Tunnel SSH saat ini sudah usang (deprecated), jadi sebaiknya jangan digunakan, kecuali kamu tahu pasti apa yang kamu lakukan. Sebuah desain baru untuk mengganti kanal komunikasi ini sedang disiapkan.

2.3 - Controller

Dalam bidang robotika dan otomatisasi, control loop atau kontrol tertutup adalah lingkaran tertutup yang mengatur keadaan suatu sistem.

Berikut adalah salah satu contoh kontrol tertutup: termostat di sebuah ruangan.

Ketika kamu mengatur suhunya, itu mengisyaratkan ke termostat tentang keadaan yang kamu inginkan. Sedangkan suhu kamar yang sebenarnya adalah keadaan saat ini. Termostat berfungsi untuk membawa keadaan saat ini mendekati ke keadaan yang diinginkan, dengan menghidupkan atau mematikan perangkat.

Di Kubernetes, controller adalah kontrol tertutup yang mengawasi keadaan klaster klaster kamu, lalu membuat atau meminta perubahan jika diperlukan. Setiap controller mencoba untuk memindahkan status klaster saat ini mendekati keadaan yang diinginkan.

Pola controller

Sebuah controller melacak sekurang-kurangnya satu jenis sumber daya dari Kubernetes. objek-objek ini memiliki spec field yang merepresentasikan keadaan yang diinginkan. Satu atau lebih controller untuk resource tersebut bertanggung jawab untuk membuat keadaan sekarang mendekati keadaan yang diinginkan.

Controller mungkin saja melakukan tindakan itu sendiri; namun secara umum, di Kubernetes, controller akan mengirim pesan ke API server yang mempunyai efek samping yang bermanfaat. Kamu bisa melihat contoh-contoh di bawah ini.

Kontrol melalui server API

Controller Job adalah contoh dari controller bawaan dari Kubernetes. Controller bawaan tersebut mengelola status melalui interaksi dengan server API dari suatu klaster.

Job adalah sumber daya dalam Kubernetes yang menjalankan a Pod, atau mungkin beberapa Pod sekaligus, untuk melakukan sebuah pekerjaan dan kemudian berhenti.

(Setelah dijadwalkan, objek Pod akan menjadi bagian dari keadaan yang diinginkan oleh kubelet).

Ketika controller job melihat tugas baru, maka controller itu memastikan bahwa, di suatu tempat pada klaster kamu, kubelet dalam sekumpulan Node menjalankan Pod-Pod dengan jumlah yang benar untuk menyelesaikan pekerjaan. Controller job tidak menjalankan sejumlah Pod atau kontainer apa pun untuk dirinya sendiri. Namun, controller job mengisyaratkan kepada server API untuk membuat atau menghapus Pod. Komponen-komponen lain dalam control plane bekerja berdasarkan informasi baru (adakah Pod-Pod baru untuk menjadwalkan dan menjalankan pekerjan), dan pada akhirnya pekerjaan itu selesai.

Setelah kamu membuat Job baru, status yang diharapkan adalah bagaimana pekerjaan itu bisa selesai. Controller job membuat status pekerjaan saat ini agar mendekati dengan keadaan yang kamu inginkan: membuat Pod yang melakukan pekerjaan yang kamu inginkan untuk Job tersebut, sehingga Job hampir terselesaikan.

Controller juga memperbarui objek yang mengkonfigurasinya. Misalnya: setelah pekerjaan dilakukan untuk Job tersebut, controller job memperbarui objek Job dengan menandainya Finished.

(Ini hampir sama dengan bagaimana beberapa termostat mematikan lampu untuk mengindikasikan bahwa kamar kamu sekarang sudah berada pada suhu yang kamu inginkan).

Kontrol Langsung

Berbeda dengan sebuah Job, beberapa dari controller perlu melakukan perubahan sesuatu di luar dari klaster kamu.

Sebagai contoh, jika kamu menggunakan kontrol tertutup untuk memastikan apakah cukup Node dalam kluster kamu, maka controller memerlukan sesuatu di luar klaster saat ini untuk mengatur Node-Node baru apabila dibutuhkan.

controller yang berinteraksi dengan keadaan eksternal dapat menemukan keadaan yang diinginkannya melalui server API, dan kemudian berkomunikasi langsung dengan sistem eksternal untuk membawa keadaan saat ini mendekat keadaan yang diinginkan.

(Sebenarnya ada sebuah controller yang melakukan penskalaan node secara horizontal dalam klaster kamu.

Status sekarang berbanding status yang diinginkan

Kubernetes mengambil pandangan sistem secara cloud-native, dan mampu menangani perubahan yang konstan.

Klaster kamu dapat mengalami perubahan kapan saja pada saat pekerjaan sedang berlangsung dan kontrol tertutup secara otomatis memperbaiki setiap kegagalan. Hal ini berarti bahwa, secara potensi, klaster kamu tidak akan pernah mencapai kondisi stabil.

Selama controller dari klaster kamu berjalan dan mampu membuat perubahan yang bermanfaat, tidak masalah apabila keadaan keseluruhan stabil atau tidak.

Perancangan

Sebagai prinsip dasar perancangan, Kubernetes menggunakan banyak controller yang masing-masing mengelola aspek tertentu dari keadaan klaster. Yang paling umum, kontrol tertutup tertentu menggunakan salah satu jenis sumber daya sebagai suatu keadaan yang diinginkan, dan memiliki jenis sumber daya yang berbeda untuk dikelola dalam rangka membuat keadaan yang diinginkan terjadi.

Sangat penting untuk memiliki beberapa controller sederhana daripada hanya satu controller saja, dimana satu kumpulan monolitik kontrol tertutup saling berkaitan satu sama lain. Karena controller bisa saja gagal, sehingga Kubernetes dirancang untuk memungkinkan hal tersebut.

Misalnya: controller pekerjaan melacak objek pekerjaan (untuk menemukan adanya pekerjaan baru) dan objek Pod (untuk menjalankan pekerjaan tersebut dan kemudian melihat lagi ketika pekerjaan itu sudah selesai). Dalam hal ini yang lain membuat pekerjaan, sedangkan controller pekerjaan membuat Pod-Pod.

Catatan:

Ada kemungkinan beberapa controller membuat atau memperbarui jenis objek yang sama. Namun di belakang layar, controller Kubernetes memastikan bahwa mereka hanya memperhatikan sumbr daya yang terkait dengan sumber daya yang mereka kendalikan.

Misalnya, kamu dapat memiliki Deployment dan Job; dimana keduanya akan membuat Pod. Controller Job tidak akan menghapus Pod yang dibuat oleh Deployment kamu, karena ada informasi (labels) yang dapat oleh controller untuk membedakan Pod-Pod tersebut.

Berbagai cara menjalankan beberapa controller

Kubernetes hadir dengan seperangkat controller bawaan yang berjalan di dalam kube-controller-manager. Beberapa controller bawaan memberikan perilaku inti yang sangat penting.

Controller Deployment dan controller Job adalah contoh dari controller yang hadir sebagai bagian dari Kubernetes itu sendiri (controller "bawaan"). Kubernetes memungkinkan kamu menjalankan control plane yang tangguh, sehingga jika ada controller bawaan yang gagal, maka bagian lain dari control plane akan mengambil alih pekerjaan.

Kamu juga dapat menemukan pengontrol yang berjalan di luar control plane, untuk mengembangkan lebih jauh Kubernetes. Atau, jika mau, kamu bisa membuat controller baru sendiri. Kamu dapat menjalankan controller kamu sendiri sebagai satu kumpulan dari beberapa Pod, atau bisa juga sebagai bagian eksternal dari Kubernetes. Manakah yang paling sesuai akan tergantung pada apa yang controller khusus itu lakukan.

Selanjutnya

• Silahkan baca tentang control plane Kubernetes
• Temukan beberapa dasar tentang objek-objek Kubernetes
• Pelajari lebih lanjut tentang Kubernetes API
• Apabila kamu ingin membuat controller sendiri, silakan lihat pola perluasan dalam memperluas Kubernetes.

2.4 - Konsep-konsep di balik Controller Manager

Konsep Cloud Controller Manager/CCM (jangan tertukar dengan program biner kube-controller-manager) awalnya dibuat untuk memungkinkan kode vendor cloud spesifik dan kode inti Kubernetes untuk berkembang secara independen satu sama lainnya. CCM berjalan bersama dengan komponen Master lainnya seperti Kubernetes Controller Manager, API Server, dan Scheduler. CCM juga dapat dijalankan sebagai Kubernetes Addon (tambahan fungsi terhadap Kubernetes), yang akan berjalan di atas klaster Kubernetes.

Desain CCM didasarkan pada mekanisme plugin yang memungkinkan penyedia layanan cloud untuk berintegrasi dengan Kubernetes dengan mudah dengan menggunakan plugin. Sudah ada rencana untuk pengenalan penyedia layanan cloud baru pada Kubernetes, dan memindahkan penyedia layanan cloud yang sudah ada dari model yang lama ke model CCM.

Dokumen ini mendiskusikan konsep di balik CCM dan mendetail fungsi-fungsinya.

Berikut adalah arsitektur sebuah klaster Kubernetes tanpa CCM:

Desain

Pada diagram sebelumnya, Kubernetes dan penyedia layanan cloud diintegrasikan melalui beberapa komponen berbeda:

• Kubelet
• Kubernetes Controller Manager
• Kubernetes API server

CCM menggabungkan semua logika yang bergantung pada cloud dari dalam tiga komponen tersebut ke dalam sebuah titik integrasi dengan cloud. Arsitektur baru di dalam model CCM adalah sebagai berikut:

Komponen-komponen CCM

CCM memisahkan beberapa fungsi Kubernetes Controller Manager (KCM) dan menjalankannya sebagai proses yang berbeda. Secara spesifik, CCM memisahkan pengendali-pengendali (controller) di dalam KCM yang bergantung terhadap penyedia layanan cloud. KCM memiliki beberapa komponen pengendali yang bergantung pada cloud sebagai berikut:

• Node Controller
• Volume Controller
• Route Controller
• Service Controller

Pada versi 1.9, CCM menjalankan pengendali-pengendali dari daftar sebelumnya sebagai berikut:

• Node Controller
• Route Controller
• Service Controller

Catatan: Volume Controller secara sengaja tidak dipilih sebagai bagian dari CCM. Hal ini adalah karena kerumitan untuk melakukannya, dan mempertimbangkan usaha-usaha yang sedang berlangsung untuk memisahkan logika volume yang spesifik vendor dari KCM, sehingga diputuskan bahwa Volume Contoller tidak akan dipisahkan dari KCM ke CCM.

Rencana awal untuk mendukung volume menggunakan CCM adalah dengan menggunakan FlexVolume untuk mendukung penambahan volume secara pluggable. Namun, ada sebuah usaha lain yang diberi nama Container Storage Interface (CSI) yang sedang berlangsung untuk menggantikan FlexVolume.

Mempertimbangkan dinamika tersebut, kami memutuskan untuk mengambil tindakan sementara hingga CSI siap digunakan.

Fungsi-fungsi CCM

Fungsi-fungsi CCM diwarisi oleh komponen-komponen Kubernetes yang bergantung pada penyedia layanan cloud. Bagian ini disusun berdasarkan komponen-komponen tersebut.

1. Kubernetes Controller Manager

Kebanyakan fungsi CCM diturunkan dari KCM. Seperti yang telah disebutkan pada bagian sebelumnya, CCM menjalankan komponen-komponen pengendali sebagai berikut:

• Node Controller
• Route Controller
• Service Controller

Node Controller

Node Controller bertugas untuk menyiapkan sebuah node dengan cara mengambil informasi node-node yang berjalan di dalam klaster dari penyedia layanan cloud. Node Controller melakukan fungsi-fungsi berikut:

1. Menyiapkan sebuah node dengan memberi label zone/region yang spesifik pada cloud.
2. Menyiapkan sebuah node dengan informasi instance yang spesifik cloud , misalnya tipe dan ukurannya.
3. Mendapatkan alamat jaringan dan hostname milik node tersebut.
4. Dalam hal sebuah node menjadi tidak responsif, memeriksa cloud untuk melihat apakah node tersebut telah dihapus dari cloud. Juga, menghapus objek Node tersebut dari klaster Kubernetes, jika node tersebut telah dihapus dari cloud.

Route Controller

Route Controller bertugas mengkonfigurasi rute jaringan di dalam cloud secara sesuai agar Container pada node-node yang berbeda di dalam klaster Kubernetes dapat berkomunikasi satu sama lain. Route Controller hanya berlaku untuk klaster yang berjalan pada Google Compute Engine (GCE) di penyedia layanan cloud GCP.

Service Controller

Service Controller bertugas memantau terjadinya operasi create, update, dan delete pada Service. Berdasarkan keadaan terkini Service-service pada klaster Kubernetes, Service Controller mengkonfigurasi load balancer spesifik cloud (seperti ELB, Google LB, atau Oracle Cloud Infrastructure LB) agar sesuai dengan keadaan Service-service pada klaster Kubernetes. Sebagai tambahan, Service Controller juga memastikan bahwa service backend (target dari load balancer yang bersangkutan) dari load balancer cloud tersebut berada dalam kondisi terkini.

2. Kubelet

Node Controller berisi fungsi Kubelet yang bergantung pada cloud. Sebelum CCM, Kubelet bertugas untuk menyiapkan node dengan informasi spesifik cloud seperti alamat IP, label zone/region, dan tipe instance. Setelah diperkenalkannya CCM, tugas tersebut telah dipindahkan dari Kubelet ke dalam CCM.

Pada model baru ini, Kubelet menyiapkan sebuah node tanpa informasi spesifik cloud. Namun, Kubelet menambahkan sebuah Taint pada node yang baru dibuat yang menjadikan node tersebut tidak dapat dijadwalkan (sehingga tidak ada Pod yang dapat dijadwalkan ke node tersebut) hingga CCM menyiapkan node tersebut dengan informasi spesifik cloud. Setelah itu, Kubelet menghapus Taint tersebut.

Mekanisme Plugin

CCM menggunakan interface Go untuk memungkinkan implementasi dari cloud apapun untuk ditambahkan. Secara spesifik, CCM menggunakan CloudProvider Interface yang didefinisikan di sini

Implementasi dari empat kontroler-kontroler yang disorot di atas, dan beberapa kerangka kerja, bersama dengan CloudProvider Interface, akan tetap berada pada kode inti Kubernetes. Implementasi spesifik penyedia layanan cloud akan dibuat di luar kode inti dan menggunakan CloudProvider Interface yang didefinisikan di kode inti.

Untuk informasi lebih lanjut mengenai pengembangan plugin, lihat Mengembangkan Cloud Controller Manager.

Otorisasi

Bagian ini memerinci akses yang dibutuhkan oleh CCM terhadap berbagai objek API untuk melakukan tugas-tugasnya.

Akses untuk Node Controller

Node Controller hanya berinteraksi dengan objek-objek Node. Node Controller membutuhkan akses penuh untuk operasi get, list, create, update, patch, watch, dan delete terhadap objek-objek Node.

v1/Node:

• Get
• List
• Create
• Update
• Patch
• Watch
• Delete

Akses untuk Route Controller

Route Controller memantau pembuatan objek Node dan mengkonfigurasi rute jaringan secara sesuai. Route Controller membutuhkan akses untuk operasi get terhadap objek-objek Node.

v1/Node:

• Get

Akses untuk Service Controller

Service Controller memantau terjadinya operasi create, update dan delete, kemudian mengkonfigurasi Endpoint untuk Service-service tersebut secara sesuai.

Untuk mengakses Service-service, Service Controller membutuhkan akses untuk operasi list dan watch. Untuk memperbarui Service-service, dibutuhkan akses untuk operasi patch dan update.

Untuk menyiapkan Endpoint bagi untuk Service-service, dibutuhkan akses untuk operasi create, list, get, watch, dan update.

v1/Service:

• List
• Get
• Watch
• Patch
• Update

Akses Lainnya

Implementasi dari inti CCM membutuhkan akses untuk membuat Event, dan untuk memastikan operasi yang aman, dibutuhkan akses untuk membuat ServiceAccount.

v1/Event:

• Create
• Patch
• Update

v1/ServiceAccount:

• Create

Detail RBAC dari ClusterRole untuk CCM adalah sebagai berikut:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cloud-controller-manager
rules:
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - patch
  - update
- apiGroups:
  - ""
  resources:
  - nodes
  verbs:
  - '*'
- apiGroups:
  - ""
  resources:
  - nodes/status
  verbs:
  - patch
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - serviceaccounts
  verbs:
  - create
- apiGroups:
  - ""
  resources:
  - persistentvolumes
  verbs:
  - get
  - list
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - endpoints
  verbs:
  - create
  - get
  - list
  - watch
  - update

Implementasi Vendor-vendor

Penyedia layanan cloud berikut telah mengimplementasikan CCM:

• Digital Ocean
• Oracle
• Azure
• GCP
• AWS
• BaiduCloud
• Linode

Administrasi Klaster

Petunjuk lengkap untuk mengkonfigurasi dan menjalankan CCM disediakan di sini.

3 - Kontainer

3.1 - Ikhtisar Kontainer

Kontainer adalah teknologi untuk mengemas kode (yang telah dikompilasi) menjadi suatu aplikasi beserta dengan dependensi-dependensi yang dibutuhkannya pada saat dijalankan. Setiap kontainer yang Anda jalankan dapat diulang; standardisasi dengan menyertakan dependensinya berarti Anda akan mendapatkan perilaku yang sama di mana pun Anda menjalankannya.

Kontainer memisahkan aplikasi dari infrastruktur host yang ada dibawahnya. Hal ini membuat penyebaran lebih mudah di lingkungan cloud atau OS yang berbeda.

Image-Image Kontainer

Kontainer image meruapakan paket perangkat lunak yang siap dijalankan, mengandung semua yang diperlukan untuk menjalankan sebuah aplikasi: kode dan setiap runtime yang dibutuhkan, library dari aplikasi dan sistem, dan nilai default untuk penganturan yang penting.

Secara desain, kontainer tidak bisa berubah: Anda tidak dapat mengubah kode dalam kontainer yang sedang berjalan. Jika Anda memiliki aplikasi yang terkontainerisasi dan ingin melakukan perubahan, maka Anda perlu membuat kontainer baru dengan menyertakan perubahannya, kemudian membuat ulang kontainer dengan memulai dari image yang sudah diubah.

Kontainer runtime

Kontainer runtime adalah perangkat lunak yang bertanggung jawab untuk menjalankan kontainer. Kubernetes mendukung beberapa kontainer runtime: Docker, containerd, CRI-O, dan semua implementasi dari Kubernetes CRI (Container Runtime Interface).

Selanjutnya

• Baca tentang image-image kontainer
• Baca tentang Pod

3.2 - Image

Kamu membuat Docker image dan mengunduhnya ke sebuah registri sebelum digunakan di dalam Kubernetes Pod.

Properti image dari sebuah Container mendukung sintaksis yang sama seperti perintah docker, termasuk registri privat dan tag.

Memperbarui Image

Kebijakan pull default adalah IfNotPresent yang membuat Kubelet tidak lagi mengunduh (pull) sebuah image jika sudah ada terlebih dahulu. Jika kamu ingin agar selalu diunduh, kamu bisa melakukan salah satu dari berikut:

• mengatur imagePullPolicy dari Container menjadi Always.
• buang imagePullPolicy dan gunakan :latest tag untuk image yang digunakan.
• buang imagePullPolicy dan juga tag untuk image.
• aktifkan AlwaysPullImages admission controller.

Harap diingat kamu sebaiknya hindari penggunaan tag :latest, lihat panduan konfigurasi untuk informasi lebih lanjut.

Membuat Image Multi-arsitektur dengan Manifest

Docker CLI saat ini mendukung perintah docker manifest dengan anak perintah create, annotate, dan push. Perintah-perintah ini dapat digunakan untuk membuat (build) dan mengunggah (push) manifes. Kamu dapat menggunakan perintah docker manifest inspect untuk membaca manifes.

Lihat dokumentasi docker di sini: https://docs.docker.com/edge/engine/reference/commandline/manifest/

Lihat contoh-contoh bagaimana kami menggunakan ini untuk proses build harness: https://cs.k8s.io/?q=docker%20manifest%20(create%7Cpush%7Cannotate)&i=nope&files=&repos=

Perintah-perintah ini bergantung pada Docker CLI, dan diimplementasi hanya di sisi CLI. Kamu harus mengubah $HOME/.docker/config.json dan mengatur key experimental untuk mengaktifkan atau cukup dengan mengatur DOCKER_CLI_EXPERIMENTAL variabel environment menjadi enabled ketika memanggil perintah-perintah CLI.

Catatan: Gunakan Docker 18.06 ke atas, versi-versi di bawahnya memiliki bug ataupun tidak mendukung perintah eksperimental. Contohnya https://github.com/docker/cli/issues/1135 yang menyebabkan masalah di bawah containerd.

Kalau kamu terkena masalah ketika mengunggah manifes-manifes yang rusak, cukup bersihkan manifes-manifes yang lama di $HOME/.docker/manifests untuk memulai dari awal.

Untuk Kubernetes, kami biasanya menggunakan image-image dengan sufiks -$(ARCH). Untuk kompatibilitas (backward compatibility), lakukan generate image-image yang lama dengan sufiks. Idenya adalah men-generate, misalnya pause image yang memiliki manifes untuk semua arsitektur dan misalnya pause-amd64 yang punya kompatibilitas terhadap konfigurasi-konfigurasi lama atau berkas-berkas YAML yang bisa saja punya image-image bersufiks yang di-hardcode.

Menggunakan Registri Privat (Private Registry)

Biasanya kita memerlukan key untuk membaca image-image yang tersedia pada suatu registri privat. Kredensial ini dapat disediakan melalui beberapa cara:

• Menggunakan Google Container Registry
  • per-klaster
  • konfigurasi secara otomatis pada Google Compute Engine atau Google Kubernetes Engine
  • semua Pod dapat membaca registri privat yang ada di dalam proyek
• Menggunakan Amazon Elastic Container Registry (ECR)
  • menggunakan IAM role dan policy untuk mengontrol akses ke repositori ECR
  • secara otomatis refresh kredensial login ECR
• Menggunakan Oracle Cloud Infrastructure Registry (OCIR)
  • menggunakan IAM role dan policy untuk mengontrol akses ke repositori OCIR
• Menggunakan Azure Container Registry (ACR)
• Menggunakan IBM Cloud Container Registry
  • menggunakan IAM role dan policy untuk memberikan akses ke IBM Cloud Container Registry
• Konfigurasi Node untuk otentikasi registri privat
  • semua Pod dapat membaca registri privat manapun
  • memerlukan konfigurasi Node oleh admin klaster
• Pra-unduh image
  • semua Pod dapat menggunakan image apapun yang di-cached di dalam sebuah Node
  • memerlukan akses root ke dalam semua Node untuk pengaturannya
• Mengatur ImagePullSecrets dalam sebuah Pod
  • hanya Pod-Pod yang menyediakan key sendiri yang dapat mengakses registri privat

Masing-masing opsi dijelaskan lebih lanjut di bawah ini.

Menggunakan Google Container Registry

Kubernetes memiliki dukungan native untuk Google Container Registry (GCR), ketika dijalankan pada Google Compute Engine (GCE). Jika kamu menjalankan klaster pada GCE atau Google Kubernetes Engine, cukup gunakan nama panjang image (misalnya gcr.io/my_project/image:tag).

Semua Pod di dalam klaster akan memiliki akses baca image di registri ini.

Kubelet akan melakukan otentikasi GCR menggunakan service account yang dimiliki instance Google. Service acccount pada instance akan memiliki sebuah https://www.googleapis.com/auth/devstorage.read_only, sehingga dapat mengunduh dari GCR di proyek yang sama, tapi tidak untuk unggah.

Menggunakan Amazon Elastic Container Registry

Kubernetes memiliki dukungan native untuk Amazon Elastic Container Registry, ketika Node adalah AWS EC2 instance.

Cukup gunakan nama panjang image (misalnya ACCOUNT.dkr.ecr.REGION.amazonaws.com/imagename:tag) di dalam definisi Pod.

Semua pengguna klaster yang dapat membuat Pod akan bisa menjalankan Pod yang dapat menggunakan image-image di dalam registri ECR.

Kubelet akan mengambil dan secara periodik memperbarui kredensial ECR, yang memerlukan permission sebagai berikut:

• ecr:GetAuthorizationToken
• ecr:BatchCheckLayerAvailability
• ecr:GetDownloadUrlForLayer
• ecr:GetRepositoryPolicy
• ecr:DescribeRepositories
• ecr:ListImages
• ecr:BatchGetImage

Persyaratan:

• Kamu harus menggunakan versi kubelet v1.2.0 atau lebih (misal jalankan /usr/bin/kubelet --version=true).
• Jika Node yang kamu miliki ada di region A dan registri kamu ada di region yang berbeda misalnya B, kamu perlu versi v1.3.0 atau lebih.
• ECR harus tersedia di region kamu.

Cara troubleshoot:

• Verifikasi semua persyaratan di atas.
• Dapatkan kredensial $REGION (misalnya us-west-2) pada workstation kamu. Lakukan SSH ke dalam host dan jalankan Docker secara manual menggunakan kredensial tersebut. Apakah berhasil?
• Tambahkan verbositas level log kubelet paling tidak 3 dan periksa log kubelet (misal journalctl -u kubelet) di baris-baris yang seperti ini:
  • aws_credentials.go:109] unable to get ECR credentials from cache, checking ECR API
  • aws_credentials.go:116] Got ECR credentials from ECR API for <AWS account ID for ECR>.dkr.ecr.<AWS region>.amazonaws.com

Menggunakan Azure Container Registry (ACR)

Ketika menggunakan Azure Container Registry kamu dapat melakukan otentikasi menggunakan pengguna admin maupun sebuah service principal. Untuk keduanya, otentikasi dilakukan melalui proses otentikasi Docker standar. Instruksi-instruksi ini menggunakan perangkat azure-cli.

Kamu pertama perlu membuat sebuah registri dan men-generate kredensial, dokumentasi yang lengkap tentang hal ini dapat dilihat pada dokumentasi Azure container registry.

Setelah kamu membuat registri, kamu akan menggunakan kredensial berikut untuk login:

• DOCKER_USER : service principal, atau pengguna admin
• DOCKER_PASSWORD: kata sandi dari service principal, atau kata sandi dari pengguna admin
• DOCKER_REGISTRY_SERVER: ${some-registry-name}.azurecr.io
• DOCKER_EMAIL: ${some-email-address}

Ketika kamu sudah memiliki variabel-variabel di atas, kamu dapat mengkonfigurasi sebuah Kubernetes Secret dan menggunakannya untuk deploy sebuah Pod.

Menggunakan IBM Cloud Container Registry

IBM Cloud Container Registry menyediakan sebuah registri image privat yang multi-tenant, dapat kamu gunakan untuk menyimpan dan membagikan image-image secara aman. Secara default, image-image di dalam registri privat kamu akan dipindai (scan) oleh Vulnerability Advisor terintegrasi untuk deteksi isu keamanan dan kerentanan (vulnerability) yang berpotensi. Para pengguna di dalam akun IBM Cloud kamu dapat mengakses image, atau kamu dapat menggunakan IAM role dan policy untuk memberikan akses ke namespace di IBM Cloud Container Registry.

Untuk instalasi plugin CLI di IBM Cloud Containerr Registry dan membuat sebuah namespace untuk image-image kamu, lihat Mulai dengan IBM Cloud Container Registry.

Jika kamu menggunakan akun dan wilayah (region) yang sama, kamu dapat melakukan deploy image-image yang disimpan di dalam IBM Cloud Container Registry ke dalam namespace default dari klaster IBM Cloud Kubernetes Service yang kamu miliki tanpa konfigurasi tambahan, lihat Membuat kontainer dari image. Untuk opsi konfigurasi lainnya, lihat Bagaimana cara mengotorasi klaster untuk mengunduh image dari sebuah registri.

Konfigurasi Node untuk Otentikasi ke sebuah Registri Privat

Catatan: Jika kamu jalan di Google Kubernetes Engine, akan ada .dockercfg pada setiap Node dengan kredensial untuk Google Container Registry. Kamu tidak bisa menggunakan cara ini.

Catatan: Jika kamu jalan di AWS EC2 dan menggunakan EC2 Container Registry (ECR), kubelet pada setiap Node akan dapat mengatur dan memperbarui kredensial login ECR. Kamu tidak bisa menggunakan cara ini.

Catatan: Cara ini cocok jika kamu dapat mengontrol konfigurasi Node. Cara ini tidak akan bekerja dengan baik pada GCE, dan penyedia layanan cloud lainnya yang tidak melakukan penggantian Node secara otomatis.

Catatan: Kubernetes pada saat ini hanya mendukung bagian auths dan HttpHeaders dari konfigurasi docker. Hal ini berarti bantuan kredensial (credHelpers atau credsStore) tidak didukung.

Docker menyimpan key untuk registri privat pada $HOME/.dockercfg atau berkas $HOME/.docker/config.json. Jika kamu menempatkan berkas yang sama pada daftar jalur pencarian (search path) berikut, kubelet menggunakannya sebagai penyedia kredensial saat mengunduh image.

• {--root-dir:-/var/lib/kubelet}/config.json
• {cwd of kubelet}/config.json
• ${HOME}/.docker/config.json
• /.docker/config.json
• {--root-dir:-/var/lib/kubelet}/.dockercfg
• {cwd of kubelet}/.dockercfg
• ${HOME}/.dockercfg
• /.dockercfg

Catatan: Kamu mungkin harus mengatur HOME=/root secara eksplisit pada berkas environment kamu untuk kubelet.

Berikut langkah-langkah yang direkomendasikan untuk mengkonfigurasi Node kamu supaya bisa menggunakan registri privat. Pada contoh ini, coba jalankan pada desktop/laptop kamu:

1. Jalankan docker login [server] untuk setiap set kredensial yang ingin kamu gunakan. Ini akan memperbarui $HOME/.docker/config.json.
2. Lihat $HOME/.docker/config.json menggunakan editor untuk memastikan sudah berisi kredensial yang ingin kamu gunakan.
3. Dapatkan daftar Node, contohnya:
   • jika kamu ingin mendapatkan nama: nodes=$(kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}')
   • jika kamu ingin mendapatkan IP: nodes=$(kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}')
4. Salin .docker/config.json yang ada di lokal kamu pada salah satu jalur pencarian di atas.
   • contohnya: for n in $nodes; do scp ~/.docker/config.json root@$n:/var/lib/kubelet/config.json; done

Verifikasi dengana membuat sebuah Pod yanag menggunakan image privat, contohnya:

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: private-image-test-1
spec:
  containers:
    - name: uses-private-image
      image: $PRIVATE_IMAGE_NAME
      imagePullPolicy: Always
      command: [ "echo", "SUCCESS" ]
EOF

pod/private-image-test-1 created

Jika semuanya berjalan dengan baik, maka setelah beberapa lama, kamu dapat menjalankan:

kubectl logs private-image-test-1

dan lihat pada keluaran perintah:

SUCCESS

Jika kamu mencurigai ada perintah yang gagal, kamu dapat menjalankan:

kubectl describe pods/private-image-test-1 | grep 'Failed'

Pada kasus gagal, keluarannya mirip seperti:

  Fri, 26 Jun 2015 15:36:13 -0700    Fri, 26 Jun 2015 15:39:13 -0700    19    {kubelet node-i2hq}    spec.containers{uses-private-image}    failed        Failed to pull image "user/privaterepo:v1": Error: image user/privaterepo:v1 not found

Kamu harus memastikan semua Node di dalam klaster memiliki .docker/config.json yang sama. Jika tidak, Pod-Pod akan jalan pada beberapa Node saja dan gagal di Node lainnya. Contohnya, jika kamu menggunakan Node autoscaling, maka setiap templat instance perlu untuk mempunyai .docker/config.json atau mount sebuah penyimpanan yang berisi berkas tersebut.

Semua Pod memiliki akses baca (read) untuk image-image di registri privat manapun ketika key registri privat ditambahkan pada .docker/config.json.

Image Pra-unduh

Catatan: Jika kamu jalan di Google Kubernetes Engine, maka akan ada .dockercfg pada setiap Node dengan kredensial untuk Google Container Registry. Kamu dapat menggunakan cara ini.

Catatan: Cara ini cocok jika kamu dapat mengontrol konfigurasi Node. Cara ini tidak akan bisa berjalan dengan baik pada GCE, dan penyedia cloud lainnya yang tidak menggantikan Node secara otomatis.

Secara default, kubelet akan mencoba untuk mengunduh setiap image dari registri yang dispesifikasikan. Hanya saja, jika properti imagePullPolicy diatur menjadi IfNotPresent atau Never, maka sebuah image lokal digunakan.

Jika kamu ingin memanfaatkan image pra-unduh sebagai pengganti untuk otentikasi registri, kamu harus memastikan semua Node di dalam klaster memiliki image pra-unduh yang sama.

Cara ini bisa digunakan untuk memuat image tertentu untuk kecepatan atau sebagai alternatif untuk otentikasi untuk sebuah registri privat.

Semua Pod akan mendapatkan akses baca ke image pra-unduh manapun.

Tentukan ImagePullSecrets pada sebuah Pod

Catatan: Cara ini merupakan cara yang direkomendasikan saat ini untuk Google Kubernetes Engine, GCE, dan penyedia cloud lainnya yang secara otomatis dapat membuat Node.

Kubernetes mendukung penentuan key registri pada sebuah Pod.

Membuat sebuah Secret dengan Docker Config

Jalankan perintah berikut, ganti nilai huruf besar dengan yang tepat:

kubectl create secret docker-registry <name> --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL

Jika kamu sudah memiliki berkas kredensial Docker, daripada menggunakan perintah di atas, kamu dapat mengimpor berkas kredensial sebagai Kubernetes Secret. Membuat sebuah Secret berbasiskan pada kredensial Docker yang sudah ada menjelaskan bagaimana mengatur ini. Cara ini berguna khususnya jika kamu menggunakan beberapa registri kontainer privat, perintah kubectl create secret docker-registry akan membuat sebuah Secret yang akan hanya bekerja menggunakan satu registri privat.

Catatan: Pod-Pod hanya dapat mengacu pada imagePullSecrets di dalam namespace, sehingga proses ini perlu untuk diselesaikan satu kali setiap namespace.

Mengacu pada imagePullSecrets di dalam sebuah Pod

Sekarang, kamu dapat membuat Pod yang mengacu pada Secret dengan menambahkan bagian imagePullSecrets untuk sebuah definisi Pod.

cat <<EOF > pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: foo
  namespace: awesomeapps
spec:
  containers:
    - name: foo
      image: janedoe/awesomeapp:v1
  imagePullSecrets:
    - name: myregistrykey
EOF

cat <<EOF >> ./kustomization.yaml
resources:
- pod.yaml
EOF

Cara ini perlu untuk diselesaikan untuk setiap Pod yang mengguunakan registri privat.

Hanya saja, mengatur field ini dapat diotomasi dengan mengatur imagePullSecrets di dalam sumber daya serviceAccount. Periksa Tambahan ImagePullSecrets untuk sebuah Service Account untuk instruksi yang lebih detail.

Kamu dapat menggunakan cara ini bersama .docker/config.json pada setiap Node. Kredensial-kredensial akan dapat di-merged. Cara ini akan dapat bekerja pada Google Kubernetes Engine.

Kasus-Kasus Penggunaan (Use Case)

Ada beberapa solusi untuk konfigurasi registri privat. Berikut beberapa kasus penggunaan dan solusi yang disarankan.

1. Klaster yang hanya menjalankan image non-proprietary (misalnya open-source). Tidak perlu unutuk menyembunyikan image.
   • Gunakan image publik pada Docker hub.
     • Tidak ada konfigurasi yang diperlukan.
     • Pada GCE/Google Kubernetes Engine, sebuah mirror lokal digunakan secara otomatis untuk meningkatkan kecepatan dan ketersediaan.
2. Klaster yang menjalankan image proprietary yang seharusnya disembunyikan dari luar perusahaan, tetapi bisa terlihat oleh pengguna klaster.
   • Gunakan sebuah privat registri Docker yang hosted.
     • Bisa saja di-host pada Docker Hub, atau lainnya.
     • Konfigurasi .docker/config.json secara manual pada setiap Node seperti dijelaskan di atas.
   • Atau, jalankan sebuah registri privat internal di belakang firewall kamu dengan akses baca terbuka.
     • Tidak ada konfigurasi Kubernetes yang diperlukan.
   • Atau, ketika pada GCE/Google Kubernetes Engine, menggunakan Google Container Registry yang ada di proyek.
     • Hal ini bisa bekerja baik dengan autoscaling klaster dibandingkan konfigurasi Node manual.
   • Atau, pada sebuah klaster dimana mengubah konfigurasi Node tidak nyaman, gunakan imagePullSecrets.
3. Klaster dengan image proprietary, beberapa memerlukan akses kontrol yang lebih ketat.
   • Pastikan AlwaysPullImages admission controller aktif. Sebaliknya, semua Pod berpotensi memiliki akses ke semua image.
   • Pindahkan data sensitif pada sumber daya "Secret", daripada mengemasnya menjadi sebuah image.
4. Sebuah klaster multi-tenant dimana setiap tenant memerlukan registri privatnya masing-masing.
   • Pastikan AlwaysPullImages admission controller aktif. Sebaliknya, semua Pod dari semua tenant berpotensi memiliki akses pada semua image.
   • Jalankan sebuah registri privat dimana otorisasi diperlukan.
   • Men-generate kredensial registri uuntuk setiap tenant, masukkan ke dalam secret uuntuk setiap namespace tenant.
   • Tenant menambahkan secret pada imagePullSecrets uuntuk setiap namespace.

Jika kamu memiliki akses pada beberapa registri, kamu dapat membuat satu secret untuk setiap registri. Kubelet akan melakukan merge imagePullSecrets manapun menjadi sebuah virtual .docker/config.json.

3.3 - Kontainer Environment

Laman ini menjelaskan berbagai resource yang tersedia di dalam Kontainer pada suatu environment.

Environment Kontainer

Environment Kontainer pada Kubernetes menyediakan beberapa resource penting yang tersedia di dalam Kontainer:

• Sebuah Filesystem, yang merupakan kombinasi antara image dan satu atau banyak volumes.
• Informasi tentang Kontainer tersebut.
• Informasi tentang objek-objek lain di dalam klaster.

Informasi tentang Kontainer

Hostname sebuah Kontainer merupakan nama dari Pod dimana Kontainer dijalankan. Informasi ini tersedia melalui perintah hostname atau panggilan (function call) gethostname pada libc.

Nama Pod dan namespace tersedia sebagai variabel environment melalui API downward.

Variabel environment yang ditulis pengguna dalam Pod definition juga tersedia di dalam Kontainer, seperti halnya variabel environment yang ditentukan secara statis di dalam image Docker.

Informasi tentang Klaster

Daftar semua Service yang dijalankan ketika suatu Kontainer dibuat, tersedia di dalam Kontainer tersebut sebagai variabel environment. Variabel-variabel environment tersebut sesuai dengan sintaksis links dari Docker.

Untuk suatu Service bernama foo yang terkait dengan Kontainer bernama bar, variabel-variabel di bawah ini tersedia:

FOO_SERVICE_HOST=<host dimana service dijalankan>
FOO_SERVICE_PORT=<port dimana service dijalankan>

Semua Service memiliki alamat-alamat IP yang bisa didapatkan di dalam Kontainer melalui DNS, jika addon DNS diaktifkan. 

Selanjutnya

• Pelajari lebih lanjut tentang berbagai hook pada lifecycle Kontainer.
• Dapatkan pengalaman praktis soal memberikan handler untuk event dari lifecycle Kontainer.

3.4 - Runtime Class

Laman ini menjelaskan tentang resource RuntimeClass dan proses pemilihan runtime.

Peringatan: RuntimeClass memiliki breaking change untuk pembaruan ke beta pada v1.14. Jika kamu menggunakan RuntimeClass sebelum v1.14, lihat Memperbarui RuntimeClass dari Alpha ke Beta.

Runtime Class

RuntimeClass merupakan sebuah fitur untuk memilih konfigurasi runtime kontainer. Konfigurasi tersebut digunakan untuk menjalankan kontainer-kontainer milik suatu Pod.

Persiapan

Pastikan gerbang fitur (feature gate) RuntimeClass sudah aktif (secara default sudah aktif). Lihat Gerbang Fitur untuk lebih jelasnya soal pengaktifan gerbang fitur. Gerbang fitur RuntimeClass ini harus aktif pada semua apiserver dan kubelet.

1. Lakukan konfigurasi pada implementasi CRI untuk setiap node (tergantung runtime yang dipilih)
2. Buat resource RuntimeClass yang terkait

1. Lakukan konfigurasi pada implementasi CRI untuk setiap node

Pilihan konfigurasi yang tersedia melalui RuntimeClass tergantung pada implementasi Container Runtime Interface (CRI). Lihat bagian (di bawah ini) soal bagaimana melakukan konfigurasi untuk implementasi CRI yang kamu miliki.

Catatan: Untuk saat ini, RuntimeClass berasumsi bahwa semua node di dalam klaster punya konfigurasi yang sama (homogen). Jika ada node yang punya konfigurasi berbeda dari yang lain (heterogen), maka perbedaan ini harus diatur secara independen di luar RuntimeClass melalui fitur scheduling (lihat Menempatkan Pod pada Node).

Seluruh konfigurasi memiliki nama handler yang terkait, dijadikan referensi oleh RuntimeClass. Nama handler harus berupa valid label 1123 DNS (alfanumerik + karakter -).

2. Buat resource RuntimeClass yang terkait

Masing-masing konfigurasi pada langkah no.1 punya nama handler yang merepresentasikan konfigurasi-konfigurasi tersebut. Untuk masing-masing handler, buatlah sebuah objek RuntimeClass terkait.

Resource RuntimeClass saat ini hanya memiliki 2 field yang penting: nama RuntimeClass tersebut (metadata.name) dan handler (handler). Definisi objek tersebut terlihat seperti ini:

apiVersion: node.k8s.io/v1beta1  # RuntimeClass didefinisikan pada grup API node.k8s.io
kind: RuntimeClass
metadata:
  name: myclass  # Nama dari RuntimeClass yang nantinya akan dijadikan referensi
  # RuntimeClass merupakan resource tanpa namespace
handler: myconfiguration  # Nama dari konfigurasi CRI terkait

Catatan: Sangat disarankan untuk hanya memperbolehkan admin klaster melakukan operasi write pada RuntimeClass. Biasanya ini sudah jadi default. Lihat Ikhtisar Autorisasi untuk penjelasan lebih jauh.

Penggunaan

Ketika RuntimeClass sudah dikonfigurasi pada klaster, penggunaannya sangatlah mudah. Kamu bisa tentukan runtimeClassName di dalam spec sebuah Pod, sebagai contoh:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  runtimeClassName: myclass
  # ...

Kubelet akan mendapat instruksi untuk menggunakan RuntimeClass dengan nama yang sudah ditentukan tersebut untuk menjalankan Pod ini. Jika RuntimeClass dengan nama tersebut tidak ditemukan, atau CRI tidak dapat menjalankan handler yang terkait, maka Pod akan memasuki tahap Failed. Lihat event untuk mengetahui pesan error yang terkait.

Jika tidak ada runtimeClassName yang ditentukan di dalam Pod, maka RuntimeHandler yang default akan digunakan. Untuk kasus ini, perilaku klaster akan seperti saat fitur RuntimeClass dinonaktifkan.

Konfigurasi CRI

Lihat instalasi CRI untuk lebih detail mengenai pengaturan runtime CRI.

dockershim

Built-in dockershim CRI yang dimiliki Kubernetes tidak mendukung handler runtime.

containerd

Handler runtime diatur melalui konfigurasi containerd pada /etc/containerd/config.toml. Handler yang valid dapat dikonfigurasi pada bagian runtime:

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]

Lihat dokumentasi konfigurasi containerd untuk lebih detail: https://github.com/containerd/cri/blob/master/docs/config.md

cri-o

Handler runtime dapat diatur menggunakan konfigurasi cri-o pada /etc/crio/crio.conf. Handler yang valid dapat dikonfigurasi pada tabel crio.runtime:

[crio.runtime.runtimes.${HANDLER_NAME}]
  runtime_path = "${PATH_TO_BINARY}"

Lihat dokumentasi konfigurasi cri-o untuk lebih detail: https://github.com/kubernetes-sigs/cri-o/blob/master/cmd/crio/config.go

Memperbarui RuntimeClass dari Alpha ke Beta

Fitur Beta pada RuntimeClass memiliki perubahan sebagai berikut:

• Grup API resource node.k8s.io dan runtimeclasses.node.k8s.io telah dimigrasi ke suatu API built-in dari CustomResourceDefinition.
• Atribut spec telah disederhakan pada definisi RuntimeClass (tidak ada lagi yang namanya RuntimeClassSpec).
• Field runtimeHandler telah berubah nama menjadi handler.
• Field handler sekarang bersifat wajib untuk semua versi API. Artinya, field runtimeHandler pada API Alpha juga bersifat wajib.
• Field handler haruslah berupa label DNS valid (RFC 1123), yang artinya tidak bisa berisi karakter . (pada semua versi). Handler valid harus sesuai dengan regular expression ini: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$.

Tindakan yang diperlukan: Tindakan-tindaka berikut ini diperlukan untuk melakukan pembaruan fitur RuntimeClass dari versi alpha ke versi beta:

• Resource RuntimeClass harus dibuat ulang setelah diperbarui ke v.1.14, dan CRD runtimeclasses.node.k8s.io harus dihapus secara manual:

  kubectl delete customresourcedefinitions.apiextensions.k8s.io runtimeclasses.node.k8s.io
  

• Fitur Alpha pada RuntimeClass akan menjadi tidak valid, jika runtimeHandler tidak ditentukan atau kosong atau menggunakan karakter . pada handler. Ini harus dimigrasi ke handler dengan konfigurasi yang valid (lihat petunjuk di atas).

3.5 - Lifecyle Hook pada Kontainer

Laman ini menjelaskan bagaimana semua Kontainer yang diatur kubelet menggunakan framework lifecycle hook untuk menjalankan kode yang di-trigger oleh event selama lifecycle berlangsung.

Ikhtisar

Kubernetes menyediakan hook untuk lifecycle Kontainer. Hal ini sejalan dengan framework bahasa pemrograman pada umumnya yang memiliki hook untuk lifecycle komponen, seperti Angular contohnya. Hook tersebut digunakan Kontainer untuk selalu siap menerima event selama lifecycle dan menjalankan kode yang diimplementasi pada suatu handler, ketika hook lifecycle terkait telah dieksekusi.

Jenis-jenis hook pada Kontainer

Ada dua jenis hook yang diekspos pada Kontainer:

PostStart

Hook ini dijalankan segera setelah suatu kontainer dibuat. Hanya saja, tidak ada jaminan bahwa hook akan tereksekusi sebelum ENTRYPOINT dari kontainer. Tidak ada parameter yang diberikan pada handler.

PreStop

Hook ini akan dipanggil sesaat sebelum kontainer dimatikan, karena suatu request API atau event pengaturan, contohnya kegagalan pada liveness probe, preemption, perebutan resource, dan lainnya. Sebuah panggilan untuk hook PreStop akan gagal jika kontainer tersebut telah ada pada state terminate atau complete. Hal ini bersifat blocking, yang artinya panggilan bersifat sinkron (synchronous), harus menunggu eksekusi selesai, sebelum melakukan panggilan untuk menghapus kontainer tersebut. Tidak ada parameter yang diberikan pada handler.

Penjelasan yang lebih rinci tentang proses terminasi dapat dilihat pada Terminasi Pod.

Implementasi handler untuk hook

Kontainer dapat mengakses sebuah hook melalui implementasi dan registrasi sebuah handler untuk hook tersebut. Ada dua jenis handler untuk hook yang dapat diimplementasikan untuk Kontainer:

• Exec - Mengeksekusi sebuah perintah tertentu, contohnya pre-stop.sh, di dalam cgroups dan namespace suatu Kontainer. Resource yang dikonsumsi oleh perintah tersebut dianggap sebagai bagian dari Kontainer.
• HTTP - Mengeksekusi sebuah request HTTP untuk endpoint tertentu pada Kontainer tersebut.

Eksekusi handler untuk hook

Ketika manajemen hook untuk suatu lifecycle Kontainer dipanggil, sistem manajemen internal pada Kubernetes akan mengeksekusi handler di dalam Kontainer yang terdaftar untuk hook tersebut.

Panggilan handler untuk hook semuanya bersifat synchronous di dalam konteks Pod yang memiliki Kontainer tersebut. Artinya, untuk hook PostStart, Kontainer ENTRYPOINT dan hook dieksekusi secara asyncrhonous. Akan tetapi, jika hook mengambil waktu terlalu lama, atau hang, Kontainer tersebut tidak bisa sampai ke state running.

Perilaku ini mirip dengan yang terjadi pada hook PreStop. Jika hook terlalu lama atau hang saat dieksekusi, Pod tersebut tetap ada pada state Terminating dan akan dimatikan setelah terminationGracePeriodSeconds Pod selesai. Jika sebuah hook PostStart atau PreStop gagal dieksekusi, Kontainer akan dimatikan.

Para pengguna sangat disarankan membuat handler untuk hook seringan mungkin (lightweight). Biar bagaimanapun, ada beberapa kasus yang memang membutuhkan waktu lama untuk mengeksekusi suatu perintah, misalnya saat proses penyimpanan state sebelum Kontainer dimatikan.

Jaminan pengiriman hook

Proses pengiriman hook akan dilakukan paling tidak satu kali. Artinya suatu hook boleh dipanggil beberapa kali untuk event yang sama, seperti dalam PostStart atauPreStop. Namun begitu, implementasi hook masing-masing harus memastikan bagaimana menangani kasus ini dengan benar.

Pada umumnya, hanya terjadi satu proses pengiriman. Jika misalnya sebuah penerima HTTP hook mati atau tidak bisa menerima trafik, maka tidak ada usaha untuk mengirimkan kembali. Namun demikian, bisa saja terjadi dua kali proses pengiriman untuk kasus tertentu. Contohnya, jika kubelet restart saat di tengah proses pengiriman hook, hook tersebut akan dikirimkan kembali saat kubelet sudah hidup kembali.

Melakukan debug handler untuk hook

Log untuk suatu handler hook tidak terekspos pada event Pod. Jika handler gagal dieksekusi untuk alasan tertentu, handler akan melakukan broadcast sebuah event. Untuk PostStart, akan dilakukan broadcast event FailedPostStartHook, dan untuk PreStop, akan dilakukan broadcast event FailedPreStopHook. Kamu dapat melihat event-event ini dengan menjalankan perintah kubectl describe pod <pod_name>. Berikut merupakan contoh keluaran event-event setelah perintah tersebut dijalankan.

Events:
  FirstSeen  LastSeen  Count  From                                                   SubobjectPath          Type      Reason               Message
  ---------  --------  -----  ----                                                   -------------          --------  ------               -------
  1m         1m        1      {default-scheduler }                                                          Normal    Scheduled            Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd
  1m         1m        1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Pulling              pulling image "test:1.0"
  1m         1m        1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Created              Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined]
  1m         1m        1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Pulled               Successfully pulled image "test:1.0"
  1m         1m        1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Started              Started container with docker id 5c6a256a2567
  38s        38s       1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Killing              Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1
  37s        37s       1      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Normal    Killing              Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1
  38s        37s       2      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}                         Warning   FailedSync           Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1"
  1m         22s       2      {kubelet gke-test-cluster-default-pool-a07e5d30-siqd}  spec.containers{main}  Warning   FailedPostStartHook

Selanjutnya

• Pelajari lebih lanjut tentang environment Kontainer.
• Pelajari bagaimana caranya melakukan attach handler pada event lifecycle sebuah Kontainer.

4 - Workloads

4.1 - Pods

4.1.1 - Pengenalan Pod

Halaman ini menyajikan ikhtisar dari Pod, objek terkecil yang dapat di deploy di dalam objek model Kubernetes.

Memahami Pod

Sebuah Pod adalah unit dasar di Kubernetes--unit terkecil dan paling sederhana di dalam objek model Kubernetes yang dapat dibuat dan di deploy. Sebuah Pod merepresentasikan suatu proses yang berjalan di dalam klaster.

Pod membungkus sebuah kontainer (atau, di beberapa kasus, beberapa kontainer), sumber penyimpanan, alamat jaringan IP yang unik, dan opsi yang mengatur bagaimana kontainer harus dijalankan. Pod merupakan representasi dari unit deployment: sebuah instance aplikasi di dalam Kubernetes, yang mungkin terdiri dari satu kontainer atau sekumpulan kontainer yang berbagi resource.

Docker adalah salah satu kontainer runtime yang paling umum digunakan di Kubernetes Pod, tetapi Pod mendukung kontainer runtime lainnya.

Pod di Kubernetes klaster dapat digunakan dengan dua cara:

• Pod menjalankan satu kontainer. Model satu kontainer per Pod adalah model yang umum digunakan di Kubernetes; kamu dapat membayangkan sebuah Pod sebagai pembungkus kontainer tersebut, dan Kubernetes tidak mengelola kontainer secara langsung tetapi mengelola Pod tersebut.
• Pod menjalankan beberapa kontainer yang perlu berjalan bersamaan. Sebuah Pod dapat membungkus sebuah aplikasi yang terdiri dari beberapa kontainer yang perlu berbagi resource. Kontainer yang ditempatkan di dalam satu Pod ini membentuk sebuah layanan. Sebuah kontainer menyajikan berkas dari sumber penyimpanan ke publik, sedangkan kontainer sidecar yang lain melakukan pembaharuan terhadap berkas tersebut. Pod membungkus semua kontainer dan resource penyimpanan sebagai satu kesatuan yang dapat dikelola.

Kubernetes Blog menyediakan beberapa informasi tambahan terkait penggunaan Pod. Informasi selengkapnya, kunjungi:

• The Distributed System Toolkit: Patterns for Composite Containers
• Container Design Patterns

Setiap Pod dimaksudkan untuk menjalankan satu instance aplikasi. Jika kamu ingin mengembangkan aplikasi secara horizontal (contoh, banyak instance sekaligus), kamu dapat menggunakan banyak Pod, satu untuk setiap instance. Di Kubernetes, konsep ini umumnya disebut dengan replikasi. Pod yang direplikasi biasanya dibuat dan dikelola sebagai grup oleh objek abstraksi yang disebut kontroler. Lihat Pod dan Kontroler untuk informasi selengkapnya.

Bagaimana Pod mengelola beberapa Kontainer

Pod didesain untuk mendukung banyak proses (sebagai kontainer) yang membentuk sebuah layanan. Kontainer di dalam sebuah Pod akan otomatis ditempatkan bersama di dalam satu mesin fisik atau mesin virtual di dalam klaster. Kontainer tersebut dapat berbagi resource dan dependensi, berkomunikasi satu sama lain, dan berkoordinasi kapan dan bagaimana mereka diterminasi.

Perhatikan bahwa mengelompokan kontainer di dalam satu Pod merupakan kasus lanjutan. Kamu dapat menggunakan pola ini hanya dalam kasus tertentu. Sebagai contoh, kamu memiliki kontainer yang bertindak sebagai web server yang menyajikan berkas dari resource penyimpanan bersama, dan kontainer sidecar melakukan pembaharuan terhadap berkas tersebut dari sumber lain, seperti dalam diagram Pod berikut:

Pod menyediakan dua jenis resource sebagai penyusun dari kontainer: jaringan dan penyimpanan.

Jaringan

Setiap Pod diberikan sebuah alamat IP unik. Setiap kontainer di dalam Pod berbagi network namespace, termasuk alamat IP dan port jaringan. Setiap kontainer di dalam Pod dapat berkomunikasi satu sama lain menggunakan localhost. Saat para kontainer di dalam Pod berkomunikasi dengan entitas lain di luar Pod, mereka harus berkoordinasi satu sama lain bagaimana mereka menggunakan resource jaringan (seperti Port).

Penyimpanan

Pod dapat menentukan penyimpanan bersama yaitu volumes. Semua kontainer di dalam Pod dapat mengakses volumes ini, mengizinkan kontainer untuk berbagi data. Volumes juga memungkinkan data di Pod untuk bertahan jika salah satu kontainer perlu melakukan proses restart. Lihat Volumes untuk informasi lebih lanjut bagaimana Kubernetes mengimplementasikan penyimpanan di dalam Pod.

Bekerja dengan Pod

Kamu akan jarang membuat Pod secara langsung di Kubernetes. Ini karena Pod dirancang sebagai entitas sesaat. Saat Pod dibuat (baik oleh kamu, atau secara tidak langsung oleh kontroler), Pod ditempatkan dan dijalankan di sebuah Node di dalam klaster. Pod akan tetap di Node tersebut sampai proses dihentikan, Objek Pod dihapus, Pod dihentikan karena kekurangan resource, atau Node tersebut berhenti berjalan.

Catatan: Tidak perlu bingung untuk membedakan antara menjalankan ulang sebuah kontainer di dalam Pod dan menjalankan ulang Pod. Pod itu sendiri tidak berjalan, tetapi Pod adalah environment kontainer itu berjalan dan akan tetap ada sampai dihapus.

Pod tidak melakukan mekanisme penyembuhan diri sendiri. Jika Pod ditempatkan disebuah Node yang gagal, atau proses penempatan Pod itu sendiri gagal, Pod akan dihapus; demikian juga, Pod tidak akan bertahan jika Node tersebut kehabisan resource atau sedang dalam tahap pemeliharaan. Kubernetes menggunakan abstraksi yang disebut kontroler, yang menangani dan mengelola Pod. Jadi, meskipun Pod dapat dipakai secara langsung di Kubernetes, kontroler merupakan cara umum yang digunakan untuk mengelola Pod. Lihat Pod dan kontroler untuk informasi lebih lanjut bagaimana Kubernetes menggunakan kontroler untuk mengimpelentasikan mekanisme penyembuhan diri sendiri dan replikasi pada Pod.

Pod dan Kontroler

Kontroler dapat membuat dan mengelola banyak Pod untuk kamu, menangani replikasi dan menyediakan kemampuan penyembuhan diri sendiri pada lingkup klaster. Sebagai contoh, jika sebuah Node gagal, kontroler akan otomatis mengganti Pod tersebut dengan menempatkan Pod yang identik di Node yang lain.

Beberapa contoh kontroler yang berisi satu atau lebih Pod meliputi:

• Deployment
• StatefulSet
• DaemonSet

Secara umum, kontroler menggunakan templat Pod yang kamu sediakan untuk membuat Pod.

Templat Pod

Templat Pod adalah spesifikasi dari Pod yang termasuk di dalam objek lain seperti Replication Controllers, Jobs, dan DaemonSets. Kontroler menggunakan templat Pod untuk membuat Pod.

Contoh di bawah merupakan manifestasi sederhana untuk Pod yang berisi kontainer yang membuat sebuah pesan.

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']

Perubahan yang terjadi pada templat atau berganti ke templat yang baru tidak memiliki efek langsung pada Pod yang sudah dibuat. Pod yang dibuat oleh replication controller dapat diperbarui secara langsung.

Selanjutnya

• Pelajari lebih lanjut tentang perilaku Pod:
  • Terminasi Pod
  • Lifecycle Pod

4.1.2 - Pod

Pod adalah unit komputasi terkecil yang bisa di-deploy dan dibuat serta dikelola dalam Kubernetes.

Apa Itu Pod?

Sebuah Pod (seperti pod pada paus atau kacang polong) adalah sebuah kelompok yang terdiri dari satu atau lebih kontainer (misalnya kontainer Docker), dengan ruang penyimpanan ataupun jaringan yang dipakai bersama, dan sebuah spesifikasi mengenai bagaimana menjalankan kontainer. Isi dari Pod akan selalu diletakkan dan dijadwalkan bersama, serta berjalan dalam konteks yang sama. Sebuah Pod memodelkan "logical host" yang spesifik terhadap aplikasi. Ini mengandung lebih dari satu kontainer aplikasi yang secara relatif saling terhubung erat. Sebelum masa kontainer, menjalankan aplikasi dalam mesin fisik atau virtual berarti menjalankan dalam logical host yang sama.

Walaupun Kubernetes mendukung lebih banyak runtime kontainer selain Docker, namun Docker adalah yang paling umum diketahui dan ini membantu dalam menjelaskan Pod dengan istilah pada Docker.

Konteks bersama dalam sebuah Pod adalah kumpulan Linux namespace, cgroup dan kemungkinan segi isolasi lain, hal yang sama yang mengisolasi kontainer Docker. Dalam sebuah konteks pada Pod, setiap aplikasi bisa menerapkan sub-isolasi lebih lanjut.

Semua kontainer dalam suatu Pod akan berbagi alamat IP dan port yang sama, dan bisa saling berkomunikasi melalui localhost. Komunikasi tersebut mengunakan standar inter-process communications (IPC) seperti SystemV semaphores atau POSIX shared memory. Kontainer pada Pod yang berbeda memiliki alamat IP yang berbeda dan tidak dapat berkomunikasi menggunakan IPC tanpa pengaturan khusus. Kontainer ini biasa berkomunikasi dengan yang lain menggunakan alamat IP setiap Pod.

Aplikasi dalam suatu Pod juga memiliki akses ke ruang penyimpanan bersama, yang didefinisikan sebagai bagian dari Pod dan dibuat bisa diikatkan ke masing-masing filesystem pada aplikasi.

Dalam istilah konsep Docker, sebuah Pod dimodelkan sebagai gabungan dari kontainer Docker yang berbagi namespace dan ruang penyimpanan filesystem.

Layaknya aplikasi dengan kontainer, Pod dianggap sebagai entitas yang relatif tidak kekal (tidak bertahan lama). Seperti yang didiskusikan dalam siklus hidup Pod, Pod dibuat, diberikan ID unik (UID), dan dijadwalkan pada suatu mesin dan akan tetap disana hingga dihentikan (bergantung pada aturan restart) atau dihapus. Jika mesin mati, maka semua Pod pada mesin tersebut akan dijadwalkan untuk dihapus, namun setelah suatu batas waktu. Suatu Pod tertentu (sesuai dengan ID unik) tidak akan dijadwalkan ulang ke mesin baru, namun akan digantikan oleh Pod yang identik, bahkan jika dibutuhkan bisa dengan nama yang sama, tapi dengan ID unik yang baru (baca replication controller untuk info lebih lanjut)

Ketika sesuatu dikatakan memiliki umur yang sama dengan Pod, misalnya saja ruang penyimpanan, maka itu berarti akan tetap ada selama Pod tersebut masih ada. Jika Pod dihapus dengan alasan apapun, sekalipun Pod pengganti yang identik telah dibuat, semua yang berhubungan (misalnya ruang penyimpanan) akan dihapus dan dibuat ulang.

Sebuah Pod dengan banyak kontainer, yaitu File Puller dan Web Server yang menggunakan ruang penyimpanan persisten untuk berbagi ruang penyimpanan bersama antara kontainer.

Motivasi suatu Pods

Pengelolaan

Pod adalah suatu model dari pola beberapa proses yang bekerja sama dan membentuk suatu unit layanan yang kohesif. Menyederhanakan proses melakukan deploy dan pengelolaan aplikasi dengan menyediakan abstraksi tingkat yang lebih tinggi daripada konstituen aplikasinya. Pod melayani sebagai unit dari deployment, penskalaan horizontal, dan replikasi. Colocation (co-scheduling), berbagi nasib (misalnya dimatikan), replikasi terkoordinasi, berbagi sumber daya dan pengelolaan ketergantungan akan ditangani otomatis untuk kontainer dalam suatu Pod.

Berbagi sumber daya dan komunikasi

Pod memungkinkan berbagi data dan komunikasi diantara konstituennya.

Semua aplikasi dalam suatu Pod menggunakan namespace jaringan yang sama (alamat IP dan port yang sama), dan menjadikan bisa saling mencari dan berkomunikasi dengan menggunakan localhost. Oleh karena itu, aplikasi dalam Pod harus berkoordinasi mengenai penggunaan port. Setiap Pod memiliki alamat IP dalam satu jaringan bersama yang bisa berkomunikasi dengan komputer lain dan Pod lain dalam jaringan yang sama.

Kontainer dalam suatu Pod melihat hostname sistem sebagai sesuatu yang sama dengan konfigurasi name pada Pod. Informasi lebih lanjut terdapat dibagian jaringan.

Sebagai tambahan dalam mendefinisikan kontainer aplikasi yang berjalan dalam Pod, Pod memberikan sepaket sistem penyimpanan bersama. Sistem penyimpanan memungkinkan data untuk bertahan saat kontainer dijalankan ulang dan dibagikan kepada semua aplikasi dalam Pod tersebut.

Penggunaan Pod

Pod dapat digunakan untuk menjalankan beberapa aplikasi yang terintegrasi secara vertikal (misalnya LAMP), namun motivasi utamanya adalah untuk mendukung berlokasi bersama, mengelola program pembantu, diantaranya adalah:

• sistem pengelolaan konten, pemuat berkas dan data, manajer cache lokal, dll.
• catatan dan checkpoint cadangan, kompresi, rotasi, dll.
• pengamat perubahan data, pengintip catatan, adapter pencatatan dan pemantauan, penerbit peristiwa, dll.
• proksi, jembatan dan adaptor.
• pengontrol, manajer, konfigurasi dan pembaharu.

Secara umum, masing-masing Pod tidak dimaksudkan untuk menjalankan beberapa aplikasi yang sama.

Penjelasan lebih lengkap bisa melihat The Distributed System ToolKit: Patterns for Composite Containers.

Alternatif pertimbangan

Kenapa tidak menjalankan banyak program dalam satu kontainer (Docker)?

1. Transparansi. Membuat kontainer dalam suatu Pod menjadi terlihat dari infrastruktur, memungkinkan infrastruktur menyediakan servis ke kontainer tersebut, misalnya saja pengelolaan proses dan pemantauan sumber daya. Ini memfasilitasi sejumlah kenyamanan untuk pengguna.
2. Pemisahan ketergantungan perangkat lunak. Setiap kontainer mungkin memiliki versi, dibuat dan dijalankan ulang secara independen. Kubernetes mungkin mendukung pembaharuan secara langsung terhadap suatu kontainer, suatu saat nanti.
3. Mudah digunakan. Penguna tidak diharuskan menjalankan manajer prosesnya sendiri, khawatir dengan sinyal dan propagasi exit-code, dan lain sebagainya.
4. Efisiensi. Karena infrastruktur memegang lebih banyak tanggung jawab, kontainer bisa lebih ringan.

Kenapa tidak mendukung penjadwalan kontainer berdasarkan affinity?

Cara itu bisa menyediakan lokasi yang sama, namun tidak memberikan banyak keuntungan dari Pod, misalnya saja berbagi sumber daya, IPC, jaminan berbagi nasib dan kemudahan manajemen.

Ketahanan suatu Pod (atau kekurangan)

Pod tidak dimaksudkan untuk diperlakukan sebagai entitas yang tahan lama. Mereka tidak akan bertahan dengan kegagalan penjadwalan, kegagalan mesin, atau eviction (pengusiran), misalnya karena kurangnya sumber daya atau dalam suatu kasus mesin sedang dalam pemeliharaan.

Secara umum, pengguna tidak seharusnya butuh membuat Pod secara langsung. Mereka seharusnya selalu menggunakan pengontrol, sekalipun untuk yang tunggal, misalnya, Deployment. Pengontrol menyediakan penyembuhan diri dengan ruang lingkup kelompok, begitu juga dengan pengelolaan replikasi dan penluncuran. Pengontrol seperti StatefulSet bisa memberikan dukungan terhadap Pod yang stateful.

Penggunaan API kolektif sebagai user-facing primitive utama adalah hal yang relatif umum diantara sistem penjadwalan kluster, seperti

Borg, Marathon, Aurora, dan Tupperware.

Pod diekspose sebagai primitive untuk memfasilitasi hal berikut:

• penjadwalan dan pengontrol sifat pluggability
• mendukung operasi pada level Pod tanpa perlu melakukan proksi melalui API pengontrol
• pemisahan antara umur suatu Pod dan pengontrol, seperti misalnya bootstrapping.
• pemisahan antara pengontrol dan servis, pengontrol endpoint hanya memperhatikan Pod
• komposisi yang bersih antara fungsionalitas dilevel Kubelet dan klaster. Kubelet secara efektif adalah pengontrol Pod.
• aplikasi dengan ketersediaan tinggi, yang akan mengharapkan Pod akan digantikan sebelum dihentikan dan tentu saja sebelum dihapus, seperti dalam kasus penggusuran yang direncanakan atau pengambilan gambar.

Penghentian Pod

Karena Pod merepresentasikan proses yang berjalan pada mesin didalam klaster, sangat penting untuk memperbolehkan proses ini berhenti secara normal ketika sudah tidak dibutuhkan (dibandingkan dengan dihentikan paksa dengan sinyal KILL dan tidak memiliki waktu untuk dibersihkan). Pengguna seharusnya dapat meminta untuk menghapus dan tahu proses penghentiannya, serta dapat memastikan penghentian berjalan sempurna. Ketika pengguna meminta menghapus Pod, sistem akan mencatat masa tenggang untuk penghentian secara normal sebelum Pod dipaksa untuk dihentikan, dan sinyal TERM akan dikirim ke proses utama dalam setiap kontainer. Setelah masa tenggang terlewati, sinyal KILL akan dikirim ke setiap proses dan Pod akan dihapus dari API server. Jika Kubelet atau kontainer manajer dijalankan ulang ketika menunggu suatu proses dihentikan, penghentian tersebut akan diulang dengan mengembalikan masa tenggang senilai semula.

Contohnya sebagai berikut:

1. Pengguna mengirim perintah untuk menghapus Pod, dengan masa tenggang (30 detik)
2. Pod dalam API server akan diperbarui dengan waktu dimana Pod dianggap "mati" bersama dengan masa tenggang.
3. Pod ditampilkan dalam status "Terminating" ketika tercantum dalam perintah klien
4. (bersamaan dengan poin 3) Ketika Kubelet melihat Pod sudah ditandai sebagai "Terminating" karena waktu pada poin 2 sudah diatur, ini memulai proses penghentian Pod
   1. Jika salah satu kontainer pada Pod memiliki preStop hook, maka akan dipanggil di dalam kontainer. Jika preStop hook masih berjalan setelah masa tenggang habis, langkah 2 akan dipanggil dengan tambahan masa tenggang yang sedikit, 2 detik.
   2. Semua kontainer akan diberikan sinyal TERM. Sebagai catatan, tidak semua kontainer akan menerima sinyal TERM dalam waktu yang sama dan mungkin butuh waktu untuk menjalankan preStop hook jika bergantung pada urutan penghentiannya.
5. (bersamaan dengan poin 3) Pod akan dihapus dari daftar endpoint untuk servis dan tidak lagi dianggap sebagai bagian dari Pod yang berjalan dalam replication controllers. Pod yang dihentikan, secara perlahan tidak akan melayani permintaan karena load balancer (seperti servis proksi) menghapus mereka dari daftar rotasi.
6. Ketika masa tenggang sudah lewat, semua proses yang masih berjalan dalam Pod akan dihentikan dengan sinyal SIGKILL.
7. Kubelet akan selesai menghapus Pod dalam API server dengan mengatur masa tenggang menjadi 0 (langsung menghapus). Pod akan menghilang dari API dan tidak lagi terlihat oleh klien.

Secara default, semua penghapusan akan berjalan normal selama 30 detik. Perintah kubectl delete mendukung opsi --grace-period=<waktu dalam detik> yang akan memperbolehkan pengguna untuk menimpa nilai awal dan memberikan nilai sesuai keinginan pengguna. Nilai 0 akan membuat Pod dihapus paksa. Kamu harus memberikan opsi tambahan --force bersamaan dengan --grace-period=0 untuk melakukan penghapusan paksa.

Penghapusan paksa sebuah Pod

Penghapusan paksa dari sebuah Pod didefinisikan sebagai penghapusan Pod dari state klaster dan etcd secara langsung. Ketika penghapusan paksa dilakukan, API server tidak akan menunggu konfirmasi dari kubelet bahwa Pod sudah dihentikan pada mesin ia berjalan. Ini menghapus Pod secara langsung dari API, sehingga Pod baru bisa dibuat dengan nama yang sama. Dalam mesin, Pod yang dihentikan paksa akan tetap diberikan sedikit masa tenggang sebelum dihentikan paksa.

Penghentian paksa dapat menyebabkan hal berbahaya pada beberapa Pod dan seharusnya dilakukan dengan perhatian lebih. Dalam kasus StatefulSet Pods, silakan melihat dokumentasi untuk penghentian Pod dari StatefulSet.

Hak istimewa untuk kontainer pada Pod

Setiap kontainer dalam Pod dapat mengaktifkan hak istimewa (mode privileged), dengan menggunakan tanda privileged pada konteks keamanan pada spesifikasi kontainer. Ini akan berguna untuk kontainer yang ingin menggunakan kapabilitas Linux seperti memanipulasi jaringan dan mengakses perangkat. Proses dalam kontainer mendapatkan hak istimewa yang hampir sama dengan proses di luar kontainer. Dengan hak istimerwa, seharusnya lebih mudah untuk menulis pada jaringan dan plugin ruang penyimpanan sebagai Pod berbeda yang tidak perlu dikompilasi ke dalam kubelet.

Catatan: Runtime kontainer kamu harus mendukung konsep hak istimewa kontainer untuk membuat pengaturan ini menjadi relevan.

API Object

Pod adalah sumber daya tingkat tinggi dalam Kubernetes REST API. Definisi Objek Pod API menjelaskan mengenai objek secara lengkap.

4.1.3 - Siklus Hidup Pod

Halaman ini menjelaskan siklus hidup sebuah Pod

Fase Pod

Field status dari sebuah Pod merupakan sebuah objek PodStatus, yang memiliki sebuah field phase.

Fase dari sebuah Pod adalah sesuatu yang sederhana, ringkasan yang lebih tinggi tentang Pod dalam siklus hidupnya. Fase ini tidak ditujukan sebagai sebuah kesimpulan yang luas dari observasi suatu kontainer atau state suatu Pod, serta tidak ditujukan sebagai state machine yang luas.

Jumlah dan arti dari nilai-nilai fase Pod dijaga ketat. Selain yang ada dalam dokumentasi ini, tidak perlu berasumsi mengenai Pod telah diberikan nilai phase.

Berikut adalah nilai yang mungkin diberikan untuk suatu phase:

Kondisi Pod

Suatu Pod memiliki sebuah PodStatus, yang merupakan array dari PodConditions yang telah atau belum dilewati oleh Pod. Setiap elemen dari array PodConditions mungkin memiliki enam field berikut:

• Field lastProbeTime memberikan nilai timestamp yang menandakan kapan terakhir kali kondisi kondisi Pod diperiksa.

• Field lastTransitionTime memberikan nilai timestamp yang menandakan kapan terakhir kali Pod berubah status ke status lain.

• Field message adalah pesan yang bisa dibaca manusia yang mengidikasikan detail dari suatu transisi.

• Field reason adalah suatu alasan yang unik, satu kata, ditulis secara CamelCase untuk kondisi transisi terakhir.

• Field status adalah sebuah kata dengan kemungkinan nilainya berupa "True", "False", dan "Unknown".

• Field type adalah sebuah kata yang memiliki kemungkinan nilai sebagai berikut:

  • PodScheduled: Pod telah dijadwalkan masuk ke node;
  • Ready: Pod sudah mampu menerima request masuk dan seharusnya sudah ditambahkan ke daftar pembagian beban kerja untuk servis yang sama;
  • Initialized: Semua init containers telah berjalan sempurna.
  • Unschedulable: scheduler belum dapat menjadwalkan Pod saat ini, sebagai contoh karena kekurangan resources atau ada batasan-batasan lain.
  • ContainersReady: Semua kontainer di dalam Pod telah siap.

Pemeriksaan Kontainer

Sebuah Probe adalah sebuah diagnosa yang dilakukan secara berkala oleh kubelet dalam suatu kontainer. Untuk melakukan diagnosa, kubelet memanggil sebuah Handler yang diimplementasikan oleh kontainer. Ada 3 tipe Handler yang tersedia, yaitu:

• ExecAction: Mengeksekusi perintah tertentu di dalam kontainer. Diagnosa dikatakan berhasil jika perintah selesai dengan kode status 0.

• TCPSocketAction: Melakukan pengecekan TCP terhadap alamat IP kontainer dengan port tertentu. Diagnosa dikatakan berhasil jika port tersebut terbuka.

• HTTPGetAction: Melakukan sebuah request HTTP Get terhadap alamat IP kontainer dengan port dan path tertentu. Diagnosa dikatakan berhasil jika responnya memiliki kode status lebih besar atau sama dengan 200 dan kurang dari 400.

Setiap pemeriksaan akan menghasilkan salah satu dari tiga hasil berikut:

• Success: Kontainer berhasil melakukan diagnosa.
• Failure: Kontainer gagal melakukan diagnosa.
• Unknown: Gagal melakukan diagnosa, sehingga tidak ada aksi yang harus dilakukan.

Kubelet dapat secara optimal melakukan dan bereaksi terhadap dua jenis pemeriksaan yang sedang berjalan pada kontainer, yaitu:

• livenessProbe: Ini menunjukkan apakah kontainer sedang berjalan. Jika tidak berhasil melakukan pemeriksaan terhadap liveness dari kontainer, maka kubelet akan mematikan kontainer, dan kontainer akan mengikuti aturan dari restart policy. Jika kontainer tidak menyediakan pemeriksaan terhadap liveness, maka nilai dari state adalah Success.

• readinessProbe: Ini menunjukan apakah kontainer sudah siap melayani request. Jika tidak berhasil melakukan pemeriksaan terhadap kesiapan dari kontainer, maka endpoints controller akan menghapus alamat IP Pod dari daftar semua endpoint untuk servis yang sama dengan Pod. Nilai awal state sebelum jeda awal adalah Failure. Jika kontainer tidak menyediakan pemeriksaan terhadap readiness, maka nilai awal state adalah Success.

Kapan sebaiknya menggunakan pemeriksaan terhadap liveness atau readiness?

Jika proses dalam kontainer mungkin gagal yang dikarenakan menghadapi suatu masalah atau menjadi tidak sehat, maka pemeriksaan terhadap liveness tidak diperlukan. Kubelet akan secara otomatis melakukan aksi yang tepat mengikuti restartPolicy dari Pod.

Jika kamu ingin kontainer bisa dimatikan dan dijalankan ulang ketika gagal melakukan pemeriksaan, maka tentukan pemeriksaan liveness dan tentukan nilai restartPolicy sebagai Always atau OnFailure.

Jika kamu ingin mulai mengirim traffic ke Pod hanya ketika pemeriksaan berhasil, maka tentukan pemeriksaan readiness. Dalam kasus ini, pemeriksaan readiness mungkin akan sama dengan pemeriksaan liveness, tapi keberadaan pemeriksaan readiness dalam spec berarti Pod akan tetap dijalankan tanpa menerima traffic apapun dan akan mulai menerima traffic ketika pemeriksaan yang dilakukan mulai berhasil. Jika kontainermu dibutuhkan untuk tetap berjalan ketika loading data yang besar, file konfigurasi, atau melakukan migrasi ketika startup, maka tentukanlah pemeriksaan readiness.

Jika kamu ingin kontainermu dalam mematikan dirinya sendiri, kamu dapat menentukan suatu pemeriksaan readiness yang melakukan pengecekan terhadap endpoint untuk readiness. endpoint tersebut berbeda dengan endpoint untuk pengecekan liveness.

Perlu dicatat, jika kamu hanya ingin bisa menutup request ketika Pod sedang dihapus maka kamu tidak perlu menggunakan pemeriksaan readiness. Dalam penghapusan, Pod akan secara otomatis mengubah state dirinya menjadi unready tanpa peduli apakah terdapat pemeriksaan readiness atau tidak. Pod tetap ada pada state unready selama menunggu kontainer dalam Pod berhenti.

Untuk informasi lebih lanjut mengenai pengaturan pemeriksaan liveness atau readiness, lihat bagian Konfigurasi Liveness dan Readiness Probe.

Status Pod dan Kontainer

Untuk informasi lebih mendalam mengenai status Pod dan kontainer, silakan lihat PodStatus dan ContainerStatus. Mohon diperhatikan, informasi tentang status Pod bergantung pada ContainerState.

State Kontainer

Ketika Pod sudah ditempatkan pada suatu node oleh scheduler, kubelet mulai membuat kontainer menggunakan runtime kontainer. Ada tiga kemungkinan state untuk suatu kontainer, yaitu Waiting, Running, dan Terminated. Untuk mengecek state suatu kontainer, kamu bisa menggunakan perintah kubectl describe pod [NAMA_POD]. State akan ditampilkan untuk masing-masing kontainer dalam Pod tersebut.

• Waiting: Merupakan state default dari kontainer. Jika state kontainer bukan Running atau Terminated, berarti dalam Wating state. Suatu kontainer dalam Waiting state akan tetap menjalan operasi-operasi yang dibutuhkan, misalnya mengunduh images, mengaplikasikan Secrets, dsb. Bersamaan dengan state ini, sebuah pesan dan alasan tentang state akan ditampilkan untuk memberi informasi lebih.

  ...
    State:          Waiting
     Reason:       ErrImagePull
    ...
  

• Running: Menandakan kontainer telah berjalan tanpa masalah. Setelah kontainer masuk ke state Running, jika terdapat hook postStart maka akan dijalankan. State ini juga menampilkan waktu ketika kontainer masuk ke state Running.

  ...
     State:          Running
      Started:      Wed, 30 Jan 2019 16:46:38 +0530
  ...
  

• Terminated: Menandakan kontainer telah menyelesaikan "tugasnya". Kontainer akan menjadi state ini ketika telah menyelesaikan eksekusi atau terjadi kesalahan. Terlepas dari itu, sebuah alasan dan exit code akan ditampilkan, bersama dengan waktu kontainer mulai dijalankan dan waktu berhenti. Sebelum kontainer masuk ke state Terminated, jika terdapat preStop hook maka akan dijalankan.

  ...
     State:          Terminated
       Reason:       Completed
       Exit Code:    0
       Started:      Wed, 30 Jan 2019 11:45:26 +0530
       Finished:     Wed, 30 Jan 2019 11:45:26 +0530
   ...
  

Pod readiness gate

Dalam rangka menambahkan ekstensibilitas terhadap kesiapan Pod dengan menggunakan injeksi umpan balik tambahan atau sinyal ke dalam PodStatus, Kubernetes 1.11 memperkenalkan sebuah fitur bernama Pod ready++. Kamu dapat menggunakan field baru ReadinessGate dalam sebuah PodSpec untuk menunjukan kondisi tambahan yang akan dievaluasi untuk kesiapan Pod. Jika Kubernetes tidak dapat menemukan kondisi pada field status.conditions dalam suatu Pod, maka statusnya akan secara otomatis menjadi False. Berikut adalah contoh pemakaiannya:

Kind: Pod
...
spec:
  readinessGates:
    - conditionType: "www.example.com/feature-1"
status:
  conditions:
    - type: Ready  # ini adalah PodCondition yang telah tersedia
      status: "False"
      lastProbeTime: null
      lastTransitionTime: 2018-01-01T00:00:00Z
    - type: "www.example.com/feature-1"   # sebuah PodCondition tambahan
      status: "False"
      lastProbeTime: null
      lastTransitionTime: 2018-01-01T00:00:00Z
  containerStatuses:
    - containerID: docker://abcd...
      ready: true
...

Kondisi Pod yang baru harus memenuhi format label pada Kubernetes. Sejak perintah kubectl patch belum mendukung perubahan status objek, kondisi Pod yang baru harus mengubah melalui aksi PATCH dengan menggunakan salah satu dari KubeClient libraries.

Dengan diperkenalkannya kondisi Pod yang baru, sebuah Pod akan dianggap siap hanya jika memenuhi dua syarat berikut:

• Semua kontainer dalam Pod telah siap.
• Semua kontainer yang diatur dalam ReadinessGates bernilai "True".

Untuk memfasilitasi perubahan tersebut terhadap evaluasi kesiapan Pod, dibuatkan sebuah kondisi Pod baru yaitu ContainerReady, untuk dapat menangani kondisi Pod Ready yang sudah ada.

Dalam K8s 1.11, sebagai fitur alpha, fitur "Pod Ready++" harus diaktifkan melalui pengaturan fitur gate pada PodReadinessGates.

Dalam K8s 1.12, fitur tersebut sudah diaktifkan dari awal.

Aturan Menjalankan Ulang

Sebuah PodSpec memiliki field restartPolicy dengan kemungkinan nilai berupa Always, OnFailure, dan Never. Nilai awalnya berupa Always. restartPolicy akan berlaku untuk semua kontainer dalam Pod. Kontainer yang mati dan dijalankan ulang oleh kubelet akan dijalankan ulang dengan jeda waktu yang ekponensial (10s, 20s, 40s, ...) dengan batas atas senilai lima menit. Jeda waktu ini akan diatur ulang setelah sukses berjalan selama 10 menit. Sesuai dengan diskusi pada dokumen Pod, setelah masuk ke suatu node, sebuah Pod tidak akan pindah ke node lain.

Umur Pod

Secara umum, Pod tidak hilang sampai ada yang menghapusnya. Ini mungkin dihapus oleh orang atau pengontrol. Satu pengecualian untuk aturan ini adalah Pod dengan phase bernilai Succeeded atau Failed untuk waktu beberapa lama yang akan berakhir dan secara otomatis akan dihapus. (diatur dalam terminated-pod-gc-threshold pada master)

Tiga tipe pengontrol yang tersedia yaitu:

• Menggunakan sebuah Job untuk Pod yang diharapkan akan berakhir, sebagai contoh, penghitungan dalam jumlah banyak. Jobs hanyak cocok untuk Pod dengan restartPolicy yang bernilai OnFailure atau Never.

• Menggunakan sebuah ReplicationController, ReplicaSet, atau Deployment untuk Pod yang tidak diharapkan untuk berakhir, sebagai contoh, web servers. ReplicationControllers hanya cocok digunakan pada Pod dengan restartPolicy yang bernilai Always.

• Menggunakan sebuah DaemonSet untuk Pod yang akan berjalan hanya satu untuk setiap mesin, karena menyediakan servis yang spesifik untuk suatu mesin.

Ketiga tipe pengontrol ini memiliki sebuah PodTemplate. Direkomdasikan untuk membuat pengontrol yang sesuai dan membiarkan ini membuat Pod, daripada membuat Pod sendiri secara langsung. Karena Pod itu sendiri tidak tahan terhadap gagalnya suatu mesin, namun pengontrol tahan.

Jika node mati atau sambungannya terputus dari klaster, Kubernetes mengatur phase dari semua Pod pada node yang mati untuk menjadi Failed.

Contoh

Contoh Liveness Probe tingkat lanjut

Liveness probe dieksekusi oleh kubelet, jadi semua permintaan akan dilakukan di dalam namespace jaringan kubelet.

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - args:
    - /server
    image: k8s.gcr.io/liveness
    livenessProbe:
      httpGet:
        # ketika "host" tidak ditentukan, "PodIP" akan digunakan
        # host: my-host
        # ketika "scheme" tidak ditentukan, _scheme_ "HTTP" akan digunakan. Hanya "HTTP" and "HTTPS" yang diperbolehkan
        # scheme: HTTPS
        path: /healthz
        port: 8080
        httpHeaders:
        - name: X-Custom-Header
          value: Awesome
      initialDelaySeconds: 15
      timeoutSeconds: 1
    name: liveness

Contoh State

• Pod sedang berjalan dan memiliki sebuah kontainer. Kontainer berhenti dengan sukses.

  • Mencatat event penyelesaian.
  • Jika nilai restartPolicy adalah:
    • Always: Jalankan ulang kontainer; nilai phase Pod akan tetap Running.
    • OnFailure: nilai phase Pod akan berubah menjadi Succeeded.
    • Never: nilai phase Pod akan berubah menjadi Succeeded.

• Pod sedang berjalan dan memiliki sebuah kontainer. Kontainer berhenti dengan kegagalan.

  • Mencatat event kegagalan.
  • Jika nilai restartPolicy adalah:
    • Always: Jalankan ulang kontainer, nilai phase Pod akan tetap Running.
    • OnFailure: Jalankan ulang kontainer, nilai phase Pod akan tetap Running.
    • Never: nilai phase Pod akan menjadi Failed.

• Pod sedang berjalan dan memiliki dua kontainer. Kontainer pertama berhenti dengan kegagalan.

  • Mencatat event kegagalan.
  • Jika nilai restartPolicy adalah:
    • Always: Jalankan ulang kontainer, nilai phase Pod akan tetap Running.
    • OnFailure: Jalankan ulang kontainer, nilai phase Pod akan tetap Running.
    • Never: Tidak akan menjalankan ulang kontainer, nilai phase Pod akan tetap Running.
  • Jika kontainer pertama tidak berjalan dan kontainer kedua berhenti:
    • Mencatat event kegagalan.
    • Jika nilai restartPolicy adalah:
      • Always: Jalankan ulang kontainer, nilai phase Pod akan tetap Running.
      • OnFailure: Jalankan ulang kontainer, nilai phase Pod akan tetap Running.
      • Never: nilai phase Pod akan menjadi Failed.

• Pod sedang berjalan dan memiliki satu kontainer. Kontainer berhenti karena kehabisan memory.

  • Kontainer diberhentikan dengan kegagalan.
  • Mencatat kejadian kehabisan memory (OOM)
  • Jika nilai restartPolicy adalah:
    • Always: Jalankan ulang kontainer, nilai phase Pod akan tetap Running.
    • OnFailure: Jalankan ulang kontainer, nilai phase Pod akan tetap Running.
    • Never: Mencatat kejadian kegagalan, nilai phase Pod akan menjadi Failed.

• Pod sedang berjalan dan sebuah disk mati.

  • Menghentikan semua kontainer.
  • Mencatat kejadian yang sesuai.
  • Nilai phase Pod menjadi Failed.
  • Jika berjalan menggunakan pengontrol, maka Pod akan dibuat ulang di tempat lain.

• Pod sedang berjalan, dan node mengalami segmented out.

  • Node pengontrol menunggu sampai suatu batas waktu.
  • Node pengontrol mengisi nilai phase Pod menjadi Failed.
  • Jika berjalan menggunakan pengontrol, maka Pod akan dibuat ulang di tempat lain.

Selanjutnya

• Dapatkan pengalaman langsung mengenai penambahan handlers pada kontainer lifecycle events.

• Dapatkan pengalaman langsung mengenai pengaturan liveness dan readiness probes.

• Pelajari lebih lanjut mengenai lifecycle hooks pada kontainer.

4.1.4 - Init Container

Halaman ini menyediakan ikhtisar untuk Init Container, yaitu Container khusus yang dijalankan sebelum Container aplikasi dan berisi skrip peralatan atau setup yang tidak tersedia di dalam image dari Container aplikasi.

Fitur ini telah keluar dari trek Beta sejak versi 1.6. Init Container dapat dispesifikasikan di dalam PodSpec bersama dengan array containers aplikasi. Nilai anotasi beta akan tetap diperhitungkan dan akan menimpa nilai pada PodSpec, tetapi telah ditandai sebagai kedaluarsa pada versi 1.6 dan 1.7. Pada versi 1.8, anotasi beta tidak didukung lagi dan harus diganti menjadi nilai pada PodSpec.

Memahami Init Container

Sebuah Pod dapat memiliki beberapa Container yang berjalan di dalamnya, dan dapat juga memiliki satu atau lebih Init Container, yang akan berjalan sebelum Container aplikasi dijalankan.

Init Container sama saja seperti Container biasa, kecuali:

• Mereka selalu berjalan hingga selesai.
• Setiap Init Container harus selesai secara sukses sebelum Init Container berikutnya dijalankan.

Jika sebuah Init Container tidak selesai secara sukses untuk sebuah Pod, Kubernetes akan mengulang kembali Pod tersebut secara terus menerus hingga Init Container selesai secara sukses. Tetapi, jika Pod tersebut memiliki nilai restartPolicy berupa Never, Pod tersebut tidak akan diulang kembali.

Untuk menspesifikasikan sebuah Container sebagai Init Container, tambahkan kolom initContainers pada PodSpec sebagai sebuah array JSON yang berisi objek dengan tipe Container, berdampingan dengan array containers aplikasi. Status-status dari Init Container dikembalikan di kolom .status.initContainerStatuses sebagai sebuah array dari status-status Container (mirip seperti kolom status.containerStatuses)

Perbedaan dengan Container biasa

Init Container mendukung semua kolom dan fitur dari Container aplikasi, termasuk konfigurasi limit sumber daya, volume, dan keamanan. Tetapi, request dan limit sumber daya dari sebuah Init Container ditangani dengan cara yang sedikit berbeda, yang didokumentasikan di bagian Sumber Daya di bawah. Juga, Init Container tidak mendukung readiness probe karena mereka harus berjalan hingga selesai sebelum Pod dapat siap.

Jika beberapa Init Container dispesifikasikan untuk sebuah Pod, Container-container tersebut akan dijalankan satu per satu secara berurutan. Setiap Init Container harus selesai secara sukses sebelum yang berikutnya dapat berjalan. Saat semua Init Container telah berjalan hingga selesai, Kubernetes akan menginisialisasi Pod dan menjalankan Container aplikasi seperti biasa.

Apa kegunaan Init Container?

Karena Init Container memiliki image yang berbeda dengan Container aplikasi, mereka memiliki beberapa kelebihan untuk kode yang berhubungan dengan dimulainya Init Container:

• Mereka dapat berisi dan menjalankan skrip peralatan yang tidak diinginkan untuk berada di dalam image Container aplikasi karena alasan keamanan.
• Mereka dapat berisi skrip peralatan atau setup yang tidak tersedia di dalam image aplikasi. Misalnya, kita tidak perlu membuat image dengan instruksi FROM dari image lainnya hanya untuk menggunakan peralatan seperti sed, awk, python, atau dig pada saat setup.
• Peran builder atau deployer dari image dapat bekerja secara independen tanpa harus digabung untuk membuat satu image aplikasi.
• Mereka menggunakan namespace Linux, sehingga mereka dapat memiliki sudut pandang filesystem yang berbeda dengan Container aplikasi. Oleh karenanya, mereka dapat diberikan akses terhadap Secret yang tidak boleh diakses oleh Container aplikasi.
• Mereka berjalan hingga selesai sebelum Container aplikasi manapun dimulai, sedangkan Container aplikasi dijalankan secara paralel, sehingga Init Container menyediakan cara yang mudah untuk menunda dijalankannya Container aplikasi hingga ketentuan-ketentuan yang diinginkan dipenuhi.

Contoh-contoh

Berikut beberapa contoh kasus penggunaan Init Container:

• Menunggu sebuah Service untuk dibuat dengan perintah shell seperti:

  for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1
  

• Mendaftarkan suatu Pod ke sebuah peladen terpisah dari downward API dengan perintah seperti:

  `curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$(<POD_NAME>)&ip=$(<POD_IP>)'`
  

• Menunggu beberapa waktu sebelum menjalankan Container aplikasi dengan perintah seperti sleep 60.

• Mengklon sebuah git repository ke dalam sebuah volume.

• Menaruh nilai-nilai tertentu ke dalam sebuah file konfigurasi dan menjalankan peralatan template untuk membuat file konfigurasi secara dinamis untuk Container aplikasi utama. Misalnya, untuk menaruh nilai POD_IP ke dalam sebuah konfigurasi dan membuat konfigurasi aplikasi utama menggunakan Jinja.

Contoh-contoh penggunaan yang lebih detail dapat dilihat pada dokumentasi StatefulSet dan petunjuk Produksi Pod.

Menggunakan Init Container

File YAML untuk Kubernetes 1.5 berikut menguraikan sebuah Pod sederhana yang memiliki dua buah Init Container. Pod pertama menunggu myservice dan yang kedua menunggu mydb. Saat kedua Init Container tersebut sudah selesai, Podnya akan dijalankan.

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
  annotations:
    pod.beta.kubernetes.io/init-containers: '[
        {
            "name": "init-myservice",
            "image": "busybox:1.28",
            "command": ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
        },
        {
            "name": "init-mydb",
            "image": "busybox:1.28",
            "command": ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]
        }
    ]'
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']

Ada sintaksis baru pada Kubernetes 1.6, walaupun sintaksis anotasi yang lama tetap akan bekerja untuk versi 1.6 dan 1.7. Sintaksis yang baru harus digunakan untuk versi 1.8 ke atas. Deklarasi Init Container dipindahkan ke dalam spec:

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
  - name: init-mydb
    image: busybox:1.28
    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

Sintaksis versi 1.5 tetap akan bekerja pada versi 1.6 dan 1.7, tetapi kami menyarankan untuk menggunakan sintaksis versi 1.6. Pada Kubernetes 1.6, Init Container dijadikan sebagai sebuah kolom di dalam API Kubernetes. Anotasi beta tetap akan diperhitungkan pada versi 1.6 dan 1.7, tetapi tidak didukung lagi pada versi 1.8 ke atas.

File YAML di bawah menguraikan Service mydb dan myservice.

apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
---
apiVersion: v1
kind: Service
metadata:
  name: mydb
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9377

Pod ini dapat dijalankan dan di-debug dengan menggunakan perintah berikut:

kubectl apply -f myapp.yaml

pod/myapp-pod created

kubectl get -f myapp.yaml

NAME        READY     STATUS     RESTARTS   AGE
myapp-pod   0/1       Init:0/2   0          6m

kubectl describe -f myapp.yaml

Name:          myapp-pod
Namespace:     default
[...]
Labels:        app=myapp
Status:        Pending
[...]
Init Containers:
  init-myservice:
[...]
    State:         Running
[...]
  init-mydb:
[...]
    State:         Waiting
      Reason:      PodInitializing
    Ready:         False
[...]
Containers:
  myapp-container:
[...]
    State:         Waiting
      Reason:      PodInitializing
    Ready:         False
[...]
Events:
  FirstSeen    LastSeen    Count    From                      SubObjectPath                           Type          Reason        Message
  ---------    --------    -----    ----                      -------------                           --------      ------        -------
  16s          16s         1        {default-scheduler }                                              Normal        Scheduled     Successfully assigned myapp-pod to 172.17.4.201
  16s          16s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Pulling       pulling image "busybox"
  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Pulled        Successfully pulled image "busybox"
  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Created       Created container with docker id 5ced34a04634; Security:[seccomp=unconfined]
  13s          13s         1        {kubelet 172.17.4.201}    spec.initContainers{init-myservice}     Normal        Started       Started container with docker id 5ced34a04634

kubectl logs myapp-pod -c init-myservice # Memeriksa Init Container pertama
kubectl logs myapp-pod -c init-mydb      # Memeriksa Init Container kedua

Saat kita menjalankan Service mydb dan myservice, kita dapat melihat Init Container telah selesai dan myapp-pod pun dibuat:

kubectl apply -f services.yaml

service/myservice created
service/mydb created

kubectl get -f myapp.yaml
NAME        READY     STATUS    RESTARTS   AGE
myapp-pod   1/1       Running   0          9m

Contoh ini sangat sederhana, tetapi dapat memberikan sedikit petunjuk bagi kamu untuk membuat Init Container sendiri.

Perilaku mendetail

Saat dimulainya sebuah Pod, Init Container dijalankan secara berurutan, setelah jaringan dan volume telah diinisialisasi. Setiap Init Container harus selesai dan keluar secara berhasil sebelum yang berikutnya dijalankan. Jika ada Init Container yang gagal dijalankan atau keluar secara gagal, dia akan diulang kembali sesuai dengan restartPolicy yang dimiliki Pod. Tetapi, jika restartPolicy Pod disetel dengan nilai Always, Init Container akan menggunakan strategi RestartPolicy OnFailure.

Sebuah Pod tidak dapat masuk ke status Ready hingga semua Init Container berhasil selesai. Port di sebuah Init Container tidak diagregasikan di dalam sebuah Service. Sebuah Pod yang sedang diinisalisasikan akan masuk ke dalam status Pending, tetapi akan memiliki kondisi Initialized yang disetel menjadi true.

Jika sebuah Pod diulang kembali, semua Init Container harus dijalankan kembali.

Perubahan pada spesifikasi Init Container dibatasi hanya pada kolom image pada Init Container. Mengganti kolom image sebuah Init Container sama dengan mengulang kembali Pod tersebut.

Karena Init Container dapat diulang kembali, dicoba ulang, atau dijalankan ulang, Init Container sebaiknya bersifat idempotent. Khususnya, kode yang menulis ke dalam file pada EmptyDir sebaiknya dipersiapkan untuk menangani kemungkinan jika file keluaran yang diharapkan sudah ada di dalam EmptyDir tersebut.

Init Container memiliki semua kolom yang dimiliki oleh Container aplikasi. Tetapi, Kubernetes melarang penggunaan readinessProbe karena Init Container tidak dapat mendefinisikan/menggunakan readiness probe setelah selesai/keluar secara berhasil. Hal ini dipaksakan saat proses validasi.

Gunakan activeDeadlineSeconds pada Pod dan livenessProbe pada Container untuk mencegah Init Container gagal terus menerus. Nilai activeDeadlineSeconds berlaku juga terhadap Init Container.

Nama setiap Container aplikasi dan Init Container pada sebuah Pod haruslah unik; Kesalahan validasi akan terjadi jika ada Container atau Init Container yang memiliki nama yang sama.

Sumber Daya

Karena eksekusi Init Container yang berurutan, aturan-aturan untuk sumber daya berlaku sebagai berikut:

• Yang tertinggi antara request atau limit sumber daya yang didefinisikan pada semua Init Container adalah request/limit inisialisasi yang berlaku.
• request/limit sumber daya Pod yang berlaku adalah yang paling besar diantara:
  • Jumah request/limit semua Container aplikasi untuk suatu sumber daya.
  • request/limit inisialisasi yang berlaku untuk suatu sumber daya.
• Penjadwalan dilakukan berdasarkan request/limit (Pod) yang berlaku, yang berarti bahwa Init Container dapat mengambil sumber daya inisialisasi yang tidak digunakan selama umur Pod tersebut.
• Tingkat QoS yang berlaku milik Pod adalah sama dengan tingkat QoS untuk Init Container dan Container aplikasi.

ResourceQuota dan limitedResources diberlakukan berdasarkan request dan limit Pod yang berlaku.

Cgroup pada tingat Pod didasarkan pada request dan limit Pod yang berlaku, sama dengan scheduler.

Alasan Pod diulang kembali

Pod dapat diulang kembali, yang berakibat pada diulangnya eksekusi Init Container, diakibatkan oleh beberapa alasan berikut:

• Seorang pengguna memperbarui PodSpec, mengakibatkan image Init Container berubah. Perubahan apapun pada image Init Container akan mengulang kembali Pod tersebut. Perubahan pada image Container aplikasi hanya mengulang kembali Container aplikasi yang bersangkutan.
• Infrastruktur Container Pod diulang kembali. Hal ini jarang terjadi, dan hanya dapat dilakukan oleh seseorang yang memiliki akses root pada node yang bersangkutan.
• Semua Container di dalam Pod diterminasi, dengan nilai restartPolicy yang disetel sebagai Always, memaksa pengulangan kembali, dan catatan selesainya Init Container telah hilang karena garbage collection.

Dukungan dan kompatibilitas

Sebuah klaster dengan versi Apiserver 1.6.0 ke atas mendukung Init Container melalui kolom .spec.initContainers. Versi-versi sebelumnya mendukung Init Container melalui anotasi alpha atau beta. Kolom .spec.initContainers juga diduplikasikan dalam bentuk anotasi alpha dan beta agar Kubelet versi 1.3.0 ke atas dapat menjalankan Init Container, dan agar Apiserver versi 1.6 dapat dengan aman dikembalikan ke versi 1.5.x tanpa kehilangan fungsionalitas Pod-pod yang telah dibuat sebelumnya.

Pada Apiserver dan Kubelet versi 1.8.0 ke atas, dukungan untuk anotasi alpha dan beta telah dihapus, sehingga dibutuhkan konversi (manual) dari anotasi yang telah kedaluwarsa tersebut ke dalam bentuk kolom .spec.initContainers.

Selanjutnya

• Membuat Pod yang memiliki Init Container

4.1.5 - Batasan Persebaran Topologi Pod

Kamu dapat menggunakan batasan perseberan topologi (topology spread constraints) untuk mengatur bagaimana Pod akan disebarkan pada klaster yang ditetapkan sebagai failure-domains, seperti wilayah, zona, Node dan domain topologi yang ditentukan oleh pengguna. Ini akan membantu untuk mencapai ketersediaan yang tinggi dan juga penggunaan sumber daya yang efisien.

Persyaratan

Mengaktifkan Gerbang Fitur

Gerbang fitur (feature gate) EvenPodsSpread harus diaktifkan untuk API Server dan penjadwal (_scheduler_).

Label Node

Batasan persebaran topologi bergantung dengan label pada Node untuk menentukan domain topologi yang memenuhi untuk semua Node. Misalnya saja, sebuah Node bisa memiliki label sebagai berikut: node=node1,zone=us-east-1a,region=us-east-1

Misalkan kamu memiliki klaster dengan 4 Node dengan label sebagai berikut:

NAME    STATUS   ROLES    AGE     VERSION   LABELS
node1   Ready    <none>   4m26s   v1.16.0   node=node1,zone=zoneA
node2   Ready    <none>   3m58s   v1.16.0   node=node2,zone=zoneA
node3   Ready    <none>   3m17s   v1.16.0   node=node3,zone=zoneB
node4   Ready    <none>   2m43s   v1.16.0   node=node4,zone=zoneB

Maka klaster tersebut secara logika akan dilihat sebagai berikut:

+---------------+---------------+
|     zoneA     |     zoneB     |
+-------+-------+-------+-------+
| node1 | node2 | node3 | node4 |
+-------+-------+-------+-------+

Tanpa harus memberi label secara manual, kamu dapat menggunakan [label ternama] (/docs/reference/kubernetes-api/labels-annotations-taints/) yang terbuat dan terkumpulkan secara otomatis pada kebanyakan klaster.

Batasan Persebaran untuk Pod

API

Field pod.spec.topologySpreadConstraints diperkenalkan pada versi 1.16 sebagai berikut:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  topologySpreadConstraints:
  - maxSkew: <integer>
    topologyKey: <string>
    whenUnsatisfiable: <string>
    labelSelector: <object>

Kamu dapat mendefinisikan satu atau lebih topologySpreadConstraint untuk menginstruksikan kube-scheduler mengenai cara peletakan tiap Pod baru dengan menggunakan kondisi Pod yang sudah ada dalam klaster kamu. Field yang ada adalah:

• maxSkew menentukan batasan yang menandakan Pod tidak tersebar secara merata. Ini merupakan nilai maksimal dari selisih jumlah Pod yang sama untuk setiap 2 domain topologi yang sama. Nilai ini harus lebih dari 0.
• topologyKey adalah kunci dari label Node. Jika terdapat dua Node memiliki label dengan kunci ini dan memiliki nilai yang identik untuk label tersebut, maka penjadwal akan menganggap kedua Noode dalam topologi yang sama. Penjadwal akan mencoba untuk menyeimbangkan jumlah Pod dalam setiap domain topologi.
• whenUnsatisfiable mengindikasikan cara menangani Pod yang tidak memenuhi batasan persebaran:
  • DoNotSchedule (default) memberitahukan penjadwal untuk tidak menjadwalkan Pod tersebut.
  • ScheduleAnyway memberitahukan penjadwal untuk tetap menjadwalkan Pod namun tetap menjaga ketidakseimbangan Node sekecil mungkin.
• labelSelector digunakan untuk mencari Pod yang sesuai. Pod dengan label yang sama dengan ini akan dihitung untuk menentukan jumlah Pod dalam domain topologi yang sesuai. Silakan baca Label dan Selector untuk lebih detailnya.

Kamu juga bisa membaca lebih detail mengenai field ini dengan menjalankan perintah kubectl explain Pod.spec.topologySpreadConstraints.

Contoh: Satu TopologySpreadConstraint

Misalkan kamu memiliki klaster dengan 4 Node dimana 3 Pod berlabel foo:bar terdapat pada node1, node2 dan node3 (P merepresentasikan Pod):

+---------------+---------------+
|     zoneA     |     zoneB     |
+-------+-------+-------+-------+
| node1 | node2 | node3 | node4 |
+-------+-------+-------+-------+
|   P   |   P   |   P   |       |
+-------+-------+-------+-------+

Jika kita ingin Pod baru akan disebar secara merata berdasarkan Pod yang telah ada pada semua zona, maka spec bernilai sebagai berikut:

pods/topology-spread-constraints/one-constraint.yaml

kind: Pod
apiVersion: v1
metadata:
  name: mypod
  labels:
    foo: bar
spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  containers:
  - name: pause
    image: k8s.gcr.io/pause:3.1

topologyKey: zone berarti persebaran merata hanya akan digunakan pada Node dengan pasangan label "zone: ". whenUnsatisfiable: DoNotSchedule memberitahukan penjadwal untuk membiarkan tetap ditunda jika Pod yang baru tidak memenuhi batasan yang diterapkan.

Jika penjadwal menempatkan Pod baru pada "zoneA", persebaran Pod akan menjadi [3, 1], menjadikan ketidakseimbangan menjadi bernilai 2 (3 - 1), yang mana akan melanggar batasan maxSkew: 1. Dalam contoh ini, Pod baru hanya dapat ditempatkan pada "zoneB":

+---------------+---------------+      +---------------+---------------+
|     zoneA     |     zoneB     |      |     zoneA     |     zoneB     |
+-------+-------+-------+-------+      +-------+-------+-------+-------+
| node1 | node2 | node3 | node4 |  OR  | node1 | node2 | node3 | node4 |
+-------+-------+-------+-------+      +-------+-------+-------+-------+
|   P   |   P   |   P   |   P   |      |   P   |   P   |  P P  |       |
+-------+-------+-------+-------+      +-------+-------+-------+-------+

Kamu dapat mengatur spesifikasi Pod untuk memenuhi beberapa persyaratan berikut:

• Ubah nilai maxSkew menjadi lebih besar, misal "2", sehingga Pod baru dapat ditempatkan pada "zoneA".
• Ubah nilai topologyKey menjadi "node" agar Pod disebarkan secara merata pada semua Node, bukan zona. Pada contoh di atas, jika maxSkew tetap bernilai "1", maka Pod baru hanya akan ditempatkan pada "node4".
• Ubah nilai whenUnsatisfiable: DoNotSchedule menjadi whenUnsatisfiable: ScheduleAnyway untuk menjamin agar semua Pod baru akan tetap dijadwalkan (misalkan saja API penjadwalan lain tetap terpenuhi). Namun, ini lebih suka ditempatkan pada domain topologi yang memiliki lebih sedikit Pod yang sesuai. (Harap diperhatikan bahwa preferensi ini digabungkan bersama dengan prioritas penjadwalan internal yang lain, seperti rasio penggunaan sumber daya, dan lain sebagainya.)

Contoh: Beberapa TopologySpreadConstraint

Ini dibuat berdasarkan contoh sebelumnya. Misalkan kamu memiliki klaster dengan 4 Node dengan 3 Pod berlabel foo:bar yang ditempatkan pada node1, node2 dan node3. (P merepresentasikan Pod):

+---------------+---------------+
|     zoneA     |     zoneB     |
+-------+-------+-------+-------+
| node1 | node2 | node3 | node4 |
+-------+-------+-------+-------+
|   P   |   P   |   P   |       |
+-------+-------+-------+-------+

Kamu dapat menggunakan 2 TopologySpreadConstraint untuk mengatur persebaran Pod pada zona dan Node:

pods/topology-spread-constraints/two-constraints.yaml

kind: Pod
apiVersion: v1
metadata:
  name: mypod
  labels:
    foo: bar
spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  - maxSkew: 1
    topologyKey: node
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        foo: bar
  containers:
  - name: pause
    image: k8s.gcr.io/pause:3.1

Dalam contoh ini, untuk memenuhi batasan pertama, Pod yang baru hanya akan ditempatkan pada "zoneB", sedangkan untuk batasan kedua, Pod yang baru hanya akan ditempatkan pada "node4". Maka hasil dari 2 batasan ini akan digunakan (AND), sehingga opsi untuk menempatkan Pod hanya pada "node4".

Beberapa batasan dapat berujung pada konflik. Misalnya saja kamu memiliki klaster dengan 3 Node pada 2 zona berbeda:

+---------------+-------+
|     zoneA     | zoneB |
+-------+-------+-------+
| node1 | node2 | node3 |
+-------+-------+-------+
|  P P  |   P   |  P P  |
+-------+-------+-------+

Jika kamu menerapkan "two-constraints.yaml" pada klaster ini, kamu akan mendapatkan "mypod" tetap dalam kondisi Pending. Ini dikarenakan oleh: untuk memenuhi batasan pertama, "mypod" hanya dapat ditempatkan pada "zoneB", sedangkan untuk batasan kedua, "mypod" hanya dapat ditempatkan pada "node2". Tidak ada hasil penggabungan dari "zoneB" dan "node2".

Untuk mengatasi situasi ini, kamu bisa menambahkan nilai maxSkew atau mengubah salah satu dari batasan untuk menggunakan whenUnsatisfiable: ScheduleAnyway.

Konvensi

Ada beberapa konvensi implisit yang perlu diperhatikan di sini:

• Hanya Pod dengan Namespace yang sama dengan Pod baru yang bisa menjadi kandidat yang cocok.

• Node tanpa memiliki topologySpreadConstraints[*].topologyKey akan dilewatkan. Ini berarti:

  1. Pod yang ditempatkan pada Node tersebut tidak berpengaruh pada perhitungan maxSkew. Dalam contoh di atas, misalkan "node1" tidak memiliki label "zone", maka kedua Pod tidak diperhitungkan dan menyebabkan Pod yang baru akan dijadwalkan masuk ke "zoneA".
  2. Pod yang baru tidak memiliki kesempatan untuk dijadwalkan ke Node tersebut, pada contoh di atas, misalkan terdapat "node5" dengan label {zone-typo: zoneC} bergabung dalam klaster, Node ini akan dilewatkan karena tidak memiliki label dengan kunci "zone".

• Harap diperhatikan mengenai hal yang terjadi jika nilai topologySpreadConstraints[*].labelSelector pada Pod yang baru tidak sesuai dengan labelnya. Pada contoh di atas, jika kita menghapus label pada Pod yang baru, maka Pod akan tetap ditempatkan pada "zoneB" karena batasan yang ada masih terpenuhi. Namun, setelah ditempatkan, nilai ketidakseimbangan pada klaster masih tetap tidak berubah, zoneA tetap memiliki 2 Pod dengan label {foo:bar} dan zoneB memiliki 1 Pod dengan label {foo:bar}. Jadi jika ini tidak yang kamu harapkan, kami menyarankan nilai dari topologySpreadConstraints[*].labelSelector disamakan dengan labelnya.

• Jika Pod yang baru memiliki spec.nodeSelector atau spec.affinity.nodeAffinity, Node yang tidak sesuai dengan nilai tersebut akan dilewatkan.

  Misalkan kamu memiliki klaster dengan 5 Node dari zoneA sampai zoneC:

  +---------------+---------------+-------+
  |     zoneA     |     zoneB     | zoneC |
  +-------+-------+-------+-------+-------+
  | node1 | node2 | node3 | node4 | node5 |
  +-------+-------+-------+-------+-------+
  |   P   |   P   |   P   |       |       |
  +-------+-------+-------+-------+-------+
  

  dan kamu mengetahui bahwa "zoneC" harus tidak diperhitungkan. Dalam kasus ini, kamu dapat membuat berkas yaml seperti di bawah, jadi "mypod" akan ditempatkan pada "zoneB", bukan "zoneC". Demikian juga spec.nodeSelector akan digunakan.

  pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml

  kind: Pod
  apiVersion: v1
  metadata:
    name: mypod
    labels:
      foo: bar
  spec:
    topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: zone
      whenUnsatisfiable: DoNotSchedule
      labelSelector:
        matchLabels:
          foo: bar
    affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: zone
              operator: NotIn
              values:
              - zoneC
    containers:
    - name: pause
      image: k8s.gcr.io/pause:3.1

Batasan default pada tingkat klaster

Ini memungkinkan untuk mengatur batasan persebaran topologi bawaan untuk klaster. Batasan persebaran topologi bawaan akan digunakan pada Pod jika dan hanya jika:

• Hal ini tidak mendefinisikan batasan apapun pada .spec.topologySpreadConstraints.
• Hal ini milik sebuah Service, ReplicationController, ReplicaSet atau StatefulSet.

Batasan bawaan akan diatur sebagai bagian dari argumen pada plugin PodTopologySpread di dalam sebuah profil penjadwalan. Batasan dispesifikasikan dengan API yang sama dengan di atas, kecuali bagian labelSelector harus kosong. selector akan dihitung dari Service, ReplicationController, ReplicaSet atau StatefulSet yang dimiliki oleh Pod tersebut.

Sebuah contoh konfigurasi sebagai berikut:

apiVersion: kubescheduler.config.k8s.io/v1alpha2
kind: KubeSchedulerConfiguration

profiles:
  - pluginConfig:
      - name: PodTopologySpread
        args:
          defaultConstraints:
            - maxSkew: 1
              topologyKey: topology.kubernetes.io/zone
              whenUnsatisfiable: ScheduleAnyway

Catatan: Nilai yang dihasilkan oleh batasan penjadwalan bawaan mungkin akan konflik dengan nilai yang dihasilkan oleh DefaultPodTopologySpread plugin. Direkomendasikan untuk kamu menonaktifkan plugin ini dalam profil penjadwalan ketika menggunakan batasan default untuk PodTopologySpread.

Perbandingan dengan PodAffinity/PodAntiAffinity

Di Kubernetes, arahan yang terkait dengan "Afinitas" mengontrol bagaimana Pod dijadwalkan - lebih terkumpul atau lebih tersebar.

• Untuk PodAffinity, kamu dapat mencoba mengumpulkan beberapa Pod ke dalam suatu domain topologi yang memenuhi syarat.
• Untuk PodAntiAffinity, hanya satu Pod yang dalam dijadwalkan pada sebuah domain topologi.

Fitur "EvenPodsSpread" memberikan opsi fleksibilas untuk mendistribusikan Pod secara merata pada domain topologi yang berbeda, untuk meraih ketersediaan yang tinggi atau menghemat biaya. Ini juga dapat membantu saat perbaruan bergilir dan menaikan jumlah replika dengan lancar. Silakan baca motivasi untuk lebih detail.

Limitasi yang diketahui

Pada versi 1.18, dimana fitur ini masih Beta, beberapa limitasi yang sudah diketahui:

• Pengurangan jumlah Deployment akan membuat ketidakseimbangan pada persebaran Pod.
• Pod yang cocok pada tainted Node akan dihargai. Lihat Issue 80921

4.1.6 - Pod Preset

Halaman ini menyajikan gambaran umum tentang PodPreset, yang merupakan objek untuk memasukkan informasi tertentu ke dalam Pod pada saat waktu penciptaan. Informasi dapat berupa secret, volume, volume mount, dan variabel environment.

Memahami Pod Preset

Sebuah Pod Preset adalah sebuah resource API untuk memasukkan kebutuhan runtime tambahan ke dalam sebuah Pod pada saat waktu penciptaan. Kamu akan menggunakan label selector untuk menunjuk Pod dimana Pod Preset diterapkan.

Menggunakan sebuah Pod Preset memungkinkan pembuat templat pod untuk tidak menyediakan secara eksplisit semua informasi untuk setiap pod. Dengan demikian, pembuat templat pod yang mengkonsumsi sebuah service spesifik tidak perlu tahu semua detail-detail tentang service tersebut.

Untuk informasi lebih lanjut mengenai latar belakang lihat proposal desain untuk PodPreset.

Bagaimana Cara Kerja Pod Preset

Kubernetes menyediakan sebuah admission controller (PodPreset) dimana, ketika diaktifkan, PodPreset diterapkan kepada permintaan penciptaan Pod yang akan datang. Ketika sebuah penciptaan Pod terjadi, sistem melakukan hal-hal berikut:

1. Mengambil semua PodPreset yang tersedia untuk digunakan.
2. Cek jika label selector dari salah satu PodPreset cocok dengan label pada pod yang sedang diciptakan.
3. Usaha untuk menggabungkan berbagai resource didefinisikan oleh PodPreset ke dalam Pod yang sedang diciptakan.
4. Ketika terjadi galat, lempar sebuah event yang mendokumentasikan galat penggabungan dalam pod, dan membuat pod tanpa salah satu resource dari PodPreset.
5. Anotasikan hasil spesifikasi Pod yang telah dimodifikasi untuk menunjukkan bahwa Pod telah dimodifikasi oleh sebuah PodPreset. Anotasi berupa podpreset.admission.kubernetes.io/podpreset-<nama pod-preset>: "<versi resource>".

Tiap Pod akan bisa dipasangkan oleh nol atau lebih PodPreset; dan tiap PodPreset bisa diterapkan ke nol atau lebih Pod. Ketika sebuah PodPreset diterapkan ke satu atau lebih Pod, Kubernetes memodifikasi Pod Spec. Untuk perubahan terhadap Env,EnvFrom, dan VolumeMount, Kubernetes memodifikasi spesifikasi kontainer untuk semua kontainer di dalam Pod; Untuk perubahan terhadap Volume, Kubernetes memodifikasi Pod Spec.

Catatan: Sebuah Pod Preset mampu memodifikasi kolom .spec.containers pada sebuah Pod Spec jika sesuai. Tidak ada definisi resource dari Pod Preset yang akan diterapkan kepada kolom initContainer.

Menonaktifkan Pod Preset untuk sebuah Pod Spesifik

Mungkin akan ada keadaan dimana kamu menginginkan sebuah Pod tidak bisa diubah oleh sebuah mutasi PodPreset. Pada kasus ini, kamu bisa menambahkan sebuah anotasi pada Pod Spec dalam bentuk: podpreset.admission.kubernetes.io/exclude: "true".

Mengaktifkan Pod Preset

Dalam rangka untuk menggunakan Pod Preset di dalam klaster kamu, kamu harus memastikan hal berikut:

1. Kamu telah mengaktifkan tipe API settings.k8s.io/v1alpha1/podpreset. Sebagai contoh, ini bisa dilakukan dengan menambahkan settings.k8s.io/v1alpha1=true di dalam opsi --runtime-config untuk API server. Dalam minikube tambahkan argumen berikut --extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true saat menginisialisasi klaster.

2. Kamu telah mengaktifkan admission controller dari PodPreset. Salah satu cara untuk melakukannya adalah dengan menambahkan PodPreset di dalam nilai opsi --enable-admission-plugins yang dispesifikasikan untuk API server. Dalam minikube tambahkan argumen berikut

   --extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
   

   saat menginisialisasi klaster.

3. Kamu telah membuat objek PodPreset pada namespace yang kamu gunakan dengan cara mendefinisikan Pod Preset.

Selanjutnya

• Memasukkan data ke dalam sebuah Pod dengan PodPreset

4.1.7 - Disrupsi

Petunjuk ini ditujukan pada pemilik aplikasi yang meninginkan aplikasinya memiliki ketersediaan yang tinggi, sehingga butuh untuk mengerti jenis-jenis Disrupsi yang dapat terjadi pada Pod-pod.

Petunjuk ini juga ditujukan pada administrator klaster yang ingin melakukan berbagai tindakan otomasi pada klaster, seperti pembaruan dan autoscaling klaster.

Disrupsi yang Disengaja dan Tidak Disengaja

Pod-pod tidak akan terhapus sampai sesuatu (orang ataupun pengendali) menghancurkan mereka atau ada kesalahan perangkat keras maupun perangkat lunak yang tidak dapat dihindari.

Kita menyebut kasus-kasus yang tidak dapat dihindari sebagai disrupsi yang tidak disengaja terhadap aplikasi. Beberapa contohnya adalah sebagai berikut:

• Kesalahan perangkat keras pada mesin yang menjalankan Node
• Administrator klaster menghapus virtual machine secara tidak sengaja
• Kesalahan pada penyedia layanan cloud yang mengakibatkan terhapusnya virtual machine
• Sebuah kernel panic
• Node menghilang dari klaster karena partisi jaringan klaster
• Pod mengalami eviction karena Node kehabisan sumber daya

Dengan pengecualian pada kondisi kehabisan sumber daya, kondisi-kondisi tersebut pada umumnya diketahui oleh kebanyakan pengguna karena kondisi-kondisi tersebut tidak spesifik pada Kubernetes saja.

Kita menyebut kasus-kasus lainnya sebagai disrupsi yang disengaja. Hal ini termasuk tindakan yang dilakukan oleh pemilik aplikasi atau yang dilakukan oleh administrator klaster. Pemilik aplikasi umumnya melakukan hal-hal berikut:

• Menghapus Deployment atau pengendali yang mengatur Pod
• Memperbarui templat Pod yang menyebabkan pengulangan kembali/restart
• Menghapus Pod secara langsung

Administrator klaster umumnya melakukan hal-hal berikut:

• Melakukan drain terhadap Node untuk perbaikan atau pembaruan.
• Melakukan drain terhadap sebuah node dari klaster untuk memperkecil ukuran klaster (untuk lebih lanjutnya, pelajari Autoscaling klaster).
• Menghapus sebuah Pod dari node untuk memuat Pod lain ke node tersebut.

Tindakan-tindakan tersebut dapat dilakukan secara langsung oleh administrator klaster, atau oleh alat otomasi yang dijalankan oleh administrator klaster, atau oleh penyedia layanan Kubernetes kamu.

Tanyakan administrator klaster atau penyedia layanan cloud kamu, atau lihatlah dokumentasi penyedia layanan Kubernetes kamu untuk mengetahui bila ada sumber-sumber yang berpotensi mengakibatkan disrupsi yang disengaja yang ada pada klastermu. Jika tidak ada, kamu bisa melewatkan pembuatan PodDisruptionBudget

Perhatian: Tidak semua disrupsi yang disengaja dibatasi oleh Pod Disruption Budget. Contohnya, menghapus Deployment atau Pod dapat mengabaikan PodDisruptionBudget.

Mengatasi Disrupsi

Berikut beberapa cara untuk mengatasi disrupsi yang tidak disengaja:

• Pastikan Pod-pod kamu merinci permintaan sumber daya klaster yang dibutuhkan.
• Replikasikan aplikasimu jika membutuhkan ketersediaan yang tinggi. (Pelajari tentang menjalankan aplikasi stateless dan stateful).
• Untuk mencapai ketersediaan yang bahkan lebih tinggi lagi saat mereplikasikan aplikasi, sebarkanlah Pod-pod kamu di rak-rak pada data center (menggunakan anti-affinity) atau di seluruh zona (jika kamu menggunakan klaster pada beberapa zona).

Frekuensi disrupsi yang disengaja dapat berubah-ubah. Pada klaster Kubernetes yang dasar, tidak ada disrupsi yang disengaja sama sekali. Tetapi, administrator klaster atau penyedia layanan Kubernetes kamu mungkin saja menjalankan beberapa servis tambahan yang dapat mengakibatkan disrupsi yang disengaja. Misalnya, memperbarui perangkat lunak pada node yang dapat mengakibatkan disrupsi yang disengaja. Selain itu, beberapa implementasi autoscaling klaster (atau node) dapat mengakibatkan disrupsi yang disengaja untuk merapikan dan memadatkan node-node pada klaster. Administrator klaster atau penyedia layanan Kubernetes kamu perlu mendokumentasikan tingkatan disrupsi yang disengaja, jika ada disrupsi yang telah diperkirakan.

Kubernetes menawarkan fitur-fitur untuk membantu menjalankan aplikasi-aplikasi dengan ketersediaan tinggi bersamaan dengan seringnya disrupsi yang disengaja, fitur-fitur tersebut dinamai Disruption Budget.

Bagaimana cara kerja Disruption Budget

Pemilik aplikasi dapat membuat objek PodDisruptionBudget (PDB) untuk setiap aplikasi. Sebuah PDB membatasi jumlah Pod yang boleh mati secara bersamaan pada aplikasi yang direplikasi dikarenakan disrupsi yang disengaja. Misalnya, sebuah aplikasi yang bekerja secara quorum mau memastikan bahwa jumlah replika yang berjalan tidak jatuh ke bawah yang dibutuhkan untuk membentuk sebuah quorum. Contoh lainnya, sebuah front-end web mungkin perlu memastikan bahwa jumlah replika yang melayani trafik tidak pernah turun ke total persentase yang telah ditentukan.

Administrator klaster dan penyedia layanan Kubernetes sebaiknya menggunakan alat-alat yang menghormati PDB dengan cara berkomunikasi dengan Eviction API dari pada menghapus Pod atau Deployment secara langsung. Contohnya adalah perintah kubectl drain dan skrip pembaruan Kubernets-on-GCE (cluster/gce/upgrade.sh)

Saat seorang administrator klaster ingin melakukan drain terhadap sebuah node, ia akan menggunakan perintah kubectl drain. Alat tersebut mencoba untuk "mengusir" semua Pod di node tersebut. Permintaan untuk mengusir Pod tersebut mungkin ditolak untuk sementara, dan alat tersebut akan mencoba ulang permintaannya secara periodik hingga semua Pod dihapus, atau hingga batas waktu yang ditentukan telah dicapai.

Sebua PDB merinci jumlah replika yang dapat ditoleransi oleh sebuah aplikasi, relatif terhadap berapa banyak yang seharusnya dimiliki oleh aplikasi tersebut. Sebagai contoh, sebuah Deployment yang memiliki rincian .spec.replicas :5 diharapkan memiliki 5 Pod pada satu waktu. Jika PDB aplikasi tersebut mengizinkan ada 4 replika pada satu waktu, maka Eviction API akan mengizinkan disrupsi yag disengaja sebanyak satu, tapi tidak mengizinkan dua, pada satu waktu.

Sebuah kelompok Pod yang mewakili aplikasi dispesifikasikan menggunakan sebuah label selector yang sama dengan yang digunakan oleh pengatur aplikasi tersebut (Deployment, StatefulSet, dsb.)

Jumlah Pod yang "diharapkan" dihitung dari .spec.replicas dari pengendali Pod tersebut. Pengendali dari sebuah Pod dapat ditemukan di spesifikasi .metadata.ownerReferences objek Pod yang bersangkutan.

PDB tidak dapat mencegah disrupsi yang tidak disengaja, tapi disrupsi ini akan dihitung terhadap bujet PDB.

Pod yang dihapus atau tidak tersetia dikarenakan pembaruan bertahap juga dihitung terhadap bujet PDB, tetapi pengendali (seperti Deployment dan StatefulSet) tidak dibatasi oleh PDB ketika melakukan pembaruan bertahap; Penanganan kerusakan saat pembaruan aplikasi dikonfigurasikan pada spesifikasi pengendali. (Pelajari tentang memperbarui sebuah Deployment.)

Saat sebuah Pod diusir menggunakan eviction API, Pod tersebut akan dihapus secara graceful (lihat terminationGracePeriodSeconds pada PodSpec.))

Contoh PDB

Kita ambil contoh sebuah klaster dengan 3 node, node-1 hingga node-3. Klaster tersebut menjalankan beberapa aplikasi. Salah satu dari aplikasi tersebut awalnya memiliki 3 replika, yang akan kita namai Pod-a, Pod-b, dan Pod-c. Sebuah Pod lain yang tidak bersangkutan dan tidak memiliki PDB, dinamai Pod-x juga terlihat. Awalnya, Pod-pod tersebut berada pada node-node sebagai berikut:

3 Pod Pod-a hingga Pod-c adalah bagian dari sebuah Deployment, dan mereka secara kolektif memiliki sebuah PDB yang mengharuskan ada setidaknya 2 dari 3 Pod untuk tersedia sepanjang waktu.

Sebagai contoh, asumsikan administrator klaster ingin me-reboot ke dalam versi kernel baru untuk memperbaiki kesalahan di dalam kernel lama. Administator klaster pertama-tama mencoba untuk melakukan drain terhadap node-1 menggunakan perintah kubectl drain. Perintah tersebut mencoba untuk mengusir Pod-a dan Pod-x. Hal ini langsung berhasil. Kedua Pod tersebut masuk ke dalam kondisi terminating secara bersamaan. Hal ini mengubah kondisi klaster menjadi sebagai berikut:

Deployment tersebut melihat bahwa salah satu Pod berada dalam kondisi terminating, sehingga Deployment mencoba untuk membuat penggantinya, Pod-d. Sejak node-1 ditutup (karena perintah kubectl-drain), Pod-d masuk ke node lainnya. Sesuatu juga membuat Pod-y sebagai pengganti Pod-x

(Catatan: untuk sebuah StatefulSet, Pod-a, akan dinamai dengan Pod-1, harus diterminasi hingga selesai sebelum penggantinya, yang juga dinamai Pod-1 tetapi memiliki UID yang berbeda, akan dibuat. Selain hal ini, seluruh contoh ini juga berlaku untuk StatefulSet.)

Sekarang, klaster berada pada kondisi berikut:

Pada satu waktu, Pod-pod yang diusir pun selesai diterminasi, dan kondisi klaster menjadi seperti berikut:

Pada titik ini, jika seorang administrator klaster yang tidak sabar mencoba untuk melakukan drain terhadap node-2 atau node-3, perintah untuk melakukan drain terhadap node tersebut akan terhalang, karena hanya ada 2 Pod yang tersedia, dan PDB-nya membutuhkan setidaknya ada 2 Pod tersedia. Setelah beberapa waktu, Pod-d menjadi tersedia.

Kondisi klaster menjadi seperti berikut:

Sekarang, administrator klaster mencoba untuk melakukan drain terhadap node-2. Perintah drain tersebut akan mencoba mengusir Pod-pod tersebut secara berurutan (tidak bersamaan), misalnya Pod-b yang pertama dan diikuti dengan Pod-d. Perintah tersebut akan berhasil mengusir Pod-b. Tetapi, pada saat ia mencoba untuk mengusir Pod-d, hal tersebut akan ditolak karena hal tersebut akan mengakibatkan hanya satu Pod yang tersedia untuk Deployment yang bersangkutan.

Deployment tersebut membuat pengganti Pod-b yang dinamai Pod-e. Karena tidak ada sumber daya klaster yang cukup untuk mengalokasikan Pod-e, proses drain akan kembali terhalang. Klaster mungkin berada pada kondisi berikut:

Pada titik ini, administrator klaster mesti menambah sebuah node untuk klaster agar bisa melanjutkan pembaruan klaster.

Kamu dapat melihat bagaimana frekuensi disrupsi dapat berubah-ubah pada Kubernetes, tergantung pada:

• Berapa banyak replika yang dibutuhkan sebuah aplikasi
• Berapa lama waktu yang dibutuhkan untuk mematikan sebuah Pod secara graceful
• Berapa lama waktu yang dibutuhkan untuk memulai sebuah Pod
• Tipe pengendali
• Kapasitas sumber daya klaster

Memisahkan Peran Pemilik Klaster dan Pemilik Aplikasi

Seringkali akan bermanfaat untuk berpikir Administrator Klaster dan Pemilik Aplikasi sebagai peran yang terpisah dan dengan pengetahuan yang terbatas satu sama lainnya. Pemisahan ini dapat dimengerti dalam beberapa skenario berikut:

• Saat ada banyak tim aplikasi yang berbagi pakai sebuah klaster Kubernetes, dan ada pembagian peran yang spesifik
• Saat alat atau servis pihak ketiga digunakan untuk melakukan otomasi manajemen klaster.

PDB mendukung pemisahan peran ini dengan cara menyediakan antarmuka bagi peran-peran tersebut.

Jika kamu tidak memiliki pemisahan peran seperti ini pada organisasimu, kamu mungkin tidak membutuhkan PDB.

Bagaimana cara melakukan Tindakan Disruptif terhadap Klaster

Jika kamu adalah Administrator Klaster, maka kamu mesti melakukan tindakan disruptif pada setiap node di klastermu, seperti melakukan pembaruan perangkat lunak pada node, berikut beberapa opsinya:

• Menerima downtime pada saat pembaruan node
• Melakukan failover ke replika lengkap klaster lain.
  • Tanpa downtime, tetapi mungkin lebih mahal, baik ongkos duplikasi node-node dan tenaga yang dibutuhkan untuk melakukan failover.
• Membuat aplikasi yang toleran terhadap disrupsi, dan gunakan PDB.
  • Tanpa downtime.
  • Duplikasi sumber daya yang minimal.
  • Mengizinkan lebih banyak otomasi administrasi klaster.
  • Membuat aplikasi yang toleran terhadap disrupsi agak rumit, tetapi usaha yang dilakukan untuk menoleransi disrupsi yang disengaja kebanyakan beririsan dengan usaha untuk mendukung autoscaling dan menoleransi disrupsi yang tidak disengaja.

Selanjutnya

• Ikuti langkah-langkah untuk melindungi aplikasimu dengan membuat sebuah PodDisruptionBudget.

• Pelajari lebih lanjut mengenai melakukan drain terhadap node.

4.1.8 - Kontainer Sementara (Ephemeral)

Halaman ini memberikan gambaran umum tentang kontainer sementara: satu jenis kontainer khusus yang berjalan sementara pada Pod yang sudah ada untuk melakukan tindakan yang diinisiasi oleh pengguna seperti dalam pemecahan masalah. Kamu menggunakan kontainer sementara untuk memeriksa layanan bukan untuk membangun aplikasi.

Peringatan: Kontainer sementara masih berada dalam fase alpha dan tidak cocok untuk klaster produksi. Kamu harus mengharapkan adanya suatu fitur yang tidak akan berfungsi dalam beberapa situasi tertentu, seperti saat menargetkan namespace dari suatu kontainer. Sesuai dengan Kubernetes Deprecation Policy, fitur alpha ini dapat berubah secara signifikan di masa depan atau akan dihapus seluruhnya.

Memahami Kontainer Sementara

Pod adalah blok pembangun fundamental dalam aplikasi Kubernetes. Karena Pod diharapkan digunakan hanya sekali dan dapat diganti, sehingga kamu tidak dapat menambahkan kontainer ke dalam Pod setelah Pod tersebut dibuat. Sebaliknya, kamu biasanya menghapus dan mengganti beberapa Pod dengan cara yang terkontrol melalui Deployment.

Namun, kadang-kadang perlu juga untuk memeriksa keadaan Pod yang telah ada, sebagai contoh untuk memecahkan masalah bug yang sulit direproduksi. Dalam kasus ini, kamu dapat menjalankan sebuah kontainer sementara di dalam suatu Pod yang sudah ada untuk memeriksa statusnya dan menjalankannya segala macam perintah.

Apa itu Kontainer Sementara?

Kontainer sementara berbeda dengan kontainer lainnya karena tidak memiliki jaminan sumber daya maupun akan eksekusi, dan mereka tidak akan pernah secara otomatis melakukan restart, jadi mereka tidak sesuai untuk membangun aplikasi. Kontainer sementara dideskripsikan dengan menggunakan ContainerSpec yang sama dengan kontainer biasa, tetapi banyak bagian yang tidak kompatibel dan tidak diperbolehkan untuk kontainer sementara.

• Kontainer sementara mungkin tidak memiliki port, sehingga bagian seperti port, livenessProbe, readinessProbe tidak diperbolehkan.
• Alokasi sumber daya untuk Pod tidak dapat diubah, sehingga pengaturan sumber daya tidak diperbolehkan.
• Untuk daftar lengkap bagian yang diperbolehkan, dapat di lihat referensi dokumentasi Kontainer Sementara.

Kontainer sementara dibuat dengan menggunakan handler khusus EphemeralContainers dalam API tanpa menambahkannya langsung ke pod.spec, sehingga tidak memungkinan untuk menambahkan kontainer sementara dengan menggunakan kubectl edit.

Seperti dengan kontainer biasa, kamu tidak dapat mengubah atau menghapus kontainer sementara setelah kamu memasukkannya ke dalam sebuah Pod.

Penggunaan Kontainer Sementara

Kontainer sementara berguna untuk pemecahan masalah secara interaktif pada saat kubectl exec tidak mencukupi karena sebuah kontainer telah hancur atau kontainer image tidak memiliki utilitas untuk debugging.

Khususnya, untuk images_distroless memungkinkan kamu untuk menyebarkan kontainer image minimal yang mengurangi surface attack dan paparan bug dan vulnerability. Karena image distroless tidak mempunyai sebuah shell atau utilitas debugging apa pun, sehingga sulit untuk memecahkan masalah image distroless dengan menggunakan kubectl exec saja.

Saat menggunakan kontainer sementara, akan sangat membantu untuk mengaktifkan process namespace sharing sehingga kamu dapat melihat proses pada kontainer lain.

Contoh

Catatan: Contoh-contoh pada bagian ini membutuhkan EphemeralContainers feature gate untuk diaktifkan, dan membutuhkan Kubernetes klien dan server versi v1.16 atau yang lebih baru.

Contoh-contoh pada bagian ini menunjukkan bagaimana kontainer sementara muncul dalam API. Kamu biasanya dapat menggunakan plugin kubectl untuk mengatasi masalah untuk mengotomatiskan langkah-langkah ini.

Kontainer sementara dibuat menggunakan subresource ephemeralcontainers Pod, yang dapat didemonstrasikan menggunakan kubectl --raw. Pertama-tama deskripsikan kontainer sementara untuk ditambahkan dalam daftar EphemeralContainers:

{
    "apiVersion": "v1",
    "kind": "EphemeralContainers",
    "metadata": {
        "name": "example-pod"
    },
    "ephemeralContainers": [{
        "command": [
            "sh"
        ],
        "image": "busybox",
        "imagePullPolicy": "IfNotPresent",
        "name": "debugger",
        "stdin": true,
        "tty": true,
        "terminationMessagePolicy": "File"
    }]
}

Untuk memperbarui kontainer yang sudah berjalan dalam example-pod:

kubectl replace --raw /api/v1/namespaces/default/pods/example-pod/ephemeralcontainers  -f ec.json

Ini akan menampilkan daftar baru dari seluruh kontainer sementara:

{
   "kind":"EphemeralContainers",
   "apiVersion":"v1",
   "metadata":{
      "name":"example-pod",
      "namespace":"default",
      "selfLink":"/api/v1/namespaces/default/pods/example-pod/ephemeralcontainers",
      "uid":"a14a6d9b-62f2-4119-9d8e-e2ed6bc3a47c",
      "resourceVersion":"15886",
      "creationTimestamp":"2019-08-29T06:41:42Z"
   },
   "ephemeralContainers":[
      {
         "name":"debugger",
         "image":"busybox",
         "command":[
            "sh"
         ],
         "resources":{

         },
         "terminationMessagePolicy":"File",
         "imagePullPolicy":"IfNotPresent",
         "stdin":true,
         "tty":true
      }
   ]
}

Kamu dapat melihat kondisi kontainer sementara yang baru dibuat dengan menggunakan kubectl describe:

kubectl describe pod example-pod

...
Ephemeral Containers:
  debugger:
    Container ID:  docker://cf81908f149e7e9213d3c3644eda55c72efaff67652a2685c1146f0ce151e80f
    Image:         busybox
    Image ID:      docker-pullable://busybox@sha256:9f1003c480699be56815db0f8146ad2e22efea85129b5b5983d0e0fb52d9ab70
    Port:          <none>
    Host Port:     <none>
    Command:
      sh
    State:          Running
      Started:      Thu, 29 Aug 2019 06:42:21 +0000
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:         <none>
...

Kamu dapat mengakses kontainer sementara yang baru menggunakan kubectl attach:

kubectl attach -it example-pod -c debugger

Jika proses berbagi namespace diaktifkan, kamu dapat melihat proses dari semua kontainer dalam Pod tersebut. Misalnya, setelah mengakses, kamu jalankan ps di kontainer debugger:

# Jalankan ini pada _shell_ dalam _debugger_ dari kontainer sementara
ps auxww

Hasilnya akan seperti ini:

PID   USER     TIME  COMMAND
    1 root      0:00 /pause
    6 root      0:00 nginx: master process nginx -g daemon off;
   11 101       0:00 nginx: worker process
   12 101       0:00 nginx: worker process
   13 101       0:00 nginx: worker process
   14 101       0:00 nginx: worker process
   15 101       0:00 nginx: worker process
   16 101       0:00 nginx: worker process
   17 101       0:00 nginx: worker process
   18 101       0:00 nginx: worker process
   19 root      0:00 /pause
   24 root      0:00 sh
   29 root      0:00 ps auxww

4.2 - Controllers

4.2.1 - ReplicaSet

Tujuan dari ReplicaSet adalah untuk memelihara himpunan stabil dari replika Pod yang sedang berjalan pada satu waktu tertentu. Maka dari itu, ReplicaSet seringkali digunakan untuk menjamin ketersediaan dari beberapa Pod identik dalam jumlah tertentu.

Cara kerja ReplicaSet

Sebuah ReplicaSet didefinisikan dengan beberapa field termasuk selektor yang menentukan bagaimana mengidentifikasi Pod yang dapat diakuisisi, jumlah replika yang mengindikasi berapa jumlah Pod yang harus dikelola, dan sebuah templat pod yang menentukan data dari berbagai Pod baru yang harus dibuat untuk memenuhi kriteria jumlah replika. Sebuah ReplicaSet selanjutnya akan memenuhi tujuannya dengan membuat dan menghapus Pod sesuai dengan kebutuhan untuk mencapai jumlah yang diinginkan. Ketika ReplicaSet butuh untuk membuat Pod baru, templat Pod akan digunakan.

Tautan dari sebuah ReplicaSet terhadap Pod yang dimiliki adalah melalui field metadata.ownerReferences pada Pod, yang menentukan sumber daya yang dimiliki oleh objek saat ini. Semua Pod yang diakuisisi oleh sebuah ReplicaSet masing-masing memiliki informasi yang mengidentifikasi ReplicaSet dalam field ownerReferences. Melalui tautan ini ReplicaSet dapat mengetahui keadaan dari Pod yang sedang dikelola dan melakukan perencanaan yang sesuai.

Sebuah ReplicaSet mengidentifikasi Pod baru untuk diakuisisi menggunakan selektornya. Jika terdapat sebuah Pod yang tidak memiliki OwnerReference atau OwnerReference yang dimiliki bukanlah sebuah Controller dan sesuai dengan selektor dari ReplicaSet, maka Pod akan langsung diakuisisi oleh ReplicaSet tersebut.

Kapan menggunakan ReplicaSet

Sebuah ReplicaSet memastikan replika-replika pod dalam jumlah yang ditentukan berjalan pada satu waktu tertentu. Namun demikian, sebuah Deployment adalah konsep dengan tingkatan yang lebih tinggi yang mengatur ReplicaSet dan mengubah Pod secara deklaratif serta berbagai fitur bermanfaat lainnya. Maka dari itu, kami merekomendasikan untuk menggunakan Deployment alih-alih menggunakan ReplicaSet secara langsung, kecuali jika kamu membutuhkan orkestrasi pembaruan yang khusus atau tidak membutuhkan pembaruan sama sekali.

Hal ini berarti kamu boleh jadi tidak akan membutuhkan manipulasi objek ReplicaSet: Gunakan Deployment dan definisikan aplikasi kamu pada bagian spec.

Contoh

controllers/frontend.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # modify replicas according to your case
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3

Menyimpan manifest ini dalam frontend.yaml dan mengirimkannya ke klaster Kubernetes akan membuat ReplicaSet yang telah didefinisikan beserta dengan Pod yang dikelola.

kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml

Selanjutnya kamu bisa mendapatkan ReplicaSet yang sedang di-deploy:

kubectl get rs

Dan melihat frontend yang telah dibuat:

NAME       DESIRED   CURRENT   READY   AGE
frontend   3         3         3       6s

Kamu juga dapat memeriksa kondisi dari ReplicaSet:

kubectl describe rs/frontend

Dan kamu akan melihat keluaran yang serupa dengan:

Name:		frontend
Namespace:	default
Selector:	tier=frontend,tier in (frontend)
Labels:		app=guestbook
		tier=frontend
Annotations:	<none>
Replicas:	3 current / 3 desired
Pods Status:	3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:       app=guestbook
                tier=frontend
  Containers:
   php-redis:
    Image:      gcr.io/google_samples/gb-frontend:v3
    Port:       80/TCP
    Requests:
      cpu:      100m
      memory:   100Mi
    Environment:
      GET_HOSTS_FROM:   dns
    Mounts:             <none>
  Volumes:              <none>
Events:
  FirstSeen    LastSeen    Count    From                SubobjectPath    Type        Reason            Message
  ---------    --------    -----    ----                -------------    --------    ------            -------
  1m           1m          1        {replicaset-controller }             Normal      SuccessfulCreate  Created pod: frontend-qhloh
  1m           1m          1        {replicaset-controller }             Normal      SuccessfulCreate  Created pod: frontend-dnjpy
  1m           1m          1        {replicaset-controller }             Normal      SuccessfulCreate  Created pod: frontend-9si5l

Terakhir, kamu dapat memeriksa Pod yang dibawa:

kubectl get Pods

Kamu akan melihat informasi Pod yang serupa dengan:

NAME             READY     STATUS    RESTARTS   AGE
frontend-9si5l   1/1       Running   0          1m
frontend-dnjpy   1/1       Running   0          1m
frontend-qhloh   1/1       Running   0          1m

Kamu juga dapat memastikan bahwa referensi pemilik dari pod-pod ini telah disesuaikan terhadap ReplicaSet frontend. Untuk melakukannya, yaml dari Pod yang sedang berjalan bisa didapatkan dengan:

kubectl get pods frontend-9si5l -o yaml

Keluarannya akan terlihat serupa dengan contoh berikut ini, dengan informasi ReplicaSet frontend yang ditentukan pada field ownerReferences pada bagian metadata:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: 2019-01-31T17:20:41Z
  generateName: frontend-
  labels:
    tier: frontend
  name: frontend-9si5l
  namespace: default
  ownerReferences:
  - apiVersion: extensions/v1beta1
    blockOwnerDeletion: true
    controller: true
    kind: ReplicaSet
    name: frontend
    uid: 892a2330-257c-11e9-aecd-025000000001
...

Akuisisi Pod Non-Templat

Walaupun kamu bisa membuat Pod biasa tanpa masalah, sangat direkomendasikan untuk memastikan Pod tersebut tidak memiliki label yang sama dengan selektor dari salah satu ReplicaSet yang kamu miliki. Hal in disebabkan sebuah ReplicaSet tidak dibatasi untuk memilki Pod sesuai dengan templatnya -- ReplicaSet dapat mengakuisisi Pod lain dengan cara yang telah dijelaskan pada bagian sebelumnya.

Mengambil contoh ReplicaSet frontend sebelumnya, dan Pod yang ditentukan pada manifest berikut:

pods/pod-rs.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod1
  labels:
    tier: frontend
spec:
  containers:
  - name: hello1
    image: gcr.io/google-samples/hello-app:2.0

---

apiVersion: v1
kind: Pod
metadata:
  name: pod2
  labels:
    tier: frontend
spec:
  containers:
  - name: hello2
    image: gcr.io/google-samples/hello-app:1.0

Karena Pod tersebut tidak memiliki Controller (atau objek lain) sebagai referensi pemilik yang sesuai dengan selektor dari ReplicaSet frontend, Pod tersebut akan langsung diakuisisi oleh ReplicaSet.

Misalkan kamu membuat Pod tersebut setelah ReplicaSet frontend telah di-deploy dan telah mengkonfigurasi replika Pod awal untuk memenuhi kebutuhan jumlah replika:

kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml

Pod baru akan diakuisisi oleh ReplicaSet, dan setelah itu langsung diterminasi ketika ReplicaSet melebihi jumlah yang diinginkan.

Memperoleh Pod:

kubectl get Pods

Keluaran menunjukkan bahwa Pod baru dalam keaadan telah diterminasi, atau sedang dalam proses terminasi:

NAME             READY   STATUS        RESTARTS   AGE
frontend-9si5l   1/1     Running       0          1m
frontend-dnjpy   1/1     Running       0          1m
frontend-qhloh   1/1     Running       0          1m
pod2             0/1     Terminating   0          4s

Jika kamu membuat Pod terlebih dahulu:

kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml

Dan selanjutnya membuat ReplicaSet maka:

kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml

Kamu akan melihat bahwa ReplicaSet telah mengakuisisi Pod dan hanya membuat Pod yang baru sesuai dengan spec yang ditentukan hingga jumlah dari Pod yang baru dan yang orisinil sesuai dengan jumlah yang diinginkan. Dengan memperoleh Pod:

kubectl get Pods

Akan diperlihatkan pada keluarannya:

NAME             READY   STATUS    RESTARTS   AGE
frontend-pxj4r   1/1     Running   0          5s
pod1             1/1     Running   0          13s
pod2             1/1     Running   0          13s

Dengan cara ini, sebuah ReplicaSet dapat memiliki himpunan berbagai Pod yang tidak homogen.

Menulis manifest ReplicaSet

Seperti objek API Kubernetes lainnya, sebuah ReplicaSet membutuhkan field apiVersion, kind, dan metadata. Untuk ReplicaSet, nilai dari kind yang memungkinkan hanyalah ReplicaSet. Pada Kubernetes 1.9 versi API apps/v1 pada kind ReplicaSet adalah versi saat ini dan diaktifkan secara default. Versi API apps/v1beta2 telah dideprekasi. Lihat baris-baris awal pada contoh frontend.yaml untuk petunjuk.

Sebuah ReplicaSet juga membutuhkan bagian .spec.

Templat Pod

.spec.template adalah sebuah templat pod yang juga dibutuhkan untuk mempunyai label. Pada contoh frontend.yaml kita memiliki satu label: tier: frontend. Hati-hati agar tidak tumpang tindih dengan selektor dari controller lain, agar mereka tidak mencoba untuk mengadopsi Pod ini.

Untuk field restart policy dari templat, .spec.template.spec.restartPolicy, nilai yang diperbolehkan hanyalah Always, yang merupakan nilai default.

Selektor Pod

Field .spec.selector adalah sebuah selektor labe. Seperti yang telah dibahas sebelumnya, field ini adalah label yang digunakan untuk mengidentifikasi Pod yang memungkinkan untuk diakuisisi. Pada contoh frontend.yaml, selektornya adalah:

matchLabels:
	tier: frontend

Pada ReplicaSet, .spec.template.metadata.labels harus memiliki nilai yang sama dengan spec.selector, atau akan ditolak oleh API.

Catatan: Untuk 2 ReplicaSet dengan nilai .spec.selector yang sama tetapi memiliki nilai yang berbeda pada field .spec.template.metadata.labels dan .spec.template.spec, setiap ReplicaSet akan mengabaikan Pod yang dibuat oleh ReplicaSet lain.

Replika

Kamu dapat menentukan jumlah Pod yang seharusnya berjalan secara konkuren dengan mengatur nilai dari .spec.replicas. ReplicaSet akan membuat/menghapus Pod-nya hingga jumlahnya sesuai dengan field ini.

Jika nilai .spec.replicas tidak ditentukan maka akan diatur ke nilai default 1.

Menggunakan ReplicaSet

Menghapus ReplicaSet dan Pod-nya

Untuk menghapus sebuah ReplicaSet beserta dengan Pod-nya, gunakan kubectl delete. Garbage collector secara otomatis akan menghapus semua Pod dependen secara default.

Ketika menggunakan REST API atau library client-go, kamu harus mengatur nilai propagationPolicy menjadi Background atau Foreground pada opsi -d. Sebagai contoh:

kubectl proxy --port=8080
curl -X DELETE  'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \
> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
> -H "Content-Type: application/json"

Menghapus hanya ReplicaSet

Kamu dapat menghapus ReplicaSet tanpa memengaruhi Pod-nya menggunakan kubectl delete dengan menggunakan opsi --cascade=false. Ketika menggunakan REST API atau library client-go, kamu harus mengatur nilai propagationPolicy menjadi Orphan. Sebagai contoh:

kubectl proxy --port=8080
curl -X DELETE  'localhost:8080/apis/extensions/v1beta1/namespaces/default/replicasets/frontend' \
> -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
> -H "Content-Type: application/json"

Ketika ReplicaSet yang asli telah dihapus, kamu dapat membuat ReplicaSet baru untuk menggantikannya. Selama field .spec.selector yang lama dan baru memilki nilai yang sama, maka ReplicaSet baru akan mengadopsi Pod lama namun tidak serta merta membuat Pod yang sudah ada sama dan sesuai dengan templat Pod yang baru. Untuk memperbarui Pod dengan spec baru dapat menggunakan Deployment karena ReplicaSet tidak mendukung pembaruan secara langsung.

Mengisolasi Pod dari ReplicaSet

Kamu dapat menghapus Pod dari ReplicaSet dengan mengubah nilai labelnya. Cara ini dapat digunakan untuk menghapus Pod dari servis untuk keperluan debugging, data recovery, dan lainnya. Pod yang dihapus dengan cara ini akan digantikan seecara otomatis (dengan asumsi jumlah replika juga tidak berubah).

Mengatur jumlah Pod pada ReplicaSet

Jumlah Pod pada ReplicaSet dapat diatur dengan mengubah nilai dari field .spec.replicas. Pengatur ReplicaSet akan memastikan Pod dengan jumlah yang telah ditentukan dan dengan nilai selektor yang sama sedang dalam keadaan berjalan.

Pengaturan jumlah Pod pada ReplicaSet menggunakan Horizontal Pod Autoscaler

Pengaturan jumlah Pod pada ReplicaSet juga dapat dilakukan mengunakan Horizontal Pod Autoscalers (HPA). Berikut adalah contoh HPA terhadap ReplicaSet yang telah dibuat pada contoh sebelumnya.

controllers/hpa-rs.yaml

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: frontend-scaler
spec:
  scaleTargetRef:
    kind: ReplicaSet
    name: frontend
  minReplicas: 3
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50

Menyimpan manifest ini dalam hpa-rs.yaml dan mengirimkannya ke klaster Kubernetes akan membuat HPA tersebut yang akan mengatur jumlah Pod pada ReplicaSet yang telah didefinisikan bergantung terhadap penggunaan CPU dari Pod yang direplikasi.

kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml

Opsi lainnya adalah dengan menggunakan perintah kubectl autoscale untuk tujuan yang sama.

kubectl autoscale rs frontend --max=10

Alternatif selain ReplicaSet

Deployment (direkomendasikan)

Deployment adalah sebuah objek yang bisa memiliki ReplicaSet dan memperbarui ReplicaSet dan Pod-nya melalui rolling update deklaratif dan server-side. Walaupun ReplicaSet dapat digunakan secara independen, seringkali ReplicaSet digunakan oleh Deployments sebagai mekanisme untuk mengorkestrasi pembuatan, penghapusan dan pembaruan Pod. Ketika kamu menggunakan Deployments kamu tidak perlu khawatir akan pengaturan dari ReplicaSet yang dibuat. Deployments memiliki dan mengatur ReplicaSet-nya sendiri. Maka dari itu penggunaan Deployments direkomendasikan jika kamu menginginkan ReplicaSet.

Pod sederhana

Tidak seperti pada kasus ketika pengguna secara langsung membuat Pod, ReplicaSet akan menggantikan Pod yang dihapus atau diterminasi dengan alasan apapun, seperti pada kasus dimana terjadi kegagalan node atau pemeliharaan node yang disruptif, seperti pada kasus upgrade kernel. Karena alasan ini kami merekomendasikan kamu untuk menggunakan ReplicaSet walaupun jika aplikasimu membutuhkan hanya satu Pod. Hal ini mirip dengan pengawas proses, hanya saja pada kasus ini mengawasi banyak Pod pada berbagai node alih-alih berbagai proses individu pada sebuah node. ReplicaSet mendelegasikan proses pengulangan kembali dari kontainer lokal kepada agen yang terdapat di node (sebagai contoh, Kubelet atau Docker).

Job

Gunakan Job alih-alih ReplicaSet untuk Pod yang diharapkan untuk diterminasi secara sendirinya.

DaemonSet

Gunakan DaemonSet alih-alih ReplicaSet untuk Pod yang menyediakan fungsi pada level mesin, seperti monitoring mesin atau logging mesin. Pod ini memiliki waktu hidup yang bergantung terhadap waktu hidup mesin: Pod perlu untuk berjalan pada mesin sebelum Pod lain dijalankan, dan aman untuk diterminasi ketika mesin siap untuk di-reboot atau dimatikan.

ReplicationController

ReplicaSet adalah suksesor dari ReplicationControllers. Keduanya memenuhi tujuan yang sama dan memiliki perilaku yang serupa, kecuali bahwa ReplicationController tidak mendukung kebutuhan selektor set-based seperti yang dijelaskan pada panduan penggunaan label. Pada kasus tersebut, ReplicaSet lebih direkomendasikan dibandingkan ReplicationController.

4.2.2 - ReplicationController

Catatan: Deployment yang mengonfigurasi ReplicaSet sekarang menjadi cara yang direkomendasikan untuk melakukan replikasi.

Sebuah ReplicationController memastikan bahwa terdapat sejumlah Pod yang sedang berjalan dalam suatu waktu tertentu. Dengan kata lain, ReplicationController memastikan bahwa sebuah Pod atau sebuah kumpulan Pod yang homogen selalu berjalan dan tersedia.

Bagaimana ReplicationController Bekerja

Jika terdapat terlalu banyak Pod, maka ReplicationController akan membatasi dan mematikan Pod-Pod yang berlebih. Jika terdapat terlalu sedikit, maka ReplicationController akan memulai dan menjalankan Pod-Pod baru lainnya. Tidak seperti Pod yang dibuat secara manual, Pod-Pod yang diatur oleh sebuah ReplicationController akan secara otomatis diganti jika mereka gagal, dihapus, ataupun dimatikan. Sebagai contoh, Pod-Pod yang kamu miliki akan dibuat ulang dalam sebuah Node setelah terjadi proses pemeliharaan seperti pembaruan kernel. Untuk alasan ini, maka kamu sebaiknya memiliki sebuah ReplicationController bahkan ketika aplikasimu hanya membutuhkan satu buah Pod saja. Sebuah ReplicationController memiliki kemiripan dengan sebuah pengawas proses, tetapi alih-alih mengawasi sebuah proses individu pada sebuah Node, ReplicationController banyak Pod yang terdapat pada beberapa Node.

ReplicationController seringkali disingkat sebagai "rc" dalam diskusi, dan sebagai shortcut dalam perintah kubectl.

Sebuah contoh sederhana adalah membuat sebuah objek ReplicationController untuk menjalankan sebuah instance Pod secara berkelanjutan. Contoh pemakaian lainnya adalah untuk menjalankan beberapa replika identik dari sebuah servis yang direplikasi, seperti peladen web.

Menjalankan Sebuah Contoh ReplicationController

Contoh ReplicationController ini mengonfigurasi tiga salinan dari peladen web nginx.

controllers/replication.yaml

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    app: nginx
  template:
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

Jalankan contoh di atas dengan mengunduh berkas contoh dan menjalankan perintah ini:

kubectl apply -f https://k8s.io/examples/controllers/replication.yaml

replicationcontroller/nginx created

Periksa status dari ReplicationController menggunakan perintah ini:

kubectl describe replicationcontrollers/nginx

Name:        nginx
Namespace:   default
Selector:    app=nginx
Labels:      app=nginx
Annotations:    <none>
Replicas:    3 current / 3 desired
Pods Status: 0 Running / 3 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:       app=nginx
  Containers:
   nginx:
    Image:              nginx
    Port:               80/TCP
    Environment:        <none>
    Mounts:             <none>
  Volumes:              <none>
Events:
  FirstSeen       LastSeen     Count    From                        SubobjectPath    Type      Reason              Message
  ---------       --------     -----    ----                        -------------    ----      ------              -------
  20s             20s          1        {replication-controller }                    Normal    SuccessfulCreate    Created pod: nginx-qrm3m
  20s             20s          1        {replication-controller }                    Normal    SuccessfulCreate    Created pod: nginx-3ntk0
  20s             20s          1        {replication-controller }                    Normal    SuccessfulCreate    Created pod: nginx-4ok8v

Tiga Pod telah dibuat namun belum ada yang berjalan, kemungkinan karena image yang sedang di-pull. Beberapa waktu kemudian, perintah yang sama akan menunjukkan:

Pods Status:    3 Running / 0 Waiting / 0 Succeeded / 0 Failed

Untuk melihat semua Pod yang dibuat oleh ReplicationController dalam bentuk yang lebih mudah dibaca mesin, kamu dapat menggunakan perintah seperti ini:

pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name})
echo $pods

nginx-3ntk0 nginx-4ok8v nginx-qrm3m

Pada perintah di atas, selektor yang dimaksud adalah selektor yang sama dengan yang terdapat pada ReplicationController (yang dapat dilihat pada keluaran kubectl describe), dan dalam bentuk yang berbeda dengan yang terdapat pada replication.yaml. Opsi --output=jsonpath menentukan perintah untuh mendapatkan hanya nama dari setiap Pod yang ada pada daftar hasil.

Menulis Spesifikasi ReplicationController

Seperti semua konfigurasi Kubernetes lainnya, sebuah ReplicationController membutuhkan field apiVersion, kind, dan metadata.

Untuk informasi umum mengenai berkas konfigurasi, kamu dapat melihat pengaturan objek.

Sebuah ReplicationController juga membutuhkan bagian .spec.

Templat Pod

.spec.template adalah satu-satunya field yang diwajibkan pada .spec.

.spec.template adalah sebuah templat Pod. Ia memiliki skema yang sama persis dengan sebuah Pod, namun dapat berbentuk nested dan tidak memiliki field apiVersion ataupun kind.

Selain field-field yang diwajibkan untuk sebuah Pod, templat Pod pada ReplicationController harus menentukan label dan kebijakan pengulangan kembali yang tepat. Untuk label, pastikan untuk tidak tumpang tindih dengan kontroler lain. Lihat selektor pod.

Nilai yang diperbolehkan untuk .spec.template.spec.restartPolicy hanyalah Always, yaitu nilai bawaan jika tidak ditentukan.

Untuk pengulangan kembali dari sebuah kontainer lokal, ReplicationController mendelegasikannya ke agen pada Node, contohnya Kubelet atau Docker.

Label pada ReplicationController

ReplicationController itu sendiri dapat memiliki label (.metadata.labels). Biasanya, kamu akan mengaturnya untuk memiliki nilai yang sama dengan .spec.template.metadata.labels; jika .metadata.labels tidak ditentukan maka akan menggunakan nilai bawaan yaitu .spec.template.metadata.labels. Namun begitu, kedua label ini diperbolehkan untuk memiliki nilai yang berbeda, dan .metadata.labels tidak akan memengaruhi perilaku dari ReplicationController.

Selektor Pod

Field .spec.selector adalah sebuah selektor label. Sebuah ReplicationController mengatur semua Pod dengan label yang sesuai dengan nilai selektor tersebut. Ia tidak membedakan antara Pod yang ia buat atau hapus atau Pod yang dibuat atau dihapus oleh orang atau proses lain. Hal ini memungkinkan ReplicationController untuk digantikan tanpa memengaruhi Pod-Pod yang sedang berjalan.

Jika ditentukan, .spec.template.metadata.labels harus memiliki nilai yang sama dengan .spec.selector, atau akan ditolak oleh API. Jika .spec.selector tidak ditentukan, maka akan menggunakan nilai bawaan yaitu .spec.template.metadata.labels.

Selain itu, kamu juga sebaiknya tidak membuat Pod dengan label yang cocok dengan selektor ini, baik secara langsung, dengan menggunakan ReplicationController lain, ataupun menggunakan kontroler lain seperti Job. Jika kamu melakukannya, ReplicationController akan menganggap bahwa ia telah membuat Pod-Pod lainnya. Kubernetes tidak akan menghentikan kamu untuk melakukan aksi ini.

Jika kamu pada akhirnya memiliki beberapa kontroler dengan selektor-selektor yang tumpang tindih, kamu harus mengatur penghapusannya sendiri (lihat di bawah).

Beberapa Replika

Kamu dapat menentukan jumlah Pod yang seharusnya berjalan secara bersamaan dengan mengatur nilai .spec.replicas dengan jumlah Pod yang kamu inginkan untuk berjalan secara bersamaan. Jumlah yang berjalan dalam satu satuan waktu dapat lebih tinggi ataupun lebih rendah, seperti jika replika-replika tersebut melewati proses penambahan atau pengurangan, atau jika sebuah Pod melalui proses graceful shutdown, dan penggantinya telah dijalankan terlebih dahulu.

Jika kamu tidak menentukan nilai dari .spec.replicas, maka akan digunakan nilai bawaan 1.

Bekerja dengan ReplicationController

Menghapus Sebuah ReplicationController dan Pod-nya

Untuk menghapus sebuah ReplicationController dan Pod-Pod yang berhubungan dengannya, gunakan perintah kubectl delete. Kubectl akan mengatur ReplicationController ke nol dan menunggunya untuk menghapus setiap Pod sebelum menghapus ReplicationController itu sendiri. Jika perintah kubectl ini terhenti, maka dapat diulang kembali.

Ketika menggunakan REST API atau library klien go, maka kamu perlu melakukan langkah-langkahnya secara eksplisit (mengatur replika-replika ke 0, menunggu penghapusan Pod, dan barulah menghapus ReplicationController).

Menghapus Hanya ReplicationController

Kamu dapat menghapus ReplicationController tanpa memengaruhi Pod-Pod yang berhubungan dengannya.

Dengan menggunakan kubectl, tentukan opsi --cascade=false ke kubectl delete.

Ketika menggunakan REST API atau library klien go, cukup hapus objek ReplicationController.

Ketika ReplicationController yang asli telah dihapus, kamu dapat membuat ReplicationController yang baru sebagai penggantinya. Selama .spec.selector yang lama dan baru memiliki nilai yang sama, maka ReplicationController baru akan mengadopsi Pod-Pod yang lama. Walaupun begitu, ia tidak akan melakukan usaha apapun untuk membuat Pod-Pod yang telah ada sebelumnya untuk sesuai dengan templat Pod yang baru dan berbeda. Untuk memperbarui Pod-Pod ke spesifikasi yang baru dengan cara yang terkontrol, gunakan pembaruan bergulir.

Mengisolasi Pod dari ReplicationController

Pod-Pod dapat dihapus dari kumpulan target sebuah ReplicationController dengan mengganti nilai dari labelnya. Teknik ini dapat digunakan untuk mencopot Pod-Pod dari servis untuk keperluan pengawakutuan (debugging), pemulihan data, dan lainnya. Pod-Pod yang dicopot dengan cara ini dapat digantikan secara otomatis (dengan asumsi bahwa jumlah replika juga tidak berubah).

Pola penggunaan umum

Penjadwalan ulang

Seperti yang telah disebutkan sebelumnya, baik kamu memiliki hanya 1 Pod untuk tetap dijalankan, ataupun 1000, ReplicationController akan memastikan tersedianya jumlah Pod yang telat ditentukan, bahkan ketika terjadi kegagalan Node atau terminasi Pod (sebagai contoh karena adanya tindakan dari agen kontrol lain).

Penskalaan

ReplicationController memudahkan penskalaan jumlah replika, baik meningkatkan ataupun mengurangi, secara manual ataupun dengan agen kontrol penskalaan otomatis, dengan hanya mengubah nilai dari field replicas.

Pembaruan bergulir

ReplicationController didesain untuk memfasilitasi pembaruan bergulir untuk sebuah servis dengan mengganti Pod-Pod satu per satu.

Seperti yang telah dijelaskan di #1353, pendekatan yang direkomendasikan adalah dengan membuat ReplicationController baru dengan 1 replika, skala kontroler yang baru (+1) atau yang lama (-1) satu per satu, dan kemudian hapus kontroler lama setelah menyentuh angka 0 replika. Hal ini memungkinkan pembaruan dilakukan dengan dapat diprediksi terlepas dari adanya kegagalan yang tak terduga.

Idealnya, kontroler pembaruan bergulir akan memperhitungkan kesiapan dari aplikasi, dan memastikan cukupnya jumlah Pod yang secara produktif meladen kapanpun.

Dua ReplicationController diharuskan untuk memiliki setidaknya satu label yang berbeda, seperti tag image dari kontainer utama dari Pod, karena pembaruan bergulir biasanya dilakukan karena adanya pembaruan image.

Pembaruan bergulir diimplementasikan pada perkakas klien kubectl rolling-update. Lihat kubectl rolling-update task untuk contoh-contoh yang lebih konkrit.

Operasi rilis majemuk

Selain menjalankan beberapa rilis dari sebuah aplikasi ketika proses pembaruan bergulir sedang berjalan, adalah hal yang awam untuk menjalankan beberapa rilis untuk suatu periode waktu tertentu, atau bahkan secara kontinu, menggunakan operasi rilis majemuk. Operasi-operasi ini akan dibedakan menggunakan label.

Sebagai contoh, sebuah servis dapat menyasar semua Pod dengan tier in (frontend), environment in (prod). Anggap kamu memiliki 10 Pod tiruan yang membangun tier ini tetapi kamu ingin bisa menggunakan 'canary' terhadap versi baru dari komponen ini. Kamu dapat mengatur sebuah ReplicationController dengan nilai replicas 9 untuk replika-replikanya, dengan label tier=frontend, environment=prod, track=stable, dan ReplicationController lainnya dengan nilai replicas 1 untuk canary, dengan label tier=frontend, environment=prod, track=canary. Sekarang servis sudah mencakup baik canary maupun Pod-Pod yang bukan canary. Kamu juga dapat mencoba-coba ReplicationController secara terpisah untuk melakukan pengujian, mengamati hasilnya, dan lainnya.

Menggunakan ReplicationController dengan Service

Beberapa ReplicationController dapat berada di belakang sebuah Service, sedemikian sehingga, sebagai contoh, sebagian traffic dapat ditujukan ke versi lama, dan sebagian lainnya ke versi yang baru.

Sebuah ReplicationController tidak akan berhenti dengan sendirinya, namun ia tidak diekspektasikan untuk berjalan selama Service-Service yang ada. Service dapat terdiri dari berbagai Pod yang dikontrol beberapa ReplicationController, dan terdapat kemungkinan bahwa beberapa ReplicationController untuk dibuat dan dimatikan dalam jangka waktu hidup Service (contohnya adalah untuk melakukan pembaruan Pod-Pod yang menjalankan Service). Baik Service itu sendiri dan kliennya harus tetap dalam keadaan tidak mempunyai pengetahuan terhadap ReplicationController yang memelihara Pod-Pod dari Service tersebut.

Menulis program untuk Replikasi

Pod-Pod yang dibuat oleh ReplicationController ditujukan untuk dapat sepadan dan memiliki semantik yang identik, walaupun konfigurasi mereka dapat berbeda seiring keberjalanan waktunya. Ini adalah contoh yang cocok untuk peladen stateless, namun ReplicationController juga dapat digunakan untuk memelihara ketersediaan dari aplikasi-aplikasi yang master-elected, sharded, worker-pool. Aplikasi-aplikasi seperti itu sebaiknya menggunakan mekanisme penetapan kerja yang dinamis, seperti antrian kerja RabbitMQ, berlainan dengan pengubahan statis/satu kali dari konfigurasi setiap Pod, yang dipandang sebagai sebuah anti-pattern. Pengubahan apapun yang dilakukan terhadap Pod, seperti auto-sizing vertikal dari sumber daya (misalnya cpu atau memori), sebaiknya dilakukan oleh proses kontroller luring lainnya, dan bukan oleh ReplicationController itu sendiri.

Tanggung Jawab ReplicationController

ReplicationController hanya memastikan ketersediaan dari sejumlah Pod yang cocok dengan selektor label dan berjalan dengan baik. Saat ini, hanya Pod yang diterminasi yang dijadikan pengecualian dari penghitungan. Kedepannya, kesiapan dan informasi yang ada lainnya dari sistem dapat menjadi pertimbangan, kami dapat meningkatkan kontrol terhadap kebijakan penggantian, dan kami berencana untuk menginformasikan kejadian (event) yang dapat digunakan klien eksternal untuk implementasi penggantian yang sesuai dan/atau kebijakan pengurangan.

ReplicationController akan selalu dibatasi terhadap tanggung jawab spesifik ini. Ia tidak akan melakukan probe kesiapan atau keaktifan. Daripada melakukan auto-scaling, ia ditujukan untuk dikontrol oleh auto-scaler eksternal (seperti yang didiskusikan pada #492), yang akan mengganti field replicas. Kami tidak akan menambahkan kebijakan penjadwalan (contohnya spreading) untuk ReplicationController. Ia juga tidak seharusnya melakukan verifikasi terhadap Pod-Pod yang sedang dikontrol yang cocok dengan spesifikasi templat saat ini, karena hal itu dapat menghambat auto-sizing dan proses otomatis lainnya. Demikian pula batas waktu penyelesaian, pengurutan dependencies, ekspansi konfigurasi, dan fitur-fitur lain yang seharusnya berada di komponen lain. Kami juga bahkan berencana untuk mengeluarkan mekanisme pembuatan Pod secara serentak (#170).

ReplicationController ditujukan untuk menjadi primitif komponen yang dapat dibangun untuk berbagai kebutuhan. Kami menargetkan API dengan tingkatan yang lebih tinggi dan/atau perkakas-perkakas untuk dibangun di atasnya dan primitif tambahan lainnya untuk kenyamanan pengguna kedepannya. Operasi-operasi makro yang sudah didukung oleh kubectl (run, scale, rolling-update) adalah contoh proof-of-concept dari konsep ini. Sebagai contohnya, kita dapat menganggap sesuatu seperti Asgard yang mengatur beberapa ReplicationController, auto-scaler, servis, kebijakan penjadwalan, canary, dan yang lainnya.

Objek API

ReplicationController adalah sebuah sumber daya top-level pada REST API Kubernetes. Detil dari objek API dapat ditemukan di: objek API ReplicationController.

Alternatif untuk ReplicationController

ReplicaSet

ReplicaSet adalah kelanjutan dari ReplicationController yang mendukung selektor selektor label set-based yang baru. Umumnya digunakan oleh Deployment sebagai mekanisme untuk mengorkestrasi pembuatan, penghapusan, dan pembaruan Pod. Perhatikan bahwa kami merekomendasikan untuk menggunakan Deployment sebagai ganti dari menggunakan ReplicaSet secara langsung, kecuali jika kamu membutuhkan orkestrasi pembaruan khusus atau tidak membutuhkan pembaruan sama sekali.

Deployment (Direkomendasikan)

Deployment adalah objek API tingkat tinggi yang memperbarui ReplicaSet dan Pod-Pod di bawahnya yang mirip dengan cara kerja kubectl rolling-update. Deployment direkomendasikan jika kamu menginginkan fungsionalitas dari pembaruan bergulir ini, karena tidak seperti kubectl rolling-update, Deployment memiliki sifat deklaratif, server-side, dan memiliki beberapa fitur tambahan lainnya.

Pod sederhana

Tidak seperti pada kasus ketika pengguna secara langsung membuat Pod, ReplicationController menggantikan Pod-Pod yang dihapus atau dimatikan untuk alasan apapun, seperti pada kasus kegagalan Node atau pemeliharaan Node yang disruptif, seperti pembaruan kernel. Untuk alasan ini, kami merekomendasikan kamu untuk menggunakan ReplicationController bahkan ketika aplikasimu hanya membutuhkan satu Pod saja. Anggap hal ini mirip dengan pengawas proses, hanya pada kasus ini mengawasi banyak Pod yang terdapat pada berbagai Node dan bukan proses-proses tunggal pada satu Node. ReplicationController mendelegasikan pengulangan kontainer lokal ke agen yang terdapat dalam Node (contohnya Kubelet atau Docker).

Job

Gunakan Job sebagai ganti ReplicationController untuk Pod-Pod yang diharapkan diterminasi dengan sendirinya (seperti batch jobs).

DaemonSet

Gunakan DaemonSet sebagai ganti ReplicationController untuk Pod-Pod yang menyediakan fungsi pada level mesin, seperti pengamatan mesin atau pencatatan mesin. Pod-Pod ini memiliki waktu hidup yang bergantung dengan waktu hidup mesin: Pod butuh untuk dijalankan di mesin sebelum Pod-Pod lainnya dimulai, dan aman untuk diterminasi ketika mesin sudah siap untuk dinyalakan ulang atau dimatikan.

Informasi lanjutan

Baca Menjalankan Kontroler Replikasi AP Stateless.

4.2.3 - Deployment

Deployment menyediakan pembaruan Pods dan ReplicaSets secara deklaratif.

Kamu mendeskripsikan sebuah state yang diinginkan dalam Deployment, kemudian Deployment Pengontrol mengubah state sekarang menjadi seperti pada deskripsi secara bertahap. Kamu dapat mendefinisikan Deployment untuk membuat ReplicaSets baru atau untuk menghapus Deployment yang sudah ada dan mengadopsi semua resourcenya untuk Deployment baru.

Catatan: Jangan mengganti ReplicaSets milik Deployment. Pertimbangkan untuk membuat isu pada repositori utama Kubernetes jika kasusmu tidak diatasi semua kasus di bawah.

Penggunaan

Berikut adalah penggunaan yang umum pada Deployment:

• Membuat Deployment untuk merilis ReplicaSet. ReplicaSet membuat Pod di belakang layar. Cek status rilis untuk tahu proses rilis sukses atau tidak.
• Mendeklarasikan state baru dari Pods dengan membarui PodTemplateSpec milik Deployment. ReplicaSet baru akan dibuat dan Deployment mengatur perpindahan Pod secara teratur dari ReplicaSet lama ke ReplicaSet baru. Tiap ReplicaSet baru akan mengganti revisi Deployment.
• Mengembalikan ke revisi Deployment sebelumnya jika state Deployment sekarang tidak stabil. Tiap pengembalian mengganti revisi Deployment.
• Memperbesar Deployment untuk memfasilitasi beban yang lebih.
• Menjeda Deployment untuk menerapkan perbaikan pada PodTemplateSpec-nya, lalu melanjutkan untuk memulai rilis baru.
• Memakai status Deployment sebagai indikator ketika rilis tersendat.
• Membersihkan ReplicaSet lama yang sudah tidak terpakai.

Membuat Deployment

Berikut adalah contoh Deployment. Dia membuat ReplicaSet untuk membangkitkan tiga Pod nginx:

controllers/nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

Dalam contoh ini:

• Deployment baru akan dibuat dengan nama nginx-deployment, tertulis pada kolom .metadata.name.

• Deployment membuat tiga Pod yang direplikasi, ditandai dengan kolom replicas.

• Kolom selector mendefinisikan bagaimana Deployment menemukan Pod yang diatur. Dalam kasus ini, kamu hanya perlu memilih sebuah label yang didefinisikan pada templat Pod (app: nginx). Namun, aturan pemilihan yang lebih canggih mungkin dilakukan asal templat Pod-nya memenuhi aturan.

  Catatan: Kolom matchLabels berbentuk pasangan {key,value}. Sebuah {key,value} dalam map matchLabels ekuivalen dengan elemen pada matchExpressions, yang mana kolom key adalah "key", operator adalah "In", dan larik values hanya berisi "value". Semua prasyarat dari matchLabels maupun matchExpressions harus dipenuhi agar dapat dicocokkan.

• Kolom template berisi sub kolom berikut:

  • Pod dilabeli app: nginx dengan kolom labels.
  • Spesifikasi templat Pod atau kolom .template.spec menandakan bahwa Pod mennjalankan satu kontainer nginx, yang menjalankan image nginx Docker Hub dengan versi 1.7.9.
  • Membuat satu kontainer bernama nginx sesuai kolom name.

  Ikuti langkah-langkah berikut untuk membuat Deployment di atas:

  Sebelum memulai, pastikan klaster Kubernetes sedang menyala dan bekerja.

  1. Buat Deployment dengan menjalankan perintah berikut:

     Catatan: Kamu dapat menambahkan argument --record untuk menulis perintah yang dijalankan pada anotasi sumber daya kubernetes.io/change-cause. Ini berguna untuk pemeriksaan di masa depan. Contohnya yaitu untuk melihat perintah yang dijalankan pada tiap revisi Deployment.

  kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
  

  2. Jalankan kubectl get deployments untuk mengecek apakah Deployment telah dibuat. Jika Deployment masih sedang pembuatan, keluaran akan tampil seperti berikut:

  NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
  nginx-deployment   3         0         0            0           1s
  

  Ketika kamu memeriksa Deployments pada klastermu, kolom berikut akan tampil:

  * `NAME` menampilkan daftar nama Deployment pada klaster.
  * `DESIRED` menampilkan jumlah replika aplikasi yang diinginkan sesuai yang didefinisikan saat pembuatan Deployment. Ini adalah _state_ yang diinginkan.
  * `CURRENT` menampilkan berapa jumlah replika yang sedang berjalan.
  * `UP-TO-DATE` menampilkan jumlah replika yang diperbarui agar sesuai state yang diinginkan.
  * `AVAILABLE` menampilkan jumlah replika aplikasi yang dapat diakses pengguna.
  * `AGE` menampilkan lama waktu aplikasi telah berjalan.
  

  Perhatikan bahwa jumlah replika yang diinginkan adalah tiga sesuai kolom .spec.replicas.

  3. Untuk melihat status rilis Deployment, jalankan kubectl rollout status deployment.v1.apps/nginx-deployment. Keluaran akan tampil seperti berikut:

  Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
  deployment "nginx-deployment" successfully rolled out
  

  4. Jalankan kubectl get deployments lagi beberapa saat kemudian. Keluaran akan tampil seperti berikut:

  NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
  nginx-deployment   3         3         3            3           18s
  

  Perhatikan bahwa Deployment telah membuat ketiga replika dan semua replika sudah merupakan yang terbaru (mereka mengandung pembaruan terakhir templat Pod) dan dapat diakses.

  5. Untuk melihat ReplicaSet (rs) yang dibuat Deployment, jalankan kubectl get rs. Keluaran akan tampil seperti berikut:

  NAME                          DESIRED   CURRENT   READY   AGE
  nginx-deployment-75675f5897   3         3         3       18s
  

  Perhatikan bahwa nama ReplicaSet selalu dalam format [NAMA-DEPLOYMENT]-[KATA-ACAK]. Kata acak dibangkitkan secara acak dan menggunakan pod-template-hash sebagai benih.

  6. Untuk melihat label yang dibangkitkan secara otomatis untuk tiap Pod, jalankan kubectl get pods --show-labels. Perintah akan menghasilkan keluaran berikut:

  NAME                                READY     STATUS    RESTARTS   AGE       LABELS
  nginx-deployment-75675f5897-7ci7o   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
  nginx-deployment-75675f5897-kzszj   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
  nginx-deployment-75675f5897-qqcnn   1/1       Running   0          18s       app=nginx,pod-template-hash=3123191453
  

  ReplicaSet yang dibuat menjamin bahwa ada tiga Pod nginx.

  Catatan: Kamu harus memasukkan selektor dan label templat Pod yang benar pada Deployment (dalam kasus ini, app: nginx). Jangan membuat label atau selektor yang beririsan dengan kontroler lain (termasuk Deployment dan StatefulSet lainnya). Kubernetes tidak akan mencegah adanya label yang beririsan. Namun, jika beberapa kontroler memiliki selektor yang beririsan, kontroler itu mungkin akan konflik dan berjalan dengan tidak semestinya.

Label pod-template-hash

Catatan: Jangan ubah label ini.

Label pod-template-hash ditambahkan oleh Deployment kontroler pada tiap ReplicaSet yang dibuat atau diadopsi Deployment.

Label ini menjamin anak-anak ReplicaSet milik Deployment tidak tumpang tindih. Dia dibangkitkan dengan melakukan hash pada PodTemplate milik ReplicaSet dan memakainya sebagai label untuk ditambahkan ke selektor ReplicaSet, label templat Pod, dan Pod apapun yang ReplicaSet miliki.

Membarui Deployment

Catatan: Rilis Deployment hanya dapat dipicu oleh perubahan templat Pod Deployment (yaitu, .spec.template), contohnya perubahan kolom label atau image container. Yang lain, seperti replika, tidak akan memicu rilis.

Ikuti langkah-langkah berikut untuk membarui Deployment:

1. Ganti Pod nginx menjadi image nginx:1.9.1 dari image nginx:1.7.9.

   kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1
   

   Keluaran akan tampil seperti berikut:

   deployment.apps/nginx-deployment image updated
   

   Alternatif lainnya, kamu dapat edit Deployment dan mengganti .spec.template.spec.containers[0].image dari nginx:1.7.9 ke nginx:1.9.1:

   kubectl edit deployment.v1.apps/nginx-deployment
   

   Keluaran akan tampil seperti berikut:

   deployment.apps/nginx-deployment edited
   

2. Untuk melihat status rilis, jalankan:

   kubectl rollout status deployment.v1.apps/nginx-deployment
   

   Keluaran akan tampil seperti berikut:

   Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
   

   atau

   deployment "nginx-deployment" successfully rolled out
   

Untuk menampilkan detail lain dari Deployment yang terbaru:

• Setelah rilis sukses, kamu dapat melihat Deployment dengan menjalankan kubectl get deployments. Keluaran akan tampil seperti berikut:

  NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
  nginx-deployment   3         3         3            3           36s
  

• Jalankan kubectl get rs to see that the Deployment updated the Pods dengan membuat ReplicaSet baru dan menggandakannya menjadi 3 replika, sembari menghapus ReplicaSet menjadi 0 replika.

  kubectl get rs
  

  Keluaran akan tampil seperti berikut:

  NAME                          DESIRED   CURRENT   READY   AGE
  nginx-deployment-1564180365   3         3         3       6s
  nginx-deployment-2035384211   0         0         0       36s
  

• Menjalankan get pods sekarang hanya akan menampilkan Pod baru:

  kubectl get pods
  

  Keluaran akan tampil seperti berikut:

  NAME                                READY     STATUS    RESTARTS   AGE
  nginx-deployment-1564180365-khku8   1/1       Running   0          14s
  nginx-deployment-1564180365-nacti   1/1       Running   0          14s
  nginx-deployment-1564180365-z9gth   1/1       Running   0          14s
  

  Selanjutnya ketika ingin membarui Pod, kamu hanya perlu mengganti templat Pod Deployment lagi.

  Deployment memastikan hanya ada beberapa Pod yang mati saat pembaruan berlangsung. Umumnya, dia memastikan paling sedikit ada 75% jumlah Pod yang diinginkan menyala (25% maksimal tidak dapat diakses).

  Deployment juga memastikan hanya ada beberapa Pod yang dibuat melebihi jumlah Pod yang diinginkan. Umumnya, dia memastikan paling banyak ada 125% jumlah Pod yang diinginkan menyala (25% tambahan maksimal).

  Misalnya, jika kamu lihat Deployment diatas lebih jauh, kamu akan melihat bahwa pertama-tama dia membuat Pod baru, kemudian menghapus beberapa Pod lama, dan membuat yang baru. Dia tidak akan menghapus Pod lama sampai ada cukup Pod baru menyala, dan pula tidak membuat Pod baru sampai ada cukup Pod lama telah mati. Dia memastikan paling sedikit 2 Pod menyala dan paling banyak total 4 Pod menyala.

• Melihat detil Deployment:

  kubectl describe deployments
  

  Keluaran akan tampil seperti berikut:

  Name:                   nginx-deployment
  Namespace:              default
  CreationTimestamp:      Thu, 30 Nov 2017 10:56:25 +0000
  Labels:                 app=nginx
  Annotations:            deployment.kubernetes.io/revision=2
  Selector:               app=nginx
  Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
  StrategyType:           RollingUpdate
  MinReadySeconds:        0
  RollingUpdateStrategy:  25% max unavailable, 25% max surge
  Pod Template:
    Labels:  app=nginx
     Containers:
      nginx:
        Image:        nginx:1.9.1
        Port:         80/TCP
        Environment:  <none>
        Mounts:       <none>
      Volumes:        <none>
    Conditions:
      Type           Status  Reason
      ----           ------  ------
      Available      True    MinimumReplicasAvailable
      Progressing    True    NewReplicaSetAvailable
    OldReplicaSets:  <none>
    NewReplicaSet:   nginx-deployment-1564180365 (3/3 replicas created)
    Events:
      Type    Reason             Age   From                   Message
      ----    ------             ----  ----                   -------
      Normal  ScalingReplicaSet  2m    deployment-controller  Scaled up replica set nginx-deployment-2035384211 to 3
      Normal  ScalingReplicaSet  24s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 1
      Normal  ScalingReplicaSet  22s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 2
      Normal  ScalingReplicaSet  22s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 2
      Normal  ScalingReplicaSet  19s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 1
      Normal  ScalingReplicaSet  19s   deployment-controller  Scaled up replica set nginx-deployment-1564180365 to 3
      Normal  ScalingReplicaSet  14s   deployment-controller  Scaled down replica set nginx-deployment-2035384211 to 0
  

  Disini bisa dilihat ketika pertama Deployment dibuat, dia membuat ReplicaSet (nginx-deployment-2035384211) dan langsung menggandakannya menjadi 3 replika. Saat Deployment diperbarui, dia membuat ReplicaSet baru (nginx-deployment-1564180365) dan menambah 1 replika kemudian mengecilkan ReplicaSet lama menjadi 2, sehingga paling sedikit 2 Pod menyala dan paling banyak 4 Pod dibuat setiap saat. Dia kemudian lanjut menaik-turunkan ReplicaSet baru dan ReplicaSet lama, dengan strategi pembaruan rolling yang sama. Terakhir, kamu akan dapat 3 replika di ReplicaSet baru telah menyala, dan ReplicaSet lama akan hilang (berisi 0).

Perpanjangan (alias banyak pembaruan secara langsung)

Setiap kali Deployment baru is teramati oleh Deployment kontroler, ReplicaSet dibuat untuk membangkitkan Pod sesuai keinginan. Jika Deployment diperbarui, ReplicaSet yang terkait Pod dengan label .spec.selector yang cocok, namun kolom .spec.template pada templat tidak cocok akan dihapus. Kemudian, ReplicaSet baru akan digandakan sebanyak .spec.replicas dan semua ReplicaSet lama dihapus.

Jika kamu mengubah Deployment saat rilis sedang berjalan, Deployment akan membuat ReplicaSet baru tiap perubahan dan memulai penggandaan. Lalu, dia akan mengganti ReplicaSet yang dibuat sebelumnya -- mereka ditambahkan ke dalam daftar ReplicaSet lama dan akan mulai dihapus.

Contohnya, ketika kamu membuat Deployment untuk membangkitkan 5 replika nginx:1.7.9, kemudian membarui Deployment dengan versi nginx:1.9.1 ketika ada 3 replika nginx:1.7.9 yang dibuat. Dalam kasus ini, Deployment akan segera menghapus 3 replika Pod nginx:1.7.9 yang telah dibuat, dan mulai membuat Pod nginx:1.9.1. Dia tidak akan menunggu kelima replika nginx:1.7.9 selesai baru menjalankan perubahan.

Mengubah selektor label

Umumnya, sekali dibuat, selektor label tidak boleh diubah. Sehingga disarankan untuk direncanakan dengan hati-hati sebelumnya. Bagaimanapun, jika kamu perlu mengganti selektor label, lakukan dengan seksama dan pastikan kamu tahu segala konsekuensinya.

Catatan: Pada versi API apps/v1, selektor label Deployment tidak bisa diubah ketika selesai dibuat.

• Penambahan selektor mensyaratkan label templat Pod di spek Deployment untuk diganti dengan label baru juga. Jika tidak, galat validasi akan muncul. Perubahan haruslah tidak tumpang-tindih, dengan kata lain selektor baru tidak mencakup ReplicaSet dan Pod yang dibuat dengan selektor lama. Sehingga, semua ReplicaSet lama akan menggantung sedangkan ReplicaSet baru tetap dibuat.
• Pengubahan selektor mengubah nilai pada kunci selektor -- menghasilkan perilaku yang sama dengan penambahan.
• Penghapusan selektor menghilangkan kunci yang ada pada selektor Deployment -- tidak mensyaratkan perubahan apapun pada label templat Pod. ReplicaSet yang ada tidak menggantung dan ReplicaSet baru tidak dibuat. Tapi perhatikan bahwa label yang dihapus masih ada pada Pod dan ReplicaSet masing-masing.

Membalikkan Deployment

Kadang, kamu mau membalikkan Deployment; misalnya, saat Deployment tidak stabil, seperti crash looping. Umumnya, semua riwayat rilis Deployment disimpan oleh sistem sehingga kamu dapat kembali kapanpun kamu mau (kamu dapat mengubahnya dengan mengubah batas riwayat revisi).

Catatan: Revisi Deployment dibuat saat rilis Deployment dipicu. Ini berarti revisi baru dibuat jika dan hanya jika templat Pod Deployment (.spec.template) berubah, misalnya jika kamu membarui label atau image kontainer pada templat. Pembaruan lain, seperti penggantian skala Deployment, tidak membuat revisi Deployment, jadi kamu dapat memfasilitasi penggantian skala secara manual atau otomatis secara simultan. Artinya saat kamu membalikkan ke versi sebelumnya, hanya bagian templat Pod Deployment yang dibalikkan.

• Misal kamu membuat saltik saat mengganti Deployment, dengan memberi nama image dengan nginx:1.91 alih-alih nginx:1.9.1:

  kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.91 --record=true
  

  Keluaran akan tampil seperti berikut:

  deployment.apps/nginx-deployment image updated
  

• Rilis akan tersendat. Kamu dapat memeriksanya dengan melihat status rilis:

  kubectl rollout status deployment.v1.apps/nginx-deployment
  

  Keluaran akan tampil seperti berikut:

  Waiting for rollout to finish: 1 out of 3 new replicas have been updated...
  

• Tekan Ctrl-C untuk menghentikan pemeriksaan status rilis di atas. Untuk info lebih lanjut tentang rilis tersendat, baca disini.

• Kamu lihat bahwa jumlah replika lama (nginx-deployment-1564180365 dan nginx-deployment-2035384211) adalah 2, dan replika baru (nginx-deployment-3066724191) adalah 1.

  kubectl get rs
  

  Keluaran akan tampil seperti berikut:

  NAME                          DESIRED   CURRENT   READY   AGE
  nginx-deployment-1564180365   3         3         3       25s
  nginx-deployment-2035384211   0         0         0       36s
  nginx-deployment-3066724191   1         1         0       6s
  

• Lihat pada Pod yang dibuat. Akan ada 1 Pod dibuat dari ReplicaSet baru tersendat loop(?) ketika penarikan image.

  kubectl get pods
  

  Keluaran akan tampil seperti berikut:

  NAME                                READY     STATUS             RESTARTS   AGE
  nginx-deployment-1564180365-70iae   1/1       Running            0          25s
  nginx-deployment-1564180365-jbqqo   1/1       Running            0          25s
  nginx-deployment-1564180365-hysrc   1/1       Running            0          25s
  nginx-deployment-3066724191-08mng   0/1       ImagePullBackOff   0          6s
  

  Catatan: Controller Deployment menghentikan rilis yang buruk secara otomatis dan juga berhenti meningkatkan ReplicaSet baru. Ini tergantung pada parameter rollingUpdate (secara khusus maxUnavailable) yang dimasukkan. Kubernetes umumnya mengatur jumlahnya menjadi 25%.

• Tampilkan deskripsi Deployment:

  kubectl describe deployment
  

  Keluaran akan tampil seperti berikut:

  Name:           nginx-deployment
  Namespace:      default
  CreationTimestamp:  Tue, 15 Mar 2016 14:48:04 -0700
  Labels:         app=nginx
  Selector:       app=nginx
  Replicas:       3 desired | 1 updated | 4 total | 3 available | 1 unavailable
  StrategyType:       RollingUpdate
  MinReadySeconds:    0
  RollingUpdateStrategy:  25% max unavailable, 25% max surge
  Pod Template:
    Labels:  app=nginx
    Containers:
     nginx:
      Image:        nginx:1.91
      Port:         80/TCP
      Host Port:    0/TCP
      Environment:  <none>
      Mounts:       <none>
    Volumes:        <none>
  Conditions:
    Type           Status  Reason
    ----           ------  ------
    Available      True    MinimumReplicasAvailable
    Progressing    True    ReplicaSetUpdated
  OldReplicaSets:     nginx-deployment-1564180365 (3/3 replicas created)
  NewReplicaSet:      nginx-deployment-3066724191 (1/1 replicas created)
  Events:
    FirstSeen LastSeen    Count   From                    SubobjectPath   Type        Reason              Message
    --------- --------    -----   ----                    -------------   --------    ------              -------
    1m        1m          1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-2035384211 to 3
    22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 1
    22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 2
    22s       22s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 2
    21s       21s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 1
    21s       21s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-1564180365 to 3
    13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled down replica set nginx-deployment-2035384211 to 0
    13s       13s         1       {deployment-controller }                Normal      ScalingReplicaSet   Scaled up replica set nginx-deployment-3066724191 to 1
  

  Untuk memperbaikinya, kamu harus kembali ke revisi Deployment yang sebelumnya stabil.