https://blogs.vmware.com/load-balancing/2020/08/21/overcoming-application-delivery-challenges-for-kubernetes/
쿠버네티스는 컨테이너 기반 워크로드를 위한 우수한 자동화된 애플리케이션 배포 플랫폼을 제공합니다. 트래픽 관리, 클러스터 내, 클러스터/지역 및 가용성 영역 간 로드 밸런싱, 서비스 검색, 모니터링/분석 및 애플리케이션 보안과 같은 애플리케이션 서비스는 최신 애플리케이션 인프라에 매우 중요합니다. 그러나 쿠버네티스를 사용하거나 배치할 때는 다양한 과제가 있다. 일부 과제는 쿠버네티스에게 고유한 것이지만, 컨테이너 조정 솔루션을 선택하고 쿠버네티스 채택을 방해하는 주요 요인은 새로운 기술의 채택으로 나타나는 증가하는 고통의 전형이다. 기업에는 프로덕션 환경의 쿠버네티스 클러스터에 마이크로 서비스 애플리케이션을 배포하기 위한 확장 가능하고 실제 테스트를 거친 강력한 애플리케이션 네트워킹 서비스가 필요합니다.
쿠버네티스을 위한 애플리케이션 제공 문제
기존 애플리케이션에서 사용할 수 있는 로드 밸런싱/트래픽 관리, 네트워크 성능 모니터링 및 애플리케이션 보안과 같은 공통 애플리케이션 서비스는 컨테이너 기반 애플리케이션에서 다르게 구현하거나 접근해야 하는 경우가 많습니다. 다음은 컨테이너 기반 애플리케이션 구현 시 발생하는 몇 가지 과제입니다.
여러 별개의 솔루션
마이크로 서비스를 기반으로 하는 최신 애플리케이션 아키텍처는 어플라이언스 기반 로드 밸런싱 솔루션을 더 이상 사용하지 않게 만들었습니다. 기존의 하드웨어/가상 로드 밸런싱 장치 또는 오픈 소스 툴은 남북 수신 서비스를 지원하거나, 애플리케이션 자동 확장을 지원하지 않으며, DNS, IPAM 및 웹 애플리케이션 방화벽(WAF)과 같은 주변 서비스와의 기본 통합이 부족합니다.
복잡한 작업
상이한 솔루션을 통해 IT 조직은 서로 다른 공급업체의 여러 독립 구성 요소를 관리하고 문제를 해결하는 데 있어 보다 복잡한 작업에 직면하게 됩니다.
관측성 결여
컨테이너 기반 애플리케이션의 경우 종단 간 가시성이 특히 중요합니다. 애플리케이션 개발자와 운영 팀은 모두 잘못된 상호 작용, 보안 위반 및 잠재적인 지연을 식별하기 위해 주변 서비스와 컨테이너 서비스 사이의 상호작용을 볼 수 있어야 합니다.
부분 자동화
애플리케이션 및 네트워킹 서비스는 하드웨어 어플라이언스의 제약 없이 API 기반 및 프로그래밍 가능해야 합니다. 멀티벤더 솔루션은 환경 전반에서 유연성과 휴대성을 제한할 수 있습니다. 또한 멀티벤더 솔루션은 여러 제품에 대한 심층적인 스크립팅 지식이 있어야만 부분적인 자동화만 제공할 수 있으므로 기능, 자동화 및 확장 간의 타협을 가져올 수 있습니다.
따라서 애플리케이션 서비스 제공을 단순화하고 최신 애플리케이션에 대해 예상되는 클라우드 네이티브 자동화와 일치하는 단일 플랫폼에서 쿠버네티스를 위한 통합 서비스가 필요합니다.
쿠버네티스를 위한 통합 서비스 패브릭
VMware NSX Advanced Load Balancer(이전의 Avi Platform)는 온프리미엄, 멀티 클라우드, 멀티 클러스터 및 멀티 영역 환경의 가상 머신 및 베어 메탈 서버에서 VMware Tanzu, Kubernetes 또는 Red Hat OpenShift와 같은 컨테이너 오케스트레이션 플랫폼과 통합됩니다. 기존 애플리케이션과 클라우드 네이티브 애플리케이션 모두에 포괄적인 컨테이너 서비스를 제공하기 위해 NSX ALB 쿠버네티스 수신 서비스는 남북(잉글레스 컨트롤러) 트래픽 관리, GSLB(Local and Global Server Load Balancing), 성능 모니터링, 동적 서비스 검색, 웹 애플리케이션 화재와 같은 애플리케이션 보안에 최적화되어 있습니다.WAF(벽) 및 DNS/IPAM 관리. 단일 솔루션에 L4 ~ L7 로드 밸런싱, GSLB, DNS/IPAM 관리 및 보안 기능을 결합한 NSX ALB Kubernetes 수신 서비스는 Kubernetes 클러스터가 실행 중인 온프리미엄, 프라이빗 클라우드 또는 퍼블릭 클라우드 환경에 관계없이 운영 일관성을 제공합니다.
Avi Kubernetes Operator(AKO)와 쿠버네티스 클러스터 통합
NSX ALB 쿠버네티스 수신 서비스를 사용하여 여러 Kubernetes 클러스터와 통합할 수 있으며, 각 클러스터는 고유한 AKO(Avi Kubernetes Operator) 인스턴스를 실행할 수 있습니다.
AKO는 쿠베르네테스 클러스터에서 실행되는 포드로, 쿠버네티스 기본 구성과의 통신을 제공한다. AKO는 필수 Kubernetes 개체를 동기화하고 AVi Controller API를 호출하여 AVi Service Engine(SE)을 통해 수신 서비스를 배포 및 구성합니다. 클러스터는 SE에서 분리되며, VRF 컨텍스트를 사용하여 데이터 평면의 클러스터 외부에 배포됩니다. 자동화된 IPAM 및 DNS 기능은 Avi 컨트롤러에 의해 처리됩니다.
AKO는 필수 쿠버네티스 개체와 동기화 상태를 유지하고 Avi Controller API를 호출하여 Avi Service Engine을 통해 수신 서비스를 배포합니다.
클러스터에 새 수신 서비스가 생성되면 AKO가 자동으로 Avi 컨트롤러와 동기화되고, 이 컨트롤러는 가상 서비스를 생성하고, IPAM에서 VIP를 할당하고, FQDN을 DNS에 게시하고, 새로 생성된 수신 및 경로에 대한 가상 서비스를 호스팅할 Avi Service 엔진을 지정합니다. 그런 다음 AKO는 수신 개체의 상태 필드에서 이 VIP와 호스트 이름을 업데이트합니다.
Avi Multi-Cluster Kubernetes Operator(AMKO)와 Kubernetes GSLB 통합
애플리케이션을 다중 지역 및 다중 가용성 영역 배포에 걸쳐 확장하려면 Avi Kubernetes Multi-Cluster Operator(AMKO)가 필요합니다.
AMKO는 Kubernetes/OpenShift GSLB 리더 클러스터에서 실행되는 Avi Pod이며 AKO와 함께 여러 클러스터에 배포된 동일한 애플리케이션을 단일 GSLB 서비스에 매핑하여 다중 영역 및 다중 가용성 영역 배포로 애플리케이션 수신을 확장합니다.
AKO는 모든 Kubernetes 클러스터에서 Virtual Services, VIP, FQDN 및 DNS를 생성하고 관리하기 위한 수신 컨트롤러로 실행되므로 AMKO는 수신 개체의 상태 필드에서 이러한 새 VIP 및 호스트 이름을 인식합니다. AMKO는 Avi Controller APIs를 호출하여 리더 클러스터의 새로운 VIP로 새로운 GSLB 서비스를 생성하고 모든 팔로워 클러스터에서 자동으로 동기화된 GSLB 서비스와 DNS/IPAM 설정을 구성합니다.
컨테이너 기반 구현에 사용되는 여러 개별 솔루션에서 발생하는 관찰 가능성, 부분 자동화 및 복잡한 작업의 부족 문제를 극복하기 위해 NSX ALB Kubernetes 수신 서비스는 서비스를 단일 플랫폼에 통합합니다. NSX ALB 플랫폼은 조직이 안심하고 TCO를 절감하면서 애플리케이션과 서비스를 제공할 수 있도록 지원합니다.
NSX ALB 탄력적 통합 Kubernetes 수신 서비스에 대해 자세히 알아보려면 Deliver Elastic Kubernetes Ingress Controller and Services 백서를 다운로드하십시오.
