☰

K8s LoadBalancer 서비스와 AWS Route53 도메인 이름 연결

tag-icon • tag-icon amazon-web-services kubernetes network-design
K8s LoadBalancer 서비스와 AWS Route53 도메인 이름 연결

내가 뭘 하려는지
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을 구현했습니다. 누군가 복사하여 붙여넣기를 원하는 경우를 대비한 구성은 다음과 같습니다.

게이트웨이-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"

그런 다음 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에서 포드 멤버 매핑으로, 때로는 로드 밸런서로 매핑
  • 쿠버네티스 수신

그들 중 일부는 다른 일부를 운전할 수 있습니다. 그들은 반드시 모두 함께 잘 플레이할 필요는 없으며 서로 경쟁할 수 있습니다.

저는 Amazon의 kubernetes 런타임을 실제로 살펴보지는 않았지만 그 외에 여러분이 하고 싶은 간단한 작업을 수행하기 위해 최소한 3가지 옵션을 알고 있습니다.

  • kubernetes에서 시작하여 서비스 유형=LoadBalancer를 생성하여 ELB를 생성합니다. 그러면 하위 도메인을 매핑하기 위해 Route53에서 CNAME 레코드를 만들 수 있는 고유한 도메인 이름이 제공됩니다. ELB 멤버십은 포드 IP를 통해 서비스를 업데이트하는 것과 유사한 자동화를 사용하여 업데이트됩니다. 계층 4 및 계층 7 요청 균형 조정에는 몇 가지 제한 사항이 있습니다.
  • ELB에서 시작하여 k8s EC2 노드를 ELB의 구성원으로 추가하고 수신을 데몬셋으로 실행합니다. 이에 대한 많은 변형이 있지만 이는 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는 다양한 방식으로 구현할 수 있는 추상화입니다. 수신은 수신 리소스, 컨트롤러 및 구성을 수행하는 프록시로 구성됩니다. 컨트롤러는 클러스터에서 수신 리소스 변경 사항을 감시하고 이를 프록시별 구성으로 변환한 다음 프록시를 다시 로드합니다.

nginx 수신 컨트롤러는 nginx를 사용하여 이 기계를 구현한 것입니다. haproxy 및 기타 프록시를 사용하는 다른 많은 방법이 있습니다.

이를 수행하는 방법은 너무 많은 것 같습니다. 현재 가장 좋은(그리고 가장 쉬운) 방법은 무엇입니까?

위 참조. 아마도 다른 방법도 있을 것입니다.

관련 정보