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

点击下方图片可了解培训详情。

文章插图
在公司管理基础设施团队几年后，我想在停下来休息时记录下我的一些想法和经验教训。
不仅仅是炒作
【使用Kubernetes两年来的经验教训】我在领域里活跃了很久，所以这并不出乎我的意料，但当某件事情被大肆宣传的时候，仔细检查一下总是好的。在两年多的时间里，我的团队完成了从+到纯的全面迁移，在这个过程中，我们的部署率增加了三倍多，同时将部署错误减少到“我都不记得上次是什么时候发生的”的水平。我们还提高了操作可见性，大量无趣却很重要的自动化任务，以及基础设施中断时的平均恢复时间。
并不是魔法，但如果被一个懂它的团队使用，那它就是一个非常强大的工具。
+ Cert- + Ext-DNS组合很棒
作为控制器， Cert-通过生成证书， -DNS管理边缘DNS记录，这三个组合使得HTTP路由和管理像黄油一样顺畅。我一直对 2.0中删除了很多1.x注释功能的选择颇有微词，但它们终于在2.2中回归了，尽管以不同的形式。作为一个边缘代理，是一个可靠的选择，它具有出色的指标集成，是所有控制器中管理部件最少的，以及有一个反应迅速的开发团队。Cert-配合任意方案都是一个神奇的工具，如果你在集群中做了TLS ，但还没开始使用，那现在就去了解下吧。-DNS没有其他两个那么受欢迎，但是对于自动化DNS记录和实际匹配的步骤来说，它的重要性不亚于其他两个。
如果有什么不同的话，这些工具实际上可能使得设置新的HTTPS端点变得太容易。多年来，我们最终使用了几十个独特的证书，这在Cert 搜索和自己的证书到期警告等方面产生了很多噪音。以后我将会仔细考虑哪些主机名可以作为全局配置的通配符证书的一部分，以减少正在使用的证书总数。
很震撼，并非大材小用
这是我第一次使用作为主要的度量系统，它不愧为该领域的首要工具。我们选择-来管理它，这不失为一个好的选择，让我们更容易将抓取和规则配置分发到需要它们的应用中。（如果重来的话，）我会在一开始就使用。我原本以为使用它会过于大材小用，没想到它是那么容易配置，而且在跨区域查询和减少资源使用方面起了很大帮助，即使我们没有直接使用主-主互备高可用的设置。
在使用该技术栈时我遇到的最大困扰是的数据管理，如何存储和组合仪表板。管理仪表板的工具有了巨大的增长，例如YAML文件、JSON文件、自定义对象，以及你能想到的其他任何东西。但根源问题还是任何一个工具都很难从头开始编写一个仪表盘，因为有一百万种不同的配置选项和面板模式等等。我们最终将它作为一个有状态的系统来处理，将所有的仪表板进行分组管理，但我并不喜欢这种解决方案。这里是否有一个更好的工作流程呢？
才是正道
如果你使用，那么你应该使用。关于工具选择有很多，最简单的就是在你现有的CI系统中添加运行 apply的作业，一直到使用专用的系统例如和Flux 。不过我坚定地站在阵营，它是一个可作为开始的可靠的选择，而且在过去的这些年里它越来越好。就在这周， -的第一个版本已经上线，其将和Flux放在一个共享的底层系统上，所以现在更快更好了。如果你不喜欢这些工具的工作流，你现在甚至可以更容易构建新的。在几个月前我们遇到了一次意外的灾难恢复游戏日，因为有人不小心删除了测试集群中的大部分命名空间，多亏了，我们的恢复方式是在库中执行make apply ，然后等待系统自行重建。话说回来，对于一些不能在Git中生存的有状态数据的备份也是很重要的（比如cert-的证书，它虽然可以重新签发，但你可能会遇到的速率限制）。