Kubernetes Ingress Controller를 위한 프록시: 설정

```html

K8s 클러스터가 외부 요청을 수행하는 경우 — 파트너 API, 마켓플레이스, 광고 플랫폼에 — 언젠가는 IP 차단 문제에 직면하게 됩니다. Ingress Controller는 자체적으로 들어오는 트래픽을 관리하지만, 파드에서 나가는 요청을 위한 별도의 프록시 설정이 필요합니다. 이 기사에서는 프록시 유형 선택부터 NGINX Ingress 및 Traefik에 대한 구체적인 YAML 구성까지 올바르게 설정하는 방법을 설명합니다.

Kubernetes에서 프록시가 필요한 이유: 실제 시나리오

Kubernetes는 오케스트레이터이며, 대부분의 관련 기사들은 들어오는 트래픽에 대해 이야기합니다: Ingress를 설정하는 방법, TLS 인증서를 발급하는 방법, 서비스에 요청을 라우팅하는 방법. 그러나 다른 측면도 있습니다: 파드에서 나가는 트래픽. 여기에서 차단, 지리적 제한 및 IP 제한 문제가 발생합니다.

K8s 클러스터에서 프록시가 필수적인 구체적인 작업을 살펴보겠습니다:

가격 파싱 및 모니터링. 클러스터가 15분마다 CronJob을 실행하여 Wildberries, Ozon, Amazon에서 데이터를 수집합니다. IP 회전 없이 2-3시간 후에는 클라우드 공급자의 전체 IP 범위가 차단됩니다.
광고 API 작업. Facebook Marketing API, TikTok Ads API, Google Ads API — 모두 요청의 출처를 추적합니다. 여러 파드가 동일한 데이터 센터의 IP로 요청을 보내면 자동 차단의 트리거가 됩니다.
지리적 테스트. 서비스는 서로 다른 국가의 사용자에게 다른 콘텐츠를 보여줘야 합니다. 프록시를 통해 파드는 필요한 지역에서 요청을 모방하여 자동 테스트를 수행할 수 있습니다.
기업 제한 우회. 일부 인프라에서는 모든 나가는 트래픽이 기업 프록스를 통해 이루어져야 합니다 — 이는 컴플라이언스 요구 사항입니다.
IP 화이트리스트가 있는 파트너 API 작업. 파트너가 특정 IP에서만 요청을 허용하고 클러스터가 확장되어 주소를 변경할 때 — 정적 IP를 가진 프록시가 문제를 해결합니다.

아키텍처적 분리를 이해하는 것이 중요합니다: Ingress Controller는 들어오는 트래픽을 관리합니다 (사용자에서 서비스로), 그리고 나가는 요청을 위한 프록시는 별도의 작업입니다. 그럼에도 불구하고, 이들은 연결되어 있습니다: 프록시 구성은 종종 동일한 Ingress Controller 수준에서 설정되거나 그가 읽는 주석을 통해 설정됩니다.

💡 주요 구분

이 기사에서는 두 가지 시나리오를 다룹니다: (1) 외부 업스트림 서버를 위한 리버스 프록시로서의 Ingress Controller 설정, (2) 파드에서 나가는 트래픽을 외부 프록시 서버를 통해 라우팅하는 것입니다. 두 시나리오는 프로덕션에서 자주 발생합니다.

K8s 클러스터에 적합한 프록시 유형 선택하기

프록시 유형 선택은 클러스터가 차단 없이 얼마나 오랫동안 작동할 수 있는지에 직접적인 영향을 미칩니다. 데이터 센터 IP는 가장 저렴하지만 쉽게 식별되고 차단될 수 있습니다. 레지던트 및 모바일 IP는 더 비싸지만 실제 사용자를 모방하는 작업에서 훨씬 더 신뢰할 수 있습니다.

프록시 유형	속도	차단 위험	K8s에서의 최적 시나리오
데이터 센터	높음	높음	내부 API, 기업 컴플라이언스, IP 화이트리스트가 있는 파트너 통합
레지던트	중간	낮음	마켓플레이스 파싱, 광고 API 작업, 지리적 테스트
모바일	중간	최소	Facebook Ads API, TikTok API, 차단 위험이 있는 고부하 작업

K8s 클러스터에서 파싱이나 광고 플랫폼 작업과 관련된 대부분의 작업에 대해 최적의 선택은 회전하는 레지던트 프록시입니다. 이들은 실제 가정 사용자의 IP를 제공하며, 사이트 보호 알고리즘은 이러한 요청을 일반 브라우저 트래픽으로 인식합니다.

K8s에 대한 프로토콜 측면에서 가장 보편적인 것은 HTTP/HTTPS 프록시입니다 — 모든 인기 있는 HTTP 클라이언트에서 지원되며, 표준 환경 변수를 통해 설정할 수 있습니다 HTTP_PROXY 및 HTTPS_PROXY. SOCKS5는 비표준 프로토콜이나 HTTP뿐만 아니라 다른 프로토콜을 프록시할 때만 필요합니다.

NGINX Ingress Controller를 통한 프록시 설정

NGINX Ingress Controller는 K8s에서 가장 널리 사용되는 옵션입니다. 두 가지 시나리오를 살펴보겠습니다: 외부 업스트림에 대한 리버스 프록시로서 NGINX 설정 및 컨트롤러 자체를 위한 전역 나가는 프록시 설정.

업스트림 요청을 프록시하기 위한 주석

NGINX Ingress는 프록시 동작을 관리하기 위한 주석을 지원합니다. Ingress가 외부 서비스에 요청을 중개 프록시를 통해 전달하도록 하려면 사용자 정의 구성으로 ConfigMap을 사용하세요:

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
data:
  # NGINX의 나가는 요청을 위한 전역 HTTP 프록시
  http-snippet: |
    proxy_connect_timeout 10s;
    proxy_read_timeout 30s;
    proxy_send_timeout 30s;
  # 프록시를 통한 업스트림 설정
  use-proxy-protocol: "false"
  proxy-real-ip-cidr: "0.0.0.0/0"

프록시를 위한 주석이 있는 Ingress 리소스

개별 Ingress 리소스에 대해 주석을 통해 프록시 매개변수를 설정할 수 있습니다. 이는 서로 다른 서비스가 서로 다른 타임아웃 및 설정을 요구할 때 유용합니다:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-service-ingress
  namespace: production
  annotations:
    kubernetes.io/ingress.class: "nginx"
    # 프록시 타임아웃
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "10"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "60"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "60"
    # 버퍼 크기
    nginx.ingress.kubernetes.io/proxy-buffer-size: "16k"
    nginx.ingress.kubernetes.io/proxy-buffers-number: "8"
    # 실제 클라이언트 IP 전달
    nginx.ingress.kubernetes.io/use-forwarded-headers: "true"
    nginx.ingress.kubernetes.io/forwarded-for-header: "X-Forwarded-For"
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

NGINX 파드의 나가는 요청을 위한 외부 프록시 설정

NGINX Ingress Controller가 외부 프록시를 통해 나가는 요청을 수행해야 하는 경우 (예: 외부 엔드포인트의 헬스 체크를 위해), 컨트롤러의 Deployment에서 환경 변수를 설정해야 합니다:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
spec:
  template:
    spec:
      containers:
      - name: controller
        image: registry.k8s.io/ingress-nginx/controller:v1.9.4
        env:
        - name: HTTP_PROXY
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: http-proxy-url
        - name: HTTPS_PROXY
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: https-proxy-url
        - name: NO_PROXY
          value: "localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.cluster.local"

NO_PROXY 변수를 주의하세요 — 이는 매우 중요합니다. 이 변수가 없으면 모든 클러스터 내 트래픽도 외부 프록시를 통해 전달되어 서비스 간의 상호작용이 깨집니다. NO_PROXY에는 항상 RFC-1918 범위와 .cluster.local 접미사를 포함해야 합니다.

Traefik Ingress Controller에서 프록시 설정하기

Traefik은 Helm과 관리형 클러스터(k3s, Docker Swarm, Nomad)와 함께 사용할 때 특히 인기 있는 NGINX Ingress의 대안입니다. Traefik은 CRD(사용자 정의 리소스 정의)를 통해 구성 시스템을 가지고 있으며 정적/동적 구성을 지원합니다.

프록시가 있는 Traefik의 정적 구성

apiVersion: v1
kind: ConfigMap
metadata:
  name: traefik-config
  namespace: traefik
data:
  traefik.yaml: |
    # Traefik의 정적 구성
    entryPoints:
      web:
        address: ":80"
      websecure:
        address: ":443"
    
    # 프록시 뒤에서 작동하기 위한 설정
    serversTransport:
      insecureSkipVerify: false
      maxIdleConnsPerHost: 200
      dialTimeout: 10s
      responseHeaderTimeout: 30s
    
    # 프록시 진단을 위한 로깅
    log:
      level: INFO
    
    accessLog:
      fields:
        headers:
          defaultMode: keep
          names:
            X-Forwarded-For: keep
            X-Real-IP: keep

프록시 헤더 추가를 위한 미들웨어

Traefik에서는 요청을 전달할 때 헤더를 추가하거나 수정하는 미들웨어를 생성할 수 있습니다. 이는 프록시 체인을 통해 실제 클라이언트 IP를 올바르게 전달하는 데 유용합니다:

apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: proxy-headers
  namespace: production
spec:
  headers:
    customRequestHeaders:
      X-Forwarded-Proto: "https"
    # 인프라를 노출할 수 있는 헤더 제거
    customResponseHeaders:
      X-Powered-By: ""
      Server: ""
---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: my-app-route
  namespace: production
spec:
  entryPoints:
    - websecure
  routes:
  - match: Host(`myapp.example.com`)
    kind: Rule
    middlewares:
    - name: proxy-headers
    services:
    - name: my-service
      port: 80

Traefik Deployment를 위한 환경 변수

NGINX와 유사하게, Traefik의 경우 Helm values 또는 Deployment에서 직접 환경 변수를 설정합니다. Helm 차트를 사용할 때는 values.yaml를 통해 설정합니다:

# Traefik Helm 차트를 위한 values.yaml
deployment:
  enabled: true
  kind: Deployment
  
env:
  - name: HTTP_PROXY
    valueFrom:
      secretKeyRef:
        name: proxy-credentials
        key: http-proxy-url
  - name: HTTPS_PROXY
    valueFrom:
      secretKeyRef:
        name: proxy-credentials
        key: https-proxy-url
  - name: NO_PROXY
    value: "localhost,127.0.0.1,10.96.0.0/12,10.244.0.0/16,.cluster.local,.svc"

파드에서 환경 변수를 통한 프록시 설정

모든 파드에 대한 나가는 프록시를 설정하는 가장 보편적인 방법은 표준 환경 변수를 사용하는 것입니다. 이 방법은 프로그래밍 언어와 프레임워크에 관계없이 작동합니다: Python requests, Go net/http, Node.js axios, Java HttpClient — 모두 자동으로 HTTP_PROXY 및 HTTPS_PROXY를 읽습니다.

옵션 1: Pod Spec에 직접 설정

apiVersion: v1
kind: Pod
metadata:
  name: scraper-pod
  namespace: production
spec:
  containers:
  - name: scraper
    image: mycompany/scraper:latest
    env:
    - name: HTTP_PROXY
      value: "http://username:[email protected]:8080"
    - name: HTTPS_PROXY
      value: "http://username:[email protected]:8080"
    - name: NO_PROXY
      value: "localhost,127.0.0.1,10.0.0.0/8,.cluster.local"
    resources:
      requests:
        memory: "128Mi"
        cpu: "100m"
      limits:
        memory: "256Mi"
        cpu: "500m"

⚠️ 자격 증명을 평문으로 저장하지 마세요!

위의 예시는 가시성을 위해 보여준 것입니다. 프로덕션에서는 프록시 자격 증명을 항상 Kubernetes Secret에 저장하고 secretKeyRef를 통해 전달해야 합니다. 자세한 내용은 아래 Secrets 섹션을 참조하세요.

옵션 2: 여러 파드를 위한 ConfigMap을 통한 설정

여러 Deployment에서 프록시를 사용하는 경우, 설정을 ConfigMap으로 분리하고 envFrom을 통해 연결하는 것이 편리합니다:

apiVersion: v1
kind: ConfigMap
metadata:
  name: proxy-config
  namespace: production
data:
  NO_PROXY: "localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,.cluster.local,.svc.cluster.local"
  PROXY_TIMEOUT: "30"
  PROXY_MAX_RETRIES: "3"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: price-monitor
  namespace: production
spec:
  replicas: 5
  selector:
    matchLabels:
      app: price-monitor
  template:
    metadata:
      labels:
        app: price-monitor
    spec:
      containers:
      - name: monitor
        image: mycompany/price-monitor:v2.1
        envFrom:
        - configMapRef:
            name: proxy-config
        - secretRef:
            name: proxy-credentials
        ports:
        - containerPort: 8080

옵션 3: 변형 WebhookAdmissionController

모든 파드가 프록시를 사용해야 하는 기업 클러스터의 경우, 모든 생성되는 파드에 프록시 환경 변수를 자동으로 추가하는 변형 admission webhook을 설정할 수 있습니다. 이 솔루션은 모든 나가는 트래픽이 기업 프록시를 통해 이루어지도록 요구하는 컴플라이언스가 있는 엔터프라이즈 인프라에서 사용됩니다. 이러한 webhook의 구현은 이 기사의 범위를 넘어가지만, 존재하는 것을 아는 것이 중요합니다.

K8s에서 IP 회전 및 프록시 풀 관리

정적 프록시는 기업 컴플라이언스에는 좋지만, 차단을 피해야 하는 작업에는 좋지 않습니다. 50개의 파드가 동일한 IP를 통해 요청을 보낸다면, 해당 IP는 매우 빠르게 차단될 것입니다. 해결책은 프록시 회전입니다.

프록시 사이드카 패턴

하나의 패턴은 프록시 에이전트를 기본 애플리케이션 옆에 사이드카 컨테이너로 실행하는 것입니다. 사이드카는 localhost:8080에서 요청을 수신하고 회전하는 외부 프록시 풀을 통해 전달합니다:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: scraper-with-proxy-sidecar
  namespace: production
spec:
  replicas: 10
  selector:
    matchLabels:
      app: scraper
  template:
    metadata:
      labels:
        app: scraper
    spec:
      containers:
      # 기본 애플리케이션
      - name: scraper
        image: mycompany/scraper:latest
        env:
        - name: HTTP_PROXY
          value: "http://localhost:8080"
        - name: HTTPS_PROXY
          value: "http://localhost:8080"
        - name: NO_PROXY
          value: "localhost,127.0.0.1,.cluster.local"
      
      # 사이드카: 회전하는 로컬 프록시 에이전트
      - name: proxy-rotator
        image: mycompany/proxy-rotator:latest
        ports:
        - containerPort: 8080
        env:
        - name: PROXY_LIST_URL
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: api-endpoint
        - name: ROTATION_INTERVAL
          value: "60"  # 60초마다 회전
        resources:
          requests:
            memory: "64Mi"
            cpu: "50m"
          limits:
            memory: "128Mi"
            cpu: "200m"

중앙 프록시 서비스 패턴

대안적 접근 방식은 모든 파드가 접근하는 단일 프록시 서비스를 클러스터 내에서 운영하는 것입니다. 이는 관리가 더 간단합니다: 프록시 자격 증명을 포함하는 하나의 Secret을 업데이트하면 모든 파드가 자동으로 새로운 데이터를 사용하기 시작합니다.

apiVersion: v1
kind: Service
metadata:
  name: proxy-gateway
  namespace: proxy-system
spec:
  selector:
    app: proxy-gateway
  ports:
  - name: http
    port: 8080
    targetPort: 8080
  - name: socks5
    port: 1080
    targetPort: 1080
  type: ClusterIP
---
# 파드는 내부 DNS를 통해 프록시를 사용합니다
# HTTP_PROXY=http://proxy-gateway.proxy-system.svc.cluster.local:8080

익명성이 중요하고 차단 위험이 최소화된 작업(예: 마켓플레이스 파싱 또는 광고 API 작업)에서는 회전하는 레지던트 프록시를 사용하는 것이 좋습니다 — 이들은 실제 가정 사용자의 IP를 제공하여 클러스터의 트래픽이 일반 브라우저 트래픽과 구별되지 않도록 합니다.

Kubernetes Secrets에 프록시 자격 증명 저장하기

자격 증명을 안전하게 저장하는 것은 모든 프로덕션 클러스터에 대한 필수 요구 사항입니다. Git 리포지토리에 저장된 YAML 매니페스트에 프록시 로그인/비밀번호를 직접 삽입하지 마세요.

프록시를 위한 Secret 생성하기

# kubectl을 통해 생성 (값은 base64로 자동 인코딩됨)
kubectl create secret generic proxy-credentials \
  --namespace=production \
  --from-literal=http-proxy-url='http://user:[email protected]:8080' \
  --from-literal=https-proxy-url='http://user:[email protected]:8080' \
  --from-literal=socks5-proxy-url='socks5://user:[email protected]:1080'

# 생성된 Secret 확인
kubectl get secret proxy-credentials -n production -o yaml

Secret의 YAML 매니페스트

apiVersion: v1
kind: Secret
metadata:
  name: proxy-credentials
  namespace: production
  labels:
    app: proxy-config
    managed-by: ops-team
type: Opaque
# 값은 base64로 인코딩됨
# echo -n 'http://user:pass@proxy:8080' | base64
stringData:
  # stringData를 사용하면 값을 평문으로 지정할 수 있습니다
  # Kubernetes는 이를 자동으로 base64로 인코딩합니다
  http-proxy-url: "http://user:[email protected]:8080"
  https-proxy-url: "http://user:[email protected]:8080"
  proxy-host: "gate.proxycove.com"
  proxy-port: "8080"
  proxy-username: "user"
  proxy-password: "password"

Deployment에서 Secret 사용하기

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-worker
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-worker
  template:
    metadata:
      labels:
        app: api-worker
    spec:
      containers:
      - name: worker
        image: mycompany/api-worker:latest
        env:
        - name: HTTP_PROXY
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: http-proxy-url
        - name: HTTPS_PROXY
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: https-proxy-url
        - name: NO_PROXY
          value: "localhost,127.0.0.1,10.0.0.0/8,.cluster.local"
        # 호스트/포트를 별도로 읽는 애플리케이션의 경우
        - name: PROXY_HOST
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: proxy-host
        - name: PROXY_PORT
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: proxy-port

외부 비밀 저장소와의 통합

엔터프라이즈 환경에서는 HashiCorp Vault, AWS Secrets Manager 또는 Azure Key Vault에서 비밀을 동기화하기 위해 External Secrets Operator를 사용하는 것이 좋습니다. 이를 통해 수동 개입 없이 프록시 자격 증명을 자동으로 업데이트할 수 있습니다:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: proxy-credentials-ext
  namespace: production
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: proxy-credentials
    creationPolicy: Owner
  data:
  - secretKey: http-proxy-url
    remoteRef:
      key: secret/proxy/proxycove
      property: http_proxy_url
  - secretKey: https-proxy-url
    remoteRef:
      key: secret/proxy/proxycove
      property: https_proxy_url

K8s에서 프록시 설정 시 문제 해결 및 일반적인 오류

올바른 구성에도 불구하고 문제가 발생할 수 있습니다. 가장 흔한 문제와 진단 방법을 살펴보겠습니다.

문제 1: 클러스터 내 트래픽이 프록시를 통해 흐름

증상: 파드가 서로를 인식하지 못하고, 클러스터 내 DNS 해상도가 깨지며, 서비스가 응답하지 않습니다. 원인 — NO_PROXY 변수가 설정되지 않았습니다.

표준 K8s 클러스터에 대한 NO_PROXY의 최소 필요 값은 다음과 같습니다:

NO_PROXY=localhost,127.0.0.1,::1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.cluster.local,.svc,.svc.cluster.local,kubernetes.default.svc

문제 2: 특정 파드에 프록시가 적용되지 않음

진단: 파드에 들어가서 환경 변수를 확인하세요:

# 파드에서 환경 변수 확인
kubectl exec -it <pod-name> -n production -- env | grep -i proxy

# 파드에서 프록시를 통한 연결 테스트
kubectl exec -it <pod-name> -n production -- curl -v --proxy http://proxy:8080 https://httpbin.org/ip

# Secret이 올바르게 마운트되었는지 확인
kubectl exec -it <pod-name> -n production -- env | grep PROXY

문제 3: HTTPS 프록시 사용 시 TLS 오류

프록시가 자체 서명된 인증서나 기업 CA를 사용하는 경우, 애플리케이션은 TLS 검증 오류를 받게 됩니다. 해결책 — 프록시의 CA 인증서를 신뢰할 수 있는 목록에 추가합니다:

# CA 인증서로 ConfigMap 생성
kubectl create configmap proxy-ca-cert \
  --from-file=proxy-ca.crt=./proxy-ca.crt \
  -n production

# 파드에 마운트
spec:
  containers:
  - name: app
    volumeMounts:
    - name: proxy-ca
      mountPath: /etc/ssl/certs/proxy-ca.crt
      subPath: proxy-ca.crt
  volumes:
  - name: proxy-ca
    configMap:
      name: proxy-ca-cert

문제 4: 프록시를 통한 요청이 느림

프록시를 통한 요청이 직접 요청보다 상당히 느린 경우 — 다음을 확인하세요:

DNS 해상도: DNS 요청이 프록시를 통해 흐르지 않도록 확인하세요 (프록시에서 NO_PROXY에 추가)
Keep-alive 연결: 프록시 서버에 대한 연결 풀을 설정하세요
지리적 위치: 프록시 서버는 대상 리소스에 물리적으로 가까워야 합니다
프록시 유형: 고속 작업을 위해 데이터 센터 프록시를 고려하세요 — 최소 지연 시간을 제공합니다

유용한 진단 명령어

# Ingress Controller 로그 확인
kubectl logs -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx --tail=100

# 파드 이벤트 확인
kubectl describe pod <pod-name> -n production

# 파드에서 프록시 연결 테스트
kubectl run test-proxy --image=curlimages/curl --rm -it --restart=Never -- \
  curl -x http://user:pass@proxy:8080 -v https://httpbin.org/ip

# Secret이 존재하고 필요한 키를 포함하는지 확인
kubectl get secret proxy-credentials -n production -o jsonpath='{.data}' | python3 -c "
import sys, json, base64
data = json.load(sys.stdin)
for k, v in data.items():
    print(f'{k}: {base64.b64decode(v).decode()[:20]}...')
"

결론 및 권장 사항

Kubernetes에서 프록시 설정은 일회성 작업이 아니라 클러스터의 네트워크 보안 아키텍처의 일부입니다. 요약하자면:

NGINX Ingress Controller의 경우 — 개별 Ingress 리소스 수준에서 프록시 매개변수를 설정하기 위해 주석을 사용하고, 나가는 트래픽에 대한 전역 설정을 위해 Deployment에서 환경 변수를 사용하세요.
Traefik의 경우 — ConfigMap을 통한 정적 구성과 헤더 관리를 위한 미들웨어를 조합하세요.
파드의 경우 — Secrets를 통한 표준 변수 HTTP_PROXY / HTTPS_PROXY가 가장 보편적이고 안전한 접근 방식입니다.
항상 NO_PROXY를 설정하세요 — 그렇지 않으면 클러스터 내 트래픽이 깨질 수 있습니다.
프록시 자격 증명을 절대 평문으로 저장하지 마세요 — 매니페스트나 Git에 저장하지 마세요.
프로덕션에서는 — 자격 증명의 자동 회전을 위해 External Secrets Operator를 사용하세요.

K8s 클러스터가 IP 안정성과 차단 위험 최소화가 중요한 작업을 수행하는 경우 — 파싱, 광고 API 작업, 지리적 테스트 — 레지던트 프록시를 사용하는 것이 좋습니다. 이들은 실제 가정 사용자의 IP를 제공하여 보호 알고리즘이 이를 합법적인 트래픽으로 인식하게 합니다. 속도와 차단 위험이 최소화된 작업에는 모바일 프록시가 적합합니다 — 이들은 실제 4G/5G 네트워크를 통해 작동합니다.