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