Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Ten dokument ułatwia skonfigurowanie przykładowej aplikacji wykorzystującej zasoby z interfejsu API Gateway w celu zademonstrowania hostowania wielu witryn na tym samym zasobie Kubernetes Gateway / Application Gateway for Containers. Podano kroki, aby:
- Utwórz zasób Gateway z jednym odbiornikiem HTTP.
- Utwórz dwa zasoby usługi HTTPRoute , które odwołują się do unikatowej usługi zaplecza.
Kontekst
Usługa Application Gateway dla kontenerów umożliwia hostowanie wielu witryn, umożliwiając skonfigurowanie więcej niż jednej aplikacji internetowej na tym samym porcie. Co najmniej dwie unikatowe witryny mogą być hostowane przy użyciu unikatowych usług zaplecza. Zobacz następujący przykładowy scenariusz:
Wymagania wstępne
Jeśli użyto strategii wdrażania BYO, upewnij się, że skonfigurujesz Application Gateway for Containers i kontroler ALB.
Jeśli użyłeś strategii wdrażania zarządzanego ALB, upewnij się, że aprowizowany jest zarówno Kontroler ALB, jak i zasoby usługi Application Gateway for Containers, za pośrednictwem niestandardowego zasobu ApplicationLoadBalancer.
Wdróż przykładową aplikację HTTP:
Zastosuj następujący plik deployment.yaml w klastrze, aby utworzyć przykładową aplikację internetową w celu zademonstrowania routingu opartego na ścieżkach, zapytaniach i nagłówkach.kubectl apply -f https://raw.githubusercontent.com/MicrosoftDocs/azure-docs/refs/heads/main/articles/application-gateway/for-containers/examples/traffic-split-scenario/deployment.yamlTo polecenie tworzy w klastrze następujące elementy:
- Przestrzeń nazw o nazwie
test-infra - Dwie usługi o nazwie
backend-v1ibackend-v2wtest-infraprzestrzeni nazw - Dwa wdrożenia o nazwie
backend-v1ibackend-v2w przestrzeni nazw o nazwietest-infra
- Przestrzeń nazw o nazwie
Wdróż wymagane zasoby Gateway API
- Tworzenie bramy
kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: gateway-01
namespace: test-infra
annotations:
alb.networking.azure.io/alb-namespace: alb-test-infra
alb.networking.azure.io/alb-name: alb-test
spec:
gatewayClassName: azure-alb-external
listeners:
- name: http-listener
port: 80
protocol: HTTP
allowedRoutes:
namespaces:
from: Same
EOF
Uwaga / Notatka
Gdy kontroler usługi ALB tworzy zasoby usługi Application Gateway for Containers w usłudze Azure Resource Manager, używa następującej konwencji nazewnictwa dla zasobu frontonu: fe-<eight randomly generated characters>.
Jeśli chcesz zmienić nazwę zasobu interfejsu frontowego utworzonego w Azure, rozważ zastosowanie strategii wdrożenia 'bring-your-own'.
Po utworzeniu zasobu bramy upewnij się, że stan jest prawidłowy, nasłuchiwacz jest zaprogramowany, a do bramy przypisano adres.
kubectl get gateway gateway-01 -n test-infra -o yaml
Przykładowy wynik pomyślnie utworzonej bramy.
status:
addresses:
- type: Hostname
value: xxxx.yyyy.alb.azure.com
conditions:
- lastTransitionTime: "2023-06-19T21:04:55Z"
message: Valid Gateway
observedGeneration: 1
reason: Accepted
status: "True"
type: Accepted
- lastTransitionTime: "2023-06-19T21:04:55Z"
message: Application Gateway For Containers resource has been successfully updated.
observedGeneration: 1
reason: Programmed
status: "True"
type: Programmed
listeners:
- attachedRoutes: 0
conditions:
- lastTransitionTime: "2023-06-19T21:04:55Z"
message: ""
observedGeneration: 1
reason: ResolvedRefs
status: "True"
type: ResolvedRefs
- lastTransitionTime: "2023-06-19T21:04:55Z"
message: Listener is accepted
observedGeneration: 1
reason: Accepted
status: "True"
type: Accepted
- lastTransitionTime: "2023-06-19T21:04:55Z"
message: Application Gateway For Containers resource has been successfully updated.
observedGeneration: 1
reason: Programmed
status: "True"
type: Programmed
name: https-listener
supportedKinds:
- group: gateway.networking.k8s.io
kind: HTTPRoute
Po utworzeniu bramy utwórz dwa zasoby HTTPRoute dla contoso.com i fabrikam.com nazw domen. Każda domena przekazuje ruch do innej usługi zaplecza.
kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: contoso-route
namespace: test-infra
spec:
parentRefs:
- name: gateway-01
hostnames:
- "contoso.com"
rules:
- backendRefs:
- name: backend-v1
port: 8080
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: fabrikam-route
namespace: test-infra
spec:
parentRefs:
- name: gateway-01
hostnames:
- "fabrikam.com"
rules:
- backendRefs:
- name: backend-v2
port: 8080
EOF
Po utworzeniu zasobu usługi HTTPRoute upewnij się, że oba zasoby usługi HTTPRoute zawierają wartość Zaakceptowane , a zasób Application Gateway for Containers jest zaprogramowany.
kubectl get httproute contoso-route -n test-infra -o yaml
kubectl get httproute fabrikam-route -n test-infra -o yaml
Sprawdź, czy stan zasobu usługi Application Gateway dla kontenerów został pomyślnie zaktualizowany dla każdej usługi HTTPRoute.
status:
parents:
- conditions:
- lastTransitionTime: "2023-06-19T22:18:23Z"
message: ""
observedGeneration: 1
reason: ResolvedRefs
status: "True"
type: ResolvedRefs
- lastTransitionTime: "2023-06-19T22:18:23Z"
message: Route is Accepted
observedGeneration: 1
reason: Accepted
status: "True"
type: Accepted
- lastTransitionTime: "2023-06-19T22:18:23Z"
message: Application Gateway For Containers resource has been successfully updated.
observedGeneration: 1
reason: Programmed
status: "True"
type: Programmed
controllerName: alb.networking.azure.io/alb-controller
parentRef:
group: gateway.networking.k8s.io
kind: Gateway
name: gateway-01
namespace: test-infra
Testowanie dostępu do aplikacji
Teraz jesteśmy gotowi wysłać ruch do naszej przykładowej aplikacji za pośrednictwem FQDN przypisanego do frontend. Użyj następującego polecenia, aby uzyskać pełną nazwę domeny (FQDN).
fqdn=$(kubectl get gateway gateway-01 -n test-infra -o jsonpath='{.status.addresses[0].value}')
Jeśli określisz wskaźnik nazwy serwera przy użyciu polecenia curl, contoso.com dla nazwy FQDN frontonu zwraca odpowiedź z usługi backend-v1.
fqdnIp=$(dig +short $fqdn)
curl -k --resolve contoso.com:80:$fqdnIp http://contoso.com
W odpowiedzi powinniśmy zobaczyć:
{
"path": "/",
"host": "contoso.com",
"method": "GET",
"proto": "HTTP/1.1",
"headers": {
"Accept": [
"*/*"
],
"User-Agent": [
"curl/7.81.0"
],
"X-Forwarded-For": [
"xxx.xxx.xxx.xxx"
],
"X-Forwarded-Proto": [
"http"
],
"X-Request-Id": [
"dcd4bcad-ea43-4fb6-948e-a906380dcd6d"
]
},
"namespace": "test-infra",
"ingress": "",
"service": "",
"pod": "backend-v1-5b8fd96959-f59mm"
}
Jeśli określisz wskazanie nazwy serwera przy użyciu polecenia curl dla nazwy FQDN frontend, zwraca ono odpowiedź z usługi backend-v1.
fqdnIp=$(dig +short $fqdn)
curl -k --resolve fabrikam.com:80:$fqdnIp http://fabrikam.com
W odpowiedzi powinniśmy zobaczyć:
{
"path": "/",
"host": "fabrikam.com",
"method": "GET",
"proto": "HTTP/1.1",
"headers": {
"Accept": [
"*/*"
],
"User-Agent": [
"curl/7.81.0"
],
"X-Forwarded-For": [
"xxx.xxx.xxx.xxx"
],
"X-Forwarded-Proto": [
"http"
],
"X-Request-Id": [
"adae8cc1-8030-4d95-9e05-237dd4e3941b"
]
},
"namespace": "test-infra",
"ingress": "",
"service": "",
"pod": "backend-v2-594bd59865-ppv9w"
}
Gratulacje, zainstalowano kontroler ALB, wdrożono aplikację zaplecza i skierowano ruch do dwóch różnych usług zaplecza przy użyciu różnych nazw hostów za pomocą interfejsu API bramy na Application Gateway for Containers.