使用Kubernetes两年来的经验教训( 二 ) _应用

我们遇到最大的问题就是选择将所有核心基础设施保存在一个存储库中。我依然认为使用一个单一的库是正确的设计，但我将会将不同的事物划分到不同的实例中，而不是像现在将所有都放在一个“infra”的实例中。使用单个实例导致更长的收敛时间和嘈杂的UI ，而且如果我们习惯了正确地分割我们的定义的话，它就没有多大益处了。
我们应用创建更多的
我从一开始就积极发展自定义，且我们在这方面取得了巨大的成功。我们从一个自定义资源和控制器开始，用于部署我们的主要网络应用，并慢慢扩展到该应用和其他应用所需的所有其他自动化。使用普通的和进行简单的基础架构服务效果很好，但是当我们想要控制外部事物时（例如从创建AWS IAM角色，通过kiam来使用），或者当我们需要某种级别的状态机来控制这些事物时（例如带有SQL迁移的应用部署），我们都会需要用到。作为其中的一部分，我们还为我们所有的自定义对象和控制器建立了一个非常彻底的测试套件，这极大地提高了操作的稳定性和我们自己对系统正确工作的确定性。
当前有越来越多的方式来构建，但我仍然对相当满意（尽管公平地说，我们确实随着时间的推移大幅修改了项目结构，所以说它使用的是-和-tools比本身更公平）。无论你最喜欢使用哪种语言和框架，都可能有可用的工具包，你绝对应该使用它。
管理仍是难题
有自己的对象，用于在运行时管理秘密数据，与容器或与其他对象一起使用，而且这个系统工作得很好。但是的长期工作流程还是有点乱。把一个原始的提交到Git是很糟糕的，原因有很多，希望我不需要列举，那么我们如何管理这些对象呢？我的解决方案是开发一个自定义的类型，它使用AWS KMS对每个值进行加密，同时在中运行的控制器像往常一样将其解密回正常的，还有一个用于解密-编辑-再加密循环的命令行工具。使用 KMS意味着我们可以通过IAM规则限制KMS密钥的使用来做访问控制，并且只加密值，让文件有合理的差异性。现在有一些基于 Sops的社区提供了大致相同的工作流，尽管Sops在本地编辑工作流程上有点令人沮丧。总的来说，这个领域还需要很多努力，人们应该期待一个可审计、可版本化、可代码审查的工作流，就像在世界里的所有事情一样。
作为一个相关的问题，的RBAC模型的弱点在上表现得最为明显。几乎在所有情况下，被用于一个事物的必须和使用它的事物在同一个命名空间中，这往往意味着很多不同事物的最终会在同一个命名空间中（数据库密码、厂商API令牌、TLS证书），如果你想给某人（或某事，同样的问题适用于）访问其中一个，他们就会获得所有的访问权限。让你的命名空间尽可能的小，任何可以放在它自己的命名空间的东西，都去做吧。你的RBAC策略会感谢你现在的做法。
原生CI和日志分析仍是开放性问题
我遇到的两大生态系统坑就是CI和日志分析。有很多部署在的CI系统，例如、、等。但感觉完全类原生的解决方案很少。可能是最接近原生体验的，但它是建立在非常大的复杂性上，我觉得非常可惜。Prow本身也是非常原生的，但定制化很多，所以也不是一个容易上手的工具。和Argo 都有原生CI系统的低级管道，但是找到一种方法将其暴露给我的开发团队从来没有超出理论操作人员的范围。Argo-CI似乎已经被放弃了，但团队似乎正在积极地追踪这个用例，所以我对它的一些改进充满希望。