동일한 아키텍처에서 BIG-IP 및 NGINX Ingress Controller 배포

이전 블로그 시리즈인 'Kubernetes에서 애플리케이션 서비스 배포' 에서는 많은 고객이 디지털 혁신 과정에서 볼 수 있는 패턴에 대해 설명했습니다. 대부분의 여정은 앱을 만들고 배포하는 기존 모델(일반적으로 모놀리스)에서 시작하여 두 기능에 대한 책임을 분리된 개발팀과 운영팀으로 분할합니다. 조직이 보다 현대적인 모델로 전환함에 따라 마이크로서비스 기반 앱을 만들고 DevOps 방식을 사용하여 배포하는데, 이는 기존 사일로 간의 구분이 모호해짐을 의미합니다.

DevOps 팀과 애플리케이션 소유자가 애플리케이션 배포, 관리 및 제공 방법을 보다 직접적으로 제어하고 있지만 모든 사일로 벽을 한꺼번에 무너뜨리는 것은 실용적이지 않은 경우가 많으며 그럴 필요성도 없다고 생각합니다. 대신 우리는 여전히 책임의 논리적 구분이 적용된다는 것을 관찰합니다.

• 네트워크 및 보안 팀은 기업 인프라의 전반적인 보안, 성능 및 가용성에 계속해서 집중하고 있습니다. 그들은 일반적으로 해당 인프라의 "프런트 도어"에 배치되는 글로벌 서비스를 가장 중요하게 여깁니다.

  이러한 팀은 GSLB( 글로벌 서버 로드 밸런싱 ), DNS 확인 및 로드 밸런싱, 정교한 트래픽 셰이핑과 같은 사용 사례에 F5 BIG-IP를 사용합니다. BIG‑IQ 와 NGINX Controller [현재 F5 NGINX Management Suite ] 는 NetOps 팀에 가장 적합한 형태로 지표와 알림을 제공하고, SecOps 팀에게는 조직의 자산을 보호하고 업계 규정을 준수하는 데 필요한 보안에 대한 가시성과 제어 기능을 제공합니다.

• 운영 팀(Ops에 중점을 둔 DevOps)은 관련 사업부의 요구에 따라 개별 애플리케이션을 만들고 관리합니다. 그들은 업데이트된 기능에 대한 반복 작업을 보다 신속하게 수행하는 데 도움이 되는 자동화 및 CI/CD 파이프라인과 같은 서비스를 가장 중요하게 여깁니다. 이러한 서비스는 일반적으로 Kubernetes 환경 내부와 같이 앱에 "더 가깝게" 배포됩니다.

  이러한 팀은 Kubernetes 클러스터를 포함한 여러 환경에서 호스팅되는 분산형 마이크로서비스 기반 애플리케이션의 부하 분산 및 트래픽 셰이핑을 위해 NGINX Plus , NGINX App Protect , NGINX Ingress Controller , NGINX Service Mesh 와 같은 NGINX 제품을 사용합니다. 사용 사례로는 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는 포드 세트의 변경 사항을 감시하고 BIG‑IP 시스템의 부하 분산 풀에 있는 주소를 자동으로 그에 따라 수정합니다. 또한 새로운 Ingress, Route 및 사용자 지정 리소스가 생성되었는지 확인하고 이에 따라 BIG‑IP 구성을 업데이트합니다.

BIG‑IP와 CIS를 조합하여 트래픽을 애플리케이션 포드로 직접 부하 분산 할 수 있지만 실제로 NGINX Ingress Controller는 많은 수의 서비스를 나타내는 포드 및 워크로드에 대한 동적 애플리케이션 변경 사항을 발견하고 이를 따라잡는 데 이상적인 솔루션입니다. 예를 들어, 수요 수준 변화에 맞춰 애플리케이션 포드를 수평 확장하는 경우에 유용합니다.

NGINX Ingress Controller를 구축하는 또 다른 장점은 애플리케이션 로드 밸런싱에 대한 제어권을 애플리케이션 자체를 담당하는 DevOps 팀으로 넘긴다는 것입니다. 고성능 제어 평면과 DevOps 중심 설계 덕분에 여러 네임스페이스의 Kubernetes 서비스에서 즉시 재구성 및 롤링 업데이트와 같은 빠르게 변화하는 DevOps 사용 사례를 지원하는 데 특히 강력합니다. NGINX Ingress Controller는 Kubernetes의 기본 API를 사용하여 확장되는 Pod를 검색합니다.

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를 방문하세요.

NGINX App Protect WAF 및 DoS가 포함된 NGINX Ingress Controller의 무료 30일 체험판을 요청하여 시작하세요. 아직 BIG‑IP 사용자가 아니라면 F5.com에서 귀하의 팀에 가장 적합한 체험판을 선택하세요 .