1

我正在为多个租户设计一个具有单个 kubernetes 部署的系统，但每个客户有多个数据库、队列等。任何无状态的东西都是共享的，任何有状态的东西对于每个租户都是分开的。根据请求主机（tenant1.company.com 或tenant2.company.com），代码将连接到相应的数据库和队列。

在这种情况下，我的 pod 设计为为多个租户工作，应该如何设计就绪探针？

我可以想到以下选项，但似乎都不正确：

  1. 连接所有的数据库和队列，看看是否准备好了： 缺点：这会导致 pod 没有准备好，即使一个资源宕机了。
  2. 连接到任何一个数据库和队列： 缺点：并没有真正检查所有探测器的准备情况。
  3. 根本没有任何就绪探测。

感觉如果我在资源级别进行分离以支持多个租户（这是一个 B2B 多租户，需要时间和精力来加入新租户），我还需要在 Kubernetes 部署级别进行分离。

这是标准方法吗？要么在所有级别上完全分离，要么拥有一个具有相同共享资源的统一系统？如果没有，我该如何设计就绪探针？

4

1 回答 1

1

据我了解，您正在尝试扩展 Kubernetes Pod 的就绪探测以反映特定租户的应用程序运行状况。不幸的是，Readiness 探针并不是为此而设计的。

Kubernetes 就绪探测（甚至是新特性Pod Ready++）的唯一目的是反映 Pod 服务流量的特定能力。Deployment 和 StatefulSet 控制器会在滚动更新过程中考虑 Pod 就绪状态。

如果您将就绪探测设置为依赖于 Pod 组件的外部或网络端点连接，您可以阻止整个更新机制。使用 Readiness probe 的正确方法是只检查 Pod 内部组件的状况。

Kubernetes 文档页面：

对于某些仅包含一个 Pod 的简单应用程序或微服务，它也可能反映应用程序的状态。但通常，应用程序架构要复杂得多，包含许多部分，每个部分都可能有依赖关系。

有时在前端应用程序www.example.com/healthz（

在 Kubernetes 世界中，组件/应用程序通常是平衡到一个或多个 Pod 的流量的服务。因此，如果相应 Service 后面的至少一个 Pod 处于 Ready 状态，则该组件是健康的。Service 背后的 Ready Pod 数量更多地反映了 App 的性能，而不是 App 的运行状况。

根据我想象您的应用程序设计的能力：

  • 我将使用几个 Ingress 对象，使流量被转发到租户的Namespace中每个租户前端的专用端口。所有其他租户的资源也部署在那里。
  • 我会将所有共享组件放入额外的命名空间中，比如“shared/static/commmon/stateless”，并在每个租户的命名空间中创建ExternalName 服务以访问它们（如果我将在特定 URL 路径上提供此内容，则为 Ingress）。
  • 我还会为应用程序+集群监控部署一些解决方案。

这样，如果某些租户需要更多资源，您就可以轻松扩展应用程序部分。
为了管理部署，我会使用Helm 图表。这样我就可以轻松地再部署一个租户或删除/更新现有的租户。

有许多不同的解决方案可以监控应用程序的运行状况、性能、收集指标和日志并在满足某些条件时采取行动。这只是最流行的解决方案的简短列表：

PS：如果您想为租户实现断路器，Istio 具有内置功能。

于 2020-04-14T17:12:36.447 回答