NGINX Ingress Controller 와 BIG-IP를 함께 배포


대부분의 개발 및 배포 과정은 모놀리식 모델로 시작합니다. NGINX Ingress Controller 를 배포하는 또 다른 이점은 애플리케이션 로드 밸런싱의 제어를 애플리케이션을 담당하는 DevOps팀에게 넘길 수 있다는 점입니다. 이 모델에서는 애플리케이션의 생성과 배포를 개발팀과 운영팀이 분리하여 담당합니다.

그러나 기업이 더 현대적인 모델로 전환함에 따라, 마이크로서비스 기반 애플리케이션을 생성하고 DevOps 관행을 사용하여 배포하는 경우, 이러한 모놀리식 역할 구분이 흐려지게 됩니다.

DevOps팀과 애플리케이션 소유자는 애플리케이션이 배포, 관리 및 제공되는 방식을 보다 직접적으로 제어할 수 있지만 모놀리스의 벽을 한 번에 모두 허물는 것은 종종 실용적이지 않으며 필요하지도 않습니다.
대신 NGINX는 책임의 논리적 구분이 여전히 적용됨을 관찰합니다.

  • 네트워크 및 보안팀은 기업 인프라의 전체 보안, 성능 및 가용성에 집중합니다.
    일반적으로 이러한 팀은 인프라의 “입구”에 배포되는 글로벌 서비스에 가장 관심을 가지고 있습니다.
    이러한 팀은 BIG-IP를 전 세계적인 서버 로드 밸런싱(GSLB), DNS resolution 및 로드 밸런싱, 정교한 Traffic Shaping 만들기와 같은 사용 사례에 사용합니다. BIG-IQ와 NGINX Management Suite는 NetOps팀에 가장 적합한 형태로 메트릭과 알림을 제공하며, SecOps팀에는 조직의 자산을 보호하고 산업 규정을 준수하기 위해 SecOps가 가져야 할 가시성과 보안 제어를 제공합니다.
  • 운영팀(주로 운영에 중점을 둔 DevOps)은 해당 비즈니스 라인에 필요한 개별 애플리케이션을 생성하고 관리합니다.
    이 팀은 주로 자동화 및 CI/CD 파이프라인과 같은 서비스에 관심을 가지며, 이러한 서비스는 일반적으로 앱 “근처”에 배포됩니다. 예를 들어 Kubernetes 환경 내부에 배포됩니다.

    이러한 팀은 NGINX 제품인 NGINX Plus, NGINX App Protect, NGINX Ingress Controller 및 NGINX Service Mesh를 사용하여 분산된, 마이크로서비스 기반 애플리케이션의 로드 밸런싱과 Traffic Shaping을 수행합니다.
    이러한 사용 사례에는 TLS Termination, 호스트 기반 라우팅, URI 재작성(Rewrite), JWT 인증, 세션 지속성, 요청 제한(Rate Limit), Health Check, 보안(통합 WAF로 NGINX App Protect 사용) 등이 포함됩니다.

목차

1. Kubernetes 환경에서의 NetOps 및 DevOps
2. BIG-IP와 NGINX Ingress Controller 가 함께 작동하는 방식
3. 시작하기

1. Kubernetes 환경에서의 NetOps 및 DevOps

NetOps팀과 DevOps팀의 다른 관심사는 Kubernetes 환경에서의 역할과 해당 역할을 수행하는데 사용하는 도구에 반영됩니다.
과도한 단순화의 위험을 감수하면, NetOps팀은 주로 Kubernetes 클러스터 외부의 인프라 및 네트워크 기능에 관심을 가지고 있으며, DevOps팀은 주로 클러스터 내부의 기능에 관심을 가지고 있습니다.

NetOps팀은 Kubernetes 클러스터로 트래픽을 전달하기 위해 BIG-IP를 사용할 수 있습니다.
BIG-IP는 이미 알고 있는 오버레이 네트워킹 기술의 기능과 범위를 지원하는 외부 로드 밸런서입니다.
하지만 BIG-IP 자체로는 Kubernetes 클러스터 내의 Pod 세트의 변경사항 (ex: Pod의 개수 변경이나 IP 주소 변경)을 추적할 수 있는 방법이 없습니다.

이 제약을 해결하기 위해 Container Ingress Controller (CIS)가 클러스터 내부에 오퍼레이터로 배포됩니다.
CIS는 Pod 세트의 변경 사항을 감지하고 BIG-IP 시스템의 로드 밸런싱 풀 내의 주소를 자동으로 수정합니다.
또한 Ingress, Route 및 사용자 정의 리소스의 생성 여부를 확인하고 BIG-IP 구성을 업데이트 합니다.

BIG-IP와 CIS의 조합을 사용하여 애플리케이션 Pod로 트래픽을 로드 밸런싱할 수 있지만,
실제로 NGINX Ingress Controller 가 Pod와 대규모 서비스를 나타내는 워크로드의 동적인 애플리케이션 변경을 탐지하고 따라가는 이상적인 솔루션입니다.

NGINX Ingress Controller 를 배포하는 또 다른 이점은 애플리케이션 로드 밸런싱의 제어를 애플리케이션을 담당하는 DevOps팀에게 넘길 수 있다는 점입니다.

고성능의 Control Plane과 DevOps 중심적인 디자인은 특히 다중 네임스페이스에서 Kubernetes 서비스 전체에 대한 빠르게 변경되는 DevOps 사용 사례(ex: 장소에서의 재구성 및 롤링 업데이트)를 지원하는 데 강점을 발휘합니다. NGINX Ingress Controller는 Pod를 확장할 때 네이티브 Kubernetes API를 사용하여 Pod를 탐지합니다.

2. BIG-IP와 NGINX Ingress Controller 가 함께 작동하는 방식

아시다시피 BIG-IP 및 NGINX Ingress Controller는 원래 두 개의 별개 회사 (F5와 NGINX)에서 설계되었습니다.
F5가 NGINX를 인수한 이후, 고객들은 두 도구 간의 상호 운용성을 향상 시키면 인프라 관리가 간소화될 것이라고 NGINX에게 전달해 왔습니다.
이에 대응하여 NGINX는 Ingress Link라는 새로운 Kubernetes 리소스를 개발했습니다.

IngressLink 리소스는 Kubernetes Custom Resource Definition (CRD)를 사용하여 NGINX Ingress Controller와 BIG-IP를 “연결”하는 간단한 기능 개선입니다.
간단히 말해, 이것은 CIS가 NGINX Ingress Controller Pod 세트가 변경되었음을 BIG-IP에 “알리도록” 하는 것을 가능하게 합니다.
이 정보를 통해 BIG-IP는 대응하는 로드 밸런싱 정책을 유연하게 조정하여 일치시킬 수 있습니다.

BIG-IP가 Kubernetes 클러스터로의 로드 밸런싱을 처리하고 NGINX Ingress Controller가 Ingress-Egress 트래픽을 처리하는 경우, 트래픽 흐름은 다음과 같습니다:

  1. BIG-IP는 외부 트래픽을 NGINX Ingress Controller 인스턴스로 전달합니다.
  2. NGINX Ingress Controller는 클러스터 내 적절한 서비스로 트래픽을 분배합니다.
  3. NGINX Ingress Controller는 매우 효율적이기 때문에 안정적인 인스턴스 세트가 자주 발생하는 애플리케이션 Pod의 변경 사항을 처리할 수 있습니다.
    그러나 NGINX Ingress Controller 가 가로 스케일 아웃 또는 인 (트래픽 증감을 처리하기 위해) 필요한 경우, CIS는 변경 사항에 대해 IngressLink 리소스를 통하여 BIG-IP에 알려줍니다.
    이를 통해 BIG-IP가 변경 사항에 빠르게 대응할 수 있습니다.
Topology diagram of F5 BIG-IP and F5 NGINX Ingress Controller deployed in the same Kubernetes environment with F5 Container Ingress Services

3. 시작하기

NGINX App Protect WAF 및 DoS가 포함된 NGINX Ingress Controller의 30일 무료 평가판을 요청하여 시작하세요 .

아래 뉴스레터를 구독하고 NGINX와 NGINX STORE의 최신 정보들을 빠르게 전달 받아보세요.