Gdy kilka aplikacji konkuruje o CPU, pamięć i porty na tych samych serwerach, ręczne przydzielanie zasobów szybko przestaje działać. Apache Mesos powstał jako open source’owy menedżer klastrów, który oddziela zarządzanie infrastrukturą od uruchamiania konkretnych aplikacji. Wyjaśniam, jak działa jego architektura, gdzie wykorzystywano go w DevOps, czym różni się od Kubernetes oraz dlaczego w 2026 roku jego status ma duże znaczenie przy planowaniu nowych wdrożeń.
Najważniejsze informacje o zarządzaniu klastrem przez Mesos
- Mesos łączy zasoby wielu serwerów w jeden logiczny klaster.
- Za uruchamianie aplikacji odpowiadają frameworki, a nie sam menedżer klastra.
- Model resource offers pozwala schedulerom wybierać dostępne CPU, pamięć, dyski i porty.
- Projekt Apache Mesos został wycofany i przeniesiony do Apache Attic.
- Do nowych wdrożeń najczęściej lepiej wybrać Kubernetes lub inne aktywnie rozwijane rozwiązanie.
Apache Mesos łączy serwery w jeden pulę zasobów
Najprościej myśleć o Mesosie jak o warstwie, która zbiera zasoby wielu maszyn i udostępnia je aplikacjom w spójny sposób. Zamiast przypisywać usługę na stałe do konkretnego serwera, można pozwolić schedulerowi zdecydować, gdzie uruchomić zadanie na podstawie aktualnego obciążenia i wymaganych parametrów.
Sam Mesos nie jest jednak typowym systemem wdrażania aplikacji. Jego zadaniem jest przede wszystkim alokowanie zasobów oraz izolowanie zadań. Za logikę uruchamiania usług odpowiadają frameworki, czyli aplikacje korzystające z API klastra.
To rozdzielenie było jednym z najciekawszych pomysłów projektu. Jeden klaster mógł obsługiwać jednocześnie obciążenia Spark, zadania Hadoop, serwisy uruchamiane przez Marathon czy własne schedulery napisane w Pythonie. Każdy framework zachowywał własną logikę, ale korzystał ze wspólnej infrastruktury.
Jak działa architektura master, agent i framework
W centrum klastra znajduje się Mesos master. Śledzi on stan zasobów, przyjmuje zgłoszenia frameworków i oferuje im dostępne CPU, pamięć, dyski oraz porty. Na poszczególnych serwerach działają agenci, dawniej nazywani slave’ami, którzy uruchamiają zadania i raportują ich stan.
Framework składa się zwykle z dwóch elementów. Scheduler podejmuje decyzję, które zasoby przyjąć, a executor uruchamia zadania na wybranym agencie. Dzięki temu Mesos nie musi znać szczegółów każdej aplikacji, a framework może implementować własne reguły priorytetów, harmonogramów i ponawiania zadań.
Mechanizm ofert zasobów
Przepływ wygląda następująco. Master widzi wolne zasoby, przekazuje ich ofertę schedulerowi, a scheduler odpowiada, czy chce ją przyjąć i jakie zadania uruchomić. Jeżeli oferta nie pasuje do wymagań, zasoby mogą zostać przekazane innemu frameworkowi.
Przykładowo usługa może wymagać 2 vCPU, 4 GB pamięci i określonego portu. Scheduler wybiera ofertę spełniającą te warunki, po czym zleca uruchomienie zadania agentowi. Taki model ułatwia współdzielenie klastra, ale wymaga dobrego schedulera, ponieważ to on odpowiada za znaczną część decyzji operacyjnych.
Odporność na awarie
W środowisku produkcyjnym pojedynczy master byłby oczywistym punktem awarii, dlatego stosuje się konfigurację wysokiej dostępności i mechanizm wyboru lidera. Frameworki mogą również korzystać z checkpointingu, czyli zapisywania stanu potrzebnego do odtworzenia pracy po awarii procesu lub połączenia.
Nie oznacza to jednak, że każda aplikacja automatycznie stanie się odporna na awarie. Scheduler musi poprawnie obsługiwać utratę agenta, ponowne uruchomienie zadania i rozbieżności między stanem zapisanym lokalnie a stanem klastra. To jedna z rzeczy, które początkujący często przypisują samemu Mesosowi, choć w praktyce zależy ona również od frameworka.
Do czego wykorzystywano ten system w DevOps
Największą wartość rozwiązanie pokazywało w dużych, heterogenicznych klastrach, w których różne zespoły uruchamiały odmienne typy obciążeń. Zamiast budować osobną infrastrukturę dla Spark, zadań wsadowych i usług HTTP, można było wykorzystać wspólną warstwę alokacji zasobów.
- Przetwarzanie danych - frameworki dla Spark i Hadoop mogły korzystać z zasobów wtedy, gdy były potrzebne.
- Usługi długotrwałe - Marathon i podobne narzędzia obsługiwały wdrażanie oraz restart serwisów.
- CI/CD - zadania budowania i testów uruchamiały się na współdzielonych agentach.
- Własne platformy - zespoły mogły pisać schedulery dopasowane do specyficznych reguł biznesowych.
W praktyce najwięcej zyskiwały organizacje, które miały już kompetencje w tworzeniu i utrzymywaniu frameworków. Dla małego zespołu koszt operacyjny takiej warstwy mógł przewyższyć korzyści, zwłaszcza gdy potrzebne były tylko kontenery i kilka prostych usług.
Przeczytaj również: Architektura Multi Tenant - Jak uniknąć błędów i skalować SaaS?
Przykład z aplikacją Python
Scheduler napisany w Pythonie mógł komunikować się z masterem przez Scheduler HTTP API. Aplikacja subskrybowała oferty, analizowała dostępne zasoby, akceptowała wybraną ofertę i przekazywała opis zadania do uruchomienia.
To podejście było wygodne dla zespołów, które nie chciały pisać natywnego kodu w C++. Trzeba jednak pamiętać, że sam scheduler nie zastępował całego systemu wdrożeniowego. Należało jeszcze zadbać o obraz kontenera, konfigurację, logowanie, health checki, sekrety i strategię odtwarzania po błędach.
Apache Mesos a Kubernetes w nowym projekcie
Oba rozwiązania służą do zarządzania obciążeniami w klastrze, ale mają inną filozofię. Mesos udostępnia ogólną warstwę zasobów i pozwala frameworkom definiować sposób planowania. Kubernetes dostarcza bardziej kompletny model platformy dla aplikacji kontenerowych, obejmujący między innymi deploymenty, usługi, konfigurację i deklaratywne zarządzanie stanem.
| Kryterium | Mesos | Kubernetes |
|---|---|---|
| Model działania | Oferty zasobów i zewnętrzne frameworki | Deklaratywny stan aplikacji i kontrolery |
| Elastyczność schedulera | Bardzo duża, scheduler może być własną aplikacją | Duża, ale oparta na modelu Kubernetes |
| Obsługa aplikacji | Zależna od wybranego frameworka | Wbudowane obiekty, kontrolery i ekosystem |
| Krzywa wejścia | Wysoka przy budowaniu własnych frameworków | Wysoka, lecz łatwiejsza dzięki standardowym wzorcom |
| Perspektywa projektu | Projekt wycofany | Aktywnie rozwijany ekosystem |
Moja praktyczna ocena jest prosta. Mesos pozostaje interesujący jako przykład architektury systemu rozproszonego i może być ważny przy utrzymaniu starszej platformy, ale nie wybierałbym go do nowego wdrożenia produkcyjnego. Kubernetes bywa cięższy, jednak ma obecnie znacznie większy ekosystem, dostępność narzędzi i pulę specjalistów.
Nie znaczy to, że migracja zawsze jest szybka albo tania. Jeżeli istniejąca platforma korzysta z własnych frameworków, rezerwacji zasobów i niestandardowych mechanizmów schedulowania, przejście na Kubernetes wymaga osobnego projektu, testów obciążeniowych i ponownego zaprojektowania części procesów.
Co trzeba sprawdzić przed uruchomieniem klastra
W przypadku starszego środowiska największym błędem jest skupienie się wyłącznie na instalacji mastera i agentów. Najpierw sprawdziłbym, jakie typy zadań faktycznie działają, kto nimi zarządza oraz które elementy są krytyczne dla odtworzenia usług.
- Zidentyfikuj frameworki i ich wersje.
- Sprawdź wymagania dotyczące CPU, pamięci, dysków, portów i sieci.
- Zweryfikuj sposób przechowywania konfiguracji, sekretów i danych trwałych.
- Przetestuj utratę agenta oraz przełączenie mastera.
- Zmierz czas ponownego uruchomienia zadań po awarii.
- Ustal, czy dostępne są obrazy kontenerów, biblioteki i procedury wdrożeniowe.
Szczególnej uwagi wymagają dane trwałe. Zadanie uruchomione ponownie na innym agencie nie zawsze znajdzie lokalny dysk ani poprzedni stan. Jeżeli aplikacja nie jest bezstanowa, trzeba jasno opisać sposób korzystania z wolumenów, systemu plików lub zewnętrznej bazy danych.
Sprawdziłbym też monitoring. Same informacje o tym, że zadanie działa, są niewystarczające. Potrzebne są metryki wykorzystania zasobów, powody restartów, opóźnienia w przydziale ofert, błędy executorów oraz alerty dotyczące braku wolnych zasobów.
Najważniejsze ograniczenie w 2026 roku
Apache Mesos został oznaczony jako projekt wycofany i trafił do Apache Attic. Oznacza to, że nie należy traktować go jak aktywnie rozwijanej platformy, na której można bezpiecznie opierać nową strategię infrastrukturalną.
Dla administratora utrzymującego istniejące środowisko nie oznacza to natychmiastowego wyłączenia klastra. Znacznie ważniejsze jest przygotowanie planu obejmującego wersje systemu operacyjnego, obrazy kontenerów, biblioteki, poprawki bezpieczeństwa, backup konfiguracji oraz kompetencje potrzebne do reagowania na awarie.
Największe ryzyko nie wynika dziś z samego modelu resource offers. Problemem jest malejące wsparcie ekosystemu, trudniejszy dostęp do aktualnych integracji i rosnący koszt znalezienia osób, które znają konkretną konfigurację starego klastra.
Jeśli Mesos jest używany tylko do uruchamiania zwykłych usług kontenerowych, warto porównać koszt utrzymania z migracją do Kubernetes. Jeżeli obsługuje unikatowy scheduler lub specjalistyczne zadania danych, najpierw trzeba odtworzyć te funkcje w środowisku testowym, zamiast zakładać, że standardowe manifesty rozwiążą problem.
Jak rozsądnie podejść do spuścizny Mesosa
Mesos jest dobrym materiałem do nauki zarządzania zasobami, projektowania schedulerów i budowania systemów rozproszonych. Pokazuje też, że elastyczność architektury ma swoją cenę: im więcej decyzji pozostawia się frameworkom, tym większe wymagania wobec zespołu utrzymującego całość.
Przy istniejącym klastrze zacząłbym od inwentaryzacji usług i testu odtwarzania, a dopiero później wybierał kierunek migracji. Przy nowym projekcie wybrałbym rozwiązanie z aktywnym rozwojem, szeroką dokumentacją i łatwo dostępnym wsparciem operacyjnym. Taka decyzja zwykle ma większe znaczenie dla stabilności platformy niż sama różnica w wydajności schedulera.
