如何在kubernetes上部署前端，以及如何与AWS Cloudfront一起工作？

Question

我有两个前端，一个是基于VueJS的，另一个是传统服务器端呈现的前端。这两个前端都使用cookie来识别用户，用户数据存储在MongoDB上。我想部署两个或多个前端实例(由公众使用)和另一个前端实例(仅供员工使用)。

我还想通过AWS Cloudfront部署面向公共的前端静态资产。

如何部署到上述场景中的Kubernetes？我是否在Kubernetes中将前端部署到多个Pods？

我是否将Cloudfront部署到Kubernetes的Pods上？

如果我使用AWS管理的Kubernetes，EKS，在上面的场景中有什么变化吗？

如何将动态资产(从MongoDB数据库中提取)部署到AWS云前沿？

后端使用OAuth 2来引诱用户(在VueJS前端登录表单上)。VueJS前端使用JWT访问/刷新令牌，而SpringBoot前端在后端使用固定的API用户向API后端发出API请求以获取内容以显示给客户。

Answer 1

您在这里要问的是一个架构设计问题，这是优化云托管的先决条件。简单地说，您需要非常严格地对待-- Web的分离和API与有关。

单页应用程序

Web静态内容应该通过内容交付网络(CDN)部署，例如部署到50个全球位置。在这里使用容器通常是过分的，像AWS Cloudfront这样的系统可以在不需要花费太多技术的情况下为web下载提供全球平等的性能。

COOKIE后端

这些都需要运行时，所以如果您使用网站技术(如Spring )，您将无法以首选的方式使用CDN。AWS Cloudfront只托管静态内容，而不是运行时。

API

通常倾向于使用Kubernetes部署API和其他后端组件，以便保持代码的可移植性，并与API一起承载最好的支持组件。

令牌处理程序模式

API可以为单个页面应用程序执行cookie发布，而不需要网站后端。这是一个棘手的问题，但是要了解它的工作原理，请参阅这篇文章。

动态资产

在这个模型中，任何需要安全的东西都最好通过API而不是Cloudfront来管理。动态图像等可以随时推送到云阵。如果有特殊原因，也可以将API发布的cookie发送到Cloudfront，并在lambda边缘函数中使用它们。

矿山实例

我的单页应用程序只使用浏览器中最新的安全cookies，并且还通过Cloudfront部署--您可以运行一个在线版本，并附带一些博客文章。

我也有一个端到端SPA + API Kubernetes回购，我将在今年晚些时候将它的相关部分部署到EKS。在开发计算机上，web静态内容是通过运行Express web服务器的容器提供的，尽管我在部署到EKS时将使用Cloudfront作为web主机。

摘要

为web应用程序启用最佳云托管需要付出努力，部分原因是当前的安全最佳实践是SPA只使用浏览器中最新的安全cookie。

您将不得不使用容器托管的网站，你可以选择使用它的温泉，如果这最适合你目前的架构。但是，通过努力，可以将Cloudfront用于cookies所保护的温泉疗养地。

Answer 2

似乎有些误会，所以让我先澄清几点：

AWS Cloudfront是一个内容传送网络(CDN)，与Kubernetes无关。AWS在世界各地都有很多服务器，它们只是简单地复制您想要与客户共享的静态内容(例如徽标、常见问题等)。通过将其复制到世界的几乎每一个角落，无论您的客户在哪里，都会有一台服务器靠近它们，从而使它们的加载时间更快，因为它们不需要与世界另一端的服务器通信。

我是否将Cloudfront部署到Kubernetes的Pods上？

因此，没有人在库伯内特斯部署Cloudfront。您所要做的就是告诉Cloudfront您的原始服务器，这基本上是您的静态资产所处的位置。大多数情况下，最简单的方法是将这些资产放在S3桶上。由于这方面有一个非常好的文件，我不会在这里复制每一步。特别是，“如何开始使用亚马逊CloudFront”网站将指导您逐步完成Cloudfront的设置和配置。

现在关于Kubernetes：

库伯奈特斯是个集装箱策划人。这听起来比现在复杂多了。本质上，它意味着它将为您管理容器，即重新启动失败的容器、它们之间的负载平衡等等。容器被定义为Pods的一部分。虽然在一个Pod中有多个容器是可能的(对于某些架构模式也是必要的)，但是大多数情况下，Pods和容器之间的比例是1:1。因此，每个应用程序通常都部署在自己的Pod中，并由一个容器组成。

如何部署到上述场景中的Kubernetes？我是否在Kubernetes中将前端部署到多个Pods？

这取决于您的应用程序，您没有提供太多的信息(除了提到VueJS)。在大多数情况下，VueJS很适合CDN上的部署，因为它只是静态javascript。因此，除非有特定的理由不将它们部署到CDN上，否则就没有理由将它们部署到Kubernetes上。

但是，如果出于任何原因，它必须部署在Kubernetes上，那么只需创建一个部署。部署是一个Kubernetes对象，它为您创建(ReplicaSets，然后创建) Pods。在创建部署(这只是一个使用kubectl apply -f <your-file>发送给Kubernetes的YAML文件)时，您可以告诉它Pods会是什么样子，而Kubernetes将为您处理其余的内容。一旦创建了Pods，它们就只能从Kubernetes集群中访问。要将它们暴露在外界面前，有两种选择：

• 创建具有LoadBalancer类型的服务
• 创建一个Ingress对象(然后为您创建一个LoadBalancer )

如果我使用AWS管理的Kubernetes，EKS，在上面的场景中有什么变化吗？

使用托管Kubernetes (如EKS)是迄今为止最简单的方法，因为它可以为您自动创建具有公共IP地址的LoadBalancers。如果没有使用EKS的话，事情会变得更加复杂。然后，您必须亲自管理您的LoadBalancer和/或大会(自行设置所有内容，维护它，.)。