Mempelajari Panduan Dasar Kubernetes

Konsep

Kubernetes v1.16 dokumentasi sudah tidak dirawat lagi. Versi yang kamu lihat ini hanyalah snapshot statis. Untuk dokumentasi terkini, lihat versi terkini.

Edit This Page

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.

General Configuration Tips

  • 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 memanggil kubectl 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 sebelum Pod 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 semua Pods harus dapat melakukan resolusi namaService secara otomatis.

  • Jangan tentukan hostPort untuk Pod kecuali jika benar-benar diperlukan. Ketika Anda bind Pod ke hostPort, hal itu membatasi jumlah tempat Pod dapat dijadwalkan, karena setiap kombinasi <hostIP, hostPort,protokol> harus unik. Jika Anda tidak menentukan hostIP danprotokol secara eksplisit, Kubernetes akan menggunakan 0.0.0.0 sebagaihostIP dan TCP 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 (yang memiliki ClusterIP dariNone) untuk Service discovery yang mudah ketika Anda tidak membutuhkan kube-proxy load balancing.

Using Labels

  • Deklarasi dan gunakan 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 semua tier: frontend Pods, atau semua komponenphase: test dari app: 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 contoh sha256: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 bahkan imagePullPolicy: Always efisien. Dengan Docker, misalnya, jika image sudah ada, upaya pull cepat karena semua lapisan image di-cache dan tidak perlu mengunduh image.

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

Masukan