В своей базовой конфигурации c маршруты посла основаны на поступлении prefix
запроса. В настоящее время посол настроен на маршрутизацию запросов с prefix: /api/minio/
на службу с именем minio-svc
через порт 9000
с prefix: /
.
. При такой конфигурации запрос на http(s)://{{IP}}/api/minio/
будет правильно попадать в minio-svc
с префиксом, переписанным в /
. Однако, если вы проверите сетевые журналы, вы увидите, что когда minio получает запрос с prefix: /
, он отправляет перенаправление 307 на /minio/
, который не является зарегистрированным маршрутом в Ambassador, поэтому вы видите сбой.
Исправление для этого - отредактировать Mapping
для маршрутизации на основе prefix: /minio/
и не переписывать этот префикс при отправке запроса в нисходящем направлении:
apiVersion: v1
kind: Service
metadata:
annotations:
getambassador.io/config: |
---
apiVersion: ambassador/v1
kind: Mapping
name: _api_minio
service: "http://minio-svc:9000"
prefix: /minio/
rewrite: ""
bypass_auth: true
host: xxxx
add_response_headers:
Strict-Transport-Security: max-age=15552000; includeSubDomains
X-Frame-Options: SAMEORIGIN
creationTimestamp: '2020-01-09T15:10:34Z'
labels:
platform: xxx
name: minio
namespace: xxx
resourceVersion: 'xxxxx'
selfLink: /api/v1/namespaces/services/minio
uid: 2f7619a0-32f2-11ea-9dcc-xxxxxxxx
spec:
clusterIP:xxxxx
ports:
- port: 80
protocol: TCP
targetPort: 80
sessionAffinity: None
type: ClusterIP
Теперь запрос к http(s)://{{IP}}/minio/
будет отправить в службу minio-svc
через порт 9000
с prefix: /minio/
, который должен разрешиться.
При отладке таких более крупных приложений GUI за обратным прокси очень полезно проверить сеть Журналы вашего браузера, чтобы увидеть, если есть запросы ресурсов, которые не выполняются.