因此，您决定在AWS中运行Kubernetes工作负载。 正如我们在设置AWS EKS 之前所看到的，需要很多耐心和头痛。 您也许可以使其正常运行。 对于其他用户，您应该从Weaveworks中 eksctl 工具 。
现在您已经有了一个Kubernetes集群，您想要开始在其上部署微服务，并开始向您的客户和组织的其他部分公开和集成API和服务。 在Solo.io，我们开源了一个基于名为Gloo的Envoy Proxy构建的微服务网关 。 Gloo是Envoy的一个平台不可知的控制平面，目的是为了理解“功能”级别的调用（认为是HTTP路径/方法/标头，gRPC调用或Lambda函数的组合），目的是组成它们并为北向构建更丰富的API南方和东西向交通。 GLOO也是服务网技术，如高度互补Istio 。
Gloo的功能包括：
- 函数路由（REST方法，gRPC端点，Lambda / Cloud函数）
- 细粒度的流量转移（功能金丝雀，功能加权路由等）
- 请求/内容转换（隐式和显式）
- 授权/认证
- 限速
- gRPC
- Web套接字
- SOAP / WSDL
- 深度指标收集
- 用于聚合数据API的GraphQL引擎
- 强大的与平台无关的发现机制
Gloo具有非常深的Kubernetes原生支持，并且可以作为Kubernetes集群的集群入口运行。 附带说明一下，对于Ingress急需的澄清，API Gatweay，API管理（甚至服务网格）请看博客文章“ API网关正在经历身份危机”
为了帮助人们在AWS EKS中使用Gloo，我们不得不浏览选择和公开Kubernetes中运行的服务的相当复杂的选择。 对于其他Kuberentes本地入口，API或功能网关，这些选项将相同。 由于AWS EKS是Kubernetes，因此我们可以通过以下方式公开类似Gloo的微服务/ API网关：
- Kubernetes 入口资源
- 类型为LoadBalancer的Kubernetes 服务
- Kubernetes 服务作为NodePort （不建议用于生产环境）
在Gloo上，我们还在致力于本机OpenShift的支持 ，应该尽快提供。
同时，如果您正在AWS EKS上运行工作负载，则可能对如何利用微服务网关或是否应仅使用AWS托管AWS API Gateway存有疑问。
让我们在这里探索选项。
将AWS API Gateway与您的EKS集群一起使用
AWS EKS实际上是Kubernetes的托管控制平面，您可以自己运行工作程序节点。 一种典型的设置是在私有VPC中拥有您的工作节点（EC2主机），并使用所有内置的VPC隔离，安全组，IAM策略等。一旦开始将工作负载/微服务部署到Kubernetes集群，您可能希望揭露他们和/或您的客户/消费者/合作伙伴等你的第一个问题可能是一起的“好了，因为我使用AWS，它应该只是超级好用的线条提供了一个很好的去耦API AWS我的Kubernetes集群前面的API网关 ”。
在开始挖掘时，您意识到将AWS API Gateway连接到您的EKS集群并非一帆风顺。 您会发现，AWS API Gateway在其自己的VPC中运行，并且受到完全管理，因此您看不到有关其基础架构的任何详细信息。 幸运的是，使用AWS API Gateway，您可以执行“私有集成”以连接到在您自己的VPC中运行的HTTP端点 。
专用集成允许您在专用VPC中公开网络负载平衡器（NLB） ，可以终止API网关与VPC集成的流量。 因此，基本上，AWS API网关会创建到VPC中运行的NLB的VpcLink 。
太好了！ 网络负载平衡器是一个非常强大的负载平衡器，但是即使它在VPC内运行，它也不了解或不了解Kubernetes集群（即Kubernetes Pods）中运行的工作负载。 让我们改变这个。 此时，我们需要部署某种Kubernetes Ingress端点，该端点了解如何路由到Pod 。 一些人可能会倾向于此时使用本地Kubernetes Ingress资源，或者您实际上可以只使用暴露为“ LoadBalancer”的单个Kubernetes服务。 实际上，我们可以更进一步。 在EKS的Kubernetes服务中指定LoadBalancer时创建的默认负载均衡器是经典负载均衡器 。 此问题是API网关无法路由到经典负载均衡器。 我们需要在EKS内运行的Kubernetes服务来创建网络负载平衡器 。 例如，此配置将创建经典的负载均衡器：
apiVersion: v1
kind: Service
metadata:
name: gloo
namespace: default
annotations: {}
spec:
ports:
- name: http
port: 80
protocol: TCP
targetPort: 80
selector:
app: gloo
type: LoadBalancer 当我们在EKS中创建此服务时，添加注释service.beta.kubernetes.io/aws-load-balancer-type: "nlb"将使AWS创建网络负载平衡器：
apiVersion: v1
kind: Service
metadata:
name: gloo
namespace: default
labels:
app: gloo
annotations:
service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
spec:
externalTrafficPolicy: Local
ports:
- name: http
port: 80
protocol: TCP
targetPort: 80
selector:
app: gloo
type: LoadBalancer至此，我们已经正确配置了负载均衡器（私有VPC中的NLB）和AWS API Gateway的正确组合。 我们甚至可以在AWS API Gateway上启用AWS Web应用程序防火墙（WAF） 。 唯一的问题是，我们在边缘具有AWS API Gateway的功能（和成本），但它仍然无法理解Kubernetes集群中正在运行的工作负载。
当我们想要执行诸如Canary发布，API聚合，功能路由和内容转换之类的事情时，我们需要在Kubernetes集群中进行。 格洛为此解决了。 那么，您真的需要API网关-> NLB-> API网关吗？ 在这种情况下，您可以将网络负载平衡器升级到公共子网，让Gloo处理所有API网关路由，流量整形，速率限制，而不会丢失AWS API网关的任何功能（Lambda路由，AuthZ / N，Websockets等）。
替代设置
我们在上一节的开头假设是，使用EKS时，与替代解决方案相比，AWS API Gateway将更易于与Kubernetes集群集成。 我们发现情况并非如此。 但是，我们还有其他选择。 如果您使用的是EKS，则需要某种在Kubernetes中运行的API网关或微服务网关。 但是，我们如何获得到EKS集群的流量呢？ 如果我们想利用AWS Web Application Firewall（WAF）之类的东西怎么办？
鉴于各种类型的负载均衡器以及在AWS EKS中运行微服务/ API网关的权衡，我们拥有的选项归结为以下几点：
AWS API网关+专用VPC NLB +简单的Kubernetes入口
这与上一节相似，但是您没有选择使用像Gloo这样的强大的微服务网关，而是选择在Kubernetes中使用基本的入口控制器。 在这种情况下，您可以利用AWS API Gateay，拥有AWS Web Application Firewall之类的不错的东西，但是却失去了在EKS（pod）中运行的工作负载的保真度。
AWS API网关+专用VPC NLB +功能强大的Kubernetes微服务网关（例如Gloo）
这是上一节中的用例。 现在，您已经获得了微服务网关的功能，使其更接近于EKS中的工作负载，但是您的边缘处有冗余且昂贵的网关。 这样做的好处是您仍然可以利用AWS Web应用程序防火墙（WAF）。
公共NLB +功能强大的Kubernetes微服务网关（例如Gloo）
在这种情况下，我们避开了AWS API Gateway，只是使用了位于公共子网中的网络负载平衡器。 现在，微服务/ API网关的所有功能都靠近您在EKS中的工作负载，但是您丢失了Web应用程序防火墙（无法应用于NLB）。 如果您拥有自己的WAF，这可能不是一个坏的折衷。
公共ALB +私有NLB +功能强大的Kubernetes微服务网关（例如Gloo）
您可以使用Application Load Balancer（您可以应用AWS WAF）更好地控制面向公众的网络请求，并且仍将EKS流量保持私有状态，并通过私有NLB进行控制。 使用这种方法，您还可以通过CloudFormation集中管理所有TLS证书
作为Kubernetes集群专用的Kubernetes入口控制器+ Kubernetes API网关管理的公共ALB
您可以将Kubernetes Ingress与Application Load Balancer 3rd-party插件一起使用来管理Kubernetes中的ALB。 此时，您可以在EKS集群中本地和私有地运行API Gateweay，但由于我们使用的是ALB，因此仍可以利用WAF。 缺点是此功能由第三方插件提供， 您无法通过云形成来集中管理证书 。 也就是说，您必须使用Ingress批注来管理这些批注 。
结论
有许多选项可在AWS EKS中运行您的微服务/ API网关。 每种组合都需要权衡取舍，应仔细考虑。 我们专门构建了Gloo ，使其成为功能强大的跨平台，跨云微服务API网关。 这意味着在AWS，本地或任何其他云上运行时，您还有更多选择。 每个组织都会有其独特的约束，观点和选择。 我们认为，有很多不错的选择可以使微服务整体或本地混合部署成功部署到公共云。 如果您对此用例有其他建议， 请在Twitter或此博客的评论中与我联系@christianposta 。
翻译自: https://www.javacodegeeks.com/2019/02/exposing-running-microservices.html