错误 Service/502 minikube 中的错误网关
Bad Service/502 Bad Gateway in minikube
鉴于以下 K8s 资源(deployment/pods、服务、入口),当我在浏览器中访问 https://staging-micro.local/
时,我希望看到请求回显给我。我得到的是 502 Bad Gateway
。
# describe deployment (trunc. to show only containers)
Containers:
cloudsql-proxy:
Image: gcr.io/cloudsql-docker/gce-proxy:1.11
Port: <none>
Host Port: <none>
Command:
/cloud_sql_proxy
-instances=myproject:us-central1:project-staging=tcp:5432
-credential_file=/secrets/cloudsql/credentials.json
Environment: <none>
Mounts:
/secrets/cloudsql from cloudsql-instance-credentials-volume (ro)
adv-api-django:
Image: gcr.io/google_containers/echoserver:1.9
Port: 8000/TCP
Host Port: 0/TCP
Environment:
# describe service
Name: staging-adv-api-service
Namespace: staging
Labels: app=adv-api
platformRole=api
tier=backend
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app":"adv-api","platformRole":"api","tie...
Selector: app=adv-api-backend,platformRole=api,tier=backend
Type: LoadBalancer
IP: 10.103.67.61
Port: http 80/TCP
TargetPort: 8000/TCP
NodePort: http 32689/TCP
Endpoints: 172.17.0.14:8000,172.17.0.6:8000,172.17.0.7:8000
Session Affinity: None
External Traffic Policy: Cluster
Events: <none>
# describe ingress
Name: staging-api-ingress
Namespace: staging
Address: 10.0.2.15
Default backend: default-http-backend:80 (172.17.0.12:8080)
Rules:
Host Path Backends
---- ---- --------
staging-micro.local
/ staging-adv-api-service:http (172.17.0.14:8000,172.17.0.6:8000,172.17.0.7:8000)
请注意,我在主机 (运行 minikube) 的 /etc/hosts
中有条目 192.168.99.100 staging-micro.local
,这是正确的 minikube ip
。如果我删除该服务,点击 staging-micro.local/
会给出默认后端的 404 Not Found
响应。
我的期望是 Ingress 将主机名 staging-micro.local
和路径 /
映射到正在侦听端口 80 的服务。然后该服务将请求转发到 3 个服务之一在端口 8000 上选择容器。echoserver 容器正在侦听端口 8000,并且 returns 以请求为主体的 HTTP 响应。当然,这不是实际发生的情况。
最后,cloudsql-proxy
容器:此时不应该涉及它,但我将其包含在内是因为我想在存在边车容器时验证服务是否正常工作。然后我可以将 echoserver
换成我的主应用程序容器。我已经在删除 echoserver
的情况下进行了测试,并得到了相同的结果。
日志显示 echoserver
正在正常启动。
我无法找到任何更全面的 echoserver
文档,所以我不是 100% 了解它正在侦听的端口。
我猜你使用了错误的 echoserver:1.9
目标容器端口,因为它默认在 8080
端口上响应。看看这个example.
我已经在我的环境中测试了它,在 8080
端口上容器响应成功。
鉴于以下 K8s 资源(deployment/pods、服务、入口),当我在浏览器中访问 https://staging-micro.local/
时,我希望看到请求回显给我。我得到的是 502 Bad Gateway
。
# describe deployment (trunc. to show only containers)
Containers:
cloudsql-proxy:
Image: gcr.io/cloudsql-docker/gce-proxy:1.11
Port: <none>
Host Port: <none>
Command:
/cloud_sql_proxy
-instances=myproject:us-central1:project-staging=tcp:5432
-credential_file=/secrets/cloudsql/credentials.json
Environment: <none>
Mounts:
/secrets/cloudsql from cloudsql-instance-credentials-volume (ro)
adv-api-django:
Image: gcr.io/google_containers/echoserver:1.9
Port: 8000/TCP
Host Port: 0/TCP
Environment:
# describe service
Name: staging-adv-api-service
Namespace: staging
Labels: app=adv-api
platformRole=api
tier=backend
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app":"adv-api","platformRole":"api","tie...
Selector: app=adv-api-backend,platformRole=api,tier=backend
Type: LoadBalancer
IP: 10.103.67.61
Port: http 80/TCP
TargetPort: 8000/TCP
NodePort: http 32689/TCP
Endpoints: 172.17.0.14:8000,172.17.0.6:8000,172.17.0.7:8000
Session Affinity: None
External Traffic Policy: Cluster
Events: <none>
# describe ingress
Name: staging-api-ingress
Namespace: staging
Address: 10.0.2.15
Default backend: default-http-backend:80 (172.17.0.12:8080)
Rules:
Host Path Backends
---- ---- --------
staging-micro.local
/ staging-adv-api-service:http (172.17.0.14:8000,172.17.0.6:8000,172.17.0.7:8000)
请注意,我在主机 (运行 minikube) 的 /etc/hosts
中有条目 192.168.99.100 staging-micro.local
,这是正确的 minikube ip
。如果我删除该服务,点击 staging-micro.local/
会给出默认后端的 404 Not Found
响应。
我的期望是 Ingress 将主机名 staging-micro.local
和路径 /
映射到正在侦听端口 80 的服务。然后该服务将请求转发到 3 个服务之一在端口 8000 上选择容器。echoserver 容器正在侦听端口 8000,并且 returns 以请求为主体的 HTTP 响应。当然,这不是实际发生的情况。
最后,cloudsql-proxy
容器:此时不应该涉及它,但我将其包含在内是因为我想在存在边车容器时验证服务是否正常工作。然后我可以将 echoserver
换成我的主应用程序容器。我已经在删除 echoserver
的情况下进行了测试,并得到了相同的结果。
日志显示 echoserver
正在正常启动。
我无法找到任何更全面的 echoserver
文档,所以我不是 100% 了解它正在侦听的端口。
我猜你使用了错误的 echoserver:1.9
目标容器端口,因为它默认在 8080
端口上响应。看看这个example.
我已经在我的环境中测试了它,在 8080
端口上容器响应成功。