U ovom članku želim govoriti o dvije karakteristike NGINX Ingress-a koje se odnose na prikazivanje personaliziranih stranica s greškama, kao io ograničenjima koja postoje u njima i načinima da ih se zaobiđe.
1. Promjena zadane pozadine
Podrazumevano, NGINX Ingress koristi podrazumevani backend, koji obavlja odgovarajuću funkciju. To znači da kada zatražite Ingress koji navodi host koji nije u Ingress resursima, primamo sljedeću stranicu sa kodom odgovora 404:
Međutim, sve češće naši klijenti dolaze sa zahtjevom da svoju stranicu pokažu s korporativnim logotipom i drugim sadržajima umjesto standardnog 404. Da bi to uradio, NGINX Ingress ima redefinisati default-backend-service. Unos formata prosljeđujemo kao argument opciji istog imena namespace/servicename. Port usluge bi trebao biti 80.
Da biste to učinili, trebate kreirati vlastiti pod (deployment) i servis sa svojom aplikacijom ( iz ingress-nginx repozitorija), koji će biti dat umesto podrazumevanog pozadina.
Evo male ilustracije:
~$ curl -i -XGET http://sadsdasdas.kube-cloud.my/
HTTP/1.1 404 Not Found
Date: Mon, 11 Mar 2019 05:38:15 GMT
Content-Type: */*
Transfer-Encoding: chunked
Connection: keep-alive
<span>The page you're looking for could not be found.</span>
Dakle, svi domeni koji nisu eksplicitno kreirani putem YAML-a sa kind: Ingress, spadaju u default-backend. U gornjem popisu, ova domena je postala sadsdasdas.
2. Rukovanje HTTP greškama u aplikaciji koristeći zadanu pozadinu
Druga situacija su zahtjevi koji završavaju HTTP greškama (404, 500, 502...) aplikaciji koja ne obrađuje takve situacije (ne generišu se odgovarajuće lijepe stranice). Ovo može biti i zbog želje programera da poslužuju iste stranice o greškama u više aplikacija.
Za implementaciju ovog slučaja na strani servera potrebno nam je:
- Slijedite gorenavedena uputstva iz paragrafa o zadanoj pozadini;
- Dodajte ključ u nginx-ingress konfiguraciju ConfigMap
custom-http-errors, na primjer, sa vrijednošću404,503(očigledno odgovara kodovima grešaka koji su obuhvaćeni novim pravilom).
Očekivani rezultat je postignut: kada je klijentska aplikacija pokrenuta i primi grešku s kodom odgovora 404 ili 503, zahtjev će se automatski preusmjeriti na novu zadanu pozadinu...
Međutim, kada razvijate aplikaciju za zadane pozadinske i prilagođene http-greške, morate uzeti u obzir važnu značajku:
!!! Important The custom backend is expected to return the correct HTTP status code instead of 200. NGINX does not change the response from the custom default backend.Činjenica je da kada se zahtjev preusmjeri, zaglavlja će sadržavati korisne informacije s prethodnim kodom odgovora i dodatne informacije (njihova kompletna lista je dostupna ).
To znači da i sami morate vodite računa o ispravnom kodu odgovora. iz dokumentacije kako to funkcionira.
Različite aplikacije imaju različite zadane pozadine
Kako biste osigurali da rješenje nije globalno za cijeli klaster, već da se odnosi samo na određene aplikacije, prvo morate provjeriti Ingress verziju. Ako se poklapa 0.23 ili više, koristite izvorne Ingress bilješke:
- Možemo nadjačati
default-backenddo svake od njih Ingress's ; - Možemo nadjačati
custom-http-errorsdo svake od njih Ingress's .
Kao rezultat toga, Ingress resurs će izgledati otprilike ovako:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: {{ .Chart.Name }}-app2
annotations:
kubernetes.io/ingress.class: "nginx"
nginx.ingress.kubernetes.io/custom-http-errors: "404,502"
nginx.ingress.kubernetes.io/default-backend: error-pages
spec:
tls:
- hosts:
- app2.example.com
secretName: wildcard-tls
rules:
- host: app2.example.com
http:
paths:
- path: /
backend:
serviceName: {{ .Chart.Name }}-app2
servicePort: 80U tom slučaju, greške 404 i 502 će biti preusmjerene na servis stranica s greškom sa svim potrebnim zaglavljima.
В prethodne verzije Ingress-a nisu imale ovu funkciju (). A ako imate 2 potpuno različite aplikacije koje se pokreću u vašem klasteru i želite da navedete različitu default-backend-uslugu i obradu različitih kodova grešaka za svaku od njih, za to ćete morati koristiti zaobilazna rješenja, od kojih imamo dva.
Ulaz < 0.23: pristup jedan
Ova opcija je jednostavnija. Kao aplikacija koja opslužuje svoje stranice, imamo običan HTML, koji ne zna kako pogledati zaglavlja i vratiti ispravne kodove odgovora. Takva aplikacija se razvija sa Ingressom iz url-a /error-pages, i u katalogu ws će biti vraćeni HTML.
Ilustracija u YAML-u:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: {{ .Chart.Name }}-app2
annotations:
kubernetes.io/ingress.class: "nginx"
ingress.kubernetes.io/server-snippet: |
proxy_intercept_errors on;
error_page 500 501 502 503 504 @error_pages;
location @error_pages {
rewrite ^ /error-pages/other/index.html break;
proxy_pass http://error-pages.prod.svc.cluster.local;
}
spec:
tls:
- hosts:
- app2.example.com
secretName: wildcard-tls
rules:
- host: app2.example.com
http:
paths:
- path: /
backend:
serviceName: {{ .Chart.Name }}-app2
servicePort: 80Usluga za ovu implementaciju mora biti tipa ClusterIP.
Istovremeno, u aplikaciju u kojoj ćemo obraditi grešku, u Ingress dodajemo isječak servera ili isječak konfiguracije sa sljedećim sadržajem:
nginx.ingress.kubernetes.io /server-snippet: |
proxy_intercept_errors on;
error_page 500 501 502 503 504 @error_pages;
location @error_pages {
rewrite ^ /error-pages/ws/index.html break;
proxy_pass http://error-pages.prod.svc.cluster.local;
}Ingress < 0.23: drugi pristup
Opcija za aplikaciju koja može da obrađuje zaglavlja... I generalno, ovo je ispravniji način, pozajmljen od custom-http-grešaka. Ručno korištenje (kopiranje) omogućit će vam da ne mijenjate globalne postavke.
Koraci su sljedeći. Mi stvaramo s aplikacijom koja može slušati potrebne naslove i pravilno odgovoriti. Dodajte isječak servera u aplikaciju Ingress sa sljedećim sadržajem:
nginx.ingress.kubernetes.io /server-snippet: |
proxy_intercept_errors off;
error_page 404 = @custom_404;
error_page 503 = @custom_503;
location @custom_404 {
internal;
proxy_intercept_errors off;
proxy_set_header X-Code 404;
proxy_set_header X-Format $http_accept;
proxy_set_header X-Original-URI $request_uri;
proxy_set_header X-Namespace $namespace;
proxy_set_header X-Ingress-Name $ingress_name;
proxy_set_header X-Service-Name $service_name;
proxy_set_header X-Service-Port $service_port;
proxy_set_header Host $best_http_host;
rewrite ^ /error-pages/ws/index.html break;
proxy_pass http://error-pages.prod.svc.cluster.local;
}
location @custom_503 {
internal;
proxy_intercept_errors off;
proxy_set_header X-Code 503;
proxy_set_header X-Format $http_accept;
proxy_set_header X-Original-URI $request_uri;
proxy_set_header X-Namespace $namespace;
proxy_set_header X-Ingress-Name $ingress_name;
proxy_set_header X-Service-Name $service_name;
proxy_set_header X-Service-Port $service_port;
proxy_set_header Host $best_http_host;
rewrite ^ /error-pages/ws/index.html break;
proxy_pass http://error-pages.prod.svc.cluster.local;
}Kao što vidite, za svaku grešku koju želimo obraditi moramo napraviti vlastitu lokaciju, gdje će biti umetnuta sva potrebna zaglavlja, kao u „nativnom“. . Na ovaj način možemo kreirati različite personalizirane stranice grešaka čak i za pojedinačne lokacije i servere.
PS
Ostali iz serije K8s tips & tricks:
- «»;
- «»;
- «»;
- «".
Pročitajte i na našem blogu:
- «»;
- «".
izvor: www.habr.com