Я получил возможность опробовать функцию обслуживания Knative для развертывания приложения Spring Boot, и в этом посте просто документируется образец и выбранный мной подход.
Я пока недостаточно разбираюсь во внутренностях Knative, чтобы иметь представление о том, лучше ли этот подход, чем подход, основанный на развертывании + сервисах + входе .
Одной из замечательных функций является функция автоматического масштабирования в Knative Serving, которая в зависимости от нагрузки увеличивает / уменьшает количество модулей в рамках «Развертывания», обрабатывающего запрос.
Детали образца
Весь мой образец доступен здесь, и он в основном разработан на основе примера Java, доступного в документации по Knative Serving . Я использовал Knative со средой мини-куба, чтобы попробовать пример.
Развертывание в Kubernetes / Knative
Предполагая, что среда Kubernetes с Istio и Knative настроена, способ запустить приложение состоит в том, чтобы развернуть манифест Kubernetes следующим образом:
01
02
03
04
05
06
07
08
09
10
11
12
|
apiVersion: serving.knative.dev/v1alpha1 kind: Service metadata: name: sample-boot-knative-service namespace: default spec: runLatest: configuration: revisionTemplate: spec: container: image: bijukunjummen/sample-boot-knative-app: 0.0 . 1 -SNAPSHOT |
Изображение «bijukunjummen / sample-boot-knative-app: 0.0.1-SNAPSHOT» общедоступно через Dockerhub , поэтому этот образец должен работать «из коробки».
Применяя этот манифест:
1
|
kubectl apply -f service.yml |
следует зарегистрировать ресурс Knative Serving Service в Kubernetes, ресурс обслуживающих услуг Knative управляет жизненным циклом других ресурсов Knative (конфигурация, редакция, маршрут), сведения о которых можно просмотреть с помощью следующих команд. Если что-то пойдет не так, детали должны отображаться на выходе:
1
|
kubectl get services.serving.knative.dev sample-boot-knative-service -o yaml |
тестирование
Предполагая, что служба обслуживания Knative развернута корректно, первой странностью будет то, что для приложения не отображаются модули!
Если бы я должен был сделать запрос к приложению сейчас, что делается через слой маршрутизации, управляемый Knative — это можно получить для среды мини-куба, используя следующий скрипт bash:
1
2
|
export GATEWAY_URL=$(echo $(minikube ip):$(kubectl get svc knative-ingressgateway -n istio-system -o 'jsonpath={.spec.ports[?(@.port==80)].nodePort}' )) export APP_DOMAIN=$(kubectl get services.serving.knative.dev sample-boot-knative-service -o= "jsonpath={.status.domain}" ) |
и вызову конечной точки приложения с помощью CUrl:
1
2
3
4
5
6
7
8
9
|
-H "Accept: application/json" \ -H "Content-Type: application/json" \ -H "Host: ${APP_DOMAIN}" \ -d $'{ "id" : "1" , "payload" : "one" , "delay" : "300" }' |
ИЛИ httpie
1
|
http http: // ${GATEWAY_URL} /messages Host: "${APP_DOMAIN}" id =1 payload= test delay=100 |
следует по волшебству, используя компонент автоматического масштабирования, начать раскручивать модули для обработки запроса:
Первый запрос занял почти 17 секунд, время, необходимое для раскрутки модуля, но последующие запросы выполняются быстро.
Теперь, чтобы показать реальную мощность автоматического масштабирования, я провел небольшой тест нагрузки с нагрузкой 50 пользователей, а модули масштабировались вверх и вниз по мере необходимости.
Вывод
Я вижу перспективу Knative в автоматическом управлении ресурсами, когда-то определенными с использованием довольно простого манифеста, в среде Kubernetes и позволяющей разработчику сосредоточиться на коде и логике.
См. Оригинальную статью здесь: «Knative Serving» для приложений Spring Boot
Мнения, высказанные участниками Java Code Geeks, являются их собственными. |