在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集群按照图中所示的层级方式排列：
所有容器运行在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监控数据：开源工具
Probes
cAdvisor
Heapster
Kubernetes Dashboard
Kebu-state-metrics
之后我们将对比一下这些选择和使用Sysdig进行监控。
Liveness和Readiness Probes
Readiness Probe某种程度上说是Liveness Probe的修正版，同样它是执行一条命令来检测Pod在启动/重启后是否准备好进行工作。
cAdvisor和Heapster
它只能收集一些基本的资源利用信息——cAdvisor不能够告诉你应用程序的真实性能，它只能告诉你一个容器用了X% CPU信息。
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
简单通过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：作为监控设置的补充
我调度了多少个replicas？现在可用的有几个？
多少个Pod是running/stopped/terminated状态？
Pod重启了多少次？
……等等。一般来说，该模型将采集Kubernetes事件并将其转换为metrics信息。需要Kubernetes 1.2+版本，不过，需要提醒的是metrics名称和标签是不稳定的，可能会改变。
通过以上介绍，至少可以让你了解如何为你的Kubernetes环境构建合理的监控配置。虽然我们仍然没有详细的应用程序监控（例如：“我的数据库服务的响应时间是多少？”），但我们至少可以看到我们的宿主机，Kubernetes节点以及我们的Kubernetes抽象状态的一些监控。
让我们来看看Sysdig进行Kubernetes监控的方式。
使用Sysdig进行Kubernetes监控
考虑到这两个用例，Sysdig Monitor对Kubernetes的支持现在可以做到：
通过连接到Kubernetes的集群API服务器并查询API（常规API和观察API）我们现在可以推断出您的微服务应用程序物理和逻辑结构。
另外，我们透传获取到的重要元数据信息，例如labels。
这些信息与我们的ContainerVision[4]技术相结合，这使得我们可以检查在容器内运行的应用程序，而不需要对任何容器或应用程序进行检测。检测在每个节点上进行，而不是针对每个Pod。
因此，使用单一的检测点，你就可以监控你的主机、网络、容器和应用程序——所有这些都使用Kubernetes元数据进行标记。您可以通过Kubernetes中的DaemonSet部署Sysdig。
然后，你可以根据你的要求，在Sysdig Monitor的云服务或我们的内部部署软件中对此数据进行可视化和报警。
让我们来看看实际是什么样子。
按Kubernetes元数据分组
如果你对利用你的基础物理资源感兴趣——例如识别noisy neighbors——那么物理层次是较好的选择。但是如果你正在研究应用程序和微服务的性能，那么逻辑层次往往是较好的。
一般来说，与典型Dashboard相比，动态重新组合基础架构的能力是解决环境故障更强大的方法。
分析Kubernetes服务的响应时间
这使我们能够快速分析服务是否按预期执行，是否与底层资源利用率有关。 现在我们可以更深入服务。
分析Kubernetes HTTP服务的最慢端点
从上图你可以看到我们现在可以深入了解：
最常用的HTTP端点
最慢的HTTP端点
平均连接时间
错误
状态码
实现此服务的Pod可能分散在多台计算机上，但我们仍然可以将此服务的请求计数、响应时间和URL统计信息汇总在一起。不要忘记：这不需要任何配置或检测WordPress、Apache或底层容器。
同样，如果这是RabbitMQ、MySQL、Redis、Consul、Nginx或其他50多个组件服务，我们将以相同的方式执行（尽管每个应用程序的指标会有所不同）。
关联Kubernetes事件
从这个视图（或任何其他方面），你可以轻松地为Kubernetes service聚合的metrics信息创建报警策略，而不是容器或node节点。此外，你仍然可以深入到任何单独的容器中进行深度检查直至进程级别。
可视化你的Kubernetes Services
下面的两张图片展示的是完全相同的基础设施和服务。第一张图描述了物理层次，一个master节点和三个node节点：
而第二张图将容器分组到Namespace、Service和Pod中，同时抽象容器的物理位置。
第二张（面向服务的）视图对于监视Kubernetes应用程序是多么自然和直观。应用程序的结构和各种依赖性非常清晰。各种微服务之间的交互变得明显，尽管这些微服务混合在我们的机器群集中！总结
相关链接：
https://landing.google.com/sre/book/chapters/practical-alerting.html
http://dockone.io/article/4053
http://dockone.io/article/4054
http://dockone.io/article/4055
http://sysdig.com/blog/no-plugins-required-application-visibility-inside-containers/