使用Netsil监控Kubernetes上的微服务

mancha

　　ubernetes是容器编排和调度领域的王者，它击败了竞争对手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。