Σε αυτό το άρθρο, θέλω να μιλήσω για δύο χαρακτηριστικά του NGINX Ingress που σχετίζονται με την εμφάνιση εξατομικευμένων σελίδων σφαλμάτων, καθώς και για τους περιορισμούς που υπάρχουν σε αυτές και τους τρόπους αντιμετώπισης τους.
1. Αλλαγή του προεπιλεγμένου backend
Από προεπιλογή, το NGINX Ingress χρησιμοποιεί το προεπιλεγμένο backend, το οποίο εκτελεί την αντίστοιχη λειτουργία. Αυτό σημαίνει ότι όταν ζητάμε ένα Ingress που καθορίζει έναν κεντρικό υπολογιστή που δεν βρίσκεται στους πόρους Ingress, λαμβάνουμε την ακόλουθη σελίδα με έναν κωδικό απόκρισης 404:
Ωστόσο, όλο και πιο συχνά οι πελάτες μας έρχονται με αίτημα να εμφανίσουν τη σελίδα τους με εταιρικό λογότυπο και άλλες ανέσεις αντί για το τυπικό 404. Για να γίνει αυτό, το NGINX Ingress έχει επαναπροσδιορίσει default-backend-service. Περνάμε την καταχώρηση μορφής ως όρισμα στην ομώνυμη επιλογή namespace/servicename. Η θύρα της υπηρεσίας πρέπει να είναι 80.
Για να το κάνετε αυτό, πρέπει να δημιουργήσετε το δικό σας pod (ανάπτυξη) και υπηρεσία με την εφαρμογή σας ( από το αποθετήριο ingress-nginx), το οποίο θα δοθεί αντί για το προεπιλεγμένο backend.
Εδώ είναι μια μικρή απεικόνιση:
~$ 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, εμπίπτουν σε προεπιλεγμένο backend. Στην παραπάνω λίστα, αυτός ο τομέας έγινε sadsdasdas.
2. Χειρισμός σφαλμάτων HTTP στην εφαρμογή χρησιμοποιώντας το προεπιλεγμένο backend
Μια άλλη κατάσταση είναι αιτήματα που καταλήγουν σε σφάλματα HTTP (404, 500, 502...) σε μια εφαρμογή που δεν επεξεργάζεται τέτοιες καταστάσεις (δεν δημιουργούνται οι αντίστοιχες όμορφες σελίδες). Αυτό μπορεί επίσης να οφείλεται στην επιθυμία των προγραμματιστών να εμφανίζουν τις ίδιες σελίδες σφαλμάτων σε πολλές εφαρμογές.
Για να εφαρμόσουμε αυτήν την περίπτωση στην πλευρά του διακομιστή χρειαζόμαστε:
- Ακολουθήστε τις παραπάνω οδηγίες από την παράγραφο σχετικά με το προεπιλεγμένο backend.
- Προσθέστε ένα κλειδί στη διαμόρφωση nginx-ingress ConfigMap
custom-http-errors, για παράδειγμα, με την τιμή404,503(προφανώς αντιστοιχεί στους κωδικούς σφαλμάτων που καλύπτονται από τον νέο κανόνα).
Το αναμενόμενο αποτέλεσμα έχει επιτευχθεί: όταν η εφαρμογή-πελάτης εκτελείται και λάβει ένα σφάλμα με κωδικό απόκρισης 404 ή 503, το αίτημα θα ανακατευθυνθεί αυτόματα στο νέο προεπιλεγμένο backend...
Ωστόσο, κατά την ανάπτυξη μιας εφαρμογής για προεπιλεγμένα σφάλματα υποστήριξης και προσαρμοσμένα 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.Το γεγονός είναι ότι όταν ένα αίτημα ανακατευθύνεται, οι κεφαλίδες θα περιέχουν χρήσιμες πληροφορίες με τον προηγούμενο κωδικό απάντησης και πρόσθετες πληροφορίες (η πλήρης λίστα τους είναι διαθέσιμη ).
Αυτό σημαίνει ότι εσείς οι ίδιοι πρέπει φροντίστε για τον σωστό κωδικό απάντησης. από την τεκμηρίωση πώς λειτουργεί.
Διαφορετικές εφαρμογές έχουν διαφορετικά προεπιλεγμένα backend
Για να διασφαλίσετε ότι η λύση δεν είναι καθολική για ολόκληρο το σύμπλεγμα, αλλά ισχύει μόνο για συγκεκριμένες εφαρμογές, πρέπει πρώτα να ελέγξετε την έκδοση Ingress. Αν ταιριάζει 0.23 και άνω, χρησιμοποιήστε τους εγγενείς σχολιασμούς Ingress:
- Μπορούμε να παρακάμψουμε
default-backendγια του καθενός του Ingress ; - Μπορούμε να παρακάμψουμε
custom-http-errorsγια του καθενός του Ingress .
Ως αποτέλεσμα, ο πόρος 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 εντελώς διαφορετικές εφαρμογές που εκτελούνται στο σύμπλεγμα σας και θέλετε να καθορίσετε μια διαφορετική προεπιλεγμένη υπηρεσία υποστήριξης και επεξεργασία διαφορετικών κωδικών σφάλματος για καθεμία από αυτές, για αυτό θα πρέπει να χρησιμοποιήσετε λύσεις, από τις οποίες έχουμε δύο.
Είσοδος < 0.23: προσέγγιση ένα
Αυτή η επιλογή είναι απλούστερη. Ως εφαρμογή που εξυπηρετεί τις σελίδες της, έχουμε κανονικό HTML, το οποίο δεν ξέρει πώς να κοιτάξει τις κεφαλίδες και να επιστρέψει τους σωστούς κωδικούς απόκρισης. Μια τέτοια εφαρμογή κυκλοφορεί με το Ingress από το 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 προσθέτουμε ένα διακομιστή-snippet ή configuration-snippet με το ακόλουθο περιεχόμενο:
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: δεύτερη προσέγγιση
Μια επιλογή για μια εφαρμογή που μπορεί να επεξεργαστεί κεφαλίδες... Και γενικά αυτός είναι πιο σωστός τρόπος, δανεισμένος από 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 tips & tricks:
- «"?
- «"?
- «"?
- «».
Διαβάστε επίσης στο blog μας:
- «"?
- «».
Πηγή: www.habr.com