假设我有一个使用EC2实例（VM）部署在AWS中的Web应用程序（Apache httpd服务器）。使用EC2用户数据执行应用程序部署。
或者，我可以对我的Web应用程序进行docker化。使用EKS或自定义设置在EC2实例上部署Kubernetes集群。我们还可以将AWS Fargate用于无服务器功能。
在此处将第二种方法与Kubernetes一起使用的利弊是什么？
答案 0 :(得分：4)
如果您是开发人员，则将应用程序部署到EC2计算机上，则通常还负责维护和修补EC2实例。问题在于，开发人员通常对此并不擅长，并且通常对此也不太感兴趣。监视和修补Linux计算机或对网络进行故障排除不是他们的专业知识。
使用Kubernetes，您作为开发人员仅对应用程序容器负责，并且您的应用程序运行状况良好。但是另一个团队，例如平台团队可能负责基础架构，例如EC2实例和联网。或与Fargate一样，云提供商可以对此负责。
让开发人员承担更少的责任，但仍然拥有用于自助服务部署的API，这使他们非常高效。
但是当开始使用Kubernetes作为平台时，您将承担更多的复杂性。您需要足够大的组织才能做到这一点。除非您使用更高级别的服务，例如Google Cloud Run。
关于这一切的好话是Kubernetes is Not Your Platform, It's Just the Foundation
答案 1 :(得分：0)
Kubernetes是一个容器编排器，用于管理容器化工作负载的生命周期。无论是托管的还是内部部署的，运行Kubernetes集群都有很多操作开销。
Kubernetes使中大型容器化工作负载受益。对于单个整体式应用程序，负面影响远远大于使用Kubernetes的好处。
对于您的用例，建议使用托管应用程序服务。如果您希望拥有更多控制权，那么滚动自己的EC2基础结构将是下一个最佳建议。
说Kubernetes对开发人员来说更容易是错误的说法。实际上，Kubernetes是一个非常复杂且成本高昂的系统，无法有效运行。安全有效地运行Kubernetes集群有很多操作开销。
您将需要维护节点，使用昂贵的负载平衡器来暴露流量，实施设计以处理持久性数据和会话管理。
此外，容器也不能神奇地删除操作任务。它们仍然容易出现漏洞，必须存在一个工作流才能定期使用更新后的基础图像来更新您应用的容器图像。
另一个挑战是容器被设计为临时的，这意味着状态更改必须持久保存到连接的卷上，并且会话管理必须外部化。所有这些都增加了更多的复杂性和开销。