Ten tekst jest dla właściciela, któremu ktoś właśnie zaproponował klaster, i dla osoby, która miałaby go potem utrzymywać. Po przeczytaniu rozstrzygniecie jedno pytanie: czy Kubernetes rozwiązuje Wasz problem, czy dokłada drugi, większy od pierwszego.
Kubernetes przy pięćdziesięciu stanowiskach prawie nigdy nie jest potrzebny. Klaster nie ma opłaty licencyjnej i mimo to bywa najdroższą rzeczą w firmie, bo płaci się za czas człowieka, który go rozumie. Sens pojawia się w trzech sytuacjach: wymaga tego umowa z klientem, producent dostarcza aplikację wyłącznie w tej formie albo zespół już tak pracuje.
Nie ma tu instrukcji instalacji ani porównania dystrybucji klastra, bo w tej rozmowie żadna z tych rzeczy nie zmienia wyniku. Jest jedno rozstrzygnięcie do zabrania: czy Kubernetes rozwiązuje Wasz problem, czy dokłada drugi, większy od pierwszego. Czytają to zwykle dwie osoby, właściciel i ten, kto miałby klaster utrzymywać.
Wyobraźcie sobie kierownika zmiany w dużym magazynie. Nie pakuje, nie wozi, nie skanuje. Robi jedną rzecz: pilnuje, żeby przy każdym stanowisku przez cały czas stało tylu ludzi, ilu ma stać. Ktoś zasłabnie, kierownik natychmiast ściąga zmiennika z innej hali. Ktoś nie przyszedł, kierownik przesuwa obsadę. Wchodzi nowa procedura, kierownik wymienia ludzi po jednym, żeby taśma ani na chwilę nie stanęła.
Kubernetes jest tym kierownikiem zmiany, a stanowiska to serwery, na których działa Wasza aplikacja. Deklarujecie mu, ile kopii aplikacji ma pracować, a on to egzekwuje: kopia, która padnie, wraca na tej samej albo na innej maszynie, ruch rozkłada się między działające, a nowa wersja wchodzi po jednej kopii, więc użytkownik nie widzi przerwy. To jest cała obietnica i jest prawdziwa.
Cała reszta tego tekstu wynika z jednego pytania: czy Wasza hala ma tylu ludzi, żeby opłacało się zatrudniać do niej kierownika zmiany.
źródło: Unsplash, Frank EiffertProblem, który to rozwiązuje, brzmi konkretnie: aplikacji jest tyle, że nikt nie pamięta, na której maszynie stoi która, a ich liczba rośnie szybciej niż liczba ludzi w zespole.
Firma na kilkanaście stanowisk zwykle ma inny problem. Ma jedną aplikację, która musi działać w godzinach pracy, i serwer, którego nikt nie aktualizował od osiemnastu miesięcy. Przestój kosztuje tam nie sekundy, tylko godziny, i bierze się z braku kopii zapasowej albo z dysku, którego nikt nie monitorował. Kubernetes nie dotyka ani jednej z tych rzeczy. Kierownik zmiany nie zrobi kopii dokumentów i nie zauważy, że w magazynie kończy się miejsce, bo nie od tego jest.
Kubernetes w małej firmie odpowiada więc na pytanie, którego nikt tam nie zadał.
Brak klastra kosztuje w takiej firmie dokładnie zero. Zdanie to jest prawdziwe wyłącznie w tej jednej sprawie i nie jest zaproszeniem do niczego innego: brak kopii zapasowej, brak monitoringu i serwer bez poprawek kosztują tam bardzo dużo. Tyle że żadnej z tych trzech rzeczy klaster nie naprawia, a wszystkie trzy kosztują mniej niż on.
Odradzamy. To jest domyślna odpowiedź, od której zaczynamy każdą taką rozmowę.
Sześć sytuacji, w których mówimy „nie” bez zastanowienia:
# | Sytuacja | Dlaczego mówimy „nie” |
|---|---|---|
1 | Macie jedną albo dwie aplikacje | klaster do dwóch usług dokłada warstwę, którą trzeba rozumieć, żeby zrestartować rzecz działającą wcześniej jednym poleceniem |
2 | Wszystko stoi na jednym serwerze i tak zostanie | kierownik zmiany nie ma dokąd przesunąć obsady, bo hala jest jedna. Awaria maszyny zatrzymuje usługę tak samo jak bez klastra, zostaje sam skomplikowany sposób uruchamiania kontenerów |
3 | Nikt u Was nie czyta logów | klaster generuje ich kilkanaście razy więcej niż zwykły host i rozprasza je między obiekty, których trzeba umieć szukać |
4 | Aplikacja jest kupiona, nie pisana | producent, który nie dostarcza obrazów kontenerów, nie zacznie tego robić dlatego, że postawiliście klaster |
5 | Nie macie osoby na dyżurze | klaster naprawia się sam do momentu, w którym przestaje, a wtedy trzeba wiedzieć, dlaczego kontener nie wstaje |
6 | Powodem jest zdanie „wszyscy tak robią” | to jedyny powód, po którym kończymy rozmowę o technologii i wracamy do rozmowy o problemie |
Mogę Ci jakoś pomóc?
Próg, po którym w ogóle zaczynamy się zastanawiać, jest prosty i podajemy go wprost: co najmniej kilkanaście osobnych usług, wdrażanych częściej niż raz w miesiącu, plus co najmniej trzy węzły. Poniżej tego rachunek się nie spina i mówimy to na spotkaniu, a nie w ofercie.
Wolimy być firmą, która odradziła, niż firmą, która sprzedała klaster i zniknęła po odbiorze.
To jest cała nasza polityka handlowa w tym temacie.
Są trzy układy, w których Kubernetes przestaje być modą i staje się warunkiem wykonania roboty. Każdy z nich rozpoznaje się przed podpisaniem umowy, nie po.
Pierwszy: wymaga tego klient albo przetarg. Zdarza się, że warunek zapisany jest w specyfikacji zamówienia albo w umowie ramowej z odbiorcą, który sam prowadzi klastry i chce dostać usługę w tej samej formie. Wtedy nie ma o czym dyskutować, bo alternatywą nie jest prostsze rozwiązanie, tylko brak kontraktu. Sprawdzamy wyłącznie jedno: czy zapis mówi o Kubernetesie, czy o obrazie kontenera, bo to dwie różne rzeczy i drugą spełnia sam Docker.
Drugi: producent dostarcza aplikację wyłącznie w tej formie. Coraz więcej systemów branżowych rozsyłanych jest jako Helm chart albo operator, bez instalatora na maszynę i bez wsparcia dla innego sposobu uruchomienia. Zgłoszenie awarii kończy się wtedy pytaniem o wersję klastra. Postawienie klastra jest w takim układzie kosztem licencji tej aplikacji, tylko rozliczonym w godzinach zamiast w fakturze producenta.
Trzeci: zespół już tak pracuje. Firma z własnymi programistami, którzy wdrażają kilka razy w tygodniu i znają kubectl, nie potrzebuje przekonywania, tylko porządku: kopii zapasowych stanu klastra, monitoringu i procedury na dzień, w którym autor konfiguracji jest na urlopie. Nasza rola jest tam inna niż zwykle, bo nie budujemy, tylko przejmujemy.
Czwartego powodu nie ma. Skala, o której mówią materiały producenta, w firmie na 5 do 50 stanowisk po prostu nie występuje.
Ta sekcja ma formę pytań, bo dokładnie tak wygląda nasza pierwsza rozmowa techniczna. Odpowiedzi są tu ważniejsze od diagramów architektury.
Kto aktualizuje klaster i jak często? Kubernetes wydaje nową wersję mniej więcej trzy razy w roku, a poprawki do konkretnego wydania kończą się po czternastu miesiącach: przez pierwszych dwanaście idą normalnie, przez ostatnie dwa wychodzą już tylko poprawki krytyczne, potem wydanie jest martwe. Rachunek jest prosty i nieprzyjemny. Klaster postawiony i zostawiony samemu sobie mija termin ważności przed drugimi urodzinami, a firma dowiaduje się o tym przy pierwszym audycie. Aktualizacja nie jest przy tym kliknięciem, bo razem z wersją zmieniają się wersje interfejsów sterujących klastrem, a plik konfiguracji napisany dwa lata temu potrafi po niej przestać się wczytywać.
Gdzie leżą dane? Kontener jest z założenia jednorazowy i to jest jego zaleta do chwili, w której trzyma w sobie bazę danych. Trwałe dane wymagają magazynu podpiętego do klastra, a ten magazyn jest osobnym systemem z własną awaryjnością. Bazę danych częściej zostawiamy poza klastrem i nie uważamy tego za porażkę.
Kto ma dostęp do panelu i skąd? API klastra wystawione do internetu bez drugiego składnika logowania to jedno z tych ustawień, które działają idealnie do dnia, w którym ktoś je znajdzie. Konta serwisowe z nadmiarowymi uprawnieniami są tu regułą, nie wyjątkiem.
Co robi klaster, gdy zabraknie pamięci? Zabija kontener, który przekroczył limit, i uruchamia go ponownie. Bez ustawionych limitów zabija ten, który akurat był największy, czyli często nie ten, który zawinił. Ustawienie limitów jest robotą na godziny i nikt nie robi jej z przyjemnością.
Mogę Ci jakoś pomóc?
Czego nie lubimy w tej technologii? Tego, że błędne polecenie nie jest odrzucane. Kubernetesowi nie wydaje się rozkazów, tylko składa się u niego zamówienie: „ma pracować pięć kopii tej aplikacji”. Jeśli w zamówieniu jest literówka albo warunek nie do spełnienia, klaster nie odpowiada „nie mamy” i nie odmawia. Przyjmuje zamówienie i czeka, w nieskończoność, dokładnie tak jak kelner, który zapisał danie i nigdy go nie przyniesie, a Wy siedzicie przy stole i nie wiecie, czy kuchnia pracuje, czy nie. Usługa wygląda w panelu na uruchomioną, a nie odpowiada nikomu, i szukanie powodu zaczyna się w logach, nie w komunikacie o błędzie.
Do serwera, systemu i aplikacji dochodzą sieć klastra, magazyn, kontroler ruchu przychodzącego, certyfikaty i rejestr obrazów. Każda z nich ma własne wydania i własne wsteczne niezgodności.
Kolejność jest zawsze ta sama i pierwszy krok najczęściej kończy projekt, zanim się zacznie. Uważamy to za wynik pozytywny.
Kroki 1 i 2 są nierozłączne i nie da się ich przeskoczyć na życzenie. Pilot kosztuje ułamek projektu i odpowiada na pytanie, którego żadna prezentacja nie rozstrzygnie: czy Wasza aplikacja w ogóle nadaje się do takiego uruchomienia.
Klaster jest usługą utrzymaniową, nie projektem, który się kończy. Tym różni się od wdrożenia serwera pocztowego albo firewalla.
Praca bieżąca dzieli się na cztery rzeczy:
Monitoring jest tu warstwą osobną i nie jest częścią klastra. Piszemy o tym szerzej przy okazji monitoringu infrastruktury , bo zasada jest wspólna dla całej serwerowni: to, czego nikt nie mierzy, psuje się najciszej.
Ten rytm jest jedynym powodem, dla którego klaster po dwóch latach dalej działa.
Alternatywy są dwie i obie wygrywają z Kubernetesem częściej, niż wynikałoby to z liczby artykułów w internecie.
Docker z Compose: to jest domyślna odpowiedź dla firmy na 5 do 50 stanowisk. Dostajecie to samo środowisko na teście i na produkcji, wdrożenie nowej wersji w minutę i powrót do poprzedniej w tyle samo, a całość mieści się w jednym pliku, który da się przeczytać w pięć minut. Traci wtedy, gdy padnie host, bo nie ma dokąd przenieść kontenerów. Dla większości naszych klientów ta strata jest akceptowalna, bo drugi host kosztuje mniej niż kompetencja potrzebna do klastra. Zakres takiej roboty opisuje strona konteneryzacji aplikacji .
Mogę Ci jakoś pomóc?
Zwykła maszyna wirtualna: wygrywa przy aplikacji kupionej i rzadko aktualizowanej. System, instalator producenta, kopia całej maszyny raz na dobę i migawka przed każdą zmianą. Odtworzenie takiej maszyny rozumie każdy informatyk, także ten, który przyjdzie po nas. Przy jednej aplikacji, którą producent aktualizuje dwa razy w roku, kontener nie dokłada niczego poza nową rzeczą do nauczenia. Jest to najczęstsza rekomendacja, jaką wydajemy po pierwszej rozmowie, i stoi za nią zwykła wirtualizacja serwerów .
Kubernetes: wygrywa przy kilkunastu usługach, częstych wdrożeniach i realnym wymogu ciągłości. Poniżej tego progu przegrywa z obiema powyższymi rzeczami, i to nie na wydajności, tylko na liczbie osób w Polsce, które potrafią go naprawić o drugiej w nocy.
Kryterium rozstrzygające jest jedno i nie dotyczy technologii: policzcie, ile razy w ostatnim kwartale ktoś wdrażał u Was nową wersję czegokolwiek. Jeśli odpowiedź brzmi „dwa razy”, klaster rozwiąże problem, którego nie macie.
Sam Kubernetes jest wolnym oprogramowaniem i nie ma opłaty licencyjnej. To jest pierwsze zdanie każdej oferty i jednocześnie najmniej istotne.
Rachunek robią trzy pozycje, których w żadnym cenniku nie ma:
Dla porównania: aplikacja zapakowana w kontener i uruchomiona bez klastra to u nas wydatek od 3 900 zł netto jednorazowo (stan na 14 sierpnia 2026), a opieka nad hostem z kontenerami mieści się w tych samych 250 zł netto miesięcznie co każdy inny serwer. Klaster wyceniamy osobno, bo to inna skala projektu i inny zakres opieki.
Kwoty za naszą pracę bieżącą stoją na stronie administracji serwerami i liczą się z konfiguracji, więc nie przepisujemy ich do tekstu, który zestarzeje się szybciej niż cennik.
Wszystkie pięć to błędy, które popełnia się raz, a płaci się za nie przez rok. Żaden nie jest egzotyczny.
# | Błąd | Czym się kończy |
|---|---|---|
1 | Klaster na jednym węźle | firma płaci za złożoność i dostaje tę samą dostępność co przy zwykłym hoście. Awaria maszyny zatrzymuje wszystko, tylko odtworzenie trwa dłużej, bo trzeba jeszcze odtworzyć klaster |
2 | Baza danych w kontenerze bez trwałego magazynu | utrata danych przy pierwszym przeniesieniu kontenera na inny węzeł. To jest ten rodzaj awarii, po której nie ma czego odtwarzać, bo kopia nigdy nie objęła tego miejsca |
3 | Brak limitów pamięci i procesora | jedna aplikacja z wyciekiem pamięci zabija wszystkie pozostałe na tym samym węźle, a klaster robi dokładnie to, co mu kazano |
4 | Manifesty poza repozytorium | środowisko, którego stan zna wyłącznie klaster. Odtworzenie po awarii polega wtedy na odgadywaniu, co ktoś wpisał ręcznie osiemnaście miesięcy temu |
5 | Panel i API wystawione do internetu | przejęcie całego środowiska, bo uprawnienia w klastrze są z natury szerokie, a konta serwisowe rzadko bywają zawężane |
Dostęp do panelu i API zamykamy do sieci wewnętrznej i drugiego składnika logowania, tak samo jak przy każdym innym panelu administracyjnym.
Szósty błąd jest nietechniczny i najdroższy: postawienie klastra, zanim ktokolwiek policzył liczbę usług i częstotliwość wdrożeń.
Lista jest krótka celowo, bo każda pozycja jest sprawdzalna:
Ostatni punkt jest częścią oferty. Nie jest uprzejmością.
Czy Kubernetes jest darmowy? Samo oprogramowanie tak, i wolno go używać komercyjnie bez opłat. Płatne są maszyny, na których działa, oraz czas ludzi, którzy go rozumieją. W firmie na kilkanaście stanowisk to drugie jest wielokrotnie droższe od pierwszego.
Czy da się uruchomić klaster na jednym serwerze? Da się i technicznie działa, tylko nie daje tego jednego, po co klastry powstały: żeby awaria jednej maszyny nie zatrzymała usługi. Przy jednym serwerze nie ma dokąd przenieść pracy, więc zostaje sam narzut złożoności. W takim układzie rekomendujemy Docker Compose i mówimy to wprost.
Czym różni się Kubernetes od Dockera? Docker pakuje aplikację razem z jej wyposażeniem i uruchamia ją na jednej maszynie. Kubernetes nikogo nie pakuje: to kierownik zmiany, który dostaje gotowe paczki od Dockera i rozstawia je po wielu maszynach, pilnując, ile kopii ma pracować i gdzie. Jedno nie zastępuje drugiego, bo klaster uruchamia dokładnie te obrazy, które zbudował Docker.
Czy potrzebujemy własnego informatyka, żeby to utrzymać? Potrzebujecie kogoś, kto to rozumie, i nie musi to być osoba z Waszej listy płac. Utrzymanie zlecane na zewnątrz jest tu regułą, tak samo jak przy serwerach. Firma bez jednego i bez drugiego nie powinna stawiać klastra.
Czy Kubernetes pomaga spełnić wymagania NIS 2 albo RODO? Sam z siebie nie zmienia niczego w tych obowiązkach. Wymóg aktualizacji, kontroli dostępu i ciągłości działania dotyczy każdego środowiska, a klaster dokłada tu kolejne komponenty do łatania. Przy danych osobowych liczy się dodatkowo to, w jakim kraju stoją węzły i gdzie leżą kopie.
Co się dzieje, gdy padnie jeden węzeł? Klaster przenosi kontenery na pozostałe maszyny i usługa wraca w kilkadziesiąt sekund, pod dwoma warunkami: maszyn jest co najmniej trzy i dane leżą w magazynie dostępnym z każdej z nich. Przy dwóch maszynach ten mechanizm bywa gorszy od jego braku, bo do rozstrzygnięcia, która z nich jest sprawna, potrzeba większości, a dwie maszyny większości nie utworzą i obie ruszają do pracy naraz.
Czy można wycofać się z Kubernetesa? Można, bo aplikacja siedzi w obrazach kontenerów, a te uruchomi też zwykły host z Dockerem. Powrót jest tańszy od wejścia i to jest dobra wiadomość. Kosztem zostaje czas poświęcony na naukę czegoś, czego firma ostatecznie nie używa.
Umówcie rozmowę, na której policzymy Wasze usługi, wdrożenia i okna serwisowe. Po niej dostajecie pisemną rekomendację z jednym z trzech werdyktów:
Rekomendacja jest Wasza także wtedy, gdy brzmi „nie róbcie tego” i gdy nie zamawiacie u nas nic więcej.
Rozmowę umawiacie przez formularz kontaktowy albo telefonicznie. Biuro główne mamy w Gorzowie Wielkopolskim i stamtąd obsługujemy klientów lokalnie , a klaster i tak prowadzi się zdalnie.
Mogę Ci jakoś pomóc?
Zestaw zmienia się codziennie, więc przy kolejnej wizycie zobaczysz inny wycinek bloga.
Luka typu cross-site scripting w Roundcube Webmail, oznaczona CVE-2025-68461, jest wpisana do katalogu CISA KEV jako aktywnie wykorzystywana. Poniżej znajdziesz mechanizm ataku, listę zagrożonych wersji i potwierdzone sposoby naprawy.
Czytaj artykułLuka CVE-2026-22719 w VMware Aria Operations pozwala niezalogowanemu atakującemu wykonać dowolne polecenia, ale tylko w jednym oknie czasowym. Ten tekst pokazuje, które wersje produktów VMware są zagrożone, co oznacza wpis do katalogu CISA KEV i jakie działania podjąć najpierw.
Czytaj artykułCVE-2026-3055 to podatność urządzeń Citrix NetScaler ADC i Gateway, wykorzystywana w atakach od dnia publikacji. Tekst wyjaśnia mechanizm błędu, warunek zagrożenia, różnice w danych o wersjach naprawionych oraz działania, które należy podjąć w trybie pilnym.
Czytaj artykułKrótka rozmowa wystarczy, żeby ocenić zakres prac i podać widełki kosztu. Bez zobowiązań.
Klikając „Akceptuję”, zgadzasz się na przechowywanie plików cookie przez UXU w celu poprawy działania strony, analizy i wsparcia działań marketingowych.