Implementowanie odporności infrastruktury za pomocą rozwiązania Kubernetes
Aby zaimplementować odporność opartą na infrastrukturze, można użyć siatki usług. Oprócz odporności bez zmieniania kodu siatka usług zapewnia zarządzanie ruchem, zasady, zabezpieczenia, silną tożsamość i możliwość obserwowania. Aplikacja jest oddzielona od tych funkcji operacyjnych, które są przenoszone do warstwy infrastruktury. Mówiąc architektonicznie, siatka usług składa się z dwóch składników: płaszczyzny sterowania i płaszczyzny danych.
Składnik płaszczyzny sterowania ma wiele składników obsługujących zarządzanie siatką usług. Spis składników zwykle obejmuje:
- Interfejs zarządzania, który może być interfejsem użytkownika lub interfejsem API.
- Reguły i definicje zasad definiujące sposób implementowania określonych możliwości przez siatkę usług.
- Zarządzanie zabezpieczeniami dla elementów takich jak silna tożsamość i certyfikaty dla mTLS.
- Metryki lub obserwowalność w celu zbierania i agregowania metryk oraz telemetrii z aplikacji.
Składnik płaszczyzny danych obejmuje serwery proxy, które są przezroczysto wstrzykiwane wraz z każdą usługą, co jest nazywane wzorcem Sidecar. Każdy serwer proxy jest skonfigurowany do kontrolowania ruchu sieciowego w zasobniku zawierającym usługę i poza nim. Ta konfiguracja umożliwia skonfigurowanie każdego serwera proxy do:
- Zabezpieczanie ruchu przez mTLS.
- Dynamicznie kieruj ruch.
- Stosowanie zasad do ruchu.
- Zbieranie metryk i informacji śledzących.
Niektóre popularne opcje siatki usług dla klastrów Kubernetes obejmują Linkerd, Istio i Consul. Ten moduł koncentruje się na Linkerd. Na poniższym diagramie przedstawiono interakcje między składnikami w płaszczyznach danych i sterowania:
Porównanie z metodami opartymi na kodzie
Główna strategia obsługi błędów w Linkerd obejmuje ponawianie prób i przekroczenia limitu czasu. Ponieważ linkerd ma systemowy widok całego klastra, może stosować strategie odporności w nowatorski sposób. Przykład polega na ponowieniu próby w taki sposób, aby dodać maksymalnie 20 procent dodatkowego obciążenia w usłudze docelowej. Widok oparty na metrykach Linkerd umożliwia dynamiczne dostosowywanie się do warunków klastra w czasie rzeczywistym. Takie podejście dodaje kolejny wymiar do zarządzania klastrem, ale nie dodaje żadnego kodu.
W przypadku podejścia opartego na kodzie, takiego jak Polly, możesz:
- Należy ustalić, które wartości parametrów ponawiania i przekroczenia limitu czasu są odpowiednie.
- Skoncentruj się na konkretnym żądaniu HTTP.
Nie ma rozsądnego sposobu reagowania na awarię infrastruktury w kodzie aplikacji. Rozważmy setki lub tysiące żądań, które są przetwarzane jednocześnie. Nawet ponowienie próby z wykładniczym wycofywaniem (pomnożonym przez liczbę żądań) może przeciążyć usługę.
Z kolei podejścia oparte na infrastrukturze, takie jak Linkerd, nie znają wewnętrznych aplikacji. Na przykład złożone transakcje bazy danych są niewidoczne dla Linkerd. Takie transakcje mogą być chronione przed awarią za pomocą usługi Polly.
W nadchodzących jednostkach zaimplementujesz odporność usługi kuponowej przy użyciu Polly i Linkerd.