如果使用任何系统的时间足够长，那么你肯定必须对其进行调试，Kubernetes也不例外。它是一个分布式系统，有许多运动部件。我们将介绍8个可以运行以调试任何Kubernetes集群的命令。
它将帮助你了解集群，并确保核心功能，运行pods可用。
假设你有集群的管理员权限，收到一个kubeconfig文件可以访问集群，并且你被告知集群已损坏。我们可以从下面8个命令调试Kubernetes。
1.kubectl version -short
通过这个命令，我们可以查看API服务器正在运行的版本。这为我们以后在对特定错误进行故障排除时提供了重要信息，对了解是否在1.16这样的旧集群上非常有用。
了解版本也可以帮助我们搜索错误和阅读变更日志。可能存在需要版本升级或新引入错误的已知问题。不同组件之间有时会存在版本兼容性问题，了解正在运行的版本是第一步。
2.kubectl cluster-info
接下来，我们应该了解集群在哪里运行，以及CoreDNS是否在运行。你可以解析控制平面URL，以了解你是在处理托管集群还是内部部署。
在这个示例输出中，我们可以看出我们正在美国东部2地区运行一个Amazon Elastic Kubernetes Service（Amazon EKS）集群。如果你的供应商当前发生停机，此信息也有助于查找。你可以查看供应商的“服务运行状况”仪表板，以了解当前的问题是与集群有关还是与集群无关。
这还可以为集群是否需要额外的身份验证提供线索。可能存在AWS Identity和访问管理（IAM）权限问题，或者需要安装类似aws-iam-authenticator的身份验证插件。
3.kubectl get componentstatus
此命令是发现调度器、控制器管理器和etcd节点是否正常的最简单方法。这些都是运行pod的关键控制平面组件。你应该查找任何未显示“ok”状态的组件，并查找一切错误。
如果你使用的集群具有托管控制平面（例如Amazon EKS），则可能无法直接访问调度器或控制器管理器。能够从这个输出中看到它们的状态可能是了解etcd或其他组件是否有问题的最简单方法。
还需要注意的是，CLI中弃用了componentstatus命令，但尚未删除。目前没有此命令的替代品，但在将其从CLI中删除之前，它是安全的，非常有用。根据集群的不同，可能需要多个命令才能获得类似的输出。此命令存在设计限制，这就是它被弃用的原因。
查看其他健康端点（包括etcd）的另一个选择是kubectl get--raw'/healthz？verbose':
尽管此命令不显示调度器或控制器管理器输出，但它添加了许多额外的检查，如果出现问题，这些检查可能很有价值。
4.kubectl api-resource -o wide -sort-by name
这是第一个包含大量信息的命令。我们已经知道集群运行的版本和位置。此时，我们应该知道控制平面是否正常，现在需要查看集群中的一些资源。
为了保持一致性，笔者喜欢列出所有按名称排序的资源，更容易按字母顺序扫描资源。添加-o wide将显示每个资源上可用的verb。这可能很重要，因为有些资源比其他资源做得更多。了解哪些可用，哪些不可用，将有助于缩小查找错误的范围。
使用此命令将告诉你集群中安装了哪些CRD（自定义资源定义）以及每个资源的API版本。这可以让你深入了解控制器或工作负载定义上的日志。你的工作负载可能使用旧的alpha或beta API版本，但集群可能只使用v1或apps/v1。
5.kubectl get events -A
我们已经了解了集群中运行的是什么，接下来应该看看发生了什么。如果最近发生了故障，你可以查看集群事件，了解故障前后发生了什么。如果你知道某个特定命名空间中只有一个问题，那么可以将事件过滤到该命名空间中，并排除健康服务中的一些额外干扰。
有了这个输出，你应该关注输出的类型、原因和对象。通过这三条信息，你可以缩小要查找的错误以及可能配置错误的组件的范围。
6.kubectl get nodes -o wide
节点是Kubernetes内部的一级资源，也是pods运行的基础。使用-o-wide选项将告诉我们其他细节，如操作系统（OS）、IP地址和容器运行时。你首先要看的是状态。如果节点没有说“就绪”，你可能会遇到问题，但并非总是如此。
查看节点的年龄，查看状态和年龄之间是否存在任何关联。可能只有新节点出现问题，因为节点镜像中发生了更改。该版本将帮助你快速了解kubelet上是否存在版本偏差，并且可能由于kubelet和API服务器之间的版本不同而存在已知错误。
如果你看到子网之外的IP地址，则内部IP可能很有用。可能是节点以错误的静态IP地址启动，并且CNI无法将流量路由到工作负载。
OS镜像、内核版本和容器运行时都是导致问题的可能差异的重要指标。你可能只有特定操作系统或运行时有问题。这些信息将帮助你快速关注潜在的问题，并知道在哪里可以更深入地查看日志。
7.kubectl get pods -A -o wide
这是最后一个信息收集命令。与列表节点一样，你应该首先查看status列并查找错误。ready列将显示需要多少pod以及有多少正在运行。
使用-A将列出所有命名空间中的pod，-o-wide将显示IP地址、节点以及pod的指定位置。使用列表节点中的信息，你可以查看哪些pod在哪些节点上出现故障。将这些信息与操作系统、内核和容器运行时等细节相关联，可能会提供修复集群所需的洞察。
8.kubectl run a -image alpine -command — /bin/sleep 1d
有时候，调试某些东西的最佳方法是从最简单的示例开始。这个命令没有任何直接输出，但你应该可以从中看到一个名为“a”的正在运行的pod。
如果没有与其他人一起调试某些东西，笔者喜欢将调试容器命名为单个字母，因为这样可以更快地键入，并且很容易进行迭代（例如b、c、d）。笔者喜欢在调试时保留旧的容器，因为有时查看与以前的pod有什么不同会很有帮助，让它们运行或崩溃比搜索终端输出历史记录更容易。
如果由于某种原因，你没有从该命令中看到正在运行的pod，那么使用kubectl descripte po a是下一个最佳选择。查看事件，找出可能出错的错误。
使用这些命令，你应该能够开始使用任何集群，并知道它是否足够健康，可以运行工作负载。还有其他需要考虑的事情，如CoreDNS缩放、负载均衡、卷，以及*日志记录和度量。这些命令应该可以在云中或内部部署中工作。
如果需要对节点或外部资源（例如负载均衡器）进行故障排除，则应查看控制器和API服务器日志以查找错误。根据损坏的内容，你可能需要查看kube-proxy、CNI插件或服务网格sidecar容器日志。
这8条命令能帮助你缩小集群中可能出现的问题的范围。如果你不知道问题是什么，那么从广度优先搜索开始是最好的方法。请注意不匹配的版本和不同的节点或设置的异常情况。如果你查找发生了什么变化，它可以指出正确的方向，快速发现并解决问题。
转载:https://www.tuicool.com/wx/em2UjyY