Verbinden Sie den AWS Route53-Domänennamen mit dem K8s LoadBalancer Service

Verbinden Sie den AWS Route53-Domänennamen mit dem K8s LoadBalancer Service

Was ich versuche zu tun
Erstellen Sie eine Kubernetes-Umgebung mit einem einzelnen API-Gateway-Dienst, der einer DNS-Adresse zugeordnet ist.

Was habe ich getan:
1) Ich ging zum AWS Route53-Dienst und erstellte eine Subdomain.
2) Diese Subdomain scheint eine statische IP zu haben. Ich habe diese IP erhalten, indem ich den Domänennamen angepingt habe.
3) Ich habe eineKubernetes-Cluster auf AWS mit kops.
4) Ich habe einen Gateway-Dienst, dessen Endpunkte auf Mikrodienste innerhalb der K8s-Infrastruktur treffen.
Dieser Dienst ist vom Typ LoadBalancer, wobei die loadBalancerIPder statischen IP von oben entspricht.

Das Problem:
Mit dem obigen Setup kann der Dienst nicht erstellt werden Failed to ensure load balancer for service default/gateway-service: LoadBalancerIP cannot be specified for AWS ELB.

Dann lese ich scheinbar ziemlich gute Quellen überK8s-Eindringling(Auch) und einNginx-Reverseproxydienst. (Und dieses zum Schluss) (Auch dieses).

Mein Fehlerwurde auch schon mal gefragt, und wieder scheint die Antwort eine weitere Schicht zwischen meinem API-Gateway und der Außenwelt zu platzieren.
Nachdem ich dann viel über Nginx Ingress-Controller gelesen habe, bin ich wirklich verwirrt.

Meine Fragen
a) Gibt es außer der Kompatibilität einen wichtigeren Grund, eine weitere Schicht zwischen dem Gateway und der Außenwelt einzurichten?
b) Würde das, was ich versucht habe, in der Google Cloud Platform funktionieren (Ist das ein spezifisches Problem der AWS-Bereitstellung)?
c) Nginx-Ingress-Controller... Was ist der Unterschied zwischen einem Nginx-Reverse-Proxy und dem Kubernetes-Ingress-Dienst? Denn mir scheinen die Wörter hier synonym verwendet zu werden.
d) Es scheint so viele Möglichkeiten zu geben, dies zu tun. Was ist derzeit die beste (und einfachste) Methode?

BEARBEITEN:

Ich habe Option 1 aus Jonahs Antwort implementiert. Hier sind die Konfigurationen, falls jemand etwas kopieren und einfügen möchte.

gateway-service.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"

Erstellen Sie dann die Subdomäne in AWS Route53:

1) Domäne erstellen
2) New Record Set
3) Typ A(IPv 4)
4) Alias yes
​​5) Wählen Sie das Alias-Ziel aus, das dem externen Endpunkt des Dienstes entspricht. ( kubectl describe services gateway-service | grep LoadBalancer)

Antwort1

Es können fünf verschiedene Aspekte der Infrastrukturautomatisierung zum Tragen kommen:

  • IP-zu-Knoten-Zuweisung
  • Zuordnung von DNS-Namen zu IP
  • Lastverteilung zur Mitgliederzuordnung
  • Kubernetes-Service-IP zur Zuordnung von Pod-Mitgliedern und manchmal zum Load Balancer
  • Kubernetes-Ingress

Einige von ihnen können andere antreiben. Sie spielen nicht unbedingt alle gut zusammen und können miteinander konkurrieren.

Ich habe mir die Kubernetes-Runtime von Amazon nicht wirklich angesehen, aber abgesehen davon sind mir für die einfachen Dinge, die Sie tun möchten, mindestens drei Optionen bekannt:

  • Erstellen Sie ausgehend von Kubernetes einen Servicetyp=LoadBalancer, damit dieser einen ELB erstellt. Dadurch erhalten Sie einen eindeutigen Domänennamen, für den Sie in Route53 einen CNAME-Eintrag erstellen können, um Ihre Subdomäne zuzuordnen. Die ELB-Mitgliedschaft wird mithilfe einer ähnlichen Automatisierung aktualisiert, mit der Dienste mit Pod-IPs auf dem neuesten Stand gehalten werden. Es gibt einige Einschränkungen beim Anforderungsausgleich auf Ebene 4 und Ebene 7.
  • Beginnen Sie mit einem ELB, fügen Sie K8s EC2-Knoten als Mitglieder des ELB hinzu und führen Sie Ingress als Daemonset aus. Es gibt viele Varianten dazu, aber das bedeutet, dass die Verantwortung für die Sicherstellung der korrekten Mitgliedschaft im ELB an die Verwaltung von K8s auf EC2 gebunden ist, ob automatisiert oder manuell. Dies bietet jedoch andere Kontrollpunkte für die Verkehrsführung auf Schicht 7.
  • Verwenden Sie ausgehend von Kubernetes ein Tool namens Route53-Mapper, um die Route53-Konfiguration anhand von Anmerkungen zu den Serviceressourcen zu steuern.

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

Dies ist eine einfachere Version der ersten, einschließlich TLS, aber es scheint etwas verrückt, sie für TLS zu verwenden, da es offenbar erforderlich ist, Zertifikate in Serviceanmerkungen aufzubewahren, anstatt dort, wo sie hingehören, nämlich geheim.

Antworten:

Gibt es außer der Kompatibilität einen wichtigeren Grund für eine weitere Schicht zwischen dem Gateway und der Außenwelt?

Es gibt keine Anforderung, dieser Ansatz löst das Problem, dass sowohl ELB als auch k8s über Automatisierung verfügen. Im Allgemeinen möchte man keine konkurrierenden Automatisierungseigentümer.

Würde das, was ich versucht habe, in der Google Cloud Platform funktionieren (Ist das ein spezifisches Problem der AWS-Bereitstellung)?

gcloud Automation ist anders, und seinen Load Balancern können IPs zugewiesen werden, da die IP-Zuweisung separat verwaltet wird. Dies ist also bis zu einem gewissen Grad ein AWS-spezifisches Problem.

Nginx-Ingress-Controller ... Was ist der Unterschied zwischen einem Nginx-Reverse-Proxy und dem Kubernetes-Ingress-Dienst? Denn für mich scheinen die Wörter hier synonym verwendet zu werden.

Sie sind austauschbar. Das eine ist eine Abstraktion, das andere ist konkret.

Kubernetes Ingress ist die Abstraktion, die auf viele verschiedene Arten implementiert werden kann. Ingress besteht aus Ingress-Ressourcen, einem Controller und einem Proxy, der die Konfiguration übernimmt. Der Controller überwacht den Cluster auf Änderungen an Ingress-Ressourcen, übersetzt sie in eine proxyspezifische Konfiguration und lädt dann den Proxy neu.

Der Nginx-Ingress-Controller ist eine Implementierung dieser Maschinerie unter Verwendung von Nginx. Es gibt viele andere, die Haproxy und andere Proxys verwenden.

Es scheint so viele Möglichkeiten zu geben, dies zu tun. Was ist derzeit die beste (und einfachste) Methode?

Siehe oben. Es gibt wahrscheinlich auch andere Möglichkeiten.

verwandte Informationen