文末有kubernetes排障全景图，请转发高清版，关注后私信获取。
排查Kubernetes三步部署故障首先，检查Pod已创建并正常。以下命令可用于排查Pod故障：
kubectl logs <pod name>：用来查看Pod容器日志。
kubectl 路由网 describe pod <pod name>：用于查看与Pod相关事件列表。
kubectl get pod <pod name>：用于获取Pod的YAML定义。
**kubectl exec -ti <pod name> bash：**对进入Pod交互式终端的容器。
其次，如果Pod正常情况下，应检查服务是否能分配流量Pod。如果的Pod正在运行并准备就绪，但仍不能收到应用程序的响应，应检查服务配置是否正确。
服务的主要功能是根据流量标签将流量路由到Pod。因此，首先要检查服务定位了多少Pod，检查服务中的端点可以查看:
kubectl describe service <service-name> | grep Endpoints
端点是一对<ip address：port>，服务(至少)Pod至少要有一个目标。
路由知识如果"端点"；部分为空有两个原因：
没有带有正确标签的运行标签Pod，检查命名空间是否正确。
如果"端点"；部分为空有两个原因：
没有带有正确标签的运行标签Pod，检查命名空间是否正确。
服务选择器标签中有错字；
如果你能看到端点列表，但仍然不能访问应用程序，那么很大的原因是服务targetPort配置有误。
可使用kubectl port-forward连接到具体的服务调查：kubectl port-forward service/<service-name> 3000:80最后，检查服务与入口的连接。
如果Pod正常运行，服务可以分配流量Pod，可能原因是入口配置错误:根据入口可能使用不同类型的控制器，需要按照相应的方法进行调试。
检查入口配置参数serviceName和servicePort配置是否正确。以下命令可用于检查：
kubectl describe ingress <ingress-name>
如果"后端"；如果列为空，配置中一定有错误。
如果可以在"后端"；列中看到端口，但仍无法访问该应用程序，可能是以下问题：
入口没有发布到公网；群集没有发布到公网；
可直接连接Ingress Pod将基础设施问题与入口隔离开来。
首先，检查入口控制器Pod列表：
kubectl get pods --all-namespaces
其次，使用kubectl describe命令检查端口：
kubectl describe pod nginx-ingress-controller-6fc5bcc
最后，连接到Pod：
kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system
这样，当访问计算机上的端口3000时，请求将转发到Pod上的端口80。现在可以用应用吗？现在可以用应用吗？如果可行，问题在于基础设施。检查如何将流量调度到群组。
如果没有，问题在于入口控制器。入口控制器应进行调试。常见的入口控制包括Nginx，HAProxy，Traefik等等，可查看具体控制器相关文件进行问题排查。此处我们以Nginx为例：Ingress-nginx项目是Kubectl官方插件。可以使用kubectl ingress-nginx执行以下操作：
查看日志、后端、证书等；
连接到入口；
检查当前配置。相应的命令包括：
kubectl ingress-nginx lint：用于检查nginx.conf**kubectl ingress-nginx backend：**用于检查后端(类似于kubectl describe ingress <ingress-name>）
kubectl ingress-nginx logs：查看控制器日志。接下来，详细描述不同情况下的具体错误报告
详细解释容器退出码
| 以下是容器最常用的退出码： | 退出码 | |
名称 | 含义 | 0 |
正常退出 | 开发人员用它来表明容器正常退出 | 1 |
应用错误 | 由于应用程序错误或镜像规范中的错误引用，容器停止 | 125 |
容器无法工作 | docker run 命令执行不成功 | 126 |
命令调用错误 | 镜像中指定的命令无法调用 | 127 |
找不到文件或目录 | 在镜像中找不到指定的文件或目录 | 128 |
退出时使用的参数无效 | 退出是由无效退出代码触发的(有效代码是 0-255 之间的整数) | 134 |
异常终止 (SIGABRT) | 容器使用 abort() 中止函数 | 137 |
立即终止 (SIGKILL) | 操作系统通过容器 SIGKILL 信号终止 | 139 |
分段错误 (SIGSEGV) | 试图访问未分配给它的内存并终止容器 | 143 |
优雅终止 (SIGTERM) | 容器收到即将终止的警告，然后终止 | 255 |
退出状态超出范围
退出容器，返回可接受范围以外的退出代码，错误的原因尚不清楚
退出码 0：正常退出
退出代码 0 任务完成后，由开发人员故意停止容器触发。从技术上讲，退出代码 0 这意味着前台过程没有附加到特定的容器中。从技术上讲，退出代码 0 这意味着前台过程没有附加到特定的容器中。
若容器以退出码为准 0 终止怎么办？检查容器日志，确定哪个库导致容器退出；检查现有库的代码，确定它触发退出代码 0 原因，是否正常运行。
退出码 1：应用错误退出代码 1 表示容器因以下原因之一停止：
应用错误：这可能是容器运行代码中的简单编程错误，如除以零或与运行环境相关的高级错误，如 Java、Python 等；无效引用：这意味着镜像规范引用了容器镜像中不存在的文件。若容器以退出码为准 1 终止怎么办？检查容器日志，查看图像规范中列出的文件是否找不到。如有问题，请更正镜像以指向正确的路径和文件名。如果找不到不正确的文件引用，请检查容器日志，找出应用程序错误，调试导致错误的库。
退出码 125:容器未能运行退出码 125 表示该命令用于操作容器。例如 docker run 在 shell 调用但未成功执行。这种情况的常见原因如下：
未定义使用在命令中 flag，例如 docker run --abcd；用户在镜像中的定义命令在本机中没有足够的权限；容器与宿主机操作系统或硬件不兼容。如果容器以 退出码 125 终止怎么办？检查操作容器的命令语法是否正确；检查操作容器的用户或镜像中执行命令的上下文是否有足够的权限在宿主机上创建容器；如果您的容器引擎提供操作容器 option，试试吧。例如，在 Docker 中，尝试 docker start 而不是 docker run；测试您是否可以使用相同的用户名或上下文在主机上运行其他容器。若不能，重新安装容器发动机，或解决容器发动机与主机设置之间的底层兼容性问题。
退出码 126:命令调用错误退出码 126 表示无法调用容器镜像中使用的命令。这通常是操作容器连续集成脚本中缺乏依赖项或错误的原因。
若容器以退出码为准 126 终止怎么办？
检查容器日志，检查不能调用的命令；试着在没有命令的情况下操作容器，以确保隔离问题；排除命令故障，确保您使用正确的语法，并使用所有依赖项目；更正容器规范，重新尝试操作容器。退出码 127:找不到文件或目录
退出码 127 指示容器中指定的命令引用了不存在的文件或目录。
若容器以退出码为准 127 终止怎么办？
与退出码 126 同样，识别失败命令，确保容器镜像中引用的文件名或路径真实有效。
退出码 128:退出时使用的参数无效退出码 128 表示容器中的代码触发了退出命令，但没有提供有效的退出代码。Linux exit 命令只允许 0-255 因此，如果过程退出代码 3.5 退出后，日志将报告退出代码 128。
若容器以退出码为准 128 终止怎么办？检查容器日志，确定哪个库导致容器退出。确定有问题的库在哪里使用 exit 为了提供有效的退出代码，命令和更正。
退出码 134：异常终止 (SIGABRT)退出码 134 表示容器本身异常终止，关闭过程，刷新开流。这个操作是不可逆转的，类似的 SIGKILL(请参阅以下退出码 137）。执行以下操作之一可以触发过程 SIGABRT：
调用 libc 库中的 abort() 函数；调用 assert() 用于调试的宏。若断言为假，则该过程中止。若容器以退出码为准 134 终止怎么办？检查容器日志，检查哪个库触发 SIGABRT 信号；检查暂停过程是否在预期（例如，由于库处于调试模式），如果没有，排除库故障，修改以避免暂停容器。
退出码 137：立即终止 (SIGKILL)退出码 137 表示容器已从主机操作系统收到 SIGKILL 信号。没有宽限期，信号指示过程立即终止。可能的原因是：
当容器器引擎杀死容器时触发，如使用 docker kill 命令时；由 Linux 将用户发送到过程中 kill -9 触发命令；试试 终止
