Ć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ę. Wykonasz następujące zadania:
- Ponownie wdróż aplikację bez żadnej odporności na platformę Kubernetes.
- Wdróż konsolidator Linkerd w klastrze Kubernetes.
- Skonfiguruj aplikację do używania konsolidatora Linkerd dla odporności.
- Zapoznaj się z zachowaniem aplikacji za pomocą konsolidatora Linkerd.
Ponowne wdrażanie aplikacji
Przed zastosowaniem konsolidatora Linkerd przywróć aplikację do stanu przed dodaniem odporności opartej na 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 wyświetlić aplikację eShop działającą na platformie Kubernetes, wybierz ikonę globusa obok portu frontonu (32000).
Instalowanie konsolidatora konsolidatora
Kontener deweloperski wymaga zainstalowania interfejsu wiersza polecenia konsolidatora Linkerd. Uruchom następujące polecenie, aby upewnić się, że wymagania wstępne konsolidatora 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 konsolidatora Linkerd na platformie 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 powyższym poleceniu:
linkerd installgeneruje manifest Kubernetes z wymaganymi zasobami płaszczyzny sterowania.- Wygenerowany manifest jest potokowy do
kubectl applyelementu , 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
Weryfikowanie wdrożenia konsolidatora Linkerd
Uruchom następujące polecenie:
linkerd check
Poprzednie polecenie analizuje konfiguracje interfejsu wiersza polecenia konsolidatora Linkerd i płaszczyzny sterowania. Jeśli konsolidator Linkerd jest skonfigurowany prawidłowo, wyświetlane są następujące dane wyjściowe:
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ę zainstalowanych składników konsolidatora Linkerd, uruchom następujące polecenie: kubectl -n linkerd get deploy
Konfigurowanie aplikacji do użycia konsolidatora Linkerd
Konsolidator konsolidatora jest wdrażany, ale nie jest skonfigurowany. Zachowanie aplikacji jest niezmienione.
Konsolidator Linkerd nie zna wewnętrznych usług i nie może określić, czy należy ponowić próbę żądania zakończonego niepowodzeniem. Na przykład niewłaściwym pomysłem może być ponowienie próby wykonania nieudanego żądania HTTP POST dla płatności. Z tego powodu profil usługi jest niezbędny. Profil usługi jest niestandardowym zasobem Kubernetes, który definiuje trasy dla usługi. Włącza on również funkcje dla trasy, takie jak ponowne próby i limity czasu. Konsolidator Linkerd tylko ponawia próby na trasie skonfigurowanej w manifeście profilu usługi.
W celu zwięzłości zaimplementuj konsolidator Linkerd tylko w przypadku agregatora i usług kuponowych. Aby zaimplementować konsolidator Linkerd dla tych dwóch usług, musisz:
- 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 serwera proxy konsolidatora 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
Stosowanie profilu usługi Konsolidator linkerd dla usługi produktu
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:
- Można było wycofać dowolną idempotentną trasę HTTP GET zgodną ze wzorcem
/api/Product. - 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
Wyświetlane są następujące dane wyjściowe:
serviceprofile.linkerd.io/backend created
Instalowanie monitorowania w usłudze Service Mesh
Linkerd ma rozszerzenia, które zapewniają dodatkowe funkcje. Zainstaluj rozszerzenie viz i wyświetl stan aplikacji na pulpicie nawigacyjnym konsolidatora 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 i aby wyświetlić nowy port przesłany dalej z uruchomionym procesem konsolidatora linkerd pulpitu nawigacyjnego. Wybierz pozycję Otwórz w przeglądarce , aby otworzyć pulpit nawigacyjny.
Na pulpicie nawigacyjnym konsolidatora konsolidatora wybierz pozycję Przestrzenie nazw.
W obszarze Metryki HTTP wybierz pozycję domyślną.
Testowanie odporności konsolidatora Linkerd
Gdy ponownie wdrożone kontenery są w dobrej kondycji, wykonaj następujące kroki, aby przetestować zachowanie aplikacji za pomocą konsolidatora Linkerd:
Sprawdź stan uruchomionych zasobnikó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.
Konsolidator Linkerd stosuje inne podejście do odporności niż w przypadku odporności opartej na kodzie. Konsolidator Linkerd w przezroczysty sposób wielokrotnie szybko ponawiał operację raz za razem. Aplikacja nie musi zostać zmieniona, aby obsługiwać to zachowanie.
Dodatkowe informacje
Aby uzyskać więcej informacji na temat konfiguracji konsolidatora Linkerd, skorzystaj z następujących zasobów: