🥇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, которые эти сервисы используют (модули, сервисы и т.п.).

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, бессерверных вычислениях:

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.