Azure Kubernetes Service(AKS)를 위한 Application Gateway Ingress Controller - 1편

<출처> https://azure.microsoft.com/ko-kr/blog/application-gateway-ingress-controller-for-azure-kubernetes-service/

 

 

 

 

 

2019년 12월 초 Microsoft Azure 블로그에 게시된 "Application Gateway Ingress Controller for Azure Kubernetes Service" 라는 글에 유용한 정보가 있어 멤버분들에게 공유하고자 번역해 봤습니다. 더불어 Microsoft Azure의 공식 문서 "Application Gateway Ingress Controller란?" 도 함께 번역하여 게시하였으니 관심 있으신분들은 함께 살펴보고 구성까지 해보시면 좋을 것 같습니다.   다음 2편에서 실제 구성하고 실습한 결과를 게시하도록 하겠습니다.

 

 

 

 

 

오늘 AKS (Azure Kubernetes Service)와 Application Gateway를 바인딩하는 새로운 솔루션을 제공하게 되어 기쁘게 생각한다. 이 새로운 솔루션은 Kubernetes에 오픈소스 AGIC (Application Gateway Ingress Controller)를 제공하여 AKS 고객이 Application Gateway를 활용하여 클라우드 소프트웨어를 인터넷에 노출시킬 수 있도록 해준다.

관리 Kubernetes 서비스인 Azure Kubernetes Service의 이점을 통합하여 고급 Kubernetes 환경을 쉽게 운영할 수 있으며, 기본적(native)이고 확장 가능하며 가용성이 높은 L7 로드밸런서인 Azure Application Gateway는 고객으로부터 많은 요청을 받았다.

 

 

 

 

 

어떻게 작동하나?

Application Gateway Ingress Controller는 고객의 AKS에서 자체 파드로 실행된다.  Ingress Controller는 Kubernetes 리소스의 하위 집합을 모니터링하여 변경사항을 확인한다. AKS 클러스터의 상태는 Application Gateway 특유(specific)의 구성으로 변환되어 Azure Resource Manager에 적용된다. Application Gateway를 지속적으로 재구성하면 AKS 서비스로의 트래픽 흐름이 중단되지 않는다. 아래 다이어그램은 Kubernetes API에서 Application Gateway Ingress Controller를 통해 Resource Manager 및 Application Gateway 로의 상태 및 구성 변경 흐름을 보여준다.

 

 

가장 인기있는 Kubernetes Ingress 컨트롤러와 마찬가지로 Application Gateway Ingress Controller는 Azure의 기본 Application Gateway L7 로드밸런서를 활용하여 여러가지 기능을 제공하다. 몇 가지 예를 들면 다음과 같다.

• URL 라우팅
• 쿠키 기반 선호도(Cookie-based affinity)
• SSL (Secure Sockets Layer) 종료
• 엔드 투 엔드 SSL
• 공개, 개인 및 하이브리드 웹 사이트 지원
• 통합 웹 애플리케이션 방화벽

 

Application Gateway Ingress Controller의 아키텍처는 기존의 클러스터 내 L7 로드밸런서와 다르다. 이 다이어그램에는 구조적 차이점이 나와 있다.

 

• 클러스터 내 로드밸런서는 Kubernetes 클러스터의 컴퓨팅 리소스를 활용하여 모든 데이터 경로 작업을 수행한다. 비즈니스 애플리케이션과 리소스를 놓고 경쟁을 한다. 클러스터 내 인그레스 컨트롤러는 Kubernetes 서비스 리소스를 생성하고 네트워크 트래픽에 kubenet을 활용한다. Ingress Controller와 비교하여 트래픽은 추가 홉(hop) 통해 흐른다.
• Ingress Controller는 AKS의 고급 네트워킹을 활용하여 Application Gateway와 공유되는 서브넷에서 각 파드에 대한 IP 주소를 할당한다. Application Gateway는 모든 Kubernetes 파드에 직접 액세스 할 수 있다. 따라서 kubenet을 통해 데이터를 전달할 필요가 없다. 이 항목에 대한 자세한 내용은 “Azure Kubernetes Service의 응용 프로그램에 대한 네트워크 개념” 글, 특히 “네트워크 모델 비교” 섹션을 참조한다.

 

 

 

 

 

솔루션 성능

Application Gateway가 Kubernetes 파드에 직접 연결되어 있기 때문에 Application Gateway 수신 컨트롤러는 클러스터 내 인그레스 컨트롤러에 비해 네트워크 대기 시간을 최대 50 % 낮출 수 있다. Application Gateway는 Azure 가상 컴퓨터 스케일 집합(VMSS)이 지원하는 관리 서비스다. 결과적으로 Application Gateway는 데이터 경로 처리에 AKS 컴퓨팅 자원을 사용하지 않는다. Kubernetes 디플로이먼트에 할당된 리소스를 공유하거나 방해하지 않는다. 클러스터 내 인그레스와 달리 사용량이 많은 시간에 Auto Scaling Application Gateway는 앱 파드를 신속하게 확장하는 기능을 방해하지 않는다. 물론 클러스터 내 L7 인그레스에서 Application Gateway로 전환하면 AKS에서 사용하는 컴퓨팅 부하가 즉시 줄어 든다.

노드 당 22 개의 파드를 실행하는 간단한 웹앱으로 3개 노드의 AKS 클러스터에서 클러스터 내 인그레스 컨트롤러 및 Application Gateway Ingress 컨트롤러의 성능을 비교해봤다. 총 66 개의 웹앱 파드는 3개의 클러스터 내 인그레스 (노드 당 1 개)로 리소스를 공유한다. 인스턴스 2개로 Application Gateway를 구성했다. Apache Bench를 사용하여 동시성(concurrency) 3K 요청으로 총 100K 요청을 작성했다. Apache Bench를 두 번 돌렸다. 한 번은 클러스터 내 인그레스 컨트롤러 앞에 SLB를 가리키도록 하고 두 번째로는 Application Gateway의 퍼블릭 IP에 연결했다. 매우 busy한 AKS 클러스터 상황에서 모든 요청의 평균 대기 시간을 기록했다.

 

• 애플리케이션 게이트웨이 : 요청 당 480ms
• 클러스터 내 인그레스 : 요청 당 710ms

위에서 수집한 데이터에서 알 수 있 듯이 로드가 많은 경우 클러스터 내 인그레스 컨트롤러는 Application Gateway 수신에 비해 요청 당 약 48 % 높은 대기 시간을 갖는다. 동일한 클러스터에서 동일한 벤치 마크를 실행했지만 노드 당 두 개의 웹앱 파드 (총 6 개의 파드)를 사용하는 클러스터 내 인그레스 컨트롤러는 Application Gateway보다 대기 시간이 약 17 % 더 높은 것으로 나타났다.

 

 

 

 

 

 

다음은?

Application Gateway Ingress Controller는 이제 안정적이며 프로덕션 환경에서 사용할 수 있다. 이 프로젝트는 빠르게 발전하고 있으며 새로운 기능을 추가하기 위해 적극적으로 노력하고 있다. Application Gateway에 저장된 인증서 사용, 상호 TLS 인증, gRPC 및 HTTP/2와 같이 고객이 요청한 기능으로 제품을 향상시키기 위해 노력하고 있다. AKS 용 새 Application Gateway Ingress Controller를 사용해보고 진행 상황을 확인하고 GitHub에 대한 의견을 보내 주시기 바란다.