Övning – Implementera infrastrukturåterhämtning med Kubernetes

11 minuter

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 oprövade 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:

Distribuera om appen utan återhämtning i Kubernetes.
Distribuera Linkerd i ditt Kubernetes-kluster.
Konfigurera appen så att den använder Linkerd för motståndskraft.
Utforska appens beteende 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 på 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.yml i kodområdet.
Ändra den här raden:
```
  containers:
    - image: [YOUR DOCKER USER NAME]/productservice:latest
```
Ersä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:latest  
```
Ersä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.yml

Du bör se utdata som liknar följande meddelanden:

deployment.apps/productsbackend created
service/productsbackend created
deployment.apps/storefrontend created
service/storefrontend created

Kontrollera att alla tjänster körs:

kubectl get pods

Du 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          20s

Växla till fliken PORTar om du vill visa eShop som körs på Kubernetes genom att välja globeikonen bredvid Front End-porten (32000).

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 kommandot ovan:

linkerd install genererar 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-distributionen

Kör följande kommando:

linkerd check

Föregående kommando analyserar konfigurationerna av Linkerd CLI och kontrollplanet. Om Linkerd har konfigurerats korrekt 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 √

Dricks

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 interna tjänstkomponenter och kan inte fastställa huruvida det är lämpligt att försöka på nytt med en misslyckad begäran. Till exempel skulle det vara en dålig idé att försöka på nytt med en misslyckad HTTP POST för en betalning. Det krävs en tjänstprofil av den anledningen. En tjänstprofil är en anpassad Kubernetes-resurs som definierar vägar för tjänsten. Den aktiverar även funktioner per väg, till exempel återförsök och tidsgränser. Linkerd gör endast återförsök för vägar som konfigurerats i tjänstprofilens manifest.

För korthet implementerar du endast Linkerd på aggregator- och kupongtjänsterna. Du implementerar Linkerd för dessa två tjänster på följande sätt:

Ändra eShop-distributionerna så att Linkerd skapar sin proxycontainer i poddarna.
Om du vill konfigurera återförsök på kupongtjänstens väg 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 anteckningen linkerd.io/inject: enabled i backend-deploy.yml-filen under mallmetadata.

  template:
    metadata:
      annotations:
        linkerd.io/inject: enabled
      labels:

Lägg till anteckningen linkerd.io/inject: enabled i filen frontend-deploy.yml 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/Product kan försökas på nytt.
Å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 dashboard
```
Gå till fliken PORTar och se en ny port som vidarebefordras med en process med en linkerd viz-instrumentpanel som körs. Välj Öppna i webbläsaren för att öppna instrumentpanelen.
Välj Namnområden på instrumentpanelen i Linkerd.
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 poddar som körs med det här kommandot:
```
kubectl get pods --all-namespaces
```

Stoppa alla produkttjänstpoddar:

kubectl scale deployment productsbackend --replicas=0

Gå till eShop-webbappen och försök visa produkterna. Det finns en fördröjning tills felmeddelandet " Det är problem med att läsa in våra produkter. Försök igen senare."

Starta om produkttjänstpoddarna:

kubectl scale deployment productsbackend --replicas=1

Appen 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 gjorde snabbt transparenta återförsök med åtgärden flera gånger i rad. 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: