Øvelse – Implementer robusthed i infrastruktur med Kubernetes

11 minutter

I det forrige undermodul implementerede du robusthed ved at tilføje kode til håndtering af fejl ved hjælp af den oprindelige .NET-robusthedsudvidelse. Denne ændring gælder dog kun for den tjeneste, du har ændret. Opdatering af en stor app med mange tjenester ville være ikke-ubetydeligt.

I stedet for at bruge kodebaseret robusthed bruger denne lektion en tilgang, der kaldes infrastrukturbaseret robusthed, der spænder over hele appen. Du skal:

Geninstaller appen uden nogen form for robusthed i Kubernetes.
Udrul Linkerd i kubernetes-klyngen.
Konfigurer appen til at bruge Linkerd til robusthed.
Udforsk appens funktionsmåde med Linkerd.

Geninstaller appen

Før du anvender Linkerd, skal du gendanne appen til en tilstand, før kodebaseret robusthed blev tilføjet. Følg disse trin for at vende tilbage:

I nederste panel skal du vælge fanen TERMINAL og køre følgende git-kommandoer for at fortryde dine ændringer:

cd Store
git checkout Program.cs
git checkout Store.csproj
cd ..
dotnet publish /p:PublishProfile=DefaultContainer

Installér Kubernetes

Installer Kubernetes og k3d i dit kodeområde. k3d er et værktøj, der kører en Kubernetes-klynge med en enkelt node i en virtuel maskine (VM) på din lokale computer. Det er nyttigt til at teste Kubernetes-udrulninger lokalt og kører godt i et kodeområde.

Kør disse kommandoer for at installere Kubernetes og 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

Udrul eShop-tjenesterne til Docker Hub

De lokale billeder af dine tjenester, som du bygger, skal hostes i en objektbeholderregistreringsdatabase for at kunne installeres i Kubernetes. I dette undermodul bruger du Docker Hub som din objektbeholderregistreringsdatabase.

Kør disse kommandoer for at overføre dine billeder til 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

Konvertér din docker-skrivefil til Kubernetes-manifester

I øjeblikket definerer du, hvordan din app kører i docker. Kubernetes bruger et andet format til at definere, hvordan din app kører. Du kan bruge et værktøj kaldet Kompose til at konvertere din docker-compose-fil til Kubernetes-manifester.

Du skal redigere disse filer for at bruge de billeder, du har pushet til Docker Hub.
Åbn filen backend-deploy.ymli kodeområdet .
Skift denne linje:
```
  containers:
    - image: [YOUR DOCKER USER NAME]/productservice:latest
```
Erstat pladsholderen [DIT DOCKER-BRUGERNAVN] med dit faktiske Docker-brugernavn.
Gentag disse trin for filen frontend-deploy.yml.

Skift denne linje:

  containers:
  - name: storefrontend
    image: [YOUR DOCKER USER NAME]/storeimage:latest

Erstat pladsholderen [DIT DOCKER-BRUGERNAVN] med dit faktiske Docker-brugernavn.

Udrul eShop-appen i Kubernetes:

kubectl apply -f backend-deploy.yml,frontend-deploy.yml

Du bør kunne se output, der ligner følgende meddelelser:

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

Kontrollér, at alle tjenesterne kører:

kubectl get pods

Du bør kunne se output, der ligner følgende meddelelser:

NAME                        READY   STATUS    RESTARTS   AGE
backend-66f5657758-5gnkw    1/1     Running   0          20s
frontend-5c9d8dbf5f-tp456   1/1     Running   0          20s

Skift til fanen PORTE for at få vist den eShop, der kører på Kubernetes, vælg globusikonet ud for Front End (32000) port.

Installér linkerd

Udviklerobjektbeholderen skal have Linkerd-kommandolinjegrænsefladen installeret. Kør følgende kommando for at bekræfte, at Linkerd-forudsætninger er opfyldt:

curl -sL run.linkerd.io/install | sh
export PATH=$PATH:/home/vscode/.linkerd2/bin
linkerd check --pre

Der vises en variation af følgende output:

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 √

Udrul Linkerd til Kubernetes

Kør først følgende kommando for at installere CRD'erne (Custom Resource Definitions):

linkerd install --crds | kubectl apply -f -

Kør derefter følgende kommando:

linkerd install --set proxyInit.runAsRoot=true | kubectl apply -f -

I den foregående kommando:

linkerd install genererer et Kubernetes-manifest med de nødvendige kontrolplanressourcer.
Det genererede manifest sendes til kubectl apply, som installerer disse kontrolplanressourcer i Kubernetes-klyngen.

Den første linje i outputtet viser, at kontrolplanet blev installeret i sit eget linkerd navneområde. Det resterende output repræsenterer de objekter, der oprettes.

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

Valider Linkerd-installationen

Kør følgende kommando:

linkerd check

Den foregående kommando analyserer konfigurationerne af Linkerd CLI og kontrolplanet. Hvis Linkerd er konfigureret korrekt, vises følgende output:

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 √

Drikkepenge

Hvis du vil se en liste over Linkerd-komponenter, der er installeret, skal du køre denne kommando: kubectl -n linkerd get deploy

Konfigurer appen til at bruge Linkerd

Linkerd er installeret, men den er ikke konfigureret. Appens funktionsmåde er uændret.

Linkerd er ikke bekendt med tjenesteinterne oplysninger og kan ikke afgøre, om det er relevant at prøve en mislykket anmodning igen. Det ville f.eks. være en dårlig idé at prøve en mislykket HTTP POST igen for en betaling. En tjenesteprofil er derfor nødvendig. En tjenesteprofil er en brugerdefineret Kubernetes-ressource, der definerer ruter for tjenesten. Den aktiverer også funktioner pr. rute, f.eks. nye forsøg og timeout. Linkerd udfører kun nye forsøg på ruter, der er konfigureret i tjenesteprofilmanifestet.

For at gøre det kort skal du kun implementere Linkerd på sammenlægnings- og kupontjenesterne. Hvis du vil implementere Linkerd for disse to tjenester, skal du:

Rediger eShop-udrulningerne, så Linkerd opretter sin proxyobjektbeholder i pods.
Hvis du vil konfigurere nye forsøg på kupontjenestens rute, skal du føje et tjenesteprofilobjekt til klyngen.

Rediger eShop-udrulningerne

Tjenesterne skal være konfigureret til at bruge Linkerd-proxyobjektbeholdere.

Føj anmærkningen linkerd.io/inject: enabled til backend-deploy.yml-filen under skabelonmetadata.

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

Føj anmærkningen linkerd.io/inject: enabled til frontend-deploy.yml-filen på samme sted.

Opdater udrulningerne i Kubernetes-klyngen:

kubectl apply -f backend-deploy.yml,frontend-deploy.yml

Anvend Linkerd-tjenesteprofilen for produkttjenesten

Tjenesteprofilmanifestet for produkttjenesten er:

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

Det foregående manifest er konfigureret således:

Enhver idempotent HTTP GET-rute, der matcher mønsteret /api/Product, kan prøves igen.
Nye forsøg kan ikke føje mere end 20 % ekstra til anmodningsbelastningen plus yderligere 10 "gratis" forsøg pr. sekund.

Kør følgende kommando for at bruge tjenesteprofilen i Kubernetes-klyngen:

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ølgende output vises:

serviceprofile.linkerd.io/backend created

Installér overvågning på tjenestemasken

Linkerd har udvidelser, der giver dig ekstra funktioner. Installér udvidelsen viz, og få vist status for appen i Linkerd-dashboardet.

Kør denne kommando i terminalen for at installere udvidelsen:
```
linkerd viz install | kubectl apply -f -
```
Få vist dashboardet med denne kommando:
```
linkerd viz dashboard
```
Gå til fanen PORTE for at få vist en ny port, der er videresendt med en proces med linkerd viz-dashboard, kører. Vælg Åbn i browser for at åbne dashboardet.
På dashboardet Linkerd skal du vælge Navneområder.
Under HTTP-målepunkter skal du vælge standard.

Test Linkerd-robusthed

Når de geninstallerede objektbeholdere er i orden, kan du bruge følgende trin til at teste appens funktionsmåde med Linkerd:

Kontrollér status for de kørende pods med denne kommando:
```
kubectl get pods --all-namespaces
```

Stop alle produkttjenestekapsler:

kubectl scale deployment productsbackend --replicas=0

Gå til eShop-webappen, og prøv at få vist produkterne. Der er en forsinkelse, indtil fejlmeddelelsen "Der er problemer med at indlæse vores produkter. Prøv igen senere."

Genstart produkttjeneste-pods:

kubectl scale deployment productsbackend --replicas=1

Appen skal nu vise produkterne.

Linkerd følger en anden tilgang til robusthed end det, du så med kodebaseret robusthed. Linkerd har forsøgt at udføre handlingen igen flere gange i hurtig rækkefølge. Appen behøvede ikke at blive ændret for at understøtte denne funktionsmåde.

Yderligere oplysninger

Du kan få flere oplysninger om Linkerd-konfiguration i følgende ressourcer:

Feedback

Var denne side nyttig?