Kubernetes Ingress（GCE）总是返回502错误

Question

我想在GCE Kubernetes中设置Ingress。但是，当我访问的入口定义的IP地址和路径的组合，我不断收到以下502错误：

---

这里是我得到的，当我运行：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 

我认为问题是dpl-identity:4000 (<none>)。我不应该看到dpl-identity服务的IP地址而不是<none>？

这里是我的服务描述：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. 

而且，这里是执行的结果是：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. 

---

这里是我的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 

Answer 1

您的后端k8s-be-32396--5fc40252fadea594显示为"UNHEALTHY"。

如果后端处于UNHEALTHY状态，Ingress将不会转发流量，这会导致您看到的502错误。

它会被标记为“不健康”，因为它没有通过它的健康检查，您可以检查k8s-be-32396--5fc40252fadea594的健康检查设置，看它们是否适合您的吊舱，可能是投票未返回200响应的URI或端口。您可以在Compute Engine> Health Checks下找到这些设置。

如果它们是正确的，那么浏览器和容器之间会有很多步骤可能会错误地传递流量，您可以尝试kubectl exec -it PODID -- bash（或者如果您使用的是Alpine，则为灰），然后尝试curl-localhost以查看容器正在按照预期做出响应，如果它正确并且健康检查配置正确，那么这将缩小问题的范围，以便可能与您的服务相关，然后您可以尝试将服务从NodePort类型更改为LoadBalancer，然后查看是否击中直接从您的浏览器服务IP。

Answer 2

问题确实是一项健康检查，对我的应用程序来说似乎是“随机的”，我使用基于名称的虚拟主机将来自入口的代理请求通过域反向转换为两个单独的后端服务。两者都使用Lets Encrypt和kube-lego进行了保护。我的解决方案是对共享入口的所有服务进行健康检查的路径标准化，并在我的deployment.yml文件中声明readinessProbe和livenessProbe配置。

我面临着谷歌云计算集群节点版本1.7.8这个问题，并发现这个问题是密切类似于什么我经历： * https://github.com/jetstack/kube-lego/issues/27

我使用gce和kube-lego和我的后端服务的健康检查是对/kube-lego在/healthz上。它出现不同的健康检查路径与gce ingress的原因可能因此它可能是值得更新后端服务相匹配的/healthz模式等等都使用相同的（或在Github的问题一个评论者表示，他们更新KUBE-LEGO转嫁/）。

Answer 3

我有同样的问题，并且在启用livenessProbe以及readinessPorbe后，它仍然存在。 它变成了这是与基本身份验证。我已将基本身份验证添加到livenessProbe和readinessPorbe，但事实证明GCE HTTP（S）负载平衡器没有配置选项。

似乎有是几另一种问题的有太多，例如将容器端口设置为8080，将服务端口设置为80不能与GKE入口控制器一起工作（但我不能清楚地指出问题所在）。广而言之，在我看来，只有很小的可见度，运行您自己的入口容器在可见度方面是更好的选择。

我拿起Traefik我的项目，它的工作开箱，我希望能够让我们的加密集成。我必须对Traefik清单作出的唯一更改是调整服务对象以禁止从群集外访问UI，并通过外部负载平衡器（GCE TCP LB）公开我的应用程序。而且，Traefik更加原生于Kubernetes。我尝试了Heptio Contour，但是有些东西并没有起作用（下一次新版本出来时，它会发挥作用）。

Answer 4

我有同样的问题。事实证明，我必须等待入境前几分钟才能验证服务运行状况。如果有人要像readinessProbe和linvenessProbe相同，完成所有的步骤，只是确保您的入口指向要么是一个NodePort服务，并等待几分钟，直到黄色警告图标变成绿色的。另外，请检查StackDriver上的日志以更好地了解发生了什么。我的readinessProbe和livenessProbe位于/login，对于gce类。所以我不认为它必须在/healthz上。