那是什么？
当Kubernetes尝试创建容器但失败时，会发生此问题，这可能有几个原因。
可能是什么问题？
Option 1: Issue with the container runtime
在怀疑容器运行时错误的情况下，首先应该尝试清理旧容器、更改容器名称或检查运行容器的节点上的Kubelet日志。
Option 2: Issue with starting up the container
这也可能表示容器根本无法运行。这可能与启动命令有关，它可能对映像不可用、未指定或不可执行。在每种情况下，容器都将无法运行。
解决问题要采取的步骤
如果出现此错误，您还需要运行：
然后查看“事件”部分。基于你在这里看到的错误（可能有相当多），您将知道您需要调试和修理。这可以是启动命令或pod，但这将是第一个开始寻找根源的地方。一些例子包括：container name [... ] already in use by container " 或 " starting container process caused "。如果事件中出现这些错误，容器在运行时或容器初始化时很可能存在问题。
“
Kubernetes Error #6:
FailedScheduling
那是什么？
当某些pod无法获得计划时，就会发生此问题。
可能是什么问题？
Option 1: Allocatable resources on the node are lower than the pod's requested resources
Kubernetes调度程序将尝试找到可以分配资源以满足pod请求的节点。如果不成功，POD将保持挂起状态，直到有更多资源可用。这可能意味着：
- 您已为任何节点请求了更多可用的CPU/内存。在这种情况下，您可以减少Pod的CPU/内存请求，释放节点上的CPU/内存，或者为更大的节点提供更多资源。
- 集群中没有更多的容量来分配您请求的CPU/内存。在这种情况下，您应该向集群添加更多节点。
Option 2: Unschedulable nodes
Kubernetes会将一个节点标记为 unschedulable（如果您对其进行封锁）。在节点重新启动或进行其他维护之前，这是一个有用的备份步骤。在这种情况下，您应该在节点上断开连接或配置更多节点。
Option 3: Nodes taints
Kubernetes允许您向节点添加污点并向POD添加容差，以影响调度决策。污点和公差一起工作，以确保POD不会被调度到不适当的节点上。如果您向节点添加了污点，那么该节点应该只接受容忍这些污点的pod.如果调度程序找不到任何合适的节点，您将收到FailedScheduling消息。你怎么能修好它？确保Pod的容差与节点的污染相匹配。
Option 4: Nodes labels
在某些情况下，您可能希望控制将Pod部署到哪个节点。其中一种方法是使用NodeSelector，NodeSelector是推荐的最简单的节点选择约束形式。它指定键——值对的映射。对于有资格在节点上运行的pod，节点必须将每个指示的键值对作为标签。
如果调度程序未能找到标签与Pod的NodeSelector匹配的节点，您将收到FailedScheduling消息。
要解决这个问题，您需要确保至少有一个可用节点包含与Pod的节点选择器匹配的标签。
解决问题要采取的步骤
好吧，我们保证，我们不是在戏弄你。当没有足够的CPU、内存或两者的组合时，最常发生此错误。还可以通过运行以下命令来了解分配的CPU和内存阈值：
一旦发现问题所在，就可以确保为部署分配足够的内存和CPU。
重要注意事项：
当涉及到K8S错误和问题时，内存问题至关重要。并且可能是应用程序被终止的原因。相比较而言，CPU问题不被视为生产关键问题。当他们可以的时候导致应用程序变慢，则可能不是要杀死的应用程序或POD。
区分可压缩和不可压缩资源很重要。如果您的容器消耗太多可压缩资源（如CPU），它们会受到限制，但如果它们使用太多不可压缩的资源（如内存），会被杀死（因为没有其他方法来要求应用程序释放分配的内存）。
“
Kubernetes Error #7:
NonZeroExitCode
那是什么？
当容器存在不正常的退出代码时，会发生此问题。
可能是什么问题？
因此，正如错误所暗示的那样，不同的退出代码将为您提供有关特定潜在问题的更清晰的信息。
每个退出代码都映射到不同的部署错误，并且有多个退出代码需要考虑。一些例子包括：
Exit Code 1:
表示容器由于（a）应用程序错误或（b）无效引用而停止，这意味着映像规范正在引用容器映像中不存在的文件。
Exit Code 127:
指示容器规范中指定的命令引用不存在的文件或目录。
解决问题要采取的步骤
运行我们最喜欢的kubectl命令：
一旦您知道容器抛出的退出代码，您将能够快速找到并修复潜在的问题。如果您正在寻找有关所有退出代码以及如何解决它们的详细信息，请务必查看此完整指南。
“
Kubernetes Error #8:
OOMKilled
那是什么？
当pod定义了内存限制时，如果pod内存使用超过了指定的限制，则pod将被终止，并且状态将被报告为OOMKilled。
如果节点在kubelet能够回收存储器之前经历了存储器不足（OOM）事件，则节点依赖于OOM杀手来响应。
可能是什么问题？
还记得我们失败的调度错误吗？好吧，当你超过了你的内存限制，你的POD无法继续安全运行时，通常会发生这种情况。
解决问题要采取的步骤
您需要检查的第一件事是最近是否更改了内存限制和阈值，或者更糟的是，是否从一开始就没有配置它们。如果您尚未配置内存限制，请从那里开始，并在分配内存时记住下面列出的最佳实践。
一旦你正确地配置了你的内存，你就可以安全地重新启动你的POD，如果它是无状态的（在这里阅读更多），它应该是一个优雅的重新启动，并且应该正常工作。如果不是，那就是另一个兔子洞了。
一个有用的深度探索：Kubernetes资源如何分配在引擎盖下工作
在FailedScheduling错误之后，您可能想知道是否有一些定义CPU和内存分配的良好实践，你的POD不会遇到这样的问题。因此，我们决定添加一个小的奖金部分，以快速了解资源如何在Kubernetes中分配工作。
就像工程中的所有事情一样，没有通用的标准CPU和内存分配——这基本上是由应用或服务的具体要求。它通常是确定的并最终通过对应用程序执行压力测试来定义了解其正常运行的最低要求。
对于Kubernetes来说，最好的方法是利用其资源建模，并按应用程序或定义所需的资源容器，这是由服务质量（QoS）等级决定的。
QoS类是一个Kubernetes概念，它决定了POD的调度和逐出优先级。
QoS由Kubernetes分配给POD，但这是我们可以做到的通过了解POD，影响我们配置POD的方式优先事项。当Kubernetes创建一个pod时，它会分配其中一个QoS到Pod的类：
- 保证
- 可爆发的
- 最大努力
现在，让我们来看看K8S中的资源分配。资源是包括限制和请求，这两者都是由限制和请求定义的。在CPU和内存阈值中，最大值是多少此pod可用的请求数（在CPU和内存中），以及此POD可以消耗的CPU和内存的总限制是多少？
