この記事では、パーソナライズされたエラー ページの表示に関連する NGINX Ingress の XNUMX つの機能と、そこに存在する制限とその回避方法について説明したいと思います。
1. デフォルトのバックエンドの変更
デフォルトでは、NGINX Ingress はデフォルトのバックエンドを使用し、対応する機能を実行します。 これは、Ingress リソースにないホストを指定して Ingress をリクエストすると、404 応答コードを含む次のページを受信することを意味します。
ただし、標準の 404 ではなく、会社のロゴやその他のアメニティをページに表示したいというクライアントからのリクエストが増えています。 これを行うために、NGINX Ingress には 再定義する default-backend-service。 フォーマットエントリを引数として同じ名前のオプションに渡します。 namespace/servicename。 サービスのポートは 80 である必要があります。
これを行うには、アプリケーションで独自のポッド (デプロイメント) とサービスを作成する必要があります ( 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、default-backend に分類されます。 上記のリストでは、このドメインは次のようになりました。 sadsdasdas.
2. デフォルトのバックエンドを使用したアプリケーションでの HTTP エラーの処理
もう 404 つの状況は、そのような状況を処理しない (対応する美しいページが生成されない) アプリケーションへの HTTP エラー (500、502、XNUMX...) で終了するリクエストです。 これは、複数のアプリケーションで同じエラー ページを提供したいという開発者の要望によるものである可能性もあります。
このケースをサーバー側で実装するには、次のものが必要です。
- デフォルトのバックエンドに関する段落の上記の手順に従ってください。
- nginx-ingress 構成 ConfigMap にキーを追加します。
custom-http-errorsたとえば、次の値を使用します。404,503(明らかに、新しいルールの対象となるエラー コードに対応します)。
期待どおりの結果が得られました。クライアント アプリケーションが実行中に応答コード 404 または 503 のエラーを受信すると、リクエストは自動的に新しいデフォルト バックエンドにリダイレクトされます。
ただし、デフォルトのバックエンドおよびカスタム 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 アノテーションを使用します。
- オーバーライドできます
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 の以前のバージョンにはこの機能はありませんでした (）。 また、クラスター内で 2 つのまったく異なるアプリケーションが実行されており、それぞれに異なるデフォルト バックエンド サービスと異なるエラー コードの処理を指定したい場合は、回避策を使用する必要があります。回避策は XNUMX つあります。
Ingress < 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;
}イングレス < 0.23: XNUMX 番目のアプローチ
ヘッダーを処理できるアプリケーションのオプション...そして一般的に、これは、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 のヒントとテクニック シリーズのその他:
- «";
- «";
- «";
- «'。
私たちのブログもお読みください:
- «";
- «'。
出所： habr.com