Gadis dengan skuter. Ilustrasi freepik , logo Nomad oleh HashiCorp

Kubernetes adalah 300 kg gorila untuk orkestrasi wadah. Ini bekerja di beberapa sistem kontainer terbesar di dunia, tetapi mahal.

Terutama mahal untuk tim kecil yang harus menghabiskan banyak waktu untuk dukungan dan kurva belajar yang curam. Untuk tim kami yang terdiri dari empat orang, ini terlalu banyak overhead. Jadi kami mulai mencari alternatif - dan jatuh cinta pada Nomad .

Apa yang kamu inginkan

Tim kami mendukung sejumlah layanan khas untuk memantau dan menganalisis kinerja: API titik akhir untuk metrik Go, ekspor Prometheus, pengurai log seperti Logstash dan Gollum , serta basis data seperti InfluxDB atau Elasticsearch. Masing-masing layanan ini berjalan dalam wadahnya sendiri. Kami membutuhkan sistem sederhana untuk menjaga semua ini operasional.

Kami mulai dengan daftar persyaratan untuk orkestrasi wadah:

• Luncurkan serangkaian layanan di banyak mesin.
  
• Ikhtisar menjalankan layanan.
  
• Komunikasi antar layanan.
  
• Restart otomatis jika layanan macet.
  
• Pemeliharaan infrastruktur oleh tim kecil.

Selain itu, hal-hal berikut akan menyenangkan, tetapi bukan tambahan wajib:

• Mesin penandaan sesuai kemampuannya (misalnya, mesin penandaan dengan cakram cepat untuk layanan I / O berat).
  
• Kemampuan untuk memulai layanan terlepas dari orkestra (misalnya, selama pengembangan).
  
• Tempat umum untuk berbagi konfigurasi dan rahasia.
  
• Titik akhir untuk metrik dan log.

Mengapa Kubernetes Tidak Sesuai Dengan Kami

Ketika membuat prototipe dengan Kubernetes, kami perhatikan bahwa kami mulai menambahkan lapisan logika yang semakin kompleks, yang kami andalkan tanpa syarat.

Sebagai contoh, Kubernetes mendukung konfigurasi layanan bawaan melalui ConfigMaps . Anda dapat menjadi bingung dengan cepat, terutama ketika menggabungkan beberapa file konfigurasi atau menambahkan layanan tambahan ke pod. Kubernetes (atau helm dalam hal ini) memungkinkan Anda untuk menerapkan konfigurasi eksternal yang dinamis untuk kepentingan yang terpisah. Tapi ini mengarah ke koneksi rahasia yang sulit antara proyek Anda dan Kubernetes. Namun, Helm dan ConfigMaps adalah opsi tambahan, jadi Anda tidak harus menggunakannya. Anda cukup menyalin konfigurasi ke gambar Docker. Namun demikian, tergoda untuk menempuh rute ini dan membangun abstraksi yang tidak perlu, yang dapat Anda sesali nanti.

Selain itu, ekosistem Kubernetes berkembang pesat. Dibutuhkan banyak waktu dan energi untuk tetap up to date dengan praktik terbaik dan alat terbaru. Kubectl, minikube, kubeadm, helm, tiller, kops, oc - daftarnya terus bertambah. Di awal pekerjaan, tidak semua alat ini diperlukan, tetapi Anda tidak tahu apa yang dibutuhkan, jadi Anda harus mengetahui semuanya. Karena itu, kurva belajar cukup curam.

Kapan harus menggunakan Kubernetes

Di perusahaan kami, banyak yang menggunakan Kubernetes dan cukup senang dengannya. Mesin virtual ini dikelola oleh Google atau Amazon, yang memiliki sumber daya dukungan yang memadai.

Kubernetes hadir dengan fitur luar biasa yang membuatnya lebih mudah dikelola dan orkestrasi wadah skala besar:

• Manajemen hak yang terperinci.
  
• Kontroler kustom menambahkan logika ke cluster. Ini hanya program yang berbicara dengan API Kubernetes.
  
• Autoscaling ! Kubernetes dapat meningkatkan skala layanan berdasarkan permintaan menggunakan metrik layanan tanpa memerlukan intervensi manual.

Pertanyaannya adalah apakah Anda benar-benar membutuhkan semua fitur ini. Anda tidak bisa hanya mengandalkan abstraksi; Anda harus mencari tahu apa yang terjadi di bawah tenda .

Tim kami menyediakan sebagian besar layanan dari jarak jauh (karena koneksi yang dekat dengan infrastruktur utama), jadi kami tidak ingin menaikkan kluster Kubernet kami sendiri. Kami hanya ingin memberikan layanan.

Baterai tidak termasuk

Nomad adalah 20% dari orkestrasi, yang memberikan 80% dari yang diperlukan. Yang dia lakukan hanyalah mengelola penyebaran. Nomad menangani penyebaran, memulai kembali kontainer jika ada kesalahan ... dan hanya itu.

Inti dari Nomad adalah bahwa ia melakukan minimum : tidak ada manajemen hak rinci atau kebijakan jaringan canggih yang dirancang khusus. Komponen-komponen ini disediakan oleh atau tidak disediakan sama sekali.

Saya pikir Nomad telah menemukan kompromi yang sempurna antara kemudahan penggunaan dan utilitas. Ini bagus untuk layanan kecil dan independen. Jika Anda perlu lebih banyak kontrol, Anda harus membuatnya sendiri atau menggunakan pendekatan yang berbeda. Pengembara hanyalah sebuah orkestra.

Hal terbaik tentang Nomad adalah mudah untuk diganti . Praktis tidak ada ikatan dengan vendor, karena fungsinya mudah diintegrasikan ke dalam sistem lain yang mengelola layanan. Ini berfungsi seperti biner biasa pada setiap mesin dalam sebuah cluster, itu saja!

Ekosistem nomaden dari komponen yang digabungkan secara longgar

Kekuatan nyata Nomad dalam ekosistemnya. Ini terintegrasi dengan sangat baik dengan produk lainnya - sepenuhnya opsional -, seperti Konsul (penyimpanan bernilai-kunci) atau Vault (pemrosesan rahasia). Di dalam file Nomad ada bagian untuk mengekstraksi 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 service/geo-api/log-verbosity kunci service/geo-api/log-verbosity dari Konsul dan dalam proses kami mewakilinya dengan variabel lingkungan LOG_LEVEL . Kami juga mewakili kunci secret/geo-api-key dari Vault sebagai API_KEY . Sederhana tapi kuat!

Karena kesederhanaannya, Nomad mudah diperluas melalui layanan lain melalui API. Misalnya, tag untuk tugas didukung. Kami menandai semua layanan dengan metrik dengan tag trv-metrics . Dengan demikian, Prometheus dengan mudah menemukan layanan ini melalui Konsul dan secara berkala memeriksa titik akhir /metrics untuk data baru. Hal yang sama dapat dilakukan, misalnya, untuk log menggunakan Loki .

Ada banyak contoh lain dari ekstensibilitas:

• Menjalankan pekerjaan Jenkins dengan hook, dan Konsul melacak penyebaran kembali pekerjaan Nomad ketika konfigurasi layanan berubah.
  
• Ceph menambahkan sistem file terdistribusi ke Nomad.
  
• fabio untuk menyeimbangkan beban.

Semua ini memungkinkan Anda untuk mengembangkan infrastruktur secara organik tanpa ada ikatan khusus dengan vendor.

Peringatan jujur

Tidak ada sistem yang sempurna. Saya tidak menyarankan segera memperkenalkan fitur-fitur terbaru ke dalam produksi. Tentu saja, ada bug dan fitur yang hilang, tetapi hal yang sama berlaku untuk Kubernetes.

Dibandingkan dengan Kubernetes, komunitas Nomad tidak begitu besar. Kubernetes sudah memiliki sekitar 75.000 komit dan 2.000 kontributor, sementara Nomad memiliki sekitar 14.000 komit dan 300 kontributor. Nomad akan sulit sekali untuk mengikuti Kubernetes dalam kecepatan, tetapi mungkin ini tidak perlu! Ini adalah sistem yang lebih terspesialisasi, dan komunitas yang lebih kecil juga berarti bahwa permintaan tarik Anda lebih cenderung diperhatikan dan diterima daripada Kubernetes.

Ringkasan

Kesimpulan: Jangan menggunakan Kubernet hanya karena semua orang melakukannya. Hati-hati mengevaluasi persyaratan Anda dan periksa alat mana yang lebih menguntungkan.

Jika Anda berencana menggunakan satu ton layanan homogen pada infrastruktur berskala besar, maka Kubernetes adalah pilihan yang baik. Ingat saja kompleksitas yang ditambahkan dan biaya perawatan. Beberapa biaya dapat dihindari dengan menggunakan lingkungan yang dikelola Kubernetes seperti Google Kubernetes Engine atau Amazon EKS .

Jika Anda hanya mencari orkestra yang andal, mudah didukung dan diperluas, mengapa tidak mencoba Nomad? Anda mungkin bertanya-tanya sejauh mana ini akan menuntun Anda.

Jika Anda membandingkan Kubernetes dengan mobil, Nomad akan menjadi skuter. Terkadang Anda membutuhkan satu, dan kadang-kadang yang lain. Keduanya memiliki hak untuk hidup.