‫Saya akan jujur.
‫Kembali ketika saya pertama kali melihat Kubernetes YAML, saya
‫benar-benar terintimidasi.
‫Tampaknya jauh lebih rumit daripada format Tulis.
‫Itu untuk alasan yang bagus.
‫Ini menambah banyak fleksibilitas, banyak hal yang
‫dapat Anda lakukan dengannya. Tapi, itu ada harganya.
‫Itulah cara mempelajari dasar-dasar dan cara membuat file-file
‫ini. Ketika Anda pertama
‫kali mulai melihat file-file ini, ada banyak hal sehingga saya bahkan tidak
‫yakin apa yang terjadi ketika saya pertama kali memegang file-file ini.
‫Benar-benar mengerti jika Anda merasa sedikit
‫bingung tentang hal ini saat kami menjalaninya,
‫coba saja untuk me-rewatch video ini karena saya akan mencoba
‫memecah ini dengan cara yang saya pikir terbaik untuk
‫belajar Kubernetes YAML.
‫Pertama adalah kita bisa menulis ini secara teknis
‫dalam JSON, tetapi YAML cenderung lebih mudah bagi
‫manusia untuk memanipulasi dan membaca, dan
‫JSON lebih baik untuk komputer.
‫Apa yang terjadi di latar belakang adalah standar bagi
‫kita manusia untuk menulis YAML dan kemudian
‫mengubahnya menjadi JSON. Secara teknis Anda bisa menulis
‫JSON, tetapi standar dengan Kubernetes untuk ditulis
‫manusia adalah YAML.
‫Seperti saya katakan sebelumnya, Anda dapat mencampur
‫atau mencocokkan file-file ini. Anda dapat memiliki banyak sumber daya yang berbeda dalam satu
‫file dan kemudian melakukan sebaliknya dari yang mana Anda memiliki
‫satu file per sumber daya.
‫Tidak masalah. Terserah kamu.
‫Perintah bekerja dengan cara yang sama.
‫Kami menyebut manifes ini.
‫Deskripsi lengkap sumber daya adalah
‫manifes, dan manifes itu memiliki persyaratan.
‫Anda akan melihat persyaratan tersebut untuk kunci root di dalam
‫file YAML.
‫Root artinya mereka ada di awal baris.
‫Itu dimulai dengan versi API.
‫Ada jenisnya.
‫Ada metadata. Dan ada spek.
‫Jadi, Anda harus melihat semua itu di setiap file agar
‫sumber daya ini berfungsi. Dan mari kita lihat beberapa contoh
‫cepat dari baris perintah.
‫Jika Anda berada di repo Docker Mastery Anda, Anda akan melihat
‫direktori k8s-yaml tempat saya memasukkan beberapa
‫contoh ini di sini.
‫Jika Anda tidak melihat direktori itu, maka Anda
‫mungkin perlu melakukan git-pull untuk mendapatkan pembaruan
‫terbaru untuk repo. Jika Anda telah membuat beberapa perubahan dalam repo dari
‫mengikuti kursus ini, itu tidak masalah.
‫Anda bisa menggunakan git-simpanan untuk menyembunyikan perubahan itu sementara
‫dan kemudian melakukan git-pull.
‫Atau, Anda bisa menyalinnya ke
‫direktori lain. Kloning saja
‫di lokasi yang berbeda untuk bagian ini saja, karena
‫hal-hal Kubernetes ini lebih baru daripada yang asli.
‫Jadi, beberapa dari Anda mungkin akan kembali lagi nanti
‫dan tidak memiliki pembaruan terbaru.
‫Contoh pertama di sini hanyalah pod sederhana.
‫Ini mungkin YAML paling sederhana yang bisa kita buat.
‫Seperti yang saya katakan sebelumnya dalam kursus ini, Anda tidak
‫akan membuat banyak polong karena itu hanya membuat seperti
‫menjalankan buruh pelabuhan.
‫Itu bukan sesuatu yang ingin Anda lakukan.
‫Tidak ada pembaruan yang bergulir. Itu
‫bukan penyebaran, kan. Jika Anda perlu memecahkan masalah, atau
‫Anda hanya perlu menjalankan sesuatu yang sederhana secara lokal, Anda bisa melakukan ini.
‫Anda akan melihat ada empat persyaratan yang sama.
‫Versi API, jenisnya, metadata,
‫dan spek.
‫Kita akan membicarakan apa yang ada di kuliah berikutnya.
‫Untuk saat ini, saya hanya ingin
‫Anda melihat bagaimana pod ini. Maka
‫metadata memiliki atribut nama.
‫Kunci itu adalah kunci yang diperlukan dari semua
‫objek YAML.
‫Mereka semua harus memiliki nama itu, seperti halnya buruh pelabuhan harus
‫memiliki nama. Semua objek Docker harus memiliki nama.
‫Sama dengan Kubernet. Spesifikasi di sini adalah dagingnya.
‫Kita akan membahasnya sebentar lagi. Mari kita lihat
‫lagi penyebaran.
‫Berikut adalah penyebaran tunggal
‫dengan dua replika wadah yang sama. Mungkin ukurannya dua kali
‫lipat tetapi untuk alasan yang bagus.
‫Karena jika Anda memikirkannya, Anda
‫membuat sumber daya penyebaran itu, dan kemudian
‫menciptakan ReplicaSet. Maka itulah yang membuat pod.
‫Area spec menjadi
‫sedikit lebih rumit karena melakukan lebih banyak
‫hal yang harus kita definisikan. Anda juga akan melihat bahwa
‫versi API kami sedikit berbeda
‫karena itu terkait dengan jenisnya, dan jenis dalam hal
‫ini adalah penyebaran. Semacam itu artinya sumber daya.
‫Dan versi API adalah versi API
‫untuk jenis itu. Sisanya di sini semoga sedikit masuk
‫akal bagi Anda.
‫Ini terlihat sedikit mirip dengan Compose file
‫tetapi jelas formatnya berbeda.
‫Jadi, saya mengerti ini bisa membingungkan, terutama jika
‫Anda bekerja bolak-balik antara Compose dan Kubernetes.
‫Dalam contoh ini, saya telah menggabungkan layanan
‫dan penyebaran, untuk
‫jenis penyebaran yang sama, menjadi satu file.
‫Ini adalah bagaimana Anda akan memiliki banyak manifes dalam satu file saat
‫Anda menggunakan tiga tanda hubung
‫untuk memecah keduanya. Itu
‫semacam hal YAML yang akan memberitahu Kubernetes hei,
‫objek ini unik. Maka bagian
‫selanjutnya adalah objek baru. Anda dapat memiliki sebanyak yang
‫Anda inginkan di sini sampai menjadi begitu sulit sehingga Anda hanya perlu memecahkannya.
‫Anda akan melihat dengan bagian pertama ini, versi API adalah
‫V1 dari jenis sumber daya layanan.
‫Kata baik di sini mungkin bisa saja sumber,
‫tetapi mereka menyebutnya baik.
‫Metadata di sini lagi. Harus punya nama.
‫Spesifikasi dan itu akan sangat berbeda berdasarkan sumber
‫daya yang Anda buat.
‫Kemudian penyebaran yang sama dengan apa yang kita miliki sebelumnya, yang kasus
‫ini saya punya tiga replika dan itu punya nama yang
‫sedikit berbeda, tapi selain itu, itu adalah
‫Nginx yang sama.
‫Hanya dengan melihat itu, Anda berpikir, wow. Saya harus membutuhkan
‫template yang akan saya simpan jadi saya tahu bagaimana memulainya
‫karena ini tampaknya cukup kompleks.
‫Tidak ada halaman dokumen tunggal yang menjabarkan
‫semua ini untuk semua lusinan dan lusinan jenis sumber
‫daya yang berbeda, dan bagaimana masing-masing perlu diatur.
‫Sayangnya itu adalah sesuatu yang kami dapatkan dengan Compose di
‫mana itu adalah single yang bagus, meskipun lama.
‫halaman web pada dokumen Docker untuk
‫seluruh format Tulis. Dalam hal ini, kami
‫tidak mendapatkannya dengan Kubernetes hanya karena ada terlalu banyak kerumitan,
‫dan itu tidak semua di satu tempat.
‫Itu bahkan bukan satu aplikasi. Anda sebenarnya dapat menambahkan lebih banyak
‫jenis sumber daya dengan menambahkan lebih banyak hal yang disebut CRD
‫yang akan kita bicarakan nanti.
‫Kita bisa membahasnya. Itu pada dasarnya berarti Anda dapat
‫memperluas Kubernet dengan lebih banyak jenis sumber daya.
‫Lebih banyak barang pihak ketiga, yang bahkan akan menambahkan lebih banyak
‫opsi ke YAML ini. Itu unik untuk Kubernetes.
‫Swarm dan Docker tidak memungkinkan untuk itu.
‫Format mereka diatur di mana yang ini cukup
‫dapat diperluas, tergantung pada apa yang diinstal di cluster Anda.