다중 테넌트 Kubernetes 클러스터의 Traefik
본문
Traefik in Multi-Tenant Kubernetes Clusters
Traefik은 기본적으로 클러스터 전체(클러스터 범위) 인그레스 컨트롤러로 설계돼요. 이런 이유로 Kubernetes Ingress나 IngressRoute 스펙을 사용할 때는, 여러 팀이나 테넌트가 같은 클러스터를 공유하는 다중 테넌트 Kubernetes 클러스터에서 Traefik의 공유 인스턴스를 사용하지 않는 것을 권장해요.
주된 이유는 다음과 같아요:
-
리소스 가시성과 격리: Traefik은 클러스터 수준 권한이 필요하고 네임스페이스 전반의 리소스를 감시해요. 한 테넌트 리소스의 잘못된 구성이 다른 테넌트에 영향을 줄 수 있어요.
-
공유 CRD: Middleware나 TLSOptions 같은 고급 구성 리소스는 클러스터 범위로 지정돼요. 충돌하는 정의가 여러 테넌트에 영향을 줄 수 있어요.
-
트래픽과 가용성 위험: 한 테넌트의 라우팅 규칙, 미들웨어, 또는 과중한 트래픽이 다른 테넌트와 간섭해 신뢰성과 성능에 영향을 줄 수 있어요.
-
관측 가능성과 프라이버시: 로그, 메트릭, 트레이스가 기본적으로 공유되어 테넌트 간에 민감한 정보가 노출될 수 있어요.
TLS 인증서 관리
이 제한의 핵심에는 Traefik이 사용하는 모든 TLS 인증서를 보관하는 TLS Store가 있어요.
이 Store는 Traefik에서 전역적이라 모든 네임스페이스에 걸쳐 공유되므로, 클러스터의 어떤 Ingress나 IngressRoute라도 다른 테넌트를 위해 만들어진 TLS 구성을 참조하거나 영향 줄 수 있어요.
이런 격리 부족은 서로 다른 팀이나 애플리케이션이 리소스(특히 TLS 인증서 같은 민감한 데이터) 사이에 엄격한 경계를 요구하는 다중 테넌트 환경에서 위험이 돼요.
권장 구성
다중 테넌트 Kubernetes 클러스터의 권장 접근 방식은 테넌트별로 전용 Traefik 인스턴스 하나를 배포하고, 그 테넌트의 네임스페이스(들)로 범위를 한정하는 거예요. 이렇게 하면 테넌트 사이의 엄격한 경계가 보장되고 테넌트 간 구성 누출이 방지돼요.
각 Traefik 인스턴스는 다음을 갖춰야 해요:
-
전용 ServiceAccount와 함께 테넌트의 네임스페이스에 배포
-
리소스 감시를 그 테넌트의 네임스페이스로만 제한하도록 provider.kubernetesCRD.namespaces와/또는 providers.kubernetesIngress.namespaces 구성
-
필요한 리소스에만 접근을 제한하는 Kubernetes RBAC 적용
이 네임스페이스별 테넌트 토폴로지는 Kubernetes NetworkPolicy 리소스와 결합될 때, 공유 클러스터에서 Traefik을 실행할 때 사용 가능한 가장 강력한 격리를 제공해요.
Helm Chart로 테넌트별 전용 Traefik 인스턴스 구성하기
providers:
kubernetesCRD:
namespaces:
- tenant
kubernetesIngress:
namespaces:
- tenant
Gateway API
또한 다중 테넌트를 일급 고려 사항으로 설계된 Kubernetes Gateway API를 채택하길 권장해요. Gateway API는 인그레스를 관리하기 위한 더 표현적이고 역할 지향적인 모델을 제공하며, 개별 테넌트에 라우트 구성을 위임하면서 클러스터 운영자를 위한 인프라 수준 제어를 보존하는 내장 지원을 갖고 있어요. 이 도구는 전통적인 Ingress 모델보다 다중 테넌트 시나리오를 더 강건하게 처리하며, 새 배포에 권장되는 방향이에요.
예를 들어 TLS 인증서 관리와 관련해 Listener 리소스는 관리자가 어떤 Route 리소스(예: HTTPRoute)가 어떤 도메인 이름이나 포트에 바인딩하도록 허용되는지 명시적으로 정의할 수 있게 해줘요.
이것은 테넌트 사이에 더 엄격한 소유권과 격리를 강제해, Gateway API를 전통적인 Ingress 모델보다 다중 테넌트 사용 사례에 더 안전하고 강건한 선택으로 만들어요.
다중 테넌트 환경의 새 배포에서는 Gateway API를 채택하는 것이 권장되는 방향이에요.