Доминирующей платформой для развертывания контейнеров, несомненно, стал 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 44sGloo готов к маршрутизации, давайте создадим автоматически масштабируемый сервис 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 68sPod с нашим образом 'helloworld-go' запускается при развертывании kservice. Если трафика не будет — число pod'ов будет сокращено до нуля. И наоборот, если число одновременных запросов превысит некоторое настраиваемое пороговое значение — число pod'ов будет расти.
kubectl get ingresses.networking.internal.knative.dev -n default
NAME READY REASON
helloworld-go TrueKnative настраивает свой 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, бессерверных вычислениях:
Автор: Павел
