Ćwiczenie — implementowanie odporności infrastruktury za pomocą platformy Kubernetes

11 min

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 używać odporności opartej na kodzie, ta jednostka stosuje podejście o nazwie odporność oparta na infrastrukturze, które obejmuje całą aplikację. Wykonasz:

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:latest
```
Zastą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:latest  
```
Zastą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.yml

Powinny 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 created

Sprawdź, czy wszystkie usługi są uruchomione:

kubectl get pods

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

Przejdź do karty PORTS, aby wyświetlić aplikację eShop działającą na Kubernetes, wybierz obok ikonę globusa Front End (32000) portu.

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 install generuje 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: enabled do pliku backend-deploy.yml w obszarze metadanych szablonu.

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

Dodaj adnotację linkerd.io/inject: enabled do 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/Product moż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 dashboard
```
Przejdź do karty PORTY, aby zobaczyć nowy przekierowany port z procesem działającego linkerd viz dashboard . Wybierz Otwórz w przeglądarce, aby otworzyć pulpit nawigacyjny.
Na panelu Linkerd wybierz pozycję 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-namespaces
```

Zatrzymaj wszystkie zasobniki usługi produktu:

kubectl scale deployment productsbackend --replicas=0

Przejdź 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=1

Aplikacja 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: