🥇Knative — platforma jako usługa oparta na k8s z wsparciem serverless

Dominującą platformą do wdrażania kontenerów niewątpliwie stał się Kubernetes. Umożliwia zarządzanie praktycznie wszystkim, używając swoich API oraz kontrolerów użytkownika, które rozszerzają jego API poprzez zasoby użytkownika.

Jednakże użytkownik wciąż musi podejmować szczegółowe decyzje dotyczące tego, jak dokładnie wdrażać, konfigurować, zarządzać i skalować aplikacje. Użytkownik decyduje o skalowaniu aplikacji, zabezpieczeniach oraz przepływie ruchu. To różni Kubernetes od zwykłych „platform jako usługa” (PaaS), takich jak Cloud Foundry czy Heroku.

Platformy mają uproszczony interfejs użytkownika, skierowane są do programistów aplikacji, którzy najczęściej zajmują się konfiguracją pojedynczych aplikacji. Routing, wdrażanie i metryki są dla użytkownika zarządzane przez podstawowy system PaaS.

Proces „kod źródłowy – dostarczenie” jest obsługiwany przez PaaS poprzez utworzenie użytkowego obrazu kontenera, jego wdrożenie, konfigurację nowego routing oraz poddomeny DNS dla nadchodzącego ruchu. Wszystko to uruchamia się na polecenie git push.

W Kubernetes (celowo) dostarczane są tylko podstawowe elementy dla takich platform, dając społeczności możliwość samodzielnego wykonania tej pracy. Jak powiedział Kelsey Hightower:

Kubernetes jest platformą do budowania platform. To najlepsza pozycja na start, ale nie na meta.

W rezultacie widzimy wiele rozwiązań Kubernetes, a także hostingów, które próbują stworzyć PaaS dla Kubernetes, takich jak OpenShift i Rancher. Na tle rosnącego rynku Kube-PaaS na scenę wkracza Knative, powstały w lipcu 2018 roku przez firmy Google i Pivotal.

Knative jest wynikiem współpracy Google i Pivotal, z niewielkim wsparciem innych firm, takich jak IBM, RedHat i Solo.im. Oferuje podobne usługi PaaS dla Kubernetes z pierwszorzędnym wsparciem aplikacji opartych na obliczeniach serverless. W przeciwieństwie do rozwiązań Kubernetes, Knative jest instalowane jako dodatek do każdego kompatybilnego klastra Kubernetes i konfigurowane przez zasoby użytkownika.

Czym jest Knative?

Knative jest opisany jako „Platforma oparta na Kubernetes do dostarczania i zarządzania obciążeniami za pomocą nowoczesnych obliczeń bezserwerowych”. Knative, ogłaszając się taką platformą, aktywnie automatycznie skaluje kontenery proporcjonalnie do równoczesnych zapytań HTTP. Nieużywane usługi w końcu skalują się do zera, zapewniając skalowanie na żądanie w stylu obliczeń bezserwerowych.

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

tworzenie aplikacji konteneryzowanych z kodu źródłowego (zapewnia komponent Build),
oferowanie dostępu do aplikacji dla nadchodzącego ruchu (zapewnia komponent Serving),
dostarczanie i automatyczne skalowanie aplikacji na żądanie (również zapewnia komponent Serving),
określanie źródeł wydarzeń, które powodują uruchamianie aplikacji (zapewnia komponent Eventing).

Kluczowym komponentem jest Serving, który zapewnia dostarczanie, automatyczne skalowanie i zarządzanie ruchem dla aplikacji sterowanych. Po zainstalowaniu Knative użytkownik wciąż ma pełny dostęp do API Kubernetes, co pozwala na zarządzanie aplikacjami w zwykły sposób oraz służy do debugowania usług Knative, pracując z tymi samymi prymitywami API, które te usługi wykorzystują (moduły, usługi itd.).

Za pomocą Serving automatyzowane jest również routowanie ruchu blue-green, co zapewnia podział ruchu między nowe a stare wersje aplikacji podczas dostarczania przez użytkownika zaktualizowanej wersji aplikacji.

Sam Knative polega na instalacji kompatybilnego kontrolera ingress. W momencie pisania artykułu obsługiwane są Gloo API Gateway i Istio Service Mesh. Skonfiguruje on dostępny ingress do routowania ruchu do aplikacji zarządzanych przez Knative.

Istio Service Mesh może stać się dużą zależnością dla użytkowników Knative, którzy chcą spróbować go bez instalacji panelu sterowania Istio, ponieważ Knative polega tylko na bramie.

Z tego powodu większość użytkowników wybiera Gloo jako bramę dla Knative, która oferuje podobny zestaw funkcji jak Istio (jeśli chodzi o zastosowanie tylko Knative), a jednocześnie zużywa znacznie mniej zasobów i generuje niższe koszty eksploatacji.

Sprawdźmy Knative w akcji na stanowisku. Będę używać świeżo zainstalowanego klastra uruchomionego w GKE:

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

Przechodzimy do instalacji 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 Pods są w statusie 'Running':

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 gotowy do routingu, stwórzmy automatycznie skalowalną usługę Knative (nazwiemy ją kservice) i skierujmy do niej ruch.

Usługi Knative oferują łatwiejszy sposób dostarczania aplikacji do Kubernetes w porównaniu do tradycyjnego modelu Deployment+Service+Ingress. Będziemy pracować z takim 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 w moim klastrze Kubernetes w ten sposób:

kubectl apply -f ksvc.yaml -n default

Możemy zobaczyć zasoby utworzone przez Knative w klastrze po dostarczeniu naszego ‘helloworld-go’ kservice:

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’ uruchamia się podczas wdrażania kservice. Jeśli nie będzie ruchu — liczba podów zostanie zmniejszona do zera. Z drugiej strony, jeśli liczba równoczesnych zapytań przekroczy pewną ustawioną wartość progową — liczba podów będzie rosła.

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

Knative konfiguruje swój ingress przy użyciu specjalnego zasobu ‘ingress’ w wewnętrznym API Knative. Gloo wykorzystuje to API jako swoją konfigurację do dostarczania właściwości charakterystycznych dla PaaS, w tym modelu wdrożenia blue-green, automatycznego stosowania TLS, timeoutów i innych zaawansowanych funkcji routingu.

Po chwili widzimy, że nasze pod'y zniknęły (ponieważ nie było ruchu przychodzącego):

kubectl get pod -n default

Nie znaleziono zasobów.
kubectl get deployment -n default
NAZWA                             POŻĄDANA   AKTUALNA   AKTUALIZOWANA   DOSTĘPNA   WIEK
helloworld-go-fjp75-deployment   0         0         0            0           9m46s

Na koniec spróbujemy się z nimi skontaktować. Uzyskanie URL do Knative Proxy jest łatwe i proste za pomocą glooctl:

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

Bez zainstalowanego glooctl można podejrzeć adres i port w kube service:

kubectl get svc -n gloo-system knative-external-proxy
NAZWA                     TYP           CLUSTER-IP     EXTERNAL-IP      PORT(Y)                      WIEK
knative-external-proxy   LoadBalancer   10.16.11.157   35.190.151.188   80:32168/TCP,443:30729/TCP   77m

Zróbmy trochę danych z użyciem cURL:

curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
Witaj użytkowniku Knative!

Knative zapewnia prawie PaaS dla programistów na bazie „z pudełka” Kubernetes, używając wydajnego, pełnofunkcjonalnego bramy API Gloo. Ta notatka jedynie dotknęła szerokiego zakresu możliwości Knative dostępnych do konfiguracji oraz dodatkowych funkcji. To samo dotyczy Gloo!

Mimo że Knative to wciąż młody projekt, jego zespół wydaje nowe wersje co sześć tygodni, rozpoczęto implementację zaawansowanych funkcji, takich jak automatyczne wdrażanie TLS, automatyczne skalowanie panelu sterowania. Istnieje wysokie prawdopodobieństwo, że wskutek współpracy licznych firm chmurowych i jako podstawa nowej oferty Cloud Run firmy Google, Knative może stać się kluczową alternatywą dla organizacji obliczeń bezserwerowych i PaaS w Kubernetes. Śledźcie nowości!

Od redakcji SouthBridge
Chcemy poznać zdanie czytelników, dlatego prosimy o udział w krótkiej ankiecie dotyczącej przyszłych artykułów o Knative, Kubernetes, obliczeniach bezserwerowych:

Tylko zarejestrowani użytkownicy mogą brać udział w ankiecie. Zaloguj się, proszę.