AKS에 대한 네트워크 토폴로지 및 연결 고려 사항

  • 아티클

디자인 고려 사항

AKS(Azure Kubernetes Service)는 컨테이너 네트워킹을 위한 세 가지 네트워킹 모델인 Kubenet, CNI Overlay 및 CNI를 제공합니다. 이러한 각 모델에는 AKS의 컨테이너 네트워킹에 대한 유연성 및 확장성 옵션을 제공하는 고유한 기능 및 장점 집합이 있습니다.

Kubenet

Kubenet은 IP 주소 공간을 절약하고 간단한 구성을 제공하는 기본 네트워킹 솔루션입니다. 노드가 400개 미만인 소규모 AKS 클러스터에 이상적입니다. 여기서 사용자 정의 경로를 수동으로 관리하고 기본 수 있습니다. 내부 또는 외부 부하 분산 장치가 클러스터 외부에서 Pod에 도달하기에 충분한 시나리오에 적합합니다.

Azure CNI

Azure CNI는 고급 네트워킹용으로 설계된 네트워크 모델입니다. Pod에 대한 전체 가상 네트워크 연결을 제공하여 Pod-Pod 및 Pod-VM 연결을 허용합니다. 가상 노드와 같은 고급 AKS 기능이 필요한 시나리오에 적합합니다. 충분한 IP 주소 공간을 사용할 수 있고 외부 리소스가 Pod에 직접 도달해야 하는 시나리오에 적합합니다. AKS 네트워크 정책은 Azure CNI에서도 지원됩니다.

Azure CNI 오버레이

Azure CNI 오버레이는 IP 주소 부족을 해결하고 네트워크 구성을 간소화하도록 설계되었습니다. 노드당 최대 1,000개의 노드와 250개의 Pod를 확장하는 것으로 충분하며 Pod 연결을 위한 추가 홉이 허용되는 시나리오에 적합합니다. AKS 송신 요구 사항은 Azure CNI 오버레이에서도 충족할 수 있습니다.

네트워크 모델당 권장되는 사용 사례에 대한 요약은 AKS에서 네트워크 모델 비교를 참조 하세요.

또한 AKS 클러스터를 디자인할 때 크기 조정을 지원하도록 가상 네트워크 서브넷의 IP 주소 지정 및 크기를 신중하게 계획하는 것이 중요합니다. 가상 노드는 빠른 클러스터 스케일링에 사용할 수 있지만 몇 가지 알려진 제한 사항이 있습니다.

AKS 클러스터는 기본 및 표준 Azure Load Balancer SKU를 지원하며, 서비스는 공용 또는 내부 부하 분산 장치로 노출될 수 있습니다. AKS는 CoreDNS를 사용하여 클러스터에서 실행되는 Pod에 이름 확인을 제공하고, 아웃바운드(송신) 네트워크 트래픽은 Azure Firewall 또는 네트워크 가상 어플라이언스 클러스터를 통해 보낼 수 있습니다.

기본적으로 AKS 클러스터의 모든 pod는 트래픽을 제한 없이 송수신할 수 있습니다. 그러나 Kubernetes 네트워크 정책을 사용하여 AKS 클러스터의 Pod 간에 보안을 개선하고 네트워크 트래픽을 필터링할 수 있습니다. AKS에는 Azure 네트워크 정책 및 Calico라는 두 가지 네트워크 정책 모델을 사용할 수 있습니다.

마지막으로 AKS는 클러스터가 배포된 서브넷에 NSG(네트워크 보안 그룹)를 설정합니다. 이 NSG를 수동으로 편집하지 않는 것이 좋지만 AKS에 배포된 서비스가 영향을 줄 수 있습니다.

전반적으로 적절한 네트워크 모델을 선택하고 네트워크 리소스를 신중하게 계획하면 AKS 클러스터의 성능, 보안 및 비용을 최적화하는 데 도움이 될 수 있습니다.

프라이빗 클러스터

AKS 클러스터 IP 가시성은 퍼블릭 또는 프라이빗일 수 있습니다. 프라이빗 클러스터는 공용 IP 주소가 아닌 개인 IP 주소를 통해 Kubernetes API를 노출합니다. 이 개인 IP 주소는 프라이빗 엔드포인트를 통해 AKS 가상 네트워크에 표시됩니다. Kubernetes API는 해당 IP 주소가 아니라 FQDN(정규화된 도메인 이름)을 통해 액세스해야 합니다. Kubernetes API FQDN에서 해당 IP 주소로 확인은 일반적으로 Azure 프라이빗 DNS 영역에서 수행합니다. 이 DNS 영역은 AKS 노드 리소스 그룹에서 Azure에 의해 만들어질 수도 있고, 기존 DNS 영역을 지정할 수도 있습니다.

엔터프라이즈 규모 입증 사례에 따라 Azure 워크로드에 대한 DNS 확인은 허브 가상 네트워크에 있거나 Azure Virtual WAN에 연결된 공유 서비스 가상 네트워크에 있는 연결 구독에 배포된 중앙 집중식 DNS 서버에서 제공됩니다. 해당 서버에서는 조건에 따라 Azure DNS(IP 주소 168.63.129.16)를 사용하여 Azure 특정 및 퍼블릭 이름을 확인하고 회사 DNS 서버를 사용하여 프라이빗 이름을 확인합니다. 그러나 이러한 중앙 집중식 DNS 서버는 AKS 클러스터용으로 만든 DNS 프라이빗 영역에 연결될 때까지 AKS API FQDN을 확인할 수 없습니다. 임의 GUID가 영역 이름 앞에 추가되므로 각 AKS에는 고유한 DNS 프라이빗 영역이 있습니다. 따라서 각 새 AKS 클러스터에 대해 해당 프라이빗 DNS 영역은 중앙 DNS 서버가 있는 가상 네트워크에 연결되어야 합니다.

모든 가상 네트워크는 이름 확인을 위해 이 중앙 DNS 서버를 사용하도록 구성해야 합니다. 그러나 AKS 가상 네트워크가 중앙 DNS 서버를 사용하도록 구성되고 이 DNS 서버가 아직 프라이빗 DNS 영역에 연결되지 않은 경우 AKS 노드는 Kubernetes API의 FQDN을 확인할 수 없으며 AKS 클러스터를 만들지 못합니다. AKS 가상 네트워크는 클러스터를 만든 후에만 중앙 DNS 서버를 사용하도록 구성해야 합니다.

클러스터가 만들어진 후 DNS 프라이빗 영역과 중앙 DNS 서버가 배포되는 가상 네트워크 간에 연결이 만들어집니다. AKS 가상 네트워크도 연결 구독에서 중앙 DNS 서버를 사용하도록 구성되었으며 AKS Kubernetes API에 대한 관리자 액세스는 다음 흐름을 따릅니다.

프라이빗 클러스터에 대한 네트워크를 보여 주는 다이어그램

참고 항목

이 문서의 이미지는 기존 허브 및 스포크 연결 모델을 사용하는 디자인을 반영합니다. 엔터프라이즈 규모 랜딩 존은 중앙 DNS 서버가 Virtual WAN 허브에 연결된 공유 서비스 가상 네트워크에 있는 Virtual WAN 연결 모델을 선택할 수 있습니다.

  1. 관리자는 Kubernetes API의 FQDN을 확인합니다. 온-프레미스 DNS 서버는 신뢰할 수 있는 서버인 Azure의 DNS 확인자에 요청을 전달합니다. 이 서버는 Azure 프라이빗 DNS 영역에서 IP 주소를 가져오는 Azure DNS 서버(168.63.129.16)에 요청을 전달합니다.
  2. IP 주소를 확인한 후 Kubernetes API에 대한 트래픽은 연결 모델에 따라 온-프레미스에서 Azure의 VPN 또는 ExpressRoute 게이트웨이로 라우팅됩니다.
  3. 프라이빗 엔드포인트는 허브 가상 네트워크에 경로를 도입 /32 했습니다. VPN 및 ExpressRoute 게이트웨이는 AKS 가상 네트워크에 배포된 Kubernetes API 프라이빗 엔드포인트로 트래픽을 바로 보냅니다.

애플리케이션 사용자에서 클러스터로 트래픽

들어오는(수신) 컨트롤러를 사용하여 AKS 클러스터에서 실행되는 애플리케이션을 노출할 수 있습니다.

  • 수신 컨트롤러는 약간 복잡성이 증가하는 비용으로 애플리케이션 수준 라우팅을 제공합니다.
  • 수신 컨트롤러는 WAF(웹 애플리케이션 방화벽) 기능을 통합할 수 있습니다.
  • 수신 컨트롤러는 클러스터 내 및 클러스터에서 실행할 수 있습니다.
    • 클러스터 외부 수신 컨트롤러는 컴퓨팅(예: HTTP 트래픽 라우팅 또는 TLS 종료)을 AKS 외부의 다른 서비스(예: AGIC(Azure Application Gateway 수신 컨트롤러) 추가 기능)로 오프로드합니다.
    • 클러스터 내부 솔루션은 컴퓨팅(예: HTTP 트래픽 라우팅 또는 TLS 종료)에 AKS 클러스터 리소스를 사용합니다. 클러스터 내부 수신 컨트롤러는 더 낮은 비용을 제공할 수 있지만 주의 깊은 리소스 계획 및 유지 관리가 필요합니다.
  • 기본 HTTP 애플리케이션 라우팅 추가 기능은 사용하기 쉽지만 HTTP 애플리케이션 라우팅에 설명된 대로 몇 가지 제한 사항이 있습니다.

수신 컨트롤러는 공용 또는 개인 IP 주소를 사용하여 애플리케이션과 API를 노출할 수 있습니다.

  • 비대칭 라우팅을 방지하려면 구성이 송신 필터링 디자인에 맞춰 조정되어야 합니다. UDR은 비대칭 라우팅(잠재적으로)을 유발할 수 있지만 반드시 그런 것은 아닙니다. Application Gateway는 트래픽에서 SNAT할 수 있습니다. 즉, UDR이 인터넷 트래픽에 대해서만 설정된 경우 반환 트래픽이 Application Gateway 노드로 돌아가고 UDR 경로로 돌아가지 않습니다.
  • TLS 종료가 필요한 경우 TLS 인증서 관리를 고려해야 합니다.

애플리케이션 트래픽은 온-프레미스 또는 퍼블릭 인터넷에서 생성될 수 있습니다. 다음 그림에서는 Azure Application Gateway가 온-프레미스 및 퍼블릭 인터넷 모두에서 클러스터에 대한 연결을 역방향 프록시하도록 구성된 예제를 설명합니다.

애플리케이션 관련 네트워크 트래픽을 보여 주는 다이어그램

온-프레미스의 트래픽은 이전 다이어그램에서 번호가 매겨진 파란색 설명선의 흐름을 따릅니다.

  1. 클라이언트는 연결 구독 또는 온-프레미스 DNS 서버에 배포된 DNS 서버를 사용하여 애플리케이션에 할당된 FQDN을 확인합니다.
  2. 애플리케이션 FQDN을 IP 주소(애플리케이션 게이트웨이의 개인 IP 주소)로 확인한 후 트래픽은 VPN 또는 ExpressRoute 게이트웨이를 통해 라우팅됩니다.
  3. 게이트웨이 서브넷의 라우팅은 웹 애플리케이션 방화벽에 요청을 보내도록 구성됩니다.
  4. 웹 애플리케이션 방화벽은 AKS 클러스터에서 실행되는 워크로드에 유효한 요청을 보냅니다.

이 예제의 Azure Application Gateway는 AKS 클러스터와 동일한 구독에 배포할 수 있습니다. 이는 해당 구성이 AKS에 배포된 워크로드와 밀접한 관련이 있으므로 동일한 애플리케이션 팀에서 관리되기 때문입니다. 인터넷에서 액세스는 이전 다이어그램에서 번호가 매겨진 녹색 설명선의 흐름을 따릅니다.

  1. 퍼블릭 인터넷의 클라이언트는 Azure Traffic Manager를 사용하여 애플리케이션의 DNS 이름을 확인합니다. 또는 Azure Front Door와 같은 다른 글로벌 부하 분산 기술을 사용할 수 있습니다.
  2. 애플리케이션 퍼블릭 FQDN은 Traffic Manager에 의해 클라이언트가 퍼블릭 인터넷을 통해 액세스하는 애플리케이션 게이트웨이의 공용 IP 주소로 확인됩니다.
  3. 애플리케이션 게이트웨이는 AKS에 배포된 워크로드에 액세스합니다.

참고 항목

이 흐름은 웹 애플리케이션에만 유효합니다. 웹 애플리케이션이 아닌 경우 이 문서의 범위를 벗어나며 허브 가상 네트워크의 Azure Firewall를 통해 또는 Virtual WAN 연결 모델을 사용하는 경우 보안 가상 허브를 통해 노출될 수 있습니다.

또는 웹 기반 애플리케이션에 대한 트래픽 흐름을 만들어 연결 구독의 Azure Firewall 및 AKS 가상 네트워크의 WAF를 모두 트래버스할 수 있습니다. 이 접근 방식은 Azure Firewall 인텔리전스 기반 필터링을 사용하여 인터넷에서 알려진 악성 IP 주소의 트래픽을 삭제하는 등 좀 더 많은 보호를 제공하는 이점이 있습니다. 그러나 몇 가지 단점도 있다. 예를 들어, 원래 클라이언트 IP 주소가 손실되고 애플리케이션을 노출할 때 방화벽과 애플리케이션 팀 간에 추가 조정이 필요합니다. 이는 Azure Firewall에서 DNAT(Destination Network Address Translation) 규칙이 필요하기 때문입니다.

AKS Pod에서 백 엔드 서비스로 트래픽

AKS 클러스터 내에서 실행되는 Pod는 Azure Storage, Azure SQL 데이터베이스 또는 Azure Cosmos DB NoSQL 데이터베이스와 같은 백 엔드 서비스에 액세스해야 할 수 있습니다. 가상 네트워크 서비스 엔드포인트 및 Private Link를 사용하여 이 Azure 관리되는 서비스에 대한 연결을 보호할 수 있습니다.

백 엔드 트래픽에 Azure 프라이빗 엔드포인트를 사용하는 경우 Azure 프라이빗 DNS 영역을 사용하여 Azure 서비스에 대한 DNS 확인을 수행할 수 있습니다. 전체 환경의 DNS 확인자는 허브 가상 네트워크(또는 Virtual WAN 연결 모델을 사용하는 경우 공유 서비스 가상 네트워크)에 있으므로 이 프라이빗 영역을 연결 구독에 만들어야 합니다. 프라이빗 서비스의 FQDN을 확인하는 데 필요한 A 레코드를 만들기 위해 프라이빗 DNS 영역(연결 구독)을 프라이빗 엔드포인트(애플리케이션 구독)와 연결할 수 있습니다. 이 작업을 수행하려면 해당 구독에서 특정 권한이 필요합니다.

A 레코드를 수동으로 만들 수 있지만 프라이빗 DNS 영역을 프라이빗 엔드포인트와 연결하면 설정이 잘못 구성될 가능성이 적습니다.

프라이빗 엔드포인트를 통해 노출되는 AKS Pod에서 Azure PaaS 서비스로의 백 엔드 연결은 다음 시퀀스를 따릅니다.

백 엔드 트래픽

  1. AKS Pod는 AKS 가상 네트워크에서 사용자 지정 DNS 서버로 정의된 연결 구독의 중앙 DNS 서버를 사용하여 Azure PaaS(Platform as a Service)의 FQDN을 확인합니다.
  2. 확인된 IP는 AKS Pod에서 직접 액세스되는 프라이빗 엔드포인트의 개인 IP 주소입니다.

AKS 클러스터가 Azure Firewall을 사용하여 송신 필터링하도록 구성된 경우에도 AKS Pod와 기본값당 프라이빗 엔드포인트 간의 트래픽은 허브 가상 네트워크의 Azure Firewall(또는 Virtual WAN을 사용하는 경우 보안 가상 허브)을 통과하지 않습니다. 그 이유는 프라이빗 엔드포인트가 AKS가 배포되는 애플리케이션 가상 네트워크의 서브넷에 경로를 만들기 /32 때문입니다.

디자인 권장 사항

  • 보안 정책에서 공용 IP 주소 대신 개인 IP 주소를 사용하는 Kubernetes API를 포함하도록 요구하는 경우 프라이빗 AKS 클러스터를 배포합니다.
    • 만들기 프로세스에서 시스템 프라이빗 DNS 영역을 사용하도록 하는 대신 프라이빗 클러스터를 만들 때 사용자 지정 프라이빗 DNS 영역을 사용합니다.
  • AKS 클러스터에 할당할 수 있는 IP 주소 범위가 제한되지 않는 한 Azure CNI(Container Networking Interface)를 네트워크 모델로 사용합니다.
    • CNI를 사용한 IP 주소 계획에 관한 설명서를 따릅니다.
    • Windows 서버 노드 풀 및 가상 노드를 사용하여 최종 제한 사항을 확인하려면 Windows AKS 지원 FAQ를 참조하세요.
  • 중앙 집중식 구독에서 Azure Firewall 또는 WAF를 사용하지 않는 한 Azure DDoS Protection을 사용하여 AKS 클러스터에 사용되는 가상 네트워크를 보호합니다.
  • Azure Virtual WAN 또는 허브 및 스포크 아키텍처, Azure DNS 영역, 자체 DNS 인프라 등에서 전체 네트워크 설정에 연결된 DNS 구성을 사용합니다.
  • Private Link를 사용하여 네트워크 연결을 보호하고 Azure Storage, Azure Container Registry, Azure SQL Database, Azure Key Vault 등 Private Link를 지원하는 다른 관리형 Azure 서비스에 대한 개인 IP 기반 연결을 사용합니다.
  • 수신 컨트롤러를 사용하여 고급 HTTP 라우팅 및 보안을 제공하고 애플리케이션의 단일 엔드포인트를 제공합니다.
  • 수신을 사용하도록 구성된 모든 웹 애플리케이션은 TLS 암호화를 사용하며 암호화되지 않은 HTTP에 대한 액세스를 허용하지 않아야 합니다. 정책에 엔터프라이즈 규모 랜딩 존의 참조 구현이 포함됨의 권장 정책이 구독에 포함된 경우 이 정책이 이미 적용된 것입니다.
  • 필요에 따라 AKS 클러스터의 컴퓨팅 및 스토리지 리소스를 절약하려면 클러스터 외부 수신 컨트롤러를 사용합니다.
    • Microsoft 관리형 Azure 서비스인 AGIC(Azure Application Gateway 수신 컨트롤러) 추가 기능을 사용합니다.
    • AGIC를 사용하여 각 AKS 클러스터에 대한 전용 Azure 애플리케이션 게이트웨이를 배포하고 여러 AKS 클러스터에서 동일한 Application Gateway를 공유하지 않습니다.
    • 리소스 또는 운영 제약 조건이 없거나 AGIC에서 필요한 기능을 제공하지 않는 경우 NGINX, Traefik 또는 기타 Kubernetes 지원 솔루션과 같은 클러스터 내 수신 컨트롤러 솔루션을 사용합니다.
  • 인터넷 연결 및 보안에 중요한 내부 연결 웹 애플리케이션의 경우 수신 컨트롤러와 함께 웹 애플리케이션 방화벽을 사용합니다.
    • Azure Application Gateway와 Azure Front Door는 모두 Azure Web Application Firewall을 통합하여 웹 기반 애플리케이션을 보호합니다.
  • 보안 정책에서 AKS 클러스터에 생성된 모든 아웃바운드 인터넷 트래픽을 검사하도록 해야 하는 경우 Azure Firewall 또는 관리형 허브 가상 네트워크에 배포된 타사 NVA(네트워크 가상 어플라이언스)를 사용하여 송신 네트워크 트래픽을 보호합니다. 자세한 내용은 송신 트래픽 제한을 참조하세요. AKS 아웃바운드 형식 UDR 을 사용하려면 경로 테이블을 AKS 노드 서브넷에 연결해야 하므로 현재 Azure Virtual WAN 또는 Azure Route Server에서 지원하는 동적 경로 삽입과 함께 사용할 수 없습니다.
  • 프라이빗이 아닌 클러스터의 경우 권한 있는 IP 범위를 사용합니다.
  • Azure Load Balancer의 기본 계층이 아닌 표준 계층을 사용합니다.
  • Azure에서 Kubernetes 클러스터를 디자인할 때 주요 고려 사항 중 하나는 특정 요구 사항에 적합한 네트워크 모델을 선택하는 것입니다. AKS(Azure Kubernetes Service)는 Kubenet, Azure CNI 및 Azure CNI 오버레이의 세 가지 네트워킹 모델을 제공합니다. 정보에 입각한 결정을 내리려면 각 모델의 기능과 특성을 이해해야 합니다.

AKS의 세 네트워크 모델 간의 기능 비교 Kubenet, Azure CNI 및 Azure CNI 오버레이는 AKS의 네트워크 모델 비교를 참조 하세요.