Kubernetes Ingress(GCE)总是返回502错误
我想在GCE Kubernetes中设置Ingress。但是,当我访问的入口定义的IP地址和路径的组合,我不断收到以下502错误:Kubernetes Ingress(GCE)总是返回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
您的后端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。
非常感谢这个答案 - 我遇到了同样的问题,并且您提供的信息能够确定'readinessProbe'没有为该吊舱配置,因此它被标记为UNHEALTHY – GrandVizier
问题确实是一项健康检查,对我的应用程序来说似乎是“随机的”,我使用基于名称的虚拟主机将来自入口的代理请求通过域反向转换为两个单独的后端服务。两者都使用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转嫁/
)。
我有同样的问题,并且在启用livenessProbe
以及readinessPorbe
后,它仍然存在。 它变成了这是与基本身份验证。我已将基本身份验证添加到livenessProbe
和readinessPorbe
,但事实证明GCE HTTP(S)负载平衡器没有配置选项。
似乎有是几另一种问题的有太多,例如将容器端口设置为8080,将服务端口设置为80不能与GKE入口控制器一起工作(但我不能清楚地指出问题所在)。广而言之,在我看来,只有很小的可见度,运行您自己的入口容器在可见度方面是更好的选择。
我拿起Traefik我的项目,它的工作开箱,我希望能够让我们的加密集成。我必须对Traefik清单作出的唯一更改是调整服务对象以禁止从群集外访问UI,并通过外部负载平衡器(GCE TCP LB)公开我的应用程序。而且,Traefik更加原生于Kubernetes。我尝试了Heptio Contour,但是有些东西并没有起作用(下一次新版本出来时,它会发挥作用)。
我有同样的问题。事实证明,我必须等待入境前几分钟才能验证服务运行状况。如果有人要像readinessProbe
和linvenessProbe
相同,完成所有的步骤,只是确保您的入口指向要么是一个NodePort
服务,并等待几分钟,直到黄色警告图标变成绿色的。另外,请检查StackDriver上的日志以更好地了解发生了什么。我的readinessProbe
和livenessProbe
位于/login
,对于gce
类。所以我不认为它必须在/healthz
上。
你可以执行'kubectl describe ep -n dpl-staging dpl-identity'吗? –
@JanosLenart:我已经更新了我的回答并提供了所需信息。非常感谢您的帮助。 – Moon