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 і забяспечваюць наступныя магчымасці:

• зборка кантэйнерызаваных прыкладанняў з зыходнага кода (прадастаўляецца кампанентам Будаваць),
• прадастаўленне доступу ўваходзіць трафіку да прыкладанняў (прадастаўляецца кампанентам Абслугоўванне),
• пастаўка і аўтаматычнае маштабаванне прыкладанняў па запыце (таксама падаецца кампанентам Абслугоўванне),
• вызначэнне крыніц падзей, якія прыводзяць да запуску прыкладанняў (прадастаўляецца кампанентам Падзеі).

Ключавым кампанентам з'яўляецца Serving, які дае пастаўку, аўтаматычнае маштабаванне і кіраванне праходжаннем трафіку для кіраваных прыкладанняў. Пасля ўстаноўкі Knative усё яшчэ захоўваецца поўны доступ да API Kubernetes, што дазваляе карыстальнікам кіраваць праграмамі звычайным спосабам, а таксама служыць для адладкі сэрвісаў Knative, працуючы з тымі ж прымітывамі API, якія гэтыя сэрвісы выкарыстоўваюць (модулі, сэрвісы і да т.п.).

C дапамогай 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

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

Нарэшце паспрабуем да іх дастукацца. Атрымаць 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
Hello Knative user!

Knative падае амаль-PaaS для распрацоўнікаў па-над «изкоробочного» Kubernetes, выкарыстаючы высокапрадукцыйны поўнафункцыянальны шлюз API Gloo. Гэтая нататка толькі злёгку кранула шырокай колькасці магчымасцяў Knative, даступных для налады, а таксама дадатковых функцый. Аналагічна і з Gloo!

Нягледзячы на ​​тое, што Knative усё яшчэ малады праект, яго каманда выпускае новыя версіі кожныя шэсць тыдняў, пачата рэалізацыя прасунутых функцый, напрыклад аўтаматычнае разгортванне TLS, аўтаматычнае маштабаванне панэлі кіравання. Ёсць высокая верагоднасць таго, што ў выніку супрацоўніцтва шматлікіх хмарных кампаній, а таксама ў якасці асновы новай прапановы Cloud Run ад кампаніі Google, Knative можа стаць асноўным варыянтам для арганізацыі бессерверных вылічэнняў і PaaS у Kubernetes. Сачыце за навінамі!

Ад рэдакцыі SouthBridge
Нам важна меркаванне чытачоў, таму мы просім вас прыняць удзел у невялікім апытанні, звязаным з будучымі артыкуламі пра Knative, Kubernetes, бессерверныя вылічэнні:

Толькі зарэгістраваныя карыстачы могуць удзельнічаць у апытанні. Увайдзіце, Калі ласка.

Перакладацьпісаць далей артыкулы і кіраўніцтва аб Knative і бессерверных вылічэннях?

• Ды калі ласка.

• Дзякуй, не трэба.

Прагаласавалі 28 карыстальнікаў. Устрымаліся 4 карыстальніка.

Крыніца: habr.com