使用Kubernetes两年来的经验教训

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

（编辑：常州站长网）

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