Serverless na Kubernetesie

Zobacz, jak sprawić, aby funkcje Serverless poprawnie współpracowały z Kubernetesem.

Przeczytawszy tytuł, pewnie zastanawiasz się, jak w ogóle można połączyć dwie rzeczy, które zupełnie do siebie nie pasują — czyli Serverless i Kubernetes. Wyjaśnijmy zatem.

Czym jest Serverless?

Podchodząc do sprawy wysokopoziomowo, Serverless to metoda deploymentu, która całkowicie abstrahuje serwery. Programiści chcą po prostu napisać swój kod i uruchomić swoją aplikację za pomocą jednego przycisku oraz bez potrzeby planowania deploymentu, konfiguracji automatycznego skalowania lub jakichkolwiek innych trudnych zadań infrastrukturalnych.

W niektórych przypadkach takie coś jest pewnie lepsze niż Kubernetes. W miarę, jak definicja Serverless się jednak rozwijała, to pojawiły się dwa wzorce:

Kontener jako usługa

Załóżmy, że przeprowadzasz deployment aplikacji jako kontener i oczekujesz, że platforma zrobi za Ciebie wszystko. Możesz uruchamiać kontenery w Kubernetesie, ale nadal masz trochę ruchomych części do skonfigurowania, wgrania, aktualizacji oraz automatycznego skalowania.

Platforma oferująca kontener jako usługę po prostu przyjmuje od programisty kontener i robi dla nich wszystko, co trzeba. Popularnymi dostawcami chmury na tej przestrzeni są Google Cloud Run i AWS Fargate.

Funkcja jako usługa

Zamiast wdrażać cały kontener, wdrażasz jedynie pojedynczą funkcję, która może zawierać tylko jedną metodę. Następnie budujesz swoją własną usługę, łącząc ze sobą wiele funkcji. Popularnymi dostawcami chmur na tej przestrzeni są Google Cloud Functions i AWS Lambda. Serverless jest zatem ciekawym sposobem na robienie pewnych rzeczy, przy czym jest jedno „ale”.

Jak się to ma do Kubernetesa?

Jako zespół operacyjny obsługujący workload, powinniście myśleć o Kubernetesie jak o rozproszonej platformie do uruchamiania całej infrastruktury, niezależnie od tego, jak została zbudowana lub jak musi zostać wykonany deployment. Nowe projekty mogą obejmować obsługę Serverless i polegać na wdrożeniu całego stosu na takich funkcjach. Istnieją jednak przypadki, w których metoda ta nie sprawdzi się ze względu na ograniczenia narzucane przez oprogramowanie.

Konieczne może być też wdrożenie oprogramowania dla wielu różnych zespołów, z których każdy ma własne wymagania. Możliwe, że większość Twojego workloadu może być oparta na deploymencie natywnego kontenera Kubernetesa.

Ale jeśli deweloper chce wpleść tu funkcje serverless, to Kubernetes jest w stanie świadczyć usługi, które wspierają taki deployment. Możesz dzięki temu nadal uruchamiać jeden, bardziej rozbudowany i rozproszony system, bez konieczności pracy na wielu różnych systemach.

Jak Kubernetes sobie z tym radzi?

Dla kontenerów serverless, mamy Knative

Projekt ten zapewnia dla kontenerów serverless deployment na zasadzie „click to deploy”. Jest to osiągnięte poprzez dodanie nowych niestandardowych zasobów do Kubernetes dla kontenerów serverless.

Oznacza to, że budujesz swoje kontenery i wykonujesz ich deployment w Knative. Knative dba o tworzenie sieci, kontrolę wersji i automatyczne skalowanie, które zwiększa się wraz z popytem i skaluje się do zera, gdy zajdzie taka potrzeba.

Możesz użyć Knative przez Cloud Run

Jest to produkt GCP, który implementuje te same usługi, co Knative, bez potrzeby klastra GKE. Możesz oczywiście rozszerzyć swój klaster GKE, instalując Knative, lub pozwolić Google to zrobić, dodając Cloud Run na GKE podczas jego budowania tak jak w przypadku kontenera jako usługi. Ale co z funkcjami?

Instalacja Knative na klastrze (GKE)

gcloud beta container clusters create $CLUSTER_NAME \
  --addons=HorizontalPodAutoscaling,HttpLoadBalancing,Istio \
  --machine-type=n1-standard-4 \
  --cluster-version=latest --zone=$CLUSTER_ZONE \
  --enable-stackdriver-kubernetes --enable-ip-alias \
  --enable-autoscaling --min-nodes=1 --max-nodes=10 \
  --enable-autorepair \
  --scopes cloud-platform

Aby zainstalować Knative na innych klastrach, zapoznaj się z dokumentacją projektu.

Deployment aplikacji przy użyciu Knative

Możesz użyć pliku .yaml, aby dokonać deploymentu skonteneryzowanej aplikacji:

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: hello_world
  namespace: default
spec: 
  runLatest:
    configuration: 
      revisionTemplate: 
        spec: 
          container: 
            image: gcr.io/knative-samples/helloworld-go
            env: 
             - name: TARGET
               value: "Beautiful People"

Uruchom .yaml w klastrze GKE, używając:

kubectl apply -f filename.yaml

Gdy dokonujemy deploymentu aplikacji Knative po raz pierwszy, musimy pobrać adres IP konfigurowany w interfejsie klastra:

export IP_ADDERSS=$(kubectl get svc istio-ingressgateway --namescpace 
istio-system --output 'jsonpath=
{.status.loadbalancer.ingress[0].ip}')

Wreszcie, aby uzyskać domenę wyjściową, musisz wykonać:

kubectl get route helloworld --output=custom-
coloum=Name:.metadata.name,DOMAIN:.status.domain

Po tym poleceniu otrzymujemy kolumnę domeny obok nazwy naszej aplikacji. Nazwijmy ją [DomainName]. Skopiuj tę domenę i wklej następne polecenie, aby zobaczyć dane wyjściowe w terminalu.

curl -H "Host: [DomainName]" http://${IP_ADDERSS}

Funkcje Serverless na Kubernetesie dzieki OpenFaaS

Jeśli kiedykolwiek pracowałeś z Cloud Functions lub AWS Lambda, to pewnie znasz się na funkcjach serverless; to platformy FaaS, czyli funkcje jako usługi. Możesz osiągnąć coś podobnego na Kubernetesie, instalując projekt open source o nazwie OpenFaaS. Dostępne są również inne opcje, takie jak Kubeless i Fission, ale na razie będziemy trzymać się OpenFaaS.

Funkcje, które są wdrażane w OpenFaaS, nadal są kontenerami, ale zostały zaprojektowane tak, aby były, jak najmniejsze. Co więcej, w przeciwieństwie do kontenera, który jest wdrażany jako własna usługa, nie muszą one zawierać komponentu służącego do udostępniania stron internetowych.

Żądania HTTP są abstrahowane przez dedykowany komponent OpenFaaS, aby same kontenery były maksymalnie uproszczone. W ten sposób OpenFaaS wciąż nie jest tak lekki, jak jakaś dedykowana platforma, np. Google Cloud Functions. Jest on jednak o wiele bardziej konfigurowalny. Pozwala uruchomić funkcję serverless w obrębie własnego klastra GKE.

Poradnik dotyczący instalacji OpenFaaS znajduje się na tej stronie.

Możemy wdrożyć funkcję za pomocą OpenFaaS, wskazując plik definicji w GitHub przy użyciu:

faas-cli deploy -f 
https://raw.githubusercontents.com/openfaas/faas/master/stack.yaml

Spowoduje to zainstalowanie przydatnej konsoli webowej do deploymentu pożądanych funkcji. Jeśli rozbijesz swój stos na usługę składającą się z wielu komponentów i użyjesz tu serverless, to OpenFaaS zapewnia w pełni funkcjonalną platformę serverless, która będzie nadal działać na Twoim własnym klastrze Kubernetes.

Oryginał tekstu w języku angielskim przeczytasz tutaj.