Hostowanie wielu witryn za pomocą usługi Application Gateway dla kontenerów — interfejs API bramy
Ten dokument ułatwia skonfigurowanie przykładowej aplikacji korzystającej z zasobów z interfejsu API bramy w celu zademonstrowania hostowania wielu witryn w tym samym zasobie usługi Kubernetes Gateway / frontonu usługi Application Gateway for Containers. Dostępne są następujące kroki:
- Utwórz zasób bramy z jednym odbiornikiem HTTP.
- Utwórz dwa zasoby usługi HTTPRoute , które odwołują się do unikatowej usługi zaplecza.
Tło
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 skonfigurowaliśmy usługę Application Gateway dla zasobów kontenerów i kontroler usługi ALB.
Jeśli użyto strategii wdrażania zarządzanego usługi ALB, upewnij się, że aprowizowanie zasobów kontrolera usługi ALB i usługi Application Gateway for Containers za pośrednictwem zasobu niestandardowego 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.yaml
To polecenie tworzy następujące polecenie w klastrze:
- Przestrzeń nazw o nazwie
test-infra
- Dwie usługi o nazwie
backend-v1
ibackend-v2
wtest-infra
przestrzeni nazw - Dwa wdrożenia o nazwie
backend-v1
ibackend-v2
wtest-infra
przestrzeni nazw
- Przestrzeń nazw o nazwie
Wdrażanie wymaganych zasobów interfejsu API bramy
- 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
Gdy kontroler usługi ALB tworzy bramę Application Gateway dla zasobów kontenerów w usłudze ARM, użyje następującej konwencji nazewnictwa dla zasobu frontonu: fe-8< losowo wygenerowanych znaków>
Jeśli chcesz zmienić nazwę frontonu utworzonego na platformie Azure, rozważ zastosowanie własnej strategii wdrażania.
Po utworzeniu zasobu bramy upewnij się, że stan jest prawidłowy, odbiornik jest zaprogramowany, a adres jest przypisany do bramy.
kubectl get gateway gateway-01 -n test-infra -o yaml
Przykładowe dane wyjściowe pomyślnego utworzenia 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 usługi HTTPRoute dla contoso.com
nazw domen i fabrikam.com
. 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 możemy wysłać jakiś ruch do naszej przykładowej aplikacji za pośrednictwem nazwy FQDN przypisanej do frontonu. Użyj następującego polecenia, aby uzyskać nazwę 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 powinna zostać wyświetlona następująca odpowiedź:
{
"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 wskaźnik nazwy serwera przy użyciu polecenia curl, fabrikam.com
dla nazwy FQDN frontonu zwraca odpowiedź z usługi backend-v1.
fqdnIp=$(dig +short $fqdn)
curl -k --resolve fabrikam.com:80:$fqdnIp http://fabrikam.com
W odpowiedzi powinna zostać wyświetlona następująca odpowiedź:
{
"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 usługi ALB, wdrożono aplikację zaplecza i przekierowano ruch do dwóch różnych usług zaplecza za pośrednictwem różnych nazw hostów za pośrednictwem interfejsu API bramy w usłudze Application Gateway for Containers.