په دې مقاله کې، زه غواړم د NGINX Ingress د دوو ځانګړتیاوو په اړه وغږیږم چې د شخصي غلطی پاڼو ښودلو پورې تړاو لري، او همدارنګه هغه محدودیتونه چې په دوی کې شتون لري او د دوی شاوخوا کار کولو لارې.
1. د ډیفالټ پس منظر بدلول
په ډیفالټ ډول، NGINX Ingress د ډیفالټ پس منظر کاروي، کوم چې ورته فعالیت ترسره کوي. دا پدې مانا ده چې کله چې د انګریس غوښتنه کول د کوربه مشخص کولو لپاره چې د Ingress سرچینو کې نه وي، موږ لاندې پاڼه د 404 ځواب کوډ سره ترلاسه کوو:
په هرصورت، ډیری وختونه زموږ پیرودونکي د دې غوښتنې سره راځي چې د معیاري 404 پرځای د کارپوریټ لوگو او نورو اسانتیاو سره خپله پاڼه وښیې. د دې کولو لپاره، NGINX Ingress لري بیا تعریف default-backend-service. موږ د ورته نوم اختیار ته د دلیل په توګه د فارمیټ داخلیدل انتقالوو namespace/servicename. د خدمت پورټ باید 80 وي.
د دې کولو لپاره ، تاسو اړتیا لرئ خپل پوډ (ګمارنه) او د خپل غوښتنلیک سره خدمت رامینځته کړئ ( د ingress-nginx repository څخه)، کوم چې به د ډیفالټ پس منظر پرځای ورکړل شي.
دلته یو کوچنی مثال دی:
~$ 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>
نو ټول هغه ډومینونه چې په واضح ډول د YAML له لارې ندي رامینځته شوي kind: Ingress, default-backend ته ورشئ. په پورته لیست کې، دا ډومین شو sadsdasdas.
2. د ډیفالټ پس منظر په کارولو سره په غوښتنلیک کې د HTTP غلطیو اداره کول
بل حالت د HTTP غلطیو (404, 500, 502 ...) پای ته رسیدو غوښتنې دي چې داسې غوښتنلیک ته اړتیا نلري چې دا ډول حالتونه پروسس نه کوي (د ورته ښکلي پا pagesې نه رامینځته کیږي). دا ممکن د پراختیا کونکو غوښتنې له امله هم وي چې په ډیری غوښتنلیکونو کې ورته غلطی پا pagesې خدمت وکړي.
د سرور اړخ کې د دې قضیې پلي کولو لپاره موږ اړتیا لرو:
- د ډیفالټ پس منظر په اړه د پراګراف څخه پورته لارښوونې تعقیب کړئ؛
- د nginx-ingress ترتیب کولو ConfigMap کې کیلي اضافه کړئ
custom-http-errorsد مثال په توګه، د ارزښت سره404,503(په ښکاره ډول د خطا کوډونو سره مطابقت لري چې د نوي قانون لخوا پوښل شوي).
تمه شوې پایله ترلاسه شوې: کله چې د پیرودونکي غوښتنلیک روان وي او د ځواب کوډ 404 یا 503 سره خطا ترلاسه کوي ، نو غوښتنه به په اوتومات ډول نوي ډیفالټ بیک اینډ ته واستول شي ...
په هرصورت، کله چې د ډیفالټ پس منظر او دودیز-http- غلطیو لپاره غوښتنلیک رامینځته کړئ، تاسو اړتیا لرئ یو مهم خصوصیت په پام کې ونیسئ:
!!! 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.حقیقت دا دی چې کله غوښتنه لیږل کیږي، سرلیکونه به د مخکیني ځواب کوډ او اضافي معلوماتو سره ګټور معلومات ولري (د دوی بشپړ لیست شتون لري ).
دا پدې مانا ده چې تاسو باید پخپله د سم ځواب کوډ پاملرنه وکړئ. د اسنادو څخه دا څنګه کار کوي.
مختلف غوښتنلیکونه مختلف ډیفالټ بیکینډونه لري
د دې لپاره چې ډاډ ترلاسه شي چې حل د ټول کلستر لپاره نړیوال ندی، مګر یوازې په ځانګړو غوښتنلیکونو باندې تطبیق کیږي، تاسو لومړی د Ingress نسخه وګورئ. که سره سمون خوري 0.23 یا لوړ, د اصلي انګریس تشریحات وکاروئ:
- موږ کولی شو له منځه یوسو
default-backendلپاره هر یو د ننوتلو ; - موږ کولی شو له منځه یوسو
custom-http-errorsلپاره هر یو د ننوتلو .
د پایلې په توګه، د ننوتلو سرچینه به داسې ښکاري:
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: 80په دې حالت کې، 404 او 502 تېروتنې به د ټولو اړین سرلیکونو سره د تېروتنې پاڼې خدمت ته واستول شي.
В د Ingress پخوانۍ نسخې دا ځانګړتیا نه درلوده (). او که تاسو په خپل کلستر کې 2 په بشپړ ډول مختلف غوښتنلیکونه پرمخ وړئ او تاسو غواړئ د هر یو لپاره د مختلف ډیفالټ بیک انډ-خدمت او د مختلف غلطو کوډونو پروسس کولو مشخص کړئ ، د دې لپاره تاسو باید د حل لارې وکاروئ ، چې موږ یې دوه لرو.
ننوتل <0.23: یو ته نږدې
دا اختیار ډیر ساده دی. د یو غوښتنلیک په توګه چې د هغې پاڼې خدمت کوي، موږ منظم HTML لرو، کوم چې نه پوهیږي چې څنګه سرلیکونه وګوري او د سم ځواب کوډونه بیرته راولي. دا ډول غوښتنلیک د یو آر ایل څخه د انګریس سره پیل شوی /error-pages، او په کتلاګ کې ws بیرته راستنیدونکي HTML به وي.
په 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: 80د دې ګمارنې لپاره خدمت باید د کلستر IP ډول وي.
په ورته وخت کې ، په غوښتنلیک کې چیرې چې موږ به خطا پروسس کړو ، په انګریس کې موږ د لاندې مینځپانګې سره د سرور-snippet یا ترتیب-snippet اضافه کوو:
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;
}ننوتل <0.23: دوهمه طریقه
د غوښتنلیک لپاره یو اختیار چې کولی شي سرلیکونه پروسس کړي ... او په عموم کې دا خورا سمه لاره ده، د دودیز-http- غلطیو څخه پور اخیستل شوی. په لاسي ډول د دې کارول (کاپي کول) به تاسو ته اجازه درکړي چې نړیوال تنظیمات بدل نه کړئ.
ګامونه په لاندې ډول دي. موږ جوړوو د یو غوښتنلیک سره چې کولی شي اړین سرلیکونو ته غوږ ونیسي او سم ځواب ووایی. د لاندې مینځپانګې سره د انګریس غوښتنلیک ته د سرور - snippet اضافه کړئ:
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;
}لکه څنګه چې تاسو لیدلی شئ، د هرې تېروتنې لپاره چې موږ یې پروسس کول غواړو، موږ باید خپل ځای جوړ کړو، چیرې چې ټول اړین سرلیکونه به داخل شي، لکه څنګه چې "اصلي" کې. . پدې توګه موږ کولی شو مختلف شخصي خطا پاڼې رامینځته کړو حتی د انفرادي ځایونو او سرورونو لپاره.
PS
د K8s لارښوونو او چلونو لړۍ څخه نور:
- «»
- «»
- «»
- «".
زموږ په بلاګ کې هم ولولئ:
- «»
- «".
سرچینه: www.habr.com