Dziewczyna na skuterze. Ilustracja , logo Nomad z
Kubernetes to goryl do orkiestracji kontenerów o masie 300 kg. Działa w niektórych z największych systemów kontenerowych na świecie, ale ma swoją cenę.
Szczególnie drogie dla małych zespołów, które muszą spędzać dużo czasu na wsparciu i stromej krzywej uczenia się. Dla naszego czteroosobowego zespołu to zbyt duże obciążenie. Dlatego zaczęliśmy szukać alternatyw - i zakochaliśmy się .
Co chcesz
Nasz zespół obsługuje szereg typowych usług monitorowania i analizy wydajności: punkty końcowe API dla metryk napisanych w Go, eksport Prometheus, parsery dziennika, takie jak Logstash i , a także baz danych, takich jak InfluxDB czy Elasticsearch. Każda z tych usług działa we własnym kontenerze. Potrzebujemy prostego systemu, aby wszystko działało.
Zaczęliśmy od listy wymagań dotyczących orkiestracji kontenerów:
- Uruchomienie zestawu usług na wielu komputerach.
- Przegląd uruchomionych usług.
- Relacje między usługami.
- Automatyczne ponowne uruchomienie w przypadku awarii usługi.
- Utrzymanie infrastruktury przez mały zespół.
Dodatkowo przydały by się następujące rzeczy, ale nie wymagane dodatki:
- Oznaczanie maszyn według ich możliwości (na przykład oznaczanie maszyn szybkimi dyskami dla ciężkich usług we/wy).
- Możliwość uruchamiania usług niezależnych od koordynatora (na przykład podczas opracowywania).
- Wspólne miejsce do udostępniania konfiguracji i wpisów tajnych.
- Punkt końcowy dla metryk i dzienników.
Dlaczego Kubernetes nie jest dla nas
Podczas prototypowania z Kubernetes zauważyliśmy, że zaczęliśmy dodawać coraz bardziej złożone warstwy logiki, na których pośrednio polegaliśmy.
Na przykład Kubernetes obsługuje wbudowane konfiguracje usług za pośrednictwem . Możesz szybko się pogubić, zwłaszcza podczas łączenia wielu plików konfiguracyjnych lub dodawania dodatkowych usług do poda. Kubernetes (lub w tym przypadku) umożliwia dynamiczne wstrzykiwanie zewnętrznych konfiguracji w celu rozdzielenia problemów. Ale to prowadzi do twardego i mrocznego połączenia między twoim projektem a Kubernetes. Jednak Helm i ConfigMaps są opcjonalne, więc nie musisz ich używać. Możesz po prostu skopiować konfigurację do obrazu platformy Docker. Jednak kuszące jest pójście tą drogą i tworzenie niepotrzebnych abstrakcji, których możesz później żałować.
Ponadto ekosystem Kubernetes szybko ewoluuje. Bycie na bieżąco z najlepszymi praktykami i najnowszymi narzędziami zajmuje dużo czasu i energii. Kubectl, minikube, kubeadm, ster, rumpel, kops, oc - lista jest długa. Nie wszystkie z tych narzędzi są potrzebne, aby rozpocząć, ale nie wiesz, czego będziesz potrzebować, więc musisz być świadomy wszystkiego. Z tego powodu krzywa uczenia się jest dość stroma.
Kiedy używać Kubernetes
Wiele osób w naszej firmie korzysta z Kubernetes i jest z tego całkiem zadowolonych. Te instancje są zarządzane przez Google lub Amazon, które mają wystarczające zasoby wsparcia.
Kubernetes jest dostarczany z , które ułatwiają zarządzanie orkiestracją kontenerów na dużą skalę:
- szczegółowe .
- dodaj logikę do klastra. To tylko programy komunikujące się z interfejsem API Kubernetes.
- ! Kubernetes jest w stanie skalować usługi na żądanie przy użyciu metryk usług bez konieczności ręcznej interwencji.
Pytanie brzmi, czy naprawdę potrzebujesz wszystkich tych funkcji. Nie możesz polegać tylko na abstrakcjach; .
Nasz zespół świadczy większość usług zdalnie (ze względu na bliskie połączenie z podstawową infrastrukturą), dlatego nie chcieliśmy tworzyć własnego klastra Kubernetes. Chcieliśmy tylko świadczyć usługi.
Nie zawiera baterii
Nomad to orkiestracja 20%, która daje 80% tego, co jest potrzebne. Wszystko, co robi, to zarządzanie wdrożeniami. Nomad dba o wdrożenia, restartuje kontenery w przypadku błędów... i tyle.
Cały sens Nomada polega na tym, co robi. minimum: brak precyzyjnego zarządzania prawami lub , tak specjalnie pomyślane. Komponenty te są dostarczane z zewnątrz lub nie są dostarczane wcale.
Myślę, że Nomad znalazł idealny kompromis między łatwością obsługi a użytecznością. Jest dobry dla małych, niezależnych serwisów. Jeśli potrzebujesz większej kontroli, będziesz musiał sam je wychować lub zastosować inne podejście. koczownik jest po prostu orkiestrator.
Najlepszą rzeczą w Nomadzie jest to, że jest łatwy wymienić. Praktycznie nie ma uzależnienia od dostawcy, ponieważ jego funkcje można łatwo zintegrować z dowolnym innym systemem zarządzającym usługami. Działa jak zwykły plik binarny na każdej maszynie w klastrze, to wszystko!
Luźno powiązany ekosystem Nomada
Prawdziwa siła Nomada tkwi w jego ekosystemie. Bardzo dobrze integruje się z innymi - całkowicie opcjonalnymi - produktami takimi jak (magazyn klucz-wartość) lub (obsługa tajemnic). Wewnątrz pliku Nomad znajdują się sekcje do wydobywania danych z tych usług:
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
}
Tutaj czytamy klucz service/geo-api/log-verbosity od Consula iw trakcie pracy reprezentujemy go zmienną środowiskową LOG_LEVEL. Prezentujemy również klucz secret/geo-api-key z Vault jako API_KEY. Prosty, ale potężny!
Ze względu na swoją prostotę Nomad można łatwo rozszerzyć o inne usługi za pośrednictwem interfejsu API. Obsługiwane są na przykład znaczniki zadań. Tagujemy wszystkie usługi z metrykami trv-metrics. W ten sposób Prometheus z łatwością znajduje te usługi za pośrednictwem usługi Consul i okresowo sprawdza punkt końcowy /metrics dla nowych danych. To samo można zrobić na przykład dla logów, używając .
Istnieje wiele innych przykładów rozszerzalności:
- Uruchom zadanie Jenkins za pomocą haka, a Consul śledzi ponowne wdrażanie zadania Nomada, gdy zmienia się konfiguracja usługi.
- Ceph dodaje rozproszony system plików do Nomada.
- do równoważenia obciążenia.
Wszystko to pozwala bez szczególnego odniesienia do sprzedawcy.
Uczciwe ostrzeżenie
Żaden system nie jest doskonały. Nie radzę od razu wprowadzać najnowszych funkcji do produkcji. Jasne, są błędy i brakujące funkcje, ale to samo dotyczy Kubernetes.
W porównaniu z Kubernetes społeczność Nomad nie jest tak duża. Kubernetes ma już około 75 000 zatwierdzeń i 2000 współpracowników, podczas gdy Nomad ma około 14 000 zatwierdzeń i 300 współpracowników. Nomadowi trudno będzie nadążyć za Kubernetes w szybkości, ale może to nie być konieczne! Jest to bardziej wyspecjalizowany system, a mniejsza społeczność oznacza również, że Twoje żądanie ściągnięcia jest bardziej prawdopodobne, że zostanie zauważone i zaakceptowane niż Kubernetes.
Streszczenie
Na wynos: nie używaj Kubernetes tylko dlatego, że wszyscy to robią. Dokładnie oceń swoje wymagania i sprawdź, które narzędzie jest bardziej opłacalne.
Jeśli planujesz wdrożyć wiele jednorodnych usług w infrastrukturze na dużą skalę, dobrym rozwiązaniem jest Kubernetes. Należy tylko pamiętać o dodatkowej złożoności i kosztach eksploatacji. Niektórych kosztów można uniknąć, korzystając z zarządzanego środowiska Kubernetes, takiego jak lub .
Jeśli po prostu szukasz solidnego orkiestratora, który jest łatwy w utrzymaniu i rozszerzalny, dlaczego nie spróbować Nomada? Możesz być zaskoczony, jak daleko Cię to zaprowadzi.
Jeśli Kubernetes jest jak samochód, Nomad jest skuterem. Czasami potrzebujesz jednego, a czasami drugiego. Obaj mają prawo istnieć.
Źródło: www.habr.com