Prostředky virtuálního serveru a VirtualServerRoute
Prostředky VirtualServer a VirtualServerRoute jsou novou konfigurací pro vyrovnávání zátěže, která byla představena ve verzi 1.5 jako alternativa k prostředku Ingress. Prostředky umožňují případy použití, které nejsou podporovány prostředkem Ingress, jako je rozdělení provozu a pokročilé směrování založené na obsahu. Zdroje jsou implementovány jako vlastní zdroje.
Tento dokument je referenční dokumentací pro zdroje. Chcete-li zobrazit další příklady použití zdrojů pro konkrétní případy použití, přejděte do složky example-of-custom-resources v našem úložišti GitHub.
Prostředek virtuálního serveru definuje konfiguraci vyrovnávání zátěže pro název domény, jako je example.com. Níže je uveden příklad takové konfigurace:
apiVersion: k8s.nginx.org/v1kind: VirtualServermetadata:name: cafespec:host: cafe.example.comtls:secret: cafe-secretupstreams:- name: teaservice: tea-svcport: 80- name: coffeeservice: coffee-svcport: 80routes :- cesta: /teaaction:pass: tea- path: /coffeeaction:pass: coffee- path: ~ ^/decaf/.*\\.jpg$action:pass: coffee- path: = /green/teaaction:pass: teaFieldDescriptionTypeRequiredhostHostitel (název domény) serveru. Musí to být platná subdoména, jak je definována v RFC 1123, jako je moje-aplikace nebo hello.example.com. Domény se zástupnými znaky jako *.example.com nejsou povoleny. Hodnota hostitele musí být jedinečná mezi všemi prostředky Ingress a VirtualServeru. Viz také Zpracování kolizí hostitele a posluchače.stringYestlsKonfigurace ukončení TLS.[tls](#virtualservertlsNopoliciesA seznam zásad.[]policyNoupstreamsA seznam upstreamů.[]upstreamNoroutesA seznam tras.[]routeNoingressClassNameUdává, který řadič Ingress.stringNohttp zdroj musí zpracovávat. -snippetsNastaví vlastní fragment v kontextu http.stringNoserver-snippetsNastaví vlastní fragment v kontextu serveru. Přepíše server-snippets ConfigMap key.stringNoPole tls definuje konfiguraci TLS pro VirtualServer. Například:
secret: cafe-secretredirect:enable: trueFieldDescriptionTypeRequiredsecretNázev tajného klíče s certifikátem TLS a klíčem. Tajný klíč musí patřit do stejného jmenného prostoru jako virtuální server. Tajný klíč musí být typu kubernetes.io/tls a obsahovat klíče s názvem tls.crt a tls.key, které obsahují certifikát a soukromý klíč, jak je popsáno zde. Pokud tajný klíč neexistuje nebo je neplatný, NGINX přeruší jakýkoli pokus o navázání připojení TLS k hostiteli VirtualServer.stringNoredirectKonfigurace přesměrování TLS pro VirtualServer.tls.redirectNoPole přesměrování konfiguruje TLS přesměrování pro virtuální server:
enable: truecode: 301basedOn: schemeFieldDescriptionTypeRequiredenablePovoluje přesměrování TLS pro virtuální server. Výchozí hodnota je False.booleanNocodeStavový kód přesměrování. Povolené hodnoty jsou: 301\ , 302\ , 307\ , 308. Výchozí hodnota je 301.intNobasedOnThe atribut požadavku, který NGINX vyhodnotí k odeslání přesměrování. Povolené hodnoty jsou schéma (schéma požadavku) nebo x-forwarded-proto (hlavička X-Forwarded-Proto požadavku). Výchozí hodnota je scheme.stringNoPole zásad odkazuje na zdroj zásad podle jeho názvu a volitelného jmenného prostoru. Například:
FieldDescriptionTypeRequirednameNázev zásady. Pokud zásada neexistuje nebo je neplatná, NGINX odpoví chybovou odpovědí se stavovým kódem 500.stringYesnamespaceJmenný prostor zásady. Není-li zadán, použije se jmenný prostor zdroje virtuálního serveru.stringNoTrasa definuje pravidla pro přiřazování požadavků klientů k akcím, jako je předání požadavku uživateli proti proudu. Například:
cesta: /teaaction:pass: teaFieldDescriptionTypeRequiredpathCesta trasy. NGINX jej porovná s URI požadavku. Možné hodnoty jsou: předpona (\ /\ , /cesta\ ), přesná shoda (\ =/přesná/shoda\ ), regulární výraz bez rozlišení velkých a malých písmen (\ ~*^/Bar.*\\.jpg\ ) nebo regulární výraz rozlišující velká a malá písmena (\ ~^/foo.*\\.jpg\ ). V případě předpony (musí začínat /\ ) nebo přesné shody (musí začínat =\ ), cesta nesmí obsahovat žádné mezery, {\ , } nebo ;. V případě shody regulárního výrazu musí být všechny dvojité uvozovky " escapovány a shoda nesmí končit zpětným lomítkem bez speciálního znaku \. Cesta musí být jedinečná mezi cestami všech tras virtuálního serveru. Další informace naleznete v direktivě umístění .stringYespoliciesSeznam zásad. Zásady přepisují zásady stejného typu definovaného ve specifikaci virtuálního serveru. Další podrobnosti naleznete v části Použití zásad.[]policyNoactionVýchozí akce, která se má provést pro požadavek.actionNosplitsVýchozí konfigurace rozdělení pro rozdělení provozu. Musí obsahovat alespoň 2 rozdělení.[]splitNomatchesPravidla shody pro pokročilé směrování založené na obsahu. Vyžaduje výchozí akci nebo rozdělení.Nepřiřazené požadavky budou zpracovány výchozí akcí nebo splits.matchesNorouteNázev zdroje VirtualServerRoute, který definuje tuto cestu. VirtualServerRoute patří do jiného jmenného prostoru než VirtualServer, musíte zahrnout jmenný prostor, například tea-namespace/tea.stringNoerrorPagesVlastní odpovědi na chybové kódy. NGINX použije tyto odpovědi místo vracení chybových odpovědí z upstream serverů nebo výchozích odpovědí generovaných NGINX. Vlastní odpovědí může být přesměrování nebo předpřipravená odpověď. Například přesměrování na jinou adresu URL, pokud nadřazený server odpověděl stavovým kódem 404.[]errorPageNolocation-snippetsNastaví vlastní fragment v kontextu umístění. Přepíše fragmenty umístění ConfigMap key.stringNo* – trasa musí obsahovat přesně jednu z následujících položek: akce, rozdělení nebo trasa.
Prostředek VirtualServerRoute definuje trasu pro VirtualServer. Může se skládat z jedné nebo více podtras. VirtualServerRoute je alternativou k typům Mergeable Ingress.
V níže uvedeném příkladu definuje kavárna VirtualServeru ze jmenného prostoru cafe-ns cestu s cestou /káva, která je dále definována v kávě VirtualServerRoute z jmenného prostoru coffee-ns.
Virtuální server:
apiVersion: k8s.nginx.org/v1kind: VirtualServermetadata:name: cafenamespace: cafe-nsspec:host: cafe.example.comupstreams:- name: teaservice: tea-svcport: 80routes:- path: /teaction:pass: tea- path : /coffeeroute: coffee-ns/coffeeVirtualServerRoute:
apiVersion: k8s.nginx.org/v1kind: VirtualServerRoutemetadata:name: coffeenamespace: coffee-nsspec:host: cafe.example.comupstreams:- name: latteservice: latte-svcport: 80- name: espressoservice: espresso-svcport:-80subroutes: 80subroutes cesta: /káva/latteaction:pass: latte- cesta: /káva/espressoaction:pass: espressoUpozorňujeme, že každá podcesta musí mít cestu, která začíná stejnou předponou (zde /káva), která je definována v trase virtuálního serveru. Kromě toho musí být hostitel ve VirtualServerRoute stejný jako hostitel virtuálního serveru.
FieldDescriptionTypeRequiredhostHostitel (název domény) serveru. Musí to být platná subdoména, jak je definována v RFC 1123, jako je moje-aplikace nebo hello.example.com. Domény se zástupnými znaky jako *.example.com nejsou povoleny. Musí být stejný jako hostitel virtuálního serveru, který odkazuje na tento resource.stringYesupstreamsA seznam upstreamů.[]upstreamNosubroutesA seznam podtras.[]subrouteNoingressClassNameUdává, který řadič Ingress musí obsluhovat prostředek VirtualServerRoute. Musí být stejný jako ingressClassName virtuálního serveru, který odkazuje na tento resource.string_NoPodcesta definuje pravidla pro přiřazování klientských požadavků k akcím, jako je předání požadavku upstreamu. Například:
cesta: /coffeeaction:pass: coffeeFieldDescriptionTypeRequiredpathCesta podtrasy. NGINX jej porovná s URI požadavku. Možné hodnoty jsou: předpona (\ /\ , /cesta\ ), přesná shoda (\ =/přesná/shoda\ ), regulární výraz bez rozlišení velkých a malých písmen (\ ~*^/Bar.*\\.jpg\ ) nebo regulární výraz rozlišující velká a malá písmena (\ ~^/foo.*\\.jpg\ ). V případě prefixu musí cesta začínat stejnou cestou jako cesta trasy virtuálního serveru, který odkazuje na tento prostředek. V případě přesné nebo regulární shody musí být cesta stejná jako cesta trasy virtuálního serveru, který odkazuje na tento zdroj. V případě předpony nebo přesné shody cesta nesmí obsahovat žádné mezery, {\ , } nebo ;. V případě shody regulárního výrazu musí být všechny dvojité uvozovky "escapovány a shoda nemůže končit znakem neuvozené zpětné lomítko \. Cesta musí být jedinečná mezi cestami všech podtras seznamu zásad VirtualServerRoute.stringYespoliciesA. Zásady přepíší všechny zásady definované v cestě virtuálního serveru, která odkazuje na tento zdroj. Zásady také přepíší zásady stejný typ definovaný ve specifikaci virtuálního serveru. Další podrobnosti naleznete v části Použití zásad.[]policyNoactionVýchozí akce, která se má provést pro požadavek.actionNosplitsVýchozí konfigurace rozdělení pro rozdělení provozu. Musí obsahovat alespoň 2 rozdělení.[]splitNomatchesPravidla shody pro pokročilé směrování založené na obsahu. Vyžaduje výchozí akci nebo rozdělení. Neodpovídající požadavky budou zpracovány výchozí akcí nebo rozděleními.matchesNoerrorPagesVlastní odpovědi na chybové kódy. NGINX použije tyto odpovědi namísto vracení chybových odpovědí z nadřazených serverů nebo výchozích odpovědí generované NGINX. Vlastní odpovědí může být přesměrování nebo předpřipravená odpověď. Například přesměrování na jinou adresu URL, pokud nadřazený server odpověděl stavovým kódem 404.[]errorPageNolocation-snippetsNastaví vlastní fragment v kontextu umístění. Přepíše fragmenty umístění virtuálního serveru (pokud jsou nastaveny) nebo fragmenty umístění ConfigMap key.stringNo* – podcesta musí obsahovat přesně jedno z následujících: action nebo splits.
Upstream definuje cíl pro konfiguraci směrování. Například:
name: teaservice: tea-svcsubselector:version: canaryport: 80lb-method: round_robinfail-timeout: 10smax-fails: 1max-conns: 32keepalive: 32connect-timeout: 30sread-timeout: 30sread-timeout: 30send-timeout: 30send"timeoutsnextpo "next-upstream-timeout: 5snext-upstream-tries: 10client-max-body-size: 2mtls:enable: truePoznámka: Protokol WebSocket je podporován bez jakékoli další konfigurace.
FieldDescriptionTypeRequirednameNázev upstreamu. Musí to být platný štítek DNS podle definice v RFC 1035. Platné jsou například ahoj a upstream-123. Název musí být jedinečný mezi všemi upstreamy zdroje.stringYesserviceNázev služby. Služba musí patřit do stejného jmenného prostoru jako zdroj. Pokud služba neexistuje, NGINX bude předpokládat, že služba má nulové koncové body, a vrátí odpověď 502 na požadavky na tento upstream. Pouze pro NGINX Plus jsou podporovány také služby typu ExternalName (zkontrolujte předpoklady\ ).stringYessubselectorVybírá pody ve službě pomocí klíčů a hodnot štítků. Ve výchozím nastavení jsou vybrány všechny moduly služby. Poznámka: Očekává se, že specifikované štítky budou přítomny v podech při jejich vytvoření. Pokud jsou štítky podů aktualizovány, Ingress Controller tuto změnu neuvidí, dokud se nezmění počet podů.map[string]stringNouse-cluster-ipEnables pomocí IP klastru a portu služby namísto výchozího chování při použití IP a port modulů. Když je toto pole povoleno, pole, která konfigurují chování NGINX související s více upstream servery (jako lb-method a next-upstream), nebudou mít žádný účinek, protože Ingress Controller nakonfiguruje NGINX pouze s jedním upstream serverem, který bude odpovídat klastru služeb. IP.booleanNoportPort služby. Pokud služba nedefinuje tento port, NGINX bude předpokládat, že služba má nulové koncové body a vrátí odpověď 502 pro požadavky na tento upstream. Port musí spadat do rozsahu 1..65535.uint16Yeslb-methodMetoda vyvažování zátěže. Chcete-li použít metodu round-robin, zadejte round_robin. Výchozí hodnota je určena v metodě lb ConfigMap key.stringNofail-timeoutČas, během kterého by se měl stát zadaný počet neúspěšných pokusů o komunikaci s nadřazeným serverem, aby byl server považován za nedostupný. Viz parametr fail_timeout direktivy serveru. Výchozí hodnota je nastavena v klíči ConfigMap při selhání.stringNomax-failsPočet neúspěšných pokusů o komunikaci s nadřazeným serverem, ke kterým by mělo dojít v době trvání nastavené časovým limitem selhání, aby byl server považován za nedostupný. Viz parametr max_fails direktivy serveru. Výchozí hodnota je nastavena v klíči ConfigMap max-fails.intNomax-connsMaximální počet současně aktivních připojení k nadřazenému serveru. Viz parametr max_conns direktivy serveru. Ve výchozím nastavení neexistuje žádný limit. Poznámka: Pokud jsou povolena udržovací připojení, celkový počet aktivních a nečinných udržovacích připojení k nadřazenému serveru může překročit hodnotu max_conns.intNokeepaliveKonfiguruje mezipaměť pro připojení k nadřazeným serverům. Hodnota 0 zakáže mezipaměť. Viz směrnice o udržení. Výchozí hodnota je nastavena v klíči Keepalive ConfigMap.intNoconnect-timeoutČasový limit pro navázání spojení s nadřazeným serverem. Viz direktiva proxy_connect_timeout. Výchozí hodnota je určena v parametru proxy-connect-timeout ConfigMap key.stringNoread-timeoutČasový limit pro čtení odpovědi z nadřazeného serveru. Viz direktiva proxy_read_timeout. Výchozí hodnota je určena v klíči ConfigMap proxy-read-timeout.stringNosend-timeoutThe timeout pro přenos požadavku na upstream server. Viz direktiva proxy_send_timeout. Výchozí hodnota je uvedena v klíči ConfigMap proxy-send-timeout.stringNonext-upstreamUdává, ve kterých případech by měl být požadavek předán dalšímu upstream serveru. Viz direktiva proxy_next_upstream. Výchozí hodnota je error timeout.stringNonext-upstream-timeoutČas, během kterého může být požadavek předán dalšímu upstream serveru. Viz direktiva proxy_next_upstream_timeout. Hodnota 0 vypne časový limit. Výchozí hodnota je 0.stringNonext-upstream-triesPočet možných pokusů o předání požadavku dalšímu upstream serveru. Viz direktiva proxy_next_upstream_tries. Hodnota 0 tento limit vypne. Výchozí hodnota je 0.intNoclient-max-body-sizeNastavuje maximální povolenou velikost těla požadavku klienta. Viz direktiva client_max_body_size. Výchozí hodnota je nastavena v konfiguraci client-max-body-size ConfigMap key.stringNotlsThe konfigurace TLS pro Upstream.tlsNohealthCheckKonfigurace kontroly stavu pro Upstream. Viz direktiva health_check. Poznámka: Tato funkce je podporována pouze v NGINX Plus.healthcheckNoslow-startPomalý start umožňuje upstream serveru postupně obnovit svou váhu z 0 na nominální hodnotu poté, co byla obnovena nebo zpřístupněna nebo když bude server dostupný po určité době bylo považováno za nedostupné. Ve výchozím nastavení je pomalý start zakázán. Viz parametr slow_start direktivy serveru. Poznámka: Parametr nelze použít společně s metodami vyvažování zátěže random\ , hash nebo ip_hash a bude ignorován.stringNoqueueKonfiguruje frontu pro upstream.Požadavek klienta bude umístěn do fronty, pokud nelze okamžitě vybrat upstream server během zpracování požadavku. Ve výchozím nastavení není nakonfigurována žádná fronta. Poznámka: Tato funkce je podporována pouze v NGINX Plus.queueNobufferingUmožňuje ukládání odpovědí z upstream serveru do vyrovnávací paměti. Viz direktiva proxy_buffering. Výchozí nastavení je nastaveno v klíči ConfigMap pro ukládání do vyrovnávací paměti proxy.booleanNobuffersKonfiguruje vyrovnávací paměti používané pro čtení odpovědi z nadřazeného serveru pro jedno připojení.buffersNobuffer-sizeNastavuje velikost vyrovnávací paměti použité pro čtení první části odpovědi přijaté od nadřazeného serveru server. Viz direktiva proxy_buffer_size. Výchozí hodnota je nastavena v konfiguračním souboru pro proxy-buffer-size key.stringNoDalší informace naleznete v direktivě proxy_buffers.
FieldDescriptionTypeRequirednumberKonfiguruje počet vyrovnávacích pamětí. Výchozí nastavení je nastaveno v proxy-bufferech ConfigMap key.intYessizeConfigures velikost bufferu. Výchozí nastavení je nastaveno v proxy-bufferech ConfigMap key.stringYesPole fronty konfiguruje frontu. Požadavek klienta bude umístěn do fronty, pokud nelze okamžitě vybrat upstream server během zpracování požadavku:
Další informace naleznete v direktivě pro fronty.
Poznámka: Tato funkce je podporována pouze v NGINX Plus.
FieldDescriptionTypeRequiredsizeVelikost fronty.intYestimeoutČasový limit fronty. Požadavek nemůže být zařazen do fronty po dobu delší, než je časový limit. Výchozí hodnota je 60s.stringNoKontrola stavu definuje aktivní kontrolu stavu. V níže uvedeném příkladu povolíme kontrolu stavu pro upstream a nakonfigurujeme všechny dostupné parametry:
name: teaservice: tea-svcport: 80healthCheck:enable: truepath: /healthzinterval: 20sjitter: 3sfails: 5passes: 5port: 8080tls:enable: trueconnect-timeout: 10sread-timeout: 10sread-timeout: 10hostheadsheaders: 10 name: servicestatusMatch: "! 500"Poznámka: Tato funkce je podporována pouze v NGINX Plus.
FieldDescriptionTypeRequiredenablePovoluje kontrolu stavu nadřazeného serveru. Výchozí hodnota je false.booleanNopathCesta používaná pro požadavky na kontrolu stavu. Výchozí hodnota je /.stringNointervalInterval mezi dvěma po sobě jdoucími kontrolami stavu. Výchozí hodnota je 5s.stringNojitterČas, během kterého bude každá kontrola stavu náhodně zpožděna. Ve výchozím nastavení neexistuje delay.stringNofailsPočet po sobě jdoucích neúspěšných kontrol stavu konkrétního upstream serveru, po kterých bude tento server považován za nezdravý. Výchozí hodnota je 1.integerNopassesPočet po sobě jdoucích úspěšných kontrol stavu konkrétního upstream serveru, po kterých bude server považován za zdravý. Výchozí hodnota je 1.integerNoportPort používaný pro požadavky na kontrolu stavu. Ve výchozím nastavení se používá port pro upstream. Poznámka: Na rozdíl od portu upstreamu tento port není port služby, ale port pod.integerNotlsThe konfigurace TLS používaná pro požadavky na kontrolu stavu. Standardně se používá pole tls upstreamu.upstream.tlsNoconnect-timeoutČasový limit pro navázání spojení s upstream serverem. Ve výchozím nastavení se používá časový limit připojení pro upstream.stringNoread-timeoutČasový limit pro čtení odpovědi z upstream serveru. Ve výchozím nastavení se používá časový limit pro čtení upstreamu.stringNosend-timeoutČasový limit pro přenos požadavku na upstream server. Ve výchozím nastavení se používá časový limit odeslání upstreamu.stringNoheadersZáhlaví požadavku používané pro požadavky na kontrolu stavu. NGINX Plus vždy nastavuje hlavičky Host\ , User-Agent a Connection pro požadavky na kontrolu stavu.[]headerNostatusMatchOčekávané kódy stavu odezvy na kontrolu stavu. Ve výchozím nastavení by odpověď měla mít stavový kód 2xx nebo 3xx. Příklady: "200"\, "! 500"\, "301-303 307". Viz dokumentace direktivy match.stringNoPole SessionCookie konfiguruje persistenci relace, která umožňuje předávání požadavků od stejného klienta stejnému upstream serveru. Informace o určeném upstream serveru jsou předávány v souboru cookie relace generovaném NGINX Plus.
V níže uvedeném příkladu nakonfigurujeme trvalost relace pomocí souboru cookie relace pro upstream a nakonfigurujeme všechny dostupné parametry:
name: teaservice: tea-svcport: 80sessionCookie:enable: truename: srv_idpath: /expires: 1hdomain: .example.comhttpOnly: falsesecure: trueDalší informace naleznete v direktivě sticky. Soubor cookie relace odpovídá metodě sticky cookie.
Poznámka: Tato funkce je podporována pouze v NGINX Plus.
FieldDescriptionTypeRequiredenablePovoluje uchování relace pomocí souboru cookie relace pro upstream server. Výchozí hodnota je false.booleanNonameNázev souboru cookie.stringYespathCesta, pro kterou je soubor cookie nastaven.stringNoexpiresDoba, po kterou má prohlížeč uchovávat soubor cookie. Lze nastavit na speciální hodnotu max\ , která způsobí, že platnost souboru cookie vyprší 31. prosince 2037 23:55:55 GMT.stringNodomainDoména, pro kterou je soubor cookie nastaven.stringNohttpOnlyPřidá atribut HttpOnly do souboru cookie.booleanNosecurePřidá atribut Secure do the cookie.booleanNoZáhlaví definuje záhlaví HTTP:
name: Hostvalue: example.comFieldDescriptionTypeRequirednameNázev header.stringYesvalueHodnota header.stringNoAkce definuje akci, která se má provést pro požadavek.
V níže uvedeném příkladu jsou požadavky klientů předány do upstream coffee:
cesta: /káva action:pass: coffeeFieldDescriptionTypeRequiredpassPředává požadavky na upstream. Upstream s tímto názvem musí být definován v požadavku resource.stringNoredirectRedirects na zadanou adresu URL.action.redirectNoreturnVrátí předem nakonfigurované požadavky response.action.returnNoproxyPasses upstreamu s možností upravit požadavek/odpověď (například přepsat URI nebo upravit hlavičky).action.proxyNo* – akce musí obsahovat přesně jednu z následujících položek: pass, redirect, return nebo proxy.
Akce přesměrování definuje přesměrování, které se má vrátit na žádost.
V níže uvedeném příkladu jsou požadavky klientů předány na adresu URL http://www.nginx.com:
redirect:url: http://www.nginx.comcode: 301FieldDescriptionTypeRequiredurlAdresa URL, na kterou se má požadavek přesměrovat. Podporované proměnné NGINX: $scheme\ , $http_x_forwarded_proto\ , $request_uri\ , $host. Proměnné musí být uzavřeny ve složených závorkách. Například: ${host}${request_uri}.stringYescodeStavový kód přesměrování. Povolené hodnoty jsou: 301\ , 302\ , 307\ , 308. Výchozí hodnota je 301.intNoAkce návratu definuje předem nakonfigurovanou odpověď na požadavek.
V níže uvedeném příkladu odpoví NGINX na každý požadavek předem nakonfigurovanou odpovědí:
return:code: 200type: text/plainbody: "Hello World\n"FieldDescriptionTypeRequiredcodeStavový kód odpovědi. Povolené hodnoty jsou: 2XX, 4XX nebo 5XX. Výchozí hodnota je 200.intNotypeTyp MIME odpovědi. Výchozí hodnota je text/plain.stringNobodyTělo odpovědi. Podporuje proměnné NGINX*. Proměnné musí být uzavřeny ve složených závorkách. Například: Požadavek je ${request_uri}\n.stringYes* – Podporované proměnné NGINX: $request_uri, $request_method, $request_body, $scheme, $http_, $args, $arg_, $cookie_, $host, $ request_time, $request_length, $nginx_version, $pid, $connection, $remote_addr, $remote_port, $time_iso8601, $time_local, $server_addr, $server_port, $server_name, $server_protocol, $connections_active, $connections_reading a $waitions_reading
Akce proxy předává požadavky upstreamu s možností upravit požadavek/odpověď (například přepsat URI nebo upravit hlavičky).
V níže uvedeném příkladu je identifikátor URI požadavku přepsán na / a záhlaví požadavku a odpovědi jsou upraveny:
proxy:upstream: coffeerequestHeaders:pass: trueset:- name: My-Headervalue: Value- name: Client-Certvalue: ${ssl_client_escaped_cert}responseHeaders:add:- name: My-Headervalue: Value- name: IC-Nginx-Versionvalue: ${nginx_version}always: truehide:- x-internal-versionignore:- Expires- Set-Cookiepass:- ServerrewritePath: /FieldDescriptionTypeRequiredupstreamNázev upstreamu, kterému budou požadavky přesměrovány. Upstream s tímto názvem musí být definován v resource.stringYesrequestHeadersThe hlavičky požadavkumodifikace.action.Proxy.RequestHeadersNoresponseHeadersTheodpovědi hlavičky modifikace.action.Proxy.ResponseHeadersNorewritePathPřepsané URI. Pokud je cesta cesty regulárním výrazem (začíná ~), rewritePath může obsahovat skupiny zachycení s $1-9. Například 1 $ pro první skupinu a tak dále. Další informace naleznete v rewrite example.stringNoPole RequestHeaders upravuje hlavičky požadavku na proxy upstream server.
FieldDescriptionTypeRequiredpass Předá původní hlavičky požadavku na proxy server upstream. Další informace naleznete v direktivě proxy_pass_request_header. Výchozí hodnota je true.boolNosetUmožňuje předefinování nebo připojení polí tak, aby prezentovala záhlaví požadavků předávaných serverům nadřazeným proxy serverem. Další informace naleznete v direktivě proxy_set_header.[]headerNoZáhlaví definuje záhlaví HTTP:
name: My-Headervalue: My-ValueJe možné přepsat výchozí hodnotu hlavičky Host, kterou Ingress Controller nastaví na $host:
name: Hostvalue: example.comFieldDescriptionTypeRequirednameNázev záhlaví.stringYesvalueHodnota záhlaví. Podporuje proměnné NGINX*. Proměnné musí být uzavřeny ve složených závorkách. Například: ${scheme}.stringNo* – Podporované proměnné NGINX: $request_uri, $request_method, $request_body, $scheme, $http_, $args, $arg_, $cookie_, $host, $request_time, $request_length , $nginx_version, $pid, $connection, $remote_addr, $remote_port, $time_iso8601, $time_local, $server_addr, $server_port, $server_name, $server_protocol, $connections_active, $connections_reading, $connectionscipherswriting, $connectionscipherswriting, $ ssl_ciphers, $ssl_client_cert, $ssl_client_escaped_cert, $ssl_client_fingerprint, $ssl_client_i_dn, $ssl_client_i_dn_legacy, $ssl_client_raw_cert, $s_sd_client, $s_sd_client,_acy _client_serial, $ssl_client_v_end, $ssl_client_v_remain, $ssl_client_v_start, $ssl_client_verify, $ssl_curves, $ssl_early_data, $ssl_protocol, $ssl_server_name, $ssl_session_id, $ssl_session_reused, $jwt_claim_ (pouze NGINX Plus) a $jwt_header_ (pouze NGINX Plus).
Pole ResponseHeaders upravuje záhlaví odpovědi klientovi.
FieldDescriptionTypeRequiredhideZáhlaví, která nebudou předána* v odpovědi klientovi z upstream serveru proxy. Další informace naleznete v direktivě proxy_hide_header.boolNopassUmožňuje předání polí skrytých hlaviček* klientovi z upstreamového serveru proxy. Další informace naleznete v direktivě proxy_pass_header.[]stringNoignoreZakazuje zpracování určitých hlaviček** klientovi z upstream serveru proxy. Další informace naleznete v direktivě proxy_ignore_headers.[]stringNoaddAdds hlavičky do odpovědi klientovi.[]addHeaderNo* – Výchozí skryté hlavičky jsou: Date, Server, X-Pad a X-Accel-....
** – Následující pole lze ignorovat: X-Accel-Redirect, X-Accel-Expires, X-Accel-Limit-Rate, X-Accel-Buffering, X-Accel-Charset, Expires, Cache-Control , Set-Cookie a Vary.
AddHeader definuje záhlaví HTTP s volitelným polem always:
name: My-Headervalue: My-Valuealways: trueFieldDescriptionTypeRequirednameNázev záhlaví.stringYesvalueHodnota záhlaví. Podporuje proměnné NGINX*. Proměnné musí být uzavřeny ve složených závorkách. Například: ${scheme}.stringNoalwaysPokud je nastaveno na hodnotu true, přidejte záhlaví bez ohledu na kód stavu odpovědi**. Výchozí hodnota je false. Další informace naleznete v direktivě add_header.boolNo* – Podporované proměnné NGINX: $request_uri, $request_method, $request_body, $scheme, $http_, $args, $arg_, $cookie_, $host, $request_time, $request_length , $nginx_version, $pid, $connection, $remote_addr, $remote_port, $time_iso8601, $time_local, $server_addr, $server_port, $server_name, $server_protocol, $connections_active, $connections_reading, $connectionscipherswriting, $connectionscipherswriting, $ ssl_ciphers, $ssl_client_cert, $ssl_client_escaped_cert, $ssl_client_fingerprint, $ssl_client_i_dn, $ssl_client_i_dn_legacy, $ssl_client_raw_cert, $s_sd_client, $s_sd_client,_acy _client_serial, $ssl_client_v_end, $ssl_client_v_remain, $ssl_client_v_start, $ssl_client_verify, $ssl_curves, $ssl_early_data, $ssl_protocol, $ssl_server_name, $ssl_session_id, $ssl_session_reused, $jwt_claim_ (pouze NGINX Plus) a $jwt_header_ (pouze NGINX Plus).
** – Je-li vždy nepravda, záhlaví odpovědi se přidá pouze v případě, že kód stavu odpovědi je kterýkoli z 200, 201, 204, 206, 301, 302, 303, 304, 307 nebo 308.
Rozdělení definuje váhu pro akci jako součást konfigurace rozdělení.
V příkladu níže NGINX předá 80 % požadavků upstream coffee-v1 a zbývajících 20 % coffee-v2:
rozdělení:- váha: 80akce:pass: káva-v1- váha: 20akce:pass: káva-v2Popis poleTypPožadovaná váhaHmotnost akce. Musí spadat do rozsahu 1..99. Součet vah všech rozdělení se musí rovnat 100.intYesactionAkce, která se má provést pro požadavek.actionYesShoda definuje shodu mezi podmínkami a akcí nebo rozděleními.
V níže uvedeném příkladu směruje NGINX požadavky s cestou /káva do různých upstreamů na základě hodnoty uživatele cookie:
uživatel=john -> coffee-futureuser=bob -> coffee-deprecatedPokud soubor cookie není nastaven nebo není roven buď john nebo bob, NGINX směruje do coffee-stablepath: /coffeematches:- podmínky:- cookie: uservalue: johnaction:pass: coffee-future- conditions:- cookie: uservalue: bobaction:pass: coffee-deprecatedaction:pass: coffee-stableV dalším příkladu NGINX směruje požadavky na základě hodnoty vestavěné proměnné $request_method, která představuje HTTP metodu požadavku:
všechny požadavky POST -> coffee-postall non-POST požadavky -> coffeepath: /coffeematches:- podmínky:- proměnná: $request_methodvalue: POSTaction:pass: coffee-postaction:pass: coffeeFieldDescriptionTypeRequiredconditionsSeznam podmínek. Musí obsahovat alespoň 1 podmínku.[]conditionYesactionAkce, která se má provést pro požadavek.actionNosplitsThe konfigurace rozdělení pro rozdělení provozu. Musí obsahovat alespoň 2 rozdělení.[]splitNo* – shoda musí obsahovat přesně jednu z následujících položek: akci nebo rozdělení.
Podmínka definuje podmínku ve shodě.
FieldDescriptionTypeRequiredheaderNázev záhlaví. Musí se skládat z alfanumerických znaků nebo -.stringNocookieNázev souboru cookie. Musí se skládat z alfanumerických znaků nebo _.stringNoargumentNázev argumentu. Musí se skládat z alfanumerických znaků nebo _.stringNovariableNázev proměnné NGINX. Musí začínat na $. Podívejte se na seznam podporovaných proměnných pod table.stringNovalueHodnota, se kterou se má podmínka shodovat. Jak definovat hodnotu je uvedeno pod table.stringYes* – podmínka musí obsahovat přesně jednu z následujících položek: hlavičku, cookie, argument nebo proměnnou.
Podporované proměnné NGINX: $args, $http2, $https, $remote_addr, $remote_port, $query_string, $request, $request_body, $request_uri, $request_method, $scheme. Dokumentaci pro každou proměnnou naleznete zde.
Hodnota podporuje dva druhy shody:
Porovnání řetězců bez ohledu na velikost písmen. Například:john – shoda bez rozlišování malých a velkých písmen, která je úspěšná pro řetězce, jako je john, John, JOHN.!john – negace shody s motivem malých a velkých písmen pro jan, která uspěje pro řetězce, jako je bob, cokoliv, '' (prázdný řetězec ).Shoda s regulárním výrazem. Všimněte si, že NGINX podporuje regulární výrazy kompatibilní s těmi, které používá programovací jazyk Perl (PCRE). Například:~^yes – regulární výraz rozlišující velká a malá písmena, který odpovídá libovolnému řetězci začínajícímu ano. Například: yes, yes123.!~^yes – negace předchozího regulárního výrazu, která je úspěšná pro řetězce jako YES, Yes123, noyes. (Mechanismus negace není součástí syntaxe PCRE).~*no$ – regulární výraz nerozlišující malá a velká písmena, který odpovídá libovolnému řetězci, který končí číslem no. Například: ne, 123no, 123NO.Poznámka: Hodnota nesmí obsahovat žádné dvojité uvozovky (") a nesmí končit zpětným lomítkem (\). Například následující hodnoty jsou neplatné: some"value , nějaká hodnota\.
ErrorPage definuje vlastní odpověď pro trasu pro případ, kdy buď nadřazený server odpoví (nebo NGINX vygeneruje) kód stavu chyby. Vlastní odpovědí může být přesměrování nebo předpřipravená odpověď. Další informace naleznete v direktivě error_page.
cesta: /coffeeerrorPages:- kódy: [502, 503]přesměrování:kód: 301url: https://nginx.org- kódy: [404]return:code: 200body: "Původní zdroj nenalezen, ale úspěch!"PolePopisTypeVyžadovanékódySeznam chybových stavových kódů.[]intYesredirectAkce přesměrování pro dané stavové kódy.errorPage.RedirectNoreturnUpravená akce odezvy pro dané stavové kódy.errorPage.ReturnNo* – chybová stránka musí obsahovat přesně jednu z následujících položek: return nebo redirect.
Přesměrování definuje přesměrování pro chybovou stránku.
V níže uvedeném příkladu NGINX odpoví přesměrováním, když má odpověď z upstream serveru stavový kód 404.
kódy: [404]přesměrování:kód: 301url: ${scheme}://cafe.example.com/error.htmlFieldDescriptionTypeRequiredcodeStavový kód přesměrování. Povolené hodnoty jsou: 301\ , 302\ , 307\ , 308. Výchozí hodnota je 301.intNourlThe URL, na kterou se má požadavek přesměrovat. Podporované proměnné NGINX: $scheme\ a $http_x_forwarded_proto. Proměnné musí být uzavřeny ve složených závorkách. Například: ${scheme}.stringYesNávrat definuje předpřipravenou odpověď pro errorPage.
V níže uvedeném příkladu NGINX odpoví předpřipravenou odpovědí, když má odpověď z upstream serveru stavový kód 401 nebo 403.
codes: [401, 403]return:code: 200type: application/jsonbody: |{\"msg\": \"Nemáte oprávnění to udělat\"}headers:- name: x-debug-original- statusesvalue: ${upstream_status}FieldDescriptionTypeRequiredcodeStavový kód odpovědi. Výchozí je stavový kód původní odpovědi.intNotypeTyp MIME odpovědi. Výchozí hodnota je text/html.stringNobodyTělo odpovědi. Podporovaná proměnná NGINX: $upstream_status \ . Proměnné musí být uzavřeny ve složených závorkách. Například: ${upstream_status}.stringYesheadersVlastní hlavičky response.errorPage.Return.HeaderNoZáhlaví definuje HTTP hlavičku pro předpřipravenou odpověď na errorPage:
jméno: x-debug-original-statusesvalue: ${upstream_status}FieldDescriptionTypeRequirednameNázev záhlaví.stringYesvalueHodnota záhlaví. Podporovaná proměnná NGINX: $upstream_status \ . Proměnné musí být uzavřeny ve složených závorkách. Například: ${upstream_status}.stringNoK práci s prostředky VirtualServer a VirtualServerRoute můžete použít obvyklé příkazy kubectl, podobně jako prostředky Ingress.
Například následující příkaz vytvoří prostředek VirtualServer definovaný v cafe-virtual-server.yaml s názvem cafe:
$ kubectl apply -f cafe-virtual-server.yamlvirtualserver.k8s.nginx.org "cafe" vytvořenoProstředek můžete získat spuštěním:
$ kubectl get virtualserver cafeNAME STATE HOST IPPORTSAGEcafe Platné cafe.example.com 12.13.23.123[80,443] 3mV příkazech kubectl get a podobných příkazech můžete místo virtualserver použít také krátký název vs.
Práce s prostředky VirtualServerRoute je analogická. V příkazech kubectl použijte virtualserverroute nebo krátký název vsr.
Úryvky umožňují vkládat nezpracovanou konfiguraci NGINX do různých kontextů konfigurace NGINX. V níže uvedeném příkladu používáme úryvky ke konfiguraci několika funkcí NGINX ve virtuálním serveru:
apiVersion: k8s.nginx.org/v1kind: VirtualServermetadata:name: cafenamespace: cafespec:http-snippets: |limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;proxy_cache_path /tmp keys_zone=one:10m;host: cafe. example.comtls:secret: cafe-secretserver-snippets: |limit_req zone=mylimit burst=20;upstreams:- name: teaservice: tea-svcport: 80- name: coffeeservice: coffee-svcport: 80routes:- path: /tealocation- snippets: |proxy_cache one;proxy_cache_valid 200 10m;action:pass: tea- path: /coffeeaction:pass: coffeeÚryvky jsou určeny pro pokročilé uživatele NGINX, kteří potřebují větší kontrolu nad vygenerovanou konfigurací NGINX.
Vzhledem k níže popsaným nevýhodám jsou úryvky ve výchozím nastavení zakázány. Chcete-li použít úryvky, nastavte argument příkazového řádku enable-snippets.
Nevýhody používání úryvků:
Složitost. Chcete-li používat úryvky, musíte: Porozumět primitivům konfigurace NGINX a implementovat správnou konfiguraci NGINX. Pochopit, jak IC generuje konfiguraci NGINX, aby úryvek nezasahoval do ostatních funkcí v konfiguraci. Snížená robustnost. Nesprávný úryvek způsobí neplatnost konfigurace NGINX, což povede k neúspěšnému opětovnému načtení. To zabrání jakýmkoli novým aktualizacím konfigurace, včetně aktualizací pro ostatní zdroje VirtualServer a VirtualServerRoute, dokud nebude fragment opraven. Důsledky pro zabezpečení. Úryvky umožňují přístup ke konfiguračním primitivům NGINX a tato primitiva nejsou ověřena Ingress Controllerem. Fragment může například nakonfigurovat NGINX tak, aby poskytoval TLS certifikáty a klíče používané pro ukončení TLS pro prostředky Ingress a VirtualServer.Aby pomohl zachytit chyby při používání úryvků, hlásí Ingress Controller chyby opětovného načtení konfigurace v protokolech i v pole událostí a stavu prostředků VirtualServer a VirtualServerRoute. Řada metrik Prometheus navíc zobrazuje statistiky o neúspěšných obnoveních – controller_nginx_last_reload_status a controller_nginx_reload_errors_total.
Všimněte si, že během období, kdy konfigurace NGINX obsahuje neplatný fragment, bude NGINX nadále fungovat s nejnovější platnou konfigurací.
Pro prostředky VirtualServer a VirtualServerRoute jsou k dispozici dva typy ověření:
Strukturální ověření pomocí serveru kubectl a Kubernetes API.Komplexní ověření pomocí Ingress Controller.Structural ValidationVlastní definice prostředků pro VirtualServer a VirtualServerRoute zahrnují strukturální schéma OpenAPI, které popisuje typ každého pole těchto prostředků.
Pokud se pokusíte vytvořit (nebo aktualizovat) prostředek, který porušuje strukturální schéma (například použijete hodnotu řetězce pro pole portu upstreamu), server kubectl a Kubernetes API takový prostředek odmítne:
Příklad ověření kubectl:$ kubectl použít -f cafe-virtual-server.yamlerror: chyba při ověřování "cafe-virtual-server.yaml": chyba při ověřování dat: ValidationError(VirtualServer.spec.upstreams[0].port): neplatný typ pro org.nginx.k8s.v1.VirtualServer.spec.upstreams.port: dostal "řetězec", očekává se "celé číslo"; pokud se rozhodnete tyto chyby ignorovat, vypněte ověření pomocí --validate=falsePříklad ověření serveru Kubernetes API:$ kubectl apply -f cafe-virtual-server.yaml --validate=false "Kavárna" virtuálního serveru je neplatná: []: Neplatná hodnota: map[řetězec]rozhraní {}{ ... }: selhání ověření seznam:spec.upstreams.port v těle musí být typu integer: "string"Pokud zdroj není odmítnut (neodmítne poruší strukturální schéma), Ingress Controller jej dále ověří.
Komplexní ověřeníIngress Controller ověřuje pole prostředků VirtualServer a VirtualServerRoute. Pokud je zdroj neplatný, Ingress Controller jej odmítne: zdroj bude nadále existovat v clusteru, ale Ingress Controller jej bude ignorovat.
Můžete zkontrolovat, zda Ingress Controller úspěšně použil konfiguraci pro virtuální server. Pro naši ukázkovou kavárnu VirtualServer můžeme spustit:
$ kubectl popsat vs kavárna. . .Events:TypeReasonAge FromMessage-------------------------NormalAddedOrUpdated16s nginx-ingress-controllerConfiguration pro výchozí/kavárnu byla přidána nebo aktualizovánaVšimněte si, jak sekce událostí obsahuje Normální událost s důvodem AddedOrUpdated, která nás informuje, že konfigurace byla úspěšně použita.
Pokud vytvoříte neplatný zdroj, Ingress Controller jej odmítne a vydá událost Rejected. Pokud například vytvoříte kavárnu VirtualServer se dvěma upstream se stejným názvem čaje, získáte:
$ kubectl popsat vs kavárna. . .Events:Type ReasonAge FromMessage---- ---------------------WarningRejected12s nginx-ingress-controllerVirtualServer default/cafe je neplatný a byl odmítnut: spec.upstreams[ 1].name: Duplicitní hodnota: "tea"Všimněte si, že sekce událostí obsahuje událost Varování s důvodem Zamítnuto.
Tyto informace jsou navíc dostupné také ve stavovém poli prostředku VirtualServer. Všimněte si sekce Stav virtuálního serveru:
$ kubectl popsat vs kavárna. . .Status:External Endpoints:Ip:12.13.23.123Ports: [80,443]Message:Výchozí nastavení virtuálního serveru/kavárna je neplatná a byla zamítnuta: spec.upstreams[1].name: Duplicitní hodnota: "tea"Důvod: RejectedState:InvalidIngress Controller ověřuje zdroje VirtualServerRoute podobným způsobem.
Poznámka: Pokud označíte existující zdroj za neplatný, Ingress Controller jej odmítne a odstraní odpovídající konfiguraci z NGINX.
Konfiguraci NGINX pro zdroje VirtualServer a VirtualServerRoutes můžete přizpůsobit pomocí ConfigMap. Většina klíčů ConfigMap je podporována s následujícími výjimkami:
proxy-hide-headersproxy-pass-headersshstshsts-max-agehsts-include-subdomainshsts-beind-proxyredirect-to-httpsssl-redirectNEXT: DB2® Connect: Vzdálenému klientovi se nedaří připojit k DB2...
![[Vyřešeno] Nelze se připojit k serveru MySql na localhost (10061) (Zobrazit téma) * Fórum komunity Apache OpenOffice](http://website-google-hk.oss-cn-hongkong.aliyuncs.com/drawing/26/2022-3-1/7051.jpeg "[Vyřešeno] Nelze se připojit k serveru MySql na localhost (10061) (Zobrazit téma) * Fórum komunity Apache OpenOffice")
