web-dev-qa-db-fra.com

Kubernetes Ingress (GCE) ne cesse de renvoyer une erreur 502

J'essaye d'installer une entrée dans GCE Kubernetes. Mais lorsque je visite la combinaison adresse IP et chemin définie dans l'Ingress, je reçois toujours l'erreur 502 suivante:

 Ingress 502 error

Voici ce que je reçois quand je cours: kubectl describe ing --namespace dpl-staging

Name:           dpl-identity
Namespace:      dpl-staging
Address:        35.186.221.153
Default backend:    default-http-backend:80 (10.0.8.5:8080)
TLS:
  dpl-identity terminates
Rules:
  Host  Path    Backends
  ----  ----    --------
  *
        /api/identity/*     dpl-identity:4000 (<none>)
Annotations:
  https-forwarding-rule:    k8s-fws-dpl-staging-dpl-identity--5fc40252fadea594
  https-target-proxy:       k8s-tps-dpl-staging-dpl-identity--5fc40252fadea594
  url-map:          k8s-um-dpl-staging-dpl-identity--5fc40252fadea594
  backends:         {"k8s-be-31962--5fc40252fadea594":"HEALTHY","k8s-be-32396--5fc40252fadea594":"UNHEALTHY"}
Events:
  FirstSeen LastSeen    Count   From                SubObjectPath   Type        Reason  Message
  --------- --------    -----   ----                -------------   --------    ------  -------
  15m       15m     1   {loadbalancer-controller }          Normal      ADD dpl-staging/dpl-identity
  15m       15m     1   {loadbalancer-controller }          Normal      CREATE  ip: 35.186.221.153
  15m       6m      4   {loadbalancer-controller }          Normal      Service no user specified default backend, using system default

Je pense que le problème est dpl-identity:4000 (<none>). Est-ce que je ne devrais pas voir l'adresse IP du service dpl-identity au lieu de <none>?

Voici la description de mon service: kubectl describe svc --namespace dpl-staging

Name:           dpl-identity
Namespace:      dpl-staging
Labels:         app=dpl-identity
Selector:       app=dpl-identity
Type:           NodePort
IP:             10.3.254.194
Port:           http    4000/TCP
NodePort:       http    32396/TCP
Endpoints:      10.0.2.29:8000,10.0.2.30:8000
Session Affinity:   None
No events.

De plus, voici le résultat de l'exécution: kubectl describe ep -n dpl-staging dpl-identity

Name:       dpl-identity
Namespace:  dpl-staging
Labels:     app=dpl-identity
Subsets:
  Addresses:        10.0.2.29,10.0.2.30
  NotReadyAddresses:    <none>
  Ports:
    Name    Port    Protocol
    ----    ----    --------
    http    8000    TCP

No events.

Voici mon deployment.yaml:

apiVersion: v1
kind: Secret
metadata:
  namespace: dpl-staging
  name: dpl-identity
type: Opaque
data:
  tls.key: <base64 key>
  tls.crt: <base64 crt>
---
apiVersion: v1
kind: Service
metadata:
  namespace: dpl-staging
  name: dpl-identity
  labels:
    app: dpl-identity
spec:
  type: NodePort
  ports:
    - port: 4000
      targetPort: 8000
      protocol: TCP
      name: http
  selector:
    app: dpl-identity
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  namespace: dpl-staging
  name: dpl-identity
  labels:
    app: dpl-identity
  annotations:
    kubernetes.io/ingress.allow-http: "false"
spec:
  tls:
  - secretName: dpl-identity
  rules:
  - http:
      paths:
        - path: /api/identity/*
          backend:
            serviceName: dpl-identity
            servicePort: 4000
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  namespace: dpl-staging
  name: dpl-identity
kind: Ingress
metadata:
  namespace: dpl-staging
  name: dpl-identity
  labels:
    app: dpl-identity
  annotations:
    kubernetes.io/ingress.allow-http: "false"
spec:
  tls:
  - secretName: dpl-identity
  rules:
  - http:
      paths:
        - path: /api/identity/*
          backend:
            serviceName: dpl-identity
            servicePort: 4000
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  namespace: dpl-staging
  name: dpl-identity
  labels:
    app: dpl-identity
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: dpl-identity
    spec:
      containers:
      - image: gcr.io/munpat-container-engine/dpl/identity:0.4.9
        name: dpl-identity
        ports:
        - containerPort: 8000
          name: http
        volumeMounts:
        - name: dpl-identity
          mountPath: /data
      volumes:
      - name: dpl-identity
        secret:
          secretName: dpl-identity
kubernetesgoogle-cloud-platformgoogle-container-enginegoogle-compute-engine
13
Moon

Votre backcode k8s-be-32396--5fc40252fadea594 s'affiche sous la forme "UNHEALTHY".

Ingress ne fera pas suivre le trafic si le backend est UNHEALTHY, cela entraînera l’erreur 502 que vous voyez.

Il sera marqué comme étant en manque de santé, car il ne réussit pas sa vérification de l'état. Vous pouvez vérifier le paramètre de vérification de l'état de santé pour k8s-be-32396--5fc40252fadea594 pour voir si elles conviennent à votre pod. cela ne renvoie pas une réponse 200. Vous pouvez trouver ces paramètres sous Compute Engine> Health Checks.

S'ils sont corrects, il existe de nombreuses étapes entre votre navigateur et le conteneur susceptibles de transmettre le trafic de manière incorrecte. Vous pouvez essayer kubectl exec -it PODID -- bash (ou ash si vous utilisez Alpine), puis essayer de courber localhost pour voir si le conteneur répond en tant que Si les contrôles de santé sont également configurés correctement, cela réduirait le problème à votre service, vous pouvez alors essayer de remplacer le service d'un type NodePort par un LoadBalancer et de voir si vous atteignez directement l'adresse IP du service. votre navigateur fonctionne.

23
Simon I

J'ai eu le même problème, et il a persisté après avoir activé livenessProbe ainsi que readinessPorbe. Il s’agissait à présent de l’authentification de base. J'ai ajouté l'authentification de base à livenessProbe et à la readinessPorbe, mais il s'avère que l'équilibreur de charge GCE HTTP (S) ne dispose pas d'une option de configuration pour cela.

Il semble y avoir quelques autres problèmes avec, par exemple: La définition du port de conteneur à 8080 et du port de service à 80 ne fonctionnait pas avec le contrôleur d’entrée GKE (mais je n’indiquerais pas clairement quel était le problème). En gros, il me semble que la visibilité est très réduite et que gérer son propre conteneur d’entrée est une meilleure option en ce qui concerne la visibilité.

J'ai choisi Traefik pour mon projet, cela fonctionnait comme prévu et j'aimerais activer l'intégration de Let's Encrypt. Le seul changement que je devais apporter aux manifestes Traefik consistait à modifier l'objet de service afin de désactiver l'accès à l'interface utilisateur depuis l'extérieur du cluster et d'exposer mon application via un équilibreur de charge externe (GCE TCP LB). En outre, Traefik est plus natif de Kubernetes. J'ai essayé Heptio Contour, mais quelque chose n'a pas fonctionné immédiatement (j'essaierai la prochaine fois que la nouvelle version sortira).

1
errordeveloper

La section "Limitations" de la documentation kubernetes indique que:

Tous les services Kubernetes doivent servir 200 pages sur '/', ou toute autre valeur personnalisée que vous avez spécifiée via le --health-check-path argument de GLBC.

https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/cluster-loadbalancing/glbc#limitations

0
morgane1806

J'avais le même problème. Il s'avère que j'ai dû attendre quelques minutes avant d'entrer pour valider le service. Si quelqu'un suit la même procédure et exécute toutes les étapes telles que readinessProbe et linvenessProbe, assurez-vous simplement que votre entrée pointe vers un service qui est soit une NodePort et attendez quelques minutes que l'icône d'avertissement jaune devienne verte. Consultez également le journal sur StackDriver pour avoir une meilleure idée de ce qui se passe. Ma readinessProbe et livenessProbe est sur /login, pour la classe gce. Donc, je ne pense pas que cela doit être sur /healthz.

0
Mauricio

Issue est en effet un bilan de santé et semblait "aléatoire" pour mes applications dans lesquelles j'ai utilisé des hôtes virtuels basés sur des noms pour inverser les demandes de proxy de l'entrée via des domaines vers deux services principaux distincts. Les deux ont été sécurisés à l'aide de Lets Encrypt et kube-lego. Ma solution consistait à normaliser le chemin d'accès aux contrôles de l'état pour tous les services partageant une entrée et à déclarer les configs readinessProbe et livenessProbe dans mon fichier deployment.yml.

J'ai rencontré ce problème avec la version du noeud de cluster cloud Google 1.7.8 et j'ai découvert ce problème qui ressemblait beaucoup à ce que j'ai connu: * https://github.com/jetstack/kube-lego/issues/27

J'utilise gce et kube-lego et mes vérifications de l'intégrité du service backend étaient sur / et kube-lego est sur /healthz. Il semble que des chemins différents pour les vérifications de l'état physique avec gce ingress pourraient en être la cause. Il peut donc être intéressant de mettre à jour les services principaux pour qu'ils correspondent au modèle /healthz afin qu'ils soient tous identiques (ou qu'un commentateur dans le numéro de Github ait déclaré avoir mis à jour kube-lego pour transmettre /).

0
Mike S.