Kubernetes 彻底改变了容器编排，简化了应用程序的管理和扩展。然而，与任何复杂系统一样，Kubernetes 集群也会遇到问题，需要及时解决才能保持最佳性能和可靠性。在本文中，我们将深入探讨必要的 kubectl 命令，这些命令是诊断和排除 Kubernetes 集群问题不可或缺的工具。无论您是新手还是经验丰富的 Kubernetes 用户，掌握这些命令都将使您有能力驾驭错综复杂的容器编排，确保应用程序的健康。
文章来源：https://www.toymoban.com/news/detail-840185.html
查看集群记录报告
排除 Kubernetes 集群故障的第一步是检查其中发生的事件。kubectl get events --all-namespaces 命令能全面查看所有命名空间的事件，让您发现与 pod、节点和其他资源相关的错误、警告和问题。
NAMESPACE LAST SEEN TYPE REASON OBJECT MESSAGE
default 5m Normal Scheduled pod/my-pod Successfully assigned default/my-pod to node-1
default 4m Normal Pulling pod/my-pod Pulling image "my-image:latest"
default 4m Normal Pulled pod/my-pod Successfully pulled image "my-image:latest"
default 4m Normal Created pod/my-pod Created container my-container
default 4m Normal Started pod/my-pod Started container my-container
kube-system 15m Normal RegisteredNode node/node-1 Node node-1 event: Registered Node node-1 in Controller
...
下面是输出结果中各列的细目：
- NAMESPACE：事件发生的命名空间。
- LAST SEEN：事件最后一次出现的时间。
- TYPE：类型：事件类型（如 Normal 或 Warning）。
- REASON：事件发生的原因。
- OBJECT：与事件相关的 Kubernetes 资源（如 pod、节点）。
- MESSAGE：与事件相关的描述或消息。
排除 pod 初始化故障
假设您遇到了 pod 无法正确初始化的问题。您可以使用 kubectl get events --all-namespaces 来识别与 pod 初始化失败相关的事件，帮助您找出根本原因。
检查 pod 日志
当出现应用程序级问题时，检查 pod 日志至关重要。使用 kubectl logs <pod-name> -n <namespace> 查看给定命名空间中特定 pod 的日志。该命令对于识别应用程序代码中的错误、异常或问题非常有用。
kubectl logs my-pod -n my-namespace
在这个例子中：
-
my-pod是要从中获取日志的 pod 的名称。 -
my-namespace是 pod 所在的命名空间。
调试应用程序错误
想象一下，在 my-namespace 中名为 my-pod 的 pod 中运行着一个应用程序。如果应用程序报错，您可以使用 kubectl logs 检索特定的错误信息，从而帮助调试和解决问题。
描述资源
kubectl describe 命令提供有关各种 Kubernetes 资源（如 pod、节点和部署）的详细信息。通过运行 kubectl describe <resource> <resource-name> -n <namespace>，您可以访问大量数据，包括事件、条件和配置详情，帮助您找出问题的根源。
kubectl describe pod my-pod -n my-namespace
在这个例子中：
-
pod是资源类型。 -
my-pod是要描述的特定 pod 的名称。 -
my-namespace是 pod 所在的命名空间。
运行此命令后，将显示指定 pod 的详细信息。输出将包括有关 pod 的元数据、条件、事件等信息的不同部分。下面是输出结果的示例：
Name: my-pod
Namespace: my-namespace
...
Containers:
my-container:
Container ID: container-id
Image: my-image:latest
...
Conditions:
Type Status
---- ------
Initialized True
Ready True
ContainersReady True
PodScheduled True
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 3m default-scheduler Successfully assigned my-namespace/my-pod to node-1
Normal Pulled 2m kubelet, node-1 Container image "my-image:latest" already present on machine
Normal Created 2m kubelet, node-1 Created container my-container
Normal Started 2m kubelet, node-1 Started container my-container
...
输出将包含指定 pod 的详细信息，包括其元数据、容器信息、条件和事件。这些信息对于排除 pod 的故障会非常有用，比如初始化问题、就绪问题或与其生命周期相关的事件。
获取 pod 信息
命令：
kubectl get pods -n <namespace>
说明
kubectl get pods 命令用于检索 Kubernetes 集群中运行的 pod 的信息。
-n <namespace> 指定要列出 pod 的命名空间。请将 <namespace> 替换为您感兴趣的实际命名空间名称。
示例
假设您有一个包含多个命名空间的 Kubernetes 集群，您想检查 my-namespace 命名空间中 pod 的状态。您可以使用以下命令：
kubectl get pods -n my-namespace
运行该命令时，输出结果可能如下：
NAME READY STATUS RESTARTS AGE
app-pod-1 1/1 Running 0 2d
app-pod-2 1/1 Running 0 1d
app-pod-3 0/1 Pending 0 1h
app-pod-4 1/1 Running 0 30m
检查节点状态
节点是 Kubernetes 集群的支柱。为确保一切运行顺利，可执行 kubectl get nodes 查看所有节点的状态。
kubectl get nodes
运行此命令后，您将看到集群中所有节点的列表及其当前状态。状态可以是以下其中之一：
- Ready：这是理想状态。这意味着节点是健康的，可以接受和运行容器。
- NotReady：这种状态表示节点无法正常运行，或者遇到了妨碍其运行容器的问题。处于这种状态的节点可能存在资源限制、网络问题或其他问题。
- SchedulingDisabled：这种状态意味着节点被明确标记为不可调度，从而无法在其上调度新容器。这对于维护或故障排除很有用。
- Unknown：在某些情况下，由于与 Kubernetes 控制平面的通信问题，节点的状态可能是未知的。
理想情况下，在一个健康的 Kubernetes 集群中，所有节点都应处于 "Ready"状态。
示例
假设您运行 kubectl get nodes 并看到以下输出：
NAME STATUS ROLES AGE VERSION
node-1 Ready <none> 30d v1.21.3
node-2 Ready <none> 30d v1.21.3
node-3 NotReady <none> 5m v1.21.3
在容器中执行
有时，调试需要亲自动手。通过 kubectl exec，您可以使用 /bin/bash 以交互方式进入容器。当您需要在容器内调查问题时，这一点尤其有用。
示例
假设在命名空间 my-namespace 中有一个名为 my-pod 的 Kubernetes pod。在这个 pod 中，有一个名为 my-container 的容器。您怀疑这个容器中存在问题，并想进行交互式调查。
下面是使用 kubectl exec 的方法：
kubectl exec -it my-pod -n my-namespace -- /bin/bash
在该命令中：
-
-it用于指定交互式终端，允许您与容器内的 shell 进行交互。 -
my-pod是要访问的 pod 的名称。 -
-n my-namespace指定 pod 所在的命名空间。 -
-- /bin/bash指定要在容器内运行的命令。在本例中，它是/bin/bash，用于启动 Bash shell。
运行命令后，您将进入容器的 shell。现在，您可以像登录到容器的操作系统一样，交互式地运行命令、检查文件、查看日志和排除故障。
下面是一个会话的案例：
root@my-pod:/app# ls
file1.txt file2.txt file3.txt
root@my-pod:/app# cat file1.txt
Contents of file1.txt
root@my-pod:/app# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 1234 567 ? Ss Sep01 0:01 /my-app
...
root@my-pod:/app# exit
完成调试或故障排除任务后，可以键入 exit 退出容器的 shell。这将返回本地终端。
使用 kubectl exec 和 /bin/bash 是诊断和解决容器内问题的有力工具，在传统调试方法不充分的情况下尤为重要。
用于服务调试的端口转发
要调试 pod 内运行的服务，可以使用 kubectl port-forward 将本地端口转发到 pod 上的端口。这样就能像访问本地运行的服务一样访问这些服务，从而方便调试和测试。
示例
假设您在命名空间 my-namespace 中有一个名为 my-app-pod 的 Kubernetes pod，它在 8080 端口上托管了一个服务，您想访问该服务进行调试。
下面是使用 kubectl port-forward 将本地端口转发到 pod 端口的方法：
kubectl port-forward my-app-pod -n my-namespace 8080:8080
在该命令中：
-
my-app-pod是要将流量转发到的 pod 的名称。 -
-n my-namespace指定 pod 所在的名称空间。 -
8080:8080表示要将流量从本地计算机的 8080 端口转发到 pod 的 8080 端口。
建立端口转发后，您就可以通过连接本地计算机上的http://localhost:8080 访问 pod 内运行的服务。向本地 8080 端口发出的任何请求都将被转发到 pod 上的相应端口。下面是一个案例：
Forwarding from 127.0.0.1:8080 -> 8080
Handling connection for 8080
现在，您可以打开网络浏览器，或使用 curl 或 wget 等工具访问 pod 中的服务，就像它在本地运行一样：
curl http://localhost:8080
这样，您就可以直接检查服务并与之交互、测试 API 端点或调试问题，而无需将服务暴露在更广泛的网络中。完成端口转发后，可以在终端按下 Ctrl+C 停止端口转发。
使用 kubectl port-forward 是调试和测试 Kubernetes pod 中运行的服务的便捷方法，无需复杂的网络配置或将服务暴露在外部。
资源指标
kubectl top nodes 和 kubectl top pods -n <namespace> 可实时了解 CPU 和内存的使用情况，帮助优化资源。
示例
假设您想监控 Kubernetes 集群中节点和 pod 的 CPU 和内存使用情况。
节点指标：
要查看节点的资源使用指标，可以使用以下命令：
kubectl top nodes
下面是输出结果的例子：
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
node-1 100m 5% 1234Mi 40%
node-2 80m 4% 987Mi 32%
在该输出中：
-
CPU(cores)显示以毫核为单位的 CPU 使用率。 -
CPU%表示 CPU 使用率的百分比。 -
MEMORY(bytes)以兆字节为单位显示内存使用情况。 -
MEMORY%表示内存使用百分比。
您可以快速识别 CPU 或内存负载较高的节点，并采取相应措施，如缩放或调整资源分配。
Pod 指标：
要查看特定命名空间中 pod 的资源使用指标，请使用以下命令：
kubectl top pods -n my-namespace
将 my-namespace替换为运行 pod 的实际名称空间。下面是 pod 指标输出的示例：
NAME CPU(cores) MEMORY(bytes)
my-pod-1 50m 128Mi
my-pod-2 30m 64Mi
my-pod-3 70m 256Mi
在该输出中:
-
CPU(cores)显示 pod 的 CPU 使用情况，单位为毫核。 -
MEMORY(bytes)以字节为单位显示 pod 的内存使用情况。
通过监控 pod 指标，您可以识别资源密集型 pod，优化资源分配，并就 pod 的扩展或资源请求和限制做出明智的决策。
kubectl top 命令提供的资源使用指标对于确保 Kubernetes 集群中资源的有效使用、识别性能瓶颈以及优化应用程序的资源分配都很有价值。
检查 API 服务器健康状况
Kubernetes API 服务器对集群运行至关重要。使用 kubectl get --raw=/healthz 查询其健康状况端点，可以快速评估其健康状况。
在该输出中:
kubectl get --raw=/healthz
ok
响应 “ok” 表示 API 服务器正常运行。
如果 API 服务器不健康或出现问题，您可能会收到错误信息或非 “ok” 响应，这可能表明存在需要调查和解决的问题。
验证版本
最后，确保 Kubernetes 客户端和服务器版本之间的兼容性至关重要。使用 kubectl version 获取两个版本的信息。
示例
要检查客户端和服务器版本，只需运行：
kubectl version
输出结果：
Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.3", ...
Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.3", ...
在该输出中：
-
Client Version提供了本地kubectl客户端的相关信息。其中包括主版本、次版本和 GitVersion，后者指定了客户端的确切版本。 -
Server Version提供kubectl客户端所连接的 Kubernetes API 服务器的信息。它包括服务器的主版本、次版本和 GitVersion。
确保客户端版本与服务器版本匹配或兼容。主要版本差异可能表示不兼容，应加以解决。一般建议客户端和服务器版本尽量保持一致，以避免出现兼容性问题。
检查版本与 kubectl version 的兼容性是确保 Kubernetes 环境稳定、运行良好的必要步骤。
结论
掌握 Kubernetes 故障排除是任何 Kubernetes 管理员或开发人员的一项重要技能。本文概述的 kubectl 命令是您诊断和解决集群问题的盟友。请记住，有效的故障排除通常需要结合使用这些命令以及对应用程序和基础架构的深入了解。此外，考虑实施 Prometheus 和 Grafana 等监控和可观察性解决方案，以主动发现和解决问题，确保 Kubernetes 集群的稳定性和性能。通过利用这些工具和技术，您可以自信地驾驭复杂的 Kubernetes 世界，并保持应用程序的平稳运行。文章来源地址https://www.toymoban.com/news/detail-840185.html
到了这里，关于掌握 Kubernetes 故障排除技巧：kubectl命令的基本指南的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
