Kubernetes 팁 및 요령: NGINX Ingress의 사용자 지정 오류 페이지

이 기사에서는 개인화된 오류 페이지 표시와 관련된 NGINX Ingress의 두 가지 기능과 해당 기능에 존재하는 제한 사항 및 이를 해결하는 방법에 대해 설명하고 싶습니다.

1. 기본 백엔드 변경

기본적으로 NGINX Ingress는 해당 기능을 수행하는 기본 백엔드를 사용합니다. 이는 Ingress 리소스에 없는 호스트를 지정하는 Ingress를 요청할 때 404 응답 코드가 포함된 다음 페이지를 수신함을 의미합니다.

그러나 점점 더 많은 고객이 표준 404 대신 회사 로고 및 기타 편의 시설을 페이지에 표시해 달라는 요청을 받고 있습니다. 이를 위해 NGINX Ingress는 내장된 기능 재정의하다 default-backend-service. 형식 항목을 동일한 이름의 옵션에 대한 인수로 전달합니다. namespace/servicename. 서비스 포트는 80이어야 합니다.

이렇게 하려면 애플리케이션을 사용하여 자체 Pod(배포) 및 서비스를 생성해야 합니다(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과 함께 오류를 수신하면 요청이 자동으로 새 기본 백엔드로 리디렉션됩니다.

그러나 기본 백엔드 및 custom-http-errors용 애플리케이션을 개발할 때는 다음과 같은 중요한 기능을 고려해야 합니다.

!!! 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 이상, 기본 Ingress 주석을 사용하십시오.

1. 우리는 재정의할 수 있습니다 default-backend 에 각 인그레스의 주석 사용;
2. 우리는 재정의할 수 있습니다 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의 운명적인 커밋). 그리고 클러스터에서 완전히 다른 2개의 애플리케이션이 실행되고 있고 서로 다른 기본 백엔드 서비스를 지정하고 각각에 대해 서로 다른 오류 코드를 처리하려는 경우 해결 방법을 사용해야 합니다. 그 중 두 가지가 있습니다.

수신 < 0.23: 접근 방식 XNUMX

이 옵션은 더 간단합니다. 페이지를 제공하는 애플리케이션으로서 헤더를 보고 올바른 응답 코드를 반환하는 방법을 모르는 일반 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 유형이어야 합니다.

동시에 오류를 처리할 애플리케이션에서 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;
      }

Ingress < 0.23: 두 번째 접근 방식

헤더를 처리할 수 있는 애플리케이션에 대한 옵션... 그리고 일반적으로 이것은 custom-http-errors에서 빌린 더 정확한 방법입니다. 수동으로(복사) 사용하면 전역 설정을 변경할 수 없습니다.

단계는 다음과 같습니다. 우리는 창조한다 동일한 배포 필요한 헤드라인을 듣고 올바르게 응답할 수 있는 애플리케이션을 사용합니다. 다음 콘텐츠로 Ingress 애플리케이션에 서버 스니펫을 추가합니다.

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 팁 및 요령 시리즈:

• «클러스터에서 실행 중인 리소스를 Helm 2 관리로 전송";
• «웹 애플리케이션의 노드 할당 및 로드 정보";
• «개발 사이트에 대한 액세스";
• «대규모 데이터베이스의 부트스트랩 속도 향상".

블로그에서도 읽어보세요.

• «Istio를 사용한 마이크로서비스로 돌아갑니다. 1 부";
• «[그림] Kubernetes 네트워킹 가이드. 3부".

출처 : habr.com