Ingress Controller

Ingress Controller

인그레스 컨트롤러 (Ingress Controller) 는 클러스터 외부에서 들어오는 HTTP/HTTPS 등 애플리케이션 트래픽을 내부 서비스로 라우팅하고, 다양한 라우팅 정책을 적용하는 네트워크 구성요소다. 특히, Kubernetes 환경에서 외부 요청을 내부 서비스로 전달하는 진입점 역할을 하는데 사용된다.

쿠버네티스 환경의 확장성과 보안을 유지하며, 네임 기반, 경로 기반, TLS 종료, 인증·인가, 부하 분산 등 많은 기능을 프록시 및 리버스 프록시 (Reverse Proxy) 구조로 제공한다. 고가용성 (High Availability) 과 자동화, 그리고 다양한 백엔드 서비스 지원이 특징이다.

등장 배경 및 발전 과정

마이크로서비스, 클라우드 네이티브로의 전환에 따라 서비스 경계가 복잡해졌다.

Kubernetes 는 내부적으로 Pod 간 통신을 ClusterIP 또는 NodePort 를 통해 지원하지만, 클러스터 외부에서 HTTP(S) 요청을 서비스로 라우팅하는 표준 메커니즘이 필요했다. 이에 따라 Ingress API가 도입되었고, 이를 실제로 처리하는 Ingress Controller가 등장했다.

• 초창기에는 kubectl port-forward 또는 NodePort 로 외부 노출
• 복잡한 URL 패턴, 도메인 기반 라우팅이 불가능 → Ingress 리소스 정의 도입
• 쿠버네티스 1.1(2015) 에서 공식 인그레스 리소스 지원 시작, 엔터프라이즈 네트워크 환경에서 프로덕션 표준이 됨.
• 다양한 Controller 구현체가 오픈소스로 발전: NGINX, Traefik, HAProxy, Contour, Istio Gateway 등

목적 및 필요성

→ 복잡한 마이크로서비스 환경에서 도메인 - 기반 라우팅, 보안, 트래픽 제어, 관측성까지 포함한 네트워크 진입 제어의 핵심 요소로 기능

핵심 개념

기본 개념

심화 개념

Ingress Resource

역할: 클러스터 외부 요청 (HTTP/HTTPS) 을 내부 서비스로 라우팅하는 규칙 선언.

구성:

• host: 도메인 기반 구분 (example.com)
• path: 경로 기반 라우팅 (/api, /admin)
• backend: 요청을 전달할 내부 서비스 (serviceName, servicePort)

예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
	nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx 
  rules:
  - host: example.com
    http:
      paths:
      - path: /web
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

• ingressClassName: 이 Ingress 는 nginx IngressClass 에 의해 처리됨.
• rewrite-target: URL 경로 재작성 (예: /web/foo → /foo)
• rules: host 와 path 에 따라 요청을 특정 서비스로 라우팅

Ingress Controller

설명: Ingress 리소스를 감시 (watch) 하고, 이를 기반으로 실제 프록시 (L7) 설정을 구성.

동작 방식: Deployment 로 실행되며, 각 클러스터 노드에서 ingress 트래픽을 처리.

역할:

• 리버스 프록시로 외부 요청 수신
• TLS 인증서 적용
• 인증 헤더 삽입, CORS 등 보안 기능 적용
• 로깅, 레이트 리밋, 서킷 브레이커 등 고급 기능 포함 (Controller 마다 다름)

IngressClass

도입 목적: 멀티 Ingress Controller 환경에서 각 리소스를 어떤 Controller 가 처리할지 명시

구성 요소:

• controller: 예: k8s.io/ingress-nginx
• parameters: 커스텀 리소스 사용 가능

예시:

1
2
3
4
5
6

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: nginx
spec:
  controller: k8s.io/ingress-nginx

• IngressClass 는 특정 Ingress 리소스를 어떤 Ingress Controller 가 처리할지 결정한다.
• controller: 해당 클래스가 어떤 컨트롤러에 의해 처리되는지를 지정한다.
  • k8s.io/ingress-nginx 는 NGINX Ingress Controller 의 기본값.
• 여러 Ingress Controller 를 병렬로 운영할 때 클래스 단위로 구분해 제어할 수 있다.

트래픽 라우팅 전략

TLS 종료 (SSL Termination)

기능: HTTPS 요청을 Ingress Controller 에서 해제 후 내부에 HTTP 로 전달.

이점:

• 백엔드 서비스에서 인증서 처리 불필요
• 인증서 중앙 관리

구성: tls 필드를 통해 Secret 정의.

인증/인가 기능 연계

기본 지원:

• HTTP Basic Auth
• OAuth2 Proxy 연동
• 인증 헤더 삽입 (e.g., X-Forwarded-User)

외부 인증 시스템 연동: OIDC, LDAP, 인증 미들웨어와 통합 가능

실무 구현과의 연관성

주요 기능 및 역할

주요 기능

주요 역할

기능 ↔ 역할 관계 매핑

Ingress Controller 역할 기반 구성

flowchart TD
    %% 외부 사용자
    UA(["사용자 (Client)"])

    %% Ingress Controller
    IGW[["Ingress Controller<br/>(Reverse Proxy, Entry Gateway)"]]

    %% 보안 정책 계층
    SEC[["보안 정책 계층<br/>(TLS 종료, 인증/인가, WAF)"]]
    SEC -->|TLS Termination<br/>JWT / OAuth2| IGW

    %% 트래픽 라우팅
    RTG[["트래픽 라우팅<br/>(Path/Host 기반)"]]
    IGW --> RTG

    %% 부하 분산 처리
    LBS[["부하 분산 처리<br/>(Load Balancer + Health Check)"]]
    RTG --> LBS

    %% 내부 백엔드 서비스
    SVC1([서비스 A])
    SVC2([서비스 B])
    LBS --> SVC1
    LBS --> SVC2

    %% 모니터링 / 로깅 / 트레이싱
    OBS[["관찰 가능성 계층<br/>(Metrics / Logs / Tracing)"]]
    IGW -->|Request Log| OBS
    SVC1 -->|App Metrics| OBS
    SVC2 -->|App Traces| OBS

    %% CI/CD와 선언형 정책 연계
    GIT[(GitOps / CI-CD)]
    GIT -->|YAML 정책 배포| IGW

    UA -->|HTTPS 요청| SEC

특징

핵심 설계 원칙

Ingress 설계 원칙별 설정 예시

선언형 구성 (Declarative Configuration)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-service-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
  - host: example.com
    http:
      paths:
      - path: /web
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

• 목적: GitOps 등과 연계 가능한 코드 기반 정책 관리

단일 진입점 (Single Point of Entry)

Ingress Controller 는 기본적으로 L7 Entry Point 역할을 수행하며, 클러스터 외부에서 진입하는 HTTP/HTTPS 트래픽의 유일한 관문으로 설정된다.

1
2
3
4
5

# Helm 설치 시 ingressClass 이름을 명시해 단일 진입점 구성
helm install ingress-nginx ingress-nginx/ingress-nginx \
  --set controller.ingressClass=nginx \
  --set controller.ingressClassResource.name=nginx \
  --set controller.watchIngressWithoutClass=false

• 목적: Ingress Controller 1 곳에서 모든 외부 요청을 제어

TLS 종료 (Security First)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: secure-ingress
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
spec:
  ingressClassName: nginx
  tls:
  - hosts:
      - secure.example.com
    secretName: secure-tls-secret
  rules:
  - host: secure.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: secure-service
            port:
              number: 443

• 목적: HTTPS 암호화, 인증서 자동 관리 (cert-manager 연동)

인증/인가 (AuthN/AuthZ)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: auth-ingress
  annotations:
    nginx.ingress.kubernetes.io/auth-url: "https://auth.example.com/oauth2/auth"
    nginx.ingress.kubernetes.io/auth-signin: "https://auth.example.com/oauth2/start"
spec:
  ingressClassName: nginx
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app
            port:
              number: 80

• 목적: OAuth2 Proxy 등 외부 인증 시스템과 연동

상태 비저장 설계 (Stateless Architecture)

Ingress Controller 자체는 상태를 저장하지 않으므로, 세션 스티키가 필요한 경우 외부 세션 스토리지(예: Redis) 를 이용한다.

1
2
3
4
5
6
7
8

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-configuration
  namespace: ingress-nginx
data:
  proxy-cookie-path: "/ /; HttpOnly; Secure"
  enable-sticky-sessions: "true"

• 목적: 사용자 세션을 외부에 저장하고 Ingress 는 상태를 유지하지 않음

가시성 확보 (Observability)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# Prometheus와 연동하여 메트릭 노출
apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx-metrics
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/component: controller
  annotations:
    prometheus.io/scrape: "true"
    prometheus.io/port: "10254"
spec:
  ports:
  - name: metrics
    port: 10254
    targetPort: 10254
  selector:
    app.kubernetes.io/name: ingress-nginx

• 목적: Ingress 메트릭을 Prometheus 로 수집하여 Grafana 대시보드 구성

최소 권한 설정 (Least Privilege)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# 예: ClusterRole 제한
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: ingress-nginx-controller
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  - endpoints
  - services
  verbs:
  - list
  - watch

• 목적: Ingress Controller 가 필요한 리소스만 접근하도록 제한

6.6 주요 원리 및 작동 원리

제어 루프 패턴 (Control Loop Pattern):

graph TD
    A[사용자가 Ingress 리소스 생성] --> B[Kubernetes API Server]
    B --> C[Ingress Controller가 변경 감지]
    C --> D[현재 상태와 원하는 상태 비교]
    D --> E[프록시 설정 업데이트]
    E --> F[NGINX/HAProxy/Traefik 재로드]
    F --> G[트래픽 라우팅 적용]
    G --> H[상태 피드백]
    H --> C

트래픽 처리 흐름:

graph LR
    A[🌐 외부 클라이언트] --> B["LB 또는 NodePort (External Access)"]
    B --> C["Ingress Controller Pod (NGINX/Envoy)"]
    C --> D["Ingress 리소스 규칙 평가 (host/path)"]
    D --> E["ClusterIP Service (Backend Selector)"]
    E --> F["Pod (애플리케이션 컨테이너)"]

작동 원리는 Kubernetes 의 Watch API 를 활용한 이벤트 기반 처리로, Ingress 리소스 변경을 실시간으로 감지하여 프록시 설정을 동적으로 업데이트한다.

Ingress 작동 흐름:

1. 사용자가 Ingress 리소스를 정의 (host, path, backend 포함)
2. Ingress Controller 는 API Server 를 통해 리소스를 감시
3. Controller 는 자신이 사용하는 로드 밸런서 (NGINX, Envoy 등) 의 설정을 업데이트
4. 외부에서 도착한 요청을 보고 적절한 서비스로 전달

sequenceDiagram
    participant User
    participant K8sAPIServer
    participant IngressController
    participant Proxy
    participant BackendService

    %% 리소스 정의 및 처리 흐름
    User->>K8sAPIServer: Ingress 리소스 생성 (host/path/backend)
    IngressController->>K8sAPIServer: Watch Ingress Resource
    IngressController->>IngressController: 프록시 설정 업데이트 (NGINX, Envoy)

    %% 실제 요청 처리 흐름
    User->>Proxy: HTTP 요청 (Host/Path)
    Proxy->>IngressController: 요청 전달 및 매칭
    IngressController->>BackendService: 트래픽 전달 (서비스 선택 → Pod)

구조 및 아키텍처

flowchart TD

    %% 외부 요청 계층
    Client[사용자 클라이언트]
    DNS[DNS]
    LB[Cloud Load Balancer]

    %% Ingress Controller 구성
    subgraph Ingress_Controller["Ingress Controller (Cluster Internal)"]
        APIWatcher[API Watcher]
        Controller["Controller Process<br/>(client-go)"]
        Cache["Resource Cache<br/>(인메모리 상태)"]
        Proxy["Proxy Engine<br/>(NGINX/HAProxy/Envoy)"]
        CRD["Custom Resources<br/>e.g., VirtualServer, Middleware"]
        Metrics["Metrics Exporter<br/>/metrics"]
        Webhook["Admission Controller<br/>(Validating Webhook)"]
    end

    %% 설정 리소스 계층
    IngressRes[Ingress Resources]
    Secret[TLS Secret]
    ConfigMap[ConfigMap]
    CRDDef["CRDs (VirtualServer, Policy 등)"]

    %% Kubernetes 서비스/파드 계층
    SvcA[Service A]
    SvcB[Service B]
    PodA1[Pod A1]
    PodA2[Pod A2]
    PodB1[Pod B1]

    %% 모니터링 도구
    Prometheus[(Prometheus)]

    %% 요청 흐름
    Client --> DNS --> LB --> Proxy

    %% 컨트롤러 구성 흐름
    IngressRes --> APIWatcher --> Controller
    APIWatcher --> Webhook
    Controller --> Cache
    Controller --> CRD
    Controller --> Proxy
    Controller --> Metrics
    Controller --> ConfigMap
    Controller --> Secret
    CRDDef --> CRD

    %% 서비스 연결
    Proxy --> SvcA --> PodA1
    SvcA --> PodA2
    Proxy --> SvcB --> PodB1

    %% 메트릭 흐름
    Metrics --> Prometheus

구성 요소

구현 기법 및 방법

요약 정리

배포 형태

Deployment 패턴

특징: ReplicaSet 기반 수평 확장 가능

장점: 롤링 업데이트, 자동 복구, 고가용성 확보

적용: 대부분의 Ingress Controller 기본 배포 방식

아키텍처 다이어그램:

graph TD
  subgraph Kubernetes Cluster
    LB[External LoadBalancer]
    svc["Service (type=LoadBalancer)"]
    dep[Deployment: Ingress Controller]
    pod1[Pod A]
    pod2[Pod B]
    pod3[Pod C]
  end

  LB --> svc
  svc --> pod1
  svc --> pod2
  svc --> pod3

배포 파이프라인 예시 (GitOps 기반):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# ArgoCD 앱 정의 예시
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: nginx-ingress
spec:
  source:
    repoURL: https://github.com/my-org/infra-config
    path: ingress/nginx
    targetRevision: HEAD
  destination:
    server: https://kubernetes.default.svc
    namespace: ingress-nginx
  project: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

구현 예시 (YAML):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-ingress
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ingress-nginx
  template:
    metadata:
      labels:
        app: ingress-nginx
    spec:
      containers:
        - name: controller
          image: k8s.gcr.io/ingress-nginx/controller:v1.12.4

DaemonSet 패턴

특징: 모든 노드에 하나의 Pod 을 배포

장점: 노드 로컬 처리로 지연 최소화, 외부 NodePort 연동에 적합

적용: 성능 중심 환경, Bare Metal 환경

아키텍처 다이어그램:

graph TD
  user[Client]
  user --> node1[Node 1]
  user --> node2[Node 2]
  user --> node3[Node 3]

  subgraph Node 1
    D1[DaemonSet Pod]
  end

  subgraph Node 2
    D2[DaemonSet Pod]
  end

  subgraph Node 3
    D3[DaemonSet Pod]
  end

배포 파이프라인 예시 (CI-CD 방식):

1
2

# CI 파이프라인에서 YAML 생성 → kubectl apply
kubectl apply -f nginx-daemonset.yaml

구현 예시 (YAML):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx-ingress-daemon
spec:
  selector:
    matchLabels:
      app: ingress-daemon
  template:
    metadata:
      labels:
        app: ingress-daemon
    spec:
      containers:
        - name: nginx-ingress
          image: k8s.gcr.io/ingress-nginx/controller:v1.12.4

Helm Chart 배포

특징: values.yaml 을 기반으로 선언적 배포

장점: 재사용성, 업그레이드 편의, 환경 분리 쉬움

적용: 대부분 Helm 공식 Chart 제공 (NGINX, Traefik 등)

아키텍처 다이어그램:

flowchart TB
  Dev[DevOps Engineer] --> GitHub[Helm Chart Repo]
  GitHub --> CI[CI Pipeline]
  CI --> K8s[Kubernetes Cluster]
  K8s --> ingress["Ingress Controller (Helm Release)"]

배포 파이프라인 예시 (Helm + GitOps):

1
2
3
4

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm upgrade --install nginx-ingress ingress-nginx/ingress-nginx \
  --namespace ingress-nginx --create-namespace \
  --values ./values.yaml

구현 예시 (values.yaml):

1
2
3
4

controller:
  replicaCount: 2
  service:
    type: LoadBalancer

Operator 기반 설치

특징: CRD + 컨트롤러로 구성

장점: 상태 기반 관리, 자동 복구 및 정책 중심 운영

적용: Istio, cert-manager, ArgoCD 등에서 광범위 사용

아키텍처 다이어그램:

graph TD
  cr[Custom Resource: IngressPolicy] --> op[Ingress Operator]
  op --> k8sres[Kubernetes Resources: Deployment, Service]

배포 파이프라인 예시 (Operator SDK + GitOps):

1
2
3

# 예시: Operator 설치 → CR 생성
kubectl apply -f operator.yaml
kubectl apply -f ingress-policy.yaml

구현 예시 (Custom Resource + CRD):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

apiVersion: networking.example.com/v1
kind: IngressPolicy
metadata:
  name: secure-policy
spec:
  tls:
    issuer: letsencrypt
  access:
    whitelist:
      - 1.2.3.4

리소스 구성

Ingress 리소스 선언 (YAML)

• Kubernetes 기본 제공 리소스인 Ingress 를 선언하여 라우팅 규칙 설정
• Host/Path 기반으로 트래픽을 백엔드 서비스로 전달

아키텍처 다이어그램:

graph TD
  client[Client Request]
  ingress[Ingress Resource]
  svc[Backend Service]
  pod["Pod (App)"]

  client --> ingress
  ingress --> svc
  svc --> pod

배포 파이프라인 예시 (GitOps 기반):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# ingress.yaml Git 저장소에 정의
# ArgoCD or Flux가 감시하여 자동 반영
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  rules:
    - host: "app.example.com"
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app-service
                port:
                  number: 80

구현 예시 (YAML):

1

kubectl apply -f ingress.yaml

Annotation 기반 설정

• Ingress 메타데이터에 어노테이션을 추가하여 컨트롤러별 특수 기능을 선언적으로 설정
• 예: 리다이렉션, 인증, 캐싱 등

아키텍처 다이어그램:

graph TD
  ingress[Ingress Resource w/ Annotation]
  ctrl[Ingress Controller]
  action["특수 기능 적용 (예: 리다이렉션, Auth)"]
  svc[Backend Service]

  ingress --> ctrl
  ctrl --> action
  action --> svc

배포 파이프라인 예시 (Helm + values override):

1
2
3

controller:
  config:
    enable-rewrite-target: "true"

구현 예시 (YAML):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$1
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  rules:
    - host: "app.example.com"
      http:
        paths:
          - path: /api/(.*)
            pathType: Prefix
            backend:
              service:
                name: app-service
                port:
                  number: 80

CRD 기반 확장 (예: Gateway API, Istio VirtualService 등)

• 기본 Ingress 기능을 넘는 복잡한 라우팅, 정책, TLS, 인증 등의 기능을 위해 CRD(Custom Resource) 기반 확장
• Gateway API, Istio, Traefik 등이 활용

아키텍처 다이어그램 (Gateway API 기반 예시):

graph TD
  client[Client]
  gw["Gateway (CRD)"]
  route["HTTPRoute (CRD)"]
  svc[Service]

  client --> gw
  gw --> route
  route --> svc

배포 파이프라인 예시 (Operator + CRD 등록 후 GitOps):

1
2

# Gateway API CRD 설치
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.0.0/standard-install.yaml

구현 예시 (HTTPRoute + Gateway):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: app-gateway
spec:
  gatewayClassName: nginx
  listeners:
    - name: http
      port: 80
      protocol: HTTP
      routes:
        kind: HTTPRoute
        selector:
          matchLabels:
            app: http-route

---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: http-route
  labels:
    app: http-route
spec:
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /foo
      backendRefs:
        - name: app-service
          port: 80

보안 구성

TLS Termination

• Ingress Controller 에서 HTTPS 요청의 TLS 암호화를 해제하고, 백엔드에는 HTTP 로 전달하는 방식
• 인증서는 Ingress Controller 또는 cert-manager 를 통해 자동 관리 가능

아키텍처 다이어그램:

sequenceDiagram
  participant Client
  participant Ingress
  participant Backend

  Client->>Ingress: HTTPS Request (TLS)
  Ingress->>Ingress: TLS Termination (SSL 해제)
  Ingress->>Backend: HTTP Request (내부 통신)

배포 파이프라인 예시 (cert-manager + GitOps):

1
2

# cert-manager CRD 설치
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/latest/download/cert-manager.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# ClusterIssuer 선언 (Let's Encrypt)
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    email: dev@example.com
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-prod-key
    solvers:
    - http01:
        ingress:
          class: nginx

구현 예시 (Ingress + 인증서 자동 적용):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tls-app-ingress
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  tls:
  - hosts:
    - app.example.com
    secretName: tls-secret
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app-service
            port:
              number: 80

인증 및 접근 제어

JWT 또는 OAuth2 인증 프록시

• 인증은 Ingress 앞단 또는 사이드카 형태의 인증 프록시에서 수행 (예: oauth2-proxy)
• 사용자 인증 후 Authorization 또는 ID Token 전달

아키텍처 다이어그램 (oauth2-proxy 기반):

sequenceDiagram
  participant Client
  participant Ingress
  participant OAuth2-Proxy
  participant Backend

  Client->>Ingress: HTTP Request
  Ingress->>OAuth2-Proxy: 인증 요청
  OAuth2-Proxy->>OAuth Server: Redirect + Token 요청
  OAuth Server-->>OAuth2-Proxy: JWT/Access Token
  OAuth2-Proxy-->>Ingress: 인증 완료
  Ingress->>Backend: 요청 전달 (with Header)

배포 파이프라인 예시 (Helm 으로 oauth2-proxy 설치):

1
2
3
4
5

helm repo add oauth2-proxy https://oauth2-proxy.github.io/manifests
helm install oauth2 oauth2-proxy/oauth2-proxy \
  --set config.clientID=$CLIENT_ID \
  --set config.clientSecret=$CLIENT_SECRET \
  --set config.cookieSecret=$COOKIE_SECRET

구현 예시 (Ingress + External Auth):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: secure-ingress
  annotations:
    nginx.ingress.kubernetes.io/auth-url: "https://oauth2-proxy.example.com/oauth2/auth"
    nginx.ingress.kubernetes.io/auth-signin: "https://oauth2-proxy.example.com/oauth2/start"
spec:
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app-service
                port:
                  number: 80

IP 화이트리스트 기반 접근 제어

• 특정 IP 만 접근 가능하도록 제한
• 주로 프라이빗 네트워크나 내부 시스템용으로 사용

아키텍처 다이어그램:

flowchart TD
  Client1[Client IP: 1.2.3.4]
  Client2[Client IP: 5.6.7.8]
  ingress[Ingress Controller]
  svc[Backend Service]

  Client1 --> ingress
  Client2 -. blocked .-> ingress
  ingress --> svc

구현 예시 (YAML Annotation 방식):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: internal-app-ingress
  annotations:
    nginx.ingress.kubernetes.io/whitelist-source-range: "192.168.0.0/16,203.0.113.0/24"
spec:
  rules:
  - host: internal.example.com
    http:
      paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: internal-service
              port:
                number: 80

운영 도구

로깅 및 모니터링

• Ingress Controller(NGINX, Traefik 등) 의 메트릭과 로그를 수집하여 Prometheus, Grafana, Loki 등으로 시각화 및 경보 설정
• 주요 관찰 지표: 요청 수, 지연 시간, 에러율, 4xx/5xx 상태코드 등

아키텍처 다이어그램:

flowchart TD
  client[Client Request] --> ingress[Ingress Controller]
  ingress --> backend[App Service]
  ingress --> prometheus["Prometheus (Metrics Export)"]
  ingress --> loki["Loki (Log Export)"]
  prometheus --> grafana[Grafana Dashboard]
  loki --> grafana

배포 파이프라인 예시 (Helm + values.yaml):

1
2
3
4
5
6
7
8

helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx --create-namespace \
  --set controller.metrics.enabled=true \
  --set controller.metrics.serviceMonitor.enabled=true \
  --set controller.metrics.serviceMonitor.additionalLabels.release=prometheus \
  --set controller.config.enable-access-log="true" \
  --set controller.config.log-format-escape-json="true" \
  --set controller.logLevel=info

구현 예시:

• values.yaml (모니터링 + 로깅)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

controller:
  metrics:
    enabled: true
    serviceMonitor:
      enabled: true
      additionalLabels:
        release: prometheus  # Prometheus Operator에서 자동 감지용

  logLevel: info

  config:
    enable-access-log: "true"             # 접근 로그 활성화
    log-format-escape-json: "true"        # JSON 형식 로그
    access-log-format: >-
      {"time": "$time_iso8601", "remote_addr": "$proxy_protocol_addr", "request": "$request", 
       "status": "$status", "body_bytes_sent": "$body_bytes_sent", "request_time": "$request_time",
       "upstream_response_time": "$upstream_response_time", "http_user_agent": "$http_user_agent"}

• Prometheus Operator 설치 시 자동 감지
• Grafana 에서 대시보드 템플릿: NGINX Ingress Controller dashboard (ID: 9614) 사용 가능

GitOps 연동

• Ingress 리소스 및 관련 YAML 파일을 Git 저장소에 선언하고, Argo CD 또는 Flux 등 GitOps 툴을 통해 자동으로 Kubernetes 클러스터에 적
• 구성 변경 시 Git commit → 자동 동기화 → 변경 반영

아키텍처 다이어그램:

flowchart TD
  dev[Developer Push] --> git[Git Repository]
  git --> argo[Argo CD Controller]
  argo --> cluster[Kubernetes Cluster]
  cluster --> ingress[Ingress + TLS + Policies]

배포 파이프라인 예시 (Argo CD Application):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: ingress-nginx
spec:
  project: default
  source:
    repoURL: 'https://github.com/my-org/infra-config'
    targetRevision: HEAD
    path: ingress/
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: ingress-nginx
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

구현 예시 (디렉토리 구조 예시):

1
2
3
4
5

infra-config/
└── ingress/
    ├── ingress.yaml
    ├── cert-issuer.yaml
    └── values.yaml  # Helm 기반 구성

• Git 저장소에 선언된 리소스를 기준으로 Argo CD 가 주기적으로 상태 감시
• kubectl describe application ingress-nginx 로 상태 점검 가능

장점

요약 정리

단점과 문제점 그리고 해결방안

단점

• 구조적 단점은 고가용성 미지원 및 L7 한계, 성능 단점은 병목/오버헤드, 운영 측면에서는 설정 복잡성과 진단 어려움, 플랫폼 측면에서는 벤더 종속성이 대표적이다.
• 해결방안은 수평 확장, 템플릿화, 표준 API 활용, 관찰성 도구 연계를 통해 보완 가능하다.

문제점

• 주요 문제는 설정 충돌, 인증서 자동화 실패, 트래픽 누락, 리소스 과다 사용, 보안 취약점 노출로 나뉘며
• 예방은 CI 검증 파이프라인, 모니터링/경보 시스템, 최신 버전 유지, 리소스 제한 설정 등으로 강화할 수 있다.
• 해결은 Admission Webhook, cert-manager 자동화, 정적 분석, 메트릭 기반 스케일링 등 실무 도구와 연계하여 진행해야 한다.

도전 과제

• 확장성과 성능 측면: Ingress 리소스 수가 많을 경우 컨트롤러의 성능 병목 발생 → IngressClass, CRD 분리, 수평 확장이 해법
• 보안 측면: 인증서 자동화 실패, 외부 노출로 인한 공격 위험 → cert-manager, WAF, 패치 적용, 제로 트러스트 접근
• 운영 자동화: 멀티 클러스터 환경, 정책 실시간 반영 어려움 → GitOps, ExternalDNS, Gateway API 기반 자동화 구조 필요
• 가시성과 디버깅: 라우팅 문제 추적 어려움 → 로그 구조화 (JSON), OpenTelemetry, Trace 연계 필요
• 복잡성과 이식성: 컨트롤러별 설정 편차 존재 → Gateway API 를 통한 표준화로 해결 가능
• 하이브리드 트래픽 (L4/L7): 기존 Ingress 로 처리 어려움 → LoadBalancer 서비스 또는 Gateway API 연동 필요

분류 기준에 따른 종류 및 유형

• 배포 방식

  • Deployment 방식은 확장성과 배포 유연성에 좋으며, DaemonSet은 각 노드에 직접 배포되어 특정 네트워크 환경에서 성능적으로 유리함

• 플랫폼 연동

  • 클라우드 네이티브 Ingress Controller는 퍼블릭 클라우드에 최적화돼 있고, 보통 부하 분산기 (LB) 와 긴밀히 통합됨
  • 인클러스터 방식은 오픈소스 및 커뮤니티 기반으로 자율성과 커스터마이징에 강함

• 트래픽 레벨

  • 대부분의 Ingress Controller 는 HTTP(S) 라우팅 중심이지만, 일부는 TCP/TLS 같은 L4 트래픽 처리도 지원하여 멀티 프로토콜 환경에 유리함

• 설정 방식

  • 기본 Ingress 는 Annotation 방식이 많지만, 확장성과 구조적 관리에서는 **CRD 기반 (Gateway API, VirtualService)**가 우수함
  • 특히 Gateway API는 현재 CNCF 에서 Ingress 의 차세대 표준으로 정립 중임

프록시 엔진 기반 분류

• NGINX, Envoy, HAProxy, Traefik 등 다양한 프록시가 Ingress Controller 의 기반 엔진으로 사용됨
• Envoy는 Service Mesh 와 연계하기 좋고, Traefik은 동적 구성과 미들웨어 내장으로 DevOps 에 최적화됨

요약 정리

추천 사용 시나리오

Gateway API vs. Ingress 비교

Kubernetes Ingress 는 오랜 기간 L7 트래픽 제어의 표준이었지만, 확장성 부족, 구성 일관성 부족, 구현체별 차이 등의 문제로 인해 Gateway API가 등장했다.

비교

Gateway API 리소스 구성

flowchart TB
    GC["GatewayClass\n(클러스터 전체에서 공통 정책 정의)"]
    GW["Gateway\n(리스너 정의 및 네트워크 진입점)"]
    HR["HTTPRoute\n(어플리케이션 라우팅 정의)"]
    TR["TLSRoute\n(HTTPS/TLS 라우팅)"]
    SR["Service\n(Kubernetes 백엔드 서비스)"]

    subgraph Cluster
        GC --> GW
        GW --> HR
        GW --> TR
        HR --> SR
        TR --> SR
    end

구조적 특징 요약

Yaml 예시

목표: example.com 으로 오는 요청 중 /app 경로를 Kubernetes 의 app-service 로 라우팅

Ingress 예제 (기존 방식)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
  - host: example.com
    http:
      paths:
      - path: /app
        pathType: Prefix
        backend:
          service:
            name: app-service
            port:
              number: 80

Gateway API 예제 (Gateway + HTTPRoute 방식)

[External Traffic]
        ↓
   [Gateway]           ← 클러스터 진입점 (Listener)
        ↓
   [HTTPRoute]         ← 어떤 조건으로 어떤 백엔드로 보낼지 정책 결정
        ↓
   [Kubernetes Service]

GatewayClass (클러스터 전역에서 사용될 클래스)

1
2
3
4
5
6

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: nginx-gw-class
spec:
  controllerName: k8s.io/nginx

Gateway (진입점 정의: Host, Port, TLS 등)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: default
spec:
  gatewayClassName: nginx-gw-class
  listeners:
  - name: http
    port: 80
    protocol: HTTP
    hostname: example.com

HTTPRoute (라우팅 정책 정의)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-route
  namespace: default
spec:
  parentRefs:
  - name: my-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /app
    backendRefs:
    - name: app-service
      port: 80

비교 요약

Gateway API 마이그레이션 시나리오 및 맵핑 가이드

Kubernetes 의 기존 Ingress 리소스는 단일 리소스 모델에 의존하며, 복잡한 L7 라우팅 및 멀티 프로토콜 처리가 어려웠다.
→ 이를 보완하기 위해 Gateway API 는 역할 기반 리소스 분리, CRD 기반의 확장성, 명시적 정책 구성을 제공한다.

마이그레이션 전략 단계별 시나리오

리소스 매핑 가이드

예시: 기존 Ingress → Gateway API

기존 Ingress

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: web.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8080

Gateway API (Gateway + HTTPRoute)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: web-gateway
spec:
  gatewayClassName: nginx
  listeners:
  - name: http
    port: 80
    protocol: HTTP
    allowedRoutes:
      namespaces:
        from: All
---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: web-api-route
spec:
  parentRefs:
  - name: web-gateway
  hostnames:
  - "web.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: api-service
      port: 8080

전환 시 주의사항

실무 적용을 위한 고려사항 및 주의할 점

• 보안에서는 TLS 설정, 인증서 자동화, 외부 인증 연동, WAF 적용 시의 영향 분석이 중요하다. 특히 cert-manager 는 운영 필수 도구로 자리잡고 있다.
• 성능 및 자원 관리에서는 CPU/메모리 limits, 캐싱 전략, 트래픽 규모에 따른 적절한 배포가 요구된다.
• 가용성 확보를 위해 Controller 이중화, HPA/VPA, PDB, 헬스 체크 설정 등 복수 계층의 장애 대응 전략이 필요하다.
• 운영 및 유지보수 관점에서는 선언형 구성과 GitOps, 경로 우선순위 충돌 방지, 관찰성 확보, 네임스페이스 설계 등이 실무 효율성과 안정성을 좌우한다.
• 다양한 구성요소 간 의존성을 고려하여 Helm/Kustomize 등의 도구로 설정을 템플릿화하고, 운영 자동화를 지속적으로 강화해야 한다.

실무 권장 시나리오

실무 활용을 위한 선택 가이드

실무 적용을 위한 운영 체크리스트

최적화 고려사항 및 주의할 점

Ingress Controller 는 고성능, 고가용성, 운영 편의성을 모두 고려해야 하는 핵심 컴포넌트로, 설정 단순화뿐 아니라 리소스 사용량, 성능, 보안까지 다각도로 최적화가 필요하다.

특히 다음 사항들을 중심으로 최적화를 고려해야 한다:

1. 성능 측면에서는 TLS 처리, Worker 수, Keep-Alive, Buffer 최적화 등 프록시 내부 처리 흐름 개선이 중요하다.
2. 리소스 측면에서는 HPA 설정, 노드 간 균형 배치, Auto Scaling 연동을 통해 안정성과 비용 효율을 확보해야 한다.
3. 운영 측면에서는 Annotation 남용 방지와 설정의 GitOps 화, Helm 템플릿화 등 구성 단순화가 유지보수성 향상에 핵심이다.
4. 보안 측면에서는 TLS Offload, Rate Limit 설정, 압축 적용 등으로 성능과 보호 수준을 동시에 고려해야 한다.

실무 사용 예시

Ingress Controller 는 단순한 라우팅 컴포넌트를 넘어 보안, 인증, 배포 전략, 모니터링, 자동화 등 다양한 실무 요구사항을 해결하는 중심 요소로 기능한다.

특히 다음과 같은 관점에서 핵심적인 역할을 한다:

• 보안/인증 계층 분리: OAuth2 Proxy, cert-manager 등을 통한 인증 게이트웨이 역할 수행
• 트래픽 제어 전략 강화: Canary 배포, 도메인 분리, 경로 기반 라우팅을 통한 서비스 유연성 확보
• 운영 자동화/관찰성 향상: GitOps 와 모니터링 도구를 통한 가시성 확보 및 CI/CD 연동

활용 사례

사례 1: 온라인 쇼핑몰

시나리오: 대용량 온라인 쇼핑몰 쿠버네티스 클러스터에 NGINX Ingress Controller 를 적용하여 멀티 도메인 트래픽 관리와 인증, TLS 자동화를 구현.

시스템 구성:

• Kubernetes 클러스터
• NGINX Ingress Controller
• cert-manager(SSL 자동화)
• Prometheus, Grafana(모니터링)
• 여러 백엔드 서비스

flowchart TD
    userA[User] --> dns[DNS]
    dns --> lb[External LB]
    lb --> nginxIC[NGINX Ingress Controller]
    nginxIC --> svcA[Service A]
    nginxIC --> svcB[Service B]
    nginxIC --> prom[Prometheus]
    nginxIC --> cert[cert-manager]
    nginxIC --> grafana[Grafana]

Workflow:

• 사용자가 도메인으로 접속하면 DNS→외부 LB→NGINX Ingress Controller 로 트래픽 전달
• 인그레스 컨트롤러에서 라우팅 정책에 따라 각 서비스로 트래픽 분기
• cert-manager 를 통해 SSL 인증서 자동 발급 및 갱신
• 모든 트래픽/에러/상태는 Prometheus, Grafana 로 실시간 모니터링

역할:

• NGINX Ingress Controller: 정책 해석, 트래픽 라우팅, SSL/TLS 종료
• cert-manager: 인증서 자동 관리
• Prometheus/Grafana: 모니터링 및 알림

유무에 따른 차이점:

• 미도입: 서비스별 개별 외부 노출, 수동 인증서 관리, 운영 복잡성 상승
• 도입: 중앙화 관리, 자동 인증서 갱신, 서비스 확장/운영 효율 증가

구현 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# Ingress 리소스 예시 - NGINX 기반
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  tls:
  - hosts:
    - shop.example.com
    secretName: shop-tls
  rules:
  - host: shop.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

위 인그레스는 shop.example.com 도메인으로 들어오는 /api 경로의 트래픽을 api-service 로 라우팅하고, shop-tls 인증서로 SSL 종료

사례 2: 쇼핑몰

시나리오: 쇼핑몰 프론트엔드와 백엔드 서비스를 동일 도메인에서 라우팅하며 인증을 제공하는 Kubernetes 기반 환경 구성

시스템 구성:

• Ingress-NGINX Controller
• cert-manager
• OAuth2-proxy
• 서비스: frontend-service, api-service

graph TD
  user[User Browser] --> https[https://shop.example.com]
  https --> Ingress["Ingress Controller (NGINX)"]
  Ingress --> OAuthProxy
  OAuthProxy --> AuthProvider[OAuth Provider]
  Ingress --> FrontendService[Frontend]
  Ingress --> APIService[Backend API]
  Ingress --> certManager["cert-manager (TLS)"]

Workflow:

• 사용자가 HTTPS 접속 → 인증 미완료 시 OAuth2-proxy 경유
• 인증 후 요청은 Host/Path 기반으로 Frontend 또는 API 에 라우팅
• TLS 인증서는 cert-manager 가 자동으로 갱신

역할:

• Ingress Controller: TLS 종료, 요청 분기
• OAuth2 Proxy: 인증 처리
• cert-manager: TLS 인증서 자동화

유무에 따른 차이점:

• ❌ Ingress 없음 → 모든 서비스 수동 노출 필요, 보안 구성 어려움
• ✅ Ingress 있음 → 중앙에서 인증 및 트래픽 제어 가능, 관리 일원화

구현 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop-ingress
  annotations:
    nginx.ingress.kubernetes.io/auth-url: "https://oauth2-proxy.shop.com/oauth2/auth"
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  tls:
  - hosts:
      - shop.example.com
    secretName: shop-tls
  rules:
  - host: shop.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 80
      - path: /api/
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8080

사례 3: 전자상거래 플랫폼

시나리오: 전자상거래 플랫폼에서 마이크로서비스 기반 웹 애플리케이션 운영

시스템 구성:

• NGINX Ingress Controller (고가용성 3 개 인스턴스)
• Frontend 서비스 (React 기반 웹 애플리케이션)
• API Gateway 서비스 (사용자 인증 및 API 라우팅)
• Product 서비스 (상품 정보 관리)
• Order 서비스 (주문 처리)
• Payment 서비스 (결제 처리)

graph TB
    subgraph "Internet"
        User[사용자]
        CDN[CloudFlare CDN]
    end
    
    subgraph "Load Balancer"
        LB[Cloud Load Balancer]
    end
    
    subgraph "Kubernetes Cluster"
        subgraph "Ingress Layer"
            IC1[NGINX Ingress 1]
            IC2[NGINX Ingress 2]
            IC3[NGINX Ingress 3]
        end
        
        subgraph "Application Services"
            Frontend[Frontend Service]
            API[API Gateway Service]
            Product[Product Service]
            Order[Order Service]
            Payment[Payment Service]
        end
    end
    
    User --> CDN
    CDN --> LB
    LB --> IC1
    LB --> IC2
    LB --> IC3
    IC1 --> Frontend
    IC1 --> API
    IC2 --> Frontend
    IC2 --> API
    IC3 --> Frontend
    IC3 --> API
    API --> Product
    API --> Order
    API --> Payment

Workflow:

• 사용자가 ecommerce.example.com 접속
• CloudFlare CDN 에서 정적 자산 캐싱 처리
• Cloud Load Balancer 가 트래픽을 NGINX Ingress Controller 로 분배
• Ingress Controller 가 경로 기반 라우팅 수행 (/api/* → API Gateway, /* → Frontend)
• API Gateway 에서 JWT 토큰 검증 후 백엔드 마이크로서비스로 라우팅

역할:

• SSL 종료 및 TLS 1.3 암호화 적용
• 경로 기반 라우팅 (/api, /static, /admin)
• 레이트 리미팅 (IP 당 분당 100 요청)
• WAF 규칙 적용 (SQL 인젝션, XSS 차단)

유무에 따른 차이점:

• Ingress Controller 사용 시: 단일 진입점, 중앙집중식 보안 정책, 비용 효율적
• 미사용 시: 서비스별 개별 LoadBalancer 필요, 관리 복잡성 증가, 인프라 비용 3-5 배 증가

구현 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

# NGINX Ingress Controller 설정
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ecommerce-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
    nginx.ingress.kubernetes.io/rate-limit: "100"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/use-regex: "true"
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - ecommerce.example.com
    secretName: ecommerce-tls
  rules:
  - host: ecommerce.example.com
    http:
      paths:
      - path: /api(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: api-gateway
            port:
              number: 80
      - path: /admin(/|$)(.*)
        pathType: Prefix
        backend:
          service:
            name: admin-panel
            port:
              number: 80
      - path: /(.*)
        pathType: Prefix
        backend:
          service:
            name: frontend
            port:
              number: 80
---
# ConfigMap for additional NGINX configuration
apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-configuration
data:
  proxy-connect-timeout: "15"
  proxy-send-timeout: "600"
  proxy-read-timeout: "600"
  client-max-body-size: "50m"
  enable-modsecurity: "true"
  enable-owasp-modsecurity-crs: "true"