← Wszystkie tematy W 11% ogłoszeń · 5 z 47 ogłoszeń frontend React

Kubernetes

Opiekunka, która pilnuje, żeby zawsze bawiło się tyle samo dzieci

Kubernetes pojawia się w 5 z 47 ogłoszeń, zwykle jako „mile widziane”. Od frontendowca nikt nie oczekuje administrowania klastrem, ale słownictwo i to, jak trafia tam aplikacja, warto znać.

Przerobione Opanowane 0 z 4 pytań

Ucz się z Claude Wytłumacz od zera Próbna rozmowa Zadanie praktyczne Ściąga na 1 stronę

Co piszą w ogłoszeniach

„Familiarity with containerized application environments (Docker/Kubernetes/OpenShift) and modern CI/CD pipelines.”
Experis Manpower Group · Senior Design Engineer – React/TypeScript
„Experience working with modern CI/CD environments and containerized applications using technologies such as Docker, Kubernetes or OpenShift”
DCG · Senior UI/UX Design & Front-End Lead
„Doświadczenie w pracy z Docker/Kubernetes,”
BlueSoft · Tech Lead React

Scena · pody, Deployment, Service

Opiekunka, która liczy dzieci

W sali bawią się dzieci. Każde dziecko to pod: jedna uruchomiona kopia Twojej aplikacji. Opiekunka (Deployment) ma kartkę: „ma się bawić tyle dzieci, w tej wersji”. Gdy jedno dziecko wyjdzie, opiekunka od razu przyprowadza nowe. Goście nie szukają dzieci sami, tylko pytają w recepcji (Service), a recepcja kieruje ich do któregoś z gotowych dzieci.

Recepcja (Service) czeka na gości

Kartka opiekunki (Deployment)

Ile dzieci 3

Zabierz dziecko i patrz, co zrobi opiekunka.

Porównajmy

Jeden serwer czy Kubernetes?

	Jeden serwer	Kubernetes
Gdy aplikacja padnie	Leży, aż ktoś ją podniesie.Ręczny restart, telefon w nocy.	Opiekunka od razu przyprowadza nowe dziecko.Kontroler Deployment/ReplicaSet utrzymuje zadaną liczbę podów, liveness probe restartuje zawieszone.
Więcej gości	Większy serwer.Skalowanie w pionie.	Więcej dzieci tego samego rodzaju.replicas albo HorizontalPodAutoscaler po CPU lub ruchu.
Nowa wersja	Przerwa techniczna.Stop, wgraj, start.	Dzieci wymieniane po kolei, sala nigdy nie jest pusta.Rolling update, maxUnavailable / maxSurge, readiness probe, `kubectl rollout undo`.
Jak goście trafiają?	Pod jeden stały adres.	Przez recepcję, która zna wszystkie gotowe dzieci.Service ze stałym adresem i load balancingiem, Ingress z zewnątrz.
A frontendowiec?		Zwykle tylko zagląda, ale warto rozumieć słowa.Obraz Dockera z nginx lub Node (SSR), zmienne środowiskowe przez ConfigMap/Secret, logi przez `kubectl logs`.

Pod

Jedno dziecko: jedna działająca kopia aplikacji w kontenerze.

Deployment

Opiekunka z kartką: ile dzieci i w jakiej wersji. Sama pilnuje, żeby się zgadzało.

Service

Recepcja ze stałym adresem. Kieruje gości do gotowych dzieci.

Sprawdź się

Pytania z rozmów

Najpierw odpowiedz na głos, dopiero potem rozwiń odpowiedź.

Pod, Deployment, Service: co robi każde z nich, w jednym zdaniu?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Pod to jedno dziecko w sali, Deployment to opiekunka z kartką, ile dzieci ma się bawić, a Service to recepcja, która kieruje gości do gotowych dzieci.

Na rozmowę: Pod: najmniejsza jednostka, jeden lub kilka kontenerów ze wspólną siecią, ulotny i wymienny. Deployment: deklaruje obraz i liczbę replik, a kontroler (przez ReplicaSet) utrzymuje ten stan, robi rolling update i rollback. Service: stały adres DNS i load balancing do podów wybranych labelem, niezależnie od tego, że pody się zmieniają. Ruch z zewnątrz zwykle przez Ingress lub Gateway.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające

Jak wygląda wdrożenie nowej wersji bez przerwy w działaniu (rolling update)?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Opiekunka wymienia dzieci po jednym: najpierw wchodzi nowe, dopiero gdy jest gotowe do zabawy, wychodzi stare. Sala nigdy nie jest pusta.

Na rozmowę: Zmieniam obraz w Deploymencie (np. przez CI lub GitOps z Argo CD). Strategia RollingUpdate z maxSurge i maxUnavailable tworzy nowe pody i usuwa stare stopniowo. Kluczowa jest readinessProbe: Service kieruje ruch tylko do podów gotowych, więc zepsuta wersja nie dostanie ruchu, a rollout stanie. Cofnięcie: kubectl rollout undo. Dla frontendu SSR ważne jest, żeby stare i nowe pody przez chwilę serwowały różne wersje, więc assety z hashami trzymam na CDN dłużej.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające
Czym są liveness i readiness probe i dlaczego aplikacja SSR powinna je mieć?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Opiekunka co chwilę pyta dziecko: „żyjesz?” i „możesz się już bawić z gośćmi?”. Na pierwsze pytanie bez odpowiedzi wymienia dziecko, a po drugim przestaje przysyłać do niego gości.

Na rozmowę: livenessProbe sprawdza, czy proces żyje. Gdy pada (np. zawieszony event loop), kubelet restartuje kontener. readinessProbe sprawdza, czy pod może przyjmować ruch (np. rozgrzany cache, połączenie z API). Do tego czasu Service go omija. startupProbe daje czas na wolny start. Dla Next.js lub innego serwera Node wystawiam lekki endpoint /healthz (liveness) i /ready (readiness), bez ciężkich zależności, żeby awaria jednego backendu nie restartowała wszystkich podów.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające
Jak przekazać konfigurację i sekrety do aplikacji frontendowej w Kubernetes?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Kartka z ustawieniami wisi na ścianie sali, a klucze do szafki trzyma opiekunka w zamkniętej szufladzie. Dziecko dostaje tylko to, co mu wolno.

Na rozmowę: ConfigMap dla zwykłej konfiguracji i Secret dla haseł i kluczy, wstrzykiwane jako zmienne środowiskowe albo pliki. Uwaga na frontend: zmienne wbudowane w bundle przy buildzie (VITE_*, NEXT_PUBLIC_*) są publiczne i ustalone w obrazie, więc albo buduję obraz per środowisko, albo serwuję konfigurację runtime (np. /config.json lub wstrzyknięcie do HTML przez serwer). Sekretów nigdy nie wkładam do kodu klienta.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające

Poziom wyżej

Wersja dla seniora

Tak wyglądają pytania na seniora i leada: nie ma jednej dobrej odpowiedzi, liczy się to, jak ważysz kompromisy i czy mówisz o skali, ryzyku i ludziach.

Przypadek 1

Next.js na Kubernetesie pada w szczycie promocji

Sklep z SSR w Next.js działa na Kubernetesie z HPA na CPU. W Black Friday ruch rośnie 8 razy w 10 minut, nowe pody startują 90 sekund, a w tym czasie TTFB rośnie do 6 s i część żądań kończy się 502.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

Czy rozumiesz, dlaczego autoskalowanie reaguje za późno
Czy łączysz infrastrukturę z architekturą renderowania
Czy planujesz testy obciążeniowe i przygotowanie przed zdarzeniem

Odpowiedź seniora

HPA na CPU reaguje dopiero po wzroście obciążenia, a 90 sekund startu to okno, w którym istniejące pody się duszą. Działam na trzech poziomach.

Mniej pracy dla serwera: strony katalogu i produktów na ISR lub cache SSR w CDN z stale-while-revalidate, więc większość ruchu nie dochodzi do podów. Szybszy start: mniejszy obraz (output standalone), brak ciężkiej pracy przy starcie, readiness probe, która przepuszcza ruch dopiero po rozgrzaniu. Lepsze skalowanie: minimalna liczba replik podniesiona przed promocją (zaplanowane skalowanie lub KEDA z harmonogramem), skalowanie po metrykach bliższych użytkownikowi (liczba żądań, opóźnienie) zamiast samego CPU, rezerwa węzłów w klastrze (cluster autoscaler też potrzebuje czasu).

Przed zdarzeniem test obciążeniowy (k6) z realnym profilem ruchu i ustalone SLO, np. p95 TTFB poniżej 800 ms. W trakcie dashboard i osoba dyżurna.

Typowe wpadki

Tylko podniesienie limitów CPU
Ignorowanie czasu startu poda i węzła
Brak cache dla stron, które są takie same dla wszystkich

Dopytają o

Jak ustawisz requests i limits dla Node.js?
Co zrobisz, jeśli wąskim gardłem okaże się API, a nie SSR?
Jak przetestujesz, że cache nie pokaże nieaktualnych cen?

Zapytaj Claude Rozwiń case Zagraj interviewera

Przypadek 2

Przy każdym wdrożeniu część użytkowników dostaje błędy

Podczas rolling update aplikacji SSR przez około minutę pojawiają się błędy 502 i zerwane połączenia SSE. Monitoring pokazuje, że stare pody są zabijane, gdy wciąż obsługują żądania, a nowe dostają ruch, zanim są gotowe.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

Czy znasz cykl życia poda i sygnały zakończenia
Czy odróżniasz liveness od readiness i wiesz, jak je ustawić
Czy myślisz o długich połączeniach

Odpowiedź seniora

Nowe pody: readiness probe na endpoint, który zwraca 200 dopiero po pełnym starcie (załadowana konfiguracja, połączenia gotowe). Liveness ustawiam ostrożniej i nie uzależniam jej od zewnętrznych usług, żeby awaria API nie restartowała wszystkich podów. Do tego startupProbe dla wolnego startu.

Stare pody: aplikacja obsługuje SIGTERM, przestaje przyjmować nowe połączenia i kończy trwające żądania. Ponieważ usunięcie poda z endpointów Service trwa chwilę, dodaję hook preStop z krótkim sleepem, żeby ruch przestał przychodzić, zanim proces zacznie się zamykać. terminationGracePeriodSeconds dobieram do najdłuższych żądań. Połączenia SSE i WebSocket zamykam z sygnałem dla klienta, który łączy się ponownie z innym podem.

Strategia rollout: maxUnavailable 0 i maxSurge 25%, PodDisruptionBudget, żeby prace na węzłach nie zabiły wszystkich replik naraz. Weryfikuję to testem: wdrożenie pod stałym ruchem syntetycznym i zero błędów jako kryterium.

Typowe wpadki

Liveness sprawdzająca bazę danych
Brak obsługi SIGTERM w serwerze Node
Takie same ustawienia probe dla liveness i readiness

Dopytają o

Jak zrobisz canary release dla frontendu?
Co z użytkownikami, którzy mają otwartą starą wersję aplikacji?
Jak długo powinien trwać grace period?

Zapytaj Claude Rozwiń case Zagraj interviewera

Przypadek 3

Jeden obraz dla dev, staging i produkcji

Obecnie frontend jest budowany osobno dla każdego środowiska, bo adres API i klucze są wkompilowane w bundle (VITE_ i NEXT_PUBLIC_). Na produkcję trafia więc inny artefakt niż ten przetestowany na stagingu. Zespół platformy wymaga jednego obrazu promowanego między środowiskami.

Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.

Moje rozwiązanie

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż, czego szuka rekruter, i modelową odpowiedź

Co sprawdza rekruter

Czy rozumiesz, że zmienne build-time są wkompilowane w kod
Czy znasz sposoby wstrzykiwania konfiguracji w runtime
Czy pamiętasz o bezpieczeństwie i cache

Odpowiedź seniora

Zasada build once, deploy many: obraz jest budowany raz, a konfiguracja przychodzi z otoczenia. Konfigurację środowiska trzymam w ConfigMap, a sekrety w Secret (najlepiej z zewnętrznego menedżera przez External Secrets).

Dla SPA serwowanej przez nginx: przy starcie kontenera skrypt generuje plik config.js lub env.json z ConfigMap, a aplikacja czyta go przed startem (window.__ENV__ lub fetch). Plik ma Cache-Control: no-cache. Dla Next.js z serwerem: zmienne bez prefiksu publicznego są czytane w runtime na serwerze, a do klienta przekazuję potrzebne wartości z Server Component albo endpointu konfiguracji, zamiast NEXT_PUBLIC_.

Do przeglądarki trafiają tylko wartości publiczne. Konfigurację waliduję przy starcie schematem (np. Zod) i pod nie przechodzi readiness, jeśli czegoś brakuje.

Typowe wpadki

Osobny build na środowisko i brak gwarancji, że testowano to samo
Sekrety w ConfigMap
Długi cache na pliku z konfiguracją

Dopytają o

Jak zmienisz konfigurację bez restartu podów?
Jak zrobisz feature flagi per środowisko?
Jak lokalnie odtworzysz konfigurację produkcyjną?

Zapytaj Claude Rozwiń case Zagraj interviewera