Kubernetes是一种非常智能的技术，但如果操作不当反而弄巧成拙。正如大多数智能化技术一样，它的智能程度取决于操作者。为了建立成功的Kubernetes团队，了解Kubernetes的健康状况至关重要。这里有五种方法，可以让工程师很好的识别出集群的潜在健康风险。
幸运的是，有一些现成的技术可以用来收集Kubernetes集群的日志、各种指标数据、事件和安全威胁，以帮助监视集群的健康状况。这些收集器从Kubernetes集群的各个部分收集数据，然后对数据进行整合，从而生成可视化的高级视图，并实时了解资源利用率，发现错误的配置和其他问题。
为所有的Pod设置CPU的使用上下限
在Kubernetes集群中，Pod的调度机制依赖于requests和limits这两个参数。我们可以为CPU和内存设置requests和limits。对于CPU，它的单位是millicores，1000m等于一个CPU核。requests是你认为容器至少需要多少CPU和内存，而limits则是允许容器使用的实际上限。
确保为所有的Pod设置了CPU requests。最佳实践是将其设置为一个CPU核或更少，如果需要更多的计算能力，则添加额外的Pod副本。需要注意的是，如果你的CPU requests过高，比如2000m，但是你只有1个CPU核可用，那么这个Pod将永远不会被调度到Kubernetes集群中。在第5点中，我将向你展示如何检查未被调度的Pod。
确保为所有的Pod设置了CPU limits。如上所述，这个参数限制了Pod使用CPU的上限，因此Kubernetes将不允许Pod使用比limits中定义的更多的CPU。也就是说，CPU是比较宽容的，因为它被认为是一种可压缩资源。如果你的Pod达到了CPU limits，它不会被终止，而是被节流，因此可能会出现性能下降。
为所有的Pod设置内存的使用上下限
确保为所有的Pod设置了memory requests：memory requests是你认为容器至少需要多少内存。像CPU一样，如果Pod的memory requests大于集群可以提供的内存，Kubernetes不会将Pod调度到Kubernetes集群中。
确保为所有的Pod设置了memory limits: memory limit是允许Pod使用内存的上限。与CPU不同，内存是不可压缩的，也不能进行节流。如果容器超过了它的内存限制，那么它将被终止。
审计资源配置
检查Kubernetes是否有不足或过剩的资源。如果Kubernetes集群中有剩余的可用CPU和内存，那么集群就处于消耗状态，并且消耗可能会持续增长。另一方面，如果CPU和内存的利用率接近100%，那么当集群需要水平扩展或有大量请求到来时，集群可能会遇到问题。
检查Pod的剩余容量，在Kubernetes中有一个指标数据“kube_node_status_allocatable”，这是Kubernetes在给定平均Pod资源利用率的情况下，对一个节点能容纳多少个Pod的估计。我们可以把剩余的Pod容量加起来，粗略地估计一下我们能在不遇到问题的情况下，集群还能扩大多少。
检查CPU总百分比使用率，CPU requests百分比使用率，CPU limits百分比使用率：CPU总百分比使用率可以告诉你现在使用了多少。CPU requests百分比使用率可以告诉你应该需要多少。CPU limits百分比使用率限制了你可以使用多少。
在下面的例子中，我们只使用了可用计算能力的2.5%。我们的剩余资源过多。相比之下，我们定义的CPU requests是46%，所以我们认为Pod需要的比Pod实际使用的多得多。我们的预估不够准确。
最后，我们的CPU limits总和是37%。由于这低于我们的CPU requests，这是一个错误的配置，我们需要重新检查我们的CPU limits。
检查内存的百分比使用率、memory requests百分比使用率，memory limits百分比使用率。就像CPU一样，查看是否有过多的剩余资源。只有3.8%的使用率告诉我们，我们确实资源过剩，但我们可以安全的进行水平扩展。
检查节点间的Pod分布
当我们查看Pod在集群中的分布情况时，我们希望得到一个大致均匀的分布。如果某些节点完全超载或负载不足，这可能是一个值得深入研究的问题。
以下是可能导致分布不均匀的一些事项：
- Node affinity，亲和性是一种Pod设置，它使Pod更喜欢具有某些属性的节点。例如，Pod可能需要在附加了GPU或SSD的节点上运行，或者Pod可能需要具有特定安全隔离或策略的节点。检查亲和性设置可以帮助分析不均匀分布的原因，并减少可能出现的问题。
Taints and tolerations，污点是亲和性的反义词。Pod不太喜欢被分配到这些被“污染”的节点上。如果你希望为特定的Pod保留节点，或者确保该节点上的Pod可以完全访问可用资源，那么可以使用此方法。
Limits and requests，查看limit和request的设置。这常常是Pod分布不均匀的原因，因此值得在本节的三个部分中提及。如果Kubernetes调度程序没有Pod需要什么的正确信息，那么调度程序在调度方面就会做得很差。
检查Pod是否处于不良状态
在Kubernetes环境中，Pod的状态时刻在变化，所以过度关注每一个被终止的Pod将会慢慢吞噬你的时间和理智。但是，下面的列表值得你关注，以确保达到期望的集群状态。
- Nodes not ready：节点可能由许多原因而陷入这种状态，但通常是因为内存或磁盘空间不足。
- Unscheduled pods：Pod通常以未调度状态结束，由于调度程序无法满足Pod所需要的CPU或内存请求。检查集群是否拥有足够的可用资源。
- Pods that failed to create：Pod在创建时失败，这通常是由于在Pod的启动脚本中缺少某些依赖项之类的镜像导致的。在这种情况下，回到起点，反复检查Pod的各种参数配置。
Container restarts：一些容器重新启动不值得关注，但是看到很多这样的情况，可能意味着Pod处于OOMKill(内存耗尽)状态。内存不足是Kubernetes集群中最常见的错误之一，可能是由镜像问题、下游依赖项问题或各种意外、限制和请求问题引起的。
这些集群健康最佳实践可以限制Kubernetes集群出现意外情况，并确保集群在扩展时不会遇到问题。还为你提供了一个很好的起点，以帮助你回答那些无定形的问题，如“我的Kubernetes集群是否健康?” 如果所有这些检查点都是绿色的，那么你的集群可能处于健康状态，你可以高枕无忧了。
