Övning – Implementera infrastrukturåterhämtning med Kubernetes
I föregående lektion implementerade du återhämtning genom att lägga till kod för felhantering med hjälp av .NET Native Resilience Extension. Den här ändringen gäller dock bara för den tjänst som du har ändrat. Det skulle vara komplicerat att uppdatera en stor app med många tjänster.
I stället för att använda kodbaserad återhämtning använder den här enheten en metod som kallas infrastrukturbaserad återhämtning som sträcker sig över hela appen. Du kommer att:
- Återdistribuera appen utan resiliens i Kubernetes.
- Distribuera Linkerd i ditt Kubernetes-kluster.
- Konfigurera appen så att den använder Linkerd för återhämtning.
- Utforska appbeteendet med Linkerd.
Omdistribuera appen
Innan du tillämpar Linkerd återställer du appen till ett tillstånd innan kodbaserad motståndskraft lades till. Följ dessa steg för att återställa:
I den nedre panelen väljer du fliken TERMINAL och kör följande git-kommandon för att ångra dina ändringar:
cd Store git checkout Program.cs git checkout Store.csproj cd .. dotnet publish /p:PublishProfile=DefaultContainer
Installera Kubernetes
Installera Kubernetes och k3d i kodområdet. k3d är ett verktyg som kör ett Kubernetes-kluster med en nod i en virtuell dator (VM) på den lokala datorn. Det är användbart för att testa Kubernetes-distributioner lokalt och körs väl i ett kodområde.
Kör dessa kommandon för att installera Kubernetes och 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
Distribuera eShop-tjänsterna till Docker Hub
De lokala avbildningarna av dina tjänster som du skapar måste finnas i ett containerregister för att kunna distribueras till Kubernetes. I den här lektionen använder du Docker Hub som containerregister.
Kör dessa kommandon för att skicka avbildningarna till 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
Konvertera docker-compose-filen till Kubernetes-manifest
För närvarande definierar du hur din app körs i docker. Kubernetes använder ett annat format för att definiera hur appen körs. Du kan använda ett verktyg med namnet Kompose för att konvertera docker-compose-filen till Kubernetes-manifest.
Du måste redigera de här filerna för att kunna använda de avbildningar som du skickade till Docker Hub.
Öppna filen backend-deploy.ymli kodområdet.
Ändra den här raden:
containers: - image: [YOUR DOCKER USER NAME]/productservice:latestErsätt platshållaren [DITT DOCKER-ANVÄNDARNAMN] med ditt faktiska Docker-användarnamn.
Upprepa de här stegen för frontend-deploy.yml-filen.
Ändra den här raden:
containers: - name: storefrontend image: [YOUR DOCKER USER NAME]/storeimage:latestErsätt platshållaren [DITT DOCKER-ANVÄNDARNAMN] med ditt faktiska Docker-användarnamn.
Distribuera eShop-appen till Kubernetes:
kubectl apply -f backend-deploy.yml,frontend-deploy.ymlDu bör se utdata som liknar följande meddelanden:
deployment.apps/productsbackend created service/productsbackend created deployment.apps/storefrontend created service/storefrontend createdKontrollera att alla tjänster körs:
kubectl get podsDu bör se utdata som liknar följande meddelanden:
NAME READY STATUS RESTARTS AGE backend-66f5657758-5gnkw 1/1 Running 0 20s frontend-5c9d8dbf5f-tp456 1/1 Running 0 20sVäxla till fliken PORTar, för att visa eShop som körs på Kubernetes, välj globikonen bredvid Front End (32000) port.
Installera linkerd
Dev-containern behöver Linkerd CLI för att installeras. Kör följande kommando för att bekräfta att Linkerd-kraven är uppfyllda:
curl -sL run.linkerd.io/install | sh
export PATH=$PATH:/home/vscode/.linkerd2/bin
linkerd check --pre
En variant av följande utdata visas:
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 √
Distribuera Linkerd till Kubernetes
Kör först följande kommando för att installera anpassade resursdefinitioner (CRD):
linkerd install --crds | kubectl apply -f -
Kör sedan följande kommando:
linkerd install --set proxyInit.runAsRoot=true | kubectl apply -f -
I föregående kommando:
-
linkerd installgenererar ett Kubernetes-manifest med nödvändiga kontrollplansresurser. - Det genererade manifestet skickas till
kubectl apply, som installerar dessa kontrollplansresurser i Kubernetes-klustret.
Den första raden i utdata visar att kontrollplanet installerades i sin egen linkerd namnrymd. Återstående utdata representerar de objekt som skapas.
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
Verifiera Linkerd-deployeringen
Kör följande kommando:
linkerd check
Föregående kommando analyserar konfigurationerna för Linkerd CLI och kontrollplanet. Om Linkerd är korrekt konfigurerat visas följande utdata:
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 √
Tips
Om du vill se en lista över Linkerd-komponenter som har installerats kör du det här kommandot: kubectl -n linkerd get deploy
Konfigurera appen så att den använder Linkerd
Linkerd distribueras, men det är inte konfigurerat. Appens beteende är oförändrat.
Linkerd känner inte till tjänstens interna funktioner och kan inte avgöra om det är lämpligt att försöka igen med en misslyckad begäran. Det skulle till exempel vara en dålig idé att försöka igen med en misslyckad HTTP POST för en betalning. En tjänstprofil är nödvändig av denna anledning. En tjänstprofil är en anpassad Kubernetes-resurs som definierar vägar för tjänsten. Det möjliggör även funktioner per väg, till exempel återförsök och tidsgränser. Linkerd försöker endast att återsända vägar som konfigurerats i tjänsteprofilmanifestet.
För korthet implementerar du endast Linkerd på aggregator- och kupongtjänsterna. Om du vill implementera Linkerd för dessa två tjänster kommer du att:
- Ändra eShop-distributionerna så att Linkerd skapar sin proxycontainer i poddarna.
- För att konfigurera återförsök för kupongtjänstens rutt lägger du till ett tjänstprofilobjekt i klustret.
Ändra eShop-distributionerna
Tjänsterna måste konfigureras för att använda Linkerd-proxycontainrar.
Lägg till
linkerd.io/inject: enabled-anteckningen i backend-deploy.yml-filen under mallmetadata.template: metadata: annotations: linkerd.io/inject: enabled labels:Lägg till
linkerd.io/inject: enabled-anteckningen i frontend-deploy.yml-filen på samma plats.Uppdatera distributionerna i Kubernetes-klustret:
kubectl apply -f backend-deploy.yml,frontend-deploy.yml
Tillämpa Linkerd-tjänstprofilen för produkttjänsten
Tjänstprofilmanifestet för produkttjänsten är:
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
Föregående manifest är konfigurerat så:
- Alla idempotenta HTTP GET-vägar som matchar mönstret
/api/Productkan försökas igen. - Återförsök kan inte lägga till mer än 20 procent extra i begärandebelastningen, plus ytterligare 10 "kostnadsfria" återförsök per sekund.
Kör följande kommando för att använda tjänstprofilen i Kubernetes-klustret:
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
Följande utdata visas:
serviceprofile.linkerd.io/backend created
Installera övervakning på tjänstnätet
Linkerd har tillägg som ger dig extra funktioner. Installera viz-tillägget och visa status för appen på Linkerds instrumentpanel.
I terminalen kör du det här kommandot för att installera tillägget:
linkerd viz install | kubectl apply -f -Visa instrumentpanelen med det här kommandot:
linkerd viz dashboardGå till fliken PORTAR för att se en ny port vidarebefordrad med processen linkerd viz dashboard som körs. Välj Öppna i webbläsaren för att öppna instrumentpanelen.
På instrumentpanelen i Linkerd väljer du Namnområden.
Under HTTP-mått väljer du standard.
Testa Linkerd-motståndskraft
När de omdistribuerade containrarna är felfria använder du följande steg för att testa appens beteende med Linkerd:
Kontrollera statusen för de körande poddarna med det här kommandot:
kubectl get pods --all-namespacesStoppa alla produkttjänstpoddar:
kubectl scale deployment productsbackend --replicas=0Gå till eShop-webbappen och försök visa produkterna. Det dröjer innan felmeddelandet "Det är problem med att ladda våra produkter. Försök igen senare."
Starta om produkttjänstpoddarna:
kubectl scale deployment productsbackend --replicas=1Appen bör nu visa produkterna.
Linkerd följer en annan metod för återhämtning än vad du såg med kodbaserad motståndskraft. Linkerd försökte transparent genomföra operationen upprepade gånger i snabb följd. Appen behövde inte ändras för att stödja det här beteendet.
Ytterligare information
Mer information om Linkerd-konfiguration finns i följande resurser: