Kubernetes 等云原生技术使公司能够快速构建软件并轻松扩展。然而，由于构建面向服务的架构（微服务）和运行底层Kubernetes基础设施的复杂性增加，调试这些基于 Kubernetes 的应用程序可能非常具有挑战性。
错误是不可避免的，通常是由于软件开发过程中的错误或疏忽而发生的。因此，为了让企业跟上应用程序交付的步伐并让最终用户满意，开发人员需要一种高效且有效的调试方式。这涉及查找、分析和修复这些错误。
本文重点介绍了五个 Kubernetes 调试挑战以及如何解决它们。
1.由于构建和重新部署容器导致开发循环缓慢
当开发团队采用像 Kubernetes 这样的云原生技术时，他们的开发人员体验会发生显着改变，因为他们现在需要在内部开发循环中执行额外的步骤。他们不再像以前在整体环境中那样编写代码并立即看到代码更改的结果，而是必须管理外部依赖项、构建容器并实施编排配置（例如 Kubernetes YAML）才能看到影响他们的代码更改。
有几种方法可以解决这个 Kubernetes 调试挑战：
第一个是让您在本地开发服务并专注于单元测试而不是端到端测试，但是当服务/Web 应用程序具有身份验证要求和对数据库的依赖性时，这会很痛苦。
解决这个问题的另一种方法是使用一个名为 DevSpace 的工具，它将自动执行您的构建和部署步骤，从而使其更快。
最后，您还可以利用名为 Telepresence 的 CNCF 工具将本地开发环境连接到远程 Kubernetes 集群，从而可以访问远程 Kubernetes 集群中的这些外部依赖项，并针对本地正在开发的服务进行即时测试反馈回路。
2.分布式应用程序的端到端流程缺乏可见性
使用 Kubernetes 时的另一个调试挑战是全面了解应用程序的端到端流程，因为服务通常太多了。如果没有完全可见性，就很难识别和修复错误。
理想情况下，您应该能够获得跨服务可见性，了解什么在调用什么、什么在超时等。要解决这个问题，您需要利用能够使可观察性和跟踪更加无缝的工具。例如，工具 OpenTelemetry、Jaeger 和 Grafana Tempo 可以帮助您获取重现错误所需的信息。这里的目标是获取尽可能多的信息，当您这样做时，您将能够实时修复错误并最终提高应用程序的整体性能。
3.无法将调试器附加到代码
开发人员需要的最重要的事情之一是能够将调试器附加到他们的代码，而使用 Kubernetes 并不能使这变得容易。是的，打印/日志语句之类的东西可以工作，但它们远不及能够将调试器放在某物上并单步执行代码，特别是如果它是用户不熟悉的新代码库。
解决此 Kubernetes 调试问题的两种可能方法是：
在本地开发并找到模拟或启动本地依赖项实例的方法。
确保代码是可单元测试的，并专注于这些代码，因为它们更容易编写测试，也更容易调试。
4.使用本地更改执行集成测试的复杂设置
云原生应用程序通常由各种微服务组成。通常情况下，这些微服务相互依赖地工作并相互通信以处理更大的业务请求。
例如，社交媒体应用程序的时间线服务可能需要与用户配置文件服务对话以确定用户的关注者，同时可能需要与身份验证服务对话以确定用户的身份验证状态。由于微服务之间发生的这种多向的、服务到服务的通信，在部署任何更改之前对微服务执行集成测试至关重要，因为单独的单元测试并不总能保证目标中应用程序的行为环境。
在此上下文中执行集成测试自然涉及运行多个服务并连接到（可能是远程的）中间件和数据存储。这需要带来多重挑战的技术和工具。这些挑战包括资源有限以及生产和非生产环境之间的数据不一致；管理不同环境的不同配置；以及与管理服务版本控制、发布和部署周期相关的困难。
5.重现仅在生产/暂存中发生的问题
有时，重现在本地生产或暂存中发生的错误可能非常复杂。此时，您的模拟或现有值是不够的。
你会想，我怎样才能真正重现这个问题？我怎样才能更快地找到问题的根源？好吧，在面对 K8s 调试挑战时，一个名为 Telepresence 的开源工具通常是我的首选——该工具允许您访问远程依赖项，就像它们在本地运行一样，并将流量从远程服务重新路由到本地服务。
这意味着您可以实时调试它们，重现这些问题，并更快地将修复推送到您首选的版本控制和CI/CD管道。
结论
大多数组织坚持认为任何重要的软件交付都要经过多次迭代测试，但重要的是要记住错误是不可避免的。能够有效地调试应用程序是识别、理解和修复错误的最佳技术之一。Kubernetes 等容器技术为软件开发人员带来了许多好处，但也带来了应用程序调试挑战。幸运的是，有多种方法可以轻松应对这些挑战。
0 留言