通过 WebSocket 连接授权到远程 kubernetes api-server
Authorize over WebSocket connection to remote kubernetes api-server
查看相关问题 - 。
我已经能够使用 Pod exec API 成功建立 WebSocket 连接。但是我在本地主机上使用 kubectl proxy 来代表终端客户端处理授权。
下一步是能够将请求直接授权给 kubernetes API 服务器，这样就无需通过 kubectl proxy 路由流量。 Here's a discussion 在 python 社区中，他们已经能够将授权令牌发送到 api-服务器。但是我在 nodejs 中没有取得任何成功。我必须承认，我对 python 也不熟悉，无法充分理解讨论。
kubernetes 团队的人可以为我指明正确的方向吗？
谢谢
为了未来的流浪者....
虽然execAPI支持Authorizationheader，但是浏览器WebSocketAPI还不支持。所以我们的解决方案是 reverse-proxy 从我们的服务器 APIs。
事情是这样的...
client browser -wss-> GKE LB (SSL Termination) -ws-> site API (nodejs) -WSS & Authorization-> kube api-server exec API
所以回答我自己的问题，根据我的测试，GKE kubernetes 仅在 headers 中支持授权，所以如果你想，你需要反向代理通过浏览器连接到它。根据 this code，一些 Kubernetes 设置允许在查询字符串中使用令牌，但我在 GKE 上没有取得任何成功。如果您使用不同的集群主机，YMMY。我欢迎 kubernetes 团队对我的观察发表评论。
如果您只是为了授权问题来到这里，您可能会停止进一步阅读。
虽然还有更多的挑战需要克服，但有好消息也有坏消息……首先是好消息：
GKE Loadbalancer 自动处理 SSL 终止 even for WebSockets，因此您可以毫无问题地代理到 WS 或 WSS。
然后是坏消息：
GKE Loadbalancer 在 30 秒内强制终止所有连接，即使它们正在使用中！有解决方法，但它们要么 don't stay put, require you to deploy your own controller, or you need to use Ingress。这对终端 sessions 意味着 Chrome 将使用 1006 代码关闭客户端，即使当时的命令是 运行。
对于某些 WS 场景，在 1006 关闭时简单地重新连接可能是可以接受的，但是对于终端 session，这是一个 deal-breaker，因为您无法重新连接到之前的终端实例并且必须从一个新的开始。
目前我们已采取增加 GKE Loadbalancer 超时的方法。但最终我们计划部署我们自己的 Loadbalancer，它可以更好地处理这个问题。 Ingress 有 some issues，我们目前不想与之共存。
查看相关问题 -
我已经能够使用 Pod exec API 成功建立 WebSocket 连接。但是我在本地主机上使用 kubectl proxy 来代表终端客户端处理授权。
下一步是能够将请求直接授权给 kubernetes API 服务器，这样就无需通过 kubectl proxy 路由流量。 Here's a discussion 在 python 社区中，他们已经能够将授权令牌发送到 api-服务器。但是我在 nodejs 中没有取得任何成功。我必须承认，我对 python 也不熟悉，无法充分理解讨论。
kubernetes 团队的人可以为我指明正确的方向吗？
谢谢
为了未来的流浪者....
虽然execAPI支持Authorizationheader，但是浏览器WebSocketAPI还不支持。所以我们的解决方案是 reverse-proxy 从我们的服务器 APIs。
事情是这样的...
client browser -wss-> GKE LB (SSL Termination) -ws-> site API (nodejs) -WSS & Authorization-> kube api-server exec API
所以回答我自己的问题，根据我的测试，GKE kubernetes 仅在 headers 中支持授权，所以如果你想，你需要反向代理通过浏览器连接到它。根据 this code，一些 Kubernetes 设置允许在查询字符串中使用令牌，但我在 GKE 上没有取得任何成功。如果您使用不同的集群主机，YMMY。我欢迎 kubernetes 团队对我的观察发表评论。
如果您只是为了授权问题来到这里，您可能会停止进一步阅读。
虽然还有更多的挑战需要克服，但有好消息也有坏消息……首先是好消息：
GKE Loadbalancer 自动处理 SSL 终止 even for WebSockets，因此您可以毫无问题地代理到 WS 或 WSS。
然后是坏消息：
GKE Loadbalancer 在 30 秒内强制终止所有连接，即使它们正在使用中！有解决方法，但它们要么 don't stay put, require you to deploy your own controller, or you need to use Ingress。这对终端 sessions 意味着 Chrome 将使用 1006 代码关闭客户端，即使当时的命令是 运行。
对于某些 WS 场景，在 1006 关闭时简单地重新连接可能是可以接受的，但是对于终端 session，这是一个 deal-breaker，因为您无法重新连接到之前的终端实例并且必须从一个新的开始。
目前我们已采取增加 GKE Loadbalancer 超时的方法。但最终我们计划部署我们自己的 Loadbalancer，它可以更好地处理这个问题。 Ingress 有 some issues，我们目前不想与之共存。