【发布时间】：2020-05-01 07:27:03
【问题描述】：
查看 Kubernetes 资源的变化时，幕后究竟发生了什么？ http 是否突然变为wss 连接？
为了解决对 kube-apiserver 的请求过多的问题，我将一些代码重写为我认为更像是操作员模式的代码。
在我们的多租户微服务架构中，所有服务都使用同一个库来查找特定于租户的数据库的连接详细信息。连接详细信息保存在与应用程序相同的命名空间内的机密中。每个租户数据库都有自己的秘密。
因此，在每次调用时，都会读取并解析所有带有正确标签的秘密，以获取必要的数据库连接详细信息。我们有大约 400 个服务/pod...
我的想法：不要在每次调用时读取所有秘密，而是创建一个缓存并在每次通过观察者更改相关秘密时更新缓存。
我的担忧：我只是用同样昂贵的 websocket 替换 http 请求吗？据我了解，我现在将为每个服务/pod 建立一个开放的 websocket 连接，仍然是 400 个开放连接。
最好有一个代理服务来监视机密（kube-apiserver 请求），然后所有服务都查询该服务以获取连接详细信息（内网请求，kube-apiserver 不相关）？
【问题讨论】：
-
我猜，您还可以将 master 添加到您的集群并扩展 etcd。这样对 apiserver 的请求将分布在多个主机上。
-
好主意。不幸的是，我们在 GKE 上。
-
在这种情况下，控制平面应该自动扩展。我猜节点数量和主节点数量之间存在某种比例。可能您可能会尝试切换到区域集群或使用更轻量级的节点而不是几个大节点。 cloud.google.com/blog/products/gcp/…learnk8s.io/kubernetes-node-size
-
进一步研究表明，GKE master 目前只能垂直调整大小，因此在 GKE 中获得三个 master 节点的唯一选择是区域集群。然而，越来越多的节点可能会帮助您获得更强大的主控。 stackoverflow.com/questions/50425198/…
-
谢谢。这正是我们的问题。我们正在使用区域集群（以节省成本......）。现在我们正在努力再次移动集群以处理这种情况。但是，我的帖子也是关于一般限制对 apiserver 的调用的想法。或者 apiserver 是否应该能够轻松处理所有这些请求？