多租户系统中的 Kubernetes Readiness Probe
Kubernetes Readiness Probe in multi-tenant system
我正在为多个租户设计一个具有单个 kubernetes 部署的系统，但每个客户有多个数据库、队列等。任何无状态的东西都是共享的，任何有状态的东西对于每个租户都是分开的。根据请求主机（tenant1.company.com 或 tenant2.company.com），代码将连接到相应的数据库和队列。
在这种情况下，我的 pod 是为多个租户设计的，应该如何设计就绪探测器？
我能想到以下选项，none 似乎是正确的：
- 连接到所有数据库和队列，看看它们是否准备就绪：
缺点：这会导致pod即使有一个也没有准备好
资源已关闭。
- 连接到任何一个数据库和队列：缺点：没有真正检查所有探测器的准备情况。
- 根本没有任何就绪探测。
感觉如果我在资源级别进行分离以支持多个租户（这是 B2B 多租户，需要时间和精力来加入新租户），我还需要在 Kubernetes 部署级别进行分离。
这是标准方法吗 - 要么在所有级别完全分离，要么拥有一个具有相同共享资源的统一系统？如果没有，我该如何设计就绪探针？
据我了解，您正在尝试扩展 Kubernetes Pod 的就绪探测以反映特定租户的应用程序运行状况。不幸的是，Readiness 探测器并非为此而设计。
Kubernetes 就绪探测（即使是新功能 Pod Ready++）的唯一目的是反映特定 Pod 服务流量的能力。 Deployment 和 StatefulSet 控制器会在滚动更新过程中考虑 Pod 就绪状态。
如果将就绪探测器设置为依赖于 Pod 组件外部或网络端点连接，则可以阻止整个更新机制。
Readiness probe 的正确使用方法是只检查 Pod 内部组件的状态。
Kubernetes 文档页面：
对于某些只包含一个Pod的简单应用或微服务，它也可能反映应用的状态。但通常情况下，应用程序架构要复杂得多，包含许多部分，每个部分都可能有依赖关系。
有时，在反映整个应用程序健康状况的前端应用程序 (www.example.com/healthz) 中创建自己的健康检查循环会更便宜、更简单，同时考虑到所有组件的状态及其依赖性，或者收集和汇总JSON 来自其他组件的状态。
在 Kubernetes 世界中，components/apps 通常是将流量平衡到一个或多个 Pods 的服务。因此，如果相应服务后面的至少一个 Pod 处于就绪状态，则组件是健康的。服务背后的就绪数 Pods 更能说明应用程序性能，而不是应用程序运行状况。
根据我对您的 App 设计的想象能力：
- 我会使用多个 Ingress 对象，使流量转发到租户 Namespace 中每个租户的专用前端。所有其他租户的资源也部署在那里。
- 我会把所有共享组件放在额外的命名空间中，比方说 "shared/static/commmon/stateless" 并在每个租户的命名空间中创建 ExternalName service 以访问它们（或者 Ingress，如果我将在特定 URL路径）。
- 我也会部署一些应用+集群监控的解决方案。
如果某些租户需要更多资源，您可以通过这种方式轻松扩展应用程序部分。
要管理部署，我会使用 Helm charts。这样我就可以轻松地再部署一个租户或 remove/update 现有租户。
有许多不同的解决方案可用于监控应用程序运行状况、性能、收集指标和日志并在满足特定条件时采取措施。这只是最流行的解决方案的简短列表：
- Metrics Framework (Java)
- Prometheus
- EFK stack
- Jaeger
- Istio
- Weave Scope
- Datadog Realtime Kubernetes Monitoring
- Cloud 特定工具，例如 Google Cloud 的操作套件（以前称为 Stackdriver）
- 还有很多...
PS：如果您想为租户实施断路器，Istio 有 built-in functionality.
我正在为多个租户设计一个具有单个 kubernetes 部署的系统，但每个客户有多个数据库、队列等。任何无状态的东西都是共享的，任何有状态的东西对于每个租户都是分开的。根据请求主机（tenant1.company.com 或 tenant2.company.com），代码将连接到相应的数据库和队列。
在这种情况下，我的 pod 是为多个租户设计的，应该如何设计就绪探测器？
我能想到以下选项，none 似乎是正确的：
- 连接到所有数据库和队列，看看它们是否准备就绪： 缺点：这会导致pod即使有一个也没有准备好 资源已关闭。
- 连接到任何一个数据库和队列：缺点：没有真正检查所有探测器的准备情况。
- 根本没有任何就绪探测。
感觉如果我在资源级别进行分离以支持多个租户（这是 B2B 多租户，需要时间和精力来加入新租户），我还需要在 Kubernetes 部署级别进行分离。
这是标准方法吗 - 要么在所有级别完全分离，要么拥有一个具有相同共享资源的统一系统？如果没有，我该如何设计就绪探针？
据我了解，您正在尝试扩展 Kubernetes Pod 的就绪探测以反映特定租户的应用程序运行状况。不幸的是，Readiness 探测器并非为此而设计。
Kubernetes 就绪探测（即使是新功能 Pod Ready++）的唯一目的是反映特定 Pod 服务流量的能力。 Deployment 和 StatefulSet 控制器会在滚动更新过程中考虑 Pod 就绪状态。
如果将就绪探测器设置为依赖于 Pod 组件外部或网络端点连接，则可以阻止整个更新机制。 Readiness probe 的正确使用方法是只检查 Pod 内部组件的状态。
Kubernetes 文档页面：
对于某些只包含一个Pod的简单应用或微服务，它也可能反映应用的状态。但通常情况下，应用程序架构要复杂得多，包含许多部分，每个部分都可能有依赖关系。
有时，在反映整个应用程序健康状况的前端应用程序 (www.example.com/healthz) 中创建自己的健康检查循环会更便宜、更简单，同时考虑到所有组件的状态及其依赖性，或者收集和汇总JSON 来自其他组件的状态。
在 Kubernetes 世界中，components/apps 通常是将流量平衡到一个或多个 Pods 的服务。因此，如果相应服务后面的至少一个 Pod 处于就绪状态，则组件是健康的。服务背后的就绪数 Pods 更能说明应用程序性能，而不是应用程序运行状况。
根据我对您的 App 设计的想象能力：
- 我会使用多个 Ingress 对象，使流量转发到租户 Namespace 中每个租户的专用前端。所有其他租户的资源也部署在那里。
- 我会把所有共享组件放在额外的命名空间中，比方说 "shared/static/commmon/stateless" 并在每个租户的命名空间中创建 ExternalName service 以访问它们（或者 Ingress，如果我将在特定 URL路径）。
- 我也会部署一些应用+集群监控的解决方案。
如果某些租户需要更多资源，您可以通过这种方式轻松扩展应用程序部分。
要管理部署，我会使用 Helm charts。这样我就可以轻松地再部署一个租户或 remove/update 现有租户。
有许多不同的解决方案可用于监控应用程序运行状况、性能、收集指标和日志并在满足特定条件时采取措施。这只是最流行的解决方案的简短列表：
- Metrics Framework (Java)
- Prometheus
- EFK stack
- Jaeger
- Istio
- Weave Scope
- Datadog Realtime Kubernetes Monitoring
- Cloud 特定工具，例如 Google Cloud 的操作套件（以前称为 Stackdriver）
- 还有很多...
PS：如果您想为租户实施断路器，Istio 有 built-in functionality.