Kubernetes ipuçları ve püf noktaları: NGINX Ingress'teki özel hata sayfaları

Bu makalede, NGINX Ingress'in kişiselleştirilmiş hata sayfalarının görüntülenmesiyle ilgili iki özelliğinden, bunların içinde bulunan sınırlamalardan ve bunları aşmanın yollarından bahsetmek istiyorum.

1. Varsayılan arka ucu değiştirme

Varsayılan olarak NGINX Ingress, ilgili işlevi gerçekleştiren varsayılan arka ucu kullanır. Bu, Giriş kaynaklarında olmayan bir ana bilgisayarı belirten bir Giriş isteğinde bulunduğumuzda, 404 yanıt kodunu içeren aşağıdaki sayfayı aldığımız anlamına gelir:

Bununla birlikte, müşterilerimiz giderek daha sık olarak sayfalarının standart 404 yerine kurumsal logo ve diğer olanaklarla gösterilmesi talebiyle geliyor. Bunu yapmak için NGINX Girişi yerleşik yetenek yeniden tanımlamak default-backend-service. Format girişini aynı isimdeki seçeneğe argüman olarak aktarıyoruz namespace/servicename. Hizmetin bağlantı noktası 80 olmalıdır.

Bunu yapmak için uygulamanızla birlikte kendi pod'unuzu (dağıtımınızı) ve hizmetinizi oluşturmanız gerekir (YAML'de örnek uygulama varsayılan arka uç yerine verilecek olan ingress-nginx deposundan).

İşte küçük bir örnek:

~$ 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>

Dolayısıyla, YAML aracılığıyla açıkça oluşturulmamış tüm alanlar kind: Ingress, varsayılan arka uca düşer. Yukarıdaki listede bu alan adı şu şekilde oldu: sadsdasdas.

2. Varsayılan arka ucu kullanarak uygulamadaki HTTP hatalarını işleme

Diğer bir durum ise bu gibi durumları işlemeyen bir uygulamaya yapılan HTTP hatalarıyla (404, 500, 502...) sonuçlanan isteklerdir (karşılık gelen güzel sayfalar oluşturulmaz). Bu aynı zamanda geliştiricilerin aynı hata sayfalarını birden fazla uygulamada sunma isteğinden de kaynaklanıyor olabilir.

Bu durumu sunucu tarafında uygulamak için ihtiyacımız var:

1. Yukarıdaki varsayılan arka uçla ilgili paragraftaki talimatları izleyin;
2. Nginx giriş yapılandırması ConfigMap'e bir anahtar ekleyin custom-http-errorsörneğin, değeriyle 404,503 (açıkçası yeni kuralın kapsadığı hata kodlarına karşılık gelir).

Beklenen sonuç elde edildi: İstemci uygulaması çalışırken ve 404 veya 503 yanıt koduyla bir hata aldığında, istek otomatik olarak yeni varsayılan arka uca yönlendirilecektir...

Ancak, varsayılan arka uç ve özel http hataları için bir uygulama geliştirirken önemli bir özelliği dikkate almanız gerekir:

!!! 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.

Gerçek şu ki, bir istek yeniden yönlendirildiğinde, başlıklar önceki yanıt koduyla birlikte yararlı bilgiler ve ek bilgiler içerecektir (bunların tam listesi mevcuttur) burada).

Bu, sizin kendinizin doğru yanıt koduna dikkat edin. İşte bir örnek belgelerden nasıl çalıştığını öğrenin.

Farklı uygulamaların farklı varsayılan arka uçları vardır

Çözümün kümenin tamamı için genel olmadığından ve yalnızca belirli uygulamalara uygulandığından emin olmak için öncelikle Giriş sürümünü kontrol etmeniz gerekir. Eşleşiyorsa 0.23 veya daha yüksek, yerel Giriş ek açıklamalarını kullanın:

1. Geçersiz kılabiliriz default-backend için her Giriş ek açıklamaları kullanma;
2. Geçersiz kılabiliriz custom-http-errors için her Giriş ek açıklamaları kullanma.

Sonuç olarak Giriş kaynağı şuna benzer:

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

Bu durumda, 404 ve 502 numaralı hatalar, gerekli tüm başlıklarla birlikte hata sayfaları hizmetine yönlendirilecektir.

В Ingress'in önceki sürümlerinde bu özellik yoktu (0.23'te kader taahhüdü). Kümenizde çalışan tamamen farklı 2 uygulamanız varsa ve bunların her biri için farklı bir varsayılan arka uç hizmeti ve farklı hata kodlarının işlenmesini belirtmek istiyorsanız, bunun için elimizde iki tane bulunan geçici çözümleri kullanmanız gerekecektir.

Giriş < 0.23: birinciye yaklaşma

Bu seçenek daha basittir. Sayfalarına hizmet veren bir uygulama olarak, başlıklara nasıl bakacağını ve doğru yanıt kodlarını nasıl döndüreceğini bilmeyen normal HTML'ye sahibiz. Böyle bir uygulama URL'den Giriş ile kullanıma sunuldu /error-pagesve katalogda ws döndürülen HTML olacaktır.

YAML'deki illüstrasyon:

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

Bu dağıtıma yönelik hizmet ClusterIP türünde olmalıdır.

Aynı zamanda hatayı işleyeceğimiz uygulamada Ingress'te aşağıdaki içeriğe sahip bir sunucu pasajı veya konfigürasyon pasajı ekliyoruz:

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

Giriş < 0.23: ikinci yaklaşım

Başlıkları işleyebilen bir uygulama için bir seçenek... Ve genel olarak bu, özel http hatalarından ödünç alınan daha doğru bir yoldur. Manuel olarak kullanmak (kopyalamak), genel ayarları değiştirmemenizi sağlar.

Adımlar aşağıdaki gibidir. Biz yaratırız aynı dağıtım gerekli başlıkları dinleyip doğru cevap verebilen bir uygulama ile. Ingress uygulamasına aşağıdaki içeriğe sahip bir sunucu pasajı ekleyin:

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

Gördüğünüz gibi, işlemek istediğimiz her hata için, “yerel” olanda olduğu gibi, gerekli tüm başlıkların ekleneceği kendi konumumuzu oluşturmamız gerekiyor. özel-hata-sayfaları. Bu şekilde, bireysel konumlar ve sunucular için bile farklı kişiselleştirilmiş hata sayfaları oluşturabiliriz.

PS

K8'in ipuçları ve püf noktaları serisinden diğerleri:

• «Bir kümede çalışan kaynakları Helm 2 yönetimine aktarma";
• «Bir web uygulamasında düğüm tahsisi ve yüklemeler hakkında";
• «Geliştirici sitelerine erişim";
• «Büyük veritabanları için önyüklemeyi hızlandırma'.

Blogumuzda da okuyun:

• «Istio ile mikro hizmetlere geri dönelim. Bölüm 1";
• «[Resimli] Kubernetes'te ağ oluşturma kılavuzu. Bölüm 3'.

Kaynak: habr.com