Information in this document may be out of date
This document has an older update date than the original, so the information it contains may be out of date. If you're able to read English, see the English version for the most up-to-date information: Configuration Best Practices
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
kubectl
dapat dipanggil pada direktori. Misalnya, Anda dapat memanggilkubectl apply
pada 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: Never
banyak 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
foo
ada, 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 * -
Service
apa pun yang ingin diakses olehPod
harus dibuat sebelumPod
itu 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
Service
baru dan membuat satu set catatan DNS untuk masing-masing. Jika DNS telah diaktifkan di seluruh cluster maka semuaPods
harus dapat melakukan resolusi namaService
secara otomatis.Jangan tentukan
hostPort
untuk 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 menentukanhostIP
danprotokol
secara eksplisit, Kubernetes akan menggunakan0.0.0.0
sebagaihostIP
danTCP
sebagai 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
ClusterIP
dariNone
) untuk Service discovery yang mudah ketika Anda tidak membutuhkankube-proxy
load 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: frontend
Pods, atau semua komponenphase: test
dariapp: 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.imagePullPolicy
dihilangkan dan tag imagenya adalah:latest
atau dihilangkan:always
diterapkan.imagePullPolicy
dihilangkan dan tag image ada tetapi tidak:latest
:IfNotPresent
diterapkan.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.json
di<directory>
dan meneruskannya keapply
.Gunakan label selector untuk operasi
get
dandelete
alih-alih nama objek tertentu. Lihat bagian di label selectors dan using labels effectively.Gunakan
kubectl run
dankubectl expose
untuk dengan cepat membuat Deployment dan Service single-container. Lihat Use a Service to Access an Application in a Cluster untuk Contoh.