青蛙小白

Prometheus监控实践:Kubernetes集群监控

本文将总结一下我们目前使用Prometheus对Kubernetes集群监控的实践。 我们选择Prometheus作为监控系统主要在以下各层面实现监控: 基础设施层:监控各个主机服务器资源(包括Kubernetes的Node和非Kubernetes的Node),如CPU,内存,网络吞吐和带宽占用,磁盘I/O和磁盘使用等指标。 中间件层:监控独立部署于Kubernetes集群之外的中间件,例如:MySQL、Redis、RabbitMQ、ElasticSearch、Nginx等。 Kubernetes集群:监控Kubernetes集群本身的关键指标 Kubernetes集群上部署的应用:监控部署在Kubernetes集群上的应用 1.基础设施层和中间件层的监控 其中基础设施层监控指标的拉取肯定是来在Prometheus的node_exporter,因为我们要监控的服务器节点既包含Kubernetes节点又包含其他部署独立中间件的节点, 所以我们并没有将node_exporter以daemonset的形式部署到k8s上,而是使用ansible将node_exporter以二进制的形式部署到所有要监控的服务器上。 而负责从node_exporter拉取指标的Prometheus也是用ansible独立部署在Kubernetes集群外部的。Prometheus的配置文件prometheus.yml使用ansible的j2模板生成。

#Kubernetes #Helm

是时候使用Helm了:Helm, Kubernetes的包管理工具

目前我们的一个产品共有4套环境:dev环境、test环境、staging环境、production环境。 其中dev, test, staging环境在一个Kubernetes集群上以不同namespace部署,production环境部署在另一个Kubernetes集群上。这个产品总共有14个微服务组成,对应gitlab中14个代码库,Kubernetes的deployment yaml文件也保存在代码库,为每个服务的每套环境以环境名创建了一个目录,里面是yaml文件,yaml文件的内容使用sed实现了简单的模板功能。14个服务*4套环境总共56个yaml文件,比较原始。

#Kubernetes

Kubernetes 1.9新特性

Kubernetes 1.9已经发布,这是2017年第4个版本,也是2017年最后一个版本。以下两个链接是官方对本此更新的介绍: Kubernetes 1.9: Apps Workloads GA and Expanded Ecosystem 1.9 Release Notes 其中比较关键的特性是Apps Workloads API进入GA阶段,升级到了稳定版。 Workloads API GA apps/v1 Workloads API进入GA阶段,升级到了稳定版本并且默认启用。 Apps Workloads API包含DaemonSet, Deployment, ReplicaSet和StatefulSet,是k8s上运行长时运行的无状态服务和有状态服务的基础。

#Jaeger #Tracing

分布式跟踪系统Jaeger(一):Jaeger简介和示例应用HotROD

当使用微服务构建我们的程序时,客户端的一次请求会产生大量服务调用,包括服务和数据库等中间件的调用。 由单体应用迁移至微服务时,服务间调用的延迟是我们需要面对的一个问题。为了定位每次调用过程中的延迟问题和性能瓶颈,我们需要知道客户端一次请求所经历的过程,分别调用了哪些服务,调用每个服务花费的时长,以及调用每个服务花费的时长,这些将会成为我们性能调优的参考。因此,分布式追踪系统是微服务架构中不可缺少的一部分。