Niewidzialny silnik za nowoczesnym SaaS Gdy użytkownik kliknie „Zarejestruj się” na produkcie SaaS lub zażąda określonych danych, oczekuje on reaktywności i niezawodności w czasie rzeczywistym. Za tą prostą interakcją działa wyrafinowany backend, zaprojektowany tak, aby skalizować, samodzielnie leczyć i rozprowadzać obciążenia w konstelacji mikrousług. Ale gdy coraz więcej start-upów przyjmuje projekty oparte na chmurze, a usługi kontenerowe stają się kręgosłupem, wielokrotnie pojawia się jedno wyzwanie: jak możemy inteligentnie zrównoważyć ruch, aby nie tylko był równomiernie rozprowadzany, ale i kierowany do najzdrowszych, najszybszych i najbardziej niezawodnych punktów końcowych usług? Jest to o wiele bardziej skomplikowane niż klasyczne routowanie okrągłe. Jak każdy, kto korzysta z systemów produkcyjnych, dowiedział się, naiwna dystrybucja ruchu prowadzi do kaskadowych awarii, gdy jedna usługa jest niezdrowa, lub przeszkód, gdy nowe wersje nie są gotowe do produkcji. Równowaga obciążenia dla mikrosłużb Python Dockerized — za pomocą funkcji Cloud Load Balancing, GKE/Cloud Run, zarządzanego VPC, wytrzymałego IAM i native observability. Inteligentny Kontekst problemu: dlaczego naiwne bilansowanie obciążeń nie działa w produkcji Nowa wersja Billing pod jest wdrażana, która zajmuje 30 sekund, aby rozgrzać swój basen połączeń z bazą danych. Albo może pod zostać zawieszony w obsłudze zadania eksportu partii, zwiększając opóźnienie do 5x normalnego. Być może istnieje wyciek pamięci, który powoli pogarsza wydajność w ciągu kilku godzin. Klasyczne balansery obciążenia będą nadal kierować użytkowników do tych zmagających się podzespołów, ponieważ technicznie nadal reagują na podstawowe kontrole zdrowia. Nawet z wbudowanymi sondami gotowości Kubernetes, domyślny balanser obciążenia zarządzany GCP nie zawsze ma wystarczająco granularne dane zdrowotne, aby natychmiast uniknąć powolnych lub nieudanych punktów końcowych. Sonda może sprawdzać co 10 sekund, ale pod może zawiesić się spektakularnie w czasie interwencji. To, czego potrzebujemy, to inteligentne bilansowanie obciążenia napędzane szczegółowymi sygnałami zdrowotnymi, bramami gotowości, wskaźnikami w czasie rzeczywistym i szybkim wykrywaniem awarii. Definicja inteligentnego balansowania obciążeń Przed napisaniem pojedynczego wiersza kodu lub przewidywaniem jakiejkolwiek infrastruktury, nauczyłem się, że ważne jest, aby być precyzyjnym o tym, co „inteligentne” naprawdę oznacza w tym kontekście.Zbyt często zespoły wskakują prosto do wdrożenia bez zdefiniowania kryteriów sukcesu, tylko aby odkryć miesiące później, że ich strategia bilansowania obciążenia ma subtelne, ale krytyczne luki. Inteligentne bilansowanie obciążenia oznacza, że system wysyła ruch tylko do pods, które są zdrowe, żywe i prawdziwie reaktywne – nie tylko pods, które jeszcze się nie zawaliły. Oznacza to rozróżnienie między kontenerami, które są technicznie uruchamiane, a tymi, które są w rzeczywistości gotowe do obsługi ruchu produkcyjnego. Widziałem zbyt wiele incydentów, w których pod przechodzi kontrolę zdrowia, ale nadal inicjuje połączenia bazy danych lub rozgrzewa pamięci podręcznej, co prowadzi do upływu czasu dla pierwszych użytkowników, którzy go uderzyli. Poza prostym zdrowiem, inteligentne routowanie musi uwzględniać właściwości wydajności w czasie rzeczywistym. Pod może być zdrowy, ale obecnie doświadcza wysokiego opóźnienia z powodu zbierania śmieci lub kontrowersji zasobów. Równowaga obciążenia powinna preferować punkty końcowe o niższych, bardziej stabilnych czasach reakcji. Architektura musi również dobrze współpracować z elastycznym skalowaniem. Ponieważ pods spina się w górę i w dół w odpowiedzi na wzorce ruchu, balanser obciążenia musi bezproblemowo zintegrować nową pojemność, jednocześnie odprowadzając ruch z pods zaplanowanych do zakończenia. A krytycznie rzecz biorąc, wszystko to wymaga wbudowanej obserwacji od pierwszego dnia. Bez logów, śladów i wskaźników, które wracają do decyzji dotyczących routingu, jesteś ślepy. Zaprojektuj architekturę Cloud-Native Backend Projektowanie Microservices (Python i Docker) Zauważyłem, że zbyt wiele mikroserwisów traktuje kontrole zdrowia jako refleksję, wdrażając je z prostym "powrotem 200 OK", który mówi balanserowi obciążenia nic użytecznego. Oto usługa rozliczania oparta na Pythonie, która demonstruje wzorzec, którego używam w produkcji. Zauważ, jak oddziela zdrowie (czy proces jest żywy?) od gotowości (czy jest gotowy do obsługi ruchu?): # billing_service.py from flask import Flask, jsonify import random import time app = Flask(__name__) @app.route("/healthz") def health(): # Report healthy 95% of the time, failure 5% if random.random() < 0.95: return "OK", 200 else: return "Unhealthy", 500 @app.route("/readyz") def ready(): # Simulate readiness delay on startup if time.time() - START_TIME < 10: return "Not Ready", 503 return "Ready", 200 @app.route("/pay", methods=["POST"]) def pay(): # Simulate payment processing latency latency = random.uniform(0.05, 1.5) time.sleep(latency) return jsonify({"status": "success", "latency": latency}) if __name__ == "__main__": global START_TIME START_TIME = time.time() app.run(host='0.0.0.0', port=8080) To oddzielenie między i Odzwierciedla to, co wdrożyłem w kilkudziesięciu usługach produkcyjnych. Punkt końcowy zdrowia informuje Kubernetes, czy proces powinien zostać ponownie uruchomiony – być może jest zamknięty lub wyczerpany opis plików. Punkt końcowy gotowości określa, czy pod otrzymuje ruch produkcyjny. W tych krytycznych pierwszych sekundach po uruchomieniu, podczas gdy usługa ustanawia połączenia z bazą danych, pamięci podręcznej lub konfigurację ładowania z Secret Manager, gotowość zwraca 503. /healthz /readyz W rzeczywistym kodzie produkcyjnym Twoja kontrola gotowości weryfikuje rzeczywiste zależności. Czy możesz pingować bazę danych? Czy Redis reaguje? Czy załadowujesz model ML do pamięci? W szczególności w przypadku usługi rozliczeniowej możesz sprawdzić, czy inicjalizacja Stripe SDK została zakończona lub czy zasady wykrywania oszustw zostały załadowane pomyślnie. Wyjątkowość w kontroli zdrowia symuluje przerywane awarie, z którymi napotkasz w produkcji – wstrząsy sieciowe, przejściowe wyczerpanie zasobów lub wstrząsy zewnętrznej zależności. 3.2 Konteneryzacja: Dockerfile Przykład Gdy Twoja usługa prawidłowo ujawni swój stan, pakowanie jej do wdrożenia w chmurze staje się proste. # Dockerfile FROM python:3.11-slim WORKDIR /app COPY billing_service.py . RUN pip install flask EXPOSE 8080 CMD ["python", "billing_service.py"] W produkcji chciałbyś to poprawić za pomocą budów wielostopniowych, aby zminimalizować rozmiar obrazu, uruchomić jako użytkownika non-root dla zabezpieczeń i potencjalnie użyć requirements.txt do zarządzania zależnościami.Ale główny wzorzec pozostaje: szczupły obraz bazowy, minimalne warstwy, jasny punkt wejścia.Zauważyłem, że optymalizacja czasu uruchamiania kontenera jest jedną z najwyższych ulepszeń dźwigni, które możesz wprowadzić do inteligentnego bilansowania obciążenia, ponieważ szybsze start-upy oznaczają mniej czasu w stanie „nie gotowym” i gładszą skalę. 3.3 GCP Resource Provisioning: budowanie i wdrażanie Z usługą kontenerową, następnym krokiem jest wprowadzenie go do rejestru artefaktów GCP i do klastra. Zazwyczaj strukturuję to jako powtarzalny rurociąg, ale oto ręczny przepływ pracy, aby zrozumieć, co dzieje się pod pokrywą: # Build, tag, and push Docker image to GCP Artifact Registry gcloud artifacts repositories create python-services --repository-format=docker --location=us-central1 docker build -t us-central1-docker.pkg.dev/${PROJECT_ID}/python-services/billing-service:v1 . gcloud auth configure-docker us-central1-docker.pkg.dev docker push us-central1-docker.pkg.dev/${PROJECT_ID}/python-services/billing-service:v1 Ważne jest to, że używasz Artifact Registry zamiast Container Registry. Artifact Registry daje wrażliwość skanowania z pudełka, lepszą integrację IAM i opcje replikacji regionalnej, które stają się krytyczne, gdy uruchamiasz usługi wieloregionowe. Teraz pojawia się konfiguracja rozmieszczenia, gdzie inteligentne równoważenie obciążenia naprawdę zaczyna przybierać kształt: # k8s/billing-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: billing-service spec: replicas: 3 selector: matchLabels: app: billing-service template: metadata: labels: app: billing-service spec: containers: - name: billing-service image: us-central1-docker.pkg.dev/YOUR_PROJECT/python-services/billing-service:v1 ports: - containerPort: 8080 livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 5 periodSeconds: 5 readinessProbe: httpGet: path: /readyz port: 8080 initialDelaySeconds: 5 periodSeconds: 5 Zwróć uwagę na konfigurację sondy. Sprawdzam stan zdrowia co 5 sekund, co w produkcji może być zbyt agresywne w zależności od cech usług. Będziesz musiał dostosować te wartości w oparciu o rzeczywiste zachowanie. Jeśli kontrole zdrowia same stają się źródłem obciążenia, wydłuż okres. Jeśli potrzebujesz szybszej wykrywania awarii, skróć ją – ale bądź przygotowany na więcej fałszywych pozytywów podczas przejściowych problemów. o ustawienie jest krytyczne i często błędnie skonfigurowane. Ustaw go za krótki, a twoje pods nie sprawdza zdrowia podczas normalnego uruchamiania, tworząc obwód ponownego uruchamiania. Ustaw go za długo, a tracisz czas, zanim ruch może przepłynąć do nowo skalowanych pods. Zazwyczaj zaczynam od wartości 2x mojego obserwowanego czasu uruchamiania w rozwoju, a następnie dostosowuję się do metryki produkcji. initialDelaySeconds Wdrażaj usługę i eksponuj ją za pomocą tych poleceń: kubectl apply -f k8s/billing-deployment.yaml kubectl expose deployment billing-service --type=LoadBalancer --port 80 --target-port 8080 To automatycznie tworzy GCP Load Balancer przed wdrożeniem, co prowadzi nas do następnej warstwy inteligencji. GCP Load Balancer z inteligentnymi kontrolami zdrowotnymi Gdy tworzysz usługę Kubernetes typu LoadBalancer, GCP zapewnia HTTP(S) Load Balancer, który głęboko integruje się z twoim zbiorem GKE. To nie tylko przekazywanie ruchu – aktywnie monitoruje stan zdrowia końcówki, przestrzega stanów gotowości i podejmuje decyzje o routingu milisekunda po milisekundach. Prawdziwa moc pochodzi z umożliwienia zbilansowania obciążeń wrodzonych kontenerów za pośrednictwem sieciowych grup punktów końcowych (NEG). Pozwala to balanserowi obciążeń GCP kierować się bezpośrednio do pod IP zamiast przechodzić przez kub-proxy i iptables, zmniejszając opóźnienie i poprawiając dokładność kontroli zdrowia: # k8s/billing-service.yaml apiVersion: v1 kind: Service metadata: name: billing-service annotations: cloud.google.com/neg: '{"ingress": true}' # Enables container-native load balancing spec: type: LoadBalancer ports: - port: 80 targetPort: 8080 selector: app: billing-service Ten jedyny wpis - —przekształca architekturę bilansowania obciążenia. Zmierzyłem 20-30% poprawy opóźnienia w produkcji po prostu poprzez włączenie NEG, ponieważ eliminujesz przetwarzanie hopów sieciowych i iptables. Co ważniejsze dla naszych celów, daje bilanserowi obciążenia GCP bezpośrednią widoczność w zdrowiu pod. Kiedy sonda gotowości nie powiodła się, ten backend jest natychmiast usunięty z obrotu bilansera obciążenia. Brak ostatecznej spójności, brak opóźnienia w oczekiwaniu na aktualizację punktów końcowych. cloud.google.com/neg Po wdrożeniu można dostosować zachowanie kontroli zdrowia za pośrednictwem konsoli GCP lub poleceń gcloud. W produkcji zazwyczaj dostosowuję odstępy kontroli zdrowia, aby zrównoważyć między szybkim wykrywaniem awarii a overhead. Konfigurowałem również niezdrowy próg – ile kolejnych awarii przed usunięciem backend – w oparciu o to, czy wolę dostępność (toleruję awarii przejściowe) lub niezawodność (nieodpowiednio szybko). Rozmieszczenie dla gotowości, skalowania i odporności 4.1 Umożliwianie autoskalowania podłogi horyzontalnej Inteligentne bilansowanie obciążeń nie oznacza tylko skutecznego kierowania do istniejących backendów – oznacza to zapewnienie odpowiedniej liczby zdrowych backendów dostępnych w każdej chwili. Piękno łączenia odpowiednich kontroli zdrowotnych z autoskalowaniem polega na tym, że nowe pods wchodzą do obrotu bilansera obciążenia tylko wtedy, gdy są naprawdę gotowe. Nie ma warunków wyścigowych, w których ruch uderza w pod, który nadal się inicjuje. kubectl autoscale deployment billing-service --cpu-percent=70 --min=3 --max=10 Z bolesnego doświadczenia dowiedziałem się, że ustawienie minimalnej liczby repliki jest tak samo ważne jak maksymalna. Uruchomienie z mniej niż 3 replikami w produkcji oznacza, że każda porażka lub wdrożenie pojedynczego podkładu stanowi znaczący procent Twojej wydajności, co prowadzi do kaskadowego przeciążenia. Próg procesora 70% jest konserwatywny, co preferuję dla usług obsługujących transakcje finansowe. Dla mniej krytycznych usług możesz przesunąć do 80-85% aby zmaksymalizować efektywność zasobów. Ale tutaj jest to, co ma znaczenie: łącząc autoskaliowanie z prawdopodobieństwem odczytu oznacza, że wzrost ruchu jest obsługiwany w sposób uroczysty. Nowe pods spin up, inicjować prawidłowo (zablokowane od ruchu przez gotowość), a następnie bezproblemowo dołączyć do basenu balansera obciążenia po przygotowaniu. W bardziej zaawansowanych konfiguracjach rozszerzyłem to, aby używać niestandardowych mierników – skalowania w oparciu o głębokość kolejki żądania lub opóźnienie P95 zamiast tylko CPU. GCP umożliwia to za pośrednictwem API niestandardowych mierników, pozwalając aplikacji na wyeksportowanie mierników świadomych logiki biznesowej, które napędzają decyzje dotyczące skalowania. 4.2 Dystrybucja ruchu na drobnych granicach dla bezpiecznych wdrożeń Nawet przy inteligentnych kontrolach zdrowia i automatycznym skalowaniu, wdrażanie nowego kodu pozostaje operacją o najwyższym ryzyku w produkcji. Błąd, który sprawia, że przeszedł etap, może zniszczyć całą usługę, jeśli zostanie wdrożona do wszystkich pods jednocześnie. Wzór, który najczęściej używam, to wdrożenie kanaryjskie z podziałem ruchu w procentach. Wdrażasz nową wersję na niewielką liczbę pods przy zachowaniu stabilnej wersji, a następnie stopniowo zmieniaj ruch w oparciu o obserwowane metryki zdrowia. # k8s/billing-deployment-canary.yaml apiVersion: apps/v1 kind: Deployment metadata: name: billing-service-canary spec: replicas: 1 selector: matchLabels: app: billing-service version: canary template: metadata: labels: app: billing-service version: canary spec: containers: - name: billing-service image: us-central1-docker.pkg.dev/YOUR_PROJECT/python-services/billing-service:v2 ports: - containerPort: 8080 livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 5 periodSeconds: 5 readinessProbe: httpGet: path: /readyz port: 8080 initialDelaySeconds: 5 periodSeconds: 5 Twój selektor usług obejmuje oba i Początkowo, przy zaledwie 1 replice kanaryjskiej w porównaniu z 3 stabilnymi replikami, około 25% ruchu trafi na nową wersję. Monitorujesz wskaźniki błędów, opóźnienia i metryki biznesowe. Jeśli wszystko wygląda zdrowo po godzinie, możesz zwiększyć repliki kanaryjskie do 2, a następnie 3, a następnie ostatecznie promować je do stabilności podczas dezaktywacji starej wersji. stable canary To, co sprawia, że jest to potężne, to sposób, w jaki wchodzi w interakcje z kontrolami zdrowotnymi. Jeśli Twoja wersja Canary ma krytyczny błąd, który powoduje niepowodzenie sond gotowości, nigdy nie otrzymuje ruchu produkcyjnego na pierwszym miejscu. W przypadku jeszcze bardziej zaawansowanych wdrożeń Dyrektor ruchu GCP umożliwia precyzyjne podziały procentowe ruchu, kierowanie w oparciu o nagłówki do testowania konkretnych scenariuszy i integrację z możliwościami sieci usługowej.W jednym systemie produkcyjnym, nad którym pracowałem, kierowaliśmy ruch wewnętrzny pracowników do wersji kanaryjskich, utrzymując przy tym cały ruch klientów na stabilnym poziomie, dając nam testy w świecie rzeczywistym bez ryzyka dla klientów. Obserwowalność: monitorowanie zdrowia, opóźnienia i awarii 5.1 Logowanie i monitorowanie z Cloud Operations Suite Oto niewygodna prawda o bilansowaniu obciążenia: możesz skonstruować najbardziej zaawansowaną logikę routingu na świecie, ale bez obserwacji nie wiesz, czy rzeczywiście działa. Integracja z GKE jest wystarczająco głęboka, aby uzyskać metryki na poziomie pod, dzienniki kontenerów i dystrybuowane ślady z minimalną konfiguracją. W przypadku usługi rozliczeniowej eksportuję kilka klas metryki. Po pierwsze, podstawy — liczbę żądań, współczynnik błędu, procenty opóźnienia. Te przepływają automatycznie przez zarządzany przez GCP Prometheus, jeśli wystawiasz je w odpowiednim formacie. Po drugie, wyniki kontroli zdrowia z biegiem czasu, co pomaga zidentyfikować wzorce w niepowodzeniach. Czy pod niepowoduje kontroli zdrowia każdego ranka o 2 rano podczas konserwacji bazy danych? Jest to sygnał do dostosowania logiki kontroli zdrowia lub dostosowania okien konserwacji. Po trzecie, i co najważniejsze, niestandardowe metryki biznesowe, które reprezentują rzeczywiste zdrowie usług z punktu widzenia użytkownika. W przypadku fakturowania, może to być wskaźnik sukcesu płatności, czas przetwarzania refundacji lub opóźnienie wykrywania oszustw. Oto, jak wyeksportować niestandardowe metryki za pomocą OpenTelemetry z usługi Flask: # Export Flask metrics (latency, errors) using OpenTelemetry from opentelemetry import metrics from opentelemetry.exporter.cloud_monitoring import CloudMonitoringMetricsExporter from opentelemetry.sdk.metrics import MeterProvider from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader exporter = CloudMonitoringMetricsExporter() meter_provider = MeterProvider( metric_readers=[PeriodicExportingMetricReader(exporter, export_interval_millis=5000)] ) metrics.set_meter_provider(meter_provider) meter = metrics.get_meter(__name__) payment_latency = meter.create_histogram( "billing.payment.latency", unit="ms", description="Payment processing latency" ) # In your endpoint: @app.route("/pay", methods=["POST"]) def pay(): start = time.time() # ... process payment ... duration_ms = (time.time() - start) * 1000 payment_latency.record(duration_ms) return jsonify({"status": "success"}) Dzięki tym wskaźnikom przepływającym do monitorowania w chmurze, Twój zespół SRE może podejmować świadome decyzje. Kiedy powinieneś skalować? Kiedy kanaryjka jest w rzeczywistości bezpieczniejsza niż wersja stabilna? Które pods są konsekwentnie wolniejsze niż ich rówieśnicy? Zbudowaliśmy tabliczki, które wyświetlają dystrybucje opóźnień per-pod, dzięki czemu jest to natychmiast widoczne, gdy pojedynczy pod ulega degradacji. Innym kluczowym elementem jest śledzenie. Integracja Cloud Trace z GKE oznacza, że możesz śledzić żądanie z bilansera obciążenia za pośrednictwem usługi rozliczeniowej i w dalszych połączeniach z procesorami płatności. Gdy opóźnienie P95 wzrośnie, możesz określić, czy jest to Twój kod, zapytania bazy danych, czy zewnętrzne połączenia API. Ta głębokość widoczności przekształca rozwiązywanie problemów z zgadywania w dochodzenie oparte na danych. 5.2 Ostrzeżenie o awarii i degradacji opóźnienia Konfiguruję zasady ostrzegania, które odpowiednio traktują różne typy sygnałów – niektóre wymagają natychmiastowych stron, inne po prostu tworzą bilety do badania w godzinach pracy. W przypadku usługi rozliczeniowej, krytyczne alerty obejmują wskaźnik błędu przekraczający 1% utrzymywany w ciągu 5 minut lub każdy przypadek niepowodzenia przetwarzania płatności dla wszystkich prób w oknie 2-minutowym. Te strony są nazywane, ponieważ stanowią natychmiastowy wpływ na klienta. alerty o średniej ciężkości mogą wybuchnąć, gdy opóźnienie P95 przekracza 1 sekundę, lub gdy pod nie sprawdza się więcej niż 3 razy w ciągu 10 minut. Te tworzą bilety, ale nie strony – wskazują na obniżoną wydajność, która wymaga badania, ale nie jest jeszcze krytyczna. Kluczem jest podłączenie powiadomień do automatycznych odpowiedzi tam, gdzie jest to możliwe. Gdy wskaźnik błędu wzrasta na kanaryjskich podnośnikach, automatycznie odwracaj rozmieszczenie. Gdy automatyczne skalowanie maksymalizuje pojemność, powiadom inżyniera dzwoniącego, aby zbadać, czy musisz zwiększyć limity lub zoptymalizować wydajność. Gdy pod konsekwentnie nie sprawdza się po uruchomieniu, zabijaj go i pozwól Kubernetesowi zmienić harmonogram – być może wylądował na zniszczonym węzle. Zbudowaliśmy automatyzację wokół tych powiadomień za pomocą funkcji chmury wywoływanych przez wiadomości Pub/Sub z Cloud Monitoring. Funkcja ta może rozszerzać rozmieszczenia, ponownie uruchamiać pods, a nawet usuwać ruch z całego klastra, jeśli metryki wskazują na awarię na poziomie strefy. Bezpieczne sieci, IAM i dostęp do usług 6.1 Ograniczenie ruchu wewnętrznego za pomocą VPC Inteligentne bilansowanie obciążeń nie polega tylko na wydajności routingu, ale także na bezpieczeństwie. Systemy SaaS produkcyjne potrzebują głębokiej obrony, gdzie kompromitowanie jednej usługi nie daje dostępu do całej infrastruktury. Wdrażam klastry produkcyjne GKE jako prywatne klastry, co oznacza, że węzły nie mają publicznych adresów IP i nie można do nich uzyskać dostępu z Internetu, z wyjątkiem bilansera obciążenia. # k8s/network-policy.yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: billing-allow-internal spec: podSelector: matchLabels: app: billing-service policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: api-gateway Niniejsza polityka gwarantuje, że tylko pods oznaczone mogą inicjować połączenia z podsami usług rozliczeniowych. Jeśli atakujący naruszy twoją usługę powiadomień, nie mogą bezpośrednio uzyskać dostępu do rozliczeń. app: api-gateway Widziałem incydenty, w których zasady sieciowe uniemożliwiały ruch boczny po uszkodzeniu kontenera. atakujący uzyskał dostęp do pod, ale nie mógł uzyskać dostępu do żadnych cennych usług, ponieważ zasady sieciowe blokowały ruch. Polityka współpracuje również z inteligentnym balansowaniem obciążeń w subtelny sposób. Ograniczając, które usługi mogą dotrzeć do twoich backendów, zabezpieczasz wszystkie zewnętrzne przepływy ruchu za pośrednictwem balansera obciążeń, gdzie podlega kontrolom zdrowia, ograniczaniu stawki i obserwacji. Wewnętrzne połączenia z usługą do usługi mogą ominąć balansera obciążeń w celu zwiększenia wydajności, ale nadal podlegają zasadom sieciowym i kontrolom sieci usługowej, jeśli korzystasz z Istio lub podobnych. 6.2 Kontrola IAM: przywileje minimalne Polityka sieci obsługuje dostęp na poziomie sieci, ale IAM kontroluje to, co mogą zrobić uwierzytelnione usługi. Konfigurowałem każdą microservice z własnym kontem usługi Kubernetes skopiowanym do określonego konta usługi GCP za pośrednictwem identyfikacji obciążenia prac. Usługa rozliczeniowa potrzebuje dostępu do Cloud SQL do rejestrów transakcji i Pub/Sub do publikowania zdarzeń płatniczych, ale nic więcej. Ta zasada najmniejszego przywileju uratowała mnie wielokrotnie.W jednym incydencie słabość w zależności pozwoliła na arbitralne wykonanie kodu w usłudze powiadomień.Ponieważ uprawnienia IAM tej usługi były ściśle ograniczone do wysyłania wiadomości e-mail za pośrednictwem SendGrid, atakujący nie mógł uzyskać dostępu do danych płatności klientów, nie mógł modyfikować infrastruktury, nie mógł nawet wymienić, jakie inne usługi istnieją. W połączeniu z inteligentnym balansowaniem obciążeń i kontrolami zdrowotnymi, kontrolki IAM zapewniają, że nawet jeśli zagrożony pod przechodzi kontrolę zdrowotną i otrzymuje ruch, szkody, które może spowodować, są zminimalizowane. Scenariusz produkcji: radzenie sobie z prawdziwą porażką Teoria jest satysfakcjonująca, ale ważne jest to, jak ta architektura działa, gdy wszystko pójdzie źle. Oto scenariusz, który przeżyłem, z nazwami zmienionymi: Wdrażasz nową wersję usługi rozliczeniowej v2.1.4, która zawiera optymalizację do przetwarzania partii. Zmiana wygląda dobrze na scenie. Wywołasz ją jako kanaryjkę do 10% ruchu produkcyjnego. W ciągu kilku minut opóźnienie P95 dla żądań uderzających w kanaryjski pod skoczy z 200ms do 3 sekund. Wskaźnik błędu wzrasta od 0,1% do 2%.W starej architekturze oznaczałoby to, że 10% użytkowników ma straszne doświadczenie, a ty byś rywalizował, aby odwrócić ręcznie, podczas gdy twój zespół wsparcia poluje wściekłe bilety. Zamiast tego oto, co się dzieje z inteligentnym bilansowaniem obciążenia: sonda gotowości poduszki kanaryjskiej zaczyna działać, ponieważ skonfigurowałeś ją, aby sprawdzić nie tylko, czy proces jest żywy, ale czy „ostatnie żądania zostały pomyślnie zakończone”.Po 3 kolejnych awarii, Kubernetes zaznacza pod, że nie jest gotowy. GCP Balancer obciążenia natychmiast przestaje kierować nowy ruch, nawet jeśli poduszka nadal działa. Monitorowanie w chmurze wykrywa wzorzec – kanaryjskie poduszki nie sprawdziły się podczas kontroli zdrowia, spik opóźnienia jest wyizolowany do poziomu v2.1.4. Ostrzeżenie wysyła się do Twojego kanału Slack. Twoja automatyczna polityka zwrotu działa, ponieważ kanaryjka przekroczyła próg niepowodzenia. W ciągu 2 minut od początkowego wdrożenia, kanaryjka zostaje usunięta, a Ty wrócisz do całkowitego uruchomienia na stabilnej wersji v2.1.3. Całkowity wpływ na klienta: kilkadziesiąt żądań zauważyło zwiększoną opóźnienie przed niepowodzeniem kontroli zdrowia. Patrząc na ślady w Cloud Trace, odkrywają, że optymalizacja wprowadziła zapytanie bazy danych, które blokuje tabele podczas operacji partii, blokując interaktywne żądania. Jest to obietnica inteligentnego bilansowania obciążeń – nie to, że systemy nigdy nie zawiodą, ale że zawiodą uroczo, zawierają promień wybuchu i zapewniają widoczność potrzebną do rozwiązywania problemów bez dramatu. Wspólne pułapki i najlepsze praktyki Nawet przy architekturze, którą opisałem, istnieją tryby awarii, z którymi spotkałem się, które warto wywołać wyraźnie. Najczęstszym błędem, który widzę, są zespoły wdrażające sondy zdrowia i gotowości, które sprawdzają niewłaściwe rzeczy. Twoja sonda może zweryfikować, że Flask reaguje, ale nie, czy basen połączeń baz danych jest wyczerpany. Może zwrócić 200 OK, podczas gdy pasma tła są zamknięte. Efektywne sondy sprawdzają, czy usługa może rzeczywiście spełnić swój cel, a nie tylko, czy proces działa. Inną pułapką jest dostosowanie intervalów kontroli zdrowia bez uwzględniania pełnego wpływu. Bardzo agresywna kontrola (każda sekunda) może przytłoczyć twoją aplikację z ruchem sondy, zwłaszcza jeśli kontrola zdrowia jest kosztowna. Ale bardzo konserwatywna kontrola (każde 30 sekund) oznacza, że może zająć ponad minutę, aby wykryć nieudany pod i usunąć go z obrotu. Odkryłem, że 5-10 sekundowe odstępy uderzają w dobrą równowagę dla większości usług, ale musisz mierzyć we własnym środowisku. Decyzja dotycząca niewłaściwego otwarcia w stosunku do niewłaściwego zamknięcia jest subtelna, ale krytyczna. Gdy twój balanser obciążenia ma wiele niezdrowych backendów, czy powinien on kontynuować kierowanie do nich (niewłaściwe otwarcie) lub całkowicie odrzucać ruch (niewłaściwe zamknięcie)? Prawidłowa odpowiedź zależy od twojej usługi. W przypadku systemu rozliczeniowego wolę niewłaściwe zamknięcie – lepiej zwrócić 503 i mieć klientów do ponownego przetwarzania płatności niż niewłaściwie. Zawsze popieram testowanie scenariuszy awarii w produkcji za pomocą narzędzi takich jak inżynieria chaosu. aby sprawdzić, czy ruch nie przechodzi płynnie do zdrowych podsów. Użyj zasad sieci do symulacji opóźnienia lub utraty pakietu. Wstrzykiwanie awarii w rozmieszczeniach kanaryjskich celowo, aby zweryfikować, czy monitoring je złapie.Każda usługa produkcyjna, którą prowadzę, ma regularne eksperymenty z chaosem zaplanowane, ponieważ zaufanie, które zapewniają, jest bezcenne. kubectl delete pod Użyj narzędzi takich jak Locust lub k6 do symulacji realistycznych wzorców ruchu i sprawdź, czy autoscaling odpowiednio reaguje, czy kontrole zdrowotne pozostają wiarygodne pod obciążeniem i czy twoje założenia dotyczące wydajności się utrzymują. 9. Conclusions and Final Thoughts Współczesny backend SaaS to zarówno rozproszony system, jak i żywy organizm – adaptacja, samoleczenie i skalowanie na żądanie.To, co opisałem w tym artykule, to nie tylko teoretyczna architektura; jest to wzorzec, który udoskonaliłem w kilkudziesięciu systemach produkcyjnych, potwierdzony przez incydenty, które wahały się od niewielkich awarii do zagrażających firmie przerw. Prawdziwy wgląd, który zajął mi lata, aby zinternalizować, jest to, że inteligentne bilansowanie obciążenia nie jest funkcją, którą dodasz na końcu. Jest to pojawiająca się właściwość dobrej architektury: usługi, które uczciwie informują o ich stanie, infrastruktura, która szanuje te sygnały, i obserwacyjność, która zamyka obwód zwrotny. Głęboka integracja między GKE, Cloud Load Balancing i Cloud Operations oznacza, że nie łączysz z sobą różnych narzędzi – pracujesz z spójną platformą, na której kontrole zdrowia naturalnie przepływają do decyzji dotyczących routingu, gdzie metryki informują o autoskaliowaniu i gdzie promień wybuchu awarii jest naturalnie zawarty. Zespół, który odniósł sukces z takimi architekturami, to ci, którzy obsesyjnie obserwują swoje systemy w produkcji, którzy traktują każdy incydent jako okazję do uczenia się i którzy nieustannie powtarzają swoje strategie kontroli ruchu.Rada, którą udzielam, pochodzi nie od planowania, ale od reagowania - do kaskadowania awarii o 3 rano, do szczytów ruchu podczas uruchamiania produktów, do subtelnych błędów, które przejawiają się tylko w skali. Jeśli wziąć jedną rzecz z tego artykułu, niech to będzie to: inteligentne zrównoważenie obciążenia polega na budowaniu systemów, które fałszują uroczo i leczą się automatycznie, dając ci przestrzeń do rozwiązywania problemów przemyślane, a nie wściekłe. Wzory, które udostępniłem, są testowane w bitwie, ale nie są przepisywne. Twój SaaS będzie miał różne ograniczenia, różne tryby awarii, różne wymagania biznesowe. Dostosuj te koncepcje do swojego kontekstu, zmierz, co jest ważne dla twoich usług, i zbuduj obserwacyjność, która pozwala ci powtarzać z ufnością.
