[Azure] Application Gateway for Containers

컨테이너용 Application Gateway란?

AGC (Application Gateway for Containers)는 AKS 고객이 Azure의 기본 Application Gateway 애플리케이션 부하 분산 장치를 사용할 수 있게 해주는 Kubernetes 애플리케이션인 AGIC(Application Gateway 수신 컨트롤러)가 진화한 것이다.

 

• 기존 AGIC의 원리는 Ingress YAML에 대한 변경 사항을 AGIC(Ingress Controller)가 감지하고 ARM 배포 프로세스를 통해 리소스 프로바이더로 AG 인스턴스를 업데이트하는 원리이다.
• 이러한 원리에서 문제점이 발생 할 수 있는 부분은 백엔드에 대한 설정 변경이 이루어질 때 업데이트 사항이 AG 인스턴스에 적용되기까지 15~30초 정도의 딜레이가 발생한다.
• 이 과정에서  백엔드에 대한 유효성이 일치하지 않으면 502 에러가 나올 수 있다.
• 이러한 지연 문제를 해결하기 위해 제시할 수 있는 솔루션이 AGC(Application Gateway for Containers)이다.
• AGC는 먼저 Gateway API 표준 방식을 사용하고 Gateway/HTTPRoute에 대한 변경 사항을 ALB Controller가 감지한다.
• 그리고 AGC 전용 컨트롤 플레인에서 GRPc인 고속채널 전용 프로토콜을 통해 데이터 플레인 영역에 바로 푸시함.
• 즉 데이터플레인 업데이트가 이루어질 때 지연 없는 실시간 통신이 가능하다는 것.
• AGIC와 AGC의 가장 큰 차이점은 ARM에 대한 배포 프로세스를 거치지 않는다는 점.

 

• 하지만 AGC 아키텍처를 보면 ARM에 대한 부분이 나온다.
• 이 부분은 Association, Front IP 구성, 권한 설정 등 초기 설정이 이루어질 때 ARM 프로세스를 거치는 부분이다.
• 이후 데이터 플레인에 업데이트되는 과정은 모두 직렬 통신으로 이루어진다.

 

• AGIC의 Annotation이 아닌 Gateway API 표준 방식을 사용하다 보니 훨씬 호환성 좋음
• Gateway/HTTPRoute 역할 분리를 통해 운영 효율성 좋음.
• 확장성을 위한 기능들이 기본적으로 Built-in 되어 있음.

---

배포 방식

BYOD(Bring Your Own Deployment) 방식

• Azure Portal, CLI, PowerShell, Terraform 등을 통해 관리
• 관리 대상 : AGC 리소스, 연결 리소스 및 프런트 엔드 리소스의 배포 및 수명주기
• K8S 내부 구성에서는 이미 배포된 리소스들을 참조하는 방식

 

ALB 컨트롤러에서 관리

• K8S에서 배포된 ALB 컨트롤러가 담당
• 관리 대상 : K8S 클러스터에 정의된 CRD를 기반으로, 리소스를 자동으로 생성 및 관리
• ALB 컨트롤러가 K8S CRD를 기반으로 자동 생성 및 관리

---

BYOD 기반 실습

사전 준비 사항

• AKS 클러스터 구성(워크로드 ID 활성화 및 VNET 구성)

 

• AKS 클러스터, VNET 생성, 가상화 등 이미 Azure Portal을 사용하면서 등록되어 있는 리소스프로바이더도 있지만, 특정 리소스 타입이 등록 안되어있는 경우도 있음. 
• 해당 문서의 Quickstarts를 통해 설치하는 경우 필요한 리소스 타입은 편하게 모두 등록.

 

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

• 그리고 리눅스인 경우 위 명령어를 통해 helm을 설치.

 

RESOURCE_GROUP='<your resource group name>'
AKS_NAME='<your aks cluster name>'
IDENTITY_RESOURCE_NAME='azure-alb-identity'

mcResourceGroup=$(az aks show --resource-group $RESOURCE_GROUP --name $AKS_NAME --query "nodeResourceGroup" -o tsv)
mcResourceGroupId=$(az group show --name $mcResourceGroup --query id -otsv)

echo "Creating identity $IDENTITY_RESOURCE_NAME in resource group $RESOURCE_GROUP"
az identity create --resource-group $RESOURCE_GROUP --name $IDENTITY_RESOURCE_NAME
principalId="$(az identity show -g $RESOURCE_GROUP -n $IDENTITY_RESOURCE_NAME --query principalId -otsv)"

echo "Waiting 60 seconds to allow for replication of the identity..."
sleep 60

echo "Apply Reader role to the AKS managed cluster resource group for the newly provisioned identity"
az role assignment create --assignee-object-id $principalId --assignee-principal-type ServicePrincipal --scope $mcResourceGroupId --role "acdd72a7-3385-48ef-bd42-f606fba81ae7" # Reader role

echo "Set up federation with AKS OIDC issuer"
AKS_OIDC_ISSUER="$(az aks show -n "$AKS_NAME" -g "$RESOURCE_GROUP" --query "oidcIssuerProfile.issuerUrl" -o tsv)"
az identity federated-credential create --name "azure-alb-identity" --identity-name "$IDENTITY_RESOURCE_NAME" --resource-group $RESOURCE_GROUP --issuer "$AKS_OIDC_ISSUER" --subject "system:serviceaccount:azure-alb-system:alb-controller-sa"

• 해당 AKS의 OIDC를 ALB컨트롤러가 사용할 MID와 페더레이션 하는 과정
• ALB 컨트롤러가 제어할 관리형 리소스 그룹 ID 확인
• ALB 컨트롤러가 Azure 리소스를 제어하기 위한 MID 생성
• AKS 노드 리소스 그룹에 대한 MID Reader 권한 부여
• 워크로드 ID와 MID 페더레이션

 

HELM_NAMESPACE='<namespace for deployment>'
CONTROLLER_NAMESPACE='azure-alb-system'
az aks get-credentials --resource-group $RESOURCE_GROUP --name $AKS_NAME
helm install alb-controller oci://mcr.microsoft.com/application-lb/charts/alb-controller --namespace $HELM_NAMESPACE --version 1.8.12 --set albController.namespace=$CONTROLLER_NAMESPACE --set albController.podIdentity.clientID=$(az identity show -g $RESOURCE_GROUP -n azure-alb-identity --query clientId -o tsv)

• HELM을 통해 ALB Controller을 설치해 주는 부분
• ALB Controller POD NS 지정
• ALB Controller가 사용할 MID 지정
• Azure 리소스 (API) 호출

 

kubectl get pods -n azure-alb-system

• azure-alb-system NS에 컨트롤러 POD가 설치가 되어있는지 확인

 

kubectl get gatewayclass azure-alb-external -o yaml

• GatewayClass azure-alb-external이 클러스터에 설치되어 있는지 확인.
• GatewayClass가 설정되고 이 GatewayClass를 참조하는 모든 게이트웨이 리소스가 ALB 컨트롤러에서 자동으로 관리됨을 나타냄.

 

• AGC에 대한 서브넷을 하나 만들고 Microsoft.ServiceNetworking/trafficControllers 리소스로 위임할 것이다.
• Microsoft.ServiceNetworking/trafficControllers는 AGC 서비스에서 사용되는 리소스 프로바이더 네임스페이스.
• AGC가 이 서브넷을 독점적으로 사용하도록 예약하고 AGC에 대한 데이터 플레인 프록시 인스턴스를 통해 트래픽을 제어 및 관리할 수 있는 역할

VNET_NAME='<name of the virtual network to use>'
VNET_RESOURCE_GROUP='<the resource group of your VNET>'
ALB_SUBNET_NAME='subnet-alb' # subnet name can be any non-reserved subnet name (i.e. GatewaySubnet, AzureFirewallSubnet, AzureBastionSubnet would all be invalid)

az network vnet subnet update --resource-group $VNET_RESOURCE_GROUP --name $ALB_SUBNET_NAME --vnet-name $VNET_NAME --delegations 'Microsoft.ServiceNetworking/trafficControllers'
ALB_SUBNET_ID=$(az network vnet subnet list --resource-group $VNET_RESOURCE_GROUP --vnet-name $VNET_NAME --query "[?name=='$ALB_SUBNET_NAME'].id" --output tsv)
echo $ALB_SUBNET_ID

• --delegations 'Microsoft.ServiceNetworking/trafficControllers' 이 부분이 위임하는 부분.

 

IDENTITY_RESOURCE_NAME='azure-alb-identity'

resourceGroupId=$(az group show --name $RESOURCE_GROUP --query id -otsv)
principalId=$(az identity show -g $RESOURCE_GROUP -n $IDENTITY_RESOURCE_NAME --query principalId -otsv)

# Delegate AppGw for Containers Configuration Manager role to RG containing Application Gateway for Containers resource
az role assignment create --assignee-object-id $principalId --assignee-principal-type ServicePrincipal --scope $resourceGroupId --role "fbc52c3f-28ad-4303-a892-8a056630b8f1"

# Delegate Network Contributor permission for join to association subnet
az role assignment create --assignee-object-id $principalId --assignee-principal-type ServicePrincipal --scope $ALB_SUBNET_ID --role "4d97b98b-1d4f-4787-a291-c67834d212e7"

• 그렇게 AGC 전용의 서브넷을 사용할 수 있게 ALB Controller의 MID에 네트워크 기역자 역할과, AGC의 핵심 리소스를 CRUD 할 수 있도록 허용하는 역할을 부여함.

* 위 권한 명령어 구조로 봤을 때 확실하진 않지만 기존 AGIC처럼 Gateway/HTTPRoute 에 대한 변경 사항을 컨트롤러가 감지하면 ARM API 호출이 발생됨. 대신 기존의 AGIC처럼 데이터 플레인 영역까지 한 번에 ARM을 통해 업데이트되는 것이 아니라 AGC는 이 권한을 통해 AGC 컨트롤 플레인에 변경 사항을 전달하고 컨트롤 플레인이 GRPC를 통해 데이터 플레인 프록시에 세부 구성을 푸시하는 원리임 (확실하진 않음) 

 

ASSOCIATION_NAME='association-test'
az network alb association create -g $RESOURCE_GROUP -n $ASSOCIATION_NAME --alb-name $AGFC_NAME --subnet $ALB_SUBNET_ID

• 마지막으로 ALB 컨트롤러가 위임된 서브넷에 연결(Join)하는 과정

 

• 이제 샘플 코드를 통해 사이트에 접속이 되는지 확인해 보자.
• 추가로 Gateway API 부분에 annotations를 사용했는데 이 부분은 특정 기능을 사용하기 위한 목적이 아닌 AGC의 리소스그룹 아이디와 연결해 주는 부분이다.

---

결과

---

* 참고로 AGC는 아직 Private 지원 안됨.

• gateway 자체 내에서도 azure-alb-internal 지원하지 않음.