동일한 아키텍처에 BIG-IP와 NGINX Ingress Controller 배포하기

Micheál Kingston수석 제품 관리자

이전 블로그 시리즈인 「Kubernetes에서 애플리케이션 서비스 배포하기」에서는 많은 고객의 디지털 트랜스포메이션 여정에서 볼 수 있는 패턴을 살펴보았습니다. 대부분의 여정은 앱(일반적으로 모놀리식 앱)을 개발하고 배포하는 전통적인 모델에서 시작하며, 이 두 기능에 대한 책임은 서로 분리된 개발 팀과 운영 팀이 나누어 맡습니다. 조직이 보다 현대적인 모델로 전환하면서 마이크로서비스 기반 앱을 개발하고, 기존 사일로 간의 경계를 허무는 DevOps 방식을 사용해 이를 배포하게 됩니다.

DevOps 팀과 애플리케이션 소유자가 애플리케이션의 배포, 관리 및 제공 방식을 더욱 직접적으로 제어하고 있지만, 사일로의 장벽을 한꺼번에 허무는 것은 현실적으로 어려운 경우가 많으며 반드시 그럴 필요도 없습니다. 대신 다음과 같은 논리적인 책임 분담은 여전히 유효합니다:

• 네트워크 및 보안 팀은 기업 인프라 전반의 보안, 성능 및 가용성에 계속 집중합니다. 이들은 일반적으로 해당 인프라의 ‘관문’에 배포되는 글로벌 서비스를 가장 중요하게 생각합니다. 이러한 팀은 F5 BIG-IP을 사용하여 글로벌 서버 부하 분산(GSLB), DNS 확인 및 부하 분산, 정교한 트래픽 조정 등의 사용 사례를 지원합니다. BIG‑IQ와 NGINX Controller[현재 F5 NGINX Management Suite]는 NetOps 팀에 가장 적합한 형태로 메트릭과 알림을 제공하며, SecOps 팀에는 조직의 자산을 보호하고 업계 규정을 준수하는 데 필요한 보안 가시성과 제어 기능을 제공합니다.
• 운영 팀(운영에 중점을 둔 DevOps)은 관련 사업 부문의 요구에 따라 개별 애플리케이션을 구축하고 관리합니다. 이들은 업데이트된 기능을 더 빠르게 반복 개발할 수 있도록 지원하는 자동화 및 CI/CD 파이프라인과 같은 서비스를 가장 중요하게 생각합니다. 이러한 서비스는 일반적으로 Kubernetes 환경 내부와 같이 앱에 “더 가까운” 위치에 배포됩니다. 이 팀들은 NGINX Plus, NGINX App Protect, NGINX Ingress Controller, NGINX Service Mesh와 같은 NGINX 제품을 사용하여 Kubernetes 클러스터를 비롯한 여러 환경에서 호스팅되는 분산형 마이크로서비스 기반 애플리케이션의 부하 분산 및 트래픽 조정을 수행합니다. 사용 사례로는 TLS 종료, 호스트 기반 라우팅, URI 재작성, JWT 인증, 세션 지속성, 속도 제한, 상태 확인, 보안(통합 WAF로 NGINX App Protect 사용) 등이 있습니다.

Kubernetes 환경의 NetOps와 DevOps

NetOps 팀과 DevOps 팀의 서로 다른 관심사는 Kubernetes 환경에서 각 팀이 수행하는 역할과 이를 위해 사용하는 도구에 반영됩니다. 다소 단순화해서 말하자면, NetOps 팀은 주로 Kubernetes 클러스터 외부의 인프라 및 네트워킹 기능을 담당하고, DevOps 팀은 클러스터 내부의 해당 기능을 담당합니다.

Kubernetes 클러스터로 트래픽을 전달하기 위해 NetOps 팀은 이미 익숙한 기능과 다양한 오버레이 네트워킹 기술을 지원하는 외부 로드 밸런서로 BIG‑IP를 사용할 수 있습니다. 하지만 BIG‑IP만으로는 Kubernetes 클러스터 내부의 Pod 집합에 발생하는 변경 사항(예: Pod 수 또는 IP 주소 변경)을 추적할 수 없습니다. 이러한 제약을 해결하기 위해 F5 Container Ingress Services(CIS)가 클러스터 내부에 오퍼레이터로 배포됩니다. CIS는 Pod 집합의 변경 사항을 감시하고 그에 따라 BIG‑IP 시스템의 로드 밸런싱 풀에 있는 주소를 자동으로 수정합니다. 또한 새로운 Ingress, Route 및 사용자 지정 리소스가 생성되는지 확인하고 그에 따라 BIG‑IP 구성을 업데이트합니다.

BIG‑IP와 CIS를 함께 사용하여 애플리케이션 Pod로 전달되는 트래픽의 부하를 직접 분산할 수 있지만, 실제로는 NGINX Ingress Controller가 수많은 서비스를 나타내는 Pod 및 워크로드의 동적인 애플리케이션 변경 사항을 감지하고 지속적으로 반영하는 데 가장 적합한 솔루션입니다. 예를 들어, 수요 수준의 변화에 맞춰 애플리케이션 Pod를 수평 확장하는 경우가 이에 해당합니다.

NGINX Ingress Controller를 배포할 때 얻을 수 있는 또 다른 이점은 애플리케이션 부하 분산에 대한 제어 권한을 해당 애플리케이션을 담당하는 DevOps 팀으로 이전할 수 있다는 것입니다. 고성능 컨트롤 플레인과 DevOps 중심 설계 덕분에 여러 네임스페이스의 Kubernetes 서비스 전반에서 인플레이스 재구성 및 롤링 업데이트와 같이 빠르게 변화하는 DevOps 사용 사례를 지원하는 데 특히 뛰어납니다. NGINX Ingress Controller는 Kubernetes 네이티브 API를 사용하여 확장되는 포드를 검색합니다.

BIG-IP와 NGINX Ingress Controller의 연동 방식

아시다시피 BIG‑IP와 NGINX Ingress Controller는 원래 서로 다른 두 회사(각각 F5와 NGINX)에서 설계했습니다. F5가 NGINX를 인수한 이후, 고객들은 두 도구 간의 상호 운용성을 개선하면 인프라 관리가 간소화될 것이라는 의견을 전해 왔습니다. 이에 따라 IngressLink라는 새로운 Kubernetes 리소스를 개발했습니다.

IngressLink 리소스는 Kubernetes CustomResourceDefinition(CRD)을 사용하여 NGINX Ingress Controller와 BIG‑IP를 ‘연결’하는 간단한 기능 개선 사항입니다. 간단히 말해, NGINX Ingress Controller Pod 집합이 변경될 때마다 CIS가 BIG‑IP에 이를 ‘알릴’ 수 있게 해 줍니다. 이 정보를 바탕으로 BIG‑IP는 해당 로드 밸런싱 정책을 변경 사항에 맞게 신속하게 조정할 수 있습니다.

Kubernetes 클러스터의 부하 분산을 위해 BIG‑IP를 배포하고 NGINX Ingress Controller가 인그레스·이그레스 트래픽을 처리하도록 구성하면 트래픽 흐름은 다음과 같습니다:

1. BIG‑IP은 외부 트래픽을 NGINX Ingress Controller 인스턴스로 전달합니다.
2. NGINX Ingress Controller는 트래픽을 클러스터 내의 적절한 서비스로 분산합니다.
3. NGINX Ingress Controller는 매우 효율적이므로 안정적인 인스턴스 집합만으로도 애플리케이션 Pod 집합의 빈번하고 큰 변화를 처리할 수 있습니다. 그러나 트래픽 급증 및 감소에 대응하기 위해 NGINX Ingress Controller를 수평으로 확장하거나 축소해야 하는 경우, CIS는 IngressLink 리소스를 통해 변경 사항을 BIG‑IP에 알려 BIG‑IP가 변화에 신속하게 대응할 수 있도록 합니다.

시작하기

배포 가이드를 비롯하여 IngressLink 리소스의 작동 방식에 대한 자세한 내용은 F5 CloudDocs에서 확인하세요.

먼저 30일 무료 평가판을 신청하여 NGINX App Protect WAF 및 DoS가 포함된 NGINX Ingress Controller를 사용해 보세요. 아직 BIG‑IP 사용자가 아니라면 F5.com에서 팀에 가장 적합한 평가판을 선택하세요.

작성자 소개

Micheál Kingston수석 제품 관리자

Micheál Kingston의 다른 블로그 게시물