Exposing AKS Apps Using Front Door And Private Link Service

1. 목적 

Azure Kubernetes Service(AKS) 의 Pod Application은 Load Balancer, Ingress Controller, API Management, Application Gateway, Front Door와 같이 여러가지 서비스에 의해 외부에 노출 될 수 있습니다.

여기서는 Azure Front Door(AFD)를 사용하여  AKS Application을 노출하여 통신이 되도록 해보겠습니다. 

AFD는 Private Link Service(PLS)를 사용하여 AKS Application을 노출합니다. 

 

목적을 달성하기 위해 사전 아래 내용과 같이 환경 구성이 필요합니다.

1) kubernetes Service Annotation을 이용해 Ingress Controller 또는  AKS로 접근하기 위한 Internal Loadbalancer를 생성합니다.

2) Annotation을 이용해서 PLS 생성을  활성화합니다. 

3) AFD에서 PLS 사용을 활성화하고 연결할 Private Endpoint를 생성할 수 있도록 합니다. 

4) PLS와 Private endpoint간의 연결을 승인합니다. 

 

 

2. 아키텍처

3. Demo 실습 진행 

1) AKS 배포 

AKS를 배포할 가상 네트워크를 먼저 생성하고 AKS 전용 서브넷을 생성합니다. 

해당 서브넷에 AKS를 배포할 수 있도록 하고 AKS 네트워크 구성은 Azure CNI Overlay로 진행합니다. 

 

2) AKS 접속 및 Service & Application 배포 

 

1.Service & application 배포
webapp namespace에 deployment로 webapp application을 배포하면서 내부 통신이 가능하도록 clusterIP 타입으로 service를 동시에 생성합니다. 

apiVersion: v1
kind: Namespace
metadata:
  name: webapp
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
  namespace: webapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: webapp
        image: jelledruyts/inspectorgadget
---
apiVersion: v1
kind: Service
metadata:
  name: webapp
  namespace: webapp
spec:
  type: ClusterIP
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: webapp

 

2. Azure에 Internal LB와 Private Link service 배포 

apiVersion: v1
kind: Service
metadata:
  name: webapp-internal-service-pls
  namespace: webapp
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true" # Right now PLS must be used with internal LB
    service.beta.kubernetes.io/azure-load-balancer-ipv4: 10.0.1.25 # aks 배포 가상네트워크에 포함되어야함
    service.beta.kubernetes.io/azure-pls-create: "true"
    service.beta.kubernetes.io/azure-pls-name: "pls-aks-service"
    service.beta.kubernetes.io/azure-pls-ip-configuration-subnet: "aks-snet" # AKS subnet에 배포
    service.beta.kubernetes.io/azure-pls-ip-configuration-ip-address-count: "1"
    service.beta.kubernetes.io/azure-pls-proxy-protocol: "false"
    service.beta.kubernetes.io/azure-pls-visibility: "*"
    service.beta.kubernetes.io/azure-pls-auto-approval: "subscription_ID"
spec:
  type: LoadBalancer
  selector:
    app: webapp
  ports:
  - port: 80
    targetPort: 80

 

Private Link Service 생성이 완료되어 배포 된 것을 확인할 수 있습니다. 

 

하지만 아래 이미지와 같이 PLS에 연결된 Private endpoint는 아직 생성되지 않아서 연결된 Private endpoint는 없습니다. 

여기서 Private endpoint는 Azure Front Door의 원본 설정 시 PLS 사용을 활성화하여 Private endpoint와 연결을 진행하도록 하겠습니다. AFD에서 PLS를 활성화하면 PLS의 Private endpoint 탭에 랜덤 문자열로 Private endpoint가 생성되게 되고 승인 절차를 거쳐서 PLS와 Private endpoint가 연결되게 됩니다. 해당 과정은 이후 진행하도록 하겠습니다.

 

Internal LB (kubernetes-internal)에 PLS(10.0.1.25)가 연결되어 있음을 확인할 수 있습니다. 

 

 

※ Private Link Service 와 Private endpoint 차이점

1. Private Link Service 

정의 : 고객(소비자) 자신의 서비스를 Azure Private Link를 통해 다른 사용자나 서비스에 제공할 수 있게 해주는 서비스입니다.

용도 : 자신의 서비스를 Azure  네트워크 외부로 안전하게 노출시키고자 할때 사용합니다. 

특징 : 내부 로드밸런서 뒤에 있는 서비스를 안전하게 노출시키며, 특정 구독에 대한 자동 승인 기능을 제공합니다. 

 

2. Private endpoint 

정의 : Azure 서비스나 private link service에 비공개로 연결하기 위한 네트워크 인터페이스 입니다. 

용도 : Private Link Service나 Azure PaaS에 안전하게 연결하기 위해 사용합니다.

특징 : 가상네트워크 내에 생성되며, 사설 IP주소를 사용하여 해당 서비스를 연결합니다. 

 

Azure PaaS(Storage 또는 SQL 등)를 구성해서 private endpoint를 연결하다보면 Private Link Service를 배포 안하고 단독으로 배포가 가능한 것을 알 수 있을 겁니다. PaaS에 연결하기 위한 Private endpoint를 단독으로 생성이 가능한 이유는 PaaS의 경우 Azure 자체적으로 Private Link Service를 생성 및 관리하기 때문에 Private Link Service 생성 없이 Private endpoint만 생성이 가능한 것입니다.

 

그렇다면, 여기서 또 의문이 생길 수 있습니다. 

AKS는 PaaS가 아닌거야?

AKS의 경우 PaaS와 IaaS의 성질을 모두 가지고 있는 서비스라고 생각하시면 좋을 것 같습니다.

AKS의 경우 VMSS 기반으로 배포되는 서비스이므로 일반적인 PaaS 서비스와 다른 점이 있습니다. 

우선적으로 알고있어야하는 부분은 AKS는 컨트롤 플레인(Azure 관리)과 데이터 플레인(사용자 관리)이 분리되어 있는 구조를 알고있어야합니다. 

 

우선, AKS와 Private Link와의 관계에 대해서 살펴보도록 하겠습니다. 

1. AKS API 서버에 대한 연결

AKS API(컨트롤 플레인)에 접근하기 위해서는 Private endpoint를 사용할 수 있습니다.

AKS API의 경우 일반적인 PaaS와 동일하게 Azure에서 관리하는 Private Link Service를 통해 연결되기 때문입니다. 

이와 같이 AKS API서버에 접근하여 Application을 관리하게 되면 소위 말하는 'Private AKS', 'Private Cluster' 구성이 되는 것입니다. 그래서 AKS를 생성할때 Private Cluster로 생성하면 Private DNS가 생성되고 해당 Private DNS 레코드에 Private IP가 생성되게 됩니다. Private IP는 AKS API에 연결된 Private endpoint IP입니다. 

 

2. AKS에서 실행되는 Application에 대한 연결 

AKS 클러스터 내의 사용자 Application에 대한 연결은 다른 방식으로 이뤄집니다. 

이 경우 사용자가 직접 Private Link Service를 생성하고 Private endpoint를 연결시켜 승인하여야합니다.

다만, 이렇게 구성하는 경우 사용자 Application이 많으면 endpoint가 많아지므로, 대부분의 경우 Private AKS를 구성하고 앞단 방화벽,WAF를 통해 AKS 내부 사용자 Application에 접근하지 못하도록 구성을 진행합니다. 

 

결론적으로 요약하자면 다음과 같습니다.

1. AKS API 서버(컨트롤 플레인) : 일반 PaaS와 유사하게 Private endpoint로 직접 연결 가능

2. AKS 내 Application (데이터 플레인) : Private Link Service를 먼저 구성하고, 그 후 Private endpoint를 연결해야 함.

 

그럼 이번 실습에서 생성하는 Azure Front Door Managed Private endpoint는 뭘까요?

정의 : Azure Front Door Managed Private endpoint는 Azure Front Door Premium에서 관리하는 특수 유형의 Private endpoint입니다.

용도 : Front Door와 Private Link Service나 Azure PaaS에 안전하게 연결하기 위해 사용됩니다. 

특징 : Azure Front Door가 소유하고 관리하는 가상 네트워크에 생성됩니다. portal에서는 확인이 불가능합니다.

         사용자가 직접 관리할 필요 없고 Premium에서만 사용이 가능합니다. 

 

그럼 실습을 계속해서 이어나가도록 하겠습니다. 

 

3) Azure Front Door 생성 

Azure Front Door의 경우 Hub에서 관리하는 경우가 많으므로 Hub Vnet을 생성 후 배포하도록 하겠습니다. 

그리고 AKS가 배포되어있는 Spoke Vnet과 Peering을 진행하여 네트워크 연결을 해주면 됩니다. 

 

아래 이미지와 같이 Hub 가상네트워크를 생성하고 Spoke와 Peering을 진행합니다. 

 

Hub에 AFD 배포를 진행합니다. 

아래 이미지와 같이 원본에 연결할 endpoint 이름을 지정하고 원본 형식을 '사용자 지정'으로 설정합니다.

원본 호스트 이름을 앞서 생성했던 Internal-LB (kubernetes-internal) 10.0.1.25로 지정하고 AFD를 생성합니다. 

Private Link Service의 경우 다음 step에서 진행하도록 하겠습니다.

 

생성 진행 후 AFD 엔드포인트에 접근하면 페이지를 찾을 수 없을 것 입니다. 

왜냐하면, AFD 뒷단의 트래픽을 Internal LB로 전환하여 Private Link service로 연결을 시켜주지 않았기 때문입니다. 

 

AFD >> 원본 그룹 >> 원본 호스트 이름 으로 들어가서 PLS 서비스 사용을 활성화 시켜줍니다. 

앞서 yml파일을 통해 Internal LB(kubernetes-internal)을 생성하면서 PLS를 생성했었습니다.

pls-aks-service를 선택합니다. 이후 적용시키고 원본 업데이트를 진행합니다.

 

PLS >> Private endpoint connection 으로 이동 후 Private endpoint를 승인해줍니다. 

 

현재 구성은 HTTPS 인증을 받지 않은 상태이므로 AFD의 원본 그룹 설정이 추가적으로 되어야합니다. 

아래 이미지와 같이 HTTPS를 사용하지 않고 HTTP를 사용하여 AKS 내부로 접근할 수 있도록 구성을 진행합니다. 

AFD >> Front Door 관리자 >> 리디렉션, 전달 프로토콜 업데이트를 진행합니다.

만약, HTTPS인증을 받은 도메인을 사용하고 싶다면 , HTTPS 인증이 된 사용자 지정 도메인을 추가해야합니다. 

 

AFD의 원본에 대한 경로를 업데이트한 후 HTTP로 AFD 엔드포인트로 접근해봅니다. 

아래 이미지와 같이 AFD >> PLS >> Internal LB >> AKS로 접근하여 Webapp Pod가 접속되는것을 볼 수 있습니다. 

 

4) Ingress Controller 

다음 명령어를 이용해서 AKS의 Application Routing Add-on을 활성화 합니다. 

활성화 하게 되면 AKS Application에 대한 Routing이 활성화 되면서 일반적인 community-managed Nginx Ingress Controller가 아닌 Microsoft의 Application Routing Add-on의 일부로 설치된 Nginx Ingress Controller가 생성됩니다. 

az aks approuting enable --name terzmy-aks-cluster --resource-group terzmy-rg

 

default NginxIngressController 외에 해당 데모에서 사용하기 위한 NginxIngressController를 생성합니다. 

apiVersion: approuting.kubernetes.azure.com/v1alpha1
kind: NginxIngressController
metadata:
  name: nginx-internal-static-pls
spec:
  ingressClassName: nginx-internal-static-pls
  controllerNamePrefix: nginx-internal-static-pls
  loadBalancerAnnotations: 
    service.beta.kubernetes.io/azure-load-balancer-internal: "true" # Right now PLS must be used with internal LB
    service.beta.kubernetes.io/azure-load-balancer-ipv4: 10.0.1.30
    service.beta.kubernetes.io/azure-pls-create: "true"
    service.beta.kubernetes.io/azure-pls-name: "pls-aks-ingress"
    service.beta.kubernetes.io/azure-pls-ip-configuration-subnet: "aks-snet" # Private Link subnet name
    service.beta.kubernetes.io/azure-pls-ip-configuration-ip-address-count: "1"
    service.beta.kubernetes.io/azure-pls-proxy-protocol: "false"
    service.beta.kubernetes.io/azure-pls-visibility: "*"
    service.beta.kubernetes.io/azure-pls-auto-approval: "c53bdcf6-8fac-491b-8692-9195df094803"

 

Ingress Controller용 PLS가 정상적으로 생성되었음을 확인할 수 있습니다.

Private endpoint는 생성하여 승인절차를 거치지 않았기 때문에 해당 PLS에는 어느 Private endpoint도 연결되어있지 않습니다. 

해당 과정은 AFD >> FrontDoor 관리자로 이동하여 원본에 접근하기위한 엔드포인트를 생성해야합니다. 

 

AFD >> FrontDoor 관리자 >> 엔드포인트 추가를 진행하고 경로를 설정합니다. 

 

엔드포인트에 대한 경로를 추가합니다.

경로를 추가하면서 동시에 원본 그룹 및 원본에 대한 정보도 추가합니다.

여기서 원본은 앞서 배포했던 Internal-LB인 Ingress Controller IP (10.0.1.30) 입니다.

 

원본 그룹을 추가한 후 경로를 추가해줍니다. 

여기서 앞 실습과 마찬가지로 HTTP로 통신이 가능하도록 설정합니다. 

 

이제 Ingress Controller 생성 및 AFD >> Ingress Controller로 네트워크 연결을 완료하였습니다. 

AKS에서 Ingress를 통해 논리적 경로 생성 후 AKS Pod로 통신이 되도록 구성을 진행하도록 하겠습니다.

Ingress 생성은 아래 yml파일을 참고하면 됩니다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: webapp-internal-ingress-pls
  namespace: webapp
spec:
  ingressClassName: nginx-internal-static-pls
  rules:
  - http:
      paths:
      - backend:
          service:
            name: webapp
            port:
              number: 80
        path: /
        pathType: Prefix

Ingress가 정상적으로 생성된 것을 확인 할 수 있습니다. 

 

Ingress 생성이 완료되었으면 PLS에 Private endpoint 승인을 진행합니다. 

 

마지막으로 AFD >> Ingress Controller >> Ingress >> AKS 순서로 http를통해서 Pod에 접근이 가능한지 확인합니다.