Бэкэнды GKE Ingress помечены как «нездоровые» - PullRequest
0 голосов
/ 05 марта 2020

Я учусь, как использовать вход для показа моего приложения в Google Kubernetes Engine. Я следовал нескольким учебникам и имел грубую настройку того, что нужно. Однако я понятия не имею, почему мой сервис помечен как нездоровый, несмотря на то, что он доступен из сервиса NodePort, который я определил напрямую.

Вот мой файл развертывания: (Я удалил некоторые данные, но большая их часть остается прежней)

--
apiVersion: "apps/v1"
kind: "Deployment"
metadata:
  name: "deployment-1"
  namespace: "default"
    spec:
      containers:
      - name: myContainer
        image: "myImage/"
        readinessProbe:
          httpGet:
            path: /app1
            port: 8080
          initialDelaySeconds: 70      
        livenessProbe:
          httpGet:
            path: /app1
            port: 8080
          initialDelaySeconds: 70    
        ports:
        - containerPort: 8080
          protocol: TCP
        volumeMounts:
        - mountPath: opt/folder/libs/jdbc/
          name: lib
      volumes:
      - name: lib
        persistentVolumeClaim:
          claimName: lib                            
---

Когда я читаю, мне нужны ReadinessProbe и LivinessProbe, чтобы GKE мог запустите проверку работоспособности на пути, который я определил, и, используя мой собственный определенный путь, показанный здесь как / app1 (который вернет 200 OK), сгенерированная проверка работоспособности должна пройти. Я установил начальную задержку в 70 секунд в качестве времени буфера для запуска сервера tomcat, работающего в образе.

Затем я создал службу NodePort в качестве бэкэнда для Ingress: я протестировал, подключившись к узлу publi c IP и нодпорт этого сервиса, и он успешно работает.

---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - name: my-port
    port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    app: deployment-1
  type: NodePort

, а затем файл манифеста Ingress:

Здесь я также зарезервировал IP-адрес stati c с именем "gke-my-stati c -ip" как созданный управляемый сертификат "gke-my-Certificate" с доменным именем "mydomain.web.com". Это также было настроено на записях DNS, чтобы указывать на этот зарезервированный IP-адрес c.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: gke-my-ingress-1
  annotations:
    kubernetes.io/ingress.global-static-ip-name: gke-my-static-ip
    networking.gke.io/managed-certificates: gke-my-certificate
spec:
  rules:
  - host: mydomain.web.com
    http:
      paths:
      - backend:
          serviceName: my-service
          servicePort: my-port

По умолчанию на входе создаются 2 серверных части: одна на пути / healthz, а другая с моим заданным путем / app1. Путь Healthz возвращает 200 OK, но мой пользовательский путь не удается подключиться. Я проверил правила брандмауэра и разрешил порты tcp30000-32767.

При проверке на стекдрайвере проверка работоспособности пытается получить доступ к IP-адресу моего LoadBalancer по пути / app1, но, похоже, всегда возвращает ошибку 502.

Я пропускаю какие-либо шаги в моей настройке?

Прикрепленный вход, конечные точки:

NAME                                        HOSTS                    ADDRESS          PORTS   AGE
ingress.extensions/gke-my-ingress-1   mydomain.web.com   <IP_ADDRESS>   80      3d15h

NAME                         ENDPOINTS           AGE
endpoints/kubernetes          <IP_ADDRESS>443   9d
endpoints/presales-service    <IP_ADDRESS>:8080     4d16h

kubectl get ingress:

Name:             gke-my-ingress-1
Namespace:        default
Address:          <IP_ADDRESS>
Default backend:  default-http-backend:80 (<IP_ADDRESS>)
Rules:
  Host                    Path  Backends
  ----                    ----  --------
  mydomain.web.com
                          /   my-service:my-port (<IP_ADDRESS>:8080)
Annotations:
  ingress.kubernetes.io/target-proxy:                k8s-tp-default-gke-my-ingress-1--d8d0fcf4484c1dfd
  ingress.kubernetes.io/url-map:                     k8s-um-default-gke-my-ingress-1--d8d0fcf4484c1dfd
  kubernetes.io/ingress.global-static-ip-name:       gke-my-static-ip
  networking.gke.io/managed-certificates:            gke-my-certificate
  ingress.gcp.kubernetes.io/pre-shared-cert:         mcrt-e7dd5612-e6b4-42ca-91c9-7d9a86abcfb2
  ingress.kubernetes.io/forwarding-rule:             k8s-fw-default-gke-my-ingress-1--d8d0fcf4484c1dfd
  ingress.kubernetes.io/ssl-cert:                    mcrt-e7dd5612-e6b4-42ca-91c9-7d9a86abcfb2
  kubectl.kubernetes.io/last-applied-configuration:  {"apiVersion":"extensions/v1beta1","kind":"Ingress","metadata":{"annotations":{"kubernetes.io/ingress.global-static-ip-name":"gke-my-static-ip","networking.gke.io/managed-certificates":"gke-my-certificate"},"name":"gke-my-ingress-1","namespace":"default"},"spec":{"rules":[{"host":"mydomain.web.com","http":{"paths":[{"backend":{"serviceName":"my-service","servicePort":"my-port"},"path":"/"}]}}]}}

  ingress.kubernetes.io/backends:               {"k8s-be-30242--d8d0fcf4484c1dfd":"HEALTHY","k8s-be-30310--d8d0fcf4484c1dfd":"UNHEALTHY"}
  ingress.kubernetes.io/https-forwarding-rule:  k8s-fws-default-gke-my-ingress-1--d8d0fcf4484c1dfd
  ingress.kubernetes.io/https-target-proxy:     k8s-tps-default-gke-my-ingress-1--d8d0fcf4484c1dfd

1 Ответ

1 голос
/ 09 марта 2020

Работая с датчиком готовности и живости, добавляя successThreshold и FailureThreshold, я смог заставить свой вход работать. Это может быть связано с тем, что моему приложению требуется немного больше времени для запуска буфера.

        readinessProbe:
          httpGet:
            path: /app1/
            port: 8080
          periodSeconds: 5
          timeoutSeconds: 60 
          successThreshold: 1
          failureThreshold: 3
          initialDelaySeconds: 70      
        livenessProbe:
          httpGet:
            path: /app1/
            port: 8080
          periodSeconds: 5
          timeoutSeconds: 60
          successThreshold: 1
          failureThreshold: 3          
          initialDelaySeconds: 70  
...