操作指南：调试Kubernetes应用程序

调试Kubernetes应用程序通常是一个痛苦的过程，充满未知和不可预知的副作用。当你的Kubernetes集群没有自我愈合时会发生什么？错误配置的资源限制如何影响应用程序在生产环境中运行？如果不遵循一些基本原则，处理这些问题通常会使调试Kubernetes成为一个非常困难的过程。

在《软件测试的艺术》第二版（The Art of Software Testing, Second Edition）中，作者指出“这些原则本质上是心理学的，直觉上是显而易见的，但它们经常被遗忘或忽视。“你有多少次因为没有使用正确的方法而难以找到问题的根源；最后，答案是显而易见的？

当涉及到故障排除和调试时，该过程保持不变，不管它是运行在Kubernetes上的应用程序，还是运行在裸VM上的应用程序。通过从一开始就了解一些关键的指导原则和可能的问题，你可以让调试过程少很多痛苦。

本文为在Kubernetes环境中运行的应用程序提供了一些常见的故障排除和调试技术，还介绍了你可能遇到的最常见的问题。

缓解疼痛的三个简单方法

很多时候，我们会忘记一些简单的技巧，这些技巧可以帮助我们提高工作效率，减少头痛。下面是这类技巧的三种故障排除方法。

关注根本原因

在调试过程中，很容易陷入困境并开始忽略实际问题。因此，请确保你关注任何问题的根本原因，并仔细阅读错误消息！当某些事情没有按照预期工作时，通常会尝试许多与实际故障排除无关的不同方法。例如，你将不断地重新创建一个Pod或更改随机的代码行，并相信这将修复问题。

但是调试是一个解决问题的过程。因此，首先，你必须通过理解特定问题发生的原因来思考并找到根本原因，例如，通过仔细查看Kubernetes事件或应用程序日志。

寻求帮助

网上搜索问题并不是可耻的，看看StackOverflow类似的问题，并与他人联系。很可能其他人也有和你一样的问题；所以好好利用这一点吧！

对于特定于kubernets的问题，值得这样做：

• 加入Kubernetes Slack频道。
• 看看Kubernetes GitHub仓库的问题。
• 成为Kubernetes社区的一部分。

休息一下

这可能听起来很明显，但是意识到你的能力以及你能保持良好专注多久是非常重要的。如果你无法在合理的时间内定位错误，请暂时放弃它，然后处理其他事情。

Kubernetes部署中可能出现的五个问题

在前一节中，我们讨论了处理调试时的一些通用原则。现在，让我们看看在使用Kubernetes时会出现什么问题，常见的问题是什么，以及如何识别它们。

不正确的资源限制

当你的资源限制设置得过高，并且Kubernetes集群在资源方面没有足够的容量时，则无法在节点上调度应用程序。这意味着它将处于Pending阶段，在运行kubectl get pods时不可见；所以，你应该看看Kubernetes事件。

当超过内存资源限制时，Kubernetes将由于OOM（Out of memory，内存不足）错误而终止Pod。超过CPU资源限制会在操作系统级别限制容器进程，并且它永远不会被驱逐。

活性和就绪探测失败

活性（Liveness）探测是Kubernetes自我修复机制的一部分。如果你的活性探测器由于某种原因失败了，Kubernetes将不会重新启动你的豆荚（Pod），直到它变得健康。

就绪（Readiness）探测确定应用程序何时准备好为流量服务，这意味着Kubernetes服务将不会将任何流量转发给该应用程序，直到探测恢复正常为止。

网络问题

现在，当使用托管的Kubernetes集群时，容器网络（CNI）由云提供商进行监视和维护。但这并不意味着不会有任何问题。

另一方面，配置不当的网络安全策略和/或入侵可能导致从/到应用程序的连接问题。

基于角色的访问控制（RBAC）问题

当在Kubernetes中启用RBAC时，你的应用程序需要使用分配了细粒度角色的服务帐户。但有时这些权限可能不够，导致应用程序本身出现问题。

配置错误、受约束的Pod安全策略

当你的应用程序需要一些特殊的权限，比如访问主机卷或网络时，Pod安全策略就会发挥作用。配置不当的策略意味着你的应用程序无法启动。

Kubernetes原生解决方案

在本节中，我们将重点讨论Kubernetes的内置机制，这些机制可以帮助我们调试应用程序。

Kubernetes事件

Kubernetes事件指示Kubernetes资源状态中的任何更改和错误。这包括超过资源配额或由于RBAC角色配置错误而挂起的Pod，以及任何其他信息消息。作为一个例子，让我们看看“Kubernetes在挂载卷#29166时不断失败”的问题，并使用以下Kubernetes事件：

https://github.com/kubernetes/kubernetes/issues/29166

Warning     FailedSync Error syncing pod, skipping: timeout expired waiting for volumes to attach/mount for pod "cinder-init-jrryr"/"default". list of unattached/unmounted volumes=[default-token-ea2n7]

正如在上面的示例中所看到的，Kubernetes事件表示Pod的卷附加/挂载由于超时而出现问题。

为了从特定的命名空间获取Kubernetes事件，运行：

kubectl get events --namespace <namespace-name> --sort-by='{.lastTimestamp}'

调试Pod和容器

容器日志

调试容器日志最明显的方式是通过日志记录机制。在Kubernetes中，每个容器通常都写标准输出（stdout）和标准错误（stderr）流，除非配置了默认的日志记录方法，例如，保存到.log文件。

应用程序日志可以使用以下方法检索：

kubectl -n logs <pod-name> 
kubectl -n logs <pod-name>  --container <container-name>.

要获得更多kubectl日志示例，请查看此备忘单。

https://kubernetes.io/docs/reference/kubectl/cheatsheet/#interacting-with-running-pods

但是，当一个Pod终止或从节点中驱逐时，所有相应的日志文件都将消失。为了避免这种损失，你需要将日志存储与Kubernetes应用程序生命周期分开。这里是一个使用ELK堆栈进行集中日志记录的示例。

https://kubernetes.io/docs/tasks/debug-application-cluster/logging-elasticsearch-kibana/

Pod的不同阶段

Pod的生命周期包括五个阶段，如下所述：

当你运行以下命令时，你可以看到Pod的实际阶段和状态：

kubectl describe pod <pod-name> 
kubectl describe pod <pod-name>  -o wide
kubectl describe pod <pod-name>  -o yaml

当你的容器不断崩溃时，根据status部分中的终止退出码确定Pod失败的原因是值得的。

另外，当Pod阶段处于Pending状态时，这意味着由于某些问题，例如缺乏权限（RBAC角色）或超过资源限制，应用程序无法启动。在这种情况下，我们有必要看看Kubernetes事件：

kubectl get events --namespace <namespace-name> --sort-by='{.lastTimestamp}'

活性和就绪探测

活性和就绪探测是Kubernetes中高可用性和自愈的关键因素。当活性探测器失败时，你的Pod将不在运行阶段，Kubernetes将重新启动它。你可以通过运行以下命令来检查：

kubectl describe pod <pod-name>

在某些情况下，由于各种问题（如初始数据索引过程可能导致活动和准备就绪探测失败），你的应用程序重启所需的时间将比通常长。在这种情况下，你必须根据应用程序的启动时间调整活性和就绪阈值。

资源限额及配额

根据良好的实践，应该指定资源限制，以帮助Kubernetes调度器确定应用程序是否适合特定的节点。

在更多资源受限的Kubernetes环境中，集群操作符用于配置CPU、内存和其他Kubernetes资源的资源配额，比如卷或集群/命名空间级别允许的Pod数量。

当应用程序不满足资源需求时，这种设置可能会导致一些问题。要想知道这里是否有问题，最简单的方法就是看看Kubernetes事件：

kubectl get events --sort-by='{.lastTimestamp}'
Error from server (Forbidden): error when creating "examples/admin/resource/quota-mem-cpu-pod-2.yaml":
pods "quota-mem-cpu-demo-2" is forbidden: exceeded quota: mem-cpu-demo,
requested: requests.memory=700Mi,used: requests.memory=600Mi, limited: requests.memory=1Gi

正如你在上面的示例中所看到的，Pod的内存请求为700 MiB。但是，当新的内存请求添加到已使用的内存请求时，总数将超过内存命名空间资源配额；这阻止了Pod的运行。

如果希望在命名空间/集群级别监视资源配额使用情况，可以运行以下命令：

kubectl describe quota
kubectl describe quota --namespace <namespace-name>

在正在运行的容器中获得Shell

另一种有趣的故障排除方法是直接执行容器并使用kubectl exec命令获得shell。

kubectl run exec-test-nginx --image=nginx
kubectl exec -it exec-test-nginx-6558988d5-fgxgg -- sh
$ ps -ef |grep kubectl
501  8507 8409   0 7:19PM ttys000    0:00.13 kubectl exec -it exec-test-nginx-6558988d5-fgxgg -- sh

一旦进入，就可以像在本地环境中一样调试实际的应用程序。请注意，Pod必须处于运行阶段，这意味着你不能执行到崩溃的容器中。

在这文章中，你可以了解更多关于kubectl exec是如何工作的。

https://erkanerol.github.io/post/how-kubectl-exec-works/

边车和共享进程命名空间

在创建运行两个容器的Pod的场景中，容器可以共享卷和网络并使用它们进行通信。

根据Kubernetes的容器设计模式，“边车容器扩展并与主容器一起工作。当主容器和需要为其执行的任何次要任务之间存在明显差异时，这种模式最适合使用。”

https://www.weave.works/blog/container-design-patterns-for-kubernetes/

下面的Pod清单显示了一个简单的边车模式：

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-sidecar
spec:
  volumes:
  - name: shared-logs 
    emptyDir: {}
  containers:
  - name: app-container
    image: alpine
    command: ["/bin/sh"]
    args: ["-c", "while true; do date >> /var/log/app.txt; sleep 1;done"]
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log
  - name: sidecar-container
    image: alpine
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log/app-logs

这对调试有什么帮助呢？拥有一个共享的存储和网络，你可以使用localhost loopback进行通信，这为你提供了从另一个容器监视和排除应用程序故障的许多可能性——即使你的主应用程序容器正在崩溃！

如果你的应用程序是作为Deployment运行，你可以简单地添加一个边车容器使用以下命令：

kubectl edit <deployment-name>

完成之后，就可以将shell转移到运行中的边车容器中，如前面部分所述。

调试网络

排除和调试Kubernetes网络问题是困难的。它需要对OSI层、软件定义网络、操作系统以及特定于云提供商的网络有很好的理解。

Kubernetes支持多个容器网络接口（CNI），每个接口的工作方式略有不同。例如，Flannel利用VxLAN覆盖网络，其中IP包封装在UDP上。另一方面，Cilium基于底层的Linux内核技术BPF。可以看到，根据使用的CNI实现，调试过程可能完全不同。

下面让我们看看Kubernetes中常见的网络问题。

防火墙规则阻止网络流量

如果一个容器不能与在同一个Kubernetes集群中运行的其他服务进行外部通信，我们需要执行到容器中，并通过从容器中运行一个简单的ping命令来验证外部连接：

kubectl exec <pod-name>
$ ping google.com
PING google.com (216.58.215.110) 56(84) bytes of data.
64 bytes from waw02s17-in-f14.1e100.net (216.58.215.110): icmp_seq=1 ttl=53 time=19.0 ms
64 bytes from waw02s17-in-f14.1e100.net (216.58.215.110): icmp_seq=2 ttl=53 time=21.8 ms
^C
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 19.085/20.466/21.847/1.381 ms

此外，如果你想使用不同的网络协议，你可以看看iperf：

#  on the server side container
iperf -s -p 8081 -u
# on the client side container
iperf -c 172.28.128.123 -u -p 8081 -b 1K

要了解更多的细节，可以看看Kubernetes使用iperf进行的网络基准测试。

https://operating-kubernetes.info/posts/kubernetes-network-benchmarking/

Kubernetes服务无法工作

在开始调试服务端点之前，必须确保可以通过DNS解析服务名称。为了做到这一点，你可以连到Pod和运行：

nslookup <service-name>
Address 1: 10.0.0.12 kube-dns.kube-system.svc.cluster.local

当你的Kubernetes服务spec.selector部分没有正确定义时，端点部分为空可能是一个常见问题。确保你的Pod是目标服务，通过运行：

kubectl get endpoints <service-name>
NAME        ENDPOINTS
hostnames   10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376

有关更多信息，请查看调试服务。

https://kubernetes.io/docs/tasks/debug-application-cluster/debug-service/

网络策略阻塞Kubernetes命名空间之间的通信

当容器无法在Kubernetes命名空间之间通信时，可能是由于网络策略阻塞了流量。

下面的网络策略选择所有的Pod，但不允许任何进入流量到这些Pod：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector: {}
  policyTypes:
  - Ingress

你可以通过运行以下命令来查看你的所有策略：

kubectl describe networkpolicy -o yaml --all-namespaces

第三方解决方案

在前一节中，我们讨论了使用内置解决方案调试Kubernetes。本节重点介绍一些可以加速故障排除过程的第三方工具。

一致性测试--Sonobuoy

Sonobuoy是一个由Heptio编写的诊断工具，它可以在Kubernetes集群上运行一致性测试，而不会影响你的工作负载。

它支持：

• 集成端到端（end-to-end，e2e）符合性测试。
• 工作负载调试。
• 通过可扩展插件自定义数据收集。

在研究应用程序问题之前，务必确保Kubernetes集群是可操作的。例如，你可以考虑每天运行Sonobuoy流水线，并在Kubernetes集群没有通过e2e测试时发送Slack通知。

容器工具箱--Kubectl-Debug

Kubectl-debug是一个瑞士军刀容器，带有预先安装的实用工具，可以帮助你在Kubernetes上调试应用程序。例如，在运行的Pod中，它将运行一个新的容器，该容器将共享目标容器的PID、网络、用户和IPC命名空间。参见示例了解更多细节。

https://github.com/aylei/kubectl-debug/blob/master/docs/examples.md

容器性能--Epsagon

如你所知，Kubernetes集群、部署、Pod和容器可能很难配置和维护。Epsagon利用Prometheus的强大功能（你不需要管理或提供它），以丰富的经验和用户界面提供一流的监视和警报。

通过将其集成到你的云环境中，Epsagon提供了易于管理的功能，它拥有光滑的仪表板和查看生产中的一切、自动监视、各种相关性能指标、与通信通道集成的警报以及快速故障诊断。

Epsagon的分布式跟踪在一个仪表板中提供了跟踪、度量和日志的自动关联。

总结

在本文中，我们回顾了运行在Kubernetes集群上的应用程序的一些故障排除和调试技术。当然，在Kubernetes这样的动态环境中，很难预测和覆盖大多数问题。在大多数情况下，仍然会有一些意外。但希望在阅读本文之后，你能够更好地了解应该期望什么，以及纠正最常见问题的整个过程。