Dziewczyna na skuterze. Ilustracja freepik, logo Nomad od HashiCorp

Kubernetes to 300-kilogramowa goryl do orkiestracji kontenerów. Działa w niektórych z największych systemów kontenerowych na świecie, ale jest kosztowny.

Szczególnie kosztowny dla małych zespołów, które będą musiały poświęcić dużo czasu na wsparcie i skomplikowaną krzywą uczenia się. Dla naszego czteroosobowego zespołu to zbyt dużo kosztów ogólnych. Dlatego zaczęliśmy szukać alternatyw i zakochaliśmy się w Nomad.

Czego pragniemy

Nasz zespół wspiera szereg typowych usług do monitorowania i analizy wydajności: punkty końcowe API do metryk, napisane w Go, eksport Prometheusa, parsery logów, takie jak Logstash oraz Gollum, a także bazy danych, takie jak InfluxDB czy Elasticsearch. Każda z tych usług działa w osobnym kontenerze. Potrzebujemy prostego systemu, aby utrzymać to wszystko w stanie roboczym.

Zaczęliśmy od listy wymagań do orkiestracji kontenerów:

• Uruchamianie zestawu usług na wielu maszynach.
• Przegląd uruchomionych usług.
• Połączenia między usługami.
• Automatyczny restart, gdy usługa pada.
• Zarządzanie infrastrukturą przez mały zespół.

Dodatkowo, następujące rzeczy będą miłe, ale nieobowiązkowe:

• Oznaczanie maszyn według ich możliwości (na przykład oznaczanie maszyn z szybkim dyskiem dla ciężkich usług wejścia/wyjścia).
• Możliwość uruchamiania usług niezależnie od orkiestratora (na przykład podczas rozwoju).
• Wspólne miejsce do wymiany konfiguracji i sekretów.
• Punkt końcowy do metryk i logów.

Dlaczego Kubernetes nam nie odpowiada

Przy prototypowaniu z Kubernetes zauważyliśmy, że zaczęliśmy dodawać coraz bardziej skomplikowane warstwy logiki, na których bezwarunkowo polegaliśmy.

Na przykład, Kubernetes obsługuje wbudowane konfiguracje usług przez ConfigMaps. Możesz szybko się pogubić, szczególnie przy scalaniu kilku plików konfiguracyjnych lub dodawaniu dodatkowych usług do poda. Kubernetes (lub helm W tym przypadku pozwala na dynamiczne wdrażanie zewnętrznych konfiguracji w celu podziału interesów. Jednak prowadzi to do sztywnej, ukrytej relacji między Twoim projektem a Kubernetes. Niemniej jednak Helm i ConfigMaps są dodatkowymi opcjami, więc nie musisz ich używać. Możesz po prostu skopiować konfigurację do obrazu Docker. Niemniej jest to kusząca ścieżka, która może prowadzić do budowy niepotrzebnych abstrakcji, z czego możesz potem żałować.

Ponadto ekosystem Kubernetes szybko się rozwija. Wymaga to dużo czasu i energii, aby pozostawać na bieżąco z najlepszymi praktykami i najnowszymi narzędziami. Kubectl, minikube, kubeadm, helm, tiller, kops, oc — lista się wydłuża. Na początku nie potrzebujesz wszystkich tych narzędzi, ale nie wiesz, co będzie potrzebne, dlatego musisz być na bieżąco ze wszystkim. Z tego powodu krzywa uczenia się jest dość stroma.

Kiedy używać Kubernetes

W naszej firmie wielu korzysta z Kubernetes i jest z tego zadowolonych. Te instancje są zarządzane przez Google lub Amazon, którzy mają wystarczające zasoby, aby to wesprzeć.

Kubernetes dostarczany jest z niesamowitymi funkcjami, które czynią zarządzanie dużą orkiestracją kontenerów bardziej przystępnym:

• Szczegółowe zarządzanie uprawnieniami.
• Niestandardowe kontrolery dodają logikę do klastra. To po prostu programy, które komunikują się z API Kubernetes.
• Automatyczne skalowanie! Kubernetes potrafi skalować usługi na żądanie, wykorzystując metryki usług i nie wymagając ręcznej interwencji.

Pytanie brzmi, czy naprawdę potrzebujesz wszystkich tych funkcji. Nie można polegać tylko na abstrakcjach; musisz dowiedzieć się, co dzieje się pod maską.

Nasz zespół świadczy większość usług zdalnie (ze względu na bliską integrację z podstawową infrastrukturą), dlatego nie chcieliśmy uruchamiać własnego klastra Kubernetes. Chcieliśmy po prostu świadczyć usługi.

Baterie nie są dołączone

Nomad to 20% orkiestracji, które dają 80% tego, co potrzebne. Wszystko, co robi, to zarządza wdrożeniami. Nomad zajmuje się wdrożeniami, ponownie uruchamia kontenery w przypadku błędów… i to wszystko.

Cały sens Nomad polega na tym, co robi minimum: brak szczegółowego zarządzania uprawnieniami lub zaawansowanych polityk sieciowych, tak zostało to specjalnie zaprojektowane. Te komponenty są dostarczane z zewnątrz lub w ogóle nie są dostarczane.

Myślę, że Nomad znalazł idealny kompromis między łatwością użycia a użytecznością. Jest dobry dla małych, niezależnych serwisów. Jeśli potrzebujesz większej kontroli, musisz je wdrożyć samodzielnie lub użyć innego podejścia. Nomad to po prostu orkiestrator.

Najlepsze w Nomadzie to to, że jest łatwy do zamiany. Związanie z dostawcą jest praktycznie nieistniejące, ponieważ jego funkcje łatwo integrują się z każdym innym systemem zarządzającym serwisami. Działa po prostu jako zwykły plik binarny na każdej maszynie w klastrze, i to wszystko!

Ekosystem Nomada składa się z luźno powiązanych komponentów

Prawdziwa siła Nomada tkwi w jego ekosystemie. Dobrze integruje się z innymi — całkowicie opcjonalnymi — produktami, takimi jak Consul (przechowalnia kluczy-wartości) lub Vault (zarządzanie sekretami). W 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 z Consula i w trakcie działania przedstawiamy go jako zmienną środowiskową LOG_LEVEL. Przedstawiamy również klucz secret/geo-api-key z Vaulta jako API_KEY. Proste, ale potężne!

Dzięki swojej prostocie Nomad łatwo rozbudowuje się z użyciem innych usług przez API. Na przykład, obsługiwane są tagi dla zadań. Oznaczamy wszystkie usługi z metrykami tagiem trv-metrics. Dzięki temu Prometheus łatwo znajduje te usługi przez Consula i okresowo sprawdza punkt końcowy /metrics w poszukiwaniu nowych danych. To samo można zrobić, na przykład, dla logów, używając Loki.

Jest wiele innych przykładów rozszerzalności:

• Uruchamianie zadań Jenkins za pomocą haka, a Consul śledzi ponowne wdrożenie zadań Nomad przy zmianach w konfiguracji usługi.
• Ceph dodaje do Nomada rozproszoną system plików.
• fabio do równoważenia obciążenia.

Wszystko to pozwala naturalnie rozwijać infrastrukturę bez szczególnej zależności od dostawcy.

Uczciwe ostrzeżenie

Żaden system nie jest doskonały. Nie zalecam wprowadzania najnowszych funkcji do produkcji od razu. Oczywiście, są błędy i brakuje funkcji, ale to samo odnosi się do Kubernetes.

W porównaniu do Kubernetes, społeczność Nomad jest mniejsza. Kubernetes ma już około 75 000 commitów i 2000 kontrybutorów, podczas gdy Nomad ma około 14 000 commitów i 300 kontrybutorów. Nomad będzie mieć trudności, aby nadążyć tempem za Kubernetes, ale może to nie jest konieczne! To bardziej wyspecjalizowany system, a mniejsza społeczność również oznacza, że Twoje zgłoszenie pull może być łatwiej zauważone i zaakceptowane, w porównaniu z Kubernetes.

Podsumowanie

Podsumowanie: nie używaj Kubernetes tylko dlatego, że wszyscy to robią. Dokładnie oceń swoje wymagania i sprawdź, który instrument jest bardziej opłacalny.

Jeśli planujesz wdrożyć dużą ilość jednorodnych usług na infrastrukturze w skali, Kubernetes to dobry wybór. Po prostu pamiętaj o dodatkowej złożoności i kosztach operacyjnych. Niektóre wydatki można uniknąć, korzystając z zarządzanego środowiska Kubernetes, takiego jak Google Kubernetes Engine lub Amazon EKS.

Jeśli po prostu szukasz niezawodnego orkiestratora, łatwego w utrzymaniu i skalowalnego, dlaczego nie spróbować Nomad? Możesz być zaskoczony, jak daleko to Cię zaprowadzi.

Jeśli porównasz Kubernetes do samochodu, Nomad będzie skuterem. Czasami potrzebujesz jednego, a czasami drugiego. Oba mają swoje miejsce.

Źródło: habr.com