Phenquestions
Apa itu Kubernetes?? Dan apa arsitekturnya??
Kontainerisasi telah memutuskan hubungan antara pengembang perangkat lunak dan lingkungan produksi. Bukan dalam artian Anda tidak memerlukan sistem produksi sama sekali, tetapi Anda tidak perlu khawatir dengan kekhususan lingkungan produksi.
Aplikasi sekarang dibundel dengan dependensi yang mereka butuhkan, dalam wadah yang ringan, bukan VM. Itu hebat! Namun, itu tidak memberikan kekebalan dari kegagalan sistem, kegagalan jaringan, atau kegagalan disk. Misalnya, jika pusat data, tempat server Anda berjalan, sedang dalam pemeliharaan, aplikasi Anda akan offline.
Kubernetes hadir untuk memecahkan masalah ini. Dibutuhkan ide wadah dan memperluasnya untuk bekerja di beberapa node komputasi (yang bisa berupa mesin virtual yang dihosting cloud atau server bare metal). Idenya adalah untuk memiliki sistem terdistribusi untuk aplikasi kemas untuk berjalan di.
Mengapa Kubernetes?
Sekarang, mengapa Anda harus memiliki lingkungan terdistribusi sejak awal??
Untuk berbagai alasan, pertama dan terpenting adalah ketersediaan tinggi. Anda ingin situs web e-commerce Anda tetap online 24/7, atau Anda akan kehilangan bisnis, gunakan Kubernetes untuk itu. Kedua adalah skalabilitas, di mana Anda ingin menskalakan 'keluar'. Penskalaan di sini melibatkan penambahan lebih banyak node komputasi untuk memberi aplikasi Anda lebih banyak ruang kaki untuk beroperasi.
Desain dan Arsitektur
Seperti sistem terdistribusi lainnya, cluster Kubernetes memiliki node master dan kemudian banyak node pekerja yang merupakan tempat aplikasi Anda akan benar-benar berjalan. Master bertanggung jawab untuk menjadwalkan tugas, mengelola beban kerja, dan menambahkan node baru ke cluster dengan aman.
Sekarang, tentu saja, master node itu sendiri dapat gagal dan membawa seluruh cluster bersamanya, jadi Kubernetes sebenarnya memungkinkan Anda untuk memiliki beberapa master node demi redundansi.
Pandangan sekilas tentang penyebaran Kubernetes yang khas
Master Kubernetes
Master Kubernetes adalah tempat tim DevOps berinteraksi dan digunakan untuk menyediakan node baru, menerapkan aplikasi baru, serta pemantauan dan pengelolaan sumber daya. Tugas paling dasar dari master node adalah untuk susunan acara beban kerja secara efisien di antara semua node pekerja untuk memaksimalkan pemanfaatan sumber daya, meningkatkan kinerja, dan, mengikuti berbagai kebijakan yang dipilih oleh tim DevOps untuk beban kerja khusus mereka.
Komponen penting lainnya adalah dll yang merupakan daemon yang melacak node pekerja dan menyimpan database yang menyimpan seluruh status cluster. Ini adalah penyimpanan data nilai kunci, yang juga dapat berjalan pada lingkungan terdistribusi di beberapa node master. Konten etcd memberikan semua data yang relevan tentang seluruh cluster. Sebuah node pekerja akan melihat isi etcd dari waktu ke waktu untuk menentukan bagaimana seharusnya berperilaku.
Pengontrol adalah entitas yang akan mengambil instruksi dari server API (yang akan kita bahas nanti) dan melakukan tindakan yang diperlukan seperti pembuatan, penghapusan, dan pembaruan aplikasi dan paket.
Itu Server API mengekspos Kubernetes API, yang menggunakan muatan JSON melalui HTTPS, untuk berkomunikasi dengan antarmuka pengguna yang pada akhirnya akan berinteraksi dengan tim pengembang atau personel DevOps. UI web dan CLI menggunakan API ini untuk berinteraksi dengan cluster Kubernetes.
Server API juga bertanggung jawab untuk komunikasi antara node pekerja dan berbagai komponen master node seperti etcd.
Node Master tidak pernah diekspos ke pengguna akhir karena akan membahayakan keamanan seluruh cluster.
Node Kubernetes
Sebuah mesin (fisik atau virtual) akan membutuhkan beberapa komponen penting yang setelah diinstal dan diatur dengan benar kemudian dapat mengubah server tersebut menjadi anggota cluster Kubernetes Anda.
Hal pertama yang Anda perlukan adalah runtime kontainer, seperti Docker, diinstal dan dijalankan di atasnya. Itu akan bertanggung jawab untuk memutar dan mengelola kontainer, tentu saja.
Seiring dengan runtime Docker, kami juga membutuhkan kubelet daemon. Ini berkomunikasi dengan node master, melalui server API dan menanyakan etcd, dan memberikan kembali informasi kesehatan dan penggunaan tentang pod yang berjalan pada node tersebut.
Namun container itu sendiri sangat terbatas, sehingga Kubernetes memiliki abstraksi yang lebih tinggi yang dibangun di atas kumpulan container, yang dikenal sebagai Polong.
Mengapa datang dengan pod?
Docker memiliki kebijakan menjalankan satu aplikasi per kontainer. Sering digambarkan sebagai “satu proses per kontainer” kebijakan. Ini berarti jika Anda memerlukan situs WordPress, Anda dianjurkan untuk memiliki dua wadah satu untuk database untuk dijalankan dan satu lagi untuk server web untuk dijalankan. Menggabungkan komponen aplikasi yang terkait seperti itu ke dalam pod memastikan bahwa setiap kali Anda melakukan scale out, dua container yang saling bergantung selalu ada pada node yang sama, dan dengan demikian saling berbicara dengan cepat dan mudah.
Pod adalah unit dasar penerapan di Kubernetes. Saat Anda menskalakan, Anda menambahkan lebih banyak pod ke kluster. Setiap pod diberikan alamat IP uniknya sendiri di dalam jaringan internal cluster.
Kembali ke Node Kubernetes
Sekarang sebuah node dapat menjalankan banyak pod dan mungkin ada banyak node seperti itu. Ini semua baik-baik saja sampai Anda berpikir untuk mencoba berkomunikasi dengan dunia luar. Jika Anda memiliki layanan berbasis web sederhana, bagaimana Anda mengarahkan nama domain Anda ke kumpulan pod ini dengan banyak alamat IP??
Anda tidak bisa, dan Anda tidak harus! Kube-proksi adalah bagian terakhir dari teka-teki yang memungkinkan operator untuk mengekspos pod tertentu ke Internet. Misalnya, front-end Anda dapat diakses secara publik dan kube-proxy akan mendistribusikan lalu lintas di antara semua berbagai pod yang bertanggung jawab untuk menghosting front end. Namun, database Anda tidak perlu dipublikasikan dan kube-proxy hanya mengizinkan komunikasi internal untuk beban kerja terkait back-end tersebut.
Apakah Anda membutuhkan semua ini??
Jika Anda baru memulai sebagai penghobi atau pelajar, menggunakan Kubernetes untuk aplikasi sederhana sebenarnya tidak efisien. Seluruh omong kosong akan menghabiskan lebih banyak sumber daya daripada aplikasi Anda yang sebenarnya dan akan menambah lebih banyak kebingungan untuk satu individu.
Namun, jika Anda akan bekerja dengan tim besar dan menerapkan aplikasi Anda untuk penggunaan komersial yang serius, Kubernetes layak untuk biaya tambahan. Anda dapat menghentikan hal-hal agar tidak kacau. Berikan ruang untuk pemeliharaan tanpa waktu henti down. Siapkan kondisi pengujian A/B yang bagus dan skalakan secara bertahap tanpa menghabiskan terlalu banyak biaya untuk infrastruktur di awal.
