Gadis menaiki skuter. Ilustrasi , logo Nomad daripada
Kubernetes ialah gorila 300 paun orkestrasi kontena. Ia berfungsi dalam beberapa sistem kontena terbesar di dunia, tetapi mahal.
Sangat mahal untuk pasukan yang lebih kecil, yang memerlukan banyak masa sokongan dan keluk pembelajaran yang curam. Ini terlalu banyak overhead untuk pasukan kami yang terdiri daripada empat orang. Jadi kami mula mencari alternatif - dan jatuh cinta .
Apa yang kamu mahu
Pasukan kami menyokong beberapa perkhidmatan pemantauan dan analisis prestasi biasa: titik akhir API untuk metrik yang ditulis dalam Go, eksport Prometheus, penghurai log seperti Logstash dan , serta pangkalan data seperti InfluxDB atau Elasticsearch. Setiap perkhidmatan ini berjalan dalam bekasnya sendiri. Kami memerlukan sistem yang mudah untuk memastikan semuanya berjalan.
Kami bermula dengan senarai keperluan untuk orkestrasi kontena:
- Menjalankan satu set perkhidmatan pada banyak mesin.
- Gambaran keseluruhan perkhidmatan yang dijalankan.
- Pautan antara perkhidmatan.
- Mulakan semula automatik jika perkhidmatan tidak berfungsi.
- Penyelenggaraan infrastruktur oleh pasukan kecil.
Di samping itu, perkara berikut akan menjadi bagus, tetapi penambahan tidak diperlukan:
- Menandai mesin berdasarkan keupayaannya (contohnya, menandai mesin dengan cakera pantas untuk perkhidmatan I/O berat).
- Keupayaan untuk menjalankan perkhidmatan secara bebas daripada orkestra (contohnya, semasa pembangunan).
- Tempat biasa untuk berkongsi konfigurasi dan rahsia.
- Titik akhir untuk metrik dan log.
Mengapa Kubernetes tidak sesuai untuk kami
Semasa membuat prototaip dengan Kubernetes, kami mendapati bahawa kami menambah lapisan logik yang semakin kompleks yang sangat kami harapkan.
Sebagai contoh, Kubernetes menyokong konfigurasi perkhidmatan terbina dalam melalui . Anda boleh cepat keliru, terutamanya apabila menggabungkan berbilang fail konfigurasi atau menambahkan perkhidmatan tambahan pada pod. Kubernetes (atau dalam kes ini) membolehkan anda melaksanakan konfigurasi luaran secara dinamik untuk memisahkan kebimbangan. Tetapi ini menghasilkan gandingan yang ketat dan tersembunyi antara projek anda dan Kubernetes. Walau bagaimanapun, Helm dan ConfigMaps ialah pilihan tambahan, jadi anda tidak perlu menggunakannya. Anda hanya boleh menyalin konfigurasi ke dalam imej Docker. Walau bagaimanapun, tergoda untuk pergi ke laluan ini dan membina abstraksi yang tidak perlu yang mungkin anda menyesal kemudian.
Selain itu, ekosistem Kubernetes sedang berkembang pesat. Ia memerlukan banyak masa dan tenaga untuk mengikuti perkembangan terkini dengan amalan terbaik dan alatan terkini. Kubectl, minikube, kubeadm, helm, tiller, kops, oc - senarai berterusan dan seterusnya. Tidak semua alat ini diperlukan semasa anda bermula, tetapi anda tidak tahu apa yang anda perlukan, jadi anda perlu mengetahui segala-galanya. Disebabkan ini, keluk pembelajaran agak curam.
Bila hendak menggunakan Kubernetes
Di syarikat kami, ramai orang menggunakan Kubernetes dan cukup gembira dengannya. Kejadian ini diuruskan oleh Google atau Amazon, yang mempunyai sumber untuk menyokongnya.
Kubernetes disertakan , yang menjadikan orkestrasi kontena pada skala lebih mudah diurus:
- Terperinci .
- tambah logik kepada kelompok. Ini hanyalah program yang bercakap dengan API Kubernetes.
- ! Kubernetes boleh menskalakan perkhidmatan atas permintaan menggunakan metrik perkhidmatan dan tanpa memerlukan campur tangan manual.
Persoalannya ialah sama ada anda benar-benar memerlukan semua ciri ini. Anda tidak boleh hanya bergantung pada abstraksi; .
Pasukan kami menyediakan kebanyakan perkhidmatan dari jauh (disebabkan sambungan rapat ke infrastruktur utama), jadi kami tidak mahu meningkatkan kluster Kubernetes kami sendiri. Kami hanya mahu memberikan perkhidmatan.
Bateri tidak disertakan
Nomad ialah 20% daripada orkestrasi yang menyediakan 80% daripada apa yang diperlukan. Apa yang dilakukannya ialah mengurus penempatan. Nomad menjaga penempatan, memulakan semula bekas sekiranya berlaku ralat... dan itu sahaja.
Keseluruhan perkara Nomad adalah apa yang dilakukannya minimum: tiada pengurusan hak berbutir atau , ini direka khas. Komponen ini disediakan secara luaran atau tidak sama sekali.
Saya rasa Nomad telah menemui kompromi yang sempurna antara kemudahan penggunaan dan utiliti. Ia bagus untuk perkhidmatan kecil dan bebas. Jika anda memerlukan lebih kawalan, anda perlu menaikkannya sendiri atau menggunakan pendekatan yang berbeza. Nomad adalah hanya orkestra.
Perkara terbaik tentang Nomad ialah ia mudah menggantikan. Hampir tiada sambungan kepada vendor, kerana fungsinya mudah disepadukan ke dalam mana-mana sistem lain yang menguruskan perkhidmatan. Ia hanya berjalan seperti binari biasa pada setiap mesin dalam kelompok, itu sahaja!
Ekosistem nomad komponen yang digandingkan secara longgar
Kekuatan sebenar Nomad ialah ekosistemnya. Ia berintegrasi dengan baik dengan produk lain - sepenuhnya pilihan - seperti (kedai nilai kunci) atau (rahsia pemprosesan). Di dalam fail Nomad terdapat bahagian untuk mengekstrak data daripada perkhidmatan ini:
template {
data = <<EOH
LOG_LEVEL="{{key "service/geo-api/log-verbosity"}}"
API_KEY="{{with secret "secret/geo-api-key"}}{{.Data.value}}{{end}}"
EOH
destination = "secrets/file.env"
env = true
}
Di sini kita membaca kuncinya service/geo-api/log-verbosity daripada Konsul dan semasa bekerja kami mendedahkannya kepada pembolehubah persekitaran LOG_LEVEL. Kami juga membentangkan kunci secret/geo-api-key daripada Vault sebagai API_KEY. Mudah tetapi berkuasa!
Disebabkan kesederhanaannya, Nomad mudah diperluaskan dengan perkhidmatan lain melalui API. Sebagai contoh, teg untuk tugasan disokong. Kami menandakan semua perkhidmatan dengan metrik trv-metrics. Dengan cara ini Prometheus boleh mencari perkhidmatan ini dengan mudah melalui Konsul dan menyemak titik akhir secara berkala /metrics untuk data baharu. Perkara yang sama boleh dilakukan, sebagai contoh, untuk log, menggunakan .
Terdapat banyak contoh lanjutan yang lain:
- Jalankan tugas Jenkins menggunakan cangkuk dan Konsul memantau penempatan semula tugas Nomad apabila konfigurasi perkhidmatan berubah.
- Ceph menambah sistem fail yang diedarkan ke Nomad.
- untuk pengimbangan beban.
Semua ini membolehkan tanpa sebarang sambungan khas kepada vendor.
Amaran yang adil
Tiada sistem yang sempurna. Saya tidak mengesyorkan agar segera memperkenalkan ciri terbaharu ke dalam pengeluaran. Sudah tentu terdapat pepijat dan ciri yang hilang, tetapi perkara yang sama berlaku untuk Kubernetes.
Berbanding dengan Kubernetes, komuniti Nomad tidaklah begitu besar. Kubernetes sudah mempunyai kira-kira 75 komitmen dan 000 penyumbang, manakala Nomad mempunyai kira-kira 2000 komitmen dan 14 penyumbang. Nomad akan menghadapi kesukaran untuk mengikuti kelajuan Kubernetes, tetapi mungkin ia tidak perlu! Ia adalah sistem yang lebih khusus, dan komuniti yang lebih kecil juga bermakna permintaan tarik anda lebih berkemungkinan diperhatikan dan diterima, berbanding dengan Kubernetes.
Ringkasan
Intinya: Jangan gunakan Kubernetes hanya kerana orang lain melakukannya. Nilai keperluan anda dengan teliti dan semak alat mana yang lebih berfaedah.
Jika anda merancang untuk menggunakan satu tan perkhidmatan homogen pada infrastruktur berskala besar, maka Kubernetes ialah pilihan yang baik. Hanya sedar tentang kerumitan tambahan dan kos operasi. Sesetengah kos boleh dielakkan dengan menggunakan persekitaran Kubernetes terurus seperti atau .
Jika anda hanya mencari orkestra yang boleh dipercayai yang mudah diselenggara dan boleh dikembangkan, mengapa tidak mencuba Nomad? Anda mungkin terkejut sejauh mana ini akan membawa anda.
Jika Kubernetes dibandingkan dengan kereta, Nomad akan menjadi skuter. Kadang-kadang anda memerlukan satu perkara dan kadang-kadang anda memerlukan yang lain. Kedua-duanya mempunyai hak untuk wujud.
Sumber: www.habr.com