මෙම ලිපියෙන්, මට පුද්ගලාරෝපිත දෝෂ පිටු පෙන්වීමට අදාළ NGINX Ingress හි විශේෂාංග දෙකක් මෙන්ම ඒවායේ පවතින සීමාවන් සහ ඒවා වටා වැඩ කිරීමේ ක්රම ගැන කතා කිරීමට අවශ්යය.
1. පෙරනිමි පසුබිම වෙනස් කිරීම
පෙරනිමියෙන්, NGINX Ingress පෙරනිමි පසුපෙළ භාවිතා කරයි, එය අනුරූප කාර්යය ඉටු කරයි. මෙයින් අදහස් කරන්නේ Ingress සම්පත් වල නොමැති ධාරකයක් සඳහන් කරමින් Ingress එකක් ඉල්ලා සිටින විට, අපට 404 ප්රතිචාර කේතයක් සහිත පහත පිටුව ලැබෙනු ඇති බවයි.
කෙසේ වෙතත්, බොහෝ විට අපගේ ගනුදෙනුකරුවන් සම්මත 404 වෙනුවට ආයතනික ලාංඡනයක් සහ වෙනත් පහසුකම් සහිතව ඔවුන්ගේ පිටුව පෙන්වීමට ඉල්ලීමක් සමඟ පැමිණේ. මෙය සිදු කිරීම සඳහා, NGINX Ingress සතුව ඇත default-backend-service
. අපි ආකෘති ප්රවේශය එකම නමේ විකල්පයට තර්කයක් ලෙස ලබා දෙන්නෙමු namespace/servicename
. සේවාවේ වරාය 80 විය යුතුය.
මෙය සිදු කිරීම සඳහා, ඔබ ඔබේ යෙදුම සමඟ ඔබේම පෝඩ් (යෙදීම) සහ සේවාවක් නිර්මාණය කළ යුතුය (
මෙන්න කුඩා නිදර්ශනයක්:
~$ 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
, පෙරනිමි-පසුපසට වැටේ. ඉහත ලැයිස්තුවේ, මෙම වසම බවට පත් විය sadsdasdas
.
2. පෙරනිමි පසුපෙළ භාවිතයෙන් යෙදුමේ HTTP දෝෂ හැසිරවීම
තවත් තත්වයක් වන්නේ එවැනි තත්ත්වයන් සකසන්නේ නැති යෙදුමකට (අනුරූප ලස්සන පිටු ජනනය නොවේ) HTTP දෝෂ (404, 500, 502...) වලින් අවසන් වන ඉල්ලීම් ය. බොහෝ යෙදුම්වල එකම දෝෂ පිටු සේවය කිරීමට සංවර්ධකයන්ගේ ආශාව මෙයට හේතු විය හැක.
මෙම නඩුව සේවාදායක පැත්තේ ක්රියාත්මක කිරීමට අපට අවශ්ය වන්නේ:
- පෙරනිමි පසුපෙළ පිළිබඳ ඡේදයෙන් ඉහත උපදෙස් අනුගමනය කරන්න;
- nginx-ingress configuration 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
සඳහා එකිනෙකා ඇතුල්වීම ගේවිවරණ භාවිතා කරමින් .
එහි ප්රතිඵලයක් වශයෙන්, Ingress සම්පත මේ වගේ දෙයක් පෙනෙනු ඇත:
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 හි පෙර සංස්කරණවල මෙම විශේෂාංගය නොතිබුණි (
ඇතුල්වීම < 0.23: එකකට පිවිසෙන්න
මෙම විකල්පය වඩාත් සරල ය. එහි පිටු සඳහා සේවය කරන යෙදුමක් ලෙස, අපට සාමාන්ය HTML ඇත, එය ශීර්ෂයන් දෙස බලා නිවැරදි ප්රතිචාර කේත ලබා දෙන්නේ කෙසේදැයි නොදනී. එවැනි යෙදුමක් url වෙතින් ඇතුල්වීම සමඟින් පෙරළේ /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
මෙම යෙදවීම සඳහා වන සේවාව ClusterIP වර්ගයේ විය යුතුය.
ඒ අතරම, අපි දෝෂය සකසන යෙදුමේ, Ingress හි අපි පහත අන්තර්ගතය සමඟ සේවාදායක-ස්නිපටයක් හෝ වින්යාස-ස්නිපටයක් එක් කරන්නෙමු:
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-දෝෂ වලින් ණයට ගත් වඩාත් නිවැරදි ක්රමයකි. එය අතින් භාවිතා කිරීම (පිටපත් කිරීම) ගෝලීය සැකසුම් වෙනස් නොකිරීමට ඔබට ඉඩ සලසයි.
පියවර පහත පරිදි වේ. අපි නිර්මාණය කරනවා
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;
}
ඔබට පෙනෙන පරිදි, අපට සැකසීමට අවශ්ය සෑම දෝෂයක් සඳහාම, “ස්වදේශික” එකේ මෙන් අවශ්ය සියලුම ශීර්ෂ ඇතුළත් කරන අපගේම ස්ථානයක් සෑදිය යුතුය.
ප්රාදේශීය සභා
K8s ඉඟි සහ උපක්රම මාලාවෙන් වෙනත්:
- «
පොකුරක් තුළ ක්රියාත්මක වන සම්පත් Helm 2 කළමනාකරණයට මාරු කිරීම »; - «
වෙබ් යෙදුමක නෝඩ් වෙන් කිරීම සහ පැටවීම ගැන »; - «
dev අඩවි වෙත ප්රවේශය »; - «
විශාල දත්ත සමුදායන් සඳහා bootstrap වේගවත් කිරීම ".
අපගේ බ්ලොග් අඩවියේ ද කියවන්න:
- «
Istio සමඟ microservices වෙත ආපසු. 1 කොටස »; - «
[නිදර්ශන] Kubernetes හි ජාලකරණය සඳහා මාර්ගෝපදේශය. 3 කොටස ".
මූලාශ්රය: www.habr.com