使用Kubernetes两年来的经验教训

在Ridecell公司管理基础设施团队几年后，我想在停下来休息时记录下我的一些想法和经验教训。

Kubernetes不仅仅是炒作

我在Kubernetes领域里活跃了很久，所以这并不出乎我的意料，但当某件事情被大肆宣传的时候，仔细检查一下总是好的。在两年多的时间里，我的团队完成了从Ansible+Terraform到纯Kubernetes的全面迁移，在这个过程中，我们的部署率增加了三倍多，同时将部署错误减少到“我都不记得上次是什么时候发生的”的水平。我们还提高了操作可见性，大量无趣却很重要的自动化任务，以及基础设施中断时的平均恢复时间。

Kubernetes并不是魔法，但如果被一个懂它的团队使用，那它就是一个非常强大的工具。

Traefik + Cert-Manager + Ext-DNS组合很棒

Traefik作为Ingress控制器，Cert-Manager通过LetsEncrypt生成证书，External-DNS管理边缘DNS记录，这三个组合使得HTTP路由和管理像黄油一样顺畅。我一直对Traefik 2.0中删除了很多1.x注释功能的选择颇有微词，但它们终于在2.2中回归了，尽管以不同的形式。作为一个边缘代理，Traefik是一个可靠的选择，它具有出色的指标集成，是所有Ingress控制器中管理部件最少的，以及有一个反应迅速的开发团队。Cert-Manager配合任意Ingress方案都是一个神奇的工具，如果你在Kubernetes集群中做了TLS，但还没开始使用，那现在就去了解下吧。External-DNS没有其他两个那么受欢迎，但是对于自动化DNS记录和实际匹配的步骤来说，它的重要性不亚于其他两个。

如果有什么不同的话，这些工具实际上可能使得设置新的HTTPS端点变得太容易。多年来，我们最终使用了几十个独特的证书，这在Cert Transparency搜索和LetsEncrypt自己的证书到期警告等方面产生了很多噪音。以后我将会仔细考虑哪些主机名可以作为全局配置的通配符证书的一部分，以减少正在使用的证书总数。

Prometheus很震撼，Thanos并非大材小用

这是我第一次使用Prometheus作为主要的度量系统，它不愧为该领域的首要工具。我们选择Prometheus-Operator来管理它，这不失为一个好的选择，让我们更容易将抓取和规则配置分发到需要它们的应用中。(如果重来的话，)我会在一开始就使用Thanos。我原本以为使用它会过于大材小用，没想到它是那么容易配置，而且在跨区域查询和减少Prometheus资源使用方面起了很大帮助，即使我们没有直接使用主-主互备高可用的设置。

在使用该技术栈时我遇到的困扰是Grafana的数据管理，如何存储和组合仪表板。管理仪表板的工具有了巨大的增长，例如YAML文件、JSON文件、Kubernetes自定义对象，以及你能想到的其他任何东西。但根源问题还是任何一个工具都很难从头开始编写一个仪表盘，因为Grafana有一百万种不同的配置选项和面板模式等等。我们最终将它作为一个有状态的系统来处理，将所有的仪表板进行分组管理，但我并不喜欢这种解决方案。这里是否有一个更好的工作流程呢?

GitOps才是正道

如果你使用Kubernetes，那么你应该使用GitOps。关于工具选择有很多，最简单的就是在你现有的CI系统中添加运行kubectl apply的作业，一直到使用专用的系统例如ArgoCD和Flux。不过我坚定地站在ArgoCD阵营，它是一个可作为开始的可靠的选择，而且在过去的这些年里它越来越好。就在这周，GitOps-engine的第一个版本已经上线，其将ArgoCD和Flux放在一个共享的底层系统上，所以现在更快更好了。如果你不喜欢这些工具的工作流，你现在甚至可以更容易构建新的。在几个月前我们遇到了一次意外的灾难恢复游戏日，因为有人不小心删除了测试集群中的大部分命名空间，多亏了GitOps，我们的恢复方式是在bootstrap库中执行make apply，然后等待系统自行重建。话说回来，对于一些不能在git中生存的有状态数据的Velero备份也是很重要的(比如cert-manager的证书，它虽然可以重新签发，但你可能会遇到LetsEncrypt的速率限制)。

我们遇到的问题就是选择将所有核心基础设施保存在一个存储库中。我依然认为使用一个单一的库是正确的设计，但我将会将不同的事物划分到不同的ArgoCD实例中，而不是像现在将所有都放在一个“infra”的实例中。使用单个实例导致更长的收敛时间和嘈杂的UI，而且如果我们习惯了正确地分割我们的Kustomize定义的话，它就没有多大益处了。

我们应用创建更多的Operator

我从一开始就积极发展自定义Operator，且我们在这方面取得了巨大的成功。我们从一个自定义资源和控制器开始，用于部署我们的主要网络应用，并慢慢扩展到该应用和其他应用所需的所有其他自动化。使用普通的Kustomize和ArgoCD进行简单的基础架构服务效果很好，但是当我们想要控制外部事物时(例如从Kubernetes创建AWS IAM角色，通过kiam来使用)，或者当我们需要某种级别的状态机来控制这些事物时(例如带有SQL迁移的Django应用部署)，我们都会需要用到Operator。 作为其中的一部分，我们还为我们所有的自定义对象和控制器建立了一个非常彻底的测试套件，这极大地提高了操作的稳定性和我们自己对系统正确工作的确定性。

当前有越来越多的方式来构建Opeator，但我仍然对kubebuilder相当满意(尽管公平地说，我们确实随着时间的推移大幅修改了项目结构，所以说它使用的是controller-runtime和controller-tools比kubebuilder本身更公平)。无论你最喜欢使用哪种语言和框架，都可能有可用的Operator工具包，你绝对应该使用它。

Secret管理仍是难题

Kubernetes有自己的Secret对象，用于在运行时管理秘密数据，与容器或与其他对象一起使用，而且这个系统工作得很好。但是Secret的长期工作流程还是有点乱。把一个原始的Secret提交到Git是很糟糕的，原因有很多，希望我不需要列举，那么我们如何管理这些对象呢?我的解决方案是开发一个自定义的EncryptedSecret类型，它使用AWS KMS对每个值进行加密，同时在Kubernetes中运行的控制器像往常一样将其解密回正常的Secret，还有一个用于解密-编辑-再加密循环的命令行工具。使用 KMS意味着我们可以通过IAM规则限制KMS密钥的使用来做访问控制，并且只加密值，让文件有合理的差异性。现在有一些基于Mozilla Sops的社区Operator提供了大致相同的工作流，尽管Sops在本地编辑工作流程上有点令人沮丧。总的来说，这个领域还需要很多努力，人们应该期待一个可审计、可版本化、可代码审查的工作流，就像在GitOps世界里的所有事情一样。

作为一个相关的问题，Kubernetes的RBAC模型的弱点在Secrets上表现得最为明显。几乎在所有情况下，被用于一个事物的Secret必须和使用它的事物在同一个命名空间中，这往往意味着很多不同事物的Secret最终会在同一个命名空间中(数据库密码、厂商API令牌、TLS证书)，如果你想给某人(或某事，同样的问题适用于Operator)访问其中一个，他们就会获得所有的访问权限。让你的命名空间尽可能的小，任何可以放在它自己的命名空间的东西，都去做吧。你的RBAC策略会感谢你现在的做法。

原生CI和日志分析仍是开放性问题

我遇到的两大生态系统坑就是CI和日志分析。有很多部署在Kubernetes的CI系统，例如Jenkins、Concourse、Buildkite等。但感觉完全类原生的解决方案很少。JenkinsX可能是最接近原生体验的，但它是建立在非常大的复杂性上，我觉得非常可惜。Prow本身也是非常原生的，但定制化很多，所以也不是一个容易上手的工具。Tekton Pipelines和Argo Workflows都有原生CI系统的低级管道，但是找到一种方法将其暴露给我的开发团队从来没有超出理论操作人员的范围。Argo-CI似乎已经被放弃了，但Tekton团队似乎正在积极地追踪这个用例，所以我对它的一些改进充满希望。

日志收集基本上是一个已解决的问题，社区集中在Fluent Bit上，将其作为一个DaemonSet发送给一些Fluentd pods，然后再发到你用来存储和分析的任何系统上。在存储方面，我们有ElasticSearch和Loki作为主要的开放竞争者，每个都有自己的分析前端(Kibana和Grafana)。似乎主要还是最后一部分是我的挫败感的来源。Kibana出现的时间更久，分析功能也很丰富，但你必须使用商业版来获得基本的操作，比如用户身份验证和用户权限仍然非常模糊。Loki要新得多，分析工具就更少了(子字符串搜索和每行标签搜索)，至今没有任何针对权限的设计。如果你小心翼翼地确保所有的日志输出是安全的，可以让所有的工程师看到，这没问题，但你要准备好在SOC/PCI等审计中遇到一些尖锐的问题。

结语

Kubernetes并不是很多人所说的那种可全套交付的解决方案，但是通过一些精心的工程设计和非凡的社区生态系统，它可以成为一个无与伦比的平台。花点时间学习每个底层组件，你将会在通往容器幸福的道路上走得很好，希望你在此过程中能避免我的一些错误。