본문으로 건너뛰기

Kong (미배포 — 데드코드)

Kong은 클러스터에 배포된 적 없습니다. bootstrap/kong/ 디렉토리에 매니페스트가 존재하지만, bootstrap/kustomization.yaml에서 제외되어 있어 ArgoCD가 해당 Application을 생성하지 않습니다.

현재 클러스터의 Ingress Controller는 Traefik입니다.

현재 상태​

bootstrap/kustomization.yaml은 다음 4개의 부트스트랩 애플리케이션만 등록합니다:

# bootstrap/kustomization.yaml (현재)
resources:
  - minio/argocd.yaml   # sync wave 0
  - zot/argocd.yaml     # sync wave 1
  - vault/argocd.yaml   # sync wave 2
  - gitea/argocd.yaml   # sync wave 3

bootstrap/kong/argocd.yaml은 이 목록에 없습니다. 따라서 kong 네임스페이스, Kong Pod, KongClusterPlugin 리소스는 클러스터에 존재하지 않습니다.

현재 책임 구조:

관심사현재 처리 주체
Ingress / TLS 종료Traefik (K3s 내장, platform/traefik-config/helmchartconfig.yaml으로 패치)
HTTP → HTTPS 리다이렉트Traefik HelmChartConfig 엔트리포인트 설정
CORSSpring Boot WebMvcConfigurer (애플리케이션 레벨)
JWT 검증Spring Security 필터 체인 (애플리케이션 레벨)
JWT 시크릿Vault secret/security/jwt → lumie-backend-jwt-secrets K8s Secret으로 직접 주입
테넌트 컨텍스트 헤더Spring Boot 필터 (X-Tenant-Slug, X-Tenant-Id, X-User-Id 등)
MinIO 업로드 프록시Traefik IngressRoute CRD (bootstrap/minio/manifests/upload-proxy-ingress.yaml)

설계 의도 (미실현)​

아래는 bootstrap/kong/ 매니페스트가 구현하려 했던 설계입니다. 실제로 동작한 적 없는 참조용 기록입니다.

배포 방식​

# bootstrap/kong/helm-values.yaml
gateway:
  deployment:
    daemonset: true
    hostNetwork: true   # 모든 노드 80/443 포트 직접 바인딩
  dnsPolicy: ClusterFirstWithHostNet
  image:
    repository: kong
    tag: "3.6"

Kong Ingress Controller(chart: ingress, targetRevision: 0.14.0)를 DaemonSet + hostNetwork 방식으로 배포하여, HAProxy 없이 모든 노드에서 직접 80/443 포트를 점유하는 구조였습니다.

KongClusterPlugin 목록​

bootstrap/kong/manifests/cluster-plugins.yaml에 정의된 플러그인:

플러그인 이름종류역할
https-redirectpre-function (global)HTTP 요청을 HTTPS로 301 리다이렉트
lumie-corscors허용 오리진(lumie-edu.com, dev.lumie-infra.com, localhost:3000) 및 헤더(X-Tenant-Slug 포함) CORS 정책
lumie-jwtjwtAuthorization 헤더 또는 lumie_access_token 쿠키에서 HS256 JWT 검증 (iss 클레임 기반 키 조회)
lumie-jwt-claimspost-function검증된 JWT 페이로드에서 sub, tenant_slug, tenant_id, role 추출 → 업스트림 헤더(X-User-Id, X-Tenant-Slug, X-Tenant-Id, X-User-Role) 주입

JWT 자격증명 관리​

bootstrap/kong/manifests/jwt-auth.yaml:

# Vault에서 JWT 시크릿 주입
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultStaticSecret
metadata:
  name: kong-jwt-credential-vss
  namespace: kong
spec:
  mount: secret
  path: security/jwt          # Vault KV 경로
  destination:
    name: kong-jwt-credential
    labels:
      konghq.com/credential: jwt
    transformation:
      templates:
        algorithm:
          text: "HS256"
        key:
          text: "lumie-auth-svc"
        secret:
          text: "{{ .Secrets.JWT_SECRET_KEY }}"
---
# KongConsumer (JWT 발급자 등록)
apiVersion: configuration.konghq.com/v1
kind: KongConsumer
metadata:
  name: lumie-auth-issuer
  namespace: kong
username: lumie-auth-svc
credentials:
  - kong-jwt-credential

HS256 알고리즘, iss=lumie-auth-svc 클레임으로 Kong이 JWT를 검증하는 구조였습니다. 현재는 동일한 시크릿(secret/security/jwt)이 Spring Boot에 직접 주입됩니다.

왜 Traefik으로 대체되었나​

Kong은 초기 설계 단계에서 API 게이트웨이로 선정되었으나, K3s 내장 Traefik이 이미 클러스터에 존재하고 DaemonSet+hostNetwork 방식의 Kong을 추가하는 복잡성 대비 실질적 이점이 없었습니다. JWT/CORS 처리는 Spring Boot 애플리케이션 레벨에서 충분히 수행 가능하므로, Kong 매니페스트는 배포 없이 보존 상태로 남아 있습니다.

관련 문서​