Ingress Controller 선택 가이드, Part 1: 요구사항 식별

조직이 처음 Kubernetes 실험을 시작할 때 Ingress Controller 선택에 대해 많은 생각을 하지 않는 경우가 많습니다. 그들은 모든 Ingress Controller가 비슷하다고 생각할 수 있으며 빠르게 시작하고 실행하기 위해 선택한 Kubernetes 프레임워크에 대해 기본 Ingress Controller를 유지하는 것이 가장 쉽습니다. 테스트나 소량 생산 환경에서는 거의 모든 Ingress Controller가 문제가 없는 것이 사실입니다. 그러나 확장함에 따라 Ingress Controller의 선택이 더욱 중요해집니다. Ingress Controller는 트래픽을 A 지점에서 B 지점으로 이동하는 기본 기능 이상을 제공할 수 있기 때문입니다.

고급 트래픽 관리에서 가시성(visibility), 기본 제공 보안에 이르기까지 Ingress Controller는 Kubernetes 스택에서 가장 강력한 도구 중 하나가 될 수 있습니다. 사실, NGINX에서 우리는 이것이 모든 프로덕션급 Kubernetes 배포의 기초라고 생각합니다. 그러나 많은 개발자와 Platform Ops 팀은 Ingress Controller의 모든 기능 또는 확장할 수 없는 Controller 선택의 결과를 깨닫지 못합니다. 확장성이 좋지 않거나 복잡한 환경을 보호하지 않는 Ingress Controller를 선택하면 Kubernetes를 테스트에서 프로덕션으로 가져오는 데 방해가 될 수 있습니다. 이 Ingress Controller 선택 가이드 시리즈에서는 Ingress Controller의 기본 사항과 현재와 미래에 필요한 기능과 보안을 제공하는 현명한 선택 방법을 교육하는 것을 목표로 합니다.

목차

1. Ingress Controller(인그레스 컨트롤러)란?
2. Ingress Controller(인그레스 컨트롤러)는 무엇을 합니까?
3. Ingress Controller(인그레스 컨트롤러)가 해결하기를 원하는 문제는 무엇입니까?
  3-1. Use Case 1: 모니터링 및 가시성(Monitoring and Visibility)
  3-2. Use Case 2: API Gateway
  3-3. Use Case 3: 인증 및 싱글 사인온(Authentication and Single Sign‑On)
  3-4. Use Case 4: 웹 애플리케이션 방화벽(WAF) 통합
4. Ingress Controller(인그레스 컨트롤러)에 리소스를 어떻게 할당하시겠습니까?
  4-1. 시간 비용에 대한 예산 책정
  4-2. Kubernetes 도구 소유권에 대한 참고 사항
  4-3. 자본 비용에 대한 예산 책정
5. 다음 단계: 위험 감수 및 미래 대비(Risk Tolerance and Future‑Proofing)

1. Ingress Controller(인그레스 컨트롤러)란?

IngIngress Controller는 Kubernetes 클러스터로 들어오는Layer 4 및 Layer 7 트래픽과 잠재적으로 클러스터에서 나가는 트래픽을 관리하는 특수 Load Balancer입니다. 우리 모두가 같은 페이지에 있도록 다음은 NGINX에서 사용하는 용어입니다(그리고 업계 전반에 걸쳐 거의 동일합니다).

Kubernetes 서비스에 대한 외부 액세스를 제공해야 하는 경우 URI 경로, 지원 서비스 이름 및 기타 정보를 포함하여 연결 규칙을 정의하는 Ingress 리소스를 생성합니다. 그러나 Ingress 리소스는 자체적으로 아무 작업도 수행하지 않습니다. Ingress 리소스에 정의된 규칙을 구현하려면 Ingress Controller 애플리케이션(Kubernetes API 사용)을 배포 및 구성해야 합니다.

2. Ingress Controller(인그레스 컨트롤러)는 무엇을 합니까?

  • Kubernetes 환경 외부의 트래픽을 수락하고 잠재적으로 수정(모양)하고 환경 내에서 실행되는 파드(Pod)에 배포합니다. Ingress Controlle는 기본 kube-proxy 트래픽 분산 모델을 대체하여 ADC(Application Delivery Controller) 및 리버스 프록시가 Kubernetes가 아닌 환경에서 제공하는 것과 같은 추가 제어를 제공합니다.
  • 서비스의 개별 파드(Pod)를 모니터링하여 지능형 라우팅을 보장하고 요청이 “블랙홀(black-holed)”되는 것을 방지합니다.
  • 상호 TLS(mTLS)로 보안을 강화하거나 특정 파드(Pod)에서 특정 외부 서비스로 나가는 트래픽을 제한하기 위해 송신 규칙을 구현합니다.

Ingress Controller를 선택해야 할 때 기능 목록으로 시작하고 싶은 마음이 들 수 있지만 멋진 기능을 가지고 있지만 비즈니스 요구 사항을 충족하지 못하는 Ingress Controller로 끝날 수 있습니다. 대신 Ingress Controller가 팀과 앱에서 얼마나 잘 작동하는지에 영향을 미치는 두 가지 요소인 사용 사례(해결할 문제)와 자원 조달(비용을 “지불”하는 방법)을 확인하십시오. 이 가이드의 나머지 부분에서 이 두 가지 주제를 다룰 것입니다.

※ 클릭하시면 PDF 파일로 크게 보실 수 있습니다.

3. Ingress Controller(인그레스 컨트롤러)가 해결하기를 원하는 문제는 무엇입니까?

Ingress Controller의 핵심 사용 사례는 트래픽 관리이므로 Ingress Controller가 다음과 같은 일반적인 사용 사례 중 하나 이상을 처리하기를 원할 것입니다.

  • Load balancing(HTTP2, HTTP/HTTPS, SSL/TLS 종료, TCP/UDP, WebSocket, gRPC)
  • 트래픽 제어(속도 제한, 회로 차단, 활성 상태 확인)
  • 트래픽 분할(디버그 라우팅, A/B 테스트, 카나리 배포, 블루-그린 배포)

그러나 “one-trick pony”에 만족할 이유가 없습니다. 대부분의 Ingress Controller는 트래픽 관리 이상을 수행할 수 있습니다. Ingress Controller를 사용하여 여러 문제를 해결하면 스택의 크기와 복잡성을 줄일 수 있을 뿐만 아니라 앱에서 Ingress Controller로 비기능 요구 사항을 오프로드(offload)할 수도 있습니다. 리소스를 보다 효율적으로 사용하면서 Kubernetes 배포를 보다 안전하고 민첩하며 확장할 수 있도록 도와줄 수 있는 4가지 Ingress Controller 사용 사례를 살펴보겠습니다.

3-1. Use Case 1: 모니터링 및 가시성(Monitoring and Visibility)

Kubernetes 클러스터에 대한 가시성 부족은 프로덕션 환경에서 가장 큰 문제 중 하나이며 문제 해결 및 복원력의 어려움에 기여합니다. Ingress Contoller는 Kubernetes 클러스터의 Edge에서 작동하고 모든 트래픽을 다루기 때문에 두 가지 일반적인 문제, 즉 Kubernetes 클러스터의 느린 앱 및 리소스 고갈 문제를 해결하는 데 도움이 될 수 있는 데이터를 제공하기에 적합한 위치에 있습니다. Ingress Controller가 가시성(Visibility)을 향상시키려면 다음을 수행해야 합니다.

  • 실시간으로 메트릭(metrics)을 제공하여 “지금” 무슨 일이 일어나고 있는지 진단할 수 있습니다.
  • Prometheus 및 Grafana와 같은 인기 있는 가시성 도구로 메트릭(metrics)을 내보낼 수 있습니다. 이 도구는 트래픽 급증 및 기타 추세를 예측하는 데 도움이 되도록 시간 경과에 따른 값을 표시합니다.

3-2. Use Case 2: API Gateway

Kubernetes에서 요청-응답 조작을 수행하려는 경우가 아니면 Ingress Controller가 API Gateway 역할을 두 배로 할 수 있습니다. 기능 세트에 따라 Ingress Controller는 TLS termination, 클라이언트 인증, 속도 제한(rate limiting), 세분화된 액세스 제어 및 Layer 4에서 Layer 7까지의 request routing을 포함한 핵심 API Gateway 기능을 제공할 수 있습니다.

3-3. Use Case 3: 인증 및 싱글 사인온(Authentication and Single Sign‑On)

Kubernetes 서비스에서 Ingress Controller로 로그인 자격 증명의 인증을 오프로드(offload)하면 두 가지 문제를 해결할 수 있습니다.

  • OpenID Connect(OIDC)로 싱글 사인온(SSO)을 구현하여 사용자가 단일 자격 증명 세트로 여러 앱에 로그인할 수 있도록 합니다.
  • 개발자가 앱의 비즈니스 로직에 집중할 수 있도록 각 애플리케이션에 인증 기능을 구축할 필요가 없습니다.

3-4. Use Case 4: 웹 애플리케이션 방화벽(WAF) 통합

Ingress Controller가 WAF(웹 애플리케이션 방화벽) 역할을 할 수 있다는 것이 아니라 WAF를 Ingress Controller와 통합할 수 있다는 것입니다. WAF는 Kubernetes 외부 및 내부의 여러 위치에 배포될 수 있지만 대부분의 조직에서 가장 효율적이고 효과적인 위치는 Ingress Controller와 동일한 파드(Pod)에 있습니다. 이 사용 사례는 보안 정책이 SecOps 또는 DevSecOps의 지시 하에 있고 세분화된 서비스별 또는 URI별 접근 방식이 필요한 경우에 적합합니다. 이는 Kubernetes API를 사용하여 정책을 정의하고 서비스와 연결할 수 있음을 의미합니다. 또한 Ingress Controller의 RBAC(역할 기반 액세스 제어) 기능을 통해 SecOps는 리스너별로 정책을 시행하는 반면 DevOps 사용자는 Ingress 리소스별로 정책을 설정할 수 있습니다.

4. Ingress Controller(인그레스 컨트롤러)에 리소스를 어떻게 할당하시겠습니까?

모든 Ingress Controller는 무료이며 오픈소스인 경우에도 비용이 듭니다. 일부 비용은 예산의 라인 항목으로 예측 가능한 금액을 할당할 수 있는 반면, 다른 비용은 선택한 Ingress Controller의 결과(복잡성 증가, 이식성 부족 등)를 처리하는 데 팀이 얼마나 많은 시간을 소비해야 하는지에 따라 다릅니다. Ingress Controller에 대한 예산을 책정할 때 고려해야 할 비용(시간과 비용 모두)을 살펴보겠습니다.

4-1. 시간 비용에 대한 예산 책정

인원 수에 대한 예산 책정은 고정 비용 항목보다 훨씬 더 어려울 수 있습니다. 특히 익숙하지 않은 공간에서 프로젝트에 리소스를 할당하려는 경우에는 더욱 그렇습니다. 다음과 같은 질문을 해야 합니다.

  • 누가 Ingress Controller를 구성하고 관리합니까? 정규직 업무의 일부입니까(예: Platform Ops 팀의 구성원으로서) 아니면 추가 책임(개발자로서)으로 수행하고 있습니까?
  • 직원들이 정식 교육을 받을 시간을 낼 수 있습니까? 아니면 직장에서 빠르고 쉽게 배울 수 있을 만큼 도구가 단순해야 합니까?
  • 직원들이 새로운 기능이 필요할 때마다 수정하도록 하거나 문제가 있을 때 문제 해결에 많은 시간을 할애할 준비가 되어 있습니까? 아니면 다른 비즈니스 가치를 제공하는 데 필요합니까?

4-2. Kubernetes 도구 소유권에 대한 참고 사항

우리는 NetOps 팀의 영역에서 도구와 소유권을 통합하려는 업계의 추세를 관찰했습니다. 이는 스택을 단순화하고 보안을 개선하는 데 큰 도움이 될 수 있지만 팀 목표에 따라 신중하게 도구를 복제할 것을 권장합니다. NetOps 팀이 더 넓은 플랫폼에 초점을 맞추기 때문에 경계 도구(예: 외부 Load Balancer)를 관리하도록 하는 것이 합리적이지만 DevOps 팀은 앱 코드에 가깝게 배포된 서비스에 가장 관심이 많으며 얻는 것보다 더 민첩하고 세분화된 제어가 필요합니다. NetOps 도구에서. Ingress Controller를 포함한 Kubernetes 도구는 DevOps에서 선택했을 때 성공할 가능성이 가장 높습니다. 그렇다고 개발자에게 도구에 대한 완전한 선택의 자유를 부여해야 한다는 것은 아닙니다! Kubernetes 내에서 도구의 일부 잔인한 표준화는 여전히 모범 사례입니다.

4-3. 자본 비용에 대한 예산 책정

조직에서 처음으로 Kubernetes를 실험할 때 도구나 지원에 대해 많은 예산을 책정하지 않는 경우가 많습니다. 더 많은 “손을 잡고” 필요로 하는 Ingress Controller를 진정으로 지원하기 위한 인력 리소스가 있다면 처음에는 금전적 예산이 없어도 괜찮습니다. 그러나 Kubernetes 투자가 증가함에 따라 도구의 기능에 제약을 받거나 팀을 다른 우선 순위에 전념하고 싶을 수 있습니다. 그때가 바로 저울이 엔터프라이즈 기능과 지원이 포함된 사용하기 쉽고 안정적인 도구에 대한 비용 지불에 대한 팁입니다.

Ingress Controller에 대한 비용을 지불할 준비가 되면 라이선스 모델이 중요하다는 점에 유의하십시오. Kubernetes 외부의 기존 가격 책정 모델을 기반으로 하는 Ingress Controller의 가격은 종종 “인스턴스당” 또는 “Ingress 프록시당”입니다. 이것이 Kubernetes에서 여전히 의미가 있는 사용 사례가 있지만 “클러스터당” 기반으로 Ingress Controller 라이선스를 부여한다는 것은 “프록시 수”가 아닌 애플리케이션 테넌시(tenancy)를 기반으로 비용을 지불한다는 것을 의미합니다.

다양한 시나리오에 대한 권장 사항은 다음과 같습니다.

Kubernetes가 처음이신가요? 클러스터별 라이선스를 선택합니다.
Kubernetes에 대한 경험이 없으면 필요한 Ingress Controller 인스턴스의 수를 정확하게 예측하기가 매우 어렵습니다. 여러 인스턴스를 선택해야 하는 경우 과소평가하여 목표 달성을 어렵게 하거나 과대평가하여 Kubernetes 프로젝트의 다른 부분에 더 잘 지출되는 비용을 낭비할 수 있습니다. “작은 클러스터”에 대해 상대적으로 낮은 고정 가격을 협상하면 성공 가능성이 높아집니다.

쿠버네티스 확장(Scaling)? 클러스터별 라이선스를 선택합니다.
Kubernetes 리소스를 확장 및 축소(버스트 및 축소)해야 하는 양과 빈도를 예측하는 것은 거의 불가능합니다. 인스턴스당 가격 책정으로 인해 팀은 라이선스 한도 내에서 유지하기 위해 임의의 임계값을 적용해야 합니다. 클러스터별 라이선스를 사용하면 개별 Ingress 컨테이너를 추적할 필요가 없으며 공급업체(예: NGINX)에 따라 추가 비용 없이 버스팅(bursting)이 포함될 수 있습니다.

고급 배포 또는 정적 배포? 인스턴스별 라이선스를 선택합니다.
Ingress Controller를 어떻게 사용할지 정확히 알고 Kubernetes에 대해 잘 알고 있고 클러스터당 소수의 Ingress 프록시를 사용할 계획이며 함께 제공될 수 있는 번들 서비스가 필요하지 않은 경우 도구를 사용하면 인스턴스당 가격 책정이 탁월한 선택이 될 수 있습니다.

5. 다음 단계: 위험 감수 및 미래 대비(Risk Tolerance and Future‑Proofing)

이제 요구 사항을 파악했으므로 다음 단계는 Ingress Controller가 도입할 수 있는 위험에 대한 허용 범위를 팀으로 결정하고 성장에 따라 Ingress Controller를 확장해야 하는 방법을 파악하는 것입니다.