使用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世界里的所有事情一样。

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!