Сбой проверки работоспособности для входящего трафика, созданного на GKE

Я создаю балансировщик нагрузки для consul ui на GKE, используя ingress со следующими конфигурациями

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: public-apis
spec:
  rules:
    - host: consul.example.com
      http:
        paths:
          - path: /ui/
            pathType: Prefix
            backend:
              serviceName: hashicorp-consul-ui
              servicePort: http

Служба hashicorp-consul-ui - это служба типа clusterIP.

Также я создаю следующий backendConfig

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: consul-ui-backendconfig
spec:
  healthCheck:
    type: HTTP
    requestPath: /v1/health/state/failed
    port: 80

Я добавляю следующую аннотацию в службу clusterIP hashicorp-consul-ui

'cloud.google.com/backend-config': '{"ports": {"80":"consul-ui-backendconfig"}}'

Этот backendConfig создает проверку работоспособности для серверной службы, созданной входом, эта конечная точка возвращает 200. Но проверка работоспособности не выполняется, и вход находится в неработоспособном состоянии.

Я включил вход в HealthCheck и получаю следующий журнал в NEG

healthCheckProbeResult: {
   detailedHealthState: "TIMEOUT"    
   healthCheckProtocol: "HTTP"    
   healthState: "UNHEALTHY"    
   ipAddress: "10.24.1.30"    
   previousDetailedHealthState: "UNKNOWN"    
   previousHealthState: "UNHEALTHY"    
   probeCompletionTimestamp: "2021-02-14T03:31:43.337063261Z"    
   probeRequest: "/v1/health/state/failed"    
   probeResultText: "HTTP response: , Error: Connection refused"    
   probeSourceIp: "35.191.9.211"    
   responseLatency: "0.001265s"    
   targetIp: "10.24.1.30"    
   targetPort: 80    
}

Кроме того, не знаю, почему я получил этот журнал только один раз, разве я не должен получать эти журналы через регулярные промежутки времени?

Кроме того, может ли кто-нибудь рассказать мне, как я могу исправить эту проблему HealthCheck?


person Avinash Dhinwa    schedule 14.02.2021    source источник
comment
Не могли бы вы предоставить результат выполнения команды kubectl describe pod <podname>. Также убедитесь, что у вас есть необходимые правила брандмауэра для работоспособности. чеки на работу.   -  person Dylan    schedule 17.02.2021
comment
@Dylan да, правила брандмауэра уже присутствуют. Контроллер входящего трафика gke делает все, что я думаю, при создании балансировщика нагрузки. Извините, сейчас я удалил все ресурсы, но модуль исправен и обслуживает запрос через переадресацию портов.   -  person Avinash Dhinwa    schedule 22.02.2021


Ответы (1)


Consul API / UI прослушивает порт 8500 по умолчанию или 8501, если в кластере включен TLS.

Измените вход servicePort на порт 8500. Это должно решить проблему с подключением.

---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: public-apis
spec:
  rules:
    - host: consul.example.com
      http:
        paths:
          - path: /ui/
            pathType: Prefix
            backend:
              serviceName: hashicorp-consul-ui
              servicePort: 8500
person Blake Covarrubias    schedule 19.02.2021
comment
извините, забыл упомянуть об этом, но сервис отображает порт 8500 на 80 - person Avinash Dhinwa; 22.02.2021