使用Netsil监控Kubernetes上的微服务

Kubernetes 是容器编排和调度领域的王者，它击败了竞争对手Docker Swarm和Apache Mesos，开启了闪耀的未来，微服务可以 自修复 ，可以 自动扩展 ，可以跨zone，region甚至跨云供应商进行federate。在这样的云原生应用程序的新纪元里，能够以简单的方式洞察服务之间是如何交互的变得日益重要——这可和大海捞针般大范围寻找导致性能问题的某个特定的原因是不一样的。

我们花了些时间研究Netsil并且 将其解决方案打包成 原生的Kubernetes Deployment。Netsil的应用程序，Application Operations Center (AOC，应用运维中心)，帮助用户观察并且收集跨Kubernetes集群运行的微服务应用程序的分析数据。服务本身是不可知的，因为它在网络上才能决定其实际上如何运行。随着时间的推移，并且实时地，它学习并且发现用户的环境，帮助用户逐渐搭建出SLA指标器，警报器等等。

开始吧

首先你需要一个Kubernetes集群。我使用 Stackpoint.io 快速创建一个集群。在任意主流供应商，比如AWS，GCE或者Azure上创建一个集群。需要确保为你的主节点选择足够大的配置——这是所有收集器会将数据发送这里，在网络，处理器和内存上都可能消耗比较大。worker节点可以是任何配置，只要能够满足微服务应用程序的需求。在我的示例里，使用了较大的实例配置，因为我会将多种服务都推送到这个环境里。

在我们的示例里，使用3个N1标准4的实例构建了一个集群，这些实例通过HAProxy Ingress Controller暴露出去，它是自发现的，并且在部署它们时注册了AOC服务。我们能够使用集群的公开VIP访问AOC仪表盘。

开始前

在仅仅运行了Kubernetes服务的空空的集群上再安装一些服务，这里使用 Sock Shop ，这是由 Weaveworks 开发的微服务参考程序。这样有助于模拟一个真实的环境。Sock Shop使用了14个不同的服务，这是很多企业的应用程序会达到的复杂度。现在将AOC添加到我们的环境里。

这里 有关于Sock Shop的详细信息。将其推送到环境里很简单，仅仅需要在克隆了repo后运行如下命令即可：

kubectl apply -f deploy/kubernetes/manifests

然后检查Pod是否已经在线了：

$ kubectl get pods --namespace=default



NAME READY STATUS RESTARTS AGE

cart-3694116665-eccpp 1/1 Running 0 55m

cart-db-2305146297-u30g8 1/1 Running 0 55m

catalogue-11453786-lkslj 1/1 Running 0 55m

catalogue-db-393939662-bn7uc 1/1 Running 0 55m

front-end-3820830240–01e6t 1/1 Running 0 55m

orders-3498886496-z8jun 1/1 Running 0 55m

orders-db-1775353731-u7dmf 1/1 Running 0 55m

payment-3012088042-vbfhw 1/1 Running 0 55m

queue-master-936560853-ocmxi 1/1 Running 0 55m

rabbitmq-1897447621–2ij04 1/1 Running 0 55m

shipping-1232389217-b278a 1/1 Running 0 55m

spc-balancer-biilo 1/1 Running 0 1h

user-3090014237–196pv 1/1 Running 0 55m

user-db-1338754314-exyou 1/1 Running 0 55m

开始观察吧

我们已经有了运行着的Kubernetes 1.4集群，并且安装了Sock Shop应用程序，那么开始学习环境里是什么吧。当股票购买者遇到问题时我们是否能知道呢？

在部署AOC之前需要在所有主机上运行如下命令。该命令帮助避免一个已知的Flannel和kube-proxy的 竞争问题 。

iptables -t nat -I POSTROUTING -o flannel.1 -s host-private-ip -j MASQUERADE

使用每台主机的私有IP替换 host-private-ip 。完成后，从GitHub克隆AOC Kubernetes repo：

git clone https://github.com/netsil/netsil-kube.git

并且使用如下单个命令将其推送到Kubernetes里：

kubectl apply -f netsil.yml

确保Pod和Service已经在线了。AOC容器可能需要一些时间，但是收集器会被启动并且队列里的数据会被推送进来，因为它们已经开始发现你的环境了。

$ kubectl get po,svc — namespace=netsil



NAME READY STATUS RESTARTS AGE

collector-7wpaa 1/1 Running 0 1h

collector-9o6k4 1/1 Running 0 1h

collector-rzekv 1/1 Running 0 4m

netsil-vjf5f 1/1 Running 0 1h

NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE

netsil 10.200.126.143 <nodes> 443/TCP,2001/TCP,2003/TCP,2003/UDP 1h

AOC拓扑有两个主要组件。第一个是作为带有单个副本的Replication Controller的一部分运行的Pod。它运行AOC仪表盘和数据收集的平台。第二个组件是AOC收集器的 DaemonSet 。它告诉Kubernetes在环境的所有节点上运行一个带有收集器容器的Pod。这些收集器配置为向AOC Pod发送信息。

生成流量

我们将使用Sock Shop的更多工具来模拟网站上的购物行为。这让我们能看到AOC是如何学习流量模式以及我们的通用拓扑的。

你需要知道Sock Shop监听以及运行的前端IP地址和端口：

docker run weaveworksdemos/load-test -h $frontend-ip[:$port] -r 100 -c 2

随着load-test的运行，可以开始看到AOC随着数据的获得被点亮了：

因为AOC作为DaemonSet部署，如果任意Pod销毁了并且在其他地方重新调度，AOC能够继续观测到拓扑，随着Kubernetes的变化而变化。

我很喜欢AOC的一个原因是部署通过服务来组织，并且我能够实时地观察到环境，并且开始深入不同的度量，为了那些可能影响到客户的事情搭建服务级别的警报。因此，当环境像下图一样变红时，我能够获得警报，知道某个服务处在紧急状态，比如Sock Shop里的信用卡和地址端点。

我甚至还可以深入仪表盘，知道承受最大压力的Pod和容器是什么。在本示例里，网络压力最大的容器是flannel Pod。这让我们能够了解最繁忙的服务是哪个，能够帮助我们重新思考配置或者Kubernetes里分发部署的方式。

总结

Netsil的AOC是非常棒的工具，可以帮助用户实时观察环境，随着使用模式的变化而更新。用户可以挖掘历史数据并且添加警报。应用程序随着添加更多的节点会自动扩展，新节点上线后就会在上面启动一个收集器，这样用户能够得到节点从上线到销毁的所有数据。

如果想在自己的Kubernetes环境里使用Application Operations Center，只需要下载这里的manifests就可以了。可以在 http://netsil.com 学习Netsil和Application Operations Center。

原文链接： Microservice Monitoring in Kubernetes with Netsil （翻译：崔婧雯 校对：）

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

译者介绍

崔婧雯，现就职于IBM，高级软件工程师，负责IBM WebSphere业务流程管理软件的系统测试工作。曾就职于VMware从事桌面虚拟化产品的质量保证工作。对虚拟化，中间件技术，业务流程管理有浓厚的兴趣。

 

http://www.tuicool.com/articles/J3iYjqI