‫Mari kita bicara tentang mengapa Anda mungkin membutuhkan Kubernet.
‫Sekarang sebagai ulasan, periksa kembali
‫dengan bagian sebelumnya. Bagian pertama untuk Swarm
‫dan ada kuliah berjudul Swarm Mode Built-in Orchestration.
‫Itu memberi Anda beberapa dasar di sekitar
‫masalah yang memecahkan orkestrasi dan mengapa Anda
‫mungkin membutuhkannya. Saya akan menekankan
‫bahwa pada awalnya, sangat penting bagi
‫Anda untuk memahami manfaat orkestrasi apa yang Anda perlukan
‫untuk menyebarkan aplikasi Anda, dan apakah Anda
‫bahkan memerlukan orkestrasi untuk memulai.
‫Orkestrasi jelas meningkat dalam popularitas, tetapi itu bukan
‫satu-satunya cara untuk menjalankan kontainer.
‫Kami sudah bicara tentang menggunakan Docker berjalan di sini.
‫Kami sudah bicara tentang Susunan Docker.
‫Kami sudah bicara tentang penawaran dan layanan platform lainnya.
‫Saya memiliki pelanggan yang masih
‫menjalankan kontainer pada node tunggal di AWS
‫tanpa orkestrasi. Mereka menggunakan
‫fitur platform itu untuk membuat abstraksi serupa seperti orkestrasi, di
‫mana mereka mungkin menggunakan grup penskalaan otomatis, Penyeimbangan Beban Elastis,
‫dan banyak hal lain yang telah kita gunakan
‫selama lebih dari satu dekade untuk
‫mengelola penyebaran aplikasi kita.
‫Mereka memiliki sistem yang begitu halus sehingga mereka tidak
‫melihat banyak manfaat dari sepenuhnya mengubah semua itu
‫menjadi orkestrasi.
‫Sekarang, kebanyakan dari kita pada akhirnya akan
‫menggunakan beberapa bentuk orkestrasi wadah karena itu benar-benar cara saya
‫pikir industri berjalan, dan ini semua akan menjadi lapisan
‫tambahan ini berjalan di atas Docker, atau runtime lainnya,
‫yang adalah apa yang Anda Sudah saya pelajari
‫sepanjang kursus ini.
‫Salah satu formula sederhana yang saya gunakan
‫untuk menggunakan orkestrasi
‫atau tidak, adalah mengambil jumlah
‫server yang akan saya perlukan untuk lingkungan
‫tertentu, dan kemudian tingkat perubahan aplikasi saya,
‫atau lingkungan itu sendiri, dan penggandaan dari keduanya
‫benar-benar sama dengan manfaat orkestrasi.
‫Yang saya maksudkan adalah bahwa orkestrasi dirancang untuk mengotomatiskan
‫perubahan dan memonitor keadaan
‫segala sesuatunya dan memastikan semuanya adalah keadaan yang
‫Anda harapkan.
‫Misalnya, aplikasi berjalan dalam kondisi sehat.
‫Ketika Anda memulai, Anda
‫mungkin hanya perlu satu server, atau hanya
‫beberapa server, dan jika Anda tidak sering mengubah
‫aplikasi Anda, katakanlah Anda hanya mengubahnya sekali sebulan atau
‫kurang, maka orkestrasi, dan upaya yang terlibat dalam
‫penerapannya, mengelolanya, mengamankannya, mungkin tidak diperlukan
‫di negara Anda. Terutama jika Anda seorang pengembang
‫solo atau hanya tim yang sangat kecil.
‫Di situlah hal-hal seperti Elastic Beanstalk, atau Heroku,
‫platform penyebaran aplikasi, di situlah banyak dari
‫mereka mulai bersinar sebagai alternatif untuk melakukan
‫orkestrasi Anda sendiri.
‫Tentu saja, pertanyaan paling umum yang
‫saya dapatkan dari orang-orang begitu mereka tahu bahwa
‫mereka membutuhkan orkestrasi, adalah untuk memutuskan mana yang mereka inginkan.
‫Sungguh pada titik ini pada
‫2019, setidaknya ada dua atau tiga platform utama.
‫Jika Anda menyertakan solusi Cloud, mungkin ada empat atau lima
‫platform utama di sana.
‫Yang saya bicarakan dalam kursus ini adalah dua teratas
‫yang bekerja di mana-mana. Itu Swarm dan Kubernetes.
‫Kemudian Anda memiliki yang lain yang
‫khusus untuk platform Cloud,
‫seperti ECS, yang hanya pada AWS, dan penawaran yang
‫lebih tradisional yang telah ada sedikit
‫lebih lama seperti Cloud Foundry, atau Mesos dan Marathon.
‫Tapi saya pikir jika Anda seseorang
‫yang khawatir tentang menjalankan kontainer berdasarkan premis, dan
‫di Cloud, atau berpotensi multicloud, Anda mungkin tidak
‫ingin menggunakan penawaran khusus Cloud seperti ECS
‫karena ada di sekitar sebelum Kubernetes berada.
‫Jadi, itu semacam solusi warisan yang masih didukung Amazon
‫dan itu masih merupakan opsi yang rapi, tetapi hanya jika
‫Anda khusus untuk AWS dan itulah satu-satunya tempat Anda
‫berencana untuk menggunakan kontainer.
‫Untuk banyak pelanggan saya, dan untuk banyak
‫siswa saya, pilihannya biasanya, saya butuh sesuatu yang hybrid.
‫Berarti saya bisa menjalankannya di pusat data
‫saya atau di multicloud. Tidak bisa hanya
‫berjalan di satu lokasi saja. Itu biasanya turun ke Swarm
‫atau Kubernetes sebagai pilihan besar mereka karena itu
‫adalah dua solusi yang merupakan orkestra kontainer
‫paling populer.
‫Mereka berjalan di setiap cloud, dan di pusat data, dan
‫bahkan lingkungan kecil mungkin seperti IoT.
‫Jika Anda memutuskan Kubernetes sebagai orkestrator
‫Anda, keputusan besar berikutnya adalah distribusi mana yang
‫akan Anda gunakan.
‫Bagian pertama dari itu adalah mencari tahu apakah Anda
‫menginginkan solusi yang dikelola Cloud, atau
‫jika Anda ingin meluncurkan solusi Anda sendiri dengan produk
‫vendor yang akan Anda instal di server sendiri.
‫Distribusi umum yang didukung vendor yang pernah Anda
‫dengar saya bicarakan, termasuk Docker Enterprise dan
‫ada yang lain seperti Rancher OpenShift dari
‫Red Hat. Canonical, perusahaan Ubuntu, memiliki
‫versi sendiri.
‫VMware memiliki versi sendiri.
‫PKS juga.
‫Faktanya, ada begitu banyak solusi vendor
‫infrastruktur dan perusahaan perangkat lunak untuk Kubernet
‫sekarang sehingga sedikit berlebihan.
‫Saya akan memberi Anda tautan di sumber daya ke
‫daftar distribusi bersertifikat Kubernetes.
‫Anda ingin menggunakan salah satunya karena mereka
‫menjamin bahwa API dari Kubernetes digunakan secara langsung, dan
‫didukung penuh.
‫Sehingga kasus yang ideal adalah Anda dapat mengambil beban kerja
‫dan file YAML Anda yang mendesain infrastruktur Anda, dan Anda dapat
‫memindahkannya dari satu vendor Kubernetes ke yang
‫lain dan mereka harus bekerja di luar kotak untuk
‫sebagian besar hal.
‫Sekarang ada opsi lain yang baru saja saya
‫sebutkan di sini yaitu menggunakan versi upstream GitHub
‫dari Kubernetes.
‫Itulah yang menjadi dasar semua distribusi.
‫Misalnya, jika Anda melihat ke hulu dan Anda melihat
‫Kubernetes 1. 14 rilis.
‫Kemudian, ketika Anda melihat produk vendor,
‫Anda akan tertarik dengan versi Kubernet mana yang mereka dukung.
‫Biasanya, produk vendor ada beberapa versi di belakang, tetapi saat ini,
‫perlombaan adalah bahwa mereka semua tetap up
‫to date sebanyak mungkin.
‫Jadi, saya cenderung melihat mereka hanya satu versi yang paling
‫ketinggalan zaman.
‫Sekarang, hal yang Anda dapatkan
‫dari solusi vendor, selain hanya opsi dukungan
‫vendor itu, juga menggabungkan perangkat lain dengannya.
‫Salah satu hal tentang Kubernet yang
‫sedikit berbeda dari Swarm adalah bahwa ia
‫perlu banyak hal ditambahkan untuk benar-benar membuatnya mudah digunakan
‫di luar kotak. Jadi, Anda
‫mungkin, ketika Anda mendapatkan solusi vendor, akan melihat
‫hal-hal seperti solusi otentikasi kustom, administrasi Web kustom, dan
‫jaringan kustom, hanya untuk beberapa nama.
‫Saya umumnya akan merekomendasikan kepada Anda,
‫tanpa mengetahui persyaratan Anda, bahwa
‫Anda mungkin tidak memerlukan versi hulu murni
‫dari Kubernet GitHub.
‫Anda tidak perlu mengkloning repo Kubernet dan
‫menjalankannya.
‫Sekarang, itu bagus untuk belajar.
‫Bahkan, saya sarankan memulai dengan itu sebagai cara
‫untuk belajar Kubernet. Tapi, begitu Anda masuk
‫ke solusi vendor, itu semua akan sedikit
‫berbeda dengan keamanan, dan jaringan, dan hal-hal lainnya.
‫Jadi, akan sulit bagi Anda untuk belajar satu dan kemudian hanya berasumsi
‫bahwa yang lain bertindak dengan cara yang sama.
‫Namun, ketika Anda mulai berbicara tentang produksi, saya
‫berharap Anda akan mencoba menggunakan salah
‫satu solusi vendor tersebut terlebih dahulu karena mereka akan
‫lebih mudah dikelola. Anda akan memiliki opsi dukungan yang lebih baik.
‫Secara umum, hal-hal hanya akan bekerja lebih baik dan lebih cepat di luar
‫kotak.