Ресурси за VirtualServer и VirtualServerRoute
Ресурсите VirtualServer и VirtualServerRoute са нова конфигурация за балансиране на натоварването, въведена във версия 1.5 като алтернатива на ресурса Ingress. Ресурсите позволяват случаи на използване, които не се поддържат от ресурса Ingress, като разделяне на трафика и разширено маршрутизиране, базирано на съдържание. Ресурсите се внедряват като персонализирани ресурси.
Този документ е референтната документация за ресурсите. За да видите допълнителни примери за използване на ресурсите за конкретни случаи на употреба, отидете в папката examples-of-custom-resources в нашето хранилище на GitHub.
Ресурсът VirtualServer дефинира конфигурация за балансиране на натоварването за име на домейн, като example.com. По-долу е даден пример за такава конфигурация:
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 :- път: /teaaction:pass: чай- път: /coffeeaction:pass: кафе- път: ~ ^/decaf/.*\\.jpg$action:pass: кафе- път: = /green/teaaction:pass: teaFieldDescriptionTypeRequiredhost Хостът (име на домейн) на сървъра. Трябва да е валиден поддомейн, както е дефиниран в RFC 1123, като my-app или hello.example.com. Домейни със заместващи знаци като *.example.com не са разрешени. Стойността на хоста трябва да е уникална сред всички ресурси на Ingress и VirtualServer. Вижте също Handling Host and Listener Collisions.stringYestlsThe TLS termination configuration.[tls](#virtualservertlsNopoliciesA list of rules.[]policyNoupstreamsA list of upstreams.[]upstreamNoroutesA list of routes.[]routeNoingressClassName Указва кой Ingress контролер трябва да обработва ресурса на VirtualServer.stringNohttp -snippetsЗадава персонализиран фрагмент в http context.stringNoserver-snippetsЗадава персонализиран фрагмент в контекст на сървъра Заменя сървърните фрагменти ConfigMap key.stringNoПолето tls дефинира TLS конфигурация за VirtualServer Например:
secret: cafe-secretredirect:enable: trueFieldDescriptionTypeRequiredsecret Името на тайна с TLS сертификат и ключ. Тайната трябва да принадлежи към същото пространство от имена като VirtualServer. Тайната трябва да е от типа kubernetes.io/tls и да съдържа ключове с имена tls.crt и tls.key, които съдържат сертификата и личния ключ, както е описано тук. Ако тайната не съществува или е невалидна, NGINX ще прекъсне всеки опит за установяване на TLS връзка към хоста на VirtualServer.stringNoredirect Конфигурацията за пренасочване на TLS за VirtualServer.tls.redirectNoПолето за пренасочване конфигурира TLS пренасочване за виртуален сървър:
enable: truecode: 301basedOn: schemeFieldDescriptionTypeRequiredenableРазрешава TLS пренасочване за VirtualServer. По подразбиране е False.booleanNocodeКодът на състоянието на пренасочване. Позволените стойности са: 301\ , 302\ , 307\ , 308. По подразбиране е 301.intNobasedOnАтрибутът на заявка, която NGINX ще оцени, за да изпрати пренасочване. Позволените стойности са схема (схемата на заявката) или x-forwarded-proto (заглавката X-Forwarded-Proto на заявката). По подразбиране е scheme.stringNoПолето за политика препраща към ресурс за политика чрез неговото име и незадължително пространство от имена. Например:
FieldDescriptionTypeRequiredname Името на политика. Ако правилото не съществува или е невалидно, NGINX ще отговори с отговор за грешка с код на състоянието 500.stringYesnamespaceПространството от имена на правило. Ако не е посочено, се използва пространството от имена на ресурса VirtualServer.stringNoМаршрутът дефинира правила за съпоставяне на клиентски заявки с действия като предаване на заявка към възходящ поток. Например:
път: /teaaction:pass: teaFieldDescriptionTypeRequiredpath Пътят на маршрута. NGINX ще го сравни с URI на заявка. Възможните стойности са: префикс (\ /\ , /path\ ), точно съвпадение (\ =/exact/match\ ), нечувствителен към регистър регулярен израз (\ ~*^/Bar.*\\.jpg\ ) или чувствителен към регистър регулярен израз (\ ~^/foo.*\\.jpg\ ). В случай на префикс (трябва да започва с /\ ) или точно съвпадение (трябва да започва с =\ ), пътят не трябва да включва никакви празни знаци, {\ , } или ;. В случай на съвпадения на регулярни изрази, всички двойни кавички " трябва да бъдат екранирани и съвпадението не може да завършва с неекранирана обратна наклонена черта \. Пътят трябва да е уникален сред пътищата на всички маршрути на VirtualServer. Проверете директивата за местоположение за повече информация .stringYespoliciesСписък с правила. Правилата заменят политиките от същия тип, дефинирани в спецификацията на VirtualServer. Вижте Прилагане на правила за повече подробности.[]policyNoactionДействието по подразбиране, което трябва да се изпълни за заявка.actionNosplitsКонфигурацията за разделяне по подразбиране за разделяне на трафик. Трябва включват най-малко 2 разделяния.[]splitNomatchesПравилата за съвпадение за разширено базирано на съдържанието маршрутизиране. Изисква действието по подразбиране или разделянията. Несъответстващите заявки ще се обработват от действието по подразбиране или разделянията.matchesNorouteИмето на ресурс на VirtualServerRoute, който дефинира този маршрут. Ако VirtualServerRoute принадлежи към пространство от имена, различно от VirtualServer, трябва да включите пространството от имена. Например tea-namespace/tea.stringNoerrorPages Персонализираните отговори за кодове за грешки. NGINX ще използва тези отговори, вместо да връща отговорите за грешка от сървърите нагоре по веригата или отговорите по подразбиране, генерирани от NGINX. Персонализираният отговор може да бъде пренасочване или готов отговор. Например пренасочване към друг URL адрес, ако сървър нагоре по веригата отговори с код на състоянието 404.[]errorPageNolocation-snippets Задава персонализиран фрагмент в контекста на местоположението. Заменя местоположението-фрагменти ConfigMap key.stringNo* – маршрутът трябва да включва точно едно от следните: действие, разделяния или маршрут.
Ресурсът VirtualServerRoute дефинира маршрут за VirtualServer. Може да се състои от една или няколко подмаршрута. VirtualServerRoute е алтернатива на типовете Mergeable Ingress.
В примера по-долу VirtualServer cafe от пространството от имена cafe-ns дефинира маршрут с пътя /coffee, който е допълнително дефиниран в VirtualServerRoute кафе от пространството от имена coffee-ns.
Виртуален сървър:
apiVersion: k8s.nginx.org/v1kind: VirtualServermetadata:name: cafenamespace: cafe-nsspec:host: cafe.example.comupstreams:- name: teaservice: tea-svcport: 80routes:- path: /teaaction: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:- path: /coffee/latteaction:pass: latte- path: /coffee/espressoaction:pass: espressoИмайте предвид, че всеки подмаршрут трябва да има път, който започва със същия префикс (тук /coffee), който е дефиниран в маршрута на виртуалния сървър. Освен това хостът във VirtualServerRoute трябва да е същият като хоста на VirtualServer.
FieldDescriptionTypeRequiredhost Хостът (име на домейн) на сървъра. Трябва да е валиден поддомейн, както е дефиниран в RFC 1123, като my-app или hello.example.com. Домейни със заместващи знаци като *.example.com не са разрешени. Трябва да е същият като хоста на VirtualServer, който препраща към този ресурс.stringYesupstreamsA списък с възходящи потоци.[]upstreamNosubroutesA списък с подмаршрути.[]subrouteNoingressClassName Указва кой Ingress контролер трябва да обработва ресурса VirtualServerRoute. Трябва да е същото като ingressClassName на VirtualServer, който препраща към този ресурс.string_NoПодмаршрутът дефинира правила за съпоставяне на клиентски заявки с действия като предаване на заявка към възходящ поток. Например:
път: /coffeeaction:pass: coffeeFieldDescriptionTypeRequiredpathПътят на подмаршрута. NGINX ще го сравни с URI на заявка. Възможните стойности са: префикс (\ /\ , /path\ ), точно съвпадение (\ =/exact/match\ ), нечувствителен към регистър регулярен израз (\ ~*^/Bar.*\\.jpg\ ) или чувствителен към регистър регулярен израз (\ ~^/foo.*\\.jpg\ ). В случай на префикс, пътят трябва да започва със същия път като пътя на маршрута на VirtualServer, който препраща към този ресурс. В случай на точно или редовно съвпадение, пътят трябва да е същият като пътя на маршрута на VirtualServer, който препраща към този ресурс. В случай на префикс или точно съвпадение, пътят не трябва да включва никакви празни знаци, {\ , } или ;. В случай на съвпадения на регулярни изрази, всички двойни кавички " трябва да бъдат екранирани и съвпадението не може да завършва на неекранирана обратна наклонена черта \. Пътят трябва да е уникален сред пътищата на всички подмаршрути на списъка с правила VirtualServerRoute.stringYespoliciesA. Правилата заменят всички политики, дефинирани в маршрута на VirtualServer, който препраща към този ресурс. Политиките също заменят политиките на същият тип, дефиниран в спецификацията на VirtualServer. Вижте Правила за прилагане за повече подробности.[]policyNoactionДействието по подразбиране, което да се извърши за заявка.actionNosplitsКонфигурацията на разделяне по подразбиране за разделяне на трафика.Трябва да включва поне 2 разделяния.[]splitNomatchesСъвпадащите правила за напреднали базирано на съдържанието маршрутизиране. Изисква действието по подразбиране или разделянията. Несъответстващите заявки ще се обработват от действието по подразбиране или разделянията. matchesNoerrorPages Персонализираните отговори за кодове за грешки. NGINX ще използва тези отговори, вместо да връща отговорите за грешки от сървърите нагоре или отговорите по подразбиране генерирани от NGINX. Персонализираният отговор може да бъде пренасочване или готов отговор. Например пренасочване към друг URL адрес, ако сървър нагоре по веригата отговори с код на състоянието 404.[]errorPageNolocation-snippets Задава персонализиран фрагмент в контекста на местоположението. Заменя фрагментите за местоположение на VirtualServer (ако е зададен) или фрагментите за местоположение ConfigMap key.stringNo* – подмаршрутът трябва да включва точно едно от следните: действие или разделяния.
Нагоре по веригата дефинира дестинация за конфигурацията на маршрутизиране. Например:
име: teaservice: tea-svcsubselector:version: canaryport: 80lb-method: round_robinfail-timeout: 10smax-fails: 1max-conns: 32keepalive: 32connect-timeout: 30sread-timeout: 30ssend-timeout: 30snext-upstream: "грешка timeout non_idempotent "next-upstream-timeout: 5snext-upstream-tries: 10client-max-body-size: 2mtl:enable: trueЗабележка: Протоколът WebSocket се поддържа без допълнителна конфигурация.
FieldDescriptionTypeRequiredname Името на потока нагоре. Трябва да е валиден DNS етикет, както е дефиниран в RFC 1035. Например hello и upstream-123 са валидни. Името трябва да е уникално сред всички нагоре по веригата на resource.stringYesservice Името на услугата. Услугата трябва да принадлежи към същото пространство от имена като ресурса. Ако услугата не съществува, NGINX ще приеме, че услугата има нула крайни точки и ще върне отговор 502 за заявки за това нагоре по веригата. Само за NGINX Plus също се поддържат услуги от тип ExternalName (проверете предпоставките\ ).stringYessubselector Избира подовете в рамките на услугата с помощта на ключове и стойности на етикети. По подразбиране са избрани всички подове на услугата. Забележка: посочените етикети се очаква да присъстват в групите, когато бъдат създадени. Ако етикетите на pod са актуализирани, Ingress Controller няма да види тази промяна, докато не се промени броят на pods. map[string]stringNouse-cluster-ipEnables с помощта на IP на клъстера и порта на услугата вместо поведението по подразбиране за използване на IP и порт на подс. Когато това поле е активирано, полетата, които конфигурират поведението на NGINX, свързано с множество сървъри нагоре по веригата (като lb-method и next-upstream), няма да имат ефект, тъй като Ingress Controller ще конфигурира NGINX само с един сървър нагоре по веригата, който ще съответства на сервизния клъстер IP.booleanNoport Портът на услугата. Ако услугата не дефинира този порт, NGINX ще приеме, че услугата има нула крайни точки и ще върне отговор 502 за заявки за това нагоре. Портът трябва да попада в диапазона 1..65535.uint16Yeslb-method Методът за балансиране на натоварването. За да използвате метода "round-robin", посочете round_robin. По подразбиране е посочено в lb-метода ConfigMap key.stringNofail-timeout Времето, през което трябва да се случи посоченият брой неуспешни опити за комуникация със сървър нагоре по веригата, за да се счита сървърът за недостъпен. Вижте параметъра fail_timeout на директивата на сървъра. По подразбиране е зададено в fail-timeout ConfigMap key.stringNomax-fails Броят неуспешни опити за комуникация със сървър нагоре по веригата, които трябва да се случат в рамките на продължителността, зададена от fail-timeout, за да се счита сървърът за недостъпен. Вижте параметъра max_fails на директивата на сървъра. По подразбиране е зададено в max-fails ConfigMap key.intNomax-connsМаксималният брой едновременни активни връзки към сървър нагоре по веригата. Вижте параметъра max_conns на директивата на сървъра. По подразбиране няма ограничение. Забележка: ако са активирани поддържащи активност връзки, общият брой активни и неактивни поддържащи активност връзки към сървър нагоре по веригата може да надвиши стойността max_conns.intNokeepalive Конфигурира кеша за връзки към сървъри нагоре по веригата. Стойността 0 деактивира кеша. Вижте директивата за поддържане на активността. По подразбиране е зададено в keyalive ConfigMap key.intNoconnect-timeout Времето за изчакване за установяване на връзка със сървър нагоре по веригата. Вижте директивата proxy_connect_timeout. Стойността по подразбиране е посочена в proxy-connect-timeout ConfigMap key.stringNoread-timeoutThe timeout за четене на отговор от сървър нагоре по веригата. Вижте директивата proxy_read_timeout. По подразбиране е посочено в proxy-read-timeout ConfigMap key.stringNosend-timeout Времето за изчакване за предаване на заявка към сървър нагоре по веригата. Вижте директивата proxy_send_timeout. По подразбиране е посочено в прокси-изпращане-време за изчакване ConfigMap key.stringNonext-upstream Указва в кои случаи заявката трябва да бъде предадена на следващия сървър нагоре по веригата. Вижте директивата proxy_next_upstream. По подразбиране е error timeout.stringNonext-upstream-timeout Времето, през което дадена заявка може да бъде предадена на следващия сървър нагоре по веригата. Вижте директивата proxy_next_upstream_timeout. Стойността 0 изключва времевото ограничение. По подразбиране е 0.stringNonext-upstream-tries Броят възможни опити за предаване на заявка към следващия сървър нагоре по веригата. Вижте директивата proxy_next_upstream_tries. Стойността 0 изключва това ограничение. По подразбиране е 0.intNoclient-max-body-sizeЗадава максималния разрешен размер на тялото на клиентската заявка. Вижте директивата client_max_body_size. По подразбиране е зададено в client-max-body-size ConfigMap key.stringNotlsThe TLS конфигурация за Upstream.tlsNohealthCheckThe конфигурация за проверка на здравето за Upstream. Вижте директивата за проверка на здравето. Забележка: тази функция се поддържа само в NGINX Plus.healthcheckNoslow-start Бавното стартиране позволява на сървър нагоре по веригата постепенно да възстанови теглото си от 0 до номиналната си стойност, след като е възстановен или стане достъпен или когато сървърът стане достъпен след определен период от време беше счетено за недостъпно. По подразбиране бавният старт е деактивиран. Вижте параметъра slow_start на директивата на сървъра. Забележка: Параметърът не може да се използва заедно с методите за балансиране на натоварването random\ , hash или ip_hash и ще бъде игнориран.stringNoqueueКонфигурира опашка за възходящ поток.Клиентска заявка ще бъде поставена в опашката, ако сървър нагоре по веригата не може да бъде избран незабавно, докато се обработва заявката. По подразбиране не е конфигурирана опашка. Забележка: тази функция се поддържа само в NGINX Plus.queueNobufferingАктивира буфериране на отговорите от сървъра нагоре. Вижте директивата proxy_buffering. По подразбиране е зададено в ключа ConfigMap за буфериране на прокси. booleanNobuffersКонфигурира буферите, използвани за четене на отговор от сървъра нагоре по веригата за една връзка.buffersNobuffer-sizeЗадава размера на буфера, използван за четене на първата част от отговор, получен от нагоре по веригата сървър. Вижте директивата proxy_buffer_size. Стойността по подразбиране е зададена в размера на прокси-буфера ConfigMap key.stringNoВижте директивата proxy_buffers за допълнителна информация.
FieldDescriptionTypeRequirednumber Конфигурира броя на буферите. По подразбиране е зададено в прокси-буферите ConfigMap key.intYessize Конфигурира размера на буфера. По подразбиране е зададено в прокси-буферите ConfigMap key.stringYesПолето за опашка конфигурира опашка. Клиентска заявка ще бъде поставена в опашката, ако сървър нагоре по веригата не може да бъде избран незабавно, докато се обработва заявката:
Вижте директивата за опашка за допълнителна информация.
Забележка: Тази функция се поддържа само в NGINX Plus.
FieldDescriptionTypeRequiredsizeРазмерът на опашката.intYestimeoutВремето на изчакване на опашката. Заявката не може да бъде поставена на опашка за период, по-дълъг от изчакването. По подразбиране е 60s.stringNoHealthcheck дефинира активна проверка на здравето. В примера по-долу активираме проверка на здравето за upstream и конфигурираме всички налични параметри:
име: teaservice: tea-svcport: 80healthCheck:enable: truepath: /healthzinterval: 20sjitter: 3sfails: 5passes: 5port: 8080tls:enable: trueconnect-timeout: 10sread-timeout: 10send-timeout: 10sheaders:- name: Hostvalue: my. servicesstatusMatch: "! 500"Забележка: Тази функция се поддържа само в NGINX Plus.
FieldDescriptionTypeRequiredenableАктивира проверка на здравето за сървър нагоре по веригата. По подразбиране е false.booleanNopathПътят, използван за заявки за проверка на състоянието. По подразбиране е /.stringNointerval Интервалът между две последователни проверки на здравето. По подразбиране е 5s.stringNojitter Времето, в рамките на което всяка проверка на здравето ще бъде произволно забавена. По подразбиране няма delay.stringNofails Броят последователни неуспешни проверки на изправността на конкретен сървър нагоре по веригата, след които този сървър ще се счита за нездравословен. По подразбиране е 1.integerNopasses Броят последователно преминали проверки на здравето на конкретен сървър нагоре по веригата, след което сървърът ще се счита за здрав. По подразбиране е 1.integerNoport Портът, използван за заявки за проверка на състоянието. По подразбиране се използва портът на upstream. Забележка: за разлика от порта на upstream, този порт не е сервизен порт, а порт на pod.integerNotls TLS конфигурацията, използвана за заявки за проверка на състоянието. По подразбиране се използва полето tls на upstream.upstream.tlsNoconnect-timeout Времето за изчакване за установяване на връзка със сървър нагоре. По подразбиране се използва времето за изчакване на връзката на възходящия поток.stringNoread-timeout Времето за изчакване за четене на отговор от сървър нагоре по веригата. По подразбиране се използва времето за изчакване за четене на възходящия поток.stringNosend-timeout Времето за изчакване за предаване на заявка към сървър нагоре по веригата. По подразбиране се използва времето за изчакване на изпращане на възходящия поток.stringNoheadersЗаглавките на заявките, използвани за заявки за проверка на състоянието. NGINX Plus винаги задава заглавките Host\, User-Agent и Connection за заявки за проверка на изправността.[]headerNostatusMatchКодовете за състояние на очаквания отговор на проверка на изправността. По подразбиране отговорът трябва да има код на състояние 2xx или 3xx. Примери: "200"\ , "! 500"\ , "301-303 307". Вижте документацията на match directive.stringNoПолето SessionCookie конфигурира постоянството на сесията, което позволява заявките от един и същ клиент да бъдат предавани към същия сървър нагоре по веригата. Информацията за определения сървър нагоре по веригата се предава в бисквитка за сесия, генерирана от NGINX Plus.
В примера по-долу ние конфигурираме постоянството на сесията със сесийна бисквитка за upstream и конфигурираме всички налични параметри:
име: teaservice: tea-svcport: 80sessionCookie:enable: truename: srv_idpath: /expires: 1hdomain: .example.comhttpOnly: falsesecure: trueВижте директивата sticky за допълнителна информация. Сесийната бисквитка съответства на метода на лепкава бисквитка.
Забележка: Тази функция се поддържа само в NGINX Plus.
FieldDescriptionTypeRequiredenableАктивира постоянство на сесия със сесийна бисквитка за сървър нагоре по веригата. По подразбиране е false.booleanNonameИмето на бисквитката.stringYespathПътят, за който е зададена бисквитката.stringNoexpiresВремето, за което браузърът трябва да пази бисквитката. Може да се настрои на специалната стойност max\ , което ще доведе до изтичане на бисквитката на 31 декември 2037 г. 23:55:55 GMT.stringNodomain Домейнът, за който е зададена бисквитката.stringNohttpOnlyДобавя атрибута HttpOnly към бисквитката.booleanNosecureДобавя атрибута Secure към cookie.booleanNoЗаглавката дефинира HTTP заглавка:
име: Hostvalue: example.comFieldDescriptionTypeRequirednameИмето на header.stringYesvalueСтойността на header.stringNoДействието дефинира действие, което да се извърши за заявка.
В примера по-долу клиентските заявки се предават на кафе нагоре:
path: /coffee action:pass: coffeeFieldDescriptionTypeRequiredpass Подава заявки към upstream. Възходящият поток с това име трябва да бъде дефиниран в resource.stringNoredirectПренасочва заявки към предоставен URL.action.redirectNoreturnВръща предварително конфигуриран response.action.returnNoproxyПредава заявки към възходящ поток с възможност за промяна на заявката/отговора (например пренаписване на URI или модифицирайте заглавките).action.proxyNo* – действието трябва да включва точно едно от следните: пропуск, пренасочване, връщане или прокси.
Действието за пренасочване дефинира пренасочване за връщане за заявка.
В примера по-долу клиентските заявки се предават на URL адрес http://www.nginx.com:
redirect:url: http://www.nginx.comcode: 301FieldDescriptionTypeRequiredurlURL адресът, към който да пренасочите заявката. Поддържани NGINX променливи: $scheme\, $http_x_forwarded_proto\, $request_uri\, $host. Променливите трябва да бъдат затворени във фигурни скоби. Например: ${host}${request_uri}.stringYescodeКодът на състоянието на пренасочване. Позволените стойности са: 301\ , 302\ , 307\ , 308. По подразбиране е 301.intNoДействието за връщане дефинира предварително конфигуриран отговор за заявка.
В примера по-долу NGINX ще отговори с предварително конфигуриран отговор за всяка заявка:
return:code: 200type: text/plainbody: "Hello World\n"FieldDescriptionTypeRequiredcodeКодът на състоянието на отговора. Допустимите стойности са: 2XX, 4XX или 5XX. По подразбиране е 200.intNotype MIME типът на отговора. По подразбиране е text/plain.stringNobodyТялото на отговора. Поддържа NGINX променливи*. Променливите трябва да бъдат затворени във къдрави скоби. Например: Заявката е ${request_uri}\n.stringYes* – Поддържани 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, $connections_writing и $connections_waiting.
Прокси действието предава заявки към възходящ поток с възможност за промяна на заявката/отговора (например пренаписване на URI или промяна на заглавките).
В примера по-долу URI адресът на заявката е пренаписан в /, а заглавките на заявката и отговора са променени:
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:- Изтича- Set-Cookiepass:- ServerrewritePath: /FieldDescriptionTypeRequiredupstream Името на възходящия поток, към който ще бъдат изпратени заявките. Възходящият поток с това име трябва да бъде дефиниран в resource.stringYesrequestHeadersЗаглавките на заявката modifications.action.Proxy.RequestHeadersNoresponseHeadersЗаглавките на отговора modifications.action.Proxy.ResponseHeadersNorewritePathПренаписания URI. Ако пътят на маршрута е регулярен израз (започва с ~), rewritePath може да включва групи за улавяне с $1-9. Например $1 за първата група и т.н. За повече информация проверете rewrite example.stringNoПолето RequestHeaders променя заглавките на заявката към прокси сървъра нагоре.
FieldDescriptionTypeRequiredpassПредава оригиналните заглавки на заявката към прокси сървъра нагоре. Вижте директивата proxy_pass_request_header за повече информация. По подразбиране е true.boolNoset Позволява предефиниране или добавяне на полета за представяне на заглавки на заявки, предадени на прокси сървърите нагоре. Вижте директивата proxy_set_header за повече информация.[]headerNoЗаглавката дефинира HTTP заглавка:
name: My-Headervalue: My-ValueВъзможно е да замените стойността по подразбиране на заглавката на хоста, която Ingress Controller задава на $host:
име: Hostvalue: example.comFieldDescriptionTypeRequirednameИмето на заглавката.stringYesvalueСтойността на заглавката. Поддържа NGINX променливи*. Променливите трябва да бъдат затворени във къдрави скоби. Например: ${scheme}.stringNo* – Поддържани 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, $connections_writing, $connections_waiting, $ssl_cipher, $ 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, $ssl_client_s_dn, $ssl_client_s_dn_legacy, $s sl_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_ (само за NGINX Plus) и $jwt_header_ (само за NGINX Plus).
Полето ResponseHeaders променя заглавките на отговора до клиента.
FieldDescriptionTypeRequiredhideЗаглавките, които няма да бъдат предадени* в отговора на клиента от прокси сървър нагоре. Вижте директивата proxy_hide_header за повече информация. boolNopass Позволява предаване на полетата на скритите заглавки* към клиента от прокси сървър нагоре. Вижте директивата proxy_pass_header за повече информация.[]stringNoignore Забранява обработката на определени заглавки** към клиента от прокси сървър нагоре. Вижте директивата proxy_ignore_headers за повече информация.[]stringNoaddДобавя заглавки към отговора на клиента.[]addHeaderNo* – Скритите заглавки по подразбиране са: Date, Server, X-Pad и X-Accel-....
** – Следните полета могат да бъдат игнорирани: X-Accel-Redirect, X-Accel-Expires, X-Accel-Limit-Rate, X-Accel-Buffering, X-Accel-Charset, Expires, Cache-Control , Set-Cookie и Vary.
AdHeader дефинира HTTP Header с незадължително винаги поле:
име: My-Headervalue: My-Valuealways: trueFieldDescriptionTypeRequirednameИмето на заглавката.stringYesvalueСтойността на заглавката. Поддържа NGINX променливи*. Променливите трябва да бъдат затворени във къдрави скоби. Например: ${scheme}.stringNoalwaysАко е зададено на true, добавете заглавката независимо от кода на състоянието на отговора**. По подразбиране е невярно. Вижте директивата add_header за повече информация.boolNo* – Поддържани 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, $connections_writing, $connections_waiting, $ssl_cipher, $ 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, $ssl_client_s_dn, $ssl_client_s_dn_legacy, $s sl_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_ (само за NGINX Plus) и $jwt_header_ (само за NGINX Plus).
** – Ако винаги е невярно, заглавката на отговора се добавя само ако кодът на състоянието на отговора е някой от 200, 201, 204, 206, 301, 302, 303, 304, 307 или 308.
Разделянето определя тежест за действие като част от конфигурацията на разделянето.
В примера по-долу NGINX предава 80% от заявките на upstream coffee-v1 и останалите 20% на coffee-v2:
разделя:- тегло: 80action:pass: coffee-v1- тегло: 20action:pass: coffee-v2FieldDescriptionTypeRequiredweight Теглото на действие. Трябва да попада в диапазона 1..99. Сумата от теглата на всички разделяния трябва да бъде равна на 100.intYesactionДействието, което трябва да се извърши за заявка.actionYesСъвпадението дефинира съответствие между условия и действие или разделяния.
В примера по-долу NGINX маршрутизира заявки с пътя /coffee към различни възходящи потоци въз основа на стойността на потребителя на бисквитката:
user=john -> кафе-бъдещ потребител=боб -> coffee-deprecatedАко бисквитката не е зададена или не е равна нито на john, нито на bob, NGINX маршрутизира към coffee-stablepath: /coffeematches:- условия:- бисквитка: потребителска стойност: johnaction:pass: кафе-бъдеще- условия:- бисквитка: потребителска стойност: bobaction:pass: coffee-deprecatedaction:pass: coffee-stableВ следващия пример NGINX маршрутизира заявки въз основа на стойността на вградената променлива $request_method, която представлява HTTP метода на заявка:
всички POST заявки -> coffee-postall не-POST заявки -> coffeepath: /coffeematches:- условия:- променлива: $request_methodvalue: POSTaction:pass: coffee-postaction:pass: coffeeFieldDescriptionTypeRequiredconditionsСписък с условия. Трябва да включва поне 1 условие. Трябва да включва поне 2 разделяния.[]splitNo* – съвпадението трябва да включва точно едно от следните: действие или разделяния.
Условието дефинира условие в съвпадение.
FieldDescriptionTypeRequiredheader Името на заглавка. Трябва да се състои от буквено-цифрови знаци или -.stringNocookieИмето на бисквитката. Трябва да се състои от буквено-цифрови знаци или _.stringNoargument Името на аргумент. Трябва да се състои от буквено-цифрови знаци или _.stringNovariable Името на NGINX променлива. Трябва да започва с $. Вижте списъка с поддържаните променливи под таблицата.stringNovalueСтойността, с която да съответствате на условието. Как да дефинирате стойност е показано под таблицата.stringYes* – условието трябва да включва точно едно от следните: заглавка, бисквитка, аргумент или променлива.
Поддържани NGINX променливи: $args, $http2, $https, $remote_addr, $remote_port, $query_string, $request, $request_body, $request_uri, $request_method, $scheme. Намерете документацията за всяка променлива тук.
Стойността поддържа два вида съвпадение:
Сравнение на низове без значение за малки и главни букви. Например:john – съвпадение без значение за малки и големи букви, което е успешно за низове, като john, John, JOHN.!john – отричане на съвпадението с малки и големи букви за john, което е успешно за низове, като bob, нещо, '' (празен низ ).Съвпадение с регулярен израз. Имайте предвид, че NGINX поддържа регулярни изрази, съвместими с тези, използвани от езика за програмиране Perl (PCRE). Например: ~^yes – чувствителен към малки и главни букви регулярен израз, който съответства на всеки низ, който започва с yes. Например: yes, yes123.!~^yes – отрицание на предишния регулярен израз, който е успешен за низове като YES, Yes123, noyes. (Механизмът за отрицание не е част от синтаксиса на PCRE).~*no$ – нечувствителен към регистър регулярен израз, който съответства на всеки низ, който завършва с no. Например: no, 123no, 123NO.Забележка: стойността не трябва да включва неекранирани двойни кавички (") и не трябва да завършва с неекранирана обратна наклонена черта (\). Например, следните са невалидни стойности: някаква"стойност , някаква стойност\.
ErrorPage дефинира персонализиран отговор за маршрут за случая, когато сървър нагоре по веригата отговори с (или NGINX генерира) код за състояние на грешка. Персонализираният отговор може да бъде пренасочване или готов отговор. Вижте директивата error_page за повече информация.
път: /coffeeerrorPages:- кодове: [502, 503]пренасочване:код: 301url: https://nginx.org- кодове: [404]връщане:код: 200body: "Оригиналният ресурс не е намерен, но успех!"FieldDescriptionTypeRequiredcodesA list от кодове за състояние на грешка.[]intYesredirectДействието за пренасочване за дадените кодове за състояние.errorPage.RedirectNoreturnДействието за готов отговор за дадените кодове за състояние.errorPage.ReturnNo* – страницата за грешка трябва да включва точно едно от следните: връщане или пренасочване.
Пренасочването дефинира пренасочване за страница с грешки.
В примера по-долу NGINX отговаря с пренасочване, когато отговор от сървър нагоре по веригата има код за състояние 404.
кодове: [404]пренасочване:код: 301url: ${scheme}://cafe.example.com/error.htmlFieldDescriptionTypeRequiredcodeКодът на състоянието на пренасочване. Позволените стойности са: 301\ , 302\ , 307\ , 308. По подразбиране е 301.intNourl URL адресът, към който да се пренасочи заявката. Поддържани NGINX променливи: $scheme\ и $http_x_forwarded_proto. Променливите трябва да бъдат затворени във фигурни скоби. Например: ${scheme}.stringYesВръщането дефинира стандартен отговор за страница с грешки.
В примера по-долу NGINX отговаря с готов отговор, когато отговор от сървър нагоре по веригата има 401 или 403 код на състоянието.
кодове: [401, 403]return:code: 200type: application/jsonbody: |{\"msg\": \"Нямате разрешение да направите това\"}headers:- име: x-debug-original- statusesvalue: ${upstream_status}FieldDescriptionTypeRequiredcodeКодът на състоянието на отговора. По подразбиране е кодът на състоянието на оригиналния отговор.intNotypeТипът MIME на отговора. По подразбиране е text/html.stringNobodyТялото на отговора. Поддържана NGINX променлива: $upstream_status \ . Променливите трябва да бъдат затворени във фигурни скоби. Например: ${upstream_status}.stringYesheaders Персонализираните заглавки на response.errorPage.Return.HeaderNoЗаглавката дефинира HTTP заглавка за готов отговор в страница за грешка:
име: x-debug-original-statusesvalue: ${upstream_status}FieldDescriptionTypeRequirednameИмето на заглавката.stringYesvalueСтойността на заглавката. Поддържана NGINX променлива: $upstream_status \ . Променливите трябва да бъдат затворени във фигурни скоби. Например: ${upstream_status}.stringNoМожете да използвате обичайните команди kubectl за работа с ресурси на VirtualServer и VirtualServerRoute, подобно на ресурсите на Ingress.
Например, следната команда създава ресурс на VirtualServer, дефиниран в cafe-virtual-server.yaml с името cafe:
$ kubectl apply -f cafe-virtual-server.yamlvirtualserver.k8s.nginx.org "cafe" createdМожете да получите ресурса, като стартирате:
$ kubectl get virtualserver cafeNAME STATE HOST IPPORTSAGEcafe Valid cafe.example.com 12.13.23.123[80,443] 3mВ kubectl get и подобни команди можете също да използвате краткото име vs вместо virtualserver.
Работата с ресурси на VirtualServerRoute е аналогична. В командите kubectl използвайте virtualserverroute или краткото име vsr.
Фрагментите ви позволяват да вмъкнете необработена конфигурация на NGINX в различни контексти на конфигурацията на NGINX. В примера по-долу използваме фрагменти, за да конфигурираме няколко функции на NGINX във VirtualServer:
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 зона=mylimit burst=20;upstreams:- име: 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Фрагментите са предназначени за използване от напреднали потребители на NGINX, които се нуждаят от повече контрол върху генерираната конфигурация на NGINX.
Въпреки това, поради недостатъците, описани по-долу, фрагментите са деактивирани по подразбиране. За да използвате фрагменти, задайте аргумента на командния ред enable-snippets.
Недостатъци на използването на фрагменти:
Сложност. За да използвате фрагменти, ще трябва да: Разбирате конфигурационните примитиви на NGINX и да приложите правилна конфигурация на NGINX. Разберете как IC генерира конфигурация на NGINX, така че фрагментът да не пречи на другите функции в конфигурацията. Намалена устойчивост. Неправилен фрагмент прави конфигурацията на NGINX невалидна, което ще доведе до неуспешно презареждане. Това ще предотврати всякакви нови актуализации на конфигурацията, включително актуализации за другите ресурси на VirtualServer и VirtualServerRoute, докато фрагментът не бъде коригиран. Последствия за сигурността. Фрагментите дават достъп до конфигурационните примитиви на NGINX и тези примитиви не се валидират от Ingress Controller. Например, фрагмент може да конфигурира NGINX да обслужва TLS сертификатите и ключовете, използвани за TLS терминиране за ресурси на Ingress и VirtualServer.За да помогне за улавяне на грешки при използване на фрагменти, Ingress Controller отчита грешки при презареждане на конфигурацията в регистрационните файлове, както и в полето за събития и състояние на ресурси на VirtualServer и VirtualServerRoute. Освен това редица показатели на Prometheus показват статистиката за неуспешни презареждания – controller_nginx_last_reload_status и controller_nginx_reload_errors_total.
Имайте предвид, че по време на период, когато конфигурацията на NGINX включва невалиден фрагмент, NGINX ще продължи да работи с последната валидна конфигурация.
Налични са два вида проверка за ресурси на VirtualServer и VirtualServerRoute:
Структурно валидиране от kubectl и Kubernetes API сървър. Цялостно валидиране от Ingress Controller. Структурно валидиранеПерсонализираните дефиниции на ресурси за VirtualServer и VirtualServerRoute включват структурна OpenAPI схема, която описва типа на всяко поле от тези ресурси.
Ако се опитате да създадете (или актуализирате) ресурс, който нарушава структурната схема (например използвате стойност на низ за полето на порта на upstream), kubectl и Kubernetes API сървърът ще отхвърли такъв ресурс:
Пример за валидиране на kubectl:$ kubectl apply -f cafe-virtual-server.yamlerror: грешка при валидиране на "cafe-virtual-server.yaml": грешка при валидиране на данни: ValidationError(VirtualServer.spec.upstreams[0].port): невалиден тип за org.nginx.k8s.v1.VirtualServer.spec.upstreams.port: получен "низ", очаквано "цяло число"; ако решите да игнорирате тези грешки, изключете валидирането с --validate=false Пример за валидиране на Kubernetes API сървър:$ kubectl apply -f cafe-virtual-server.yaml --validate=falseThe VirtualServer "cafe" е невалидно: []: Невалидна стойност: map[string]interface {}{ ... }: validation error list:spec.upstreams.port в body трябва да е от тип integer: "string"Ако даден ресурс не е отхвърлен (той не е наруши структурната схема), Ingress Controller ще го потвърди допълнително.
Цялостно валидиранеIngress Controller валидира полетата на ресурсите VirtualServer и VirtualServerRoute. Ако даден ресурс е невалиден, Ingress Controller ще го отхвърли: ресурсът ще продължи да съществува в клъстера, но Ingress Controller ще го игнорира.
Можете да проверите дали Ingress Controller е приложил успешно конфигурацията за VirtualServer. За нашия пример cafe VirtualServer можем да стартираме:
$ kubectl опишете срещу кафене. . .Events:TypeReasonAge FromMessage-------------------------NormalAddedOrUpdated16s nginx-ingress-controllerConfiguration за default/cafe беше добавен или актуализиранЗабележете как разделът за събития включва нормално събитие с причината AddedOrUpdated, което ни информира, че конфигурацията е приложена успешно.
Ако създадете невалиден ресурс, Ingress Controller ще го отхвърли и ще издаде събитие Rejected. Например, ако създадете VirtualServer кафене с две чайове нагоре по веригата с едно и също име, ще получите:
$ kubectl опишете срещу кафене. . .Events:Type ReasonAge FromMessage---- ---------------------WarningRejected12s nginx-ingress-controllerVirtualServer default/cafe е невалиден и беше отхвърлен: spec.upstreams[ 1].name: Дублирана стойност: "tea"Забележете как разделът за събития включва Предупредително събитие с причината за отхвърлено.
Освен това тази информация е достъпна и в полето за състояние на ресурса VirtualServer. Обърнете внимание на секцията Status на VirtualServer:
$ kubectl опишете срещу кафене. . .Status:External Endpoints:Ip:12.13.23.123Ports: [80,443]Съобщение:VirtualServer default/cafe е невалиден и е отхвърлен: spec.upstreams[1].name: Дублирана стойност: "tea"Reason: RejectedState:InvalidIngress Controller валидира ресурсите на VirtualServerRoute по подобен начин.
Забележка: Ако направите съществуващ ресурс невалиден, Ingress Controller ще го отхвърли и ще премахне съответната конфигурация от NGINX.
Можете да персонализирате конфигурацията на NGINX за ресурси на VirtualServer и VirtualServerRoutes с помощта на ConfigMap. Повечето ключове на ConfigMap се поддържат със следните изключения:
proxy-hide-headersproxy-pass-headershstshsts-max-agehsts-include-subdomainshsts-behind-proxyredirect-to-httpsssl-redirectNEXT: DB2® Connect : Отдалечен клиент не успява да се свърже с DB2 ...
![[Решен] Не може да се свърже с MySql сървър на localhost (10061) (Вижте темата) * Форум на общността на Apache OpenOffice](http://website-google-hk.oss-cn-hongkong.aliyuncs.com/drawing/26/2022-3-1/7051.jpeg "[Решен] Не може да се свърже с MySql сървър на localhost (10061) (Вижте темата) * Форум на общността на Apache OpenOffice")
