AKS(Azure Kubernetes Service)의 애플리케이션에 대한 네트워킹 개념

애플리케이션 개발에 대한 컨테이너 기반 마이크로 서비스 접근 방식에서 애플리케이션 구성 요소는 함께 작동하여 해당 작업을 처리합니다. Kubernetes는 이 공동 작업을 사용 설정하는 다양한 리소스를 제공합니다.

  • 애플리케이션을 내부 또는 외부에 연결하고 공개할 수 있습니다.
  • 애플리케이션의 부하를 분산시켜 고가용성 애플리케이션을 빌드할 수 있습니다.
  • Pod 및 노드에 대한 또는 서로 간에 네트워크 트래픽의 흐름을 제한하여 보안을 강화할 수 있습니다.
  • 더 복잡한 애플리케이션의 경우 여러 구성 요소의 SSL/TLS 종료 또는 라우팅에 대한 수신 트래픽을 구성할 수 있습니다.

이 문서에서는 AKS에서 네트워킹을 애플리케이션에 제공하는 핵심 개념을 소개합니다.

Kubernetes 네트워킹 기본 사항

Kubernetes는 가상 네트워킹 계층을 사용하여 애플리케이션 또는 해당 구성 요소 간 액세스를 관리합니다.

  • Kubernetes 노드 및 가상 네트워크: Kubernetes 노드는 가상 네트워크에 연결됩니다. 이 설정을 통해 Pod(Kubernetes의 기본 배포 단위)에 인바운드 및 아웃바운드 연결이 모두 있을 수 있습니다.

  • Kube-proxy 구성 요소: kube-proxy는 각 노드에서 실행되며 필요한 네트워크 기능을 제공합니다.

특정 Kubernetes 기능 관련:

  • 서비스: 서비스는 Pod를 논리적으로 그룹화하여 지정된 포트의 특정 IP 주소 또는 DNS 이름을 통해 직접 액세스할 수 있도록 하는 데 사용됩니다.
  • 서비스 유형: 만들려는 서비스의 종류를 지정합니다.
  • 부하 분산 장치: 부하 분산 장치를 사용하여 네트워크 트래픽을 다양한 리소스에 균등하게 분산할 수 있습니다.
  • 수신 컨트롤러: 이는 애플리케이션 트래픽을 전달하는 데 필수적인 계층 7 라우팅을 용이하게 합니다.
  • 송신 트래픽 제어: Kubernetes를 사용하면 클러스터 노드에서 아웃바운드 트래픽을 관리하고 제어할 수 있습니다.
  • 네트워크 정책: 이 정책은 Pod의 네트워크 트래픽에 대한 보안 측정값 및 필터링을 사용하도록 설정합니다.

Azure 플랫폼의 컨텍스트에서:

  • Azure는 AKS(Azure Kubernetes Service) 클러스터에 대한 가상 네트워킹을 간소화합니다.
  • Azure에서 Kubernetes 부하 분산 장치를 만들면 해당 Azure Load Balancer 리소스가 동시에 설정됩니다.
  • Pod에 대한 네트워크 포트를 열면 Azure는 필요한 네트워크 보안 그룹 규칙을 자동으로 구성합니다.
  • Azure는 새로운 수신 경로가 설정됨에 따라 HTTP 애플리케이션 라우팅을 위한 외부 DNS 구성도 관리할 수 있습니다.

Services

애플리케이션 워크로드에 대한 네트워크 구성을 간소화하기 위해 Kubernetes에서는 서비스를 사용해 Pod 집합을 논리적으로 함께 그룹화하고 네트워크 연결을 제공합니다. Kubernetes ServiceType지정하여 원하는 서비스 유형을 정의할 수 있습니다. 예를 들어 클러스터 외부의 외부 IP 주소에 서비스를 노출하려는 경우입니다. 자세한 내용은 게시 서비스(ServiceTypes)에 대한 Kubernetes 설명서를 참조하세요.

다음 ServiceType을 사용할 수 있습니다.

  • ClusterIP

    클러스터 IP는 AKS 클러스터 내에서 사용할 내부 IP 주소를 만듭니다. ClusterIP 서비스는 클러스터 내의 다른 워크로드를 지원하는 내부 전용 애플리케이션에 적합합니다. ClusterIP는 서비스에 대한 형식을 명시적으로 지정하지 않는 경우 사용되는 기본값입니다.

    Diagram showing ClusterIP traffic flow in an AKS cluster

  • NodePort

    NodePort는 노드 IP 주소와 포트를 사용하여 애플리케이션에 직접 액세스할 수 있도록 포트 매핑을 기본 노드에 만듭니다.

    Diagram showing NodePort traffic flow in an AKS cluster

  • LoadBalancer

    LoadBalancer는 Azure 부하 분산 장치 리소스를 만들고, 외부 IP 주소를 구성하고, 요청된 Pod을 부하 분산 장치 백 엔드 풀에 연결합니다. 고객의 트래픽이 애플리케이션에 도달할 수 있도록 하기 위해 원하는 포트에 부하 분산 규칙을 만듭니다.

    Diagram showing Load Balancer traffic flow in an AKS cluster

    인바운드 트래픽의 HTTP 부하 분산을 위한 또 다른 옵션은 수신 컨트롤러를 사용하는 것입니다.

  • ExternalName

    애플리케이션 액세스를 쉽게 하기 위해 특정 DNS 항목을 만듭니다.

부하 분산 장치 및 서비스 IP 주소를 동적으로 할당하거나 기존 고정 IP 주소를 할당할 수 있습니다. 내부 및 외부 고정 IP 주소를 모두 할당할 수 있습니다. 기존 고정 IP 주소는 DNS 항목에 연결되는 경우가 많습니다.

내부외부 부하 분산 장치를 모두 만들 수 있습니다. 내부 부하 분산 장치에는 개인 IP 주소만 할당되므로 인터넷에서 액세스할 수 없습니다.

Kubernetes 문서서 서비스에 대해 자세히 알아보세요.

Azure 가상 네트워크

AKS에서는 다음 네트워크 모델 중 하나를 사용하는 클러스터를 배포할 수 있습니다.

  • Kubenet 네트워킹

    네트워크 리소스는 일반적으로 AKS 클러스터가 배포될 때 만들어지고 구성됩니다.

  • Azure CNI(Container Networking Interface) 네트워킹

    AKS 클러스터는 기존 가상 네트워크 리소스 및 구성에 연결됩니다.

Kubenet(기본) 네트워킹

kubenet 네트워킹 옵션은 AKS 클러스터 만들기에 대한 기본 구성입니다. kubenet 사용:

  1. 노드가 Azure Virtual Network 서브넷의 IP 주소를 얻습니다.
  2. Pod는 노드의 Azure 가상 네트워크 서브넷이 아닌 논리적으로 다른 주소 공간에서 IP 주소를 받습니다.
  3. 그러면 Pod가 Azure 가상 네트워크의 리소스에 연결할 수 있도록 NAT(Network Address Translation)가 구성됩니다.
  4. 트래픽의 원본 IP 주소는 노드의 기본 IP 주소로 변환됩니다.

노드는 kubenet Kubernetes 플러그인을 사용합니다. Azure 플랫폼에서 가상 네트워크를 만들고 구성하거나 기존 가상 네트워크 서브넷에 AKS 클러스터를 배포하도록 선택할 수 있습니다.

노드만 라우팅 가능한 IP 주소를 받습니다. Pod는 NAT를 사용하여 AKS 클러스터 외부의 다른 리소스와 통신합니다. 이 방법을 사용하면 네트워크 공간에서 pod가 사용하도록 예약해야 하는 IP 주소의 수가 줄어듭니다.

참고 항목

kubenet은 AKS 클러스터에서 가상 네트워크 및 서브넷을 만들기 위한 기본 네트워킹 옵션이지만 프로덕션 배포에는 권장되지 않습니다. 대부분의 프로덕션 배포에서는 우수한 확장성과 성능 특성으로 인해 Azure CNI 네트워킹을 계획하고 사용해야 합니다.

자세한 내용은 AKS 클러스터에 대한 kubenet 네트워킹 구성을 참조하세요.

Azure CNI(고급) 네트워킹

모든 Pod는 Azure CNI를 사용하여 서브넷에서 IP 주소를 가져오며 바로 액세스 가능합니다. 이러한 IP 주소는 미리 계획되어야 하며 네트워크 공간 전체에서 고유해야 합니다. 각 노드에는 지원하는 최대 Pod 수에 대한 구성 매개 변수가 있습니다. 그러면 노드당 동일한 IP 주소 수가 미리 예약됩니다. 이 방식을 사용하면 IP 주소가 소진되거나 애플리케이션 요구 사항이 증가함에 따라 더 큰 서브넷에서 클러스터를 다시 빌드해야 할 수 있으므로 적절하게 계획해야 합니다. 이러한 계획 문제를 방지하기 위해 IP의 동적 할당 및 향상된 서브넷 지원을 위해 기능 Azure CNI 네트워킹을 사용하도록 설정할 수 있습니다.

참고 항목

Kubernetes 제한 사항으로 인해 리소스 그룹 이름, Virtual Network 이름 및 서브넷 이름은 63자 이하여야 합니다.

kubenet과 달리 동일한 가상 네트워크의 엔드포인트에 대한 트래픽은 NAT(변환)를 노드의 기본 IP로 변환되지 않습니다. 가상 네트워크 내부 트래픽의 원본 주소는 Pod IP입니다. 가상 네트워크 외부에 있는 트래픽은 여전히 노드의 기본 IP에 대한 NAT입니다.

노드는 Azure CNI Kubernetes 플러그인을 사용합니다.

Diagram showing two nodes with bridges connecting each to a single Azure VNet

자세한 내용은 AKS 클러스터에 대한 Azure CNI 구성을 참조하세요.

Azure CNI 오버레이 네트워킹

Azure CNI 오버레이 는 가상 네트워크 IP를 Pod에 할당하여 발생하는 확장성 및 계획 과제를 해결하는 Azure CNI의 진화를 나타냅니다. Azure CNI 오버레이는 프라이빗 CIDR IP를 Pod에 할당합니다. 개인 IP는 가상 네트워크와 별개이며 여러 클러스터에서 다시 사용할 수 있습니다. Azure CNI 오버레이는 Kubenet 클러스터에 적용되는 400개 노드 제한을 초과하여 확장할 수 있습니다. Azure CNI 오버레이는 대부분의 클러스터에 권장되는 옵션입니다.

Cilium에서 제공하는 Azure CNI

Cilium으로 구동되는 Azure CNICilium을 사용하여 고성능 네트워킹, 관측 가능성 및 네트워크 정책 적용을 제공합니다. IPAM(확장성 있는 IP 주소 관리)을 위해 기본적으로 Azure CNI 오버레이통합됩니다.

또한 Cilium은 별도의 네트워크 정책 엔진 없이도 기본적으로 네트워크 정책을 적용합니다. Cilium에서 제공하는 Azure CNI는 ePBF 프로그램 및 보다 효율적인 API 개체 구조를 사용하여 Azure 네트워크 정책 관리자의 250개 노드/20K Pod 제한을 초과하여 확장할 수 있습니다.

Cilium으로 구동되는 Azure CNI는 네트워크 정책 적용이 필요한 클러스터에 권장되는 옵션입니다.

자체 CNI 가져오기

사용자 고유의 CNI 가져오기 기능을 사용하여 MICROSOFT가 아닌 CNI를 AKS에 설치할 수 있습니다.

네트워크 모델 비교

kubenet과 Azure CNI 모두 AKS 클러스터에 대한 네트워크 연결을 제공합니다. 그러나 각 방법에는 장단점이 있습니다. 대략적인 수준에서는 다음과 같은 고려 사항이 적용됩니다.

  • kubenet

    • IP 주소 공간을 절약합니다.
    • Kubernetes 내부 또는 외부 부하 분산 장치를 사용하여 클러스터 외부에서 Pod에 연결합니다.
    • 수동으로 UDR(사용자 정의 경로)을 관리하고 유지 관리합니다.
    • 클러스터당 최대 노드 수는 400개입니다.
  • Azure CNI

    • Pod는 전체 가상 네트워크 연결을 가져오고 연결된 네트워크에서 개인 IP 주소를 통해 직접 연결할 수 있습니다.
    • IP 주소 공간이 더 필요합니다.
네트워크 모델 사용 시기
Kubenet • IP 주소 공간 대화가 우선 순위입니다.
• 간단한 구성.
• 클러스터당 노드 수가 400개 미만입니다.
• Kubernetes 내부 또는 외부 부하 분산 장치는 클러스터 외부에서 Pod에 도달하기에 충분합니다.
• 사용자 정의 경로를 수동으로 관리하고 기본 허용됩니다.
Azure CNI • Pod에는 전체 가상 네트워크 연결이 필요합니다.
• 고급 AKS 기능(예: 가상 노드)이 필요합니다.
• 충분한 IP 주소 공간을 사용할 수 있습니다.
• Pod에서 Pod로, 가상 머신에 Pod를 연결해야 합니다.
• 외부 리소스는 Pod에 직접 연결해야 합니다.
• AKS 네트워크 정책이 필요합니다.
Azure CNI 오버레이 • IP 주소 부족 문제가 있습니다.
• 노드당 최대 1,000개의 노드와 250개의 Pod를 확장하는 것으로 충분합니다.
• Pod 연결을 위한 추가 홉은 허용됩니다.
• 네트워크 구성이 더 간단합니다.
• AKS 송신 요구 사항을 충족할 수 있습니다.

kubenet과 Azure CNI 간에는 다음의 동작 차이점이 존재합니다.

기능 kubenet Azure CNI Azure CNI 오버레이 Cilium으로 구동되는 Azure CNI
기존 또는 새 가상 네트워크에 클러스터 배포 지원됨 - UDR이 수동 적용됨 지원됨 지원 지원됨
Pod - Pod 연결 지원 여부 지원 지원 지원 여부
Pod - VM 연결, 동일한 가상 네트워크의 VM Pod에 의해 시작된 경우 작동함 두 가지 방식 작동 Pod에 의해 시작된 경우 작동함 Pod에 의해 시작된 경우 작동함
Pod - VM 연결, 피어링된 가상 네트워크의 VM Pod에 의해 시작된 경우 작동함 두 가지 방식 작동 Pod에 의해 시작된 경우 작동함 Pod에 의해 시작된 경우 작동함
VPN 또는 Express 경로를 사용하여 온-프레미스 액세스 Pod에 의해 시작된 경우 작동함 두 가지 방식 작동 Pod에 의해 시작된 경우 작동함 Pod에 의해 시작된 경우 작동함
서비스 엔드포인트에 의해 보호되는 리소스 액세스 지원 여부 지원 지원 여부
부하 분산 장치 서비스, App Gateway 또는 수신 컨트롤러를 사용하는 Expose Kubernetes 서비스 지원 여부 지원 지원됨 오버레이 모드를 사용할 때에도 동일한 제한 사항
Windows 노드 풀 지원 지원되지 않음 지원됨 지원됨 Linux에서만 사용할 수 있고 Windows에서는 사용할 수 없습니다.
기본 Azure DNS 및 프라이빗 영역 지원 여부 지원 지원됨

Azure CNI 및 kubenet에 대한 자세한 내용을 확인하고 가장 적합한 옵션을 결정하는 데 도움이 되려면 AKS에서 Azure CNI 네트워킹 구성AKS에서 kubenet 네트워킹 사용을 참조하세요.

네트워크 모델 간의 범위 지원

어떤 네트워크 모델을 사용하든 kubenet과 Azure CNI는 다음 중 한 가지 방법으로 배포할 수 있습니다.

  • Azure 플랫폼은 AKS 클러스터를 만들 때 가상 네트워크 리소스를 자동으로 만들고 구성할 수 있습니다.
  • AKS 클러스터를 만들 때 가상 네트워크 리소스를 수동으로 만들고 구성하고 해당 리소스에 연결할 수 있습니다.

kubenet과 Azure CNI 모두 서비스 엔드포인트나 UDR 같은 기능이 지원되기는 하지만 AKS 지원 정책에서는 사용자가 수행할 수 있는 변경 작업을 정의합니다. 예시:

  • AKS 클러스터의 가상 네트워크 리소스를 수동으로 만드는 경우 고유한 UDR이나 서비스 엔드포인트를 구성할 때 지원됩니다.
  • Azure 플랫폼에서 AKS 클러스터의 가상 네트워크 리소스가 자동으로 만들어질 경우, 이와 같은 AKS로 관리되는 리소스를 수동으로 변경하여 자체 UDR 또는 서비스 엔드포인트를 구성할 수 없습니다.

수신 컨트롤러

LoadBalancer 형식 서비스를 만들 때 기본 Azure Load Balancer 리소스도 만듭니다. 부하 분산 장치는 지정된 포트에서 서비스의 Pod에 트래픽을 분산하도록 구성됩니다.

LoadBalancer는 계층 4에서만 작동합니다. 계층 4에서 서비스는 실제 애플리케이션을 인식하지 못하며 더 이상 라우팅을 고려할 수 없습니다.

수신 컨트롤러는 계층 7에서 작동하며 보다 지능적인 규칙을 사용하여 애플리케이션 트래픽을 분산할 수 있습니다. 수신 컨트롤러는 일반적으로 인바운드 URL에 따라 HTTP 트래픽을 다른 애플리케이션으로 라우팅합니다.

Diagram showing Ingress traffic flow in an AKS cluster

수신 리소스 만들기

애플리케이션 라우팅 추가 기능은 AKS에서 수신 컨트롤러를 구성하는 데 권장되는 방법입니다. 애플리케이션 라우팅 추가 기능은 다음 기능을 제공하는 AKS(Azure Kubernetes Service)용 완전 관리형 수신 컨트롤러입니다.

  • Kubernetes NGINX 수신 컨트롤러를 기반으로 관리되는 NGINX 수신 컨트롤러를 쉽게 구성합니다.

  • 공용 및 프라이빗 영역 관리를 위해 Azure DNS와 통합합니다.

  • Azure Key Vault에 저장된 인증서로 SSL 종료

애플리케이션 라우팅 추가 기능에 대한 자세한 내용은 애플리케이션 라우팅 추가 기능을 사용하여 관리되는 NGINX 수신을 참조하세요.

클라이언트 원본 IP 유지

AKS 클러스터의 컨테이너에 대한 요청에 클라이언트 원본 IP를 유지하도록 수신 컨트롤러를 구성합니다. 수신 컨트롤러가 클라이언트의 요청을 AKS 클러스터의 컨테이너에 라우팅하는 경우, 해당 요청의 원래 원본 IP는 대상 컨테이너에서 사용할 수 없습니다. 클라이언트 원본 IP 유지를 사용 설정하면 클라이언트의 원본 IP는 X-Forwarded-For 아래의 요청 헤더에서 사용할 수 있습니다.

수신 컨트롤러에서 클라이언트 원본 IP 유지를 사용하는 경우에는 TLS 통과를 사용할 수 없습니다. 클라이언트 원본 IP 유지 및 TLS 통과는 LoadBalancer 유형과 같은 다른 서비스와 함께 사용할 수 있습니다.

클라이언트 원본 IP 보존에 대한 자세한 내용은 AKS의 부하 분산 장치 서비스에서 클라이언트 원본 IP 보존이 작동하는 방식을 참조하세요.

아웃바운드(송신) 트래픽 제어

AKS 클러스터는 가상 네트워크에 배포되며 해당 가상 네트워크 외부의 서비스에 대한 아웃바운드 종속성이 있습니다. 이러한 아웃바운드 종속성은 거의가 FQDN(정규화된 도메인 이름)으로 정의됩니다. 기본적으로 AKS 클러스터에는 실행하는 노드 및 서비스가 필요에 따라 외부 리소스에 액세스할 수 있도록 하는 무제한 아웃바운드(송신) 인터넷 액세스가 있습니다. 원하는 경우 아웃바운드 트래픽을 제한할 수 있습니다.

자세한 내용은 AKS에서 클러스터 노드의 송신 트래픽 제어를 참조하세요.

네트워크 보안 그룹

네트워크 보안 그룹은 AKS 노드와 같은 VM의 트래픽을 필터링합니다. 부하 분산 장치와 같은 서비스를 만들 때 Azure 플랫폼은 필요한 모든 네트워크 보안 그룹 규칙을 자동으로 구성합니다.

AKS 클러스터의 Pod에 대한 트래픽을 필터링하는 네트워크 보안 그룹 규칙은 수동으로 구성할 필요가 없습니다. Kubernetes Service 매니페스트의 일부로 필요한 포트 및 전달을 정의하고 Azure 플랫폼에서 해당하는 규칙을 만들거나 업데이트하도록 할 수 있습니다.

또한 네트워크 정책을 사용하여 트래픽 필터 규칙을 Pod에 자동으로 적용할 수도 있습니다.

자세한 내용은 네트워크 보안 그룹이 네트워크 트래픽을 필터링하는 방법을 참조하세요.

네트워크 정책

기본적으로 AKS 클러스터의 모든 pod는 트래픽을 제한 없이 송수신할 수 있습니다. 보안 향상을 위해 다음과 같이 트래픽의 흐름을 제어하는 규칙을 정의할 수 있습니다.

  • 백 엔드 애플리케이션은 필요한 프런트 엔드 서비스에만 노출됩니다.
  • 데이터베이스 구성 요소에 연결하는 애플리케이션 계층에서만 해당 구성 요소에 액세스할 수 있습니다.

네트워크 정책은 AKS에서 사용 가능한 Kubernetes 기능으로서 사용자가 Pod 간의 트래픽 흐름을 제어하도록 돕습니다. 할당된 레이블, 네임스페이스 또는 트래픽 포트와 같은 설정에 따라 Pod에 대한 트래픽을 허용하거나 거부할 수 있습니다. 네트워크 보안 그룹은 AKS 노드에 더 적합하지만 네트워크 정책은 Pod에 대한 트래픽 흐름을 제어하는 데 더 적합한 클라우드 네이티브 방법입니다. Pod는 AKS 클러스터에서 동적으로 생성되므로 필요한 네트워크 정책을 자동으로 적용할 수 있습니다.

자세한 내용은 AKS(Azure Kubernetes Service)에서 네트워크 정책을 사용하여 pod 간 트래픽 보호를 참조하세요.

다음 단계

AKS 네트워킹을 시작하려면 kubenet이나 Azure CNI를 사용하여 자체 IP 주소 범위로 AKS 클러스터를 만들고 구성합니다.

관련된 모범 사례에 대해서는 AKS의 네트워크 연결 및 보안에 대한 모범 사례를 참조하세요.

Kubernetes 및 AKS 핵심 개념에 대한 자세한 내용은 다음 문서를 참조하세요.