Gadis dengan skuter. Ilustrasi , logo pengembara dari
Kubernetes adalah gorila orkestrasi kontainer seberat 300 pon. Ia bekerja di beberapa sistem kontainer terbesar di dunia, namun mahal.
Sangat mahal untuk tim yang lebih kecil, yang memerlukan banyak waktu dukungan dan kurva pembelajaran yang curam. Ini terlalu berlebihan untuk tim kami yang beranggotakan empat orang. Jadi kami mulai mencari alternatif - dan jatuh cinta padanya .
Apa yang kamu inginkan
Tim kami mendukung sejumlah layanan pemantauan dan analisis kinerja umum: titik akhir API untuk metrik yang ditulis dalam Go, ekspor Prometheus, pengurai log seperti Logstash dan , serta database seperti InfluxDB atau Elasticsearch. Masing-masing layanan ini berjalan dalam wadahnya sendiri. Kami membutuhkan sistem yang sederhana agar semuanya tetap berjalan.
Kami memulai dengan daftar persyaratan untuk orkestrasi container:
- Menjalankan serangkaian layanan di banyak mesin.
- Ikhtisar layanan yang berjalan.
- Tautan antar layanan.
- Mulai ulang otomatis jika layanan turun.
- Pemeliharaan infrastruktur oleh tim kecil.
Selain itu, hal-hal berikut akan menjadi tambahan yang bagus, tetapi tidak diperlukan:
- Menandai mesin berdasarkan kemampuannya (misalnya, menandai mesin dengan disk cepat untuk layanan I/O berat).
- Kemampuan untuk menjalankan layanan secara independen dari orkestrator (misalnya, selama pengembangan).
- Tempat umum untuk berbagi konfigurasi dan rahasia.
- Titik akhir untuk metrik dan log.
Mengapa Kubernetes tidak cocok untuk kami
Saat kami membuat prototipe dengan Kubernetes, kami menyadari bahwa kami menambahkan lapisan logika yang semakin kompleks yang sangat kami andalkan.
Sebagai contoh, Kubernetes mendukung konfigurasi layanan bawaan melalui . Anda dapat dengan cepat menjadi bingung, terutama saat menggabungkan beberapa file konfigurasi atau menambahkan layanan tambahan ke sebuah pod. Kubernetes (atau dalam hal ini) memungkinkan Anda menerapkan konfigurasi eksternal secara dinamis untuk memisahkan masalah. Namun hal ini menghasilkan hubungan yang erat dan tersembunyi antara proyek Anda dan Kubernetes. Namun, Helm dan ConfigMaps merupakan opsi tambahan, jadi Anda tidak perlu menggunakannya. Anda cukup menyalin konfigurasi ke image Docker. Namun, Anda tergoda untuk mengambil jalan ini dan membangun abstraksi yang tidak perlu yang mungkin Anda sesali di kemudian hari.
Selain itu, ekosistem Kubernetes berkembang pesat. Dibutuhkan banyak waktu dan energi untuk selalu mengikuti perkembangan praktik terbaik dan alat terbaru. Kubectl, minikube, kubeadm, helm, anakan, kops, oc - daftarnya terus bertambah. Tidak semua alat ini diperlukan saat Anda memulai, namun Anda tidak tahu apa yang Anda perlukan, jadi Anda perlu mengetahui semuanya. Oleh karena itu, kurva pembelajarannya cukup curam.
Kapan menggunakan Kubernetes
Di perusahaan kami, banyak orang yang menggunakan Kubernetes dan cukup puas dengannya. Instans ini dikelola oleh Google atau Amazon, yang memiliki sumber daya untuk mendukungnya.
Kubernetes hadir bersama , yang membuat orkestrasi container dalam skala besar lebih mudah dikelola:
- Terperinci .
- menambahkan logika ke cluster. Ini hanyalah program yang berkomunikasi dengan API Kubernetes.
- ! Kubernetes dapat menskalakan layanan sesuai permintaan menggunakan metrik layanan dan tanpa memerlukan intervensi manual.
Pertanyaannya adalah apakah Anda benar-benar membutuhkan semua fitur tersebut. Anda tidak bisa hanya mengandalkan abstraksi; .
Tim kami menyediakan sebagian besar layanan dari jarak jauh (karena koneksi yang dekat dengan infrastruktur utama), jadi kami tidak ingin mengembangkan cluster Kubernetes kami sendiri. Kami hanya ingin memberikan layanan.
Baterai tidak termasuk
Nomad adalah 20% dari orkestrasi yang menyediakan 80% dari apa yang dibutuhkan. Yang dilakukannya hanyalah mengelola penerapan. Nomad menangani penerapan, memulai ulang container jika terjadi kesalahan... dan selesai.
Inti dari Nomad adalah apa yang dilakukannya minimum: tidak ada manajemen hak yang terperinci atau , ini dirancang khusus. Komponen-komponen ini disediakan secara eksternal atau tidak disediakan sama sekali.
Saya rasa Nomad telah menemukan kompromi sempurna antara kemudahan penggunaan dan utilitas. Ini bagus untuk layanan kecil dan independen. Jika Anda memerlukan kontrol lebih besar, Anda harus meningkatkannya sendiri atau menggunakan pendekatan lain. Pengembara adalah hanya pemimpin orkestra.
Hal terbaik tentang Nomad adalah mudahnya Π·Π°ΠΌΠ΅Π½ΠΈΡΡ. Praktis tidak ada koneksi ke vendor, karena fungsinya mudah diintegrasikan ke dalam sistem lain yang mengelola layanan. Itu hanya berjalan seperti biner biasa di setiap mesin di cluster, itu saja!
Ekosistem pengembara dengan komponen-komponen yang berpasangan secara longgar
Kekuatan Nomad yang sebenarnya adalah ekosistemnya. Ini terintegrasi dengan sangat baik dengan produk lain - sepenuhnya opsional - seperti (penyimpanan nilai kunci) atau (memproses rahasia). Di dalam file Nomad terdapat bagian untuk mengekstrak data dari layanan 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 dari Konsul dan saat bekerja kami mengeksposnya ke variabel lingkungan LOG_LEVEL. Kami juga menyajikan kuncinya secret/geo-api-key dari Vault sebagai API_KEY. Sederhana namun kuat!
Karena kesederhanaannya, Nomad mudah diperluas dengan layanan lain melalui API. Misalnya, tag untuk tugas didukung. Kami menandai semua layanan dengan metrik trv-metrics. Dengan cara ini Prometheus dapat dengan mudah menemukan layanan ini melalui Konsul dan memeriksa titik akhir secara berkala /metrics untuk data baru. Hal yang sama dapat dilakukan, misalnya untuk log, menggunakan .
Ada banyak contoh ekstensibilitas lainnya:
- Jalankan pekerjaan Jenkins menggunakan hook, dan Konsul memantau penerapan ulang pekerjaan Nomad ketika konfigurasi layanan berubah.
- Ceph menambahkan sistem file terdistribusi ke Nomad.
- untuk penyeimbangan beban.
Semua ini memungkinkan tanpa koneksi khusus ke vendor.
Peringatan yang adil
Tidak ada sistem yang sempurna. Saya tidak menyarankan untuk segera memperkenalkan fitur-fitur terbaru ke dalam produksi. Tentu saja ada bug dan fitur yang hilang, namun hal yang sama juga berlaku pada Kubernetes.
Dibandingkan dengan Kubernetes, komunitas Nomad tidak terlalu besar. Kubernetes sudah memiliki sekitar 75 komitmen dan 000 kontributor, sementara Nomad memiliki sekitar 2000 komitmen dan 14 kontributor. Nomad akan kesulitan mengimbangi kecepatan Kubernetes, tapi mungkin tidak harus demikian! Ini adalah sistem yang lebih terspesialisasi, dan komunitas yang lebih kecil juga berarti bahwa permintaan penarikan Anda lebih mungkin diperhatikan dan diterima, dibandingkan dengan Kubernetes.
Ringkasan
Intinya: Jangan gunakan Kubernetes hanya karena orang lain melakukannya. Evaluasi kebutuhan Anda dengan cermat dan periksa alat mana yang lebih bermanfaat.
Jika Anda berencana untuk menerapkan banyak layanan homogen pada infrastruktur berskala besar, maka Kubernetes adalah pilihan yang baik. Sadarilah kompleksitas tambahan dan biaya pengoperasian. Beberapa biaya dapat dihindari dengan menggunakan lingkungan Kubernetes yang dikelola seperti ΠΈΠ»ΠΈ .
Jika Anda hanya mencari orkestrator andal yang mudah dirawat dan dikembangkan, mengapa tidak mencoba Nomad? Anda mungkin terkejut seberapa jauh hal ini akan membawa Anda.
Jika Kubernetes diibaratkan mobil, Nomad adalah skuter. Terkadang Anda membutuhkan satu hal dan terkadang Anda membutuhkan hal lain. Keduanya mempunyai hak untuk hidup.
Sumber: www.habr.com