云原生架构中的Kubernetes可观察性挑战

Posted 2021-04-23 云原生加速器

Kubernetes是用于编排容器化工作负载和微服务的实际平台，而这些工作负载和微服务是云原生应用程序的构建块。Kubernetes工作负载是高度动态的，短暂的，并部署在分布式，敏捷的基础架构上。尽管Kubernetes管理的云本机应用程序有很多好处，但是Kubernetes在云本机应用程序中提出了一系列新的可观察性挑战。

让我们考虑一些可观察性的挑战：

1. 数据孤岛：传统的监视工具专门在应用程序和基础结构级别上收集指标。考虑到云本机应用程序的高度动态，分布式和短暂性，这种度量收集方式将在孤岛中创建数据，需要在服务上下文中将它们缝合在一起，以使DevOps和SRE能够调试服务问题（例如，速度较慢、响应时间，停机时间等）。此外，如果DevOps或服务所有者添加新的观察指标，则数据孤岛可能会导致交叉引用损坏和数据误解，从而导致数据失准，通信速度变慢和分析不正确。

   
   

2. 数据量和粒度组件：Kubernetes部署具有粒度组件，例如在分布式和临时基础架构之上运行的Pod，容器和微服务。警报，日志和跟踪在每一层生成了大量的粒度数据，并且该数据量随着服务规模的增长而增长。数据越多，找出模式和调试问题就越困难。随着数据的增长，可观察性和故障排除变得越来越困难。

   
   

3. Kubernetes抽象：Kubernetes抽象使得难以理解动态的，短暂的和分布式的基础架构正在发生的事情。拆开这些抽象内容就像剥开洋葱的各个层（在容器，节点，网络和过程级别，有时甚至在套接字和数据包级别），以理解潜在的问题。

   
   

鉴于Kubernetes微服务部署的复杂性和生成的大量数据，在Kubernetes环境中对应用程序进行故障排除是一项挑战。需要一种不同的方法来应对Kubernetes的可观察性挑战。

Kubernetes可观察性的另一种方法

为了进一步理解这一点，让我们看一个简单的示例，该示例显示了代码的可观察性如何在Kubernetes环境中用于云原生应用程序。

Online Boutique（以前称为Hipster Shop）是Google Cloud的11层微服务演示应用程序。

图：Online Boutique微服务架构

微服务之一是ProductCatalogService，其目的是显示最新目录（目录根据新产品的可用性和现有产品库存而变化）。部署Online Boutique后，将监视相关的微服务（包括ProductCatalogService）的故障，超时和性能降低。

使用传统的监控和故障排除方法，开发人员，DevOps和SRE在各自的数据孤岛中工作，分别为ProductCatalogService捕获数据，然后通过构建内部脚本或利用第三方软件将它们各自的数据相互关联。最初，在数据量较小的情况下，这是可能的，但是随着业务的增长，这种方法不会随着时间的推移而扩展（由于更大的产品目录和/或业务逻辑来捕获更多的客户钱包）。

由于应用程序使用Kubernetes临时，分布式和动态基础架构来运行ProductCatalogService，因此Kubernetes抽象将使节点，容器，网络，进程和数据包级别的数据上下文变得困难。

所有这些挑战将共同导致更长的故障排除时间，通过利用Kubernetes本地抽象及其声明性模型正确观察ProductCatalogService，DevOps或具有可观察性的SRE可以采用不同的方法来实现可观察性即代码。

apiVersion: projectcalico.org/v3kind: PacketCapturemetadata: name: productcatalogservice-pcap namespace: onlineboutiquespec: selector: app == "productcatalogservice" destination: ports: - 80 protocol: TCP

以上是作为代码的可观察性的示例。在名称空间“ onlineboutique”中创建一个作业“ packetcapture-pcap”，该作业选择并过滤在标记为“ app == productcatalogservice”的Kubernetes上运行的工作负载，并在端口80和协议TCP处进行数据包捕获。由于Packetcapture是Online Boutique中ProductCatalogService的一部分，并且正在收集所有相关的元数据，因此消除了数据孤岛和数据粒度问题。这种方法具有以下优点：

1. 由于应用程序和相关的微服务由Kubernetes部署在临时和分布式基础架构上，因此代码和工作中的标签确保所有相关上下文始终处于所有团队成员的过滤范围。这样可以轻松进行过滤和流量有效负载的后续分析。

   
   

2. 不同的团队成员可以将此示例用于其他服务或在不同端口或不同协议的数据包捕获。

   
   

3. 与开发团队维护单元测试以确保构建时代码质量的方式相同，可以维护代码的可观察性（如本示例中的代码），以确保各种涉众（DevOps，SRE等）可以轻松地进行操作。在运行时对应用程序进行故障排除。

   
   

如本示例所示，数据孤岛，数据量和粒度组件以及Kubernetes抽象带来的可观察性挑战可以通过使用可观察性即代码的方法来解决，该方法利用了Kubernetes的声明性。如果您的应用程序遇到性能，故障或超时问题，这将加快故障排除速度，并缩短解决问题的时间。

参考链接：

https://thenewstack.io/kubernetes-observability-challenges-in-cloud-native-architecture/

点个在看你最好看