Kubernetes용 서비스 프록시로 Telco 5G 네트워크 아키텍처 강화

2018년 초, 저는 네트워킹과 새로운 5G 표준에 대한 전문가인 친구들과 동료들과 비슷한 대화를 나누곤 했습니다. 우리 모두는 많은 미지수 속에서 전환을 향해 서두르고 있다는 막연한 불편함을 느꼈습니다. 우리 모두는 5G가 컨테이너와 클라우드 네이티브 아키텍처로의 전환을 촉진할 것이라는 점을 알고 있었지만, Kubernetes와 기타 클라우드 네이티브 도구는 원래 완전히 다른 사용 사례를 염두에 두고 만들어졌다는 사실도 알고 있었습니다. 우리 모두가 본 것(그리고 아마 이 글을 읽는 많은 사람들도 보았을 것)은 우리 산업이 속쓰림과 충돌할 길에 있다는 것이었습니다.

그런 불안한 시기 이후, 통신 서비스 제공업체(CSP)는 클라우드 기반 인프라로 마이그레이션하는 본격적인 작업을 시작했습니다. 이러한 배포의 초창기 개척자들은 실제로 Kubernetes 네트워킹의 중요 영역이 원래 설계된 대로 서비스 공급자 사용 사례의 요구 사항을 충족할 수 없다는 예상치 못한 장벽을 발견하고 있습니다. 통신사의 목표가 5G Stand Alone(SA) Core 배포로 이동하는지 아니면 분산 클라우드 아키텍처를 통한 현대화 이니셔티브의 일부인지에 관계없이 Kubernetes를 적용하여 네트워크 상호 운용성, 통신사 등급 확장성 및 통신사 보안 정책을 지원하는 것은 클라우드 네이티브 인프라 전반에 필요한 중요한 기능입니다.

그 이후로 Kubernetes는 주로 퍼블릭 클라우드나 엔터프라이즈 환경에서 실행되는 웹 및 IT 사용 사례에 초점을 맞춰 발전했기 때문에 서비스 공급자 사용 사례를 배포하기 위한 고유한 요구 사항 및 프로토콜 세트가 전혀 계획되지 않았다는 것은 이해할 만합니다. 하지만 다행히도 쿠버네티스의 아키텍트들은 쿠버네티스를 확장 가능하게 만드는 견고한 일련의 설계 패턴을 구축하여 네트워크 트래픽 관리, 가시성 및 제어, HTTP/2, GTP, SIP, Diameter 프로토콜과 같은 확장된 프로토콜 지원 등 기본적인 통신사 사용 사례에 대한 길을 열었습니다.

오늘날의 서비스 공급자 사용 사례에 Kubernetes를 적합하게 만들기 위해 필요한 개선 사항을 설명하기 전에 먼저 서비스 공급자 네트워크가 가져오는 고유한 요구 사항을 파악해 보겠습니다.

쿠버네티스는 더 큰 생태계에 적합해야 합니다.

첫째, 쿠버네티스 클러스터는 더 광범위한 서비스 공급자 네트워크 및 운영과 통합되어야 합니다. 건축 관련 결정은 운영 비용과 복잡성이 증가하는 등 장기적인 영향을 미칠 수 있습니다. 네트워크 아키텍트는 여러 통신사 사용 사례, 레거시 프로토콜 지원, Kubernetes 내의 동적 변경 사항이 기존 네트워크 토폴로지에 어떤 영향을 미칠 수 있는지(잠재적으로 복잡성 증가로 이어질 수 있음)를 고려해야 합니다.

둘째, 통신사 워크로드(네트워크 기능)는 IT 워크로드와 다릅니다. 서비스 제공자 네트워크와 네트워크 기능은 표준 HTTP/HTTPS나 TCP 외에 다른 것을 활용합니다. 모바일 서비스 제공업체에서는 SIP, GTP, SCTP 등의 기존 3G/4G 프로토콜과 5G HTTP2에 대한 네트워크 지원을 모두 갖추는 것이 중요합니다. 통신사 워크로드는 IT 워크로드와 비교해 기존 네트워킹 계층 위에 추가 표준 계층을 갖습니다.

마지막으로, 그리고 결코 덜 중요하지 않은 점은, 모든 새로운 노출 지점에 대해 보안이 가장 중요하다는 것입니다. 이를 위해서는 새로운 자동화, 가시성 및 관리 기능이 필요합니다. 새로운 기술을 도입할 때는 모든 계층에 보안을 구축하고 새로운 클러스터와 함께 작동해야 합니다. 서비스 제공업체의 SecOps 팀은 공격 표면을 줄이고 일관된 보안 제어를 구축할 방법을 항상 모색하고 있습니다. 또한, 네트워크의 보다 광범위한 보안 정책도 시간이 지남에 따라 업데이트되고 적응될 수 있어야 합니다.

이러한 기능적 격차를 해결하기 위한 두 가지 현재 접근 방식

Kubernetes 패턴 우회

클라우드 네이티브 패턴을 우회한다는 것은 아키텍트가 필연적으로 해킹을 만들게 된다는 것을 나타내는 지표입니다. Kubernetes에는 기본적으로 통신사 워크로드를 처리하는 도구가 포함되어 있지 않기 때문입니다. 우리는 통신사들이 패턴을 깨는 몇 가지 우려스러운 방식을 관찰했습니다.

• Kubernetes 네트워킹 우회 – 대다수의 CNF는 하나 이상의 인터페이스를 Kubernetes의 제어 밖에 배치합니다. 이러한 CNF는 직접적인 네트워크 액세스를 요구합니다(종종 "multus"에 대한 요청으로 제시되어 외부에 직접 연결되는 추가 인터페이스를 허용함). 중앙 네트워크 제어 지점이 없으면 Kubernetes의 내부 복잡성이 외부 서비스 공급자 네트워크에 노출되어 운영상의 복잡성과 비용이 증가하고, 보안 공격 표면도 늘어나게 됩니다. 또한 Kubernetes에서 컨테이너의 동적 특성을 처리하고 IP 주소를 관리해야 하는 모든 앱/네트워크 기능 개발자와 네트워크 운영자에게 더 많은 요구가 발생합니다. 이는 이제 외부 세계에 노출되었습니다.
• 각 네트워크 기능에 대한 별도 클러스터 – Kubernetes 네트워킹은 기본적으로 네트워크 트래픽 유입/유출을 위한 중앙 지점을 제공하지 않습니다. 쿠버네티스는 일부 수신 제어를 제공하지만 송신 트래픽은 거의 완전히 무시하며 수신 및 송신 네트워킹을 바인딩할 기본 제공 방법이 없습니다. 각 네트워크 기능이 자체 클러스터에서 실행되어 서버의 IP 주소와 네트워크 기능의 IP 주소 간의 상관 관계를 허용하는 여러 배포를 보았습니다. 이로 인해 리소스 오버헤드가 늘어나고 CapEx 지출이 늘어나며, 운영상의 복잡성도 늘어나 OpEx 지출이 늘어납니다.

Kubernetes 패턴에 맞춰 정렬

또 다른 접근 방식은 Kubernetes 디자인 패턴에 맞춰 Kubernetes 클러스터의 외부 세계에 대한 유입/유출 네트워킹 및 보안을 위한 "단일 창구"를 제공하는 서비스 프록시를 도입하는 것입니다. 서비스 프록시의 목적은 서비스 공급자 환경에서 사용될 때 Kubernetes가 나타내는 기능적 격차를 메우는 것입니다. 서비스 프록시는 다음을 수행해야 합니다.

• Kubernetes 네이티브 패턴을 사용하여 Kubernetes 네트워킹 확장(사용자 정의 리소스 정의, K8s 제어 루프)
• 더 광범위한 네트워크와의 인터페이스 (BGP 라우팅, 이그레스 SNAT IP 할당, IPv4/v6 변환)
• 각 CNF에 대해 개별적으로 링크 유입 및 유출
• 광범위한 L4/L7 지원 제공 (tcp, udp, sctp, NGAP, HTTP/2, Diameter, GTP, SIP)
• 보안 계층 제공 (TLS 종료, 방화벽, DDoS, 웹 애플리케이션 방화벽)
• 일관된 CNF를 제시하고 매우 동적인 Kubernetes 이벤트를 숨김

F5의 접근 방식 - 서비스 프록시 소개

F5는 Kubernetes를 확장하고 이 서비스 프록시를 생성하여 누락된 기능을 제공하기 위해 위에서 설명한 두 번째 시나리오를 선택했습니다. 수십 년간의 트래픽 관리 및 보안 전문 지식을 바탕으로 우리는 이 기능이 대규모 클라우드 네이티브 마이그레이션을 지원하는 데 필요하다고 믿습니다. 현재 프로덕션에 사용할 수 있는 Kubernetes(SPK) 클라우드 기반 인프라 제품을 위한 BIG-IP Next Service Proxy가 개발되었습니다. 이 제품은 Kubernetes의 단점을 직접 해결하고 서비스 제공자가 "바닐라" Kubernetes에 없는 리소스를 생성할 수 있도록 합니다. SPK는 광범위한 네트워크 및 보안 정책을 자동화하고 원활하게 통합하는 프레임워크를 통해 아키텍처를 단순화하고 보안을 강화합니다. 통신사를 위한 쿠버네티스에 대한 이러한 접근 방식은 앞으로도 복잡성과 운영 비용을 낮추고, 더 탄력적이고 안전한 인프라를 구축하는 데 도움이 될 것입니다. 오늘날 5G SA로의 전환이 둔화되고 있는 가운데( GlobalData에 따르면 통신사업자들은 5G SA에 실패하고 있음 ) 적합한 서비스 프록시가 도입되지 않으면 전환이 더욱 더디게 진행될 것으로 추정할 수 있습니다. 대규모 디지털 현대화를 진행 중인 생산 중인 텔레콤 고객은 SPK가 자신들이 알지 못했던 5G 네트워크 아키텍처 문제에 대한 Kubernetes 솔루션임을 입증하고 있다는 것을 깨닫고 있습니다.

F5의 SPK는 현재 GA 단계에 있으며 현재 대규모 통신사에서 생산되고 있습니다. 다른 접근 방식과 비교하여 SPK 기능을 시연하는 다가올 이벤트와 당사 플랫폼에서 CNF를 인증하는 방법을 확인해 보세요. 자세한 내용은 이 페이지를 방문하시고, F5 팀원과 직접 통화하고 싶으시면 저희에게 문의하세요 .