Utrzymanie i administracja Kubernetes — zarządzany klaster dla firm
Przejmujemy odpowiedzialność za Twój klaster Kubernetes: monitoring z alertami, aktualizacje wersji, kopie zapasowe z testami odtwarzania, bezpieczeństwo i reakcję na awarie według SLA. Bez budowania własnego zespołu DevOps i bez uzależnienia od jednej osoby, która „wie, jak to działa”.
- Stała opieka w abonamencie miesięcznym
- SLA z czasem reakcji w umowie
- On-premise i chmura RKE2, k3s, EKS, GKE, AKS
Zarządzana usługa Kubernetes — kiedy warto ją zlecić
Kubernetes nie kończy się na wdrożeniu. Co kilka miesięcy wychodzi nowa wersja, a każda jest wspierana przez około rok. Certyfikaty wygasają, dyski się zapełniają, komponenty takie jak ingress czy cert-manager mają własne cykle aktualizacji i podatności. Klaster zostawiony sam sobie po roku jest nieaktualny, a po dwóch — niebezpieczny.
Zarządzany Kubernetes w chmurze (EKS, GKE, AKS) zdejmuje z Ciebie tylko część pracy: dostawca dba o control plane, ale węzły, aplikacje, dodatki, backup, monitoring i bezpieczeństwo nadal są po Twojej stronie. Przy klastrze na własnych serwerach odpowiadasz za wszystko. Tę lukę wypełnia nasza usługa utrzymania.
- Klaster postawił poprzedni zespół lub freelancer, który już nie jest dostępny.
- Masz deweloperów, ale nikogo, kto odpowiada za platformę, aktualizacje i dyżur przy awariach.
- Sklep internetowy lub SaaS na Kubernetes, gdzie każda godzina przestoju to realna strata sprzedaży.
- Aktualizacje są odkładane, bo „działa, więc lepiej nie ruszać”.
- Audytor, klient lub przepisy (NIS2, RODO) wymagają udokumentowanego procesu utrzymania.
- Chcesz przewidywalny miesięczny koszt zamiast etatu DevOps i ryzyka jego odejścia.
Co obejmuje utrzymanie klastra Kubernetes
Zakres dopasowujemy do klastra i wymagań firmy, ale poniższe elementy są podstawą każdej umowy. Zmiany wprowadzane w klastrze zapisujemy w repozytorium z konfiguracją, więc mają autora i historię.
Monitoring i alerty
Prometheus, Grafana i Alertmanager ustawione na objawy, które mają znaczenie dla biznesu: dostępność aplikacji, błędy, opóźnienia, zapełnienie dysków, wygasające certyfikaty. Alerty trafiają do nas, a nie tylko na pulpit, którego nikt nie ogląda.
Aktualizacje Kubernetes
Planowe podnoszenie wersji klastra, zanim wypadnie z okresu wsparcia — najpierw na środowisku testowym, potem na produkcji, węzeł po węźle, bez przestoju aplikacji.
Aktualizacje dodatków i systemów
Ingress, cert-manager, CNI, storage, monitoring, Argo CD oraz systemy operacyjne węzłów. Śledzimy podatności i łatamy krytyczne poprawki poza normalnym cyklem.
Backup i testy odtwarzania
Kontrola kopii zapasowych klastra i danych aplikacji, przechowywanie ich poza klastrem oraz testy odtwarzania w zakresie ustalonym w umowie.
Reakcja na awarie
Diagnoza i usuwanie problemów z klastrem na zasadach i w czasie reakcji określonych w umowie.
Bezpieczeństwo i dostępy
Przegląd RBAC i kont, rotacja sekretów i certyfikatów, skanowanie obrazów, polityki bezpieczeństwa, dostęp dla nowych członków zespołu i odbieranie go odchodzącym.
Pojemność i koszty
Obserwacja zużycia zasobów, porządkowanie limitów i requestów, rekomendacje co do rozbudowy węzłów — lub ich redukcji, jeśli płacisz za zapas, którego nie potrzebujesz.
Wsparcie dla deweloperów
Pomoc przy nowych usługach, pipeline CI/CD, problemach z wdrożeniem i konfiguracją. Twój zespół pisze aplikację, my pilnujemy, żeby platforma jej nie przeszkadzała.
Przejrzystość zamiast czarnej skrzynki
Konfiguracja klastra jest w Twoim repozytorium, a zakres prac i sposób informowania o nich ustalamy indywidualnie w umowie. Dzięki temu wiesz, co dzieje się na Twoim klastrze, a wiedza o środowisku nie znika razem z jedną osobą.
Jak przejmujemy klaster po innym zespole
Większość klientów przychodzi z działającym klastrem, o którym nikt nie wie wszystkiego. Zanim weźmiemy odpowiedzialność za produkcję, musimy go poznać — dlatego przejęcie zawsze ma osobny, krótki etap wejściowy.
Dostępy i inwentaryzacja
Zbieramy dostępy, listę węzłów, aplikacji, dodatków i wersji. Sprawdzamy, gdzie jest konfiguracja: w repozytorium, w głowie poprzednika czy tylko w samym klastrze.
Audyt stanu
Wersje i terminy końca wsparcia, stan backupu, bezpieczeństwo, certyfikaty, zużycie zasobów. Wynik to lista ryzyk z priorytetami — to samo, co w naszym audycie Kubernetes.
Naprawy krytyczne
Najpierw rzeczy, które mogą zatrzymać firmę: niedziałające kopie, wygasające certyfikaty, brak monitoringu, wersja bez wsparcia.
Konfiguracja jako kod
Przenosimy ręczne zmiany do repozytorium (Helm, Kustomize, Terraform, Argo CD), żeby każda zmiana miała historię i dało się ją odtworzyć.
Dokumentacja i runbooki
Opis architektury, procedury na typowe awarie i kontakt eskalacyjny. Ta dokumentacja jest Twoja, także jeśli kiedyś zmienisz dostawcę.
Stała opieka
Od tego momentu działamy według umowy: w zakresie ustalonym w umowie — monitoring, aktualizacje, kopie zapasowe i reakcja na awarie.
Stała opieka, zlecenia doraźne czy własny etat DevOps?
Nie ma jednej dobrej odpowiedzi — zależy od wielkości klastra, liczby zmian i tego, jak krytyczne są aplikacje. Poniżej uczciwe porównanie, które przedstawiamy także na konsultacji.
| Kryterium | Stała opieka mIT group | Zlecenia doraźne | Własny etat DevOps |
|---|---|---|---|
| Koszt | stały, przewidywalny abonament | płacisz tylko za zadania | wynagrodzenie, rekrutacja, szkolenia |
| Reakcja na awarię | według SLA w umowie | gdy znajdzie się termin | gdy osoba jest dostępna |
| Aktualizacje i backup | planowe, w zakresie umowy | gdy je zlecisz | zależnie od obciążenia |
| Ryzyko odejścia wiedzy | niskie — dokumentacja i zespół | średnie | wysokie przy jednej osobie |
| Najlepsze dla | produkcja, e-commerce, SaaS | małe klastry, rzadkie zmiany | duże platformy, wiele zespołów |
Często łączymy modele: Twój administrator lub deweloper zajmuje się codziennością, a my odpowiadamy za aktualizacje, backup, bezpieczeństwo i dyżur przy poważnych awariach. Opiekę nad klastrem możemy też połączyć z administracją serwerami Linux i całą obsługą informatyczną firmy — wtedy masz jednego partnera od serwerowni, sieci i platformy.
Opieka nad klastrem on-premise i serwerownią
Klaster na własnych serwerach to także sprzęt: dyski, zasilacze, firmware, sieć, UPS i klimatyzacja. Tu mamy przewagę nad firmami, które znają Kubernetes tylko z chmury — od lat dobieramy, wdrażamy i serwisujemy serwery w firmach. Adam Mirowski odpowiada za dobór i wdrożenia serwerów, a w ramach opieki pilnujemy ich stanu razem z klastrem.
- Monitoring sprzętu serwerów (iDRAC, XClarity), dysków i zasilania razem z klastrem.
- Aktualizacje firmware i BIOS zsynchronizowane z oknami serwisowymi klastra.
- Obsługa gwarancji i wymiana podzespołów w serwerach Dell i Lenovo.
- Kopie zapasowe poza klastrem na serwerach Synology, zgodnie z zasadą 3-2-1.
- Planowanie rozbudowy: nowe węzły, dyski, sieć 10/25 GbE, zanim zabraknie zasobów.
Jedna odpowiedzialność za całość
Gdy awaria dotyczy jednocześnie aplikacji, Kubernetes i dysku w serwerze, najgorsze, co może się zdarzyć, to trzy firmy wskazujące na siebie nawzajem. W modelu opieki mIT group możemy zająć się całą ścieżką — od sprzętu w szafie, przez system na węźle, po klaster — w zakresie ustalonym w umowie. Dla firm z Łodzi i okolic oznacza to też szybki przyjazd do serwerowni, gdy potrzebna jest fizyczna interwencja.
Kto opiekuje się Twoim klastrem
Odpowiedzialność techniczną za opiekę nad klastrami ma Adam Mirowski, CTO mIT group — ustala standardy, zatwierdza zmiany na produkcji i decyduje o sprzęcie. Michał Szapiel jest Twoim opiekunem po stronie biznesowej: umowa, zakres, raporty i rozbudowa współpracy. Przy utrzymaniu współpracujemy też ze sprawdzonymi, zewnętrznymi inżynierami DevOps, z którymi mamy za sobą wspólne projekty — dzięki temu łatwiej zapewnić ciągłość opieki, a do nietypowych problemów (np. Ceph, sieć Cilium, EKS) dobieramy specjalistę z właściwym doświadczeniem.
Utrzymanie Kubernetes w Łodzi i w całej Polsce
Opieka nad klastrem odbywa się w przeważającej części zdalnie: przez bezpieczne połączenie VPN, repozytorium z konfiguracją i system monitoringu. Dlatego obsługujemy firmy z całego kraju na tych samych zasadach. Firmy z Łodzi i województwa łódzkiego zyskują dodatkowo szybki dojazd do serwerowni przy klastrach on-premise oraz możliwość spotkań i przeglądów kwartalnych w naszym biurze przy ul. Brukowej 8.
Jeśli dopiero planujesz klaster, zacznij od strony o wdrożeniu Kubernetes. Jeśli masz aplikacje na maszynach wirtualnych i chcesz je przenieść, zobacz migrację do Kubernetes. Szerszy kontekst znajdziesz w artykule Kubernetes dla firmy.
Najczęstsze pytania o utrzymanie Kubernetes
Czym różni się utrzymanie Kubernetes od zarządzanego klastra w chmurze?
Zarządzany klaster, np. AWS EKS czy Google GKE, oznacza, że dostawca chmury utrzymuje control plane. Węzły robocze, dodatki (ingress, cert-manager, monitoring), aplikacje, backup, dostępy i planowanie aktualizacji nadal są po Twojej stronie. Nasza usługa utrzymania obejmuje właśnie tę część, której chmura nie robi. Przy klastrze on-premise obejmuje całość, łącznie z control plane i sprzętem.
Jak często trzeba aktualizować Kubernetes?
Projekt Kubernetes wydaje nową wersję mniej więcej co cztery miesiące i wspiera każdą przez około rok. W praktyce oznacza to przynajmniej jedną, a zwykle dwie większe aktualizacje klastra rocznie, plus częste poprawki bezpieczeństwa. Wersji nie da się przeskakiwać dowolnie — podnosi się je po kolei. Dlatego planujemy aktualizacje z wyprzedzeniem i testujemy je na środowisku testowym przed produkcją.
Czy możecie przejąć klaster, którego nikt nie dokumentował?
Tak, to najczęstszy scenariusz. Zaczynamy od etapu wejściowego: dostępy, inwentaryzacja, audyt stanu i naprawy krytyczne. Następnie przenosimy konfigurację do repozytorium i tworzymy dokumentację. Dopiero wtedy przechodzimy na stałą opiekę z SLA — nie bierzemy odpowiedzialności za system, którego nie znamy.
Jaki jest czas reakcji na awarię?
Czas reakcji zapisujemy w umowie i dopasowujemy do tego, jak krytyczne są Twoje aplikacje. Inne wymagania ma wewnętrzny system raportowy, a inne sklep internetowy w trakcie kampanii. Na konsultacji ustalamy, które awarie wymagają natychmiastowej reakcji, a które mogą poczekać do godzin pracy.
Czy utrzymanie obejmuje aplikacje, czy tylko klaster?
Standardowo odpowiadamy za platformę: klaster, węzły, dodatki, backup, monitoring i bezpieczeństwo. Kod aplikacji zostaje po stronie Twoich deweloperów, ale pomagamy im przy wdrożeniach, konfiguracji, pipeline CI/CD i diagnozie problemów na styku aplikacji i klastra. Zakres możemy rozszerzyć np. o bazy danych czy kolejki uruchomione w klastrze.
Ile kosztuje utrzymanie Kubernetes?
Nie publikujemy cennika, bo koszt zależy od liczby klastrów i węzłów, wymaganego czasu reakcji, tego, czy klaster jest on-premise, oraz zakresu (sam klaster czy także serwery i sieć). Stała opieka jest rozliczana w miesięcznym abonamencie, więc koszt jest przewidywalny. Wycenę przygotowujemy bezpłatnie po krótkiej rozmowie lub po audycie wejściowym.
Czy możemy zrezygnować i przejąć klaster sami?
Tak. Cała konfiguracja jest w Twoim repozytorium, dokumentacja i runbooki należą do Ciebie, a dostępy są na Twoich kontach. Przy zakończeniu współpracy przekazujemy środowisko uporządkowane i opisane. Nie budujemy uzależnienia od siebie — to jedna z naszych stałych zasad.
Czy opiekujecie się klastrami poza Łodzią?
Tak, opiekujemy się klastrami w całej Polsce, bo praca odbywa się zdalnie. W przypadku klastrów na własnych serwerach poza Łodzią fizyczne prace (wymiana dysków, rozbudowa) planujemy z wyprzedzeniem albo koordynujemy z serwisem producenta w ramach gwarancji. Firmy z Łodzi i okolic mają dodatkowo możliwość szybkiego przyjazdu do serwerowni.
Oddaj klaster w dobre ręce
Napisz, jaki masz klaster, ile aplikacji na nim działa i co dziś sprawia najwięcej problemów. Zaproponujemy zakres opieki i etap przejęcia — bezpłatnie i bez zobowiązań.
albo napisz: biuro@mitgroup.pl · zobacz też wszystkie usługi