广告

用8个命令调试Kubernetes集群

  • 浏览(176)
  • 评论(0)
  • 译者:k8s

如果使用任何系统的时间足够长,那么你肯定必须对其进行调试,Kubernetes也不例外。它是一个分布式系统,有许多运动部件。在这篇文章中,我们将介绍8个可以运行以调试任何Kubernetes集群的命令

这篇文章将集中讨论集群操作。它将帮助你了解集群,并确保核心功能,运行pods可用。

假设你有集群的管理员权限,收到一个kubeconfig文件可以访问集群,并且你被告知集群已损坏。你从哪里开始?

以下是要运行的8个命令:

kubectl version —short

kubectl clusterinfo

kubectl get componentstatus

kubectl apiresources –o wide —sortby name

kubectl get events –A

kubectl get nodes –o wide

kubectl get pods –A –o wide

kubectl run a —image alpine —command — /bin/sleep 1d

让我们对每个命令进行分解,以了解其重要性以及你该寻找的内容。对于集群调试,在深入研究工作负载之前,我们将采用广度优先的方法来理解集群中的内容。

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://thenewstack.io/living-with-kubernetes-debug-clusters-in-8-commands/

  • 分享到:
  • icon
  • icon
  • icon
  • icon
箭头