쿠버네티스 고수되기: Source IP 보존과 트래픽 관리를 위한 최종 아키텍처 🚀

안녕하세요! 쿠버네티스 환경을 운영하면서 "사용자의 진짜 IP 주소(Source IP)가 왜 안 보이지?" 혹은 "트래픽이 특정 노드에만 몰려서 힘들어하네..." 와 같은 고민, 한 번쯤 해보셨을 겁니다. 🤯

 

Service의 externalTrafficPolicy를 Cluster로 설정하면 소스 IP가 사라지고, Local로 설정하면 트래픽 쏠림이 걱정되는 딜레마에 빠지기 쉽습니다.

 

오늘은 이 모든 문제를 해결하고, 안정적이며 확장 가능한 운영 환경을 구축할 수 있는 쿠버네티스 표준 아키텍처, "Dedicated Ingress Node(전담 인그레스 노드)" 패턴에 대해 깊이 있게 알아보겠습니다!

 

---

🤔 무엇이 문제였을까? (복습)

이 아키텍처를 이해하기 전에, 우리가 해결하려는 문제를 다시 한번 짚어보겠습니다.

• externalTrafficPolicy: Cluster: kube-proxy가 마법처럼 트래픽을 클러스터 전체에 분산시켜주지만, 이 과정에서 SNAT가 발생하여 소중한 사용자의 원본 IP가 노드의 IP로 바뀌어 버립니다.
• externalTrafficPolicy: Local: 원본 IP는 지켜주지만, 파드가 배포된 노드로만 트래픽이 가기 때문에 특정 노드에 과부하가 걸릴 위험이 있습니다.

이 두 가지 단점을 모두 피할 방법은 없을까요? 정답은 '있다'입니다! 바로 트래픽을 처리하는 역할을 분리하는 것입니다.

---

🏗️ 최종 아키텍처: Dedicated Ingress Node 패턴

이 아키텍처의 핵심 아이디어는 간단합니다. "외부 트래픽을 받는 역할"과 "실제 일을 하는 역할"을 분리하자! 마치 공항에서 입국 심사를 하는 구역과 실제 여행객들이 머무는 구역을 나누는 것과 같습니다.

이를 위해 클러스터 노드를 두 그룹으로 나눕니다.

1. 엣지 노드 (Edge Nodes) / 인그레스 노드 (Ingress Nodes) GATEWAY
   • 인터넷으로부터 들어오는 모든 트래픽을 최초로 맞는 역할을 전담합니다.
   • 이 노드들에는 **인그레스 컨트롤러(Ingress Controller)**만 배포됩니다.
2. 워커 노드 (Worker Nodes) / 애플리케이션 노드 (Application Nodes) 🏭
   • 실제 우리의 애플리케이션(웹서버, API 등) 파드들이 배포되는 공간입니다.
   • 외부에 직접 노출되지 않고, 오직 엣지 노드를 통해서만 트래픽을 받습니다.

---

🔧 아키텍처 구축 단계별 상세 가이드

1단계: 노드에 역할 부여하기 (Labeling)

먼저 어떤 노드가 엣지 노드가 될지 정하고 "꼬리표(Label)"를 붙여줍니다.

# node-1과 node-2를 엣지 노드로 지정
kubectl label node node-1 node-role.kubernetes.io/edge=""
kubectl label node node-2 node-role.kubernetes.io/edge=""

이제 node-role.kubernetes.io/edge 라는 라벨을 가진 노드들은 우리의 특별한 "관문" 노드가 되었습니다.

2단계: 인그레스 컨트롤러를 엣지 노드에만 배포하기

Nginx Ingress Controller와 같은 컨트롤러를 배포할 때, Deployment YAML 파일에 nodeSelector를 추가하여 오직 엣지 노드에만 파드가 생성되도록 강제합니다.

# nginx-ingress-controller-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: ingress-nginx
    spec:
      # 🔑 바로 이 부분!
      nodeSelector:
        node-role.kubernetes.io/edge: ""
      containers:
        - name: controller
          image: registry.k8s.io/ingress-nginx/controller:v1.9.6
          ports:
            - name: http
              containerPort: 80
            - name: https
              containerPort: 443

이제 인그레스 컨트롤러 파드는 node-1과 node-2에만 생성됩니다.

3단계: 마법의 키, externalTrafficPolicy: Local 서비스 생성

다음으로, 이 인그레스 컨트롤러를 외부 세계에 노출시킬 LoadBalancer 타입의 서비스를 생성합니다. 이 아키텍처의 가장 중요한 설정이 바로 여기에 들어갑니다.

# ingress-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
spec:
  type: LoadBalancer
  # 🔑 가장 중요한 설정!
  externalTrafficPolicy: Local
  selector:
    # 이 selector는 2단계에서 배포한 인그레스 컨트롤러 파드를 가리킵니다.
    app.kubernetes.io/name: ingress-nginx
  ports:
    - name: http
      port: 80
      targetPort: 80
      protocol: TCP
    - name: https
      port: 443
      targetPort: 443
      protocol: TCP

이 설정의 효과:

• 클라우드 로드밸런서는 이제 인그레스 컨트롤러 파드가 떠 있는 엣지 노드(node-1, node-2)로만 트래픽을 보냅니다.
• 이 과정에서 불필요한 노드 간 이동이 없으므로, 원본 소스 IP가 완벽하게 보존됩니다.

4단계: 애플리케이션을 워커 노드에 배포하기

이제 우리의 소중한 애플리케이션은 아무런 nodeSelector 없이 (또는 워커 노드를 가리키는 nodeSelector를 사용하여) 배포하면 됩니다. 쿠버네티스가 알아서 엣지 노드가 아닌 나머지 워커 노드들에 파드를 분산시켜 줄 것입니다.

---

🚦 최종 트래픽 흐름 정리

1. 사용자 요청 ➡️ 인터넷 ➡️ 클라우드 로드밸런서
2. 로드밸런서는 헬스 체크를 통해 node-1, node-2가 정상임을 인지하고, 이쪽으로만 트래픽 전달 (externalTrafficPolicy: Local의 효과!)
3. 엣지 노드(node-1 또는 node-2) ➡️ Nginx 인그레스 컨트롤러 파드
4. 인그레스 컨트롤러는 Ingress 규칙을 확인하고, X-Forwarded-For 헤더에 원본 IP를 담아 내부 워커 노드에 있는 애플리케이션 파드로 트래픽을 프록시
5. 애플리케이션은 원본 IP를 확인하고 요청 처리! ✅

---

✨ 이 아키텍처가 제공하는 최고의 가치

• 🛡️ 보안 강화: 중요한 애플리케이션은 내부망에 숨기고, 외부와 맞닿는 지점을 엣지 노드로 최소화하여 공격 표면을 줄입니다.
• ⚖️ 자원 효율성: 외부 트래픽 처리에 특화된 고사양의 엣지 노드와, 계산 작업에 특화된 워커 노드를 분리하여 자원을 효율적으로 사용할 수 있습니다.
• 🚀 독립적인 확장: 갑자기 트래픽이 몰리면 엣지 노드 그룹만 확장하고, 애플리케이션의 연산량이 많아지면 워커 노드 그룹만 확장하면 됩니다.
• 🎯 명확한 책임 분리: 네트워크 담당팀은 엣지 노드와 인그레스 컨트롤러에 집중하고, 개발팀은 워커 노드의 애플리케이션에 집중할 수 있습니다.

이제 더 이상 소스 IP 문제와 비효율적인 트래픽 분산 사이에서 고민하지 마세요. Dedicated Ingress Node 아키텍처를 도입하여 안정적이고 전문적인 쿠버네티스 환경을 구축해 보시길 바랍니다!

 

태그: 쿠버네티스, Kubernetes, Ingress, externalTrafficPolicy, 아키텍처, 네트워크, Source IP, 데브옵스, DevOps, 로드밸런서