Koncepcja — wdrażanie aplikacji

Ukończone

Przed wdrożeniem aplikacji na platformie Kubernetes przejrzyjmy wdrożenia platformy Kubernetes i omówimy ich ograniczenia w naszym scenariuszu.

Co to są wdrożenia platformy Kubernetes?

Wdrożenie kubernetes to ewolucja zasobników. Wdrożenia opakowują zasobniki w inteligentny obiekt, który umożliwia skalowanie w poziomie. Możesz łatwo zduplikować i skalować aplikację w celu obsługi większego obciążenia bez konieczności konfigurowania złożonych reguł sieciowych.

Wdrożenia umożliwiają aktualizowanie aplikacji bez przestojów przez zmianę tagu obrazu. Aktualizowanie wdrożenia wyłącza aplikacje online jeden po drugim i zastępuje je najnowszą wersją zamiast usuwać wszystkie aplikacje i tworzyć nowe, co oznacza, że wdrożenie może zaktualizować zasobniki w nim bez widocznego wpływu na dostępność.

Chociaż istnieje wiele korzyści związanych z używaniem wdrożeń za pośrednictwem zasobników, nie są one w stanie odpowiednio obsłużyć naszego scenariusza.

Ten scenariusz obejmuje aplikację sterowaną zdarzeniami, która odbiera dużą liczbę zdarzeń w różnym czasie. Bez obiektu KEDA Scaler lub HPA należy ręcznie dostosować liczbę replik, aby przetworzyć liczbę zdarzeń i skalować wdrożenie w dół , gdy obciążenie powróci do normalnego.

Przykładowy manifest wdrożenia

Oto przykładowy fragment naszego manifestu wdrożenia:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: contoso-microservice
spec:
  replicas: 10                      # Tells K8S the number of pods needed to process the Redis list items
  selector:                         # Define the wrapping strategy
    matchLabels:                    # Match all pods with the defined labels
      app: contoso-microservice     # Labels follow the `name: value` template
  template:                         # Template of the pod inside the deployment
    metadata:
      labels:
        app: contoso-microservice
    spec:
      containers:
        - image: mcr.microsoft.com/mslearn/samples/redis-client:latest
          name: contoso-microservice

W przykładowym manifeście replicas ustawiono wartość 10, która jest największą liczbą, którą możemy ustawić dla niezbędnych replik dostępnych do przetwarzania szczytowej liczby zdarzeń. Jednak powoduje to, że aplikacja zużywa zbyt wiele zasobów w czasie nieokreślonym, co może zagościć w innych wdrożeniach w klastrze.

Jednym z rozwiązań jest użycie autonomicznej funkcji HPA do monitorowania użycia procesora CPU zasobników, co jest lepszą opcją niż ręczne skalowanie w obu kierunkach. Jednak hpA nie koncentruje się na liczbie zdarzeń odebranych na liście redis.

Najlepszym rozwiązaniem jest użycie narzędzia KEDA i narzędzia skalowania usługi Redis do wykonywania zapytań dotyczących listy i określania, czy do przetwarzania zdarzeń jest potrzebnych więcej lub mniej zasobników.