Yn dit artikel wol ik prate oer twa funksjes fan NGINX Ingress relatearre oan it werjaan fan personaliseare flatersiden, lykas de beheiningen dy't deryn besteane en manieren om har om te wurkjen.
1. It feroarjen fan de standert backend
Standert brûkt NGINX Ingress de standert backend, dy't de oerienkommende funksje útfiert. Dit betsjut dat by it oanfreegjen fan in Ingress dy't in host spesifisearret dy't net yn 'e Ingress-boarnen is, wy de folgjende side ûntfange mei in 404-antwurdkoade:
Dochs komme ús kliïnten hieltyd faker mei in fersyk om har pagina te sjen mei in bedriuwslogo en oare foarsjenningen ynstee fan de standert 404. Om dit te dwaan, hat NGINX Ingress redefine default-backend-service. Wy passe de opmaakyngong as argumint troch nei de opsje mei deselde namme namespace/servicename. De haven fan 'e tsjinst moat 80 wêze.
Om dit te dwaan, moatte jo jo eigen pod (ynset) en tsjinst meitsje mei jo applikaasje ( fan it ingress-nginx repository), dat sil wurde jûn ynstee fan it standert backend.
Hjir is in lytse yllustraasje:
~$ 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>
Dus alle domeinen dy't net eksplisyt makke binne fia YAML mei kind: Ingress, falle yn standert-backend. Yn 'e boppesteande list waard dit domein sadsdasdas.
2. It behanneljen fan HTTP-flaters yn 'e applikaasje mei de standert backend
In oare situaasje is fersiken dy't einigje yn HTTP-flaters (404, 500, 502 ...) nei in applikaasje dy't sokke situaasjes net ferwurket (de oerienkommende moaie siden wurde net oanmakke). Dit kin ek wêze troch de winsk fan ûntwikkelders om deselde flatersiden yn meardere applikaasjes te tsjinjen.
Om dit gefal oan 'e serverkant te ymplementearjen hawwe wy nedich:
- Folgje de ynstruksjes hjirboppe út 'e paragraaf oer standert backend;
- Foegje in kaai ta oan de nginx-ingress konfiguraasje ConfigMap
custom-http-errors, bygelyks, mei de wearde404,503(komt fansels oerien mei de flater koades dy't dekt troch de nije regel).
It ferwachte resultaat is berikt: as de kliïntapplikaasje rint en in flater ûntfangt mei antwurdkoade 404 of 503, sil it fersyk automatysk wurde omlaat nei de nije standert eftergrûn ...
By it ûntwikkeljen fan in applikaasje foar standert backend en oanpaste-http-flaters, moatte jo lykwols rekken hâlde mei in wichtige funksje:
!!! 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.It feit is dat as in fersyk wurdt omlaat, de kopteksten nuttige ynformaasje sille befetsje mei de foarige antwurdkoade en oanfoljende ynformaasje (har folsleine list is beskikber ).
Dit betsjut dat jo sels moatte soargje foar de juste antwurd koade. út de dokumintaasje hoe't it wurket.
Ferskillende applikaasjes hawwe ferskillende standert backends
Om derfoar te soargjen dat de oplossing net globaal is foar it hiele kluster, mar allinich jildt foar spesifike applikaasjes, moatte jo earst de Ingress-ferzje kontrolearje. As it oerienkomt 0.23 of heger, brûk de eigen Ingress-annotaasjes:
- Wy kinne oerskriuwe
default-backendfoar fan elk fan Ingress ; - Wy kinne oerskriuwe
custom-http-errorsfoar fan elk fan Ingress .
As resultaat sil de Ingress-boarne der sa útsjen:
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: 80Yn dit gefal sille flaters 404 en 502 wurde omlaat nei de tsjinst foar flatersiden mei alle nedige kopteksten.
В eardere ferzjes fan Ingress hie dizze funksje net (). En as jo 2 folslein ferskillende applikaasjes hawwe dy't yn jo kluster rinne en jo wolle in oare standert-backend-tsjinst opjaan en ferwurkjen fan ferskate flaterkoades foar elk fan har, dan moatte jo oplossingen brûke, wêrfan wy twa hawwe.
Ingress <0.23: benaderje ien
Dizze opsje is ienfâldiger. As in applikaasje dy't har siden tsjinnet, hawwe wy gewoane HTML, dy't net wit hoe't jo nei de kopteksten sjogge en de juste antwurdkoades weromjaan. Sa'n applikaasje wurdt útrôle mei Ingress fan 'e url /error-pages, en yn 'e katalogus ws sil de weromjûn HTML wêze.
Yllustraasje yn YAML:
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: 80De tsjinst foar dizze ynset moat fan it ClusterIP-type wêze.
Tagelyk, yn 'e applikaasje wêr't wy de flater sille ferwurkje, foegje wy yn Ingress in server-snippet of konfiguraasje-snippet ta mei de folgjende ynhâld:
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: twadde oanpak
In opsje foar in applikaasje dy't kopteksten ferwurkje kin... En yn 't algemien is dit in krektere manier, liend fan oanpaste-http-flaters. Troch it mei de hân te brûken (kopiearje) kinne jo de globale ynstellingen net feroarje.
De stappen binne as folget. Wy meitsje mei in applikaasje dy't nei de nedige koppen harkje kin en goed reagearje kin. Foegje in server-snippet ta oan de Ingress-applikaasje mei de folgjende ynhâld:
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;
}Sa't jo sjen kinne, foar elke flater dy't wy wolle ferwurkje, moatte wy ús eigen lokaasje meitsje, wêr't alle nedige kopteksten sille wurde ynfoege, lykas yn 'e "native". . Op dizze manier kinne wy ferskate personaliseare flatersiden oanmeitsje, sels foar yndividuele lokaasjes en servers.
PS
Oare út 'e K8s tips & tricks-searje:
- «";
- «";
- «";
- «".
Lês ek op ús blog:
- «";
- «".
Boarne: www.habr.com