ਕੁਬਰਨੇਟਸ ਟਿਪਸ ਅਤੇ ਟ੍ਰਿਕਸ: NGINX ਇਨਗਰੇਸ ਵਿੱਚ ਕਸਟਮ ਐਰਰ ਪੇਜ

ਇਸ ਲੇਖ ਵਿੱਚ, ਮੈਂ ਵਿਅਕਤੀਗਤ ਤਰੁਟੀ ਪੰਨਿਆਂ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨ ਨਾਲ ਸੰਬੰਧਿਤ NGINX Ingress ਦੀਆਂ ਦੋ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਬਾਰੇ ਗੱਲ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ, ਨਾਲ ਹੀ ਉਹਨਾਂ ਵਿੱਚ ਮੌਜੂਦ ਸੀਮਾਵਾਂ ਅਤੇ ਉਹਨਾਂ ਦੇ ਆਲੇ ਦੁਆਲੇ ਕੰਮ ਕਰਨ ਦੇ ਤਰੀਕਿਆਂ ਬਾਰੇ.

1. ਡਿਫੌਲਟ ਬੈਕਐਂਡ ਬਦਲਣਾ

ਮੂਲ ਰੂਪ ਵਿੱਚ, NGINX Ingress ਡਿਫੌਲਟ ਬੈਕਐਂਡ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਜੋ ਅਨੁਸਾਰੀ ਫੰਕਸ਼ਨ ਕਰਦਾ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਜਦੋਂ ਇੱਕ ਇੰਗਰੈਸ ਦੀ ਬੇਨਤੀ ਕਰਦੇ ਹੋਏ ਇੱਕ ਮੇਜ਼ਬਾਨ ਨੂੰ ਨਿਸ਼ਚਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜੋ ਇੰਗਰੈਸ ਸਰੋਤਾਂ ਵਿੱਚ ਨਹੀਂ ਹੈ, ਤਾਂ ਸਾਨੂੰ ਇੱਕ 404 ਜਵਾਬ ਕੋਡ ਦੇ ਨਾਲ ਹੇਠਾਂ ਦਿੱਤਾ ਪੰਨਾ ਪ੍ਰਾਪਤ ਹੁੰਦਾ ਹੈ:

ਹਾਲਾਂਕਿ, ਵੱਧ ਤੋਂ ਵੱਧ ਅਕਸਰ ਸਾਡੇ ਗਾਹਕ ਸਟੈਂਡਰਡ 404 ਦੀ ਬਜਾਏ ਇੱਕ ਕਾਰਪੋਰੇਟ ਲੋਗੋ ਅਤੇ ਹੋਰ ਸੁਵਿਧਾਵਾਂ ਦੇ ਨਾਲ ਆਪਣਾ ਪੰਨਾ ਦਿਖਾਉਣ ਦੀ ਬੇਨਤੀ ਦੇ ਨਾਲ ਆਉਂਦੇ ਹਨ। ਅਜਿਹਾ ਕਰਨ ਲਈ, NGINX Ingress ਹੈ ਬਿਲਟ-ਇਨ ਸਮਰੱਥਾ ਮੁੜ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ default-backend-service. ਅਸੀਂ ਉਸੇ ਨਾਮ ਦੇ ਵਿਕਲਪ ਲਈ ਇੱਕ ਦਲੀਲ ਵਜੋਂ ਫਾਰਮੈਟ ਐਂਟਰੀ ਪਾਸ ਕਰਦੇ ਹਾਂ namespace/servicename. ਸੇਵਾ ਦਾ ਪੋਰਟ 80 ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਅਜਿਹਾ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਆਪਣੀ ਅਰਜ਼ੀ (ਤੈਨਾਤੀ) ਅਤੇ ਸੇਵਾ ਨਾਲ ਆਪਣੀ ਖੁਦ ਦੀ ਪੋਡ (ਡਿਪਲਾਇਮੈਂਟ) ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ (YAML ਵਿੱਚ ਉਦਾਹਰਨ ਲਾਗੂ ਕਰਨਾ ingress-nginx ਰਿਪੋਜ਼ਟਰੀ ਤੋਂ), ਜੋ ਕਿ ਡਿਫਾਲਟ ਬੈਕਐਂਡ ਦੀ ਬਜਾਏ ਦਿੱਤਾ ਜਾਵੇਗਾ।

ਇੱਥੇ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਦ੍ਰਿਸ਼ਟਾਂਤ ਹੈ:

~$ 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...) ਵਿੱਚ ਖਤਮ ਹੋਣ ਵਾਲੀਆਂ ਬੇਨਤੀਆਂ ਦੀ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਹੈ ਜੋ ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ 'ਤੇ ਕਾਰਵਾਈ ਨਹੀਂ ਕਰਦੀ ਹੈ (ਅਨੁਸਾਰ ਸੁੰਦਰ ਪੰਨੇ ਨਹੀਂ ਬਣਾਏ ਗਏ ਹਨ)। ਇਹ ਕਈ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਇੱਕੋ ਤਰੁੱਟੀ ਪੰਨਿਆਂ ਦੀ ਸੇਵਾ ਕਰਨ ਲਈ ਡਿਵੈਲਪਰਾਂ ਦੀ ਇੱਛਾ ਦੇ ਕਾਰਨ ਵੀ ਹੋ ਸਕਦਾ ਹੈ।

ਸਰਵਰ ਸਾਈਡ 'ਤੇ ਇਸ ਕੇਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਸਾਨੂੰ ਲੋੜ ਹੈ:

1. ਡਿਫੌਲਟ ਬੈਕਐਂਡ ਬਾਰੇ ਪੈਰੇ ਤੋਂ ਉੱਪਰ ਦਿੱਤੀਆਂ ਹਿਦਾਇਤਾਂ ਦੀ ਪਾਲਣਾ ਕਰੋ;
2. 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.

ਤੱਥ ਇਹ ਹੈ ਕਿ ਜਦੋਂ ਇੱਕ ਬੇਨਤੀ ਰੀਡਾਇਰੈਕਟ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਸਿਰਲੇਖਾਂ ਵਿੱਚ ਪਿਛਲੇ ਜਵਾਬ ਕੋਡ ਅਤੇ ਵਾਧੂ ਜਾਣਕਾਰੀ ਦੇ ਨਾਲ ਉਪਯੋਗੀ ਜਾਣਕਾਰੀ ਹੋਵੇਗੀ (ਉਨ੍ਹਾਂ ਦੀ ਪੂਰੀ ਸੂਚੀ ਉਪਲਬਧ ਹੈ ਇੱਥੇ).

ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਆਪਣੇ ਆਪ ਨੂੰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਸਹੀ ਜਵਾਬ ਕੋਡ ਦਾ ਧਿਆਨ ਰੱਖੋ. ਇੱਥੇ ਇੱਕ ਉਦਾਹਰਨ ਹੈ ਦਸਤਾਵੇਜ਼ਾਂ ਤੋਂ ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ।

ਵੱਖ-ਵੱਖ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਵੱਖ-ਵੱਖ ਡਿਫੌਲਟ ਬੈਕਐਂਡ ਹੁੰਦੇ ਹਨ

ਇਹ ਸੁਨਿਸ਼ਚਿਤ ਕਰਨ ਲਈ ਕਿ ਹੱਲ ਪੂਰੇ ਕਲੱਸਟਰ ਲਈ ਗਲੋਬਲ ਨਹੀਂ ਹੈ, ਪਰ ਸਿਰਫ ਖਾਸ ਐਪਲੀਕੇਸ਼ਨਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਇਨਗਰੇਸ ਸੰਸਕਰਣ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਜੇਕਰ ਇਹ ਮੇਲ ਖਾਂਦਾ ਹੈ 0.23 ਜਾਂ ਵੱਧ, ਨੇਟਿਵ ਇੰਗ੍ਰੇਸ ਐਨੋਟੇਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ:

1. ਅਸੀਂ ਓਵਰਰਾਈਡ ਕਰ ਸਕਦੇ ਹਾਂ default-backend ਨੂੰ ਹਰ ਇਕ ਪ੍ਰਵੇਸ਼ ਦੇ ਐਨੋਟੇਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ;
2. ਅਸੀਂ ਓਵਰਰਾਈਡ ਕਰ ਸਕਦੇ ਹਾਂ 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 ਦੇ ਪਿਛਲੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ ਨਹੀਂ ਸੀ (0.23 'ਤੇ ਕਿਸਮਤ ਵਾਲੀ ਪ੍ਰਤੀਬੱਧਤਾ). ਅਤੇ ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਤੁਹਾਡੇ ਕਲੱਸਟਰ ਵਿੱਚ 2 ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨ ਚੱਲ ਰਹੀਆਂ ਹਨ ਅਤੇ ਤੁਸੀਂ ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਲਈ ਇੱਕ ਵੱਖਰੀ ਡਿਫੌਲਟ-ਬੈਕਐਂਡ-ਸਰਵਿਸ ਅਤੇ ਵੱਖ-ਵੱਖ ਗਲਤੀ ਕੋਡਾਂ ਦੀ ਪ੍ਰੋਸੈਸਿੰਗ ਨਿਰਧਾਰਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਸਦੇ ਲਈ ਤੁਹਾਨੂੰ ਵਰਕਅਰਾਉਂਡਸ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਪਵੇਗੀ, ਜਿਸ ਵਿੱਚੋਂ ਸਾਡੇ ਕੋਲ ਦੋ ਹਨ।

ਪ੍ਰਵੇਸ਼ <0.23: ਇੱਕ ਪਹੁੰਚੋ

ਇਹ ਵਿਕਲਪ ਸਰਲ ਹੈ। ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਰੂਪ ਵਿੱਚ ਜੋ ਇਸਦੇ ਪੰਨਿਆਂ ਦੀ ਸੇਵਾ ਕਰਦਾ ਹੈ, ਸਾਡੇ ਕੋਲ ਨਿਯਮਤ HTML ਹੈ, ਜੋ ਇਹ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਸਿਰਲੇਖਾਂ ਨੂੰ ਕਿਵੇਂ ਵੇਖਣਾ ਹੈ ਅਤੇ ਸਹੀ ਜਵਾਬ ਕੋਡ ਕਿਵੇਂ ਵਾਪਸ ਕਰਨਾ ਹੈ. ਅਜਿਹੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ url ਤੋਂ Ingress ਨਾਲ ਰੋਲ ਆਊਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ /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 ਕਿਸਮ ਦੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

ਉਸੇ ਸਮੇਂ, ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਜਿੱਥੇ ਅਸੀਂ ਗਲਤੀ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਾਂਗੇ, ਇੰਗ੍ਰੇਸ ਵਿੱਚ ਅਸੀਂ ਹੇਠਾਂ ਦਿੱਤੀ ਸਮੱਗਰੀ ਦੇ ਨਾਲ ਇੱਕ ਸਰਵਰ-ਸਨਿਪਟ ਜਾਂ ਕੌਂਫਿਗਰੇਸ਼ਨ-ਸਨਿਪਟ ਜੋੜਦੇ ਹਾਂ:

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;
      }

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ, ਹਰ ਇੱਕ ਗਲਤੀ ਲਈ ਜਿਸਦੀ ਅਸੀਂ ਪ੍ਰਕਿਰਿਆ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਸਾਨੂੰ ਆਪਣਾ ਸਥਾਨ ਬਣਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਜਿੱਥੇ ਸਾਰੇ ਲੋੜੀਂਦੇ ਸਿਰਲੇਖ ਸ਼ਾਮਲ ਕੀਤੇ ਜਾਣਗੇ, ਜਿਵੇਂ ਕਿ "ਮੂਲ" ਵਿੱਚ. ਕਸਟਮ-ਗਲਤੀ-ਪੰਨੇ. ਇਸ ਤਰ੍ਹਾਂ ਅਸੀਂ ਵਿਅਕਤੀਗਤ ਸਥਾਨਾਂ ਅਤੇ ਸਰਵਰਾਂ ਲਈ ਵੀ ਵੱਖ-ਵੱਖ ਵਿਅਕਤੀਗਤ ਗਲਤੀ ਪੰਨੇ ਬਣਾ ਸਕਦੇ ਹਾਂ।

PS

K8s ਟਿਪਸ ਅਤੇ ਟ੍ਰਿਕਸ ਸੀਰੀਜ਼ ਤੋਂ ਹੋਰ:

• «ਹੈਲਮ 2 ਦੇ ਨਿਯੰਤਰਣ ਅਧੀਨ ਕਲੱਸਟਰ ਵਿੱਚ ਚੱਲ ਰਹੇ ਸਰੋਤਾਂ ਦਾ ਤਬਾਦਲਾ";
• «ਵੈਬ ਐਪਲੀਕੇਸ਼ਨ 'ਤੇ ਨੋਡ ਅਲੋਕੇਸ਼ਨ ਅਤੇ ਲੋਡ ਬਾਰੇ";
• «dev ਸਾਈਟਾਂ ਤੱਕ ਪਹੁੰਚ";
• «ਵੱਡੇ ਡੇਟਾਬੇਸ ਲਈ ਬੂਟਸਟਰੈਪ ਨੂੰ ਤੇਜ਼ ਕਰਨਾ".

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

• «ਇਸਟੀਓ ਦੇ ਨਾਲ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ 'ਤੇ ਵਾਪਸ ਜਾਓ। ਭਾਗ 1";
• «[ਇਲਸਟ੍ਰੇਟਿਡ] ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਨੈੱਟਵਰਕਿੰਗ ਲਈ ਗਾਈਡ। ਭਾਗ 3".

ਸਰੋਤ: www.habr.com