⚫️ ☣️ 💕 "Ayo gunakan Kubernet!" Anda sekarang memiliki 8 masalah 👨🏿‍🎨 👩🏽‍🔧 😈

Jika Anda menggunakan Docker, langkah logis berikutnya tampaknya beralih ke Kubernetes, ini K8, kan? Yah, anggap saja. Namun, solusi yang dirancang untuk 500 insinyur perangkat lunak secara bersamaan mengembangkan satu aplikasi sangat berbeda dari solusi untuk 50 orang. Dan solusi untuk tim yang terdiri dari 5 programmer adalah cerita yang berbeda.

Jika Anda bekerja dalam tim kecil, Kubernetes kemungkinan besar bukan untuk Anda. Ini akan membawa Anda banyak rasa sakit dengan imbalan manfaat yang sangat sederhana.
Mari kita lihat mengapa ini bisa terjadi.

Semua orang suka "bagian yang bergerak"

Kubernetes banyak bergerak dan berubah: konsep, subsistem, proses, mesin, kode ... Dan semua ini berarti banyak kesulitan.

Beberapa mobil

Kubernetes adalah sistem terdistribusi: ia memiliki mesin host yang mengontrol sisanya, pekerja. Setiap mesin melakukan pekerjaan dalam wadah.
Jadi, kita sudah membicarakan setidaknya dua mesin fisik atau virtual, yang diperlukan hanya untuk membuatnya bekerja. Tetapi faktanya Anda mendapatkan ... hanya satu mobil. Jika Anda akan skala (di situlah anjing dimakamkan!), Anda akan membutuhkan tiga, empat, atau mungkin sebanyak tujuh belas mesin virtual.

Sangat, sangat banyak kode

Basis kode Kubernetes pada awal Maret 2020 mencakup lebih dari 580.000 baris kode on Go. Dan ini hanya kode bersih, tidak termasuk komentar, baris kosong, dan paket vendor. Tinjauan keamanan 2019 menggambarkan basis kode sebagai berikut:
“Basis kode Kubernetes memiliki ruang yang signifikan untuk perbaikan. Itu besar dan kompleks, berisi bagian kode yang besar dengan dokumentasi minimal dan sejumlah besar dependensi, termasuk sistem yang bukan bagian dari Kubernetes. Juga di basis kode ada banyak kasus penerapan kembali logika, yang dapat dipusatkan di perpustakaan pendukung, yang akan mengurangi kompleksitas, menyederhanakan koreksi dan mengurangi beban dokumen di berbagai bidang basis kode. "
Sejujurnya, hal yang sama dapat dikatakan tentang banyak proyek besar lainnya, tetapi semua kode ini harus berfungsi dengan benar jika Anda tidak ingin aplikasi Anda gagal.

Arsitektur, operasional, konfigurasi, dan kompleksitas konseptual

Kubernetes adalah sistem komprehensif dengan berbagai layanan, sistem, dan banyak lagi.
Sebelum Anda dapat meluncurkan satu-satunya aplikasi Anda, Anda harus menyediakan arsitektur berikut yang sangat disederhanakan (gambar asli diambil dari dokumentasi Kubernetes):

Dokumentasi konsep K8 mencakup banyak hal “pendidikan” murni, seperti cuplikan berikut:

In Kubernetes, an EndpointSlice contains references to a set of network endpoints. The EndpointSlice controller automatically creates EndpointSlices for a Kubernetes Service when a selector is specified. These EndpointSlices will include references to any Pods that match the Service selector. EndpointSlices group network endpoints together by unique Service and Port combinations.
By default, EndpointSlices managed by the EndpointSlice controller will have no more than 100 endpoints each. Below this scale, EndpointSlices should map 1:1 with Endpoints and Services and have similar performance.

Sebenarnya, saya mengerti tentang apa ini, tetapi perhatikan berapa banyak konsep yang perlu Anda pelajari: EndpointSlice, Layanan, pemilih, Pod, Endpoint.

Dan - ya, sebagian besar waktu Anda tidak akan menggunakan semua fitur ini. Karenanya, sebagian besar waktu Anda tidak memerlukan Kubernet sama sekali.

Berikut ini cuplikan singkat lain:

Secara default, lalu lintas yang dikirim ke Layanan ClusterIP atau NodePort dapat dialihkan ke alamat backend apa pun untuk Layanan. Sejak Kubernetes 1.7 dimungkinkan untuk merutekan lalu lintas "eksternal" ke Pods yang berjalan di Node yang menerima lalu lintas, tetapi ini tidak didukung untuk Layanan ClusterIP, dan topologi yang lebih kompleks - seperti routing secara zonal - belum dimungkinkan. Fitur Topologi Layanan menyelesaikan masalah ini dengan mengizinkan pembuat Layanan untuk menentukan kebijakan untuk merutekan lalu lintas berdasarkan label Node untuk Node asal dan tujuan.

Inilah yang dikatakan tinjauan Keamanan tentang ini:

Kubernetes — , . , Kubernetes — , , , .

Semakin banyak yang Anda dapatkan di Kubernetes, semakin sulit proses pengembangan menjadi: Anda membutuhkan semua konsep ini (Pod, Penempatan, Layanan, dll.) Hanya untuk membuat kode Anda berfungsi. Dengan demikian, Anda perlu mempromosikan sistem K8 lengkap, bahkan hanya untuk pengujian melalui mesin virtual atau wadah Docker bersarang.

Dan, karena aplikasi Anda menjadi lebih sulit untuk dijalankan secara lokal, pengembangan menjadi rumit oleh banyak opsi untuk menyelesaikan masalah ini, dari lingkungan bangku hingga proksi proses lokal ke sebuah kluster (saya menulis alat ini beberapa tahun yang lalu ) dan memproxy sebuah proses jarak jauh ke mesin lokal ...

Anda dapat pilih opsi apa saja, tetapi tidak ada yang sempurna. Cara termudah untuk tidak menggunakan Kubernetes sama sekali.

Layanan Mikro (ini adalah ide yang buruk)

Masalah kedua adalah karena sistem Anda memungkinkan Anda untuk menjalankan banyak layanan, Anda harus menulis banyak layanan ini. Ide buruk.
Aplikasi yang didistribusikan sulit untuk menulis. Bahkan , semakin banyak bagian yang bergerak, semakin banyak masalah ini mengganggu pekerjaan.

Aplikasi yang didistribusikan sulit untuk di-debug. Anda akan memerlukan alat debugging dan logging yang benar-benar baru, yang masih akan memberi Anda lebih sedikit daripada log aplikasi monolitik.

Microservices adalah salah satu teknik penskalaan dalam organisasi: ketika Anda memiliki 500 pengembang yang melayani satu situs web yang produktif, masuk akal untuk menanggung biaya sistem terdistribusi skala besar jika memungkinkan tim pengembangan untuk bekerja secara mandiri. Dengan demikian, setiap tim yang terdiri dari 5 orang menerima satu layanan mikro, dan berpura-pura bahwa semua layanan mikro lain adalah layanan eksternal yang tidak boleh Anda percayai.

Jika seluruh tim Anda terdiri dari 5 orang, Anda memiliki 20 layanan microser dan keadaan force majeure tidak memaksa Anda untuk membuat sistem terdistribusi, maka di suatu tempat Anda salah perhitungan. Alih-alih 5 orang per 1 layanan mikro, seperti di perusahaan besar, Anda mendapatkan 0,25 orang.

Apakah Kubernet sama sekali tidak berguna?

Scaling

Kubernet mungkin berguna jika Anda membutuhkan skalabilitas serius. Namun, mari kita lihat alternatif apa yang Anda miliki:

Anda dapat membeli VM di cloud, dan mereka akan memiliki hingga 416 CPU virtual dan 8 TB RAM, yaitu daya yang benar-benar tidak menarik. Anda akan dikenakan biaya yang sangat kecil, tetapi akan sangat mudah dilakukan.
Banyak aplikasi web sederhana dapat ditingkatkan dengan cara yang cukup mudah dengan layanan seperti Heroku.

Diasumsikan, tentu saja, bahwa peningkatan jumlah pekerja VM juga akan berperan:

Sebagian besar aplikasi tidak memerlukan penskalaan yang signifikan, mereka akan memiliki cukup optimasi berkualitas tinggi.
Hambatan untuk menskalakan sebagian besar aplikasi web adalah database, bukan pekerja web

Keandalan

Semakin banyak bagian yang bergerak, semakin besar potensi terjadinya kesalahan.
Kemampuan Kubernetes, dipertajam dengan meningkatnya keandalan (pemeriksaan kesehatan, penggelaran yang bergulir), dalam banyak kasus sudah dapat dibangun atau diterapkan dengan lebih mudah. Misalnya, nginx dapat melakukan pemeriksaan kesehatan pada proses pekerja, dan Anda juga dapat menggunakan docker-autoheal atau yang serupa untuk memulai kembali proses ini secara otomatis.

Jika Anda sangat khawatir tentang downtime, pikiran pertama yang akan mengunjungi Anda tidak boleh “bagaimana cara mengurangi downtime ketika menggunakan dari 1 detik menjadi 1 milidetik), tetapi itu harus“ bagaimana saya memastikan bahwa perubahan pada skema database memungkinkan rollback jika saya suatu tempat? "
Dan jika Anda membutuhkan pekerja web yang andal tanpa mesin tunggal sebagai titik kegagalan, ada banyak cara untuk mengimplementasikannya tanpa Kubernet.

Praktik terbaik?

Faktanya, tidak ada Praktik Terbaik yang ada di alam. Hanya ada praktik terbaik untuk setiap situasi tertentu. Karena itu, jika sesuatu sedang tren dan populer, ini tidak berarti bahwa itu adalah pilihan yang tepat untuk Anda secara khusus.
Dalam beberapa kasus, Kubernetes adalah pilihan terbaik. Sisanya adalah buang-buang waktu.

Kecuali jika Anda sangat membutuhkan semua kompleksitas ini, Anda memiliki banyak pilihan alat yang akan menyelesaikan masalah Anda: Docker Menulis untuk satu mesin, Nomad Hashicorp untuk orkestrasi, Heroku dan sistem serupa untuk penskalaan, dan sesuatu seperti Shakemake untuk menghitung jaringan pipa.

Kata penutup dari Editor

Sebagai penyedia cloud, kami secara rutin bertemu berbagai klien, dari startup kecil hingga organisasi besar dengan proses bisnis yang kompleks dan permintaan infrastruktur terkait. Terlepas dari seberapa bagus teknologi itu, akan selalu ada preseden di mana penerapannya akan menghasilkan kesulitan yang tidak perlu. Anda harus selalu melanjutkan dari situasi dan hati-hati mempertimbangkan pro dan kontra dari opsi yang tersedia. Penulis artikel agak mengental warnanya, tetapi pesannya cukup jelas: kadang-kadang, untuk membuat keputusan yang tepat, ada baiknya berpaling dari tren dan mengevaluasi proyek Anda. Ini akan menghemat kekuatan pengembang, dan penggunaan sumber daya perusahaan akan membuatnya lebih tepat.

"Ayo gunakan Kubernet!" Anda sekarang memiliki 8 masalah