Kubeflow UI https之暴露

最近接了任务，希望能把Kubeflow的GUI集成在我们的产品中。

玩了玩Kubeflow, 看了看它的UI，确实非常之简陋：

另外，这个UI以http发布的，问题来了，我们的GUI是https的，要知道在https的页面中是没有办法发出http的请求的！

Google了下，最基本的方案是在在kubeflow UI前放一个https的proxy，比如nginx.

恰好我们的产品是基于k8s的，有一个nginx ingress controller可以用，感觉没什么坑哈。

大概看了看kubeflow GUI的pod和service：ambassador(https://blog.getambassador.io/case-study-kubeflow-7e666fdcd52e)

ambassador其实也是个proxy，是基于Envoy，据说这个Envoy是要替代nginx的，很牛的。

OK， 按部就班的创建ingress，把https://ip:8443/kubeflow重定向到Service ambassador的80端口，完成后试试，居然报了个426, 426（https://httpstatuses.com/426）表示服务器拒绝浏览器使用当前协议发送的请求。懵逼了，难道是因为nginx把HTTPS请求直接重定向到了80端口，不应该啊，赶紧google。

原来这个protocol指的是HTTP的version，而罪魁祸首是nginx。具体来讲是：

• browser使用HTTP 1.1发送request到nginx
• nginx使用HTTP 1.0（https://serverfault.com/questions/442960/nginx-ignoring-clients-http-1-0-request-and-respond-by-http-1-1）把request重定向到ambassador（Envoy）
• Envoy受不了HTTP 1.0，要求升级为1.1，所以抛出426

那好办了，让nginx重定向时使用HTTP1.1，在nginx的router rule中加入：

        proxy_http_version 1.1;
        proxy_set_header Connection "";

成功！