AWS EKS ALB 하나로 여러 Ingress 구성 ( Ingress Group, TargetGroupBinding)

반응형

Ingress Grouping을 사용하여 비용을 절감하고 대상 그룹 바인딩을 사용하여 기존 로드 밸런서를 통합하는 방법

쿠버네티스의 클러스터 외부의 클라이언트에 로드밸런서 또는 Ingress 리소스 유형의
쿠버네티스 서비스를 노출하는 방법은 두 가지로 두 방법 모두 ELB를 사용한다.

NLB는 많은 양의 트래픽을 처리하도록 설계된 4계층(TCP, UDP) 트래픽을 처리하도록 최적화
ALB는 웹 트래픽을 처리하도록 설계되었으며 7계층(HTTP, HTTPS) 트래픽 처리에 최적화

AWS 로드 밸런서 컨트롤러는 클러스터에 워크로드를 배포할 때 ALB 및 NLB의 수명 주기 및 구성 관리를 자동화

## 쿠버네티스 Ingress와 ALB
쿠버네티스에서 Ingress는 클러스터의 서비스에 엑세스할 수 있도록 부하 분산된 외부 IP 주소를 제공하는 API 객체

7계층 리버스 프록시 역할을 하며 요청된 호스트 및 URL 경로를 기반으로 트래픽을 다른 서비스로 라우팅

AWS 로드 밸런서 컨트롤러는 Ingress를 생성할 때마다 사용자를 대신하여 ALB를 프로비저닝하고 구성

MSA 아키텍쳐에서는 클러스터내에 여러 서비스를 배포하는것이 일반적이며,
서비스마다 외부 엑세스, 라우팅 규칙, 보안 소켓 계층(SSL) / 전송 보안 계층 (TLS) 종료 등에 대한 요구 사항이 상이함
이러한 경우 Ingress 리소스가 여러개 사용되는데 애플리케이션에선 애플리케이션별 라우팅 규칙이 포함되므로 일반적인 배포 아티팩트 (배포, 서비스, 볼륨 등)에 Ingress 리소스에 대한 정의가 이루어짐

Ingress 리소스를 분리하면 클러스터의 다른 애플리케이션에 대한 트래픽 라우팅에 영향을 주지 않고 Ingress 리소스를 관리

하지만 Ingress들에 대해 AWS 로드 밸런서 컨트롤러를 사용하는 것이 유용하다 할지라도,
단점이 존재
컨트롤러는 각 Ingress에 대해 ALB를 생성하므로 로드 밸런서 수가 많아짐 -> 비용 증가로 연결
각 서비스에 대해 별도의 로드 밸런서를 사용하는 것은 비용 효율적이지 못할 수 있다.
그래서 여러 Ingress가 ALB를 공유하면 ALB 수를 최소화 하여 비용 절감을 기대할 수 있다.

아키텍처에서 ALB 수를 최소화하기 위해 AWS 로드 밸런서 컨트롤러를 사용하여 Ingress를 그룹화 하는 기능 존재
컨트롤러는 단일 ALB를 여러 Ingress 리소스와 공유할 수 있는 IngressGroup 기능을 제공.
이를 통해 로드 밸런서를 통합하고 비용 절감.
또한 Ingress group에는 서로 다른 NS들의 Ingress가 포함 될수 있어 MSA에 대한 엑세스 관리가 용이해진다.

# Ingress group 활용
여러 Ingress와 ALB를 공유하는 프로세스
이 예시에서는 두 개의 서로 다른 NS에 네 개의 웹 APP을 배포하는 구성
다음으로 단일 ALB를 공유하도록 여러 Ingress들을 구성하고 그룹화
group.name annotation을 사용해 Ingress 리소스를 그룹화

위 이미지는 설치 후 AWS 로드 밸런서 컨트롤러가 수행하는 작업을 설명
쿠버네티스 API 서버에서 Ingress 리소스에 대한 업데이트를 감시
변경을 감지하면 애플리케이션 로드 밸런서, 리스너,  대상 그룹 및 리스너 규칙과 같은 리소스를 업데이트
- Ingress 리소스에 언급된 모든 쿠버네티스 서비스에 대해 타겟그룹이 생성됩니다.
- Ingress 리소스 annotation에 정의된 모든 포트에 대해 리스너 생성
- 리스너 규칙 (Ingress rules)은  ingress 리소스 정의의 각 경로에 대해 생성

```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: name
  namespace: namespace
  labels:
    app: label
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/group.name: ingress-group
spec:
  ingressClassName: alb
```


alb.ingress.kubernetes.io/group.name annotation을 추가하여 Ingress에 그룹을 할당
동일한 group.name 주석이 있는 Ingress는 Ingress 그룹을 형성
Ingress 그룹은 여러 네임스페이스에 Ingress를 포함

# IngressGroup의 설계 고려 사항
다중 테넌트 환경에서 IngressGroup을 사용하기 전에 고려할 점은 충돌 해결
AWS 로드 밸런서 컨트롤러는 ALB에서 Ingress 규칙을 구성 시 group.order 필드를 사용하여 평가 순서를 설정.
group.order의 기본값은 0.


ALB는 Ingress 규칙을 적용해 라우팅 방식을 결정
규칙 평가 순서는 group.order 필드에 의해 설정
순서 값이 낮은 규칙이 우선 순위
기본적으로 IngressGroup 내 Ingress 간의 규칙 순서는 Ingress Namespace/name의 어휘 순서에 따라 결정

Ingress 규칙의 기본 순서로 인해 Ingress에 규칙이 잘못 구성된 경우 잘못된 라우팅이 발생할 위험이 생긴다.
애플리케이션 간의 라우팅 충돌을 피하기 위해 명시적인 Ingress 규칙을 만들고 group.order를 설정해 순서를 설정해야함.


### 공유 환경에서 IngressGroup을 사용할 때의 다른 주요 고려 사항.
IngressGroup은 여러 NS의 Ingress를 포함할 수 있으므로 IngressGroup의 이름은 클러스터 전체에 걸쳐있다. group.name에 명확한 값을 사용해 naming conflict을 방지

AWS 로드 밸런서 컨트롤러는 현재 IngressGroup에 대한 엑세스를 제어하는 세분화된 제어기능을 제공하지 않음 따라서 그룹에 MyIngressGroup과 같은 일반적인 이름을 사용하는 것을 지양
클러스터의 다른 누군가가 동일한 이름으로 Ingress를 만들어 그룹에 추가할 우려가 있음
우선 순위가 더 높은 규칙을 만들면 트래픽이 잘못 라우팅 될 수 있음

AWS ALB에는 리스너당 구성할 수 있는 규칙 수에 몇 가지 제한이 있음
제한은 로드 밸런서의 과부하가 걸리고 성능에 영향을 미치지 않도록 하기 위함
예를 들어, 각 ALB 리스너는 규칙을 기본적으로 최대 100개로 제한

## 타겟 그룹 바인딩을 사용하여 로드 밸런서와 쿠버네티스 리소스 분리
컨트롤러는 새 Ingress 리소스가 생성될 때 ALB를 생성
어떤 Ingress가 IngressGroup의 일부인 경우 컨트롤러는 Ingress 전반의 규칙들을 병합하고 ALB, 리스너 및 규칙을 구성
로드 밸런서의 라이프사이클은 하나 이상의 관련 Ingress와 연동되며 Ingress를 삭제하면 그룹에 다른 Ingress가 없을 경우 AWS 로드 밸런서 컨트롤러가 ALB를 삭제

고객이 직접 로드 밸런서를 관리하는 것을 선호하는 몇 가지 시나리오
이 경우 로드 밸런서의 생성 및 삭제를 서비스 또는 Ingress의 라이프 사이클과 분리

> 고객은 Amazon EKS 클러스터에 로드 밸런서 생성 권한을 부여하지 않거나, 다른 상황에서는 워크로드를 Amazon EKS로 마이그레이션하고 싶었지만 로드 밸런서는 보존하기를 원할 수 있습니다. 두 시나리오 모두에서 기존 로드 밸런서를 사용하여 쿠버네티스 서비스를 노출할 수 있는 기능이 필요했습니다.


타겟 그룹 바인딩은 AWS 로드밸런서 컨트롤러에서 관리하는 CRD로 기존 로드 밸런서를 사용하여 쿠버네티스 애플리케이션을 노출할 수 있다. 타겟 그룹 바인딩 리소스는 쿠버네티스 서비스를 로드 밸런서 타겟 그룹과 바인딩
TargetGroupBinding 리소스를 생성하면 컨트롤러가 트래픽을 서비스로 라우팅하도록 대상 그룹을 자동으로 구성.
아래는 리소스 구성의 예시

장점으로는 Ingress나 클러스터를 생성, 삭제할 때 로드 밸런서가 정적 상태를 유지
로드 밸런서의 라이프사이클은 해당 로드 밸런서가 노출하는 서비스로부터 독립됨
또 다른 이점은 기존 ALB를 사용해 여러 EKS 클러스터에 트래픽 분산이 가능하다.
- DR 구성에 유리


### 클러스터 전반에서 애플리케이션 트래픽 로드 밸런싱

ALB는 가중치가 적용된 타겟 그룹을 사용해 여러 백엔드에 트래픽 분산 가능
이 기능을 사용하면 각 클러스터의 타겟 그룹을 생성하고 다음 타겟 그룹을 여러 클러스터 서비스에 바인딩하여 트래픽을 여러 클러스터로 라우팅할 수 있다.
이 전략을 사용해 각 클러스터로 보내는 트래픽의 비율을 제어할 수 있다.
- 멀티 클러스터 전략에 유리

이러한 트래픽 제어는 blue/green 클러스터 업그레이드를 수행할 때 유용하다.
제어된 방식으로 이전 클러스터에서 새 클러스터로 트래픽 마이그레이션 가능

또한 이 아키텍처를 사용하여 다중 클러스터 환경에서 워크로드의 복원성(Resilience)을 개선
애플리케이션을 여러 쿠버네티스 클러스터에 동시 배포하는 경우 
이를 통해 쿠버네티스 클러스터가 단일 장애 지점이 되는 것을 방지
한 클러스터에서 장애 이벤트가 발생하는 경우 로드 밸런서 타겟에서 해당 클러스터를 제거

할일 :
방금까지 설명한 방법을 사용해 모니터링 툴인 LGTM으로 구성된 그라파나 대시보드와 ArgoCD등을 타겟그룹으로 묶어 하나의 ALB로 구성하는 것을 진행할 예정









출처 :
https://aws.amazon.com/ko/blogs/tech/a-deeper-look-at-ingress-sharing-and-target-group-binding-in-aws-load-balancer-controller/

AWS 로드 밸런스 컨트롤러의 Ingress 공유 및 대상 그룹 바인딩 자세히 살펴보기 | Amazon Web Services