任何能够被描述的内容都必须存储在Git库中 这个GitOps的理念, 今天来践行一下，不借助其它devops平台, 看看是不是能够实现工具闭环

最近在思考作为一个小团队来说，在没有配置管理平台的情况下怎么样的配置管理才能更好地支持多个Kubernetes环境的差异呢, 大多数的人跟我的反应一样, 使用Helm, 这也是我一直的想法，Helm对于复杂的应用来说，其实比较实用，特别是在Helm3去除了Tiller之后，可是业务中的应用基本都属于轻应用，有更优的解决方案吗?

使用kubernetes做为底层平台, 对于配置文件的部署形式, 如果没有统一的配置管理, 使用最多的就是configmap及secret

但有时候只会将敏感的信息放在secret中，而大多数的配置会放在configmap, 这就造成要么把secret以env的形式存在于容器中,要么就以volumn的形式挂载到容器中, 需要从两个源来引用配置， 从本质上, configmap与secret是一个东西, 有时候会觉得这种场景其实可以优化到一个配置中， 官方到目前为止并不打算支持在configmap中引用secret, 这是在github上讨论的issue

在Devops中经常面对的一个问题就是，如何将敏感信息保存在git中, 虽然kubernetes提供了secret，但它也只是Base64转换了一下, 任何人拿到这个串都可以反转出来，不安全.

在GitOps的流程上, 如何解决save everything on git but secrets的问题一直是个非常有趣的话题，而今天要说的Sealed Secrets就是一个很好的工具, 可以与Kubernetes无缝接入.

今天排查了一个HTTPS证书的问题, 虽然很快的就解决了, 但里面涉及到的东西学是蛮多啊的，学习一下

今天同事反映了一个很奇怪的问题: 在k8s环境里的容器中curl另一个服务时会出现断断续续的超时, 问题现象很简单, 但问题根源很复杂

在调研elastalert时几乎把整个源码都看了一遍，记录一下几个重要的部分.

ClickHouse是一种用于在线分析处理的面向列的开源DBMS。 由俄罗斯IT公司Yandex为Yandex.Metrica网站分析服务开发的, 多用于OLAP分析需求. 今天记录下clickhouse-operator的搭建部署.

这次着重看一看elastalert的配置及支持的Rule规则. 对于一般的业务需求基本是可以满足的了.

elastalert是专门为elastsearch开源的日志关键字监控工具, 支持非常多的告警方式且自定义程度很高, 代码写的也非常清晰, 最近调研了这个开源库进行了二次开发, 用在了业务日志关键字监控上,还是很不错的.这里站在用户使用的角度对邮件告警进行了改造, 期间踩了不少坑.

下次会记录一下常见的监控rule类型及接入微信告警的方式.