Хабрахабр

[Перевод] Knative — платформа как услуга на основе k8s с поддержкой serverless

Он предоставляет возможность управлять практически всем, используя свои API и пользовательские контроллеры, расширяющие его API посредством пользовательских ресурсов. Доминирующей платформой для развертывания контейнеров, несомненно, стал Kubernetes.

На усмотрение пользователя остаются вопросы масштабирования приложения, защиты, прохождения трафика. Тем не менее пользователь все еще должен принимать подробные решения о том, как именно разворачивать, настраивать, управлять и масштабировать приложения. Этим Kubernetes отличается от обычных "платформ как услуга" (PaaS), к примеру Cloud Foundry и Heroku.

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

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

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

Лучшая позиция для старта, но не финиша. Kubernetes — платформа для построения платформ.

На фоне растущего рынка Kube-PaaS на ринг выходит Knative, созданный в июле 2018 года компаниями Google и Pivotal. В результате мы видим пачку сборок Kubernetes, а также хостингов, которые пытаются создать PaaS для Kubernetes, к примеру OpenShift и Rancher.

Он предлагает аналогичные PaaS вещи для Kubernetes с первоклассной поддержкой приложений на основе бессерверных вычислений. Knative получился в результате совместной работы Google и Pivotal, при небольшом содействии других компаний, к примеру IBM, RedHat и Solo.im. В отличие от сборок Kubernetes, Knative устанавливается в виде дополнения на любой совместимый кластер Kubernetes, настраивается через пользовательские ресурсы.

Что такое Knative?

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

Knative состоит из набора контроллеров, устанавливаемых в любой кластер Kubernetes и обеспечивающих следующие возможности:

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

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

C помощью Serving также автоматизируется blue-green маршрутизация трафика, обеспечивая разделение трафика между новыми и старыми версиями приложения при поставке пользователем обновленной версии приложения.

На момент написания статьи поддерживаются Gloo API Gateway и Istio Service Mesh. Сам Knative зависит от установки совместимого ingress контроллера. Он настроит доступный ingress для маршрутизации трафика к управляемым посредством Knative приложениям.

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

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

Я буду использовать свежеустановленный кластер, запущенный в GKE: Давайте проверим Knative в действии на стенде.

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'ов будет сокращено до нуля. Pod с нашим образом 'helloworld-go' запускается при развертывании kservice. И наоборот, если число одновременных запросов превысит некоторое настраиваемое пороговое значение — число pod'ов будет расти.

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

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

Спустя некоторое время мы видим, что наши 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, доступных для настройки, а также дополнительных функций. Knative предоставляет почти-PaaS для разработчиков поверх "изкоробочного" Kubernetes, используя высокопроизводительный полнофункциональный шлюз API Gloo. Аналогично и с Gloo!

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

От редакции SouthBridge
Нам важно мнение читателей, поэтому мы просим вас принять участие в небольшом опросе, связанном с будущими статьями о Knative, Kubernetes, бессерверных вычислениях:

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть