一、从节点分配分析服务高可用问题¶

图中有 4 个副本（Deployment Replicas: 4），分布在 5 个节点（Node01 - Node05）上。其中 Node01 有 3 个 Pod，Node02 有 1 个 Pod，Node04 有 2 个 Pod，Node03 和 Node05 没有分配 Pod。

这种分配方式对服务高可用存在一定风险：

• 节点负载不均：Node01 和 Node04 负载较重，一旦这些节点出现故障，会导致较多的 Pod 不可用，影响服务的整体可用性。例如，Node01 故障，就会有 3 个 Pod 无法工作，可能使服务出现明显的性能下降甚至部分功能不可用。
• 资源浪费：Node03 和 Node05 处于闲置状态，没有充分利用集群资源，在面对突发流量时，无法及时通过在这些节点上调度新的 Pod 来扩展服务，不利于保证服务高可用。

同样是 4 个副本，分别均匀分布在 Node01 - Node04 这 4 个节点上，Node05 没有分配 Pod。

这种分配对服务高可用较为有利：

• 负载均衡：每个节点承载一个 Pod，当单个节点出现故障时，只会影响一个副本，其他节点上的 Pod 仍能继续提供服务，将故障影响范围降到最低，维持服务的基本可用性。
• 故障容错：集群有一定的容错能力，即使有一个节点出现故障，剩余节点上的 Pod 可以通过负载均衡等手段，继续支撑服务，保障业务不中断。不过 Node05 闲置，存在一定资源浪费，如果能动态利用起来，高可用保障能力还能进一步提升 。

总体来说，在 Kubernetes 集群中，为了实现服务的高可用，应尽量保证 Pod 在节点上的均匀分配，避免单个节点负载过重，并充分利用集群资源，以应对节点故障等意外情况。

二、从机房分配分析服务高可用问题¶

由于故障节点 Node02 位于海淀机房，该机房只剩 1 个可用 Pod。此时，若海淀机房再出现其他问题，或者朝阳机房的 Pod 也出现故障，那么服务将面临不可用的风险。尽管跨机房部署提供了一定的容错能力，但副本分布不均衡使得在面对连续故障时，服务高可用性的保障能力大打折扣。

3 个 Pod 分布在两个机房（海淀机房 2 个，朝阳机房 1 个），实现了跨机房部署。这意味着如果其中一个机房因电力故障、网络中断等原因整体不可用，另一个机房的 Pod 仍能继续提供服务，保障业务不全面中断，有效提升了服务的高可用性。

三、从资源分配分析服务的性能问题¶

上面图片显示4 个 Pod 分别分布在 Node01、Node02、Node03 和 SSD01 上，其中 Node01、Node02、Node03 均标注 “性能不佳”。这意味着在这些性能不佳的节点上运行的 Pod，可能会因为节点自身的 CPU、内存、I/O 等资源瓶颈，导致服务响应变慢、吞吐量下降甚至出现故障。例如，当请求量增加时，性能不佳的节点可能无法及时处理 Pod 内的业务逻辑，造成服务延迟。

下面图片与上图节点分布相同，但 SSD02 标注 “资源浪费”。虽然 4 个 Pod 分布看似与之前相同，但标注变化暗示了资源分配不合理。在 Node01、Node02、Node03 性能不佳的情况下，SSD02 资源闲置，没有将其可用资源用于分担其他节点的负载，从而无法有效提升整体服务性能，可能导致服务整体的处理能力受限。

总体来说，为提升服务性能，应优化资源分配。一方面，排查并改善性能不佳节点的资源状况；另一方面，合理调度 Pod 到资源充足的节点，避免资源浪费，实现资源的均衡利用，以保障服务的高效稳定运行。

四、提升服务高可用性的方式与方法¶

1、针对需要性能的Pod优先选择有ssd=true标签的节点,如果没有在考虑部署到其它节点

2、某些Pod需要部署在ssd-true和type-physical的节点上,但是优先部署在ssd=true的节点上

3、同一个应用的不同副本或者同一个项目的应用尽量或必须不部署在同一个节点或者符合某个标签的一类节点上或者不同的区域

4、相互依赖的两个Pod尽量或必须部署在同一个节点上或者同一个域内