Ćwiczenie — implementowanie odporności infrastruktury za pomocą platformy Kubernetes
W poprzedniej lekcji zaimplementowano odporność, dodając kod obsługi błędów przy użyciu rozszerzenia odporności natywnej platformy .NET. Jednak ta zmiana dotyczy tylko zmienionej usługi. Aktualizowanie dużej aplikacji z wieloma usługami byłoby nietrywialne.
Zamiast korzystać z odporności opartej na kodzie , w tej lekcji użyto podejścia nazywanego odpornością opartą na infrastrukturze , która obejmuje całą aplikację. Będziesz:
- Ponownie wdróż aplikację bez żadnej odporności na platformę Kubernetes.
- Zainstaluj Linkerd w klastrze Kubernetes.
- Skonfiguruj aplikację do używania Linkerd dla odporności.
- Poznaj zachowanie aplikacji z Linkerd.
Ponowne wdrażanie aplikacji
Przed zastosowaniem Linkerd przywróć aplikację do stanu sprzed dodania odporności implementowanej w kodzie. Aby przywrócić, wykonaj następujące kroki:
W dolnym panelu wybierz kartę TERMINAL i uruchom następujące polecenia git, aby cofnąć zmiany:
cd Store git checkout Program.cs git checkout Store.csproj cd .. dotnet publish /p:PublishProfile=DefaultContainer
Instalowanie rozwiązania Kubernetes
W środowisku codespace zainstaluj platformę Kubernetes i k3d. k3d to narzędzie, które uruchamia klaster Kubernetes z jednym węzłem wewnątrz maszyny wirtualnej na maszynie lokalnej. Jest to przydatne do testowania wdrożeń platformy Kubernetes lokalnie i działa dobrze wewnątrz przestrzeni kodu.
Uruchom następujące polecenia, aby zainstalować platformę Kubernetes i aplikację MiniKube:
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.28/deb/Release.key | sudo gpg --dearmor -o /etc/apt/kubernetes-apt-keyring.gpg
echo 'deb [signed-by=/etc/apt/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.28/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubectl
curl -s https://raw.githubusercontent.com/k3d-io/k3d/main/install.sh | bash
k3d cluster create devcluster --config k3d.yml
Wdrażanie usług eShop w usłudze Docker Hub
Lokalne obrazy usług, które skompilujesz, muszą być hostowane w rejestrze kontenerów, aby można je było wdrożyć na platformie Kubernetes. W tej lekcji użyjesz usługi Docker Hub jako rejestru kontenerów.
Uruchom następujące polecenia, aby wypchnąć obrazy do usługi Docker Hub:
sudo docker login
sudo docker tag products [your username]/productservice
sudo docker tag store [your username]/storeimage
sudo docker push [your username]/productservice
sudo docker push [your username]/storeimage
Konwertowanie pliku docker-compose na manifesty platformy Kubernetes
W tej chwili zdefiniujesz sposób działania aplikacji na platformie Docker. Platforma Kubernetes używa innego formatu do definiowania sposobu działania aplikacji. Możesz użyć narzędzia o nazwie Kompose, aby przekonwertować plik docker-compose na manifesty platformy Kubernetes.
Musisz edytować te pliki, aby używać obrazów wypychanych do usługi Docker Hub.
W przestrzeni kodu otwórz plik backend-deploy.yml.
Zmień ten wiersz:
containers: - image: [YOUR DOCKER USER NAME]/productservice:latestZastąp symbol zastępczy [YOUR DOCKER USER NAME] rzeczywistą nazwą użytkownika platformy Docker.
Powtórz te kroki dla pliku frontend-deploy.yml .
Zmień ten wiersz:
containers: - name: storefrontend image: [YOUR DOCKER USER NAME]/storeimage:latestZastąp symbol zastępczy [YOUR DOCKER USER NAME] rzeczywistą nazwą użytkownika platformy Docker.
Wdróż aplikację eShop na platformie Kubernetes:
kubectl apply -f backend-deploy.yml,frontend-deploy.ymlPowinny zostać wyświetlone dane wyjściowe podobne do następujących komunikatów:
deployment.apps/productsbackend created service/productsbackend created deployment.apps/storefrontend created service/storefrontend createdSprawdź, czy wszystkie usługi są uruchomione:
kubectl get podsPowinny zostać wyświetlone dane wyjściowe podobne do następujących komunikatów:
NAME READY STATUS RESTARTS AGE backend-66f5657758-5gnkw 1/1 Running 0 20s frontend-5c9d8dbf5f-tp456 1/1 Running 0 20sPrzejdź do karty PORTY, aby zobaczyć działającą na Kubernetes aplikację eShop, kliknij ikonę globusa obok portu Front-End (32000).
Zainstaluj linkerd
Kontener deweloperski wymaga zainstalowania Linkerd CLI. Uruchom następujące polecenie, aby upewnić się, że wymagania wstępne Linkerd są spełnione.
curl -sL run.linkerd.io/install | sh
export PATH=$PATH:/home/vscode/.linkerd2/bin
linkerd check --pre
Zostanie wyświetlona odmiana następujących danych wyjściowych:
kubernetes-api
--------------
√ can initialize the client
√ can query the Kubernetes API
kubernetes-version
------------------
√ is running the minimum Kubernetes API version
√ is running the minimum kubectl version
pre-kubernetes-setup
--------------------
√ control plane namespace does not already exist
√ can create non-namespaced resources
√ can create ServiceAccounts
√ can create Services
√ can create Deployments
√ can create CronJobs
√ can create ConfigMaps
√ can create Secrets
√ can read Secrets
√ can read extension-apiserver-authentication configmap
√ no clock skew detected
pre-kubernetes-capability
-------------------------
√ has NET_ADMIN capability
√ has NET_RAW capability
linkerd-version
---------------
√ can determine the latest version
√ cli is up-to-date
Status check results are √
Wdrażanie Linkerd w Kubernetes
Najpierw uruchom następujące polecenie, aby zainstalować niestandardowe definicje zasobów (CRD):
linkerd install --crds | kubectl apply -f -
Następnie uruchom następujące polecenie:
linkerd install --set proxyInit.runAsRoot=true | kubectl apply -f -
W poprzednim poleceniu:
-
linkerd installgeneruje manifest Kubernetes z niezbędnymi zasobami płaszczyzny sterowania. - Wygenerowany manifest jest przekazywany do
kubectl apply, który instaluje te zasoby płaszczyzny sterowania w klastrze Kubernetes.
Pierwszy wiersz danych wyjściowych pokazuje, że płaszczyzna sterowania została zainstalowana we własnej przestrzeni nazw linkerd. Pozostałe dane wyjściowe reprezentują tworzone obiekty.
namespace/linkerd created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-identity created
clusterrolebinding.rbac.authorization.k8s.io/linkerd-linkerd-identity created
serviceaccount/linkerd-identity created
clusterrole.rbac.authorization.k8s.io/linkerd-linkerd-controller created
Zwaliduj wdrożenie Linkerd
Uruchom następujące polecenie:
linkerd check
Poprzednie polecenie analizuje konfiguracje Linkerd CLI i płaszczyzny sterowania. Jeśli Linkerd jest poprawnie skonfigurowany, zostanie wyświetlony następujący wynik:
kubernetes-api
--------------
√ can initialize the client
√ can query the Kubernetes API
kubernetes-version
------------------
√ is running the minimum Kubernetes API version
√ is running the minimum kubectl version
linkerd-existence
-----------------
√ 'linkerd-config' config map exists
√ heartbeat ServiceAccount exist
√ control plane replica sets are ready
√ no unschedulable pods
√ controller pod is running
√ can initialize the client
√ can query the control plane API
linkerd-config
--------------
√ control plane Namespace exists
√ control plane ClusterRoles exist
√ control plane ClusterRoleBindings exist
√ control plane ServiceAccounts exist
√ control plane CustomResourceDefinitions exist
√ control plane MutatingWebhookConfigurations exist
√ control plane ValidatingWebhookConfigurations exist
√ control plane PodSecurityPolicies exist
linkerd-identity
----------------
√ certificate config is valid
√ trust anchors are using supported crypto algorithm
√ trust anchors are within their validity period
√ trust anchors are valid for at least 60 days
√ issuer cert is using supported crypto algorithm
√ issuer cert is within its validity period
√ issuer cert is valid for at least 60 days
√ issuer cert is issued by the trust anchor
linkerd-api
-----------
√ control plane pods are ready
√ control plane self-check
√ [kubernetes] control plane can talk to Kubernetes
√ [prometheus] control plane can talk to Prometheus
√ tap api service is running
linkerd-version
---------------
√ can determine the latest version
√ CLI is up to date
control-plane-version
---------------------
√ control plane is up to date
√ control plane and CLI versions match
linkerd-addons
--------------
√ 'linkerd-config-addons' config map exists
linkerd-grafana
---------------
√ grafana add-on service account exists
√ grafana add-on config map exists
√ grafana pod is running
Status check results are √
Napiwek
Aby wyświetlić listę składników zainstalowanych dla Linkerd, uruchom następujące polecenie: kubectl -n linkerd get deploy
Skonfiguruj aplikację do korzystania z Linkerd
Linkerd jest zainstalowany, ale nie jest skonfigurowany. Zachowanie aplikacji pozostaje niezmienione.
Linkerd nie zna wewnętrznych mechanizmów usług i nie może określić, czy należy ponowić próbę żądania, które zakończyło się niepowodzeniem. Na przykład złym pomysłem byłoby ponowne wysłanie nieudanego żądania HTTP POST w przypadku płatności. Z tego powodu konieczny jest profil usługi . Profil usługi to niestandardowy zasób Kubernetes, który definiuje trasy dla usługi. Umożliwia również funkcje dla poszczególnych tras, takie jak ponawianie prób i limity czasu. Linkerd ponawia próby tylko dla tras skonfigurowanych w manifeście profilu usługi.
Dla zwięzłości, zaimplementuj Linkerd tylko na agregatorze i usługach kuponowych. Aby zaimplementować usługę Linkerd dla tych dwóch usług, wykonasz następujące kroki:
- Zmodyfikuj wdrożenia eShop, aby Linkerd tworzył kontener proxy w zasobnikach.
- Aby skonfigurować ponawianie prób na trasie usługi kuponowej, dodaj do klastra obiekt profilu usługi.
Modyfikowanie wdrożeń eShop
Usługi muszą być skonfigurowane do używania kontenerów proxy Linkerd.
Dodaj adnotację
linkerd.io/inject: enableddo pliku backend-deploy.yml w obszarze metadanych szablonu.template: metadata: annotations: linkerd.io/inject: enabled labels:Dodaj adnotację
linkerd.io/inject: enableddo pliku frontend-deploy.yml w tym samym miejscu.Zaktualizuj wdrożenia w klastrze Kubernetes:
kubectl apply -f backend-deploy.yml,frontend-deploy.yml
Zastosuj profil usługi Linkerd dla usługi produktowej
Manifest profilu usługi dla usługi produktu to:
apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
name: backend
namespace: default
spec:
routes:
- condition:
method: GET
pathRegex: /api/Product
name: GET /v1/products
isRetryable: true
retryBudget:
retryRatio: 0.2
minRetriesPerSecond: 10
ttl: 120s
Poprzedni manifest jest skonfigurowany tak:
- Dowolna idempotentna trasa HTTP GET zgodna ze wzorcem
/api/Productmożna ponownie spróbować. - Ponowne próby mogą dodać nie więcej niż dodatkowe 20 procent do obciążenia żądania, a kolejne 10 "bezpłatnych" ponownych prób na sekundę.
Uruchom następujące polecenie, aby użyć profilu usługi w klastrze Kubernetes:
kubectl apply -f - <<EOF
apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
name: backend
namespace: default
spec:
routes:
- condition:
method: GET
pathRegex: /api/Product
name: GET /v1/products
isRetryable: true
retryBudget:
retryRatio: 0.2
minRetriesPerSecond: 10
ttl: 120s
EOF
Zostanie wyświetlone następujące dane wyjściowe:
serviceprofile.linkerd.io/backend created
Instalacja monitorowania na Service Mesh
Linkerd ma rozszerzenia, które zapewniają dodatkowe funkcje. Zainstaluj rozszerzenie viz i wyświetl stan aplikacji na pulpicie nawigacyjnym Linkerd.
W terminalu uruchom następujące polecenie, aby zainstalować rozszerzenie:
linkerd viz install | kubectl apply -f -Wyświetl pulpit nawigacyjny za pomocą tego polecenia:
linkerd viz dashboardPrzejdź do karty PORTY, aby wyświetlić nowy przekierowany port z uruchomionym procesem linkerd viz dashboard. Wybierz pozycję Otwórz w przeglądarce , aby otworzyć pulpit nawigacyjny.
Na konsoli Linkerd wybierz Przestrzenie nazw.
W obszarze Metryki HTTP wybierz domyślne.
Testowanie odporności Linkerd
Po ponownym rozmieszczeniu kontenerów w dobrej kondycji wykonaj następujące kroki, aby przetestować zachowanie aplikacji za pomocą Linkerd:
Sprawdź stan uruchomionych podów za pomocą tego polecenia:
kubectl get pods --all-namespacesZatrzymaj wszystkie zasobniki usługi produktu:
kubectl scale deployment productsbackend --replicas=0Przejdź do aplikacji internetowej eShop i spróbuj wyświetlić produkty. Występuje opóźnienie do momentu, gdy zostanie wyświetlony komunikat o błędzie "Wystąpił problem podczas ładowania naszych produktów. Spróbuj ponownie później".
Uruchom ponownie zasobniki usługi produktu:
kubectl scale deployment productsbackend --replicas=1Aplikacja powinna teraz wyświetlać produkty.
Linkerd stosuje inne podejście do odporności niż to, które widziałeś w przypadku odporności opartej na kodzie. Linkerd przezroczysto ponowił operację wiele razy w szybkim tempie. Aplikacja nie musi zostać zmieniona, aby obsługiwać to zachowanie.
Dodatkowe informacje
Aby uzyskać więcej informacji na temat konfiguracji konsolidatora Linkerd, zobacz następujące zasoby: