it-swarm-eu.dev

Kubernetes Ingress (GCE) continua a restituire 502 errori

Sto cercando di configurare un ingresso in GCE Kubernetes. Ma quando visito l'indirizzo IP e la combinazione di percorsi definiti in Ingress, continuo a ricevere il seguente errore 502:

 Ingress 502 error


Ecco cosa ottengo quando eseguo: 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

Penso che il problema sia dpl-identity:4000 (<none>). Non dovrei vedere l'indirizzo IP del servizio dpl-identity invece di <none>?

Ecco la mia descrizione del servizio: 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.

Inoltre, ecco il risultato dell'esecuzione: 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.

Ecco il mio 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
13
Moon

Il tuo backend k8s-be-32396--5fc40252fadea594 viene visualizzato come "UNHEALTHY".

Ingress non inoltrerà il traffico se il back-end è SANO, ciò comporterà l'errore 502 che stai vedendo.

Verrà contrassegnato come NON SANO perché non sta passando il controllo dello stato, è possibile controllare l'impostazione di controllo dello stato per k8s-be-32396--5fc40252fadea594 per vedere se sono appropriati per il pod, potrebbe interrogare un URI o una porta quello non sta restituendo una risposta 200. È possibile trovare queste impostazioni in Compute Engine> Health Checks.

Se sono corretti, ci sono molti passaggi tra il tuo browser e il contenitore che potrebbe passare il traffico in modo errato, potresti provare kubectl exec -it PODID -- bash (o ash se stai usando Alpine) e poi provare a curl-ing localhost per vedere se il container risponde come atteso, se lo è e anche i controlli di integrità sono configurati correttamente, questo potrebbe limitare il problema al probabile servizio, potreste quindi provare a cambiare il servizio da un tipo NodePort a LoadBalancer e vedere se colpire l'IP del servizio direttamente da il tuo browser funziona.

23
Simon I

Ho avuto lo stesso problema e persisteva dopo aver abilitato livenessProbe anche readinessPorbe. Ciò ha avuto effetto con l'autenticazione di base. Ho aggiunto l'auth di base a livenessProbe e alla readinessPorbe, ma il bilanciatore di carico di GCE HTTP (S) non ha un'opzione di configurazione per questo.

Sembra che ci sia anche un altro tipo di problema, ad es. impostando la porta del contenitore su 8080 e la porta di servizio su 80 non funzionava con il controllore di ingresso GKE (ma non indicherei chiaramente quale fosse il problema). E in generale, mi sembra che ci sia pochissima visibilità e gestire il proprio contenitore di ingresso è un'opzione migliore rispetto alla visibilità.

Ho scelto Traefik per il mio progetto, ha funzionato out of the box, e mi piacerebbe abilitare l'integrazione Let's Encrypt. L'unico cambiamento che ho dovuto apportare ai manifesti di Traefik riguarda il tweaking dell'oggetto servizio per disabilitare l'accesso all'interfaccia dall'esterno del cluster ed esporre la mia app tramite il bilanciamento del carico esterno (GCE TCP LB). Inoltre, Traefik è più nativo di Kubernetes. Ho provato Heptio Contour, ma qualcosa non ha funzionato immediatamente (lo darò la prossima volta quando uscirà la nuova versione).

1
errordeveloper

La sezione "Limitazioni" della documentazione kubernetes afferma che:

Tutti i servizi di Kubernetes devono servire una pagina di 200 su "/", o qualsiasi valore personalizzato che hai specificato tramite --health-check-path argument di GLBC.

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

0
morgane1806

Stavo avendo lo stesso problema. Si scopre che ho dovuto aspettare qualche minuto prima di entrare per convalidare la salute del servizio. Se qualcuno sta facendo lo stesso e ha fatto tutti i passaggi come readinessProbe e linvenessProbe, assicurati che il tuo ingresso stia puntando a un servizio che sia NodePort, e attendi qualche minuto fino a quando l'icona di avviso gialla diventa verde. Inoltre, controlla il registro StackDriver per avere un'idea migliore di cosa sta succedendo. La mia readinessProbe e livenessProbe è su /login, per la classe gce. Quindi non penso che debba essere su /healthz.

0
Mauricio

Il problema è in effetti un controllo dello stato di salute e sembrava "casuale" per le mie app in cui utilizzavo host virtuali basati sul nome per invertire le richieste proxy dall'ingresso tramite domini a due servizi back-end separati. Entrambi sono stati protetti utilizzando Lets Encrypt e kube-lego. La mia soluzione era di standardizzare il percorso per i controlli di integrità per tutti i servizi che condividono un'entrata e dichiarare le configurazioni readinessProbe e livenessProbe nel mio file deployment.yml.

Ho affrontato questo problema con la versione del nodo del cluster cloud Google 1.7.8 e ho trovato questo problema che assomigliava molto a quello che ho riscontrato: * https://github.com/jetstack/kube-lego/issues/27

Sto usando gce e kube-lego e i miei controlli dello stato del servizio di backend erano su / e kube-lego è su /healthz. Sembra che la causa siano percorsi diversi per i controlli di integrità con gce ingress, quindi potrebbe valer la pena aggiornare i servizi di backend in modo che corrispondano al modello /healthz in modo che tutti usino lo stesso (o come un commentatore nel problema di Github ha dichiarato di aggiornare kube-lego per passare /).

0
Mike S.