☰

將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）我已經設定了一個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 入口（也） 和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開始，建立一個service type=LoadBalancer，讓它建立一個ELB。這將為您提供一個唯一的域名，您可以在 Route53 中為其建立 CNAME 記錄以將您的子網域對應到。 ELB 會員資格將使用類似的自動化進行更新，就像使用 pod ip 更新服務一樣。第 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 Automation則不同，它的負載平衡器可以給ips，因為它有單獨管理的ip分配。所以在某種程度上，這是 AWS 特有的問題。

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

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

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

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

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

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

相關內容