15장. 인그레스를 이용한 인입 트래픽 관리

인그레스의 라우팅 과정

• 인그레스는 리버스 프록시(Nginx, Traefik .. )를 인그레스 컨트롤러 로 사용하며 리버스 프록시에 좀 더 주도적인 역할을 맡긴다.

• 로드밸런서 → 리버스 프록시 → 클러스터 IP 서비스

• 위 다이어그램의 핵심은 인그레스 컨트롤러(Nginx 파드). 이 컨트롤러는 쉽게 교체할 수 있는 리버스 프록시임
• Nginx, HAProxy, 컨투어, 트래픽 등 다양한 선택지가 있음
• 인그래스 객체에는 라우팅 규칙이 일반적인 형태로 기술되어 있고 컨트롤러가 이 규칙을 프록시에 적용함
• 사실상 인그레스 리소스는 라우팅 규칙 명세만 수행하며, 실제 규칙 구현과 트래픽 처리는 인그레스 컨트롤러가 담당
• 프록시마다 기능에 차이가 있으므로 인그레스 정의에는 공통적인 내용만 담기며, 애너테이션으로 특정 프록시만 지원하는 기능을 추가

• 인그레스 컨트롤러는 기존의 컨트롤러와 다른 점이, 파드에서 실행되며 인그레스 객체를 감시함. 그러다 어떤 변경을 감지하면 프록시에 변경된 규칙을 적용
• 인그레스 객체를 새로 배치하면 객체에 담긴 라우팅 규칙이 Nginx 설정에 추가됨
• Nginx 관점에서 보면 hello-kiamol 서비스를 업스트림(콘텐츠를 받아올 곳)으로 삼는 프록시 서버가 설정되는 것과 같은 결과
• 인그레스의 명세 내용
• rules: Ingress에서 트래픽 라우팅 규칙을 정의하는 상위 구조
• host: 특정 도메인 이름 기반으로 트래픽을 구분하는 필드
• path: 도메인 내에서 URL 경로에 따라 트래픽을 라우팅하는 규칙
• backend: 트래픽을 전달할 대상 서비스와 포트를 정의

• 네트워크 트래픽 처리

• SSL Termination: HTTPS 요청 처리 및 복호화

• 로드 밸런싱 : 파드간 트래픽 분배

• 적합한 인그레스 컨트롤러 선택: 예) NGINX, Traefik, AWS ALB 등

• 인그레스 컨트롤러의 배치와 제공하는 추가 기능 파악

실제 인그레스 사용 예시(aws)

• 주요 역할:
• URL, 도메인, 및 경로 기반 트래픽 라우팅
• 각 도메인에 대해 적절한 서비스와 연결

• 구성 요소:
• Annotations: AWS ALB 관련 설정 정의
• alb.ingress.kubernetes.io/certificate-arn: HTTPS를 위한 ACM 인증서 ARN.
• alb.ingress.kubernetes.io/healthcheck-*: ALB의 Health Check 설정.
• alb.ingress.kubernetes.io/listen-ports: ALB가 수신할 포트 정의 (HTTP: 80, HTTPS: 443)
• alb.ingress.kubernetes.io/scheme: ALB의 스키마 (internal 설정으로 내부 전용)
• alb.ingress.kubernetes.io/target-type: ip로 설정하여 Pod IP에 직접 연결
• 기타 세부 옵션으로 ALB 설정 세부 조정.
• Spec:
• 여러 host 정의로 각 도메인 이름과 해당 서비스 연결
• 각 도메인 별로 서비스 이름과 포트 지정
• 예: dev.itgo.ai -> dev-itgo-homepage-service:8080

인그레스 클래스

• 주요 역할:
• 클러스터 내 여러 Ingress Controller 중 특정 컨트롤러 지정
• spec.controller에 ingress.k8s.aws/alb 설정으로 AWS ALB Controller 사용 지정

• 구성 요소:
• Annotations 및 Labels: AWS ALB Controller 설정 정보를 포함
• name: alb로 명명되어 Ingress 리소스에서 참조

인그레스 컨트롤러

• AWS 로드 밸런서 컨트롤러를 통해 인터넷 트래픽 라우팅 - Amazon EKS

• 주요 역할:
• IngressClass에 따라 Ingress 리소스를 감지하고 처리
• 라우팅 규칙의 추가나 변경 감지
• AWS API를 호출하여 ALB 생성 및 구성
• ALB 설정과 Kubernetes 서비스 연결
• Ingress 에 정의된 라우팅 규칙에 따라 리버스 프록시에 적용

• 구성 요소:
• Pod:
• 실행 중인 컨테이너: aws-load-balancer-controller:v2.7.1
• 주요 포트:
• webhook-server: 9443 (Kubernetes Webhook Server)
• metrics-server: 8080
• Args:
• -cluster-name: EKS 클러스터 이름 지정
• -ingress-class: alb 지정으로 ALB 처리 담당
• Annotations:
• Health 체크 및 Prometheus 메트릭 수집 지원
• Affinity:
• Pod 간 겹치지 않게 스케줄링 설정 (PodAntiAffinity)

구성

• Ingress: HTTP/HTTPS 트래픽 규칙 정의
• ALB 설정을 위한 여러 AWS-specific Annotations 포함

• IngressClass: AWS ALB Controller와 Ingress 연동 설정
• Ingress의 ingressClassName을 통해 연결

• AWS Load Balancer Controller:
• Ingress 리소스를 감지하고 AWS ALB를 프로비저닝 및 설정
• Pod와 연결된 서비스 트래픽을 외부로 노출

• ALB:
• AWS 상에서 관리되는 로드 밸런서로 클러스터 외부와 내부를 연결

인그레스의 유형

1. 이름 기반의 가상 호스팅

• 설명:
• Ingress에서 host 필드를 사용해 트래픽을 특정 도메인 이름 기반으로 라우팅
• 예를 들어:
• dev.itgo.ai → dev-itgo-homepage-service
• mobile.dev.itgo.ai → dev-mobile-web-service
• 하나의 로드 밸런서(ALB)가 여러 도메인/호스트 이름에 대해 트래픽을 처리

• 적용 부분:
• 각 host에 따라 다른 서비스로 트래픽을 전달하는 Ingress 규칙 정의
• ALB는 이 규칙에 따라 도메인 기반으로 트래픽을 분리

2. 로드 밸런싱

• 설명
• Ingress 규칙에 따라 연결된 각 서비스로 트래픽을 분배
• ALB는 Target Group에 따라 각 서비스로 트래픽을 라우팅
• 각 서비스 뒤에서 실행 중인 여러 Pod 간 트래픽을 자동으로 로드 밸런싱

• 적용 부분:
• alb.ingress.kubernetes.io/target-type: ip 설정으로 각 Pod의 IP 주소를 직접 Target Group으로 연결
• 각 서비스의 여러 인스턴스(Pod) 간 부하를 분산

3. 팬아웃

• 단일 URL 경로를 기반으로 여러 백엔드 서비스로 트래픽을 분배하는 방식
• /api/auth → Service A
• /api/data → Service B

인그레스 규칙을 이용한 HTTP 트래픽 라우팅

• 인그레스는 HTTP와 HTTPS 요청만 처리 (웹 트래픽 한정)
• 다른 프로토콜(TCP, UDP 등)은 별도의 서비스 타입(예: LoadBalancer, NodePort)을 사용

1. 도메인 기반 라우팅으로 사용자 편의성 향상:
• 포트번호를 달리하는 대신, 직관적인 도메인 네임을 사용하여 트래픽을 라우팅
• 예: app1.dev.example.com → 앱 1, app2.dev.example.com → 앱 2
• 이를 통해 비운영 환경에서도 애플리케이션 여러 개를 동시에 실행하고 테스트 가능

2. 세부적인 외부 접근 제어:
• 모든 서비스가 외부에 노출되지 않도록, 명시적으로 노출하려는 경로만 설정 가능
• 클러스터 내부 서비스는 비공개 상태를 유지하여 보안을 강화

3. 중앙 집중식 관리:
• 여러 서비스의 트래픽 라우팅 규칙을 한곳에서 관리 가능(Ingress 리소스)
• 트래픽 라우팅 정책 변경이 용이

4. SSL/TLS를 통한 보안 강화:
• Ingress Controller에서 SSL Termination 설정을 통해 클라이언트와의 통신을 안전하게 유지
• HTTPS 트래픽을 쉽게 설정하고 관리 가능

5. 로드 밸런싱:
• Ingress Controller가 기본적으로 로드 밸런싱을 지원하여 트래픽 분산 처리

6. 응답 캐싱:
• 정적 콘텐츠 캐싱
• 기본 기능은 아님

• 인그레스는 HTTP와 HTTPS 요청, 즉 다시 말해 웹 트래픽만 다룬다.

• 인그레스 목적이 HTTP 요청에 담긴 라우팅 정보를 적절한 백엔드 서비스에 매칭해 주는 것이기에

• hello.kiamol.local/ → hello-kiamol 서비스의 80 포트로 연결

두 애플리케이션을 하나의 도메인에서 사용할 수 있도록

• path 정보 추가가 되면 Overwrite 된다.

• annotation 인 nginx.ingress.kubernetes.io/rewrite-target: / 로 인해 http://vweb.kiamol.local/v1 의 요청을 vweb-v1/ 로 전달하게 됨
• 해당 애너테이션으로 인해 요청에 포함된 경로는 무시하고 백엔드의 루트로만 리라이팅 됨

인그레스를 통해 외부 접근 차단

인그레스 컨트롤러 비교하기

• 리버스 프록시

• 현대적 프록시

응답캐시 기능을 적용한 인그레스 컨트롤러

• 애플리케이션의 변경이나 추가 컴포넌트 없이 인그레스 규칙만 변경해서 애플리케이션에 캐싱을 적용할 수 있음

• 인그레스 컨트롤러(Nginx)가 애너테이션에서 설정을 읽어서 캐시 기능이 적용됨

스티키 세션 적용

• CSRF 문제가 발생하여, /new 경로에 대해 요청할때만 스티키 세션을 적용하도록 기능 추가

• 해당 경로에 대해 요청할시 계속 같은 파드에 대해 요청되도록 작동함

인그레스 클래스로, 여러 인그레스 컨트롤러 중 어떤걸 사용할지 결정

• Ingress Controller는 클러스터 내 트래픽 라우팅을 담당하며, 각각 별도의 IP 주소를 가짐

• DNS 설정을 통해 도메인 이름을 Ingress Controller의 IP 주소와 연결하여 외부에서 접근 가능

• Ingress Controller는 로드 밸런서의 형태로 외부에 노출됩니다

인그레스를 사용하여 HTTPS 적용하기

인그레스 및 인그레스 컨트롤러의 이해

• 클러스터를 운영하다 보면 결국 인그레스 컨트롤러를 하나 정도는 배치할 수 밖에 없다. TLS 인증서 관리와 도메인 네임에 대한 라우팅 설정을 애플리케이션에서 할 필요가 없기 때문이다.

• 쿠버네티스의 인그레스는 인그레스 구현체를 교체 가능한 설계와 공통 인그레스 정의 덕분에 매우 유연하다. 하지만 이를 사용하는 입장에서는 덜 직관적
• 인그레스 정의에는 라우팅 규칙만 기재가능
• 프록시 같은 고급 기능 사용시, 애너테이션에 상당한 양의 설정 기재 필요 — 호환성이 좋지 않음
• Nginx 에서 Traefik 이나 HAProxy, 컨투어 로 이주할 일이 생긴다면 별도의 프로젝트로 진행해야 할 정도
• 쿠버네티스 커뮤니티에서는 이런 인그레스 문제점을 파악하고 이를 장기적으로 서비스 API 로 교체해 나가는 작업에 착수