Ingress 컨트롤러 선택 가이드, 1부: 귀하의 요구 사항을 식별하세요

편집자 - 이 게시물은 10부작 시리즈의 일부입니다.

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

또한 전체 블로그 세트를 무료 전자책인 ' 테스트에서 프로덕션까지 Kubernetes 활용' 으로 다운로드할 수 있습니다.

조직이 Kubernetes를 처음 사용할 때 Ingress 컨트롤러 를 선택하는 데 많은 생각을 하지 않는 경우가 많습니다. 그들은 모든 Ingress 컨트롤러가 똑같다고 생각할 수 있으며, 신속하게 시작하고 실행하기 위해서는 선택한 Kubernetes 프레임워크의 기본 Ingress 컨트롤러를 고수하는 것이 가장 쉽다고 생각할 수 있습니다. 사실 모든 Ingress 컨트롤러는 테스트나 소량 생산 환경에 적합합니다. 하지만 확장할수록 Ingress 컨트롤러 선택이 더욱 중요해집니다. Ingress 컨트롤러는 트래픽을 A지점에서 B지점으로 이동시키는 기본 기능보다 훨씬 더 많은 기능을 제공할 수 있기 때문입니다.

고급 트래픽 관리부터 가시성, 내장 보안까지 Ingress 컨트롤러는 Kubernetes 스택에서 가장 강력한 도구 중 하나가 될 수 있습니다. 실제로 F5 NGINX에서는 이를 모든 프로덕션 등급 Kubernetes 배포의 기반이라고 생각합니다. 하지만 많은 개발자와 플랫폼 운영 팀은 Ingress 컨트롤러의 모든 기능을 깨닫지 못하고, 확장할 수 없는 컨트롤러를 선택했을 때의 결과도 깨닫지 못합니다. 확장성이 부족하고 복잡한 환경을 보호하지 못하는 Ingress 컨트롤러를 선택하면 Kubernetes를 테스트에서 프로덕션으로 전환하는 데 방해가 될 수 있습니다. 이 블로그 시리즈에서는 Ingress 컨트롤러의 기본에 대해 알아보고, 현재와 미래에 필요한 기능과 보안을 제공하는 현명한 선택을 하는 방법을 알려드립니다.

Ingress Controller란 무엇인가요?

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

• 유입 트래픽 – Kubernetes 클러스터에 들어오는 트래픽
• 이탈 트래픽 – Kubernetes 클러스터에서 나가는 트래픽
• 남북 트래픽 – Kubernetes 클러스터에 들어오고 나가는 트래픽( ingress-egress 트래픽이라고도 함)
• 동서 트래픽 – Kubernetes 클러스터 내 서비스 간을 이동하는 트래픽( 서비스 간 트래픽이라고도 함)
• 서비스 메시 - 서비스 간 트래픽을 라우팅하고 보안하기 위한 트래픽 관리 도구

왜 Ingress Controller가 필요한가요?

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

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

Ingress Controller는 무엇을 하나요?

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

Ingress 컨트롤러를 선택할 때 기능 목록으로 시작하는 것이 유혹적일 수 있지만, 환상적인 기능을 갖추고 있지만 비즈니스 요구 사항을 충족하지 못하는 Ingress 컨트롤러를 선택하게 될 수도 있습니다. 대신 Ingress 컨트롤러가 팀과 앱에 얼마나 잘 작동하는지에 영향을 미치는 두 가지 요소, 즉 사용 사례(해결할 문제)와 리소싱(비용을 "지불"하는 방법)을 살펴보세요. 이 블로그의 나머지 부분에서는 이 두 가지 주제에 대해 다루겠습니다.

Ingress Controller로 어떤 문제를 해결하고 싶으신가요?

Ingress 컨트롤러의 핵심 사용 사례는 트래픽 관리이므로 Ingress 컨트롤러가 다음과 같은 일반적인 사용 사례 중 하나 이상을 처리하도록 하려고 할 것입니다.

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

하지만 "한 가지 기능만 수행하는" 컨트롤러에 만족할 이유는 없습니다. 대부분의 Ingress 컨트롤러는 트래픽을 관리하는 것 이상의 기능을 수행할 수 있습니다. Ingress 컨트롤러를 사용하여 여러 문제를 해결하면 스택의 크기와 복잡성을 줄일 수 있을 뿐 아니라, 앱에서 기능적이지 않은 요구 사항을 Ingress 컨트롤러로 오프로드할 수도 있습니다. Kubernetes 배포를 보다 안전하고 민첩하며 확장 가능하게 만들고 리소스를 보다 효율적으로 사용하는 데 도움이 되는 4가지 비전통적인 Ingress 컨트롤러 사용 사례를 살펴보겠습니다.

모니터링 및 가시성

Kubernetes 클러스터의 가시성이 부족한 것은 프로덕션 환경에서 가장 큰 과제 중 하나이며, 문제 해결과 복원력에 어려움을 줍니다. Ingress 컨트롤러는 Kubernetes 클러스터의 가장자리에서 작동하고 모든 트래픽에 관여하므로 Kubernetes 클러스터나 플랫폼에서 느린 앱과 리소스 고갈이라는 두 가지 일반적인 문제를 해결(심지어 방지)하는 데 도움이 되는 데이터를 제공할 수 있는 위치에 있습니다. Ingress 컨트롤러의 가시성을 개선하려면 다음이 필요합니다.

• 실시간으로 측정 항목을 제공하여 "지금" 무슨 일이 일어나고 있는지 진단할 수 있습니다.
• Prometheus 및 Grafana와 같은 인기 있는 가시성 도구에 메트릭을 내보내어 시간에 따른 값을 표시하여 트래픽 급증 및 기타 추세를 예측할 수 있습니다.

API 게이트웨이

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

인증 및 Single Sign‑On

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

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

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

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

Ingress Controller의 리소스를 어떻게 확보할 예정인가요?

모든 Ingress 컨트롤러에는 비용이 듭니다. 무료이고 오픈 소스인 컨트롤러도 마찬가지입니다. "강아지처럼 무료"라는 표현을 들어보셨을 겁니다. 일부 비용은 예산의 개별 항목으로 예측 가능한 금액을 할당할 수 있고, 다른 비용은 선택한 Ingress 컨트롤러에 따른 결과(복잡성 증가, 휴대성 부족 등)를 처리하는 데 팀에서 얼마나 많은 시간을 할애해야 하는지에 따라 달라집니다. Ingress 컨트롤러를 위한 예산을 책정할 때 고려해야 할 시간적, 비용적 측면을 살펴보겠습니다. 시간과 비용입니다.

시간 비용에 대한 예산 책정

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

• Ingress 컨트롤러를 구성하고 관리하는 사람은 누구입니까? 이 일은 그들의 정규직(예: 플랫폼 운영팀 구성원)의 일부입니까? 아니면 추가적인 책임(개발자)으로 맡습니까?
• 직원들이 공식적인 교육을 받을 수 있도록 시간을 낼 수 있나요? 아니면 업무 중에 빠르고 쉽게 배울 수 있을 만큼 도구가 간단해야 할까요?
• 새로운 기능이 필요할 때마다 직원들이 이를 조작하거나, 문제가 있을 때 문제 해결에 많은 시간을 할애할 준비가 되어 있습니까? 아니면 다른 비즈니스 가치를 제공해야 합니까?

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

우리는 업계에서 NetOps 팀의 영역으로 도구와 소유권을 통합하는 추세를 관찰했습니다. 이를 통해 스택을 단순화하고 보안을 강화하는 데 큰 도움이 될 수 있지만, 팀 목표에 따라 도구를 신중하게 복제하는 것이 좋습니다. NetOps 팀이 경계 도구(예: 외부 로드 밸런서)를 관리하는 것은 합리적입니다. NetOps 팀은 더 광범위한 플랫폼에 집중하기 때문입니다. 그러나 DevOps 팀은 앱 코드에 가깝게 배포된 서비스를 가장 중요하게 여기며 NetOps 도구에서 얻는 것보다 더 많은 민첩성과 세밀한 제어가 필요합니다. Ingress 컨트롤러를 포함한 Kubernetes 도구는 DevOps에서 선택될 경우 성공 가능성이 가장 높습니다. 하지만 이는 개발자에게 도구 선택의 완전한 자유를 부여해야 한다는 의미는 아닙니다! 쿠버네티스 내에서 툴링을 어느 정도 표준화하는 것이 여전히 모범 사례입니다.

자본 비용 예산

조직이 처음으로 Kubernetes를 실험할 때는 도구나 지원에 많은 예산을 책정하지 않는 경우가 많습니다. 더 많은 "도움"이 필요한 Ingress 컨트롤러를 지원할 인적 자원이 있다면 처음에는 아무런 재정적 예산도 괜찮지 않습니다. 하지만 Kubernetes에 대한 투자가 늘어날수록 도구의 기능에 제한을 받거나 팀을 다른 우선순위에 전담시키고 싶을 수도 있습니다. 그러면 기업용 기능과 지원이 포함된 사용이 간편 하고 안정적인 도구에 비용을 지불하는 쪽으로 규모가 기울어집니다.

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

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

• 쿠버네티스를 처음 사용하시나요? 클러스터별 라이선싱을 선택하세요.
  Kubernetes에 대한 경험이 없으면 필요한 Ingress 컨트롤러 인스턴스 수를 정확하게 예측하기가 매우 어렵습니다. 여러 인스턴스를 선택해야 하는 경우 목표를 달성하기 어렵게 만들어 과소평가하거나, Kubernetes 프로젝트의 다른 부분에 더 잘 사용할 수 있는 비용을 과대평가하여 낭비할 수 있습니다. "소규모 클러스터"에 대해 비교적 낮은 고정 가격을 협상하면 성공 가능성이 높아집니다.
• 쿠버네티스 확장? 클러스터별 라이선싱을 선택하세요.
  Kubernetes 리소스를 얼마나 자주 확장 및 축소(버스트 및 붕괴)해야 할지 예측하는 것은 거의 불가능합니다. 인스턴스별 가격 책정으로 인해 팀은 라이선스 상한 내에 머무르기 위해 임의의 임계값을 적용해야 합니다. 클러스터별 라이선싱을 사용하면 개별 Ingress 컨테이너를 추적할 필요가 없으며 공급업체(예: NGINX)에 따라 추가 비용 없이 버스팅이 포함될 수 있습니다.
• 고급 배포 또는 정적 배포? 인스턴스별 라이선싱을 선택하세요.
  Ingress 컨트롤러를 어떻게 사용할지 정확히 알 만큼 Kubernetes에 정통하고 클러스터당 소수의 Ingress 프록시를 사용할 계획이며 도구와 함께 제공되는 번들 서비스가 필요하지 않은 경우 인스턴스당 가격 책정이 좋은 선택이 될 수 있습니다.

다음 단계: 위험 감수성과 미래 지향적 준비

이제 요구 사항을 파악했으므로 다음 단계는 팀에서 Ingress 컨트롤러가 초래할 수 있는 위험에 대한 허용 범위를 결정하고 Kubernetes 배포가 확장됨에 따라 Ingress 컨트롤러를 어떻게 확장해야 할지 파악하는 것입니다. 2부 에서는 이 주제를 다루겠습니다.