‫Kubernet atau Swarm.
‫Itu salah satu pertanyaan paling populer yang saya dapatkan setelah seseorang
‫cukup belajar tentang orkestrasi untuk kemudian ingin membuat keputusan tentang yang
‫mana yang akan digunakan.
‫Saya akan merekomendasikan agar Anda pertama kali
‫menonton video di Swarm, terutama video
‫pertama itu. Itu
‫Swarm Mode Built-in Orchestration karena sekali lagi, itu
‫akan memberi Anda latar belakang mengapa orkestrasi diperlukan
‫untuk menyelesaikan masalah tertentu. Lalu tonton juga video
‫sebelumnya di bagian ini tentang Kubernetes sehingga Anda
‫memahami latar belakang kedua alat sebelum kami
‫melanjutkan. Sebagai garis dasar di sini,
‫keduanya adalah alat yang memecahkan masalah serupa. Keduanya adalah orkestra wadah
‫yang berjalan di
‫atas runtime wadah.
‫Dalam seri video ini, Anda telah mempelajari tentang
‫runtime container Docker.
‫Ada yang lain sekarang, containerd dan CRI-O.
‫Sungguh, Docker adalah # 1.
‫Ini digunakan di hampir setiap kasus.
‫Keduanya didukung oleh vendor dan tim
‫orang yang mengerjakan produk.
‫Secara umum, jika saya harus membuat
‫tweet untuk membandingkan keduanya, itu hanya akan membuat Swarm mudah dibuat, mudah
‫untuk menambahkan node, mudah untuk memulai, dan
‫mudah untuk dikelola. Jadi, mudah jelas merupakan
‫hal yang harus saya katakan untuk Swarm.
‫Tapi, itu tidak menyelesaikan semua kasus
‫penggunaan di mana Kubernetes memiliki lebih banyak fungsi,
‫fleksibilitas, dan penyesuaian. Ini dapat memecahkan lebih banyak masalah,
‫dengan lebih banyak cara, dan juga umumnya memiliki adopsi dan dukungan
‫yang lebih luas.
‫Untuk Anda, untuk membantu Anda memutuskan mana
‫yang ingin Anda gunakan, kami akan membahas
‫beberapa kelebihan masing-masing. Saya pikir ini penting, sungguh,
‫bagi kita semua jika Anda akan berada di komunitas DevOps dan
‫menggunakan alat-alat ini untuk menyelesaikan masalah bisnis, Anda
‫harus tahu keduanya.
‫Anda harus dapat menginstal keduanya dan kemudian
‫menggunakan aplikasi pada keduanya, dan mengetahui
‫beberapa fungsi dasar di sekitar penerapan aplikasi, membuat opsi
‫Ingress untuk lalu lintas masuk, dan kemudian
‫memperbarui aplikasi tersebut. Saya pikir itu
‫saja akan membuat Anda cukup terbiasa dengan alat sehingga Anda tahu
‫mana yang harus digunakan untuk memecahkan masalah yang mana.
‫Ada banyak keuntungan untuk masing-masing.
‫Mari kita hancurkan ini sangat cepat. Di sisi
‫Swarm, karena Anda telah belajar selama kursus ini,
‫ia datang dengan Docker. Jadi, ini adalah solusi tunggal yang didukung vendor.
‫Yang berarti bahwa runtime kontainer, dan orkestra,
‫dibangun oleh perusahaan yang sama.
‫Itu menuai banyak penghargaan, termasuk kompleksitas yang lebih sedikit, penggunaan sumber
‫daya yang lebih kecil hanya
‫untuk menjalankannya. Menjalankan Swarm memiliki pemanfaatan
‫sumber daya yang sangat sedikit di atas Docker.
‫Ini dirancang dengan alur kerja pengembang
‫dalam pikiran. Jadi, ini sangat
‫baik untuk digunakan oleh Ops dan pengembang. Seperti saya katakan,
‫mudah untuk menggunakan dan mengelola orkestra jenis ini.
‫Ini dapat dengan mudah tumbuh hingga ratusan, jika
‫tidak ribuan, node, dan Anda tidak perlu
‫tim besar untuk mengelolanya. Anda
‫mungkin mengatakan bahwa itu mengikuti aturan 80/20, di mana
‫ia memiliki 20% fitur Kubernetes, dan itu memecahkan 80%
‫kasus penggunaan untuk menjalankan wadah
‫dan orkestrasi.
‫Nah, itu bukan perbandingan ilmiah.
‫Saya tidak benar-benar tahu nomor fitur yang tepat. Saya tidak
‫tahu bagaimana Anda benar-benar melakukannya.
‫Tapi, sepertinya itulah yang dirasakan ketika Anda menjalankan keduanya bahwa Anda
‫menyadari bahwa Swarm memecahkan sebagian besar kasus penggunaan
‫untuk menjalankan aplikasi web solusi berjalan lama di server,
‫baik itu di Cloud atau pusat data, atau bahkan pada
‫perangkat kecil. Tampaknya bekerja dengan baik di
‫luar kotak. Ini memiliki apa yang Anda butuhkan. Ini
‫memiliki jaringan. Itu memiliki Ingress. Ia memiliki enkripsi.
‫Semua itu. Memiliki basis data.
‫Jadi, out-of-the-box, itu benar-benar menyelesaikan banyak masalah.
‫Tapi, itu tidak menyelesaikan semua kasus penggunaan, untuk semua skenario, untuk menjalankan aplikasi
‫pada mesin.
‫Di situlah Kubernetes bisa mengisi kekosongan.
‫Keuntungan besar lainnya adalah ini beroperasi di
‫mana pun Docker beroperasi. Docker Engine, yang berusia
‫enam tahun sekarang dan merupakan awal dari revolusi kontainer keseluruhan,
‫Engine berjalan di lebih banyak tempat daripada perkakas lainnya.
‫Itu berjalan tidak hanya di Linux, itu berjalan di Windows.
‫Ini berjalan pada Mainframe.
‫Ini berjalan pada perangkat ARM, yang
‫berarti Tertanam, IoT, Raspberry Pis.
‫Ini berjalan pada ARM lama, ARM baru, 32
‫bit, 64 bit. Seperti yang saya katakan, itu hanya semua tempat.
‫Ini berjalan secara native di Windows Server selama
‫bertahun-tahun sekarang sejak Server 2016.
‫Jadi, itu pasti adalah orkestra terpanjang yang didukung
‫untuk lingkungan multi-arsitektur yang beragam, jika itu
‫kebutuhan Anda.
‫Out-of-the-box, aman, dan Anda pernah mendengar
‫saya berbicara tentang itu dalam kursus ini,
‫bahwa ketika Anda membuat Swarm dan Anda menambahkan node, itu
‫memastikan otentikasi Telus bersama. Ini mengenkripsi bidang kontrol dan mengenkripsi
‫basis data untuk melindungi rahasia Anda jika
‫Anda ingin menyimpannya.
‫Itu bagus karena saya menemukan banyak tim, ketika mereka
‫diburu tenggat waktu
‫atau mungkin mereka sedikit kewalahan dengan
‫kerumitan, cenderung melupakan atau melewatkan beberapa persyaratan keamanan yang dibutuhkan
‫alat lain seperti Kubernetes. Terakhir di sini, saya percaya
‫lebih mudah untuk memecahkan masalah karena ada sedikit bagian yang
‫bergerak dengannya. Ada sedikit hal untuk dikelola.
‫Karena bawaannya adalah Docker, jika Anda tahu cara
‫memecahkan masalah Docker, maka Anda mungkin tahu cara
‫memecahkan masalah Swarm.
‫Ia menggunakan log daemon yang sama. Ini menggunakan perintah log
‫Docker yang sama untuk aplikasi. Ia menggunakan perintah Docker events
‫yang sama untuk melihat peristiwa pada node dan Swarm itu
‫sendiri. Sekarang kedengarannya seperti
‫banyak keuntungan bagi Swarm, tetapi saya tidak ingin Anda berpikir bahwa
‫itu akan selalu menjadi hal yang tepat untuk
‫Anda.
‫Secara umum, Swarm adalah alat yang saya rekomendasikan ketika orang
‫mulai dan mereka mulai dari kecil.
‫Mungkin mereka satu orang, atau hanya satu, dua,
‫atau tiga orang dalam tim mereka, dan mereka perlu
‫melihat apakah orkestra kecil yang sederhana akan
‫bekerja untuk mereka. Saya selalu merekomendasikan Swarm terlebih
‫dahulu, kecuali jika Anda benar-benar tahu Anda harus menggunakan
‫Kubernetes, saya merekomendasikan Swarm. Setelah Anda berpikir Anda telah
‫mencapai batas di Swarm dan Anda berpikir bahwa Anda tidak bisa mendapatkan apa
‫yang Anda butuhkan darinya, saat itulah saatnya
‫untuk melihat Kubernetes.
‫Mari kita bicara tentang beberapa keuntungan itu sekarang.
‫Pertama, cloud dan vendor itu sangat suka
‫mendukung Kubernetes. Karena telah menjadi sangat
‫populer, dan terutama semacam popularitas jenis zeitgeist dalam berita
‫dan media, itu adalah sesuatu yang
‫setiap vendor sekarang cari untuk memeriksa daftar
‫kami mendukung Kubernetes.
‫Jadi, saya akan mengatakan itu benar-benar memiliki dukungan cloud dan
‫vendor terluas.
‫Setiap vendor cloud menyediakan penawaran Kubernetes, jadi jika Anda
‫tidak ingin menjalankannya sendiri, Anda bisa membiarkan mereka memulai
‫semua sistem dan kemudian Anda pada
‫dasarnya hanya menjalankan aplikasi Anda di sana menggunakan
‫file penyebaran Kubernetes. Bahkan vendor infrastruktur
‫sekarang memiliki distribusi Kubernet mereka sendiri termasuk VMware,
‫Red Hat. Bahkan perusahaan seperti
‫Netflix, yang secara tradisional hanya vendor penyimpanan, memiliki
‫versi atau distribusi Kubernetes yang disetujui sendiri.
‫Jadi hal yang jelas di sini adalah
‫adopsi dan dukungan terluas, dan itu benar adanya.
‫Namun di luar itu, ia juga memiliki set kasus penggunaan yang
‫paling luas. Karena
‫memiliki begitu banyak hal untuk beralih dan bermain-main, dan
‫begitu banyak fitur yang berbeda dan
‫opsi pihak ketiga, itu pasti mencakup lebih banyak
‫kasus tepi daripada Swarm. Bahkan, Anda akan mulai melihat
‫ini dengan vendor yang mungkin sudah Anda kerjakan hari
‫ini di mana mereka akan melakukan dukungan
‫pertama Kubernetes, yang merupakan cara saya mengatakan bahwa vendor akan melihat
‫bagaimana mereka dapat mendukung Kubernetes dengan produk mereka sebelum mereka repot-repot untuk pergi
‫melihat produk Swarm Docker.
‫Terutama karena karena industri semacam ini dalam sikap
‫segala sesuatu yang perlu
‫mendukung Kubernetes, Anda akan menemukan bahwa vendor yang sudah
‫Anda miliki mungkin sudah memiliki distribusi, atau solusi, untuk
‫menjalankan alat mereka di Kubernetes. Misalnya, dengan Jenkins, dari
‫perusahaan CloudBees.
‫Jika Anda telah membeli solusi Enterprise mereka, mereka
‫memberi Anda alat Kubernetes dan sampel tentang cara menjalankannya.
‫Itu tidak berarti Anda tidak dapat menjalankan Jenkins di Swarm.
‫Ini berjalan hebat di sana.
‫Itu hanya berarti bahwa Anda akan mendapatkan dukungan yang lebih baik
‫dari vendor untuk itu.
‫Keuntungan terakhir yang akan saya sebutkan di sini
‫adalah semacam keuntungan aneh. Saya akan muntah istilah ini
‫yang tidak ada yang dipecat karena membeli IBM.
‫Sekarang pepatah ini populer beberapa dekade yang lalu
‫ketika IBM adalah vendor terbesar untuk komputasi dan outsourcing
‫perangkat keras Anda, dan mainframe Anda, dan PC Anda,
‫dan ada sepanjang waktu di mana mereka
‫benar-benar membunuhnya di pasar.
‫Intinya, jika Anda tidak bisa memutuskan vendor mana
‫yang ingin Anda tuju. Jika Anda pergi dengan
‫cara yang aman, Anda akan pergi dengan IBM.
‫Anda tidak akan pernah benar-benar dipecat karena itu
‫adalah vendor tepercaya saat itu.
‫Saya akan mengatakan bahwa, secara umum, untuk platform Kubernetes
‫secara keseluruhan, yang telah menjadi kasus sekarang.
‫Saya berpendapat bahkan sudah sampai pada titik menjadi item
‫check off untuk CIO dan CTO.
‫Itu bisa menjadi sedikit baik dan buruk, karena itu
‫bisa berarti bahwa Anda akan diminta untuk menjalankan Kubernetes meskipun
‫Anda belum memiliki persyaratan teknis.
‫Anda baru saja diberitahu oleh manajemen Anda bahwa kami
‫perlu menjalankan Kubernetes. Bagi mereka, itu mungkin
‫hanya sesuatu yang ingin mereka jalankan terlepas dari apa persyaratan
‫teknis, atau manfaatnya, atau membandingkannya dengan platform yang berbeda.
‫Itu jelas merupakan bagian dari dunia politik ini
‫di mana keputusan TI tidak selalu dibuat berdasarkan kemampuan
‫atau persyaratan teknis semata.
‫Sering kali bisa dengan kemudahan
‫penggunaan membelinya. Dengan kata lain, jika
‫Anda sudah memiliki vendor yang memilikinya, Anda mungkin hanya menggunakan produk mereka
‫daripada yang lain karena lebih mudah.
‫O, r pengalaman tim Anda di latar belakang mungkin memiliki
‫pengalaman yang lebih baik dari pekerjaan atau proyek sebelumnya.
‫Jadi, Anda hanya akan menggunakan yang itu karena
‫seseorang sudah mengetahuinya. Atau, mungkin Anda akan membelinya
‫karena sayangnya, manajemen Anda membaca majalah, atau membaca Internet, dan
‫Internet mengatakan kepada mereka bahwa mereka perlu memilih
‫produk tertentu seperti Kubernetes.
‫Jadi, itulah yang mereka sarankan untuk Anda gunakan.
‫Bahkan, ketika saya melakukan lokakarya langsung dan saya bertanya kepada
‫orang-orang mengapa mereka memilih orkestra yang mereka jalankan, jawaban paling
‫umum yang saya dapatkan dari mereka, sayangnya, tetap, bos saya mengatakan kepada
‫saya untuk melakukan ini.
‫Jadi, orang tidak selalu mendapatkan suara dalam apa yang mereka jalankan,
‫itulah sebabnya saya mencoba untuk memberi Anda keseimbangan yang baik
‫dari alat dan fitur dari keduanya sehingga Anda akan menjadi orang yang
‫paling berpendidikan dalam tim Anda dan menjadi dapat
‫membantu mereka dengan persyaratan teknis yang sebenarnya dan membantu Anda membuat keputusan terbaik.