将 AWS route53 域名与 K8s LoadBalancer 服务连接起来

Question

我正在尝试
使用映射到 DNS 地址的单个 API 网关服务创建 Kubernetes 环境。

我做了什么：
1）我去了 AWS Route53 服务并创建了一个子域。
2) 该子域似乎有一个静态 IP。我通过ping域名获得了这个IP。
3) 我已经在 AWS 上使用 kops设置了一个Kubernetes 集群。
4）我有一个网关服务，它的端点在 k8s 基础设施中访问微服务。
此服务的类型为LoadBalancer，其中loadBalancerIP等于上面的静态 IP。

问题：
使用上述设置，服务无法使用Failed to ensure load balancer for service default/gateway-service: LoadBalancerIP cannot be specified for AWS ELB.

然后我去阅读关于K8s Ingress ( Also ) 和Nginx 反向代理服务的非常好的资源。（最后是这个）（也是这个）。

之前也有人问过我的错误，答案似乎又在我的 API 网关和外部世界之间放置了另一层。
然后在阅读了很多关于 Nginx Ingress 控制器的内容后，我真的很困惑。

我的问题
a) 除了兼容性之外，是否有更大的理由在网关和外部世界之间设置另一层？
b) 我尝试在谷歌云平台上工作（这是一个 AWS 部署特定问题）
c) Nginx 入口控制器... Nginx 反向代理和 Kubernetes 入口服务有什么区别？因为对我来说，这些词在这里似乎可以互换使用。
d) 似乎有很多方法可以做到这一点，目前最好（也是最简单）的方法是什么？

编辑：

我实施了乔纳回答的选项 1。这是配置，以防有人想要复制粘贴。

网关服务.yaml :

apiVersion: v1
kind: Service
metadata:
  name: gateway-service
spec:
  ports:
    - name: "gateway"
      port: 80
      targetPort: 5000
  selector:
    app: "gateway"
  type: LoadBalancer
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: "gateway"
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: "gateway"
    spec:
      containers:
        - image: <account_nr>.dkr.ecr.us-east-1.amazonaws.com/gateway
          imagePullPolicy: Always
          name: "gateway"
          ports:
            - containerPort: 5000
              protocol: "TCP"

---

然后，在 AWS Route53 中创建子域：

1) 创建域
2) New Record Set
3) 类型A(IPv 4)
4) 别名yes
5) 选择与服务的外部端点匹配的别名目标。( kubectl describe services gateway-service | grep LoadBalancer)

Answer 1

有五种不同的基础设施自动化可能在起作用：

• ip到节点分配
• dns 名称到 ip 的映射
• 负载均衡到成员映射
• kubernetes 服务 ip 到 pod 成员映射，有时到负载均衡器
• Kubernetes入口

其中一些可以驱动其他一些。他们不一定都在一起玩得很好，并且可以相互竞争。

我还没有真正研究过亚马逊的 kubernetes 运行时，但除此之外，为了做你想做的简单事情，我知道至少有 3 个选项：

• 从 kubernetes 开始，创建一个 service type=LoadBalancer 让它创建一个 ELB。这将为您提供一个唯一的域名，您可以在 route53 中创建一个 CNAME 记录以将您的子域映射到该域名。ELB 成员将使用类似的自动化进行更新，因为使用 pod ips 保持服务更新。第 4 层和第 7 层请求平衡有一些限制。
• 从一个 ELB 开始，添加 k8s EC2 节点作为 ELB 的成员，并作为守护进程运行 ingress。这方面有很多变体，但这意味着确保 ELB 成员身份正确的责任与 EC2 上 k8s 的管理有关，无论是自动还是手动。但这提供了对第 7 层流量路由的其他控制点。
• 从 kubernetes 开始，使用名为 route53-mapper 的工具从服务资源上的注释驱动 route53 配置。

https://github.com/kubernetes/kops/tree/master/addons/route53-mapper

这是第一个的更简单版本，包括 TLS，但将它用于 TLS 似乎有点疯狂，因为它似乎需要将证书保存在服务注释中，而不是它们所属的位置，秘密。

回应：

除了兼容性之外，是否还有更大的理由在网关和外部世界之间设置另一层？

没有要求，这种方法解决了 ELB 和 k8s 都拥有自动化的问题。通常，人们不想要竞争的自动化所有者。

我尝试过的在 Google Cloud Platform 中是否有效（这是 AWS 部署特定的问题吗）

gcloud 自动化不同，它的负载均衡器可以给 ip，因为它有单独管理的 ip 分配。所以在某种程度上，这是 AWS 特有的问题。

Nginx 入口控制器... Nginx 反向代理和 Kubernetes 入口服务有什么区别？因为对我来说，这些词在这里似乎可以互换使用。

它们是可以互换的。一个是抽象的，另一个是具体的。

Kubernetes Ingress 是可以以多种不同方式实现的抽象。Ingress 包括入口资源、控制器和接受配置的代理。控制器监视集群的入口资源更改，将它们转换为特定于代理的配置，然后重新加载代理。

nginx 入口控制器是使用 nginx 实现的这种机制。还有很多其他的，使用 haproxy 和其他代理。

似乎有很多方法可以做到这一点，目前最好（也是最简单）的方法是什么？

看上面。可能还有其他方法。