인그레스 컨트롤러 선택 가이드 1부: 요구 사항 파악하기

Jenn GileNGINX 제품 마케팅 총괄

편집자 – 이 글은 10부작 시리즈의 일부입니다:

1. 프로덕션급 Kubernetes로 복잡성 줄이기
2. 고급 트래픽 관리로 Kubernetes의 복원력을 향상하는 방법
3. Kubernetes에서 가시성을 개선하는 방법
4. 트래픽 관리 도구를 사용하여 Kubernetes를 보호하는 6가지 방법
5. 인그레스 컨트롤러 선택 가이드, 1부: 요구 사항 파악하기(이 게시물)
6. 인그레스 컨트롤러 선택 가이드 2부: 위험 요소와 미래 대비
7. 인그레스 컨트롤러 선택 가이드 3부: 오픈 소스 vs. 기본 제공 vs. 상용
8. 인그레스 컨트롤러 선택 가이드, 4부: NGINX 인그레스 컨트롤러 옵션
9. 서비스 메시를 선택하는 방법
10. 동적 Kubernetes 클라우드 환경에서 NGINX Ingress Controller 성능 테스트

전체 블로그 모음을 무료 eBook으로 다운로드할 수도 있습니다. Kubernetes를 테스트에서 프로덕션으로 전환하기.

조직에서 Kubernetes를 처음 시험해 볼 때는 대개 Ingress 컨트롤러 선택에 큰 고민을 하지 않습니다. 모든 Ingress 컨트롤러가 비슷하다고 생각할 수 있으며, 빠르게 환경을 구축하고 실행하려면 선택한 Kubernetes 프레임워크의 기본 Ingress 컨트롤러를 그대로 사용하는 것이 가장 쉽습니다. 실제로 테스트 환경이나 트래픽이 적은 프로덕션 환경에서는 거의 모든 Ingress 컨트롤러가 무난합니다. 하지만 규모가 커질수록 Ingress 컨트롤러 선택은 더욱 중요해집니다. Ingress 컨트롤러는 트래픽을 A 지점에서 B 지점으로 전달하는 기본 기능보다 훨씬 더 많은 기능을 제공할 수 있기 때문입니다.

고급 트래픽 관리부터 가시성, 기본 제공 보안에 이르기까지 Ingress 컨트롤러는 Kubernetes 스택에서 가장 강력한 도구 중 하나가 될 수 있습니다. 실제로 F5 NGINX에서는 이를 모든 프로덕션급 Kubernetes 배포의 기반으로 간주합니다. 하지만 많은 개발자와 플랫폼 운영 팀은 Ingress 컨트롤러의 잠재력을 온전히 이해하지 못하며, 확장할 수 없는 컨트롤러를 선택했을 때의 결과도 인식하지 못합니다. 확장성이 부족하거나 복잡한 환경을 보호하지 못하는 Ingress 컨트롤러를 선택하면 Kubernetes를 테스트 단계에서 프로덕션 단계로 전환하지 못할 수 있습니다. 이 블로그 시리즈에서는 Ingress 컨트롤러의 기본 사항을 설명하고, 현재와 미래에 필요한 기능과 보안을 제공하는 현명한 선택을 하는 방법을 안내하고자 합니다.

Ingress 컨트롤러란 무엇인가요?

Ingress 컨트롤러는 Kubernetes 클러스터로 들어오는 레이어 4 및 7 트래픽과 잠재적으로 클러스터에서 나가는 트래픽을 관리하는 특수 로드 밸런서입니다. 모두가 같은 의미로 이해할 수 있도록 NGINX에서 사용하는 용어를 소개합니다(업계 전반에서 사용하는 용어와도 대체로 동일합니다).

• 인그레스 트래픽 – Kubernetes 클러스터로 들어오는 트래픽
• 이그레스 트래픽 – Kubernetes 클러스터에서 나가는 트래픽
• 남북 트래픽 – Kubernetes 클러스터로 들어오고 나가는 트래픽(일명 인그레스-이그레스 트래픽)
• 동서 트래픽 – Kubernetes 클러스터 내의 서비스 간에 이동하는 트래픽(일명 서비스 간 트래픽)
• 서비스 메시 – 서비스 간 트래픽을 라우팅하고 보호하기 위한 트래픽 관리 도구

Ingress 컨트롤러가 필요한 이유는 무엇인가요?

기본적으로 Kubernetes 파드(컨테이너)에서 실행되는 애플리케이션은 외부 네트워크에서 접근할 수 없으며, Kubernetes 클러스터 내의 다른 파드에서만 접근할 수 있습니다. Kubernetes에는 HTTP 부하 분산을 위한 기본 제공 구성 객체인 Ingress가 있으며, 이는 Kubernetes 클러스터 외부의 엔터티가 하나 이상의 Kubernetes 서비스로 대표되는 파드에 연결하는 방식을 정의합니다.

Kubernetes 서비스에 대한 외부 액세스를 제공해야 하는 경우, 연결 규칙을 정의하기 위해 Ingress 리소스를 생성합니다. 이러한 규칙에는 URI 경로, 백엔드 서비스 이름 및 기타 정보가 포함됩니다. 하지만 Ingress 리소스만으로는 아무 작업도 수행되지 않습니다. Ingress 리소스에 정의된 규칙을 구현하려면 Kubernetes API를 사용하여 Ingress 컨트롤러 애플리케이션을 배포하고 구성해야 합니다.

Ingress 컨트롤러는 어떤 역할을 하나요?

• Kubernetes 환경 외부에서 트래픽을 수신하고, 필요에 따라 이를 수정(셰이핑)한 후 환경 내부에서 실행 중인 Pod로 분산합니다. Ingress 컨트롤러는 기본 kube-proxy 트래픽 분산 모델을 대체하여, Kubernetes가 아닌 환경에서 애플리케이션 전송 컨트롤러(ADC)와 리버스 프록시가 제공하는 것과 같은 추가 제어 기능을 제공합니다.
• 서비스의 개별 파드를 모니터링하여 지능형 라우팅을 보장하고 요청이 “블랙홀로 빠지는” 현상을 방지합니다.
• 상호 TLS(mTLS)를 통해 보안을 강화하거나 특정 파드에서 지정된 외부 서비스로 나가는 트래픽을 제한하도록 이그레스 규칙을 구현합니다.

Ingress 컨트롤러를 선택할 때 기능 목록부터 살펴보고 싶을 수 있지만, 그러다 보면 뛰어난 기능을 갖추고도 비즈니스 요구 사항을 충족하지 못하는 Ingress 컨트롤러를 선택하게 될 수 있습니다. 대신 Ingress 컨트롤러가 팀과 애플리케이션에 얼마나 적합하게 작동할지를 좌우하는 두 가지 요소, 즉 사용 사례(어떤 문제를 해결할 것인지)와 리소스 조달(그에 필요한 비용을 어떻게 부담할 것인지)을 반드시 검토해야 합니다. 이 블로그의 나머지 부분에서는 이 두 가지 주제를 다루겠습니다.

Ingress 컨트롤러로 어떤 문제를 해결하고 싶으신가요?

Ingress 컨트롤러의 핵심 사용 사례는 트래픽 관리이므로, 다음과 같은 일반적인 사용 사례 중 하나 이상을 처리하도록 구성하는 것이 좋습니다:

• 부하 분산(HTTP2, HTTP/HTTPS, SSL/TLS 종료, TCP/UDP, WebSocket, gRPC)
• 트래픽 제어(속도 제한, 서킷 브레이킹, 능동 상태 확인)
• 트래픽 분할(디버그 라우팅, A/B 테스트, 카나리 배포, 블루-그린 배포)

하지만 한 가지 기능에만 만족할 이유는 없습니다. 대부분의 Ingress 컨트롤러는 트래픽 관리 외에도 다양한 기능을 수행할 수 있습니다. Ingress 컨트롤러를 활용해 여러 문제를 해결하면 스택의 규모와 복잡성을 줄일 수 있을 뿐만 아니라, 앱의 비기능 요구 사항을 Ingress 컨트롤러로 이전할 수도 있습니다. 리소스를 더욱 효율적으로 활용하면서 Kubernetes 배포의 보안, 민첩성, 확장성을 높이는 데 도움이 되는 네 가지 색다른 Ingress 컨트롤러 사용 사례를 살펴보겠습니다.

모니터링 및 가시성

Kubernetes 클러스터에 대한 가시성 부족은 프로덕션 환경에서 가장 큰 과제 중 하나로, 문제 해결을 어렵게 하고 복원력을 저하시킵니다. Ingress 컨트롤러는 Kubernetes 클러스터의 경계에서 작동하며 모든 트래픽을 처리하므로, 느린 애플리케이션과 Kubernetes 클러스터 또는 플랫폼의 리소스 고갈이라는 두 가지 일반적인 문제를 해결하고 심지어 예방하는 데 도움이 되는 데이터를 제공하기에 적합합니다. Ingress 컨트롤러가 가시성을 개선하려면 다음과 같은 기능이 필요합니다:

• 현재 무슨 일이 일어나고 있는지 진단할 수 있도록 실시간으로 메트릭을 제공합니다.
• 시간 경과에 따른 값을 그래프로 표시하여 트래픽 급증 및 기타 추세를 예측하는 데 도움이 되는 Prometheus 및 Grafana와 같은 널리 사용되는 가시성 도구로 메트릭을 내보낼 수 있어야 합니다

API 게이트웨이

Kubernetes에서 요청-응답을 조작하려는 경우가 아니라면, Ingress 컨트롤러를 API 게이트웨이로도 활용할 수 있을 가능성이 매우 높습니다. 제공되는 기능에 따라 Ingress 컨트롤러는 TLS 종료, 클라이언트 인증, 속도 제한, 세분화된 액세스 제어, 계층 4~7의 요청 라우팅을 비롯한 핵심 API 게이트웨이 기능을 제공할 수 있습니다.

인증 및 싱글 사인온

로그인 자격 증명 인증을 Kubernetes 서비스에서 Ingress 컨트롤러로 이전하면 두 가지 문제를 해결할 수 있습니다.

• OpenID Connect(OIDC)를 사용하여 SSO(Single Sign-On)를 구현함으로써 사용자가 하나의 자격 증명으로 여러 앱에 로그인할 수 있도록 합니다.
• 각 애플리케이션마다 인증 기능을 구축할 필요가 없어 개발자가 앱의 비즈니스 로직에 집중할 수 있습니다.

웹 애플리케이션 방화벽 통합

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

Ingress 컨트롤러에 리소스를 어떻게 할당할 것인가?

모든 Ingress 컨트롤러에는 비용이 따릅니다. 무료 오픈 소스인 경우에도 마찬가지입니다(‘강아지처럼 공짜’라는 표현을 들어보셨을 수도 있습니다). 어떤 비용은 예산 항목에 예측 가능한 금액으로 반영할 수 있지만, 어떤 비용은 선택한 Ingress 컨트롤러로 인해 발생하는 문제(복잡성 증가, 이식성 부족 등)를 해결하는 데 팀이 얼마나 많은 시간을 투입해야 하는지에 따라 달라집니다. Ingress 컨트롤러 예산을 책정할 때 고려해야 할 시간과 금전적 비용을 살펴보겠습니다.

시간 비용 예산 책정

인력 예산을 책정하는 일은 고정 비용 항목의 예산을 책정하는 것보다 훨씬 더 어려울 수 있습니다. 특히 익숙하지 않은 분야의 프로젝트에 필요한 인력을 배치하려는 경우에는 더욱 그렇습니다. 다음과 같은 질문을 고려해야 합니다:

• Ingress 컨트롤러의 구성 및 관리는 누가 담당하나요? 이 업무가 담당자의 본업인가요(예: 플랫폼 운영 팀 구성원), 아니면 개발자가 추가 업무로 맡게 되나요?
• 직원들이 정식 교육을 받을 시간을 마련할 수 있나요? 아니면 업무 중에도 빠르고 쉽게 익힐 수 있을 만큼 도구가 간단해야 하나요?
• 새로운 기능이 필요할 때마다 직원들이 도구를 직접 손보게 하거나, 문제가 발생했을 때 문제 해결에 많은 시간을 들이게 할 준비가 되어 있습니까? 아니면 직원들이 다른 비즈니스 가치를 창출하는 데 집중해야 합니까?

Kubernetes 도구 소유권에 관한 참고 사항

업계에서는 도구와 소유권을 NetOps 팀의 관할 아래 통합하는 추세가 나타나고 있습니다. 이는 기술 스택을 간소화하고 보안을 강화하는 데 크게 기여할 수 있지만, 저희는 팀의 목표에 따라 도구를 신중하게 중복 도입할 것을 권장합니다. NetOps 팀은 더 광범위한 플랫폼에 중점을 두므로 외부 로드 밸런서와 같은 경계 도구를 관리하는 것이 합리적입니다. 반면 DevOps 팀은 애플리케이션 코드와 가까운 곳에 배포되는 서비스를 가장 중요하게 여기며, NetOps 도구로는 얻기 어려운 더 높은 민첩성과 세밀한 제어가 필요합니다. Ingress 컨트롤러를 비롯한 Kubernetes 도구는 DevOps 팀이 직접 선택할 때 성공 가능성이 가장 높습니다. 그렇다고 개발자에게 도구 선택의 완전한 자유를 부여해야 한다는 뜻은 아닙니다! Kubernetes 내부에서는 도구를 어느 정도 과감하게 표준화하는 것이 여전히 모범 사례입니다.

자본 비용 예산 수립

조직에서 Kubernetes를 처음 도입해 시험할 때는 도구나 지원에 많은 예산을 배정하지 않는 경우가 많습니다. 더 많은 관리가 필요한 Ingress 컨트롤러를 제대로 지원할 인력이 있다면 처음에는 별도의 비용 예산이 없어도 괜찮습니다. 하지만 Kubernetes에 대한 투자가 늘어나면 도구의 기능적 한계에 부딪히거나 팀을 다른 우선순위에 투입하고 싶어질 수 있습니다. 이때부터는 사용하기 쉽고 안정적이며 엔터프라이즈 기능과 지원을 제공하는 도구에 비용을 지불하는 편이 더 유리해집니다.

Ingress 컨트롤러에 비용을 지불할 준비가 되었다면 라이선스 모델이 중요하다는 점을 유의해야 합니다. Kubernetes 외부의 전통적인 가격 책정 모델을 기반으로 Ingress 컨트롤러의 가격은 흔히 ‘인스턴스당’ 또는 ‘Ingress 프록시당’으로 책정됩니다. Kubernetes에서도 이러한 방식이 적합한 사용 사례가 있지만, Ingress 컨트롤러 라이선스를 ‘클러스터당’ 방식으로 적용하면 ‘프록시 수’가 아니라 애플리케이션 테넌시를 기준으로 비용을 지불하게 됩니다.

다양한 시나리오에 따른 권장 사항은 다음과 같습니다:

• Kubernetes를 처음 사용하시나요? 클러스터별 라이선스를 선택하세요.
  Kubernetes 경험이 부족하면 필요한 Ingress 컨트롤러 인스턴스 수를 정확히 예측하기가 매우 어렵습니다. 인스턴스 수를 정해야 한다면 너무 적게 예상해 목표 달성이 어려워지거나, 너무 많이 예상해 Kubernetes 프로젝트의 다른 부분에 더 유용하게 쓸 수 있는 비용을 낭비할 수 있습니다. 비교적 저렴한 고정 가격으로 ‘소규모 클러스터’ 계약을 체결하면 성공 가능성을 높일 수 있습니다.
• Kubernetes를 확장하고 계신가요? 클러스터별 라이선스를 선택하세요.
  Kubernetes 리소스를 얼마나 많이, 얼마나 자주 확장하거나 축소해야 할지 예측하는 것은 거의 불가능합니다. 인스턴스별 요금제에서는 라이선스 한도를 넘지 않도록 팀에서 임의의 기준치를 설정해야 합니다. 클러스터별 라이선스를 사용하면 개별 Ingress 컨테이너를 추적할 필요가 없으며, NGINX와 같은 일부 공급업체의 경우 추가 비용 없이 일시적인 확장이 포함될 수도 있습니다.
• 고급 또는 정적 배포 환경인가요? 인스턴스별 라이선스를 선택하세요.
  Kubernetes에 능숙하여 Ingress 컨트롤러를 어떻게 사용할지 정확히 알고 있고, 클러스터당 소수의 Ingress 프록시만 사용할 계획이며, 도구와 함께 제공될 수 있는 번들 서비스가 필요하지 않다면 인스턴스별 요금제가 좋은 선택이 될 수 있습니다.

다음 단계: 위험 감수 수준과 미래 대비

이제 요구 사항을 파악했으므로, 다음 단계는 Ingress 컨트롤러로 인해 발생할 수 있는 위험을 어느 정도까지 감수할지 팀 차원에서 결정하고, Kubernetes 배포 규모가 커짐에 따라 Ingress 컨트롤러를 어떻게 확장해야 할지 파악하는 것입니다. 이러한 주제는 2부에서 다룹니다.

작성자 소개

Jenn GileNGINX 제품 마케팅 총괄

Jenn Gile의 다른 블로그 게시물