Kong是一个Mashape开源的高性能高可用的API网关和API服务管理层，基于OpenResty,进行API管理，并提供了插件实现了API的AOP功能, 官方更是有这样的描述: Next-Generation API Platform for Multi-Cloud and Hybrid Organizations,可见kong的野心还是非常大的，也确实非常受欢迎,目前的Kong的版本为2.1.
这里简单提一下, 如果看过视频的都会发现，kong其实应该读康，而不是读空.
NFS在kubernetes中做为共享存储，用的还是比较多的，之前也就是一直用着，也没有太关注是如何实现Dynamic provisioning，今天花了点时间研究了一下原理，还是挺有意思.
Kind(kubernetes in docker的缩写)， 用于快速地在本地部署kubernetes集群,顾名思义，就是将 Kubernetes 所需要的所有组件，全部部署在一个 Docker 容器中，可以很方便的搭建 Kubernetes 集群。
Kind 已经广泛的应用于 Kubernetes 上游及相关项目的 CI 环境中
目前平台有些遗留应用还是使用的influxdb保存监控数据, influxdb为单实例, 随时可能出现单机故障, 考虑到influxdb还将运行很长一段时间, 因此需要扩展成HA机制, 这里选择influxdb-relay方案
kubernetes提供的local path给持久化提供了相当大的便利, 但有一个问题是, 每次都需要手动提前在机器上创建相应的目录来做为被调度应用的持久化目录, 不是很方便, 有没有办法可以自动创建呢?
对于rancher平台，rancher也提供了相应的工具local-path-provisioner
线上的Grafana一直都是直接将所有数据写本地的SQLite,就单独的一个db文件，随时dashboard加的越来越多，真怕随时都可能出现磁盘宕机的问题，拓展性也差， 因此将grafana的历史数据从sqlite3迁移到mysql中，也能够保证HA, 新测有效
基于kubernetes为容器平台的业种中， 对于日志的收集，使用最多的是FEK， 不过有时候，FEK在架构上会略显重， ES的查询及全文检索功能其实使用的不是很多.LoKi做为日志架构的新面孔, 由grafana开源， 使用了与Prometheus同样的label理念, 同时摒弃了全文检索的能力, 因此比较轻便, 非常具有潜力
grafana支持的告警方式很多种, 偏偏不直接支持wechat
本文为转载文章,主要对tcp的内核相关参数做了一个比较详细的介绍, 写的非常不错, 值得推荐, 原文地址 mp.weixin.qq.com
任何能够被描述的内容都必须存储在Git库中 这个GitOps的理念, 今天来践行一下，不借助其它devops平台, 看看是不是能够实现工具闭环