🥇Knative — платформа като услуга на база k8s с поддръжка на serverless

Общоприетата платформа за разгръщане на контейнери несъмнено е Kubernetes. Тя предоставя възможност за управление на почти всичко, използвайки своите API и потребителски контролери, които разширяват API-то чрез потребителски ресурси.

Въпреки това, потребителят все още трябва да вземе подробни решения относно това как точно да разгръща, конфигурира, управлява и мащабира приложенията. Въпросите относно мащабирането на приложението, защитата и преминаването на трафика остават на преценката на потребителя. Това е разликата между Kubernetes и обикновените "платформи като услуга" (PaaS), като например Cloud Foundry и Heroku.

Платформите разполагат с опростен потребителски интерфейс, който е насочен към разработчиците на приложения, които най-често се занимават с конфигуриране на отделни приложения. Маршрутизацията, разгръщането и метриките се управляват прозрачно за потребителя от основната PaaS система.

Работният поток "изходен код – доставка" се обработва от PaaS чрез създаване на потребителски контейнърен образ, неговото разгръщане, конфигуриране на нов маршрут и поддомен DNS за входящия трафик. Всичко това се активира по команда. git push.

В Kubernetes (умислено) се предоставят само основните блокове за такива платформи, предоставяйки на общността възможност да свърши тази работа сама. Както каза Келси Хайтъуър:

Kubernetes е платформа за изграждане на платформи. Най-добрата отправна позиция, но не и финалната.

В резултат виждаме множество версии на Kubernetes, както и хостинг компании, които се опитват да създадат PaaS за Kubernetes, например OpenShift и Rancher. В контекста на нарастващия пазар на Kube-PaaS, на сцената излиза Knative, създаден през юли 2018 г. от компаниите Google и Pivotal.

Knative е резултат от съвместната работа на Google и Pivotal, с малко съдействие от други компании, като IBM, RedHat и Solo.im. Той предлага сходни PaaS функции за Kubernetes с първокласна поддръжка за приложения, базирани на безсърверни изчисления. За разлика от версиите на Kubernetes, Knative се инсталира като добавка на всеки съвместим кластер Kubernetes и се конфигурира чрез потребителски ресурси.

Какво е Knative?

Knative е описан като «Платформа на базата на Kubernetes за доставка на работни натоварвания и управление с помощта на съвременни безсървърни изчисления». Knative, обявявайки се за такава платформа, активно автоматично мащабира контейнери пропорционално на едновременните HTTP заявки. Неизползваните услуги в крайна сметка се мащабират до нула, предоставяйки мащабиране при поискване в стил безсървърни изчисления.

Knative се състои от набор от контролери, инсталирани във всеки кластер Kubernetes и осигуряващи следните възможности:

сглобяване на контейнеризирани приложения от източния код (предоставя се от компонента Build),
осигуряване на достъп на входящия трафик до приложенията (предоставя се от компонента Serving),
доставка и автоматично мащабиране на приложения при поискване (също предоставяно от компонента Serving),
определяне на източниците на събития, водещи до стартиране на приложенията (предоставя се от компонента Eventing).

Ключовият компонент е Serving, който предоставя доставка, автоматично мащабиране и управление на преминаването на трафика за управлявани приложения. След инсталирането на Knative, все още остава пълен достъп до API на Kubernetes, което позволява на потребителите да управляват приложенията по обикновения начин, а също така служи за отстраняване на грешки в услугите Knative, работейки с идентичните примитиви на API, които тези услуги използват (модули, услуги и т.н.).

С помощта на Serving също се автоматизира blue-green маршрутизацията на трафика, осигурявайки разделяне на трафика между новите и старите версии на приложението при доставка на актуализирана версия от потребителя.

Самият Knative зависи от инсталацията на съвместим контролер на входящия трафик. По време на писането на статията се поддържат Gloo API Gateway и Istio Service Mesh. Той ще конфигурира наличен входящ контролер за маршрутизиране на трафика към управляваните от Knative приложения.

Istio Service Mesh може да се окаже значителна зависимост за потребителите на Knative, желаещи да го изпробват без инсталиране на панел за управление Istio, тъй като Knative зависи само от шлюза.

Поради това повечето потребители предпочитат Gloo като шлюз за Knative, който предлага подобен набор от функции като Istio (а ако говорим за целта на използването само на Knative), както и използва значително по-малко ресурси и предлага по-ниски експлоатационни разходи.

Нека да проверим Knative в действие на стенда. Аз ще използвам ново инсталиран кластер, работещ в GKE:

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

Нека започнем с инсталирането на Knative и Gloo. Това може да стане в произволен ред:

# ставим 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
# ...

Проверяваме, че всички Pods са в статус "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 е готов за маршрутизиране, нека да създадем автоматично мащабируем Knative сервис (нека го наречем kservice) и да насочим трафика му.

Сервизите на Knative предлагат по-лесен начин за доставка на приложения в Kubernetes в сравнение с обичайната модел на Deployment+Service+Ingress. Нека работим с такъв пример:

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

Аз копирах това в файл, след което го приложих на моя кластер Kubernetes по следния начин:

kubectl apply -f ksvc.yaml -n default

Можем да прегледаме ресурсите, създадени от Knative в кластера след доставката на нашия ‘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 с нашия образ ‘helloworld-go’ се стартира при разгръщането на kservice. Ако няма трафик — броят на Pod-овете ще намалее до нула. И обратно, ако броят на едновременните заявки надвиши определен конфигурируем праг — броят на Pod-овете ще расте.

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

Knative конфигурира своя ingress, използвайки специален ‘ingress’ ресурс във вътрешния си API. Gloo използва този API като своя конфигурация, за да предостави PaaS-свойства, включително blue-green модел за разгръщане, автоматично прилагане на TLS, таймаути и други разширени функции за маршрутизиране.

След известно време виждаме, че нашите pod-ове са изчезнали (тъй като нямаше входящ трафик):

kubectl get pod -n default

Няма намерени ресурси.
kubectl get deployment -n default
NAME                             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
helloworld-go-fjp75-deployment   0         0         0            0           9m46s

Накрая ще се опитаме да се свържем с тях. Получаването на URL за Knative Proxy е лесно и удобно с помощта на glooctl:

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

Без инсталирано glooctl можете да видите адреса и порта в kube service:

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

Нека стартираме малко данни с помощта на cURL:

curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
Здравейте, потребители на Knative!

Knative предлага почти-PaaS за разработчиците над „изход от кутията“ Kubernetes, използвайки високопроизводителен, пълнофункционален API шлюз Gloo. Тази бележка само леко се докосва до многото възможности на Knative, налични за конфигуриране, както и допълнителни функции. Аналогично и с Gloo!

Въпреки че Knative все още е млад проект, неговият екип пуска нови версии на всеки шест седмици, започна внедряване на разширени функции, като автоматично разгръщане на TLS, автоматично мащабиране на контролния панел. Има голяма вероятност, че благодарение на сътрудничеството на многобройни облачни компании, както и като основа на новото предложение Cloud Run от Google, Knative може да стане основен вариант за организиране на безсървърни изчисления и PaaS в Kubernetes. Следете новините!

От редакцията SouthBridge
Важно е да чуем мнението на читателите, затова ви молим да участвате в кратко проучване, свързано с бъдещите статии за Knative, Kubernetes, безсървърни изчисления:

Само регистрирани потребители могат да участват в анкетата. Влезте, моля.