Konfigurasi dan Penerapan Konsep
Dokumen ini menyoroti dan memperkuat pemahaman konsep konfigurasi yang dikenalkan di seluruh panduan pengguna, dokumentasi Memulai, dan contoh-contoh.
Dokumentasi ini terbuka. Jika Anda menemukan sesuatu yang tidak ada dalam daftar ini tetapi mungkin bermanfaat bagi orang lain, jangan ragu untuk mengajukan issue atau mengirimkan PR.
Tip konfigurasi secara umum
-
Saat mendefinisikan konfigurasi, tentukan versi API stabil terbaru.
-
File konfigurasi harus disimpan dalam version control sebelum di push ke cluster. Ini memungkinkan Anda untuk dengan cepat mengembalikan perubahan konfigurasi jika perlu. Ini juga membantu penciptaan dan restorasi cluster.
-
Tulis file konfigurasi Anda menggunakan YAML tidak dengan JSON. Meskipun format ini dapat digunakan secara bergantian di hampir semua skenario, YAML cenderung lebih ramah pengguna.
-
Kelompokkan objek terkait ke dalam satu file yang memungkinkan. Satu file seringkali lebih mudah dikelola daripada beberapa file. Lihat pada guestbook-all-in-one.yaml sebagai contoh file sintaks ini.
-
Perhatikan juga bahwa banyak perintah
kubectldapat dipanggil pada direktori. Misalnya, Anda dapat memanggilkubectl applypada direktori file konfigurasi. -
Jangan tentukan nilai default yang tidak perlu: sederhana, konfigurasi minimal akan membuat kesalahan lebih kecil.
-
Masukkan deskripsi objek dalam anotasi, untuk memungkinkan introspeksi yang lebih baik.
"Naked" Pods vs ReplicaSets, Deployments, and Jobs
-
Jangan gunakan Pods naked (artinya, Pods tidak terikat dengan a ReplicaSet a Deployment) jika kamu bisa menghindarinya. Pod naked tidak akan dijadwal ulang jika terjadi kegagalan pada node.
Deployment, yang keduanya menciptakan ReplicaSet untuk memastikan bahwa jumlah Pod yang diinginkan selalu tersedia, dan menentukan strategi untuk mengganti Pods (seperti RollingUpdate), hampir selalu lebih disukai daripada membuat Pods secara langsung, kecuali untuk beberapa yang eksplisit
restartPolicy: Neverbanyak skenario . A Job mungkin juga sesuai.
Services
-
Buat Service sebelum workloads backend terkait (Penyebaran atau ReplicaSets), dan sebelum workloads apa pun yang perlu mengaksesnya. Ketika Kubernetes memulai sebuah container, ia menyediakan environment variabel yang menunjuk ke semua Layanan yang berjalan ketika container itu dimulai. Misalnya, jika Layanan bernama
fooada, semua container akan mendapatkan variabel berikut di environment awalnya:FOO_SERVICE_HOST=<the host the Service is running on> FOO_SERVICE_PORT=<the port the Service is running on>*Ini menunjukan persyaratan pemesanan * -
Serviceapa pun yang ingin diakses olehPodharus dibuat sebelumPoditu sendiri, atau environment variabel tidak akan diisi. DNS tidak memiliki batasan ini. -
Opsional (meskipun sangat disarankan) cluster add-on adalah server DNS. Server DNS melihat API Kubernetes untuk
Servicebaru dan membuat satu set catatan DNS untuk masing-masing. Jika DNS telah diaktifkan di seluruh cluster maka semuaPodsharus dapat melakukan resolusi namaServicesecara otomatis. -
Jangan tentukan
hostPortuntuk Pod kecuali jika benar-benar diperlukan. Ketika Anda bind Pod kehostPort, hal itu membatasi jumlah tempat Pod dapat dijadwalkan, karena setiap kombinasi <hostIP,hostPort,protokol> harus unik. Jika Anda tidak menentukanhostIPdanprotokolsecara eksplisit, Kubernetes akan menggunakan0.0.0.0sebagaihostIPdanTCPsebagai defaultprotokol.Jika kamu hanya perlu akses ke port untuk keperluan debugging, Anda bisa menggunakan apiserver proxy atau
kubectl port-forward.Jika Anda secara eksplisit perlu mengekspos port Pod pada node, pertimbangkan untuk menggunakan NodePort Service sebelum beralih ke
hostPort. -
Hindari menggunakan
hostNetwork, untuk alasan yang sama sepertihostPort. -
Gunakan [headless Services](/id/docs/concepts/services-networking/service/#headless- services) (yang memiliki
ClusterIPdariNone) untuk Service discovery yang mudah ketika Anda tidak membutuhkankube-proxyload balancing.
Menggunakan label
- Deklarasi dan gunakan [labels] (/id/docs/concepts/overview/working-with-objects/labels/) untuk identifikasi semantic attributes aplikasi atau Deployment kamu, seperti
{ app: myapp, tier: frontend, phase: test, deployment: v3 }. Kamu dapat menggunakan label ini untuk memilih Pod yang sesuai untuk sumber daya lainnya; misalnya, Service yang memilih semuatier: frontendPods, atau semua komponenphase: testdariapp: myapp. Lihat guestbook aplikasi untuk contoh-contoh pendekatan ini.
Service dapat dibuat untuk menjangkau beberapa Penyebaran dengan menghilangkan label khusus rilis dari pemilihnya. Deployments membuatnya mudah untuk memperbarui Service yang sedang berjalan tanpa downtime.
Keadaan objek yang diinginkan dideskripsikan oleh Deployment, dan jika perubahan terhadap spesifikasi tersebut adalah applied, Deployment controller mengubah keadaan aktual ke keadaan yang diinginkan pada tingkat yang terkontrol.
- Kamu dapat memanipulasi label untuk debugging. Karena Kubernetes controller (seperti ReplicaSet) dan Service Match dengan Pods menggunakan label pemilih, menghapus label yang relevan dari Pod akan menghentikannya dari dianggap oleh Controller atau dari lalu lintas yang dilayani oleh Service. Jika Anda menghapus label dari Pod yang ada, Controller akan membuat Pod baru untuk menggantikannya. Ini adalah cara yang berguna untuk men-debug Pod yang sebelumnya "live" di Environment "quarantine". Untuk menghapus atau menambahkan label secara interaktif, gunakan
kubectl label.
Container Images
Ini imagePullPolicy dan tag dari image mempengaruhi ketika kubelet mencoba menarik image yang ditentukan
-
imagePullPolicy: IfNotPresent: image ditarik hanya jika belum ada secara lokal. -
imagePullPolicy: Always: Image ditarik setiap kali pod dimulai. -
imagePullPolicydihilangkan dan tag imagenya adalah:latestatau dihilangkan:alwaysditerapkan. -
imagePullPolicydihilangkan dan tag image ada tetapi tidak:latest:IfNotPresentditerapkan. -
imagePullPolicy: Never: image diasumsikan ada secara lokal. Tidak ada upaya yang dilakukan untuk menarik image.
Catatan:
Untuk memastikan container selalu menggunakan versi image yang sama, Anda bisa menentukannya digest, untuk contohsha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2. digest mengidentifikasi secara unik versi image tertentu, sehingga tidak pernah diperbarui oleh Kubernetes kecuali Anda mengubah nilai digest.Catatan:
Anda harus menghindari penggunaan tag: latest saat menempatkan container dalam produksi karena lebih sulit untuk melacak versi image mana yang sedang berjalan dan lebih sulit untuk memutar kembali dengan benar.Catatan:
Semantik caching dari penyedia gambar yang mendasarinya membuat bahkanimagePullPolicy: Always efisien. Dengan Docker, misalnya, jika image sudah ada, upaya pull cepat karena semua lapisan image di-cache dan tidak perlu mengunduh image.Menggunakan kubectl
-
Gunakan
kubectl apply -f <directory>. Ini mencari konfigurasi Kubernetes di semua file.yaml,.yml, dan.jsondi<directory>dan meneruskannya keapply. -
Gunakan label selector untuk operasi
getdandeletealih-alih nama objek tertentu. Lihat bagian di label selectors dan using labels effectively. -
Gunakan
kubectl rundankubectl exposeuntuk dengan cepat membuat Deployment dan Service single-container. Lihat Use a Service to Access an Application in a Cluster untuk Contoh.