Knative - базирана на k8s платформа като услуга с поддръжка без сървър

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 и предоставят следните възможности:

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

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

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

Самият 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 са в състояние „Работещи“:

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

Подът с нашето изображение „helloworld-go“ се стартира, когато kservice е разгърната. Ако няма трафик, броят на капсулите ще бъде намален до нула. И обратното, ако броят на едновременните заявки надвишава определен конфигурируем праг, броят на подовете ще се увеличи.

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

Knative конфигурира входа си с помощта на специален ресурс „ingress“ във вътрешния API на Knative. Gloo използва този API като своя конфигурация, за да предостави функции, подобни на PaaS, включително синьо-зелен модел на внедряване, автоматично налагане на TLS, изчакване и други разширени функции за маршрутизиране.

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

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:

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, автоматично мащабиране на контролния панел. Има голям шанс, че в резултат на сътрудничеството между множество облачни компании и като основа на новото предложение на Google Cloud Run, Knative може да се превърне в основната опция за изчисления без сървър и PaaS на Kubernetes. Следете новините!

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

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

Трябва ли да продължа да пиша статии и ръководства за Knative и компютри без сървър?

• Да моля.

• Не благодаря.

28 потребители гласуваха. 4 потребители се въздържаха.

Източник: www.habr.com