生产中使用Kubernetes两年后

您迁移到Kubernetes的原因

所有那些无服务器和容器的东西都很好。如果您要开始一项新业务并从头开始构建所有内容，请务必使用容器来部署应用程序，并在拥有带宽(或可能不具备)的情况下使用Kubernetes来编排应用程序，并且拥有配置和配置技术的技能。操作Kubernetes以及在Kubernetes上部署应用程序。

即使您将Kubernetes的操作卸载到诸如EKS，GKE或AKS之类的Kubernetes托管服务上，在Kubernetes上正确部署和操作应用程序也需要学习。您的开发团队应该应对挑战。只有您的团队遵循DevOps理念，才能实现很多好处。如果您有中央sysadmin团队为其他团队开发的应用程序编写清单，那么从DevOps的角度来看，我们个人认为Kubernetes的好处较小。当然，您可以选择Kubernetes带来许多其他好处，例如成本，更快的实验，更快的自动缩放，弹性等。

如果您已经在云VM或其他PaaS上进行部署，那么为什么真正考虑从现有基础架构迁移到Kubernetes?您是否相信Kubernetes是解决问题的唯一方法?您必须清楚自己的动机，因为将现有基础架构迁移到Kubernetes是一项艰巨的任务。

我们在这方面犯了一些错误。我们迁移到Kubernetes的主要原因是建立一个持续集成的基础架构，该基础架构可以帮助我们快速重新构建微服务，而这些年来，这些微服务一直困扰着许多架构。大多数新功能都需要涉及多个代码库，因此，一起开发和测试所有这些功能会使我们慢下来。我们认为有必要为每个开发人员和每个变更提供一个集成的环境，以帮助加快开发和测试周期，而无需协调谁来获得“共享阶段环境”。


 

这些需要什么?我们花了将近1.5年的时间。那值得吗?

通过构建其他工具，遥测并重新部署每个应用程序的方式，我们花了将近1.5年的时间来稳定这种复杂的CI设置。为了实现开发/产品平价，我们也必须将所有这些微服务都部署到生产中，否则，基础架构和部署设置之间的偏差将使应用程序难以为开发人员辩护，并且本应为开发人员做出选择一个噩梦。

我们对这个话题有不同的看法。回顾过去，我们认为解决连续集成的问题变得更加糟糕，因为将所有微服务推向生产以实现开发/产品平价的复杂性使得实现更快的CI的挑战变得更加复杂和困难。在使用Kubernetes之前，我们将Ansible与Hashicorp Consul和Vault一起用于基础架构供应，配置管理和部署。慢吗?是的，一点没错。但是我们认为我们可以通过Consul引入服务发现并优化Ansible部署，从而在合理的较短时间内就足够接近我们的目标。

我们应该迁移到Kubernetes吗?是的，一点没错。使用Kubernetes有很多好处-服务发现，更好的成本管理，弹性，治理，对云基础架构基础架构的

（编辑：宁德站长网）

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