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 부하 분산 장치 리소스가 동시에 설정됩니다.
  • Pod에 대한 네트워크 포트를 열면 Azure에서 필요한 네트워크 보안 그룹 규칙을 자동으로 구성합니다.
  • 또한 Azure는 새 수신 경로가 설정됨에 따라 HTTP 애플리케이션 라우팅에 대한 외부 DNS 구성을 관리할 수 있습니다.

Services

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

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

  • ClusterIP

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

    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과 달리 동일한 가상 네트워크의 엔드포인트로의 트래픽은 노드의 기본 IP에 대한 NAT가 아닙니다. 가상 네트워크 내부 트래픽의 원본 주소는 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 오버레이 는 VNet IP를 Pod에 할당하여 발생하는 확장성 및 계획 과제를 해결하는 Azure CNI의 진화를 나타냅니다. VNet과 별개이며 여러 클러스터에서 다시 사용할 수 있는 Pod에 프라이빗 CIDR IP를 할당하여 이를 달성합니다. 또한 Azure CNI 오버레이는 Kubenet 클러스터에 적용되는 400개 노드 제한을 초과하여 확장할 수 있습니다. Azure CNI 오버레이는 대부분의 클러스터에 권장되는 옵션입니다.

Cilium에서 제공하는 Azure CNI

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

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

Cilium에서 제공하는 Azure CNI는 네트워크 정책 적용이 필요한 클러스터에 권장되는 옵션입니다.

자체 CNI 가져오기

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

네트워크 모델 비교

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

  • kubenet

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

    • Pod는 전체 가상 네트워크 연결을 가져오고 연결된 네트워크에서 개인 IP 주소를 통해 직접 연결할 수 있습니다.
    • 더 많은 IP 주소 공간이 필요합니다.

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 서비스 지원 여부 지원됨 AGIC(Application Gateway 수신 컨트롤러) 지원 없음 오버레이 모드를 사용하는 경우 동일한 제한 사항
Windows 노드 풀 지원 지원되지 않음 지원됨 지원됨 Linux에만 사용할 수 있으며 Windows에는 사용할 수 없습니다.

kubenet 및 Azure CNI 플러그 인 모두에 대해 DNS 서비스는 자체 자동 크기 조정기를 사용하여 AKS에서 실행되는 배포인 CoreDNS에서 제공됩니다. Kubernetes의 CoreDNS에 대한 자세한 내용은 DNS 서비스 사용자 지정을 참조하세요. 기본적으로 CoreDNS는 AKS 클러스터가 배포된 Azure Virtual Network의 DNS 기능에 알 수 없는 작업을 전달하도록 기본 구성됩니다. 따라서 Azure DNS와 프라이빗 영역은 AKS에서 실행되는 Pod에 대해 작동합니다.

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

네트워크 모델 간 지원 범위

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

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

서비스 엔드포인트 또는 UDR과 같은 기능은 kubenet과 Azure CNI 모두에서 지원되지만 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에서 NGINX, 유사한 도구 또는 AKS HTTP 애플리케이션 라우팅 기능을 사용하여 수신 리소스를 만들 수 있습니다. AKS 클러스터에 대해 HTTP 애플리케이션 라우팅을 사용하도록 설정하면 Azure 플랫폼은 수신 컨트롤러와 외부 DNS 컨트롤러를 만듭니다. Kubernetes에서 새 수신 리소스가 만들어질 때 필요한 DNS A 레코드는 클러스터별 DNS 영역에 만들어집니다.

자세한 내용은 HTTP 애플리케이션 라우팅 배포를 참조 하세요.

AGIC(Application Gateway 수신 컨트롤러)

AGIC(Application Gateway 수신 컨트롤러) 추가 기능을 사용하면 Azure의 네이티브 Application Gateway 수준 7 부하 분산 장치를 사용하여 클라우드 소프트웨어를 인터넷에 노출할 수 있습니다. AGIC는 AKS 클러스터 내에서 Pod로 실행됩니다. Kubernetes 수신 리소스를 사용하고 이를 Application Gateway 구성으로 변환하여 게이트웨이가 Kubernetes Pod로 트래픽 부하를 분산할 수 있도록 합니다.

AKS용 AGIC 추가 기능에 대한 자세한 내용은 Application Gateway 수신 컨트롤러란?을 참조하세요.

SSL/TLS 종료

SSL/TLS 종료는 수신의 또 다른 일반적인 기능입니다. HTTPS를 통해 액세스되는 대규모 웹 애플리케이션에서 TLS 종료는 애플리케이션 자체 내에서가 아니라 수신 리소스에서 처리합니다. 자동 TLS 인증 생성 및 구성을 제공하기 위해 "Let's Encrypt"와 같은 공급자를 사용하도록 수신 리소스를 구성할 수 있습니다.

Let's Encrypt를 사용하여 NGINX 수신 컨트롤러를 구성하는 방법에 대한 자세한 내용은 수신 및 TLS를 참조하세요.

클라이언트 원본 IP 유지

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

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

클라이언트 원본 IP 보존 에 대한 자세한 내용은 AKS의 LoadBalancer Services에 대해 클라이언트 원본 IP 보존이 작동하는 방식을 참조하세요.

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

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

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

네트워크 보안 그룹

네트워크 보안 그룹은 AKS 노드와 같은 VM에 대한 트래픽을 필터링합니다. LoadBalancer와 같은 서비스를 만들 때 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 개념에 대한 자세한 내용은 다음 문서를 참조하세요.