☰

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

潜在的に機能するインフラストラクチャ自動化には、次の 5 つの異なる要素があります。

  • IPからノードへの割り当て
  • DNS名からIPへのマッピング
  • メンバーマッピングへの負荷分散
  • Kubernetes サービス IP からポッド メンバーへのマッピング、場合によってはロード バランサーへのマッピング
  • Kubernetes イングレス

彼らのうちのいくつかは、他の誰かを駆動することができます。彼らは必ずしも全員がうまく連携してプレイするわけではなく、互いに競争することもできます。

私は Amazon の Kubernetes ランタイムを詳しく調べたことはありませんが、それ以外に、やりたい簡単なことを行うには、少なくとも 3 つのオプションがあることを知っています。

  • kubernetes から始めて、サービス type=LoadBalancer を作成し、ELB を作成します。これにより、サブドメインをマップするための route53 の CNAME レコードを作成できる一意のドメイン名が提供されます。ELB メンバーシップは、ポッド IP でサービスが更新され続けるのと同様の自動化を使用して更新されます。レイヤー 4 およびレイヤー 7 のリクエスト バランシングにはいくつかの制限があります。
  • ELB から開始し、ELB のメンバーとして k8s EC2 ノードを追加し、デーモンセットとして 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 は、Ingress リソース、コントローラー、および構成を取得するプロキシで構成されます。コントローラーは、クラスターの Ingress リソースの変更を監視し、それをプロキシ固有の構成に変換してから、プロキシをリロードします。

nginx イングレス コントローラは、nginx を使用してこのメ​​カニズムを実装したものです。haproxy やその他のプロキシを使用する他の多くのコントローラもあります。

これを行うには多くの方法があるようですが、現時点で最良（かつ最も簡単）な方法は何でしょうか?

上記を参照してください。おそらく他の方法もあるでしょう。

関連情報