2.1 托管服务对比自建服务
在我们进一步探讨Kubernetes的部署模式之前，应该决定我们是否需要自己部署一个完整的Kubernetes模型。云计算服务商提供的Kubernetes托管服务仅仅解决了部署方面的问题，所以你仍然需要开发可靠的、声明性的系统来管理这些被托管的Kubernetes集群。并且，依靠该系统来抽象大部分集群运行的细节也是一个不错的方案。
2.1.1 托管服务
由于管理Kubernetes的部署和生命周期需要大量的技术设计和实现，因此，使用云服务商提供的Kubernetes托管服务可以节省很大的工程量。但是，请记住Kubernetes只是应用平台的一个组件——容器编排器。
本质上，通过托管服务，你可以获得一个随意添加工作节点的Kubernetes控制平面，从而减少了控制平台扩展、保证可用性和管理的工作。此外，如果你已经使用了一个云服务商的现有服务，那么你将会轻松很多。例如，如果你使用了Amazon Web Services （AWS），并且已经使用Fargate进行无服务器计算，使用Identity and Access Management（IAM）进行基于角色的访问控制，使用CloudWatch进行监控，那么你就可以利用上述服务配合Elastic Kubernetes Service（EKS）来解决你的应用平台中的一些问题。
它与托管数据库服务没有什么不同。如果你最关注的是一个服务于业务需求的应用程序，而那个应用程序需要一个关系数据库，但是你不能为员工提供一个专门的数据库管理员，那么付钱给云服务商来为你提供一个数据库则是一件很便捷的事。托管服务的服务商将为你管理可用性、备份和升级。显然，这是很方便的。但是，一如既往，这是有代价的。
2.1.2 自建服务
使用托管Kubernetes服务所带来的便利是有代价的，即缺乏灵活性和自由。其中一部分原因是云服务商的技术锁定。一般来说，托管服务通常由云基础设施服务商提供。如果你投入巨资使用某个服务商的基础设施，你很可能会在日后设计系统并使用其他服务商的服务时遇到兼容性问题。更令人担忧的是，如果它们在未来提高价格或服务质量下滑，你可能会发现自己掉入了一个黑洞。那些你花钱请来的专家，现在变成了可以掌握你的命运的“死神”。
当然，你也可以通过使用多个服务商的托管服务来实现多样化，但它们提供Kubernetes功能的方式会有不同，这种不一致的现象会让人陷入一种尴尬的境地。
出于这个原因，你可能更喜欢自己搭建Kubernetes。因为Kubernetes上有大量的功能可以配置，而这种可配置性使它非常灵活和强大。如果你把时间或金钱投入学习和管理Kubernetes，你将完全控制应用平台。没有你不能实现的功能，也没有你不能满足的要求。而且你将能够在不同的基础设施供应商之间无缝切换，无论是公共云服务商，还是你自己在私人数据中心的服务器。一旦考虑到不同基础设施的不一致性，你的应用平台中所提供的Kubernetes功能将是一致的。而使用你的平台的开发者并不会关心，甚至可能都不知道是谁在提供底层基础设施。
请记住，开发人员只关心平台的功能，而不是底层基础设施或提供者。如果你能控制可用的功能，并且你提供的功能在不同的基础设施供应商之间是一致的，你就可以灵活地为开发者提供非常棒的体验。你可以控制你使用的Kubernetes版本、访问控制面板组件的所有标志和功能、访问底层机器和安装在上面的软件以及写入磁盘的Pod静态配置文件。你将拥有一个强大且危险的工具，但千万不要忽视你深度理解这个工具的义务，否则它就有可能被用来伤害你自己和他人。
2.1.3 做出决定
当你开始构建Kubernetes生产环境时，你会发现通往成功的道路是非常模糊的。如果你现在已经开始在Kubernetes托管服务和构建自己的集群之间进行抉择，那么你离Kubernetes生产之旅的开始就已经很近了。而且，决定使用托管服务还是自己搭建是非常重要的，因为它将对你的业务产生长期的影响。因此，这里有一些指导原则来帮助你。
在以下情况下你应该倾向于托管服务：
•了解Kubernetes对你来说非常艰难。
•管理一个对你的业务成功至关重要的分布式软件系统的责任听起来很危险。
•云服务商提供的功能所带来的限制是可以接受的。
•你相信托管服务的云服务商会响应你的需求并成为一个好的商业合作伙伴。
在以下情况下你应该倾向于自己搭建Kubernetes：
•云服务商施加的限制让你感到不安。
•你对提供云计算基础设施的企业没有信心。
•你对自己搭建强大的Kubernetes平台感到兴奋。
•你渴望有机会利用这个神奇的容器编排器，为你的开发人员提供便捷。
如果你决定使用托管服务，可以考虑仅阅读2.7节和2.9节。如果你正在自己构建集群，请继续阅读。接下来，我们将进一步探讨你应该考虑的部署模式和工具。