我有两个前端，一个是基于VueJS的，另一个是传统的服务器端渲染前端。这两个前端都使用cookie来识别用户，用户数据存储在MongoDB上。我想部署一个前端的2个或多个示例（由公众使用）和另一个前端的一个示例（仅由员工使用）。
我还想通过AWS Cloudfront部署面向公众的前端静态资产。
如何部署到Kubernetes上面的场景？我是否在Kubernetes中将前端部署到多个Pod？
我是否在Kubernetes上将Cloudfront部署到Pod？
如果我使用AWS托管的Kubernetes，EKS，在上述场景中是否会发生任何变化？
如何在AWS Cloudfront上部署动态资产（从MongoDB数据库提取）？
Java Sping Boot API后端使用OAuth 2来认证用户（在VueJS前端登录表单上）。VueJS前端使用JWT访问/刷新令牌，而Sping Boot 前端在其后端使用固定的API用户向API后端发出API请求，以获取向客户显示的内容。
2条答案
按热度按时间iszxjhcz1#
你在这里问的是一个架构设计问题，并且有最佳云托管的先决条件。简而言之，您需要非常严格地对待Web和API关注点的分离。
单页应用程序
Web静态内容应通过内容交付网络（CDN）部署，例如部署到全球50个地点。在这里使用容器通常是矫枉过正的，AWS Cloudfront这样的系统将在不需要太多技术努力的情况下为Web下载提供全球同等的性能。
Cookie后端
这些需要运行时，所以如果你使用网站技术，例如Sping Boot ，你将无法以首选的方式使用CDN。AWS Cloudfront仅托管静态内容，而不是运行时。
接口
通常首选使用Kubernetes部署API和其他后端组件，以保持代码的可移植性，并在API旁边托管最佳支持组件。
代币处理器图案
API可以为单页应用程序执行cookie发布，而不需要网站后端。这很棘手，但请参阅this article以了解它的工作原理。
动态资产**
在这个模型中，任何需要保护的东西都最好通过API而不是Cloudfront来管理。动态图像等可以随时推送到Cloudfront。如果您有特殊原因，也可以将API发布的Cookie发送到Cloudfront，并在lambda edge函数中使用它们。
我的示例
我的Single Page App只在浏览器中使用最新的安全cookie，并且也通过Cloudfront部署-有一个在线版本，你可以运行，并附带一些博客文章。
概要
为Web应用程序启用最佳云托管需要努力，部分原因是目前的安全最佳实践是SPA仅在浏览器中使用最新的安全Cookie。
您必须为网站使用容器托管，如果最适合您当前的架构，您可以选择将其用于SPA。尽管如此，通过Cookie保护的SPA使用Cloudfront是可能的。
ktca8awb2#
这里似乎有一些误解，所以让我先澄清几件事：
AWS Cloudfront是一个内容交付网络（CDN），与Kubernetes无关。AWS在世界各地部署了大量服务器，这些服务器可以简单地复制您想要与客户共享的任何静态内容（例如徽标、常见问题解答等）。通过将其复制到世界上几乎每个角落，无论您的客户在哪里，都会有一台服务器靠近他们，这会导致他们的加载时间更快，因为他们不必与世界另一端的服务器进行通信。
我是否在Kubernetes上将Cloudfront部署到Pod？
因此，不会在Kubernetes上部署Cloudfront。你所要做的就是告诉Cloudfront你的源服务器，它基本上只是你的静态资产所在的地方。大多数情况下，最简单的方法是将这些资产放在S3存储桶上。因为有一个非常好的文档在这一部分，我不会复制这样做的每一步在这里。"How to get started with Amazon CloudFront" site特别指导您逐步完成Cloudfront的设置和配置。
关于Kubernetes：
Kubernetes是一个容器编排器。这听起来比实际上复杂多了。从本质上讲，它意味着它将为您管理容器。重新启动失败的，它们之间的负载平衡等等。容器被定义为Pod的一部分。虽然在一个Pod中有可能（并且对于某些架构模式是必要的）有多个容器，但大多数情况下Pod和容器之间的比例为1：1。因此，每个应用程序通常部署在自己的Pod中，并由一个容器组成。
如何部署到Kubernetes上面的场景？我是否在Kubernetes中将前端部署到多个Pod？
这取决于你的应用程序，你没有给予太多的信息（除了提到VueJS）。在大多数情况下，VueJS非常适合在CDN上部署，因为它只是静态JavaScript。因此，除非有特定的原因不将它们部署在CDN上，否则没有理由将它们部署到Kubernetes上。
但是，如果出于某种原因必须将其部署在Kubernetes上，只需创建一个Deployment。Deployment是一个Kubernetes对象，它为您创建（ReplicaSets，然后反过来创建）Pod。当创建一个Deployment（这只是一个YAML文件，你使用
kubectl apply -f <your-file>发送到Kubernetes）时，你告诉它Pod的样子，Kubernetes会为你处理剩下的事情。一旦创建了Pod，它们只能从Kubernetes集群中访问。要将它们暴露于外部世界，有两种选择：如果我使用AWS托管的Kubernetes，EKS，在上述场景中是否会发生任何变化？
使用托管的Kubernetes（如EKS）是迄今为止最简单的方法，因为它可以自动为您创建具有公共IP地址的LoadBalancers。如果有什么不使用EKS的话，会让事情变得更复杂。然后你必须自己管理你的LoadBalancer和/或Ingress（自己设置一切，维护它，...）。