曾经想要一根魔杖来解决你所有的Kubernetes问题吗？你有没有想过有一本终极指南，可以汇总最常见的Kubernetes问题，并为每个问题提供快速解决方案？你遇到的每一个Kubernetes错误是否都会让你在一个可怕而曲折的兔子洞里越陷越深？
如果您对这些问题中的任何一个或全部回答“是”，好了，不用再看了，我们正好有适合你的东西。
我们已经完成了Kubernetes故障排除的繁重工作，因此当您真正需要解决您的Kubernetes生产问题时，您不必浪费时间搜索博客帖子和论坛来获得您需要的答案。
“
Kubernetes Error # 1 :
CrashLoopBackOff
那是什么？
CrashLoopBackoff意味着您有一个POD启动，崩溃，再次启动，然后再次崩溃。
可能是什么问题？
不幸的是，CrashLoopBackoff并不是一个简单的问题解决方案。实际上，有几个主要原因可能导致您的Kubernetes部署抛出此错误。其中包括：
Option 1: Out of memory.
发生这种情况最常见的原因之一是 POD 内存不足。
每个pod都有一个指定的内存空间，当它试图消耗比分配给它的内存更多的内存时，pod 将继续崩溃。如果分配给pod的内存少于它实际运行所需的内存，或者如果pod中存在错误，并且它在运行状态下持续消耗所有内存空间，则可能会发生这种情况。
Option 2: Probe failure.
另一个常见原因是探针故障。kubelet使用活性、就绪和启动探测来保持对容器的检查。如果活动或启动探测失败，容器将在该点重新启动。
Option 3: hostPort usage.
这种情况不太常见，但如果您确实使用了主机端口，这可能是CrashLoopBackoff错误的原因。当您将Pod绑定到主机端口时，它会限制Pod可以计划的位置数量，因为每个<hostIP, hostPort, protocol>组合必须唯一。
Option 4: Application failure.
容器中的应用程序本身由于某些错误而不断崩溃，这可能会导致POD反复崩溃。
解决问题要采取的步骤
从运行开始：
那么你可能应该开始问以下问题：
- 最近是否更改了其中一个探测器配置？
- 是否部署过此代码？
- 刚才还有其他代码更改吗？
这些问题将帮助您查找、调试和修复错误。
如果这不能帮助您解决问题，请使用相同的命令：
首先要弄清楚您是否在使用主机端口。根据Kubernetes官方文档最佳实践指南，如果你确实在使用它，你应该考虑使用 NodePort，这可能是解决问题的最快方法。
如果这两种方法都不能解决问题，您应该在这一点上开始更深入地挖掘，并查看日志以查看是否存在应用程序级错误。
首先从提取应用程序日志本身开始。当Pod本身崩溃时，运行以下命令将显示前一个Pod的日志：
应用程序在任何时候都可能因为各种原因而失败，而且由于Kubernetes不是应用程序感知的，它会抛出一条通用的错误消息，这通常很难解决。要快速解决这个问题，最好的办法是在日志中搜索应用程序级错误。错误消息很可能出现在日志的最后几行中。找到应用程序错误后，您将能够调试并修复它。
“
Kubernetes Error #2:
lmagePullBackoff
那是什么？
当Pod启动因无法提取映像而失败时，会发生lMagePullBackoff错误。在此用例中，“回退”意味着Kubernetes将继续尝试并提取映像，回退延迟会增加。
可能是什么问题？
与CrashLoopBackoff一样，它的不太流行的兄弟lmagepullbackoff也可以映射到几个不同的潜在问题。
Option 1: Manifest not found.
这表明特定版本的Docker存储库不可用。确认映像是否可用，如果可用，请相应地进行更新。
Option 2: Repository does not exist.
您无法提取映像，因为您未指定凭据或您的凭据不正确。
Option 3: Authorization failed.
您无法删除映像，因为您没有指定凭据或您的凭据不正确。
解决问题要采取的步骤
通过运行以下程序来收集信息，以确定三个问题中的哪一个是根本原因：
首先看一下结果中的事件部分。扫描错误的结果，例如找不到Nanifest或未找到存储库或可能需要授权，这是ImagePullbackoff造成的一些最常见的错误，可以通过一些简单的方法来解决。在本地提取映像，因为您的K8之间可能存在网络问题节点和注册表，或任何其他潜在问题，如丢失命名空间，甚至是不正确的密码。
“
Kubernetes Error #3:
ErrlmagePull
那是什么？
ErrlmagePull错误发生在Pod启动因无法提取映像而失败时，与上一个错误类似，但原因不同。
可能是什么问题？
此错误通常对应于以下三种最常见的情况：
Option 1: Manifest not found.
这表明特定版本的Docker存储库不可用。确认映像是否可用，如果可用，请相应地进行更新。
Option 2: Repository does not exist.
这表明您指定的映像存储库在您的集群所指向的Docker注册表中不存在。
Option 3: Authorization failed.
您无法提取映像，因为您没有指定凭据或者您的凭据不正确。
解决问题要采取的步骤
所以你可能会觉得你看到的是双重的，但有时是相似的。问题或错误可能会在复杂的、可无限扩展的像Kubernetes这样的系统。
您可以遵循在ImagePullBackoff中执行的相同步骤，可能会解决这个问题。
“
Kubernetes Error #4: CreateContainerConfigError
那是什么？
当Kubernetes试图在pod中创建容器，但在容器进入运行状态之前失败时，通常会出现此错误。
可能是什么问题？
Option 1: Missing ConfigMap.
ConfigMaps是Kubernetes对象，允许您存储配置以供其他对象使用。ConfigMap是字符串的键值对的字典。ConfigMap有助于存储和共享非敏感、未加密的配置数据。这使您可以将广泛的特定于环境的配置从容器映像中分离出来，从而使您的应用程序易于移植。如果Kubernetes无法创建或找到ConfigMap，部署将失败。
Option 2: Missing Secret.
Kubernetes Secret是存储敏感数据（如密码、OAuth令牌和SSH密钥等）的安全对象。使用机密意味着您不需要在应用程序代码中包含机密数据。Secrets类似于Con Figma PS，但专门用于保存机密数据。如果Kubernetes无法创建或找到机密，则部署将失败。
解决问题要采取的步骤
运行：
检查是否出现错误，例如未找到secret或未找到configmap
然后，运行：
并检查相关资源是否存在。如果没有，请创建它。这也可能是configmap/secret的内容的问题，这意味着资源存在于正确的名称空间中，但其内容存在问题，例如configmap中缺少密钥。在这种情况下，您应该更新configmap/secret并重新启动POD。这么简单。
