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 zmiany kodu, siatka usług zapewnia zarządzanie ruchem, zasady, zabezpieczenia, silną tożsamość i wgląd. Twoja aplikacja jest oddzielona od tych możliwości operacyjnych, które są przenoszone do warstwy infrastruktury. Z punktu widzenia architektury, 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, które obsługują zarządzanie siatką usług. Spis komponentów zazwyczaj obejmuje:
- Interfejs zarządzania, który może być interfejsem użytkownika lub interfejsem API.
- Definicje reguł i zasad, które definiują sposób implementacji określonych możliwości przez siatkę usługi.
- Zarządzanie zabezpieczeniami dla elementów, takich jak mocna tożsamość i certyfikaty, dla uwierzytelniania mTLS.
- Metryki lub wgląd w celu zbierania i agregowania metryk i danych telemetrycznych z aplikacji.
Składnik płaszczyzny danych składa się z serwerów proxy, które są niewidocznie wstrzykiwane wraz z każdą usługą. Jest to nazywane wzorcem przyczepki. 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 w celu:
- Zabezpieczania ruchu za pośrednictwem uwierzytelniania mTLS.
- Dynamicznego kierowania ruchu.
- Stosowania zasad do ruchu.
- Zbierania metryk i informacji o śledzeniu.
Niektóre popularne opcje sieci usługi dla klastrów Kubernetes obejmują Linkerd, Istio i Consul. Ten moduł koncentruje się na konsolidatorze Linkerd. Poniższy diagram pokazuje interakcje między składnikami w obrębie płaszczyzn danych i sterowania:
Porównanie z podejściami opartymi na kodzie
Główna strategia obsługi błędów konsolidatora 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ładem jest ponawianie próby w taki sposób, aby dodać maksymalnie 20 procent dodatkowego obciążenia w usłudze docelowej. Widok oparty na metrykach konsolidatora Linkerd umożliwia dynamiczne dostosowanie do warunków klastra w czasie rzeczywistym. Takie podejście dodaje kolejny wymiar do zarządzania klastrem, ale nie dodaje żadnego kodu.
Za pomocą podejścia opartego na kodzie, takiego jak Polly, możesz:
- Koniecznie musisz odgadnąć, które parametry ponawiania i limitu czasu są odpowiednie.
- Skupić się na konkretnym żądaniu HTTP.
Nie istnieje rozsądny sposób, aby odpowiedzieć na awarię infrastruktury w kodzie aplikacji. Rozważ setki lub tysiące żądań, które są przetwarzane jednocześnie. Nawet ponowienie przy użyciu funkcji wykładniczej (liczba żądań i czas) może zalać 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 konsolidatora Linkerd. Takie transakcje mogą być chronione przed awarią za pomocą usługi Polly.
W kolejnych lekcjach zaimplementujesz odporność usługi kuponowej przy użyciu usług Polly i Linkerd.