Je suis un peu confus, le chemin résolue le point final, montrait-il dans des journaux le point final qu'il crée. Je suis coincé avec ça maintenant. Vous trouverez ci-dessous le point final que je voulais appeler: -
https: // nom d'hôte / API / Ordres / Employés. Et d'appeler ce point d'extrémité via une passerelle d'application d'entrée, c'est ainsi que j'ai configuré mais il renvoie toujours 502 erreur de passerelle Bad. P>
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: ordersapi
namespace: orders
annotations:
kubernetes.io/ingress.class: azure/application-gateway
appgw.ingress.kubernetes.io/appgw-ssl-certificate: "wildcard.apps.com"
appgw.ingress.kubernetes.io/ssl-redirect: "true"
spec:
rules:
- host: orders.apps.com
http:
paths:
- path: /api/orders/employees
backend:
serviceName: orderservice
servicePort: 80
5 Réponses :
Vous semblez avoir activé la redirection SSL, mais votre service est servi sur un port non SSL.
Cela pourrait expliquer la mauvaise passerelle.
Souvent, l'Azure Appgw retournera 502 Bad Gateway lorsqu'il y a de mauvais certs impliqués, la vérification de la santé du service backend est fausse et une autre raison
Vous devriez regarder cela:
et cette
@DJSLY @ Jean-Philippe Bond - Merci pour votre réponse et pointant l'URL qui m'a aidé à enquêter plus loin. Avoir la demande de contrôle déployée sur le port 80 avait une raison en tant que SSL terminer sur la passerelle d'application et l'auditeur redirige la demande d'application de la version exécutée sur le port 80, qui fonctionne correctement.
Après une enquête supplémentaire, j'ai ajouté le préfixe de la piste de retour dans le fichier d'ingress ( appgw.ingress.kubernettes.io/backend-path-prefix: "/ API / Ordres / Employés") qui résolvait le problème d'un point final mais pas pour tous. p>
Pour décrire le problème des détails, de l'application Contient certains des services reposants mentionnés ci-dessous et leurs points d'extrémité sont tels que - P>
http: // nom d'hôte / API / Commandes / Employés http: // nom d'hôte / API / Recherche / OfficeHierarchy http: // nom d'hôte / API / DÉPARTEMENT / CODES http: // nom d'hôte / API / Position / Membres P> blockQuote>
maintenant si vous le voyez, ces différents points d'extrémité commencent par préfixe "/ API /", puis le nom du contrôleur et les actions. P>
ici Résultat attendu strong> est Si l'un de ces points d'extrémité est appelé (via HTTP GET), les données doivent être renvoyées, mais elle échoue. P>
enquête faite jusqu'à présent strong> J'ai ajouté le préfixe et ai-je modifié. Ainsi, si je configure ma pénétration comme ci-dessous, elle renvoie renvoie le résultat avec succès strong> pour un seul point d'extrémité spécifique -> p>
curl -v http://orders.apps.com/api/orders/employest strong> retourne 200 mais échoue pour les autres. xxx pré> Ainsi, pour faire fonctionner tous les points finaux, j'ai fait les modifications ci-dessous dans le fichier d'entrée mentionné ci-dessus mais appelant curl -v http://orders.apps.com/api/orders/employes strong> retourne 404. Et la même chose va avec d'autres points finaux comme curl -v http://orders.apps.com/api/department/codes strong> retourne 404. P>
selon ma compréhension, en faisant les modifications ci-dessous - "chemin - / API / *" doit être écrasé sur le chemin - / API / Commandes / Employés Strong> Appelé mais ce n'est pas. P>
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: ordersapi namespace: orders annotations: kubernetes.io/ingress.class: azure/application-gateway appgw.ingress.kubernetes.io/backend-path-prefix: "/api/" appgw.ingress.kubernetes.io/appgw-ssl-certificate: "wildcard.apps.com" appgw.ingress.kubernetes.io/ssl-redirect: "true" spec: rules: - host: orders.apps.com http: paths: - path: /api* backend: serviceName: orderservice servicePort: 80
Avez-vous essayé de supprimer le Backend-path-PROFIX-PREFIX et définissez le chemin sur / . S'il vous plaît dire ce que vous obtenez après cela?
Désolé de répondre tard à ce sujet, il lance 404 erreur. Génère-t-il une URL quelque part dans un code?
Définir plusieurs chemins sans piste backend-path-préfixe travaillait ..... par exemple. - http: chemins: chemin: / API / Commandes / Employés Backend: ServiceName: Ordreservice Serviceport: 80 Chemin: / API / Position / Membres Backend: ServiceName: ServiceService Serviceport: 80
Définition de plusieurs chemins Cela semble être un moyen complexe mais jusqu'à présent, j'ai trouvé cela la seule façon qui a fonctionné.
Enfin, il y a deux solutions à ce problème: -
second
J'ai le même problème. Ma configuration d'entrée était comme: Si j'ai défini un chemin comme / API / Todolist, le noeud final a fonctionné bien. D'autre part si je suis allé avec / API *, mes demandes ont été redirigées à l'application frontale. Le problème était que le point final / API / Todolist existait sur mon statut de backend et de mon statut de retour était de 200, pour le point de terminaison / API Je n'ai rien configuré rien, alors j'ai eu 404 Statut. Dans mon cas, j'avais besoin d'ajouter HealthCheck sous / API EdPoint, qui a renvoyé le statut HTTP correctement :) Pour que je revienne une chaîne "saine" suffisait.
Quel est le chemin sur le service du backend, est-ce "/ API / Ordres / Employés"?
Oui c'est - API / Commandes / Employés.