☰

连接AWS route53 域名和 K8s LoadBalancer 服务

tag-icon • tag-icon amazon-web-services kubernetes network-design
连接AWS route53 域名和 K8s LoadBalancer 服务

我正在尝试做什么
创建一个具有映射到 DNS 地址的单个 API 网关服务的 Kubernetes 环境。

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

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

然后我开始阅读一些看起来相当不错的资源K8s 入口（还） 和Nginx 反向代理服务。 （最后还有这个）（还有这个）。

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

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

编辑：

我实现了 Jonah 答案中的选项 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）

答案1

基础设施自动化有五个不同的部分可能发挥作用：

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

其中一些可以驱动其他一些。它们不一定都能很好地协同工作，并且会相互竞争。

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

  • 从 kubernetes 开始，创建一个服务 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 Ingress 服务之间有什么区别？因为对我来说，这两个词似乎在这里可以互换使用。

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

Kubernetes Ingress 是一种抽象概念，可通过多种不同方式实现。Ingress 包括入口资源、控制器和接受配置的代理。控制器监视集群中的入口资源变化，将其转换为特定于代理的配置，然后重新加载代理。

nginx 入口控制器是使用 nginx 实现的此机制。还有许多其他使用 haproxy 和其他代理的入口控制器。

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

参见上文。可能还有其他方法。

相关内容