为什么监控Kubernetes如此具有挑战性以及如何管理它?

本文主要是介绍为什么监控Kubernetes如此具有挑战性以及如何管理它?，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

为什么监控Kubernetes如此具有挑战性以及如何管理它?

尽管 Kubernetes 很受欢迎，但运行 Kubernetes 集群仍然具有挑战性。 了解这项具有层层抽象的技术需要相当长的时间。 管理集群部署很困难，生态系统在不断变化，最佳实践也在不断发展。

因此，Kubernetes 监控也很复杂。 了解集群健康指标、识别问题并找出解决问题的方法是组织面临的常见障碍，因此很难完全实现其 Kubernetes 部署的好处和价值。

了解如何以最佳方式监控 Kubernetes 运行状况和性能需要首先了解为什么 Kubernetes 可观察性具有独特的挑战性。 本文深入探讨了这些复杂性，以及如何使用正确的解决方案来管理它们。

Kubernetes 监控–为什么这么复杂？

Kubernetes 的优势也是它的弱点之一。它抽象了很多复杂性以加快部署；但这样做会使您对实际发生的事情、正在使用的资源，甚至所采取行动的成本影响一无所知。此外，Kubernetes 有更多的组件——例如服务器和服务——与传统基础设施相比，在出现问题时进行根本原因分析要困难得多。以下是使 Kubernetes 监控具有挑战性的三个核心复杂性。

复杂性 #1：数百万个指标

Kubernetes 是一个多层解决方案。整个部署是一个集群，每个集群内部都是节点。每个节点运行一个或多个 Pod，它们是处理容器的主要组件，节点和 Pod 依次由控制平面管理。控制平面内有许多较小的部分，例如 kube-controller、cloud-controller、kube-api-server、kube-scheduler 和 etcd。这些抽象都有助于 Kubernetes 有效地支持您的容器部署。虽然它们都非常有帮助，但它们会生成大量指标。

赞助商须知
Circonus 提供了一个 Kubernetes 监控解决方案，让客户能够更好地了解其集群的运行状况和性能。 该解决方案专为 Kubernetes 打造，提供总控制仪表板和警报，使组织能够立即呈现清晰、可操作的见解，从而节省时间、降低成本并最大限度地提高 Kubernetes 部署的价值。 

除了控制平面指标之外，还有“Pod Churn”指标。 不同组织之间的实际 pod 使用情况差异很大。 一些组织设计的系统中 pod 可能会持续数天、数周甚至数月； 而其他组织的系统中 pod 只能持续几分钟或几秒钟。 在 Kubernetes 中，每个 pod 都会生成一组自己的指标。 “Pod churn”是指 Pod 和容器的创建、销毁和随后重新创建的循环； 每次创建 pod 时，都会为其创建一组新的指标。 这会导致大量高基数（非常独特）的指标。 高水平的“pod churn”会导致每天创建数以百万计的新指标。

复杂性#2：短暂性

除了系统控制平面之外，还有您的部署元素，它们在不断变化。 Deployments、DaemonSets、Jobs 和 StatefulSets 都可以生成新的 pod 来监控，有时甚至需要缩减；那么 pod 或节点将永远消失。 Kubernetes 调度程序调度所有这些元素，以确保资源始终可用并分配到您希望的位置。随着新部署的安排，Kubernetes 可能会决定它需要移动 Pod 以释放给定节点上的资源。这会导致 pod 被移动和重新创建——同一个 pod，只是名称不同，位置不同。

复杂性 #3：缺乏可观察性

采用 Kubernetes 的组织也倾向于遵循现代软件实践，包括使用微服务和/或无状态应用程序设计。这些最终会导致非常动态的应用程序架构阻碍可观察性。

在基于微服务的应用程序中，工程师将应用程序分解为代表应用程序核心功能或服务的组件。这些组件旨在松散耦合，因此服务是独立运行的，并且以这样一种方式设计，即对一个服务的更改不会显着影响其他服务。现代应用程序可以由数十个微服务组成，Kubernetes 会跟踪这些不同组件的状态，确保它们可用并且有足够的数量来处理适当的工作负载。微服务本身不断地相互通信，而这种通信是通过 Kubernetes 集群本身内的虚拟网络进行的。

在无状态应用程序中，应用程序避免在服务器上存储任何客户端会话数据。任何会话数据存储（如果需要的话）都在客户端处理。由于服务器上没有存储会话数据，因此也不需要任何特定的客户端连接优先于任何其他客户端连接。这允许应用程序将每个连接视为第一个连接，并轻松平衡多个实例之间的处理负载。无状态应用程序设计的最大好处是它使应用程序能够水平扩展，只需将应用程序实例部署在多个服务器上，然后在可用服务器之间分配所有传入的客户端请求。

微服务不需要是无状态的（并且不需要将无状态应用程序组织成微服务），但是您确实会发现这两种实践被结合使用，以便能够轻松扩展应用程序。这意味着 Kubernetes 成为部署此类软件的理想平台。然而，这些类型的服务（按设计）预计是短暂的；它们可以扩展以处理工作负载，然后在不再需要时消失。因此，当吊舱被拆除时，吊舱内的所有操作信息都会随之消失。什么都没有留下；一切都过去了。

这对 Kubernetes 的可观察性有何影响？由于可观察性是通过了解系统输出来推断系统状态的能力，因此 Kubernetes 似乎是一个具有最小可观察性的系统。这种有限的可观察性正是解决 Kubernetes 问题如此困难的原因。 Kubernetes 运营商在迁移到生态系统几个月甚至几年后发现重大软件问题的故事并不少见。 Kubernetes 本身在确保服务保持运行方面做得非常出色，鉴于其有限的输出，您很容易发现自己处于这种情况而没有意识到这一点。从表面上看，这对 Kubernetes 来说是一个巨大的成功故事，但迟早需要发现这些软件问题，当系统看起来是一个“黑匣子”时，这将是一个问题。

为您管理 Kubernetes 复杂性的监控解决方案

管理 Kubernetes 可观察性的复杂性需要知道在监控解决方案中寻找什么。虽然有多种开源 Kubernetes 监控解决方案，但它们要求您创建并安装多个单独的组件，然后才能有意义地监控您的集群。几家传统的 IT 监控工具提供商也推出了 Kubernetes 监控解决方案，但很多都不是专门为 Kubernetes 构建的。因此，组织需要进行更多调整并花费大量时间来识别问题、导致问题的原因以及解决方法。

那么你如何确定什么对你来说是最好的呢？以下是评估 Kubernetes 监控解决方案时要考虑的关键标准。

自动适应变化但保持一致的用户体验

由于 Kubernetes 的短暂性，监控解决方案需要能够自动检测更改并不间断地继续监控。此外，Kubernetes 本身也在不断变化。因此，除了弄清楚 Kubernetes 的工作原理之外，还有一个挑战是试图弄清楚如何在不断发展的生态系统中进行监控。一个好的 Kubernetes 监控解决方案的目标应该是跟上和封装这些变化，以仍然为用户提供一致、可靠和可重复的体验——从而减轻他们的负担。

提供专为 Kubernetes 构建的管控工具

如果您正在监控 Kubernetes，那么您的工作就是找出问题、故障原因以及快速修复的步骤。这需要开发适当的领域知识，包括一组离散的病理学故障和对每个故障的规范性反应。但是，当您查看当今市场上的 Kubernetes 技能差距时，这种知识极为罕见。

一个有效的 Kubernetes 监控解决方案应该提供统包功能，用于识别和修复 Kubernetes 部署中经常出现的特定故障——如崩溃循环、作业故障、CPU 利用率等。用户不需要弄清楚他们需要监控哪些以及如何监控.解决方案应该让您意识到问题，但不需要深入分析或学习跟踪、处理并确保它不会再次发生。

处理大量数据并知道哪些指标需要注意

传统的监控系统无法跟上正确监控 Kubernetes 集群所需的大量独特指标。一个全面的 Kubernetes 监控解决方案必须能够处理所有这些数据。但是您应该关注哪些指标？你不能看所有的，你也不需要看所有的。您的 Kubernetes 监控解决方案需要密切关注重要指标，因此您可以放心，一切正常。

结论

Kubernetes 为现代基于云的应用程序提供了显着的优势，但要充分发挥其优势，组织需要一种新的监控方法。 Kubernetes 提出了独特的可观察性挑战，传统的监控技术不足以深入了解集群健康状况和资源分配。通过了解 Kubernetes 监控背后的复杂性，您可以更好地确定可以让您从 Kubernetes 部署中获得更多价值的解决方案。

参考文档：
[1]: https://thenewstack.io/why-monitoring-kubernetes-is-so-challenging-and-how-to-manage-it/

这篇关于为什么监控Kubernetes如此具有挑战性以及如何管理它?的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---