Laravel na k3s, część 3: Operacje po pierwszym dniu

Laravel na k3s — Część 1 · Część 2 · Część 3 · Część 4

Zacznij od sygnału operacyjnego, nie od dashboardu

Operator musi szybko odpowiedzieć na trzy pytania: czy release jest zdrowy, czy brakuje pojemności i czy dane można odtworzyć. Dashboard pomaga, ale nie jest źródłem prawdy. Trzymaj mały runbook poleceń w repozytorium, a wynik dołącz do notatki incydentu. Poniższe kontrole odróżniają zły release aplikacji od problemu węzła lub schedulera, zanim ktokolwiek zacznie usuwać Pody.

kubectl -n storefront get deployment web
kubectl -n storefront rollout status deployment/web --timeout=60s
kubectl -n storefront get pods -l app=storefront-web -o wide
kubectl -n storefront get events --sort-by=.lastTimestamp | tail -n 30
kubectl -n storefront top pods
kubectl top nodes

top wymaga Metrics Server; jeśli nie działa, nazwij brak obserwowalności po imieniu, zamiast zgadywać na podstawie limitów CPU. Pod w CrashLoopBackOff wymaga poprzednich logów kontenera i Events. Pending zwykle oznacza problem z pull obrazu, brak Secret, taint lub request zasobów. Restart może usunąć jedyny użyteczny ślad.

pod="$(kubectl -n storefront get pod -l app=storefront-web -o jsonpath='{.items[0].metadata.name}')"
kubectl -n storefront describe pod "$pod"
kubectl -n storefront logs "$pod" --all-containers=true --tail=200
kubectl -n storefront logs "$pod" --previous --all-containers=true --tail=200

Nie zapisuj w logach haseł bazy ani całych request body. Laravel powinien emitować request lub correlation ID, nazwę route/operacji, klasę błędu i SHA release'u. Przekaż identyfikator release'u jako niesekretną zmienną środowiskową i dodaj go do logów strukturalnych. Wtedy „klienci widzą 500” można połączyć z dokładną rewizją workloadu.

env:
  - name: RELEASE_SHA
    value: "3f18d7c"
  - name: LOG_CHANNEL
    value: stderr

Dla workerów kolejki sprawdzaj głębokość i liczbę błędów samej kolejki, nie używaj readiness poda web jako zastępnika. Horizon, Redis i managed queue mają inne sygnały. Web może być zdrowy, gdy zamówienia czekają na zatrzymanego workera. Zwiększenie replik workera bez uwzględnienia API downstream może zamienić wolną zależność w incydent limitów.

Traktuj poświadczenia jak proces rotacji

Secret Kubernetes jest mechanizmem transportu API, nie kompletną polityką zarządzania sekretami. Ogranicz, kto może go tworzyć, patchować i czytać; włącz szyfrowanie w spoczynku k3s dopiero po zrozumieniu obsługi kluczy; a gdy pasuje do organizacji, wybierz kontroler odczytujący zarządzany magazyn sekretów. Najważniejsze jest przećwiczone zmienienie poświadczenia bez kopiowania go do Gita, czatu albo historii terminala.

Aktualizacja Secret użytego przez envFrom nie aktualizuje już działającego procesu. Kolejność jest taka: utwórz nowe poświadczenie u dostawcy, zaktualizuj chronione źródło, wykonaj kontrolowany rollout web i workera, zweryfikuj nowe połączenia, a potem odbierz stare poświadczenie. Poniższe polecenie restartuje szablon, lecz nie ujawnia zawartości Secret.

kubectl -n storefront rollout restart deployment/web
kubectl -n storefront rollout restart deployment/worker
kubectl -n storefront rollout status deployment/web --timeout=180s
kubectl -n storefront rollout status deployment/worker --timeout=180s

Nie rotuj tak APP_KEY. Szyfrowane cookies Laravel i zapisane zaszyfrowane wartości mogą wymagać etapowej migracji aplikacji oraz osobnego projektu rotacji klucza. Reguła „restart po każdej zmianie Secret” jest dobrą domyślną, nie zastępuje znajomości znaczenia konkretnej wartości.

Backup danych i dowód odtworzenia

Dla Laravel zwykle ważniejsze są baza i uploady niż manifesty Kubernetes. Manifest odtworzysz z Gita; zamówienia klienta lub dokumentu nie. Wybierz metodę backupu wspieraną przez dostawcę bazy, zaszyfruj wynik, przechowuj go poza domeną awarii VPS i zachowaj historię na pomyłkę operatora oraz późne wykrycie uszkodzenia.

mysqldump --single-transaction --routines --events --hex-blob \
  --host="$DB_HOST" --user="$BACKUP_USER" --password \
  "$DB_DATABASE" | gzip > "storefront-$(date +%F-%H%M).sql.gz"

Zero z polecenia nie dowodzi backupu. Regularnie odtwarzaj jedną kopię do izolowanej bazy o nowej nazwie, uruchom zapytanie integralności i zapisz czas. Nie nadpisuj produkcji tylko po to, aby testować.

gunzip -c storefront-2026-09-05-0200.sql.gz | \
  mysql --host="$RESTORE_DB_HOST" --user="$RESTORE_USER" --password storefront_restore
mysql --host="$RESTORE_DB_HOST" --user="$RESTORE_USER" --password \
  --database=storefront_restore --execute='SELECT COUNT(*) AS orders FROM orders;'

Zapisz RPO (akceptowalna utrata danych) i RTO (czas przywrócenia usługi). Daily backup nie obiecuje zerowej utraty, a snapshot nie musi być przenośny na inny dysk czy dostawcę. Uploady testuj osobno: lifecycle object storage, wersjonowanie bucketu i referencje w bazie wpływają na faktyczny recovery.

Aktualizacje i incydenty mają własną granicę

Jednowęzłowy k3s nie ma niewidocznego okna serwisowego. Przeczytaj release notes docelowego k3s, zabezpiecz krytyczne dane, sprawdź wolny dysk i opcję rollbacku, a potem zaplanuj maintenance. Nie wklejaj do produkcji starego jednolinijkowca z internetu: polecenie upgrade zależy od aktualnej dokumentacji wydania. Patchuj też węzeł, ogranicz SSH i alertuj disk pressure, zanim kubelet zacznie wyrzucać Pody.

Przy złym release najpierw zachowaj dowody, rozpoznaj obraz i użyj rollbacku z części 1 tylko gdy schemat jest kompatybilny:

kubectl -n storefront rollout history deployment/web
kubectl -n storefront rollout undo deployment/web
kubectl -n storefront rollout status deployment/web --timeout=180s
curl --fail --show-error https://shop.example.com/up

Awaria węzła, dysku, skompromitowanego poświadczenia, uszkodzonych danych albo migracji niekompatybilnej wstecz nie poddaje się rollbackowi Deployment. Użyj procedury incydentu, włącz właściciela danych i świadomie wybierz odtworzenie, managed service albo tryb read-only. Ten model jest zły, gdy nikt nie jest właścicielem alertów, patchowania, restore i przeglądu dostępu. Małemu zespołowi często lepiej służy platforma zarządzana z backupami bazy niż k3s maskujący niestaffowaną funkcję operacyjną.

W codziennym działaniu ustal też właściciela każdego alertu i próg, który oznacza akcję. Alert bez właściciela jest tylko hałasem. Przykładowo: rosnąca liczba restartów wymaga sprawdzenia logów i limitów, brak świeżego backupu wymaga zatrzymania ryzykownego release'u, a pełny dysk węzła jest incydentem zanim pojawi się outage. Zapisuj decyzję, czas wykrycia i czas przywrócenia; to jedyny sposób, aby RTO przestało być życzeniem.

Nie zakładaj, że PVC rozwiązuje trwałość. Lokalny storage pojedynczego VPS umiera razem z jego dyskiem, a sam manifest wolumenu nie mówi nic o retencji ani off-site copy. Dla danych wymagających wysokiej dostępności wybierz zarządzaną bazę, replikowany system storage lub architekturę wielowęzłową, zanim obiecasz klientom parametry, których pojedynczy serwer nie może spełnić. Najpierw przećwicz odtworzenie na stagingu i dopiero wtedy rozszerzaj klaster o kolejne usługi stanowe.

Produkcja zaczyna się po kubectl apply. Operatorzy potrzebują logów skorelowanych z ID requestów, statusu deploymentu, restartów podów, głębokości kolejki i dowodów odtworzenia backupu bazy. Po deployu użyj kubectl rollout status, a przed wielokrotnym restartowaniem podów zbadaj zdarzenia describe.

Kubernetes Secrets są domyślnie kodowane base64, nie szyfrowane. Ogranicz RBAC, użyj zewnętrznego managera sekretów lub szyfrowania w spoczynku tam, gdzie to właściwe, i rotuj poświadczenia według planu świadomego aplikacji. Snapshoty persistent volume nie wystarczą, dopóki nie przećwiczysz odtworzenia. Dokumentuj czas odtworzenia i cele utraty danych zamiast nazywać dowolny backup „bezpiecznym”.