將 AWS route53 域名與 K8s LoadBalancer 服務連接

我正在嘗試

使用映射到 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）我嘗試過的是否可以在 Google Cloud Platform 中工作（這是 AWS 部署特定的問題）

c） Nginx 入口控制器…… Nginx 反向代理和 Kubernetes 入口服務有什麼區別？因為對我來說，這些詞在這裡似乎可以互換使用。

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)

有五種不同的基礎設施自動化可能在起作用：

• ip到節點分配
• dns名稱到ip映射
• 負載均衡到成員映射
• kubernetes 服務 ip 到 pod 成員映射，有時到負載均衡器
• Kubernetes入口

其中一些可以驅動其他一些。他們不一定都在一起玩得很好，並且可以相互競爭。

我還沒有真正看過亞馬遜的 kubernetes 執行時，但除此之外，為了做你想做的簡單事情，我知道至少 3 個選項：

• 從 kubernetes 開始，創建一個 service type=LoadBalancer 讓它創建一個 ELB。這將為您提供一個唯一的域名，您可以在 route53 中創建 CNAME 記錄以將您的子域映射到。ELB 成員資格將使用與使用 pod ip 更新服務類似的自動化進行更新。第 4 層和第 7 層請求平衡存在一些限制。
• 從 ELB 開始，添加 k8s EC2 節點作為 ELB 的成員，並將 ingress 作為 daemonset 執行。這方面有很多變體，但這意味著確保 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 自動化是不同的，它的負載均衡器可以被賦予 ips，因為它有單獨管理的 ip 分配。所以在某種程度上，這是一個 AWS 特有的問題。

Nginx 入口控制器… Nginx 反向代理和 Kubernetes Ingress 服務有什麼區別？因為對我來說，這些詞在這裡似乎可以互換使用。

它們是可以互換的。一個是抽象的，另一個是具體的。

Kubernetes Ingress 是可以通過多種不同方式實現的抽象。Ingress 包括入口資源、控制器和進行配置的代理。控制器監視集群的入口資源更改，將它們轉換為特定於代理的配置，然後重新載入代理。

nginx 入口控制器是使用 nginx 實現的這個機器。還有很多其他的，使用 haproxy 和其他代理。

似乎有很多方法可以做到這一點，目前最好（也是最簡單）的方法是什麼？

往上看。可能還有其他方法。

引用自：https://serverfault.com/questions/899180