假设我使用 EC2 实例 (VM) 在 AWS 中部署了一个 Web 应用程序（Apache httpd 服务器）。使用 EC2 用户数据执行应用程序部署。
或者，我可以将我的 Web 应用程序 dockerize。使用 EKS 或自定义设置在 EC2 实例上部署 Kubernetes 集群。我们还可以将 AWS Fargate 用于无服务器功能。
在 Kubernetes 中使用第二种方法的优缺点是什么？
【问题讨论】：
标签： amazon-web-services docker kubernetes amazon-ec2 amazon-eks
如果您作为开发人员将您的应用程序部署到 EC2 机器上，您通常还需要负责维护和修补 EC2 实例。问题在于，这是开发人员通常不擅长的事情，而且通常也不那么感兴趣。监控和修补 Linux 机器或排除网络故障不是他们的专长。
使用 Kubernetes，作为开发人员，您只需对应用程序容器负责，并且确保您的应用程序运行良好。但是另一个团队，例如平台团队可能负责底层基础设施，例如EC2 实例和网络。或者与 Fargate 一样，云提供商可以对此负责。
让开发人员的责任更少，但仍然拥有用于自助部署的 API，这让他们非常高效。
但是当开始使用 Kubernetes 作为平台时，您会面临更多的复杂性。为此，您需要成为一个足够大的组织。除非您使用更高级别的服务，例如Google Cloud Run.
关于这一切的好话是Kubernetes is Not Your Platform, It's Just the Foundation
【讨论】：
Kubernetes 是一个容器编排器，用于管理容器化工作负载的生命周期。运行 Kubernetes 集群（无论是托管还是本地）都会产生大量运营开销。
Kubernetes 有利于大中型容器化工作负载。对于单个单体应用来说，使用 Kubernetes 的弊大于利。
对于您的用例，建议使用托管应用程序服务。如果您希望拥有更多的控制权，那么滚动您自己的 EC2 基础架构将是下一个最佳建议。
说 Kubernetes 对开发人员来说更容易是错误的说法。实际上，Kubernetes 是一个非常复杂且成本高昂的系统，无法有效运行。安全有效地运行 Kubernetes 集群需要大量运营开销。
您将需要维护节点，使用昂贵的负载平衡器来公开流量，实施设计以处理持久数据和会话管理。
此外，容器不会神奇地移除操作任务。它们仍然容易出现漏洞，并且必须存在一个工作流来定期使用更新的基础镜像来更新您应用的容器镜像。
另一个挑战是容器被设计为短暂的，这意味着状态更改必须持久化到附加卷，并且会话管理必须外部化。所有这些都增加了更多的复杂性和开销。
【讨论】：