Knative — platforma jako usługa oparta na k8s z obsługą bezserwerową

Knative — platforma jako usługa oparta na k8s z obsługą bezserwerową

Kubernetes niewątpliwie stał się dominującą platformą wdrażania kontenerów. Zapewnia możliwość kontrolowania prawie wszystkiego za pomocą interfejsów API i niestandardowych kontrolerów, które rozszerzają interfejsy API o niestandardowe zasoby.

Jednak użytkownik nadal musi podejmować szczegółowe decyzje dotyczące dokładnego sposobu wdrażania, konfigurowania, zarządzania i skalowania aplikacji. Kwestie skalowania aplikacji, ochrony i przepływu ruchu pozostają w gestii użytkownika. To odróżnia Kubernetes od konwencjonalnych platform jako usługi (PaaS), takich jak Cloud Foundry i Heroku.

Platformy posiadają uproszczony interfejs użytkownika i skierowane są do twórców aplikacji, którzy najczęściej zajmują się konfiguracją indywidualnych aplikacji. Routing, wdrażanie i metryki są zarządzane w sposób przejrzysty dla użytkownika przez podstawowy system PaaS.

Przepływ pracy od źródła do wysyłki jest obsługiwany przez PaaS poprzez utworzenie niestandardowego obrazu kontenera, wdrożenie go, skonfigurowanie nowej trasy i subdomeny DNS dla ruchu przychodzącego. Wszystko to jest uruchamiane na polecenie git push.

Kubernetes (celowo) zapewnia jedynie podstawowe elementy składowe takich platform, pozostawiając społeczności swobodę samodzielnego wykonania pracy. Jak – stwierdziła Kelsey Hightower:

Kubernetes to platforma do budowania platform. Najlepsza pozycja do rozpoczęcia, ale nie do zakończenia.

W rezultacie widzimy wiele kompilacji Kubernetes, a także firmy hostingowe, które próbują stworzyć PaaS dla Kubernetes, takie jak OpenShift i Rancher. Na rosnący rynek Kube-PaaS wkracza firma Knative, założona w lipcu 2018 roku przez Google i Pivotal.

Knative powstał w wyniku współpracy Google i Pivotal, przy niewielkiej pomocy innych firm, takich jak IBM, RedHat i Solo.im. Oferuje podobne funkcje PaaS co Kubernetes z najwyższej klasy obsługą aplikacji opartych na obliczeniach bezserwerowych. W przeciwieństwie do kompilacji Kubernetes, Knative jest instalowany jako dodatek w dowolnym kompatybilnym klastrze Kubernetes i konfigurowany przy użyciu zasobów użytkownika.

Co to jest Knative?

Knative jest opisywany jako „platforma oparta na Kubernetes do dostarczania obciążeń i zarządzania nimi przy użyciu nowoczesnych obliczeń bezserwerowych”. Knative, rozliczając się jako taka platforma, aktywnie autoskaluje kontenery proporcjonalnie do jednoczesnych żądań HTTP. Niewykorzystane usługi ostatecznie skalują się do zera, zapewniając skalowanie na żądanie w stylu bezserwerowym.

Knative składa się z zestawu kontrolerów, które instalują się w dowolnym klastrze Kubernetes i zapewniają następujące możliwości:

  • budowanie aplikacji kontenerowych z kodu źródłowego (dostarczanego przez komponent Budować),
  • zapewnienie dostępu do ruchu przychodzącego do aplikacji (dostarczanego przez komponent Służąc),
  • dostarczanie i automatyczne skalowanie aplikacji na żądanie (również zapewniane przez komponent Służąc),
  • identyfikacja źródeł zdarzeń prowadzących do uruchomienia aplikacji (dostarczanych przez komponent WKKW).

Kluczowym komponentem jest Serving, który zapewnia udostępnianie, automatyczne skalowanie i zarządzanie ruchem dla zarządzanych aplikacji. Po zainstalowaniu Knative nadal masz pełny dostęp do Kubernetes API, dzięki czemu użytkownicy mogą zarządzać aplikacjami zwykłe sposób, a także służy do debugowania usług Knative, pracujących z tymi samymi prymitywami API, z których korzystają te usługi (moduły, usługi itp.).

Za pomocą Serving zautomatyzowane jest również routing ruchu niebiesko-zielonego, zapewniając separację ruchu pomiędzy nową i starą wersją aplikacji, gdy użytkownik dostarczy zaktualizowaną wersję aplikacji.

Sam Knative polega na zainstalowaniu kompatybilnego kontrolera wejścia. W chwili pisania tego artykułu ten artykuł jest obsługiwany Brama API Gloo и Siatka usług Istio. Skonfiguruje dostępne wejścia, aby kierować ruch do aplikacji zarządzanych przez Knative.

Istio Service Mesh może być dużą zależnością dla użytkowników Knative, którzy chcą wypróbować tę usługę bez instalowania panelu sterowania Istio, ponieważ Knative zależy tylko od bramy.

Z tego powodu większość użytkowników woli Gloo jako bramę do Knative, zapewniając podobny zestaw możliwości do Istio (w celu korzystania wyłącznie z Knative), a jednocześnie zużywając znacznie mniej zasobów i ponosząc niższe koszty operacyjne.

Przetestujmy Knative w akcji na stojaku. Będę używać świeżo zainstalowanego klastra działającego w GKE:

kubectl get namespace
NAME          STATUS   AGE
default       Active   21h
kube-public   Active   21h
kube-system   Active   21h

Zacznijmy instalować Knative i Gloo. Można to zrobić w dowolnej kolejności:

# ставим Knative-Serving
kubectl apply -f 
 https://github.com/knative/serving/releases/download/v0.8.0/serving-core.yaml
namespace/knative-serving created
# ...
# ставим Gloo
kubectl apply -f 
  https://github.com/solo-io/gloo/releases/download/v0.18.22/gloo-knative.yaml
namespace/gloo-system created
# ...

Sprawdzamy, czy wszystkie Pody mają status „Uruchomiony”:

kubectl get pod -n knative-serving
NAME                              READY   STATUS    RESTARTS   AGE
activator-5dd55958cc-fkp7r        1/1     Running   0          7m32s
autoscaler-fd66459b7-7d5s2        1/1     Running   0          7m31s
autoscaler-hpa-85b5667df4-mdjch   1/1     Running   0          7m32s
controller-85c8bb7ffd-nj9cs       1/1     Running   0          7m29s
webhook-5bd79b5c8b-7czrm          1/1     Running   0          7m29s
kubectl get pod -n gloo-system
NAME                                      READY   STATUS    RESTARTS   AGE
discovery-69548c8475-fvh7q                1/1     Running   0          44s
gloo-5b6954d7c7-7rfk9                     1/1     Running   0          45s
ingress-6c46cdf6f6-jwj7m                  1/1     Running   0          44s
knative-external-proxy-7dd7665869-x9xkg   1/1     Running   0          44s
knative-internal-proxy-7775476875-9xvdg   1/1     Running   0          44s

Gloo jest gotowe do routingu, stwórzmy automatycznie skalującą się usługę Knative (nazwijmy ją kservice) i kierujmy do niej ruch.

Usługi Knative zapewniają łatwiejszą ścieżkę dostarczania aplikacji do Kubernetes niż konwencjonalny model Deployment+Service+Ingress. Będziemy pracować z tym przykładem:

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
 name: helloworld-go
 namespace: default
spec:
 template:
   spec:
     containers:
       - image: gcr.io/knative-samples/helloworld-go
         env:
           - name: TARGET
             Value: Knative user

Skopiowałem to do pliku, a następnie zastosowałem go do mojego klastra Kubernetes w ten sposób:

kubectl apply -f ksvc.yaml -n default

Zasoby utworzone przez Knative możemy przeglądać w klastrze po dostarczeniu naszego „helloworld-go” kserwis:

kubectl get pod -n default
NAME                                              READY   STATUS    RESTARTS   AGE
helloworld-go-fjp75-deployment-678b965ccb-sfpn8   2/2     Running   0          68s

Pod z naszym obrazem „helloworld-go” jest uruchamiany po wdrożeniu kservice. W przypadku braku ruchu liczba podów zostanie zmniejszona do zera. I odwrotnie, jeśli liczba jednoczesnych żądań przekroczy określony konfigurowalny próg, liczba podów wzrośnie.

kubectl get ingresses.networking.internal.knative.dev -n default
NAME            READY   REASON
helloworld-go   True

Knative konfiguruje swoje wejście przy użyciu specjalnego zasobu „ingres” w wewnętrznym API Knative. Gloo używa tego interfejsu API jako swojej konfiguracji, aby zapewnić funkcje podobne do PaaS, w tym niebiesko-zielony model wdrażania, automatyczne egzekwowanie protokołu TLS, przekroczenie limitu czasu i inne zaawansowane funkcje routingu.

Po pewnym czasie widzimy, że nasze pody zniknęły (ponieważ nie było ruchu przychodzącego):

kubectl get pod -n default

No resources found.
kubectl get deployment -n default
NAME                             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
helloworld-go-fjp75-deployment   0         0         0            0           9m46s

Wreszcie postaramy się do nich dotrzeć. Możesz łatwo i łatwo uzyskać adres URL dla Knative Proxy za pomocą glooctl:

glooctl proxy url --name knative-external-proxy
http://35.190.151.188:80

Bez zainstalowanego glooctl adres i port możesz zobaczyć w usłudze kube:

kubectl get svc -n gloo-system knative-external-proxy
NAME                     TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)                      AGE
knative-external-proxy   LoadBalancer   10.16.11.157   35.190.151.188   80:32168/TCP,443:30729/TCP   77m

Uruchommy trochę danych za pomocą cURL:

curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
Hello Knative user!

Knative zapewnia programistom niemal PaaS, oparte na gotowym do użycia Kubernetesie, korzystającym z wysokowydajnej bramy API z pełnym stosem firmy Gloo. Ten post jedynie zarysował powierzchnię rozbudowanych opcji dostosowywania i dodatkowych funkcji Knative. To samo z Gloo!

Pomimo tego, że Knative jest jeszcze młodym projektem, jego zespół co sześć tygodni wypuszcza nowe wersje i rozpoczęło się wdrażanie zaawansowanych funkcji, takich jak automatyczne wdrażanie TLS, automatyczne skalowanie panelu administracyjnego. Istnieje duża szansa, że ​​w wyniku współpracy wielu firm zajmujących się chmurą i jako podstawa nowej oferty Google Cloud Run, Knative może stać się główną opcją do przetwarzania bezserwerowego i PaaS na platformie Kubernetes. Śledź wiadomości!

Od redakcji SouthBridge
Opinie czytelników są dla nas ważne, dlatego prosimy o wzięcie udziału w krótkiej ankiecie związanej z przyszłymi artykułami na temat Knative, Kubernetes, Serverless Computing:

W ankiecie mogą brać udział tylko zarejestrowani użytkownicy. Zaloguj się, Proszę.

Czy powinienem kontynuować pisanie artykułów i przewodników na temat przetwarzania natywnego i bezserwerowego?

  • Tak proszę.

  • Nie, dziękuję.

Głosowało 28 użytkowników. 4 użytkowników wstrzymało się od głosu.

Źródło: www.habr.com

Dodaj komentarz