当LoadBalancer在GKE上工作时,为什么Ingress会失败?

时间:2017-09-12 02:27:59

标签: kubernetes google-kubernetes-engine kubernetes-health-check

由于健康检查失败,我无法让Ingress在GKE上工作。我已经尝试了所有我能想到的调试步骤,包括:

  • 已确认我的任何配额都不低
  • 已验证我的服务可从群集中访问
  • 已验证我的服务是在k8s / GKE负载均衡器后面运行的。
  • 验证了healthz支票在Stackdriver日志中传递

...我很喜欢有关如何调试或修复的任何建议。详情如下!

我在GKE上设置了LoadBalancer类型的服务。通过外部IP工作得很好:

apiVersion: v1
kind: Service
metadata:
  name: echoserver
  namespace: es
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
  type: LoadBalancer
  selector:
    app: echoserver

然后我尝试在同一服务之上设置Ingress:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: echoserver-ingress
  namespace: es
  annotations:
    kubernetes.io/ingress.class: "gce"
    kubernetes.io/ingress.global-static-ip-name: "echoserver-global-ip"
spec:
  backend:
    serviceName: echoserver
    servicePort: 80

Ingress被创建,但它认为后端节点是不健康的:

$ kubectl --namespace es describe ingress echoserver-ingress | grep backends
  backends:     {"k8s-be-31102--<snipped>":"UNHEALTHY"}

在GKE Web控制台中检查Ingress后端的状态,我看到同样的事情:

0 of 3 healthy

健康检查详细信息按预期显示:

health check details

...并且从我的群集中的一个pod中,我可以成功调用该服务:

# curl  -vvv echoserver  2>&1 | grep "< HTTP"
< HTTP/1.0 200 OK

# curl  -vvv echoserver/healthz  2>&1 | grep "< HTTP"
< HTTP/1.0 200 OK

我可以通过NodePort解决该服务:

# curl  -vvv 10.0.1.1:31102  2>&1 | grep "< HTTP" 
< HTTP/1.0 200 OK

(不言而喻,因为我在步骤1中设置的Load Balancer服务导致网站运行正常。)

我还看到传递Stackdriver日志的healthz个检查:

enter image description here

关于配额,我检查并看到我只使用了30个后端服务中的3个:

$ gcloud compute project-info describe | grep -A 1 -B 1  BACKEND_SERVICES
- limit: 30.0
  metric: BACKEND_SERVICES
  usage: 3.0

3 个答案:

答案 0 :(得分:1)

几周前有一个类似的问题。为我修复的是在服务描述中添加NodePort,以便Google Cloud Loadbalancer可以探测此NodePort。对我有用的配置:

apiVersion: v1
kind: Service
metadata: 
  name: some-service
spec: 
  selector: 
    name: some-app
  type: NodePort
  ports: 
    - port: 80
      targetPort: 8080
      nodePort: 32000
      protocol: TCP

入口可能需要一些时间才能解决这个问题。你可以重新创建入口以加快速度。

答案 1 :(得分:0)

您已将超时值配置为1秒。也许将其增加到5秒将解决问题。

答案 2 :(得分:0)

我遇到了这个问题,最终遇到https://stackoverflow.com/a/50645953/9276,这使我着眼于防火墙设置。可以肯定的是,防火墙规则中未启用我添加的最后几个NodePort服务,因此从入口指向它们的运行状况检查都失败了。手动将新的主机端口添加到防火墙规则中对我来说已解决了此问题。

但是,与链接的答案不同,我没有使用无效的证书。我猜还有其他错误或怪异状态可能导致此行为,但我还没有找到规则停止自动管理的原因。

可能无关紧要,在我们的质量保证环境中,我只是生产环境,没有这个问题,所以可能有GCP项目级别的设置在起作用。