Adnotacje dla kontrolera ruchu przychodzącego usługi Application Gateway
Możesz dodać adnotację do zasobu ruchu przychodzącego Kubernetes z dowolnymi parami klucz/wartość. Kontroler ruchu przychodzącego usługi Application Gateway (AGIC) opiera się na adnotacjach do programowania aplikacja systemu Azure funkcji bramy, które nie można skonfigurować za pośrednictwem 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.
Napiwek
Zobacz również Co to jest usługa Application Gateway dla kontenerów.
Lista obsługiwanych adnotacji
Aby usługa AGIC obserwować zasób ruchu przychodzącego, zasób musi być oznaczony adnotacją kubernetes.io/ingress.class: azure/application-gateway.
Prefiks ścieżki zaplecza
Poniższa adnotacja umożliwia przepisanie ścieżki zaplecza określonej w zasobie ruchu przychodzącego z określonym prefiksem. Służy do uwidaczniania usług, których punkty końcowe różnią się od nazw 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ą o nazwie appgw.ingress.kubernetes.io/backend-path-prefix: "/test/". Adnotacja informuje usługę Application Gateway o utworzeniu ustawienia HTTP, które ma zastępowanie prefiksu ścieżki dla ścieżki /hello do /test/.
W przykładzie zdefiniowano tylko jedną regułę. Adnotacje dotyczą jednak całego zasobu przychodzącego. Dlatego jeśli zdefiniujesz wiele reguł, skonfigurujesz prefiks ścieżki zaplecza dla każdej z określonych ścieżek. Jeśli chcesz użyć różnych reguł z różnymi prefiksami ścieżki (nawet dla tej samej usługi), musisz zdefiniować różne zasoby ruchu przychodzącego.
Nazwa hosta zaplecza
Użyj następującej adnotacji, aby określić nazwę hosta, która powinna być używana przez usługę Application Gateway 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ć tak, aby wysyłała niestandardowe sondy kondycji do puli adresów zaplecza. Gdy są obecne następujące adnotacje, kontroler ruchu przychodzącego Kubernetes tworzy niestandardową sondę do monitorowania aplikacji zaplecza. Następnie kontroler stosuje zmiany w usłudze Application Gateway.
health-probe-hostname: Ta adnotacja umożliwia niestandardową nazwę hosta w sondze kondycji.health-probe-port: Ta adnotacja konfiguruje niestandardowy port dla 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ł uruchamiania sondy 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 ich 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. Następnie kontroler stosuje zmiany do wystąpienia usługi Application Gateway. Utworzone przekierowanie to 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
Jeśli chcesz użyć opróżniania połączeń, użyj następujących adnotacji:
connection-draining: Ta adnotacja określa, czy włączyć opróżnianie połączenia.connection-draining-timeout: Ta adnotacja określa limit 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
Użyj następującej adnotacji, aby 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
Użyj następującej adnotacji, aby określić limit czasu żądania w sekundach. Po przekroczeniu limitu czasu usługa Application Gateway koń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
Użyj następującej adnotacji, aby określić, czy uwidocznić ten punkt końcowy na prywatnym adresie IP usługi Application Gateway.
W przypadku wystąpienia usługi Application Gateway, które nie ma prywatnego adresu IP, ruch przychodzący z usługą appgw.ingress.kubernetes.io/use-private-ip: "true" jest ignorowany. W dziennikach kontrolera i zdarzeniach ruchu przychodzącego dla tych ruchu przychodzącego NoPrivateIP są wyświetlane ostrzeżenie.
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
Użyj następującej adnotacji, aby skonfigurować odbiornik frontonu do używania portów innych niż 80 dla protokołu HTTP i 443 dla protokołu HTTPS.
Jeśli port znajduje się w autoryzowanym zakresie usługi Application Gateway (od 1 do 64999), odbiornik zostanie utworzony na tym określonym porcie. Jeśli ustawisz nieprawidłowy port lub żaden port w adnotacji, konfiguracja używa wartości domyślnej 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
Żądania zewnętrzne muszą być kierowane http://somehost:8080 zamiast http://somehost.
Protokół zaplecza
Użyj poniższej instrukcji, aby określić protokół, który ma być używany przez usługę Application Gateway podczas komunikacji z zasobnikami. Obsługiwane protokoły to HTTP i HTTPS.
Mimo że certyfikaty z podpisem własnym są obsługiwane w usłudze Application Gateway, usługa AGIC obsługuje obecnie protokół HTTPS tylko wtedy, gdy zasobniki używają 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. hostname-extension Użyj adnotacji, aby zdefiniować wiele nazw hostów, w tym nazwy hostów z symbolami wieloznacznymi. Ta akcja dołącza nazwy hostów do nazwy FQDN zdefiniowanej w informacjach przychodzących spec.rules.host na odbiorniku frontonu, więc jest skonfigurowana 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
Powyższy przykład konfiguruje odbiornik tak, aby akceptował ruch dla nazw hostów hostname1.contoso.com i hostname2.contoso.com.
Zasady zapory aplikacji internetowej dla ścieżki
Użyj następującej adnotacji, aby dołączyć istniejące zasady zapory aplikacji internetowej (WAF) do ścieżek listy dla hosta w zasobie ruchu przychodzącego Kubernetes, który jest adnotacjonowany. Zasady zapory aplikacji internetowej są stosowane do adresów /ad-server URL i /auth .
Użycie
appgw.ingress.kubernetes.io/waf-policy-for-path: "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/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
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 tworzy regułę routingu z odbiornikiem HTTPS i stosuje zmiany do wystąpienia usługi Application Gateway. Możesz również użyć appgw-ssl-certificate adnotacji wraz z adnotacją ssl-redirect w przypadku przekierowania SSL.
Uwaga
Adnotacja appgw-ssl-certificate jest ignorowana, gdy specyfikacja protokołu TLS jest definiowana w ruchu przychodzącym w tym samym czasie. Jeśli chcesz użyć różnych certyfikatów z różnymi hostami (zakończenie wielu certyfikatów TLS), musisz 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
Profil SSL można skonfigurować w wystąpieniu usługi 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 tworzy regułę routingu z odbiornikiem HTTPS i stosuje zmiany do wystąpienia usługi Application 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
Teraz możesz skonfigurować własne certyfikaty główne do usługi Application Gateway, aby był zaufany za pośrednictwem programu AGIC. Adnotację appgw-trusted-root-certificate można używać razem z adnotacją backend-protocol , aby wskazać kompleksowe szyfrowanie SSL. Jeśli określisz wiele certyfikatów głównych, oddziel je przecinkiem; na przykład name-of-my-root-cert1,name-of-my-root-cert2.
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ł
Użyj następującej adnotacji, aby przypisać istniejącą regułę 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
Wydanie usługi Application Gateway dla kontenerów wprowadza wiele zmian wydajności, odporności i funkcji. Rozważ użycie 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źć w tym artykule na temat interfejsu API bramy i tego artykułu na temat interfejsu API ruchu przychodzącego. Reguły ponownego zapisywania nagłówka dla usługi Application Gateway dla kontenerów można znaleźć w tym artykule na temat interfejsu API bramy.
Usługa Application Gateway umożliwia ponowne zapisywanie wybranej zawartości żądań i odpowiedzi. Dzięki tej funkcji można tłumaczyć adresy URL, zmieniać parametry ciągu zapytania oraz modyfikować nagłówki żądań i odpowiedzi. Możesz również użyć tej funkcji, aby dodać warunki, aby upewnić się, że adres URL lub określone nagłówki zostaną przepisane tylko wtedy, gdy zostaną spełnione określone warunki. 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łówka powiązanych z zabezpieczeniami (na przykład HSTS lub X-XSS-Protection), usuwanie pól nagłówka odpowiedzi, które mogą ujawniać poufne informacje i usuwanie informacji o porcie z X-Forwarded-For nagłówków.
Dzięki możliwości ponownego zapisywania adresów URL można wykonywać następujące czynności:
- Zapisz ponownie nazwę hosta, ścieżkę i ciąg zapytania adresu URL żądania.
- Wybierz ponowne zapisywanie adresu URL wszystkich żądań lub tylko żądań, które pasują do co najmniej jednego ustawionego 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.
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.
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
Następująca adnotacja umożliwia kontrolerowi ruchu przychodzącego usługi Application Gateway 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 poprzednim przykładzie ustawiono priorytet 10 dla reguły routingu żądań.