🥇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, все още остава пълен достъп до Kubernetes API, което позволява на потребителите да управляват приложенията по обикновен начин, а също така служи за отстраняване на проблеми с услугите на Knative, работейки с онези същите примитиви на API, които тези услуги използват (модули, услуги и т.н.).

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

Самият Knative зависи от инсталирането на съвместим ingress контролер. Към момента на написване на статията поддържани са Gloo API Gateway и Istio Service Mesh. Той ще настрои наличния ingress за маршрутизиране на трафика към управляваните чрез 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 на Knative. Gloo взима това API за своя конфигурация, за да осигури характеристики, присъщи за PaaS, включително blue-green модел на разгръщане, автоматично прилагане на TLS, таймаути и други разширени функции за маршрутизиране.

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

kubectl get pod -n default

Не са намерени ресурси.
kubectl get deployment -n default
ИМЕ                             ЖЕЛАНИ   ТЕЧЕЩИ   АКТУАЛИЗИРАНИ   НАЛИЧНИ   ВЪЗРАСТ
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
ИМЕ                     ТИП           КЛУСТЕР-IP     ВЪНШЕН-IP      ПОРТ(ОВЕ)                      ВЪЗРАСТ
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, автоматично мащабиране на контролния панел. Има голяма вероятност Knative, в резултат на сътрудничеството на множество облачни компании и като основа на новото предложение Cloud Run от Google, да стане основен вариант за организиране на безсървърни изчисления и PaaS в Kubernetes. Следете новините!

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

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