我的用例需要通过SSL,因此我们无法在OpenShift中本地使用基于路径的路由。我们的下一个最佳解决方案是设置一个内部NGINX代理,以将流量从路径路由到另一个Web UI的OpenShift路线。这样做时我会遇到错误。
这是我简化的Nginx配置:
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /etc/nginx/nginx.pid;
include /usr/share/nginx/modules/*.conf;
events {
worker_connections 1024;
}
http {
upstream app1-ui-1-0 {
server app1-1-0.192.168.99.100.nip.io:443;
}
server {
listen 8443 ssl default_server;
location /apps/app1/ {
proxy_pass https://app1-ui-1-0/;
}
}
}
我的app1路由配置如下:
apiVersion: v1
kind: Route
metadata:
name: app1-1-0
spec:
host: app1-1-0.192.168.99.100.nip.io
to:
kind: Service
name: app1-1-0
tls:
insecureEdgeTerminationPolicy: Redirect
termination: passthrough
当我击中
https://app1-1-0.192.168.99.100.nip.io
时,该应用程序正常。当我击中NGINX代理路线URL(
https://proxier-1-0.192.168.99.100.nip.io
(时,它会正确加载Nginx的标准index.html位置。但是,当我尝试通过
https://proxier-1-0.192.168.99.100.nip.io/apps/apps1/
通过代理点击App1时,我会收到以下OpenShift错误:Application is not available The application is currently not serving requests at this endpoint. It may not have been started or is still starting.
通过日志和测试,我知道该请求已进入/apps/app1/
位置块,但它永远不会到达App1的Nginx。我还确认此错误来自App1的路由器或服务,但是由于没有日志,我不知道该如何进行故障排除。有什么想法吗?
当您想向在同一openshift群集中运行的其他应用程序请求时,在大多数情况下,正确的解决方案是使用内部DNS。
用SDN开放旋转,该SDN可以在豆荚之间启用通讯。这比通过其路线通信到另一个POD更有效,因为这通常会在再次击中OpenShift路由器之前将请求返回到公共Internet上,并通过SDN转发。
可以达到服务<service>.<pod_namespace>.svc.cluster.local
,在您的情况下,该服务可以通过server apps1-1-0.myproject.svc.cluster.local
路由通常应用于将外部流量路由到集群中。
有关网络的更多详细信息,请参见OpenShift文档
根据上面的评论,我最终放弃了路线,并在Nginx上游引用了该服务的内部DNS:
upstream finder-ui-1-0 {
server apps1-1-0.myproject.svc.cluster.local:443;
}
这适合我的需求,效果很好。