Kubernetes监控开源工具基本介绍以及如何使用Sysdig进行监控
技术
作者: Docker 社区
译者:肖远昊
2018-03-20 07:56

在GitHub上有超过21000颗星,超过一千个提交者,以及一个包括Google、RedHat、Intel在内的生态系统,Kubernetes已经让容器生态系统风靡一时。Kubernetes这么火是因为它充当了分布式容器部署的大脑,它旨在使用分布在宿主机集群上的容器来管理面向服务的应用程序。Kubernetes为应用程序部署、服务发现、调度、更新、运维以及扩容提供了相关机制,但对于Kubernetes监控呢?

虽然Kubernetes能够显著简化在容器中以及在云上部署应用程序的过程,但同时它也增加了日常管理应用程序性能、获取服务可见性以及监控->报警->故障排除流程的复杂性。

基础设施层次的新型复杂性出现在期望简化应用程序部署的过程中:通过IaaS层动态配置;使用配置管理工具自动配置;以及使用像Kubernetes一样的编排工具,这些编排工具介于裸机或者虚机基础设施和支持应用程序的服务之间。

除了增加基础设施复杂性之外,应用程序正在被设计成微服务,在微服务结构中,更多组件之间需要互相通信。每个服务都可以分布在多个实例上,Docker容器根据需求跨越基础设施。在我们知道每个服务组件有多少实例以及它们的部署位置之前,情况就不再是这样了。这会怎么影响Kubernetes监控的方法和工具呢?正如Site Reliability Engineering – How Google Runs Production Systems[1]中所述,“我们需要监控系统,让我对高层次服务目标保持警惕,但也要根据需求保持对单个组件粒度的监控”。考虑到这一点,这篇博客是一个系列中的第一篇,帮助您更好地理解在生产中使用Kubernetes的行为。 这四部分组成的系列包括:

  • 第一部分(本篇):Kubernetes监控开源工具的基本介绍以及使用Sysdig进行监控。
  • 第二部分:Kubernetes报警的最佳实践[2]
  • 第三部分:通过系统捕获对Kubernetes服务发现进行故障排除[3]
  • 第四部分:WayBlazer的Kubernetes监控(一个示例)[4]

了解Kubernetes及其复杂性

从物理/基础设施的角度来看,Kubernetes集群由一组master节点监控的nodes组成。master节点的任务包括跨node节点的容器编排、状态追踪以及通过REST API和UI界面暴露集群控制。

另一方面,从逻辑/应用的角度来看,Kubernetes集群按照图中所示的层级方式排列:

所有容器运行在Pods中,一个Pod是一组容器集合。这些容器总是部署在一起并且一起进行调度,它们运行在共享的环境中并且拥有共享的存储。Pod中的容器被保证部署在相同的机器上,可以共享资源。

  • Pods位于services之后,service主要负责负载均衡,并且将一组Pod作为一个可发现的IP地址/端口进行暴露。
  • Services通过replica sets(之前成为副本控制器)进行水平伸缩,它根据需求为每个服务创建/销毁Pod。
  • ReplicaSets由deployments进行控制,它允许对运行中的replicasets以及Pods进行状态申明。
  • Namespaces代表虚拟集群,可以包含一个或者多个services。
  • Metadata允许使用labels和tags基于容器的部署特性进行标记。

所以需要搞清楚的是,多个services甚至多个namespaces可以分散在同一个物理基础设施中。每个service都由多个Pod构建,而每个Pod都有多个container构成,这就为监控增加了一定程度的复杂性,即使是适度的Kubernetes部署也是如此。

让我们来看看Kubernetes本身提供的解决方案。

如何收集Kubernetes监控数据:开源工具

和大多数平台一样,Kubernetes有一套基本的工具,可以让你监控你的服务器,在这种情况下,Kubernetes可以直接部署在物理基础设施之上。“内置”一词可能有点言过其实,更公正地说,考虑到Kubernetes的可扩展性,你可以添加额外的组件来获取Kubernetes的可见性,让我们来看看其中的几个选择:

  • Probes
  • cAdvisor
  • Heapster
  • Kubernetes Dashboard
  • Kebu-state-metrics

之后我们将对比一下这些选择和使用Sysdig进行监控。

Liveness和Readiness Probes

Kubernetes Probes具有定期监测集装箱或服务的健康状况的重要功能,并在发生不健康的事件时采取行动。Kubernetes监控探针允许你通过设定一个特定的命令来定义“Liveness”状态,这个命令应该在Pod中成功执行。你还可以设定Liveness探针执行的频率。以下是一个简单的示例,基于cat命令。

#Example Liveness probe for the Sysdig Blog on "Monitoring Kubernetes"
apiVersion: v1
kind: Pod
metadata:
 labels:
   test: liveness
 name: liveness-exec
spec:
 containers:
 -name: liveness
   args:
   - /bin/sh
   - -c
   - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
   image: gcr.io/google_containers/busybox
   livenessProbe:
     exec:
       command:
       - cat
       - /tmp/healthy
     initialDelaySeconds: 5
     periodSeconds: 5
#source https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

Readiness Probe某种程度上说是Liveness Probe的修正版,同样它是执行一条命令来检测Pod在启动/重启后是否准备好进行工作。

cAdvisor和Heapster

cAdvisor是一个开源的容器资源使用收集器。它是专门为容器构建的,原生支持Docker容器。与在Pod级别运行的Kubernetes中的大多数元素不同,cAdvisor在每个node节点上运行。它会自动发现给定node节点中的所有容器,并收集CPU,内存,文件系统和网络使用统计信息。cAdvisor还通过分析机器上的“root”容器来提供整体机器使用情况。不过,cAdvisor两个方面有限制性:

  1. 它只能收集一些基本的资源利用信息——cAdvisor不能够告诉你应用程序的真实性能,它只能告诉你一个容器使用了X% CPU信息。
  2. cAdvisor自身没有提供任何长期存储、趋势或者分析功能。

为了进一步处理这些数据,我们需要添加Heapster。Heapster会聚集Kubernetes集群中所有节点上的数据。Heapster作为集群中的一个Pod运行,就像其他应用程序一样。Heapster Pod通过节点上Kubelets(机器上的Kubernetes agent)查询使用信息,而Kubelets又查询来自cAdvisor的数据。最终,Heapster将来自相关标签的Pod信息进行分组。

                在Kubernetes中使用Heapster和cAdvisor进行监控,来源:blog.kubernetes.io

不过,Heapster也不能够进行存储数据、趋势分析以及报警。它只是让你更容易在整个集群中收集cAdvisor数据。所以,你还需要将数据推送到可配置的后端进行存储和可视化,目前支持的后端包括InfluxDB,Google Cloud Monitoring等。此外,你还必须添加一个和Grafana一样的可视化图层来查看数据。

Kubernetes Dashboard

最近比较流行使用Kubernets插件提供一致性方式来查看一些基础数据以及管理集群环境。Kubernetes Dashboard提供了一种依据Kubernetes元数据来查看您的环境的简单方式。它有两个优势:基本的CPU/内存数据是可用的,以及可以在Dashboard上采取行动。


简单通过kubectl安装Dashboard,Kubernetes命令:

$ kubectl create -f https://rawgit.com/kubernetes/dashboard/master/src/deploy/kubernetes-dashboard.yaml

然后在安装了Dashboard的机器上通过localhost进行访问:http://localhost:8001/ui。

kube-state-metrics:作为监控设置的补充

除了配置cAdvisor/Heapster/Influx/Grafana之外,还可以考虑部署kube-state-metrics。这是一个附加服务,与Heapster一起运行,它会轮询Kubernetes API并将有关你的Kubernetes结构化特征信息转换为metrics信息。以下是kube-state-metrics会回答的一些问题:

  • 我调度了多少个replicas?现在可用的有几个?
  • 多少个Pod是running/stopped/terminated状态?
  • Pod重启了多少次?

……等等。一般来说,该模型将采集Kubernetes事件并将其转换为metrics信息。需要Kubernetes 1.2+版本,不过,需要提醒的是metrics名称和标签是不稳定的,可能会改变。

通过以上介绍,至少可以让你了解如何为你的Kubernetes环境构建合理的监控配置。虽然我们仍然没有详细的应用程序监控(例如:“我的数据库服务的响应时间是多少?”),但我们至少可以看到我们的宿主机,Kubernetes节点以及我们的Kubernetes抽象状态的一些监控。
让我们来看看Sysdig进行Kubernetes监控的方式。

使用Sysdig进行Kubernetes监控

在与数百名Kubernetes用户交谈之后,似乎典型的集群管理员往往有兴趣从物理角度来看事物,而负责构建服务的应用程序开发人员往往更倾向于从逻辑角度来看事物。无论你从什么角度进行观察,所有团队都希望减少他们为了测试系统或管理数据收集而需要完成的工作量。
考虑到这两个用例,Sysdig Monitor对Kubernetes的支持现在可以做到:

  1. 通过连接到Kubernetes的集群API服务器并查询API(常规API和观察API)我们现在可以推断出您的微服务应用程序物理和逻辑结构。
  2. 另外,我们透传获取到的重要元数据信息,例如labels。
  3. 这些信息与我们的ContainerVision[4]技术相结合,这使得我们可以检查在容器内运行的应用程序,而不需要对任何容器或应用程序进行检测。检测在每个节点上进行,而不是针对每个Pod。
  4. 因此,使用单一的检测点,你就可以监控你的主机、网络、容器和应用程序——所有这些都使用Kubernetes元数据进行标记。您可以通过Kubernetes中的DaemonSet部署Sysdig。
  5. 然后,你可以根据你的要求,在Sysdig Monitor的云服务或我们的内部部署软件中对此数据进行可视化和报警。

基于此,Sysdig Monitor现在可以从以基础架构为中心和以应用为中心的角度提供丰富的可视性和上下文。 两全其美!
让我们来看看实际是什么样子。

按Kubernetes元数据分组

Sysdig Monitor的核心功能之一就是分组。你可以根据物理层次(例如,AWS region > Host > pod > container),或者基于逻辑微服务层次(例如,namespace > replicaset > pod > container)对容器进行分组和检索。


如果你对利用你的基础物理资源感兴趣——例如识别noisy neighbors——那么物理层次是较好的选择。但是如果你正在研究应用程序和微服务的性能,那么逻辑层次往往是较好的。

一般来说,与典型Dashboard相比,动态重新组合基础架构的能力是解决环境故障更强大的方法。

分析Kubernetes服务的响应时间

例如:通过单击逻辑表中的Prod -> Wordpress,我们会自动获得一个dashboard,不管容器中运行的是主机或数据中心服务,该dashboard可以分析所有容器上聚合的HTTP服务性能。其中一个强大的概况是服务响应时间:跨所有相关容器自动聚合服务延迟,然后将其与资源利用率相关联:

这使我们能够快速分析服务是否按预期执行,是否与底层资源利用率有关。 现在我们可以更深入服务。

分析Kubernetes HTTP服务的最慢端点

接下来,让我们深入应用程序本身的特定指标——在本演示中使用WordPress应用程序充当我们的HTTP服务,让我们来看看HTTP概况。

从上图你可以看到我们现在可以深入了解:

  • 最常用的HTTP端点
  • 最慢的HTTP端点
  • 平均连接时间
  • 错误
  • 状态码

实现此服务的Pod可能分散在多台计算机上,但我们仍然可以将此服务的请求计数、响应时间和URL统计信息汇总在一起。不要忘记:这不需要任何配置或检测WordPress、Apache或底层容器。
同样,如果这是RabbitMQ、MySQL、Redis、Consul、Nginx或其他50多个组件服务,我们将以相同的方式执行(尽管每个应用程序的指标会有所不同)。

关联Kubernetes事件

最后,根据你正在检测的任何metrics信息,查看Kubernetes汇报的上下文事件,可能会提供一些有用的线索用以查看你的应用程序的运行过程。Sysdig会自动收集Kubernetes事件,所以你可以这么做。

从这个视图(或任何其他方面),你可以轻松地为Kubernetes service聚合的metrics信息创建报警策略,而不是容器或node节点。此外,你仍然可以深入到任何单独的容器中进行深度检查直至进程级别。

可视化你的Kubernetes Services

上面的例子让你感受了如何监控一个Kubernetes service的性能。但是如果我们想看到我们所有的service,以及他们如何相互沟通呢?我们通过拓扑视图来完成这个任务。
下面的两张图片展示的是完全相同的基础设施和服务。第一张图描述了物理层次,一个master节点和三个node节点:

而第二张图将容器分组到Namespace、Service和Pod中,同时抽象容器的物理位置。

第二张(面向服务的)视图对于监视Kubernetes应用程序是多么自然和直观。应用程序的结构和各种依赖性非常清晰。各种微服务之间的交互变得明显,尽管这些微服务混合在我们的机器群集中!

总结

主要结论是:如果你有一个非常庞大的部署,你必须开始考虑用一种适合你的方式来监视Kubernetes集群环境。
相关链接:

  1. https://landing.google.com/sre/book/chapters/practical-alerting.html
  2. http://dockone.io/article/4053
  3. http://dockone.io/article/4054
  4. http://dockone.io/article/4055
  5. http://sysdig.com/blog/no-plugins-required-application-visibility-inside-containers/

原文链接:https://sysdig.com/blog/monitoring-kubernetes-with-sysdig-cloud/


782 comCount 0