Статьи

Knative Serving — Сервисное обслуживание

Февраль 11, 2019

В предыдущем посте я рассмотрел использование функции обслуживания Knative для запуска примера Java-приложения. Этот пост будет посвящен этапам развертывания двух приложений, при этом одно приложение вызывает другое.

Knative

Детали образца

Весь образец доступен в моем репозитории github — https://github.com/bijukunjummen/sleuth-webflux-sample.

Приложения основаны на Spring Boot . Внутреннее приложение предоставляет конечную точку «/ messages» при вызове с полезной нагрузкой, которая выглядит следующим образом:

1
2
3
4
5
6
{
    "delay": "0",
    "id": "123",
    "payload": "test",
    "throw_exception": "true"
}

ответит после указанной задержки. Если полезная нагрузка имеет флаг throw_exception, установленный в значение true, то он вернет 5XX после указанной задержки.

Клиентское приложение предоставляет конечную точку «/ passthrough / messages», которая получает точно такую ​​же полезную нагрузку и просто перенаправляет ее в бэкэнд-приложение. URL-адрес внутреннего приложения передается клиентскому приложению как свойство среды «LOAD_TARGET_URL».

Knative

Развертывание как сервис Knative Serving

Подпапка к этому проекту — knative, содержит манифест для развертывания службы обслуживания Knative для 2 приложений. Собственный сервисный манифест внутреннего приложения выглядит так:

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: sample-backend-app
  namespace: default
spec:
  runLatest:
    configuration:
      revisionTemplate:
        spec:
          container:
            image: bijukunjummen/sample-backend-app:0.0.1-SNAPSHOT
            env:
            - name: VERSION
              value: "0.0.2-SNAPSHOT"
            - name: SERVER_PORT
              value: "8080"

Клиентское приложение должно указывать на бэкэнд-сервис и указывается в спецификации:

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: sample-client-app
  namespace: default
spec:
  runLatest:
    configuration:
      revisionTemplate:
        spec:
          container:
            image: bijukunjummen/sample-client-app:0.0.2-SNAPSHOT
            env:
            - name: VERSION
              value: "0.0.1-SNAPSHOT"
            - name: LOAD_TARGET_URL
              value: http://sample-backend-app.default.svc.cluster.local
            - name: SERVER_PORT
              value: "8080"

Домен «sample-backend-app.default.svc.cluster.local» указывает на DNS-имя серверной службы, созданной ресурсом службы Knative.

тестирование

Мне было проще просто создать небольшое видео с тем, как я это тестировал:

Как и в моем предыдущем посте , запрос к приложению осуществляется через входной входной шлюз, URL-адрес которого можно получить следующим образом (для среды мини-куба):

1
export GATEWAY_URL=$(echo $(minikube ip):$(kubectl get svc knative-ingressgateway -n istio-system -o 'jsonpath={.spec.ports[?(@.port==80)].nodePort}'))

И пример запроса сделан следующим образом, обратите внимание, что маршрутизация в шлюзе осуществляется через заголовок хоста, в данном случае «sample-client-app.default.example.com»:

1
2
3
export CLIENT_DOMAIN=$(kubectl get services.serving.knative.dev sample-client-app  -o="jsonpath={.status.domain}")
 
http http://${GATEWAY_URL}/passthrough/messages Host:"${CLIENT_DOMAIN}" id=1 payload=test delay=100 throw_exception=false
Смотрите оригинальную статью здесь: Knative Serving — сервисный сервис

Мнения, высказанные участниками Java Code Geeks, являются их собственными.

37
Share: