Eroare Kubernetes Ingress: Serverul a întâmpinat o eroare temporară și nu a putut finaliza solicitarea

voturi
3

În GKE nostru avem un serviciu numit php-services. Acesta este definit astfel:

apiVersion: v1
kind: Service
metadata:
  name: php-services
  labels:
    name: php-services
spec:
  type: NodePort
  ports:
  - port: 80
  selector:
    name: php-services

Pot accesa acest serviciu din interiorul cluster - ului. Dacă am rula aceste comenzi pe una dintre păstăi noastre (în Defaultspațiul de nume), am obține rezultate așteptate:

bash-4.4$ nslookup 'php-services'
   Name:      php-services
   Address 1: 10.15.250.136 php-services.default.svc.cluster.local

și

bash-4.4$ wget -q -O- 'php-services/health'
   {status:ok}

Deci, serviciul este gata și răspunde corect. Am nevoie pentru a expune acest serviciu la trafic străin. Am încercat să o fac cu Ingress următorul fișier de configurare:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-tls
  annotations:
    kubernetes.io/ingress.class: gce
    kubernetes.io/tls-acme: true
    kubernetes.io/ingress.global-static-ip-name: kubernetes-ingress
    kubernetes.io/ingress.allow-http: false
    external-dns.alpha.kubernetes.io/hostname: gke-ingress.goout.net
  namespace: default
spec:
  tls:
  - hosts:
     - php.service.goout.net
    secretName: router-tls
  rules:
  - host: php.service.goout.net
    http:
      paths:
      - backend:
          serviceName: php-services
          servicePort: 80
        path: /*

Dar apoi accesarea http://php.service.goout.net/health da o eroare 502:

Eroare: Eroare de server Serverul a întâmpinat o eroare temporară și ar putea să
nu finaliza solicitarea.
Vă rugăm să încercați din nou în 30 de secunde.

Avem, de asemenea alte servicii cu aceeași config care rula ok și sunt în afara formă accesibilă.

Am găsit o întrebare similară , dar care nu aduce nici un răspuns suficient , fie.
Am fost , de asemenea , ca urmare a Debug Serviciul articol , dar care , de asemenea , nu a ajutat ca serviciul în sine este în regulă.

Orice ajutor cu această problemă extrem de apreciat.

Întrebat 23/07/2018 la 19:01
sursa de către utilizator
În alte limbi...                            


1 răspunsuri

voturi
0

Ok, deci ne-am dat seama ce a fost greșit.

Aruncati o privire la definirea YAML de desfășurare pentru php-servicesserviciul: (scurtat)

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: php-services
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      name: php-services
  template:
    metadata:
      labels:
        name: php-services
    spec:
      containers:
        - name: php-services
          image: IMAGE_TAG
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /health
              port: 80
              scheme: HTTP
            initialDelaySeconds: 60
            periodSeconds: 60
            successThreshold: 1
            timeoutSeconds: 10
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /health
              port: 80
              scheme: HTTP
            initialDelaySeconds: 60
            periodSeconds: 60
            successThreshold: 1
            timeoutSeconds: 10
          ports:
          - containerPort: 80

Aerver Apache în interiorul imaginii a fost configurată în mod încât să redirecționat din căile fără slash pentru căi cu ea. Deci , când ai cerut /healthai de fapt de stare HTTP 301 indică spre /health/care apoi a răspuns cu 200.

În domeniul de aplicare al kubernetes controalelor sanitare acest lucru este OK ca „ Orice cod mai mare sau egal cu 200 și mai puțin de 400 indică un succes.

Cu toate acestea, problema a mințit în GKE LoadBalancer. De asemenea , are propria lui healthchecks GKE derivate din controalele în definiția de implementare. Diferența importantă este faptul că acceptă doar stare HTTP 200 . Și dacă LoadBalancer nu găsește un serviciu backend sănătos nu va trece nici un trafic străin să - l.

Prin urmare, am avut două opțiuni pentru a remedia acest lucru:

  • Asigurați serverul din interiorul recipientului răspunde cu starea HTTPS 200 la ambele /healthși /health/(sau mai precis doar pentru a /health)
  • sau schimba readinessProbe și livenessProbe calea defintion la /health/.

Am ales mai târziu și a rezolvat problema.

Publicat 24/07/2018 la 09:39
sursa de către utilizator

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more