kubernets基于容器日志的报警和服务自动恢复
demo地址
https://github.com/cclient/kubernetes-filebeat-collector
高可用还谈不上，是对kubernete一种服务异常重启恢复的补充方案
之前已经完成了kubernete的日志的收集，日志监控，没什么好说的 kibana grafana都是很成熟的ui产品，也都支持elasticsearch数据源
主要关注点是报警及报警信息的应用
kibana基础版本不支持报警，es 产品x-pack支持报警，但这东西收费，所以不考虑
有es报警的部分产品 如ElastAlert，不知是否支持es6.3,暂时不考虑
而grafana本身也支持报警 alerting
结合grafana本身的ui，效果很不错，同时支持多种alert 规则，其中包含webhook,webhook的定制能力很强，可以在接收到报警日志后作一些自定义的事情
由于grafana已经可用，这里选型grafana作测试
kubernetes 的 liveness probe 功能有限
如 kube的 liveness probe 如http 是监听端口是否可用，有时会有这样的情况，服务的状态还可用，但已经无法完成有效的业务处理
比如，web服务可用，端口正常监听，但web服务依赖的后端服务出问题了，实际所有请求处理都失败(日志状态会区别于正常服务)，这种情况kube默认的liveness probe 规则是无法察觉的，需要作更进一步的定制。
而如果根据为每个服务定制专用的liveness probe服务，成本比较高，也会对原项目有较高的侵入性
我们可以采用基于日志来间接判断服务状态的方案，虽然不是100%准确，但侵入小，适用面广，可以作为一个基础的方案，对准确性有更高要求的再后续定制
结合kubernetes的liveness probe，可以实现基于日志状况，报警，并重启服务
实现起来并不复杂
deploy->filebeat日志收集->写入es->grafana ui->grafana alerting 日志触发报警规则（例，10分钟内count数为0）-> webhook接收报警 -> 记录当前服务状态为失效
另外部署一套服务，查询服务状态
liveness probe 检查服务状态，若返回当前服务失效，则k8会自动重启服务
这样的流程，作为对kube liveness的简单补充
功能已经实现完成
服务状态持久化，选择简单的redis
而服务状态的api实现，这里直接用webhook(golang 实现的运维工具),配置规则即可，没必要另外开发
grafana 报警规则的配置，文字也不好说明，直接看图
启动服务时 kubernetes-init
del key
检查服务状态 kubernetes-liveness
exists key
webhook收到报警 grafana-redis-alert
set key 1
最后yml示例
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: consume
namespace: default
labels:
app: consume
spec:
replicas: 1
template:
metadata:
labels:
app: consume
spec:
containers:
- name: consume
imagePullPolicy: Always
image: cuidapeng/busybox-curl:v0.1
# del consume
command: ['sh', '-c', 'curl http://alert_hook_server:9000/hooks/kubernetes-init?contain=consume && echo The app is running! && sleep 3600']
livenessProbe:
exec:
command: ['sh', '-c', 'return $(curl -fsSL http://alert_hook_server:9000/hooks/kubernetes-liveness?contain=consume)']
initialDelaySeconds: 5
periodSeconds: 5
initContainers:
- name: init-myservice
image: cuidapeng/busybox-curl:v0.1
command: ['sh', '-c', 'curl http://alert_hook_server:9000/hooks/kubernetes-init?contain=consume;']
