2 votes

Kubernetes : 502 Bad Gateway pour certains actifs - avec Nginx Ingress

J'ai configuré un cluster Kubernetes comme suit :

  • Pod Webapp (avec une Vue.js et une API, toutes deux dans chaque conteneur)
  • Configuration ingress de Nginx (avec default-http-backend)
  • pod de base de données (qui ne semble pas être le problème ici)
  • Kube lego (pour SSL, dans un espace de noms séparé)

Quoi qu'il en soit, après avoir terminé la configuration, l'application frontale (c'est-à-dire Vue.js) n'a chargé aucun style, seulement du pur HTML + JS. En ouvrant l'onglet Réseau de Firefox, j'ai vu une erreur "502" dans le fichier CSS.

Juste pour le contexte, voici le Dockerfile de mon Vue.js :

FROM node:lts-alpine

RUN npm install http-server -g

WORKDIR /app

# copy both 'package.json' and 'package-lock.json' (if available)
COPY package*.json ./

# install project dependencies
RUN npm install

# copy project files and folders to the current working directory (i.e. 'app' folder)
COPY . .
RUN npm run build

EXPOSE 8000
CMD [ "http-server", "dist", "-c-1", "-p", "8000" ]

Et voici le journal du contrôleur Nginx (à partir de kubectl logs [nginx-controller-pod] ): https://pastebin.com/tBfPXJns (je n'ai pas pu le poster ici car il est supposé être un spam).

La plupart du temps, seules les requêtes CSS et .png renvoient 502, tandis que toutes les requêtes JS atteignent le serveur frontal.

Mon Ingress :

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-nginx
  annotations:
    kubernetes.io/tls-acme: "true"
    kubernetes.io/ingress.class: "nginx"    
    nginx.ingress.kubernetes.io/proxy-body-size: 200m                        
    nginx.ingress.kubernetes.io/rewrite-target: /    
    nginx.ingress.kubernetes.io/server-snippet: |
      add_header 'Access-Control-Expose-Headers' 'access-token,expiry,token-type,uid,client,Access-Token,Expiry,Token-Type,Uid,Client';                                                                

spec:
  tls:
    - hosts:
        ~all-hosts~
      secretName: birthplace-ssl        
  rules:
    - host: api.example.com.br
      http:
        paths:         
         - path: /
           backend:
             serviceName: example-backend-service
             servicePort: 9292         
    - host: example.com.br
      http: &default
        paths:      
          - path: /
            backend:
              serviceName: example-frontend-service
              servicePort: 8000             
    - host: painel.example.com
      http: *default        
    - host: admin.example.com
      http: *default

Mon déploiement YAML est correctement configuré pour les deux services (c'est-à-dire qu'il utilise les ports 8000 et 9292).

Bizarrement Je peux accéder à n'importe lequel de ces actifs à partir d'une requête GET (externe) normale.

P.S. Au journal...

10.24.0.40 est l'IP du cluster default-http-backend.

10.24.1.3 est l'IP de ma webapp.

0 votes

Peut-être que la réécriture a tout gâché ?

0 votes

Non. Avec ou sans, même résultat.

0 votes

Ok, définissez "La plupart du temps, seules les requêtes CSS et .png renvoient 502". donc ça marche parfois ?

2voto

Mr.KoopaKiller Points 188

Comme mentionné dans les commentaires, vous devez utiliser l'annotation nginx.ingress.kubernetes.io/service-upstream: "true" :

Extrait de la documentation de nginx-ingress :

Service en amont

Par défaut, le contrôleur NGINX ingress utilise une liste de tous les points d'extrémité (Pod IP/port) >dans la configuration NGINX upstream.

L'annotation nginx.ingress.kubernetes.io/service-upstream désactive ce comportement et utilise à la place un seul upstream dans NGINX, l'IP et le port du Cluster du service.

Cela peut être souhaitable pour des choses comme les déploiements sans temps d'arrêt, car cela réduit le besoin de recharger la configuration de NGINX lorsque les pods montent et descendent. Voir le problème n° 257.

Ici est un problème github avec une configuration valide en cours d'exécution.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X