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

1Kubernetes不仅仅是炒作

我在Kubernetes畛域里沉闷了很久，所以这并不出乎我的预料，但当某件事情被大肆宣传的时候，仔细检查一下总是好的。在两年多的工夫里，我的团队实现了从Ansible+Terraform到纯Kubernetes的全面迁徙，在这个过程中，咱们的部署率减少了三倍多，同时将部署谬误缩小到“我都不记得上次是什么时候产生的”的程度。咱们还进步了操作可见性，大量无趣却很重要的自动化工作，以及基础设施中断时的均匀复原工夫。

Kubernetes并不是魔法，但如果被一个懂它的团队应用，那它就是一个十分弱小的工具。

2Traefik + 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本人的证书到期正告等方面产生了很多乐音。当前我将会认真思考哪些主机名能够作为全局配置的通配符证书的一部分，以缩小正在应用的证书总数。

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

这是我第一次应用Prometheus作为次要的度量零碎，它不愧为该畛域的首要工具。咱们抉择Prometheus-Operator来治理它，这不失为一个好的抉择，让咱们更容易将抓取和规定配置散发到须要它们的利用中。（如果重来的话，）我会在一开始就应用Thanos。我本来认为应用它会过于大材小用，没想到它是那么容易配置，而且在跨区域查问和缩小Prometheus资源应用方面起了很大帮忙，即便咱们没有间接应用主-主互备高可用的设置。

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

4GitOps才是邪道

如果你应用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定义的话，它就没有多大好处了。

5咱们利用创立更多的Operator

我从一开始就踊跃倒退自定义Operator，且咱们在这方面获得了微小的胜利。咱们从一个自定义资源和控制器开始，用于部署咱们的次要网络应用，并缓缓扩大到该利用和其余利用所需的所有其余自动化。应用一般的Kustomize和ArgoCD进行简略的基础架构服务成果很好，然而当咱们想要管制内部事物时（例如从Kubernetes创立AWS IAM角色，通过kiam来应用），或者当咱们须要某种级别的状态机来管制这些事物时（例如带有SQL迁徙的Django利用部署），咱们都会须要用到Operator。作为其中的一部分，咱们还为咱们所有的自定义对象和控制器建设了一个十分彻底的测试套件，这极大地提高了操作的稳定性和咱们本人对系统正确工作的确定性。

以后有越来越多的形式来构建Opeator，但我依然对kubebuilder相当称心（只管偏心地说，咱们的确随着工夫的推移大幅批改了我的项目构造，所以说它应用的是controller-runtime和controller-tools比kubebuilder自身更偏心）。无论你最喜爱应用哪种语言和框架，都可能有可用的Operator工具包，你相对应该应用它。

6Secret治理仍是难题

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策略会感激你当初的做法。

7 原生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等审计中遇到一些尖利的问题。

8结语

Kubernetes并不是很多人所说的那种可全套交付的解决方案，然而通过一些精心的工程设计和不凡的社区生态系统，它能够成为一个无可比拟的平台。花点工夫学习每个底层组件，你将会在通往容器幸福的路线上走得很好，心愿你在此过程中能防止我的一些谬误。