‫Beberapa perintah yang telah Anda gunakan, sejauh
‫ini, memiliki sedikit otomatisasi di belakangnya yang
‫dikenal sebagai generator. Generator yang dapat Anda pikirkan seperti templat.
‫Mereka pada dasarnya membuat spec, atau spesifikasi,
‫untuk diterapkan ke cluster Kubernetes berdasarkan opsi
‫baris perintah Anda.
‫Anda memikirkan perintah seperti menjalankan, dan
‫mengekspos, dan membuat. Mereka sering memiliki generator
‫di belakangnya yang memberikan templat yang
‫diperlukan dengan semua bidang dan default yang tidak
‫perlu Anda tentukan di baris perintah.
‫Intinya, inti dari generator ini adalah
‫untuk memudahkan Anda menggunakan perintah satu-baris, seperti yang biasa Anda gunakan
‫dengan Docker, dan Docker Compose, dan Swarm.
‫Untuk menggunakan perintah-perintah satu-baris di Kubernetes
‫sambil membiarkan beberapa pengaturan lebih lanjut menjadi default.
‫Sungguh, Swarm melakukan ini juga.
‫Swarm memiliki banyak default ketika Anda membuat layanan dan
‫tumpukan yang semuanya terjadi di latar belakang.
‫Anda tidak tahu itu. Generator ini seperti itu.
‫Berikut adalah contoh di mana kami membuat
‫Penempatan dengan perintah create, dan kami
‫memberikan beberapa opsi untuk memenuhi persyaratan minimum.
‫Ini akan mengisi sisa spesifikasi
‫dengan generator.
‫Generator ini berbeda untuk setiap jenis
‫barang yang Anda buat. Baik itu layanan, atau
‫penyebaran, atau pekerjaan, atau pekerjaan cron.
‫Hal-hal lain yang akan kita bicarakan nanti.
‫Generator itu sebenarnya dapat berubah
‫seiring waktu ketika setiap versi Kubernet keluar.
‫Mereka mungkin mengubah satu atau dua properti dari
‫spesifikasi itu.
‫Jadi, ini ada versi.
‫Kadang-kadang jika Anda telah melihat dalam dokumentasi Anda
‫mungkin melihat beberapa YAML untuk Kubernetes, dan ia mengatakan sesuatu tentang beta.
‫Itu sering ketika generator pertama kali dibuat, itu mungkin memiliki versi
‫beta dan kemudian saat ia beralih ke generator
‫yang matang, itu akan memiliki V1.
‫Kami tidak dapat benar-benar mendapatkan daftar generator di
‫baris perintah karena itu merentang berbagai perintah dan
‫opsi yang berbeda yang digunakan generator.
‫Cara termudah di sini di seluruh semua perintah yang berbeda
‫ini untuk melihat apa yang akan dihasilkan jika
‫Anda mengetik perintah itu terhadap sebuah cluster, adalah dengan menggunakan dua opsi.
‫Lari kering, yang merupakan cara yang sangat rapi untuk menampilkan
‫hasil dari apa yang Anda ketikkan, dan kita
‫akan melihatnya sebentar lagi. Kemudian -o, yang
‫berarti output. Kami mengatakan kami ingin output dalam YAML.
‫Kami pada dasarnya mengatakan menjalankan perintah ini tetapi tidak
‫secara teknis melakukannya di cluster.
‫Coba saja untuk melihat apa yang akan terjadi jika saya melakukannya.
‫Kemudian pada saat yang sama, tunjukkan padaku hasil YAML dari apa
‫yang akan dihasilkan jika saya menyelesaikan perintah ini.
‫Anda akan mendapatkan template kecil yang bagus secara esensial.
‫Anda bahkan bisa menggunakannya untuk mulai membuat YAML Anda sendiri yang akan
‫kami gunakan dalam kuliah nanti.
‫Akhirnya, generator di sini.
‫Anda juga dapat menganggapnya sebagai bawaan yang dianggap tidak adil.
‫Mereka benar-benar tidak memiliki pendapat.
‫Mereka super kecil.
‫Mereka biasanya 10 hingga 15 baris YAML.
‫Minimal untuk memulai sesuatu.
‫Mereka memang memiliki pendapat, itulah sebabnya mereka
‫memiliki versi. Anda mungkin melihat
‫lulusan versi beta dan yang lainnya. Saya menganggap mereka berpendapat tapi mereka
‫baik-baik saja, benar. Mereka akan bekerja untuk sebagian
‫besar kasus penggunaan ketika Anda hanya mencoba hal-hal untuk dev dan pengujian.
‫Mari kita lihat beberapa contoh untuk melihat generator
‫ini di baris perintah.
‫Yang pertama di sini adalah Penyebaran seperti yang kami gunakan sebelumnya.
‫Membuat penyebaran.
‫Anda akan melihat bahwa saya meletakkan --dry-run di akhir.
‫Jika Anda hanya melakukan dry run, itu hanya akan
‫memuntahkan jenis sumber daya yang akan dibuatnya.
‫Ini mirip dengan nama sumber daya yang kita lihat
‫ketika kita daftar itu dengan perintah get kubectl.
‫Jika saya menekan panah ke atas di sana dan ketik
‫-o yaml di bagian akhir,
‫maka akan muncul output YAML yang dihasilkan dengan perintah itu.
‫Kita akan membahas spesifikasi
‫YAML nanti. Untuk saat ini, Anda dapat melihat
‫bagian utama dari apa yang dilakukan di latar belakang ketika kami melakukan
‫itu membuat perintah penyebaran.
‫Pertama, ini menunjukkan versi API, versi jenis sumber
‫daya ini.
‫Jadi, kami menggunakan versi apps / v1
‫di sini. Jenisnya adalah penyebaran, dan
‫itu karena kami menciptakan Penempatan.
‫Jika itu adalah sebuah Pekerjaan, itu adalah pekerjaan.
‫Jika itu adalah Layanan, itu akan mengatakan layanan.
‫Hal semacam itu. Metadata akan selalu ada
‫untuk sumber daya apa pun yang Anda buat.
‫Ini akan memiliki timestamp, yang bersifat opsional, karena akan
‫menghasilkan secara otomatis ketika Anda benar-benar
‫membuat hal ini. Kemudian Anda akan memiliki label
‫dan atribut nama di sini yang dapat Anda tentukan.
‫Dalam hal ini, Anda melihat bahwa ini diisi banyak
‫dengan apa yang saya berikan di baris perintah.
‫Saya katakan itu saya ingin menyebutnya tes.
‫Jadi, itu memberinya nama ujian.
‫Ini menetapkannya sebagai aplikasi karena kami menggunakan Penempatan di
‫sini, itu menganggapnya sebagai aplikasi, bukan layanan atau
‫yang lainnya. Memanggil tes label itu.
‫Ini hanya default out-of-the-box.
‫Maka spesifikasi untuk Penempatan adalah replika
‫dari satu.
‫Pemilih yang akan kita bahas nanti, tetapi pada
‫dasarnya itulah yang menentukan untuk memilih pod di dalam
‫Penempatan ini. Ini pada dasarnya
‫yang cocok dengan Penempatan ke podnya.
‫Kemudian strategi. Yang kami biarkan kosong.
‫Template di sini adalah untuk ReplicaSet.
‫Kemudian Anda akan melihat di bawah spec itu wadah
‫yang akan dibuatnya. Jadi, ada sedikit lapisan bersarang
‫dari spec yang terjadi di sini. Itu karena kompleksitas lapisan
‫ini, kan. Kami memiliki pod, lalu ReplicaSets,
‫dan kemudian Deployment.
‫Anda dapat melihat bahwa itu membuat semuanya dengan
‫cepat, dan kami akan menerapkannya pada API ketika kami menekan
‫perintah ini.
‫Mari kita buat beberapa lagi di sini. Yang kedua menggunakan Jobs,
‫bukan Deployments. Biasanya dirancang ketika Anda
‫ingin membuat satu set pod yang akan berjalan sekali.
‫Itu cenderung mengatur mereka dengan default untuk tidak me-restart.
‫Dalam hal ini, kita akan menggunakan gambar yang sama,
‫nama yang sama. Kita akan
‫keringkan menjalankannya dengan -output yaml. Anda akan melihat betapa berbedanya itu.
‫Dalam hal ini, karena kami tidak memiliki beberapa tingkat
‫Penempatan dengan ReplicaSet bersarang di dalamnya, kami
‫tidak memerlukan beberapa tingkat spesifikasi.
‫Anda akan melihat, pertama, bahwa yang ini jauh lebih pendek.
‫Itu sebagian besar karena fakta bahwa dengan
‫Penyebaran, itu menciptakan ReplicaSet bersarang yang
‫kemudian menciptakan pod. Jadi, ada beberapa level di sana.
‫Di mana di sini, kami benar-benar hanya memiliki pekerjaan batch ini membuat
‫pod langsung untuk kami.
‫Anda dapat melihat di bagian atas bahwa versi API dan
‫jenisnya telah berubah.
‫Metadata sangat mirip, meskipun dalam kasus ini,
‫itu tidak membuat label aplikasi.
‫Spek ini hanya untuk Pekerjaan dan kemudian di bawahnya, spek
‫di dalamnya, di dalam templat itu,
‫adalah spek untuk
‫setiap pod wadah, benar.
‫Spec yang satu ini akan dibuat untuk berapa banyak yang
‫saya minta untuk dibuat.
‫Kami hanya membuat satu secara default.
‫Jadi, itu akan memiliki satu wadah menjalankan Nginx
‫dengan tes nama. Anda akan melihat bahwa kebijakan
‫mulai ulang tidak pernah. Itulah perubahannya, sebenarnya, dengan
‫sebagian besar cara lain menciptakan wadah
‫di Kubernet. Mereka akan secara otomatis mencoba membuat ulang,
‫atau memulai kembali. Dengan sebuah
‫pekerjaan, atau yang lebih baru dengan pekerjaan cron, Anda akan melihat bahwa
‫kebijakan restart diatur ke tidak pernah. Karena biasanya sekali pekerjaan
‫selesai, itu baru saja selesai, dan Anda tidak
‫ingin wadah itu membuatnya kembali. Terakhir, mari kita lakukan perintah mengekspos.
‫Meskipun ada run kering di sini, ketika Anda menjalankan penyebaran
‫paparan, itu akan memeriksa penyebaran itu dan
‫menyadari bahwa itu tidak ada, jadi itu tidak
‫dapat memberikan sampel output karena tidak benar-benar memiliki input
‫yang valid .
‫Dalam hal ini, kami secara teknis perlu membuat Penempatan.
‫Dalam hal ini, kita tidak perlu menjalankan
‫dan menjalankannya. Kami hanya ingin membuatnya.
‫Jadi, mari kita lakukan saja.
‫Kemudian, mari kita kembali ke perintah mengekspos itu dan
‫coba lagi. Maka lari kering
‫itu akan bekerja saat ini. Kami akan memiliki versi API V1.
‫Anda akan melihat bahwa Layanan sekarang lebih baik daripada
‫Deployment atau Pekerjaan.
‫Lalu, kami punya label serupa lainnya.
‫Anda akan melihat bahwa spesifikasi adalah semua tentang port dan
‫protokol karena memang itulah Layanan.
‫Ini kombinasi dari rute jaringan dan subnetting
‫IP dan port TCP atau UDP, dan hal-hal
‫seperti itu. Generator belum tentu merupakan
‫masalah besar. Anda tidak perlu mengingatnya atau mempelajari
‫perbedaan di antara mereka semua. Karena ketika Anda akan menemukan
‫banyak dari mereka dengan perintah run kubectl akan pergi, karena Anda akan
‫mengetahuinya dalam satu menit. Kemudian dalam kuliah
‫nanti, kita akan berbicara lebih banyak tentang jenis
‫cara Anda membuat wadah dan mungkin mengapa Anda tidak akan menggunakan
‫banyak proses dan menciptakan dalam beban kerja produksi Anda.
‫Ingatlah untuk menghapus penyebaran uji jika Anda membuatnya
‫untuk perintah terakhir kami tempat kami menguji paparan itu.