49） 检查Kubernetes集群是否健康
本文介绍在创建Kubernetes集群时能检查出异常任务。
1- 所有的pod中设置 CPU 的requests和limits
requests和limits是k8s的一种机制，用来给pods 自动分配CPU和内存使用量这样的可用资源 。
- CPU 是用毫核来定义的， 所以1000毫核等于1核。
- requests是预期给定容器所需要的资源使用量
- limits是一个容器被允许使用的资源量的实际上限
参数位置：
containers:
- name: container_name
image: ubuntu
resources:
- requests:
memory: "128Mi"
cpu: "100m"
- limits:
memory: "256Mi"
cpu: "250m"
- 确保所有的pods 都指定requests。
最佳的实践是给这些pods 指定1核或者更少，如果需要更多算力的话，就添加额外的副本.
注意：如果你配置的太高， 比如2000毫核（2核），但是只有1核可用，那么这个pod将永远不会被调度。 - 所有的pods 都有CPU limits。
limits 是上限， 所以Kubernetes不允许pod 使用超出limits 所定义的CPU 数量。
但是CPU被认为是一种可压缩资源，pod 达到CPU limits， 它将不会被终止， 而是被限制。你的CPU将被限制，所以你可能会遇到性能问题。
2- 所有的pods上设置内存requests和limits
- 内存requests是指你认为pod将消耗多少数据。但如果内存requests大于最大节点，Kubernetes也不会调度pod。。
- 内存limits是允许pod使用多少内存的硬上限。当一个容器超过了它的内存limits，那么它将被终止。
3- 资源配额审核
资源配额审核是Kubernetes的最佳健康状况的一个检查项，检查资源，是否不足或过度资源配置。
- 如果可用CPU和内存过剩，那么消耗不足，很可能有浪费。
- 如果CPU接近100%的利用率，则在需要扩展或有意外负载时可能会遇到问题。
检查剩余的pod容量：
常用的Kubernete衡量标准是“kube_node_status_allocatable”，这是Kubernetes在给定平均pod资源利用率的情况下，对一个节点将容纳多少个pod的预估。我们可以把剩余pod容量加起来，粗略估计一下在不遇到问题的情况下可以扩展多少。
检查总的CPU使用率百分比、CPU requests百分比与CPU limits百分比：
总的CPU使用率表示现在使用了多少，requests表示预计可能需要多少，而limits是我们设置的硬性上限。
检查总内存使用量百分比、内存requests百分比与内存limits百分比。
4- 检查节点间的Pod分布
检查pod是如何在集群中的可用节点上分配时，我们想要一个大致均等的分配。如果某些节点完全超载或欠载，这可能意味着一个更大问题出现了。
可能导致分配不均的因素包括：
-
节点亲和力（node affinity）： 亲和力（Affinity）是一个pod设置项，使它们偏好具有某些属性的节点。
例如，某些pod可能需要在带有GPU或SSD的计算机上运行，或者某些pod可能需要具有特定安全隔离或特定策略的节点。重复检查关联设置可以帮助缩小 导致不均匀分配的原因的范围，并降低问题发生的可能性。 -
污点（taints）和容忍(tolerations)： 污点与亲和力相反。这些是节点的设置项，给节点设置污点，从而使pod 难以调度到这些节点。如果要为特定pod保留节点，或者为了确保该节点上的pod对可用资源具有完全访问权限，则可以使用此选项。
-
limits和requests： 检查limits和requests设置项。这常常是问题的起因，如果调度器没有关于pods需要什么的正确信息，那么它的调度工作将会做的很差。
5- pod是否处于不良状态
当前的状态每时每刻都在变化，过度关注每一个终止的pod会慢慢侵蚀你的时间和理智。
为了确保它与您基于当前集群中的事件来作出的预期相符，需要关注以下几点：
-
Nodes not ready： pod通常会由于调度器无法满足CPU或内存requests 而以未被调度的状态终止。检查你的集群是否有足够的podsrequests的可用资源。
-
Pods that failed to create ： Pods在创建时失败，通常是因为镜像问题，比如启动脚本依赖项缺失
-
Container restarts：
- 只有一部分容器重启是不用担心的，但当你看到大量的（容器重启）则可能意味着pod处于OOMKill（内存不足而被杀死）状态。
- 内存不足是最常见的错误之一。
- 镜像问题、及其引发的依赖问题或limits和requests问题引起的意外
