Kubernet'lere ihtiyacınız olmayabilir

Kubernet'lere ihtiyacınız olmayabilir
Kız bir scooter üzerinde. İllüstrasyon freepik, Nomad logosu HashiCorp

Kubernetes, 300 kg'lık bir konteyner düzenleme gorilidir. Dünyanın en büyük konteyner sistemlerinden bazılarında çalışır, ancak bunun bir bedeli vardır.

Destek için çok zaman harcamak zorunda kalan ve dik bir öğrenme eğrisi olan küçük ekipler için özellikle pahalıdır. Dört kişilik ekibimiz için bu çok fazla bir yük. Bu nedenle alternatifler aramaya başladık - ve aşık olduk Göçebe.

Ne istiyorsun

Ekibimiz bir dizi tipik performans izleme ve analiz hizmetlerine sahiptir: Go'da yazılan metrikler için API uç noktaları, Prometheus dışa aktarımları, Logstash gibi günlük ayrıştırıcılar ve GollumInfluxDB veya Elasticsearch gibi veritabanlarının yanı sıra. Bu hizmetlerin her biri kendi kapsayıcısında çalışır. Her şeyi çalışır durumda tutmak için basit bir sisteme ihtiyacımız var.

Kapsayıcı düzenleme için gereksinimlerin bir listesiyle başladık:

  • Birçok makinede bir dizi hizmet çalıştırmak.
  • Çalışan hizmetlere genel bakış.
  • Hizmetler arasındaki ilişkiler.
  • Hizmet çökerse otomatik yeniden başlatma.
  • Küçük bir ekip tarafından altyapının bakımı.

Ek olarak, aşağıdaki şeyler güzel olurdu, ancak gerekli eklemeler:

  • Makineleri yeteneklerine göre işaretleme (örneğin, ağır G/Ç hizmetleri için hızlı diskli markalama makineleri).
  • Hizmetleri orkestratörden bağımsız olarak çalıştırma yeteneği (örneğin, geliştirme sırasında).
  • Yapılandırmaları ve sırları paylaşmak için ortak bir yer.
  • Metrikler ve günlükler için bitiş noktası.

Kubernetes neden bize göre değil?

Kubernetes ile prototip oluştururken, dolaylı olarak güvendiğimiz daha karmaşık mantık katmanları eklemeye başladığımızı fark ettik.

Örnek olarak, Kubernetes yerleşik hizmet yapılandırmalarını destekler. Yapılandırma Haritaları. Özellikle birden çok yapılandırma dosyasını birleştirirken veya bir bölmeye ek hizmetler eklerken kafanız hızla karışabilir. Kubernet'ler (veya dümen bu durumda), kaygıların ayrılması için harici yapılandırmaları dinamik olarak enjekte etmenize olanak tanır. Ancak bu, projeniz ile Kubernet'ler arasında zor ve karanlık bir bağlantıya yol açar. Ancak Helm ve ConfigMaps isteğe bağlıdır, dolayısıyla bunları kullanmak zorunda değilsiniz. Yapılandırmayı Docker görüntüsüne kopyalayabilirsiniz. Ancak, o rotaya gitmek ve daha sonra pişman olabileceğiniz gereksiz soyutlamalar oluşturmak cazip gelebilir.

Ek olarak, Kubernetes ekosistemi hızla gelişiyor. En iyi uygulamalar ve en son araçlarla güncel kalmak çok zaman ve enerji gerektirir. Kubectl, minikube, kubeadm, helm, yeke, kops, oc - liste uzayıp gidiyor. Başlamak için bu araçların hepsine ihtiyaç yoktur, ancak neye ihtiyacınız olacağını bilmediğiniz için her şeyin farkında olmanız gerekir. Bu nedenle, öğrenme eğrisi oldukça diktir.

Kubernetes Ne Zaman Kullanılır?

Şirketimizdeki birçok kişi Kubernetes kullanıyor ve bundan oldukça memnun. Bu bulut sunucuları, yeterli destek kaynağına sahip olan Google veya Amazon tarafından yönetilmektedir.

Kubernetes ile birlikte gelir inanılmaz özellikler, büyük ölçekli konteyner düzenlemesini daha yönetilebilir hale getirir:

Soru şu ki, tüm bu özelliklere gerçekten ihtiyacınız var mı? Sadece soyutlamalara güvenemezsiniz; kaputun altında neler olduğunu öğrenmelisin.

Ekibimiz hizmetlerin çoğunu uzaktan sağlıyor (çekirdek altyapıya yakın bağlantı nedeniyle), bu nedenle kendi Kubernetes kümemizi oluşturmak istemedik. Biz sadece hizmet vermek istedik.

piller dahil değildir

Nomad, ihtiyaç duyulanın %20'ini sağlayan %80'lik bir orkestrasyondur. Tek yaptığı dağıtımları yönetmektir. Nomad konuşlandırmalarla ilgilenir, hata olması durumunda kapsayıcıları yeniden başlatır... ve hepsi bu.

Nomad'ın tüm amacı ne yaptığıdır. asgari: ayrıntılı hak yönetimi yok veya gelişmiş ağ politikaları, çok özel olarak tasarlandı. Bu bileşenler harici olarak sağlanır veya hiç sağlanmaz.

Bence Nomad, kullanım kolaylığı ve kullanışlılık arasında mükemmel bir uzlaşma buldu. Küçük, bağımsız hizmetler için iyidir. Daha fazla kontrole ihtiyacınız varsa, bunları kendiniz yükseltmeniz veya farklı bir yaklaşım kullanmanız gerekecektir. göçebe sadece orkestratör.

Nomad ile ilgili en iyi şey, kolay olmasıdır vekil. İşlevleri, hizmetleri yöneten diğer herhangi bir sisteme kolayca entegre edildiğinden, neredeyse hiçbir satıcıya bağlı kalma durumu yoktur. Kümedeki her makinede normal bir ikili dosya gibi çalışır, hepsi bu!

Gevşek bağlı Göçebe ekosistemi

Nomad'ın gerçek gücü ekosistemindedir. Gibi diğer - tamamen isteğe bağlı - ürünlerle çok iyi entegre olur konsolos (anahtar/değer deposu) veya Tonoz (sırları ele almak). Nomad dosyasının içinde, bu hizmetlerden veri çıkarmak için bölümler vardır:

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
}

Burada anahtarı okuyoruz service/geo-api/log-verbosity Konsolos'tan ve çalışma sırasında onu bir ortam değişkeni ile temsil ediyoruz LOG_LEVEL. Anahtarı da sunuyoruz secret/geo-api-key Apps Kasası'ndan şu şekilde API_KEY. Basit ama güçlü!

Basitliği nedeniyle Nomad, bir API aracılığıyla diğer hizmetlerle kolayca genişletilebilir. Örneğin, iş etiketleri desteklenir. Tüm hizmetleri metriklerle etiketi ile etiketliyoruz trv-metrics. Bu sayede Prometheus bu hizmetleri Consul aracılığıyla kolayca bulur ve uç noktayı periyodik olarak kontrol eder. /metrics yeni veriler için. Aynı şey, örneğin günlükler için şu şekilde yapılabilir: loki.

Genişletilebilirliğin başka birçok örneği vardır:

  • Bir Jenkins işini bir kanca ile çalıştırın ve Consul, hizmet yapılandırması değiştiğinde yeniden konuşlandırılan Nomad işinin kaydını tutar.
  • Ceph, Nomad'a dağıtılmış bir dosya sistemi ekler.
  • fabio yük dengeleme için.

Bütün bunlar izin verir altyapıyı organik olarak geliştirmek satıcıya özel referans olmadan.

Adil Uyarı

Hiçbir sistem mükemmel değildir. En yeni özellikleri hemen üretime sokmanızı tavsiye etmiyorum. Elbette hatalar ve eksik özellikler var ama aynısı Kubernet'ler için de geçerli.

Kubernetes ile karşılaştırıldığında Nomad topluluğu o kadar büyük değil. Kubernetes'in halihazırda yaklaşık 75 işlemi ve 000 katılımcısı varken, Nomad'ın yaklaşık 2000 işlemi ve 14 katılımcısı var. Nomad'in hız açısından Kubernetes'e ayak uydurması zor olacak ama buna gerek olmayabilir! Daha özel bir sistemdir ve daha küçük topluluk, çekme isteğinizin fark edilme ve kabul edilme olasılığının Kubernetes'e göre daha yüksek olduğu anlamına gelir.

Özet

Çıkarım: Herkes yapıyor diye Kubernetes kullanmayın. Gereksinimlerinizi dikkatlice değerlendirin ve hangi aracın daha karlı olduğunu kontrol edin.

Büyük ölçekli bir altyapı üzerinde çok sayıda homojen hizmet dağıtmayı planlıyorsanız Kubernetes iyi bir seçenektir. Sadece eklenen karmaşıklığın ve çalıştırma maliyetlerinin farkında olun. Aşağıdakiler gibi yönetilen bir Kubernetes ortamı kullanılarak bazı maliyetlerden kaçınılabilir: Google Kubernetes Motoru veya Amazon EKS'si.

Bakımı kolay ve genişletilebilir sağlam bir orkestratör arıyorsanız, neden Nomad'ı denemiyorsunuz? Bunun sizi ne kadar ileri götüreceğine şaşırabilirsiniz.

Kubernetes bir araba gibiyse, Nomad bir scooter'dır. Bazen birine bazen de diğerine ihtiyaç duyarsın. Her ikisinin de var olma hakkı vardır.

Kaynak: habr.com

Yorum ekle