Adnotacje dla kontrolera ruchu przychodzącego usługi Application Gateway
Zasób ruchu przychodzącego Kubernetes może być dodawać adnotacje do dowolnych par klucz/wartość. Program AGIC opiera się na adnotacjach do programowania funkcji usługi Application Gateway, które nie można konfigurować przy użyciu kodu YAML ruchu przychodzącego. Adnotacje ruchu przychodzącego są stosowane do wszystkich ustawień protokołu HTTP, pul zaplecza i odbiorników pochodzących z zasobu ruchu przychodzącego.
Lista obsługiwanych adnotacji
Aby zasób ruchu przychodzącego był obserwowany przez AGIC, musi być oznaczony adnotacją kubernetes.io/ingress.class: azure/application-gateway. Dopiero wtedy AGIC współpracuje z danym zasobem Ruchu przychodzącego.
Prefiks ścieżki zaplecza
Poniższa adnotacja umożliwia przepisanie ścieżki zaplecza określonej w zasobie ruchu przychodzącego z prefiksem określonym w tej adnotacji. Umożliwia użytkownikom uwidacznienie usług, których punkty końcowe są inne niż nazwy punktów końcowych używanych do uwidaczniania usługi w zasobie ruchu przychodzącego.
Użycie
appgw.ingress.kubernetes.io/backend-path-prefix: <path prefix>
Przykład
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-bkprefix
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/backend-path-prefix: "/test/"
spec:
rules:
- http:
paths:
- path: /hello/
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 80
W poprzednim przykładzie zdefiniowano zasób ruchu przychodzącego o nazwie go-server-ingress-bkprefix z adnotacją appgw.ingress.kubernetes.io/backend-path-prefix: "/test/". Adnotacja informuje bramę aplikacji o utworzeniu ustawienia HTTP, które ma zastępowanie prefiksu ścieżki dla ścieżki /hello do /test/.
Uwaga
W powyższym przykładzie zdefiniowano tylko jedną regułę. Jednak adnotacje mają zastosowanie do całego zasobu ruchu przychodzącego, więc jeśli użytkownik zdefiniował wiele reguł, prefiks ścieżki zaplecza zostanie skonfigurowany dla każdej z określonych ścieżek. Jeśli użytkownik chce różnych reguł z różnymi prefiksami ścieżki (nawet dla tej samej usługi), musi zdefiniować różne zasoby ruchu przychodzącego.
Nazwa hosta zaplecza
Ta adnotacja umożliwia określenie nazwy hosta, której usługa Application Gateway powinna używać podczas rozmowy z zasobnikami.
Użycie
appgw.ingress.kubernetes.io/backend-hostname: "internal.example.com"
Przykład
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-timeout
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/backend-hostname: "internal.example.com"
spec:
rules:
- http:
paths:
- path: /hello/
backend:
service:
name: store-service
port:
number: 80
pathType: Exact
Niestandardowa sonda kondycji
Usługę Application Gateway można skonfigurować do wysyłania niestandardowych sond kondycji do puli adresów zaplecza. Gdy te adnotacje są obecne, kontroler ruchu przychodzącego Kubernetes tworzy niestandardową sondę do monitorowania aplikacji zaplecza i stosuje zmiany do bramy aplikacji.
health-probe-hostname: Ta adnotacja umożliwia niestandardową nazwę hosta w sondze kondycji.
health-probe-port: Ta adnotacja konfiguruje niestandardowy port sondy kondycji.
health-probe-path: Ta adnotacja definiuje ścieżkę dla sondy kondycji.
health-probe-status-code: Ta adnotacja umożliwia sondie kondycji akceptowanie różnych kodów stanu HTTP.
health-probe-interval: Ta adnotacja definiuje interwał uruchamiany przez sondę kondycji.
health-probe-timeout: Ta adnotacja definiuje czas oczekiwania sondy kondycji na odpowiedź przed niepowodzeniem sondy.
health-probe-unhealthy-threshold: Ta adnotacja określa, ile sond kondycji musi zakończyć się niepowodzeniem, aby zaplecze było oznaczone jako w złej kondycji.
Użycie
appgw.ingress.kubernetes.io/health-probe-hostname: "contoso.com"
appgw.ingress.kubernetes.io/health-probe-port: 80
appgw.ingress.kubernetes.io/health-probe-path: "/"
appgw.ingress.kubernetes.io/health-probe-status-code: "100-599"
appgw.ingress.kubernetes.io/health-probe-interval: 30
appgw.ingress.kubernetes.io/health-probe-timeout: 30
appgw.ingress.kubernetes.io/health-probe-unhealthy-threshold: 2
Przykład
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/health-probe-hostname: "contoso.com"
appgw.ingress.kubernetes.io/health-probe-port: 81
appgw.ingress.kubernetes.io/health-probe-path: "/probepath"
appgw.ingress.kubernetes.io/health-probe-status-code: "100-599"
appgw.ingress.kubernetes.io/health-probe-interval: 31
appgw.ingress.kubernetes.io/health-probe-timeout: 31
appgw.ingress.kubernetes.io/health-probe-unhealthy-threshold: 2
spec:
rules:
- http:
paths:
- path: /
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 80
Przekierowanie PROTOKOŁU TLS
Usługę Application Gateway można skonfigurować tak, aby automatycznie przekierowywała adresy URL HTTP do swoich odpowiedników HTTPS. Gdy ta adnotacja jest obecna i protokół TLS jest prawidłowo skonfigurowany, kontroler ruchu przychodzącego Kubernetes tworzy regułę routingu z konfiguracją przekierowania i stosuje zmiany w usłudze Application Gateway. Utworzone przekierowanie będzie adresem HTTP 301 Moved Permanently.
Użycie
appgw.ingress.kubernetes.io/ssl-redirect: "true"
Przykład
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-redirect
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/ssl-redirect: "true"
spec:
tls:
- hosts:
- www.contoso.com
secretName: testsecret-tls
rules:
- host: www.contoso.com
http:
paths:
- backend:
service:
name: websocket-repeater
port:
number: 80
Opróżnianie połączenia
connection-draining: Ta adnotacja pozwala określić, czy włączyć opróżnianie połączeń.
connection-draining-timeout: Ta adnotacja umożliwia określenie limitu czasu, po którym usługa Application Gateway kończy żądania do punktu końcowego opróżniania zaplecza.
Użycie
appgw.ingress.kubernetes.io/connection-draining: "true"
appgw.ingress.kubernetes.io/connection-draining-timeout: "60"
Przykład
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-drain
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/connection-draining: "true"
appgw.ingress.kubernetes.io/connection-draining-timeout: "60"
spec:
rules:
- http:
paths:
- path: /hello/
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 80
Koligacja oparta na plikach cookie
Poniższa adnotacja umożliwia określenie, czy włączyć koligację opartą na plikach cookie.
Użycie
appgw.ingress.kubernetes.io/cookie-based-affinity: "true"
Przykład
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-affinity
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/cookie-based-affinity: "true"
spec:
rules:
- http:
paths:
- path: /hello/
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 80
Limit czasu żądania
Poniższa adnotacja umożliwia określenie limitu czasu żądania w sekundach, po którym usługa Application Gateway zakończy się niepowodzeniem żądania, jeśli odpowiedź nie zostanie odebrana.
Użycie
appgw.ingress.kubernetes.io/request-timeout: "20"
Przykład
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-timeout
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/request-timeout: "20"
spec:
rules:
- http:
paths:
- path: /hello/
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 80
Korzystanie z prywatnego adresu IP
Poniższa adnotacja umożliwia określenie, czy uwidocznić ten punkt końcowy w prywatnym adresie IP usługi Application Gateway.
Uwaga
- W przypadku usługi Application Gateway, która nie ma prywatnego adresu IP, ruch przychodzący z usługą
appgw.ingress.kubernetes.io/use-private-ip: "true"jest ignorowany. Jest to odzwierciedlone w dziennikach kontrolera i zdarzeniach ruchu przychodzącego dla tych ruchu przychodzącego zNoPrivateIPostrzeżeniem.
Użycie
appgw.ingress.kubernetes.io/use-private-ip: "true"
Przykład
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-privateip
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/use-private-ip: "true"
spec:
rules:
- http:
paths:
- path: /
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 80
Zastąpij port frontonu
Adnotacja umożliwia skonfigurowanie odbiornika frontonu do używania różnych portów innych niż 80/443 dla protokołu http/https.
Jeśli port znajduje się w autoryzowanym zakresie bramy aplikacji (1 – 64999), ten odbiornik zostanie utworzony na tym określonym porcie. Jeśli nieprawidłowy port lub żaden port nie jest ustawiony w adnotacji, konfiguracja powróci domyślnie 80 lub 443.
Użycie
appgw.ingress.kubernetes.io/override-frontend-port: "port"
Przykład
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-overridefrontendport
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/override-frontend-port: "8080"
spec:
rules:
- http:
paths:
- path: /hello/
backend:
service:
name: store-service
port:
number: 80
pathType: Exact
Uwaga
Żądanie zewnętrzne będzie musiało być kierowane http://somehost:8080 zamiast http://somehost.
Protokół zaplecza
Poniższa adnotacja umożliwia określenie protokołu, którego usługa Application Gateway powinna używać podczas komunikowania się z zasobnikami. Obsługiwane protokoły to http i https.
Uwaga
Certyfikaty z podpisem własnym są obsługiwane w usłudze Application Gateway, ale obecnie program AGIC obsługuje https tylko wtedy, gdy zasobniki korzystają z certyfikatu podpisanego przez dobrze znany urząd certyfikacji.
Nie używaj portu 80 z protokołem HTTPS i portem 443 z protokołem HTTP w zasobnikach.
Użycie
appgw.ingress.kubernetes.io/backend-protocol: "https"
Przykład
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-timeout
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/backend-protocol: "https"
spec:
rules:
- http:
paths:
- path: /
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 443
Rozszerzenie nazwy hosta
Usługę Application Gateway można skonfigurować tak, aby akceptowała wiele nazw hostów. Adnotacja o zakresie nazwy hosta pozwala na to, umożliwiając zdefiniowanie wielu nazw hostów, w tym nazw hostów wieloznacznych. Spowoduje to dołączenie nazw hostów do nazwy FQDN zdefiniowanej w adresie spec.rules.host ruchu przychodzącego na odbiorniku frontonu, tak aby był skonfigurowany jako odbiornik z wieloma lokacjami.
Użycie
appgw.ingress.kubernetes.io/hostname-extension: "hostname1, hostname2"
Przykład
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-multisite
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/hostname-extension: "hostname1, hostname2"
spec:
rules:
- host: contoso.com
http:
paths:
- path: /
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 443
Uwaga
W powyższym przykładzie odbiornik zostanie skonfigurowany do akceptowania ruchu dla nazw hostów "hostname1.contoso.com" i "hostname2.contoso.com"
Zasady zapory aplikacji internetowej dla ścieżki
Ta adnotacja umożliwia dołączenie już utworzonych zasad zapory aplikacji internetowej do ścieżek listy dla hosta w zasobie ruchu przychodzącego Kubernetes, który jest adnotacją.
Użycie
appgw.ingress.kubernetes.io/waf-policy-for-path: "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/SampleRG/providers/Microsoft.Network/applicationGatewayWebApplicationFirewallPolicies/AGICWAFPolcy"
Przykład
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ad-server-ingress
namespace: commerce
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/waf-policy-for-path: "/subscriptions/abcd/resourceGroups/rg/providers/Microsoft.Network/applicationGatewayWebApplicationFirewallPolicies/adserver"
spec:
rules:
- http:
paths:
- path: /ad-server
backend:
service:
name: ad-server
port:
number: 80
pathType: Exact
- path: /auth
backend:
service:
name: auth-server
port:
number: 80
pathType: Exact
Uwaga
Zasady zapory aplikacji internetowej zostaną zastosowane zarówno do adresów URL /ad-server, jak i /auth.
Certyfikat SSL usługi Application Gateway
Certyfikat SSL można skonfigurować do usługi Application Gateway z lokalnego pliku certyfikatu PFX lub odwołania do niewersyjnego identyfikatora wpisu tajnego usługi Azure Key Vault. Gdy adnotacja jest obecna z nazwą certyfikatu i certyfikat jest wstępnie zainstalowany w usłudze Application Gateway, kontroler ruchu przychodzącego Kubernetes utworzy regułę routingu z odbiornikiem HTTPS i zastosuje zmiany do usługi App Gateway. Adnotacja appgw-ssl-certificate może być również używana razem z adnotacją ssl-redirect w przypadku przekierowania SSL.
Aby uzyskać więcej informacji, zapoznaj się z funkcją appgw-ssl-certificate.
Uwaga
Adnotacja "appgw-ssl-certificate" zostanie zignorowana, gdy specyfikacja protokołu TLS jest definiowana w ruchu przychodzącym w tym samym czasie. Jeśli użytkownik chce różnych certyfikatów z różnymi hostami (zakończenie certyfikatu z wieloma protokołami TLS), należy zdefiniować różne zasoby ruchu przychodzącego.
Użycie
appgw.ingress.kubernetes.io/appgw-ssl-certificate: "name-of-appgw-installed-certificate"
Przykład
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-certificate
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/appgw-ssl-certificate: "name-of-appgw-installed-certificate"
spec:
rules:
- host: www.contoso.com
http:
paths:
- backend:
service:
name: websocket-repeater
port:
number: 80
Profil SSL usługi Application Gateway
Użytkownicy mogą skonfigurować profil ssl w usłudze Application Gateway na odbiornik. Gdy adnotacja jest obecna z nazwą profilu i profil jest wstępnie zainstalowany w usłudze Application Gateway, kontroler ruchu przychodzącego Kubernetes utworzy regułę routingu z odbiornikiem HTTPS i zastosuje zmiany w usłudze App Gateway.
Użycie
appgw.ingress.kubernetes.io/appgw-ssl-certificate: "name-of-appgw-installed-certificate"
appgw.ingress.kubernetes.io/appgw-ssl-profile: "SampleSSLProfile"
Przykład
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-certificate
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/appgw-ssl-certificate: "name-of-appgw-installed-certificate"
appgw.ingress.kubernetes.io/appgw-ssl-profile: "SampleSSLProfile"
spec:
rules:
- host: www.contoso.com
http:
paths:
- backend:
service:
name: websocket-repeater
port:
number: 80
Zaufany certyfikat główny usługi Application Gateway
Użytkownicy mogą teraz skonfigurować własne certyfikaty główne do usługi Application Gateway, aby był zaufany za pośrednictwem programu AGIC. Adnotacja appgw-trusted-root-certificate może być używana razem z protokołem zaplecza adnotacji, aby wskazać kompleksowe szyfrowanie ssl, wiele certyfikatów głównych, rozdzielonych przecinkami, na przykład "name-of-my-root-cert1,name-of-my-root-certificate2".
Użycie
appgw.ingress.kubernetes.io/backend-protocol: "https"
appgw.ingress.kubernetes.io/appgw-trusted-root-certificate: "name-of-my-root-cert1"
Przykład
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-certificate
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/backend-protocol: "https"
appgw.ingress.kubernetes.io/appgw-trusted-root-certificate: "name-of-my-root-cert1"
spec:
rules:
- host: www.contoso.com
http:
paths:
- backend:
service:
name: websocket-repeater
port:
number: 80
Ponowne zapisywanie zestawu reguł
Poniższa adnotacja umożliwia przypisanie istniejącej reguły ponownego zapisywania do odpowiedniej reguły routingu żądań.
Użycie
appgw.ingress.kubernetes.io/rewrite-rule-set: <rewrite rule set name>
Przykład
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-bkprefix
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/rewrite-rule-set: add-custom-response-header
spec:
rules:
- http:
paths:
- path: /
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 8080
Ponowne zapisywanie zestawu reguł niestandardowych
Uwaga
Usługa Application Gateway for Containers została wydana, co wprowadza wiele zmian wydajności, odporności i funkcji. Rozważ wykorzystanie usługi Application Gateway dla kontenerów na potrzeby następnego wdrożenia. Reguły ponownego zapisywania adresów URL dla usługi Application Gateway dla kontenerów można znaleźć tutaj dla interfejsu API bramy i tutaj dla interfejsu API ruchu przychodzącego. Reguły ponownego zapisywania nagłówka dla usługi Application Gateway dla kontenerów można znaleźć tutaj dla interfejsu API bramy.
Uwaga
Ta funkcja jest obsługiwana od wersji 1.6.0-rc1. Użyj polecenia appgw.ingress.kubernetes.io/rewrite-rule-set, który umożliwia używanie istniejącej reguły ponownego zapisywania ustawionej w usłudze Application Gateway.
Usługa Application Gateway umożliwia ponowne zapisywanie wybranej zawartości żądań i odpowiedzi. Dzięki tej funkcji można tłumaczyć adresy URL, parametry ciągu zapytania, a także modyfikować nagłówki żądań i odpowiedzi. Umożliwia również dodawanie warunków w celu upewnienia się, że adres URL lub określone nagłówki zostaną przepisane tylko wtedy, gdy zostaną spełnione określone warunki. Te warunki są oparte na informacjach dotyczących żądania i odpowiedzi. Zasób niestandardowy zestawu reguł ponownego zapisywania powoduje przeniesienie tej funkcji do usługi AGIC.
Nagłówki HTTP umożliwiają klientowi i serwerowi przekazywanie dodatkowych informacji z żądaniem lub odpowiedzią. Zapisując te nagłówki ponownie, można wykonać ważne zadania, takie jak dodawanie pól nagłówków związanych z zabezpieczeniami, takich jak HSTS/ X-XSS-Protection, usuwanie pól nagłówka odpowiedzi, które mogą ujawniać poufne informacje i usuwanie informacji o porcie z nagłówków X-Forwarded-For.
Dzięki możliwości ponownego zapisywania adresów URL możesz: - Przepisać nazwę hosta, ścieżkę i ciąg zapytania adresu URL żądania — wybierz ponowne zapisywanie adresu URL wszystkich żądań lub tylko tych żądań, które odpowiadają co najmniej jednemu ustawieniu warunków. Te warunki są oparte na właściwościach żądania i odpowiedzi (nagłówek żądania, nagłówek odpowiedzi i zmienne serwera). — Wybierz kierowanie żądania na podstawie oryginalnego adresu URL lub przepisanego adresu URL
Użycie
appgw.ingress.kubernetes.io/rewrite-rule-set-custom-resource
Przykład
apiVersion: appgw.ingress.azure.io/v1beta1
kind: AzureApplicationGatewayRewrite
metadata:
name: my-rewrite-rule-set-custom-resource
spec:
rewriteRules:
- name: rule1
ruleSequence: 21
conditions:
- ignoreCase: false
negate: false
variable: http_req_Host
pattern: example.com
actions:
requestHeaderConfigurations:
- actionType: set
headerName: incoming-test-header
headerValue: incoming-test-value
responseHeaderConfigurations:
- actionType: set
headerName: outgoing-test-header
headerValue: outgoing-test-value
urlConfiguration:
modifiedPath: "/api/"
modifiedQueryString: "query=test-value"
reroute: false
Priorytet reguły
Ta adnotacja umożliwia kontrolerowi ruchu przychodzącego bramy aplikacji jawne ustawienie priorytetu skojarzonych reguł routingu żądań.
Użycie
appgw.ingress.kubernetes.io/rule-priority:
Przykład
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: go-server-ingress-rulepriority
namespace: test-ag
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/rule-priority: 10
spec:
rules:
- http:
paths:
- path: /
pathType: Exact
backend:
service:
name: go-server-service
port:
number: 8080
W powyższym przykładzie reguła routingu żądań będzie miała ustawiony priorytet 10.