[EKS] AWS Load Balancer Controller란? (Service & Ingress 관점)

vinca·2024년 2월 8일

aws kubernetes

🦓 EKS

목록 보기

9/23

Service & Ingress

서비스와 인그레스 무엇이 다른지 살펴보고, 애플리케이션(파드)에 연결하여 각각의 방법으로 노출해보도록 하자.

Service

서비스란 무엇일까?

공식 문서를 참고하면, 파드 집합에서 실행중인 애플리케이션을 네트워크 서비스로 노출하는 추상화 방법이라고 기술되어 있다.

쉽게말해 다음과 같이 정리할 수 있다.

Service : 다수 또는 단일의 파드(애플리케이션)를 외부로 노출하는 방법

그 예가 대표적으로 3가지 ClusterIP, NodePort, LoadBalancer + (**ExternalName)가 있다.

** ExternalName은 파드 내부에서 외부로의 접속할 때 사용한다.

ClusterIP

쿠버네티스 클러스터 내부에서 파드를 노출하는 방법이다.
즉, 클러스터 내부에서만 해당 ClusterIP 서비스 타입의 IP로 접속할 수 있고, 외부에서는 접근이 불가능하다.

ClusterIP 서비스에 도착한 트래픽은 워커노드의 kube-proxy를 통해 각 파드에 부하분산이 수행된다.
(리눅스 내부 커널의 iptables 부하분산 룰이 사용되며 요즘은 eBPF가 뜨는 추세)

NodePort

노드포트는 ClusterIP가 내부적으로 사용되는 서비스로, 노드의 포드를 통해서 파드를 외부로 노출할 수 있는 방법이다.

노드IP:<포트번호>를 통해서 접속하게 되는데, 이렇게 접속하게 되면 외부에서 접속하는 사용자가 내부의 노드IP를 알게된다는 보안상의 문제가 있다.

LoadBalancer

NodePort와 ClusterIP가 내부적으로 사용되는 서비스로, 맨 앞단에 LoadBalancer를 부착하여 내부 노드의 IP를 노출하지 않고, 파드를 노출시킬 수 있다.

단순히 사용자가 알게되는 것은 로드밸런서의 IP만을 알게되는 것이다.

EKS에서 Service, Ingress

AWS EKS에서 Service는 CLB/NLB가 생성된다 (4계층 LB)
Ingress는 ALB가 생성된다 (7계층 LB)

즉, 인그레스를 배포할 때 ALB 어노테이션을 명시적으로 쓰면 AWS에 ALB가 생성되고, 반대로 서비스로 LB를 배포하게되면 기본적으로 CLB가 그리고, AWS Load Balancer Controller를 설치한 상태에서는 NLB가 생성된다.

Ingress

인그레스는 반드시 내부 서비스(ClusterIP, NodePort)가 있어야 작동할 수 있는 유형으로, 클러스터 외부에서 내부 서비스로 HTTP와 HTTPS 경로를 노출하는 방법이다.

즉, 인그레스는 7계층 로드밸런서이다.

Why Ingress?

MSA를 생각해보면 왜 이러한 방식이 필요한 지 이해할 수 있다.
MSA를 수행하면 애플리케이션이 도메인별로 쪼개지고, 이를 노출하기 위해 각각 다른 LoadBalancer를 생성하여 노출하게 되는데, 이것은 효율적인 방법이 아니다.

이를 해결하기 위해 Ingress 유형으로 하나의 LoadBalancer를 구성하여 다수의 내부 서비스에 연결하여 한번에 처리하는 것이다.

AWS Load Balancer Controller

AWS Load Balancer Controller란 EKS 클러스터를 위한 AWS Load Balancer를 관리하는 add-on(애즈온)이다.

AWS Load Balancer Controller 역할

AWS Load Balancer Controller는 크게 2가지의 역할이 있다.

첫째로 AWS ELB를 프로비저닝하고 관리하는 역할과,
둘째로 AWS EKS Cluster의 컨트롤 플레인과 상호작용하여 파드의 정보를 확인하고 이벤트를 확인하는 역할이다.

AWS ELB를 프로비저닝하고 관리하기 위해서는?

EKS 내 파드로 배포되는 AWS Load Balancer Controller가 AWS 서비스인 AWS ELB를 프로비저닝하고, 관리하기 위해서는 그냥은 안된다. 이는 AWS 서비스에 함부로 접근할 수 없기에 IRSA 보안 작업이 수행되어야 한다.

IRSA는 IAM Role for Service Accounts의 약자로 IAM Role을 서비스 어카운트에 부여하는 것을 의미한다.

OIDC

⭐이 때 쿠버네티스의 Service Account와 IAM Role간의 연결에는 OIDC 인증 방식을 통해 연결된다.
⭐이는 IAM Role의 신뢰관계 정책에 쿠버네티스 클러스터의 OIDC가 들어가 있기 때문이다.

실제로 AWS Load Balancer Controller 설치과정을 확인해보면 다음과 같다.

IAM 정책 생성

IAM Role 생성 (IAM 정책 연결 + 클러스터의 OIDC를 신뢰 관계 정책에 연결)

IAM Role를 Service Account에 부여하여 Service Account 생성 (IRSA 과정)

AWS Load Balancer Controller에 IRSA가 된 Service Account를 넣어서 설치

IP 모드

apiVersion: v1
kind: Service
metadata:
  annotations:
    # 💡 IP 모드
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: your-app