gpt4 book ai didi

.net - GKE 中的 dotnet 应用程序与 nginx 入口 Controller 和代理

转载 作者:行者123 更新时间:2023-12-02 11:32:51 25 4
gpt4 key购买 nike

我有一个在 Kestrel 上运行的 dotnet 应用程序,并将其托管在 GKE 上的 Linux 容器中。除了容器,我还运行一个 sidecar nginx 容器来代理它。我读到 Kestrel 的功能并不丰富,因此包括 nginx sidecar。

我遇到的问题是我一直收到 502 或 404 not found。不过,在重定向之后运行本地 curl 请求确实有效。

这从我的 nginx -> Kestrel 返回了正确的响应

curl -vL "http://127.0.0.1"

通过公共(public) lb 从外部命中它,

response 404 (backend NotFound), service rules for [ /index.html ] non-existent
``

This is my nginx.conf

worker_processes 1;

events { worker_connections 1024; }

http {

sendfile on;

upstream web-api {
server 127.0.0.1:5000;
}

server {
listen 80;
server_name $hostname;

location /nginx-health {
return 200 "healthy\n";
}

location / {
proxy_pass http://web-api;
proxy_redirect off;
proxy_http_version 1.1;
proxy_cache_bypass $http_upgrade;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection keep-alive;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $server_name;
}
}
}

我的入口

Name:             app
Namespace: app
Address: 34.120.149.155
Default backend: default-http-backend:80 (<none>)
TLS:
app-tls terminates external_url
Rules:
Host Path Backends
---- ---- --------
<external_url>
/ app:80 (10.108.21.149:80)
Annotations:
certmanager.k8s.io/cluster-issuer: letsencrypt
ingress.kubernetes.io/forwarding-rule: k8s2-fr-6bwo4q66-app-2jv0uft5
ingress.kubernetes.io/https-forwarding-rule: k8s2-fs-6bwo4q66-app-2jv0uft5
ingress.kubernetes.io/https-target-proxy: k8s2-ts-6bwo4q66-app-2jv0uft5
ingress.kubernetes.io/target-proxy: k8s2-tp-6bwo4q66-app-2jv0uft5
ingress.kubernetes.io/url-map: k8s2-um-6bwo4q66-app-2jv0uft5
meta.helm.sh/release-name: app
ingress.kubernetes.io/backends: {"k8s-be-30587--b22f31f8e3f41440":"HEALTHY","k8s-be-31967--b22f31f8e3f41440":"HEALTHY"}
ingress.kubernetes.io/ssl-cert: k8s2-cr-6bwo4q66-rn3hwilrxhwvg79m-506e1c732112861c
ingress.kubernetes.io/static-ip: k8s2-fr-6bwo4q66-labs-createstudio-createdataservice-2jv0uft5
meta.helm.sh/release-namespace: app

我的服务

Name:                     app
Namespace: app
Labels: app.kubernetes.io/instance=app
app.kubernetes.io/managed-by=Helm
app.kubernetes.io/name=app
app.kubernetes.io/version=0.1.0
helm.sh/chart=app-0.1.0
Annotations: beta.cloud.google.com/backend-config: {"ports": {"80":"app-config"}}
meta.helm.sh/release-name: app
meta.helm.sh/release-namespace: app
Selector: app.kubernetes.io/instance=app,app.kubernetes.io/name=app
Type: NodePort
IP: 10.181.45.135
Port: http 80/TCP
TargetPort: 80/TCP
NodePort: http 30587/TCP
Endpoints: 10.108.21.149:80
Session Affinity: None
External Traffic Policy: Cluster
Events: <none>

我将所有名称/命名空间/网址更新为更通用的内容,这样我就不会在我的应用程序中暴露太多信息。

我有一种感觉,这是因为主机上的入口路径只是 /

我还注意到,当从外部访问 nginx 时,我得到一个 301 重定向,它代理到 Kestrel 服务器。在那之后,Kestrel 将 301 返回给 nginx,我觉得这就是循环所在的地方。即当Kestrel返回response时,它再次通过外部URL出去,将请求从外部发回给nginx。希望这是有道理的。

希望任何人都可以阐明这一点。干杯!

最佳答案

由于 GKE ingress controller 可以充当您的反向代理(例如提供 SSL 终止),因此无需添加 nginx sidecar,您可以将请求直接路由到容器应用程序。

关于.net - GKE 中的 dotnet 应用程序与 nginx 入口 Controller 和代理,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/64186353/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com