AKS 레거시 CNI(컨테이너 네트워킹 인터페이스)

AKS(Azure Kubernetes Service)에서는 Azure CNI 오버레이 및 Azure CNI Pod 서브넷이 대부분의 시나리오에 권장되지만 Azure CNI 노드 서브넷 및 kubenet과 같은 레거시 네트워킹 모델은 여전히 사용 가능하고 지원됩니다. 이러한 레거시 모델은 각각 고유한 기능 및 고려 사항 집합을 사용하여 Pod IP 주소 관리 및 네트워킹에 대한 다양한 접근 방식을 제공합니다. 이 문서에서는 이러한 레거시 네트워킹 옵션에 대한 개요를 제공하며, 해당 역할 및 AKS 클러스터 내에서 효과적으로 사용할 수 있는 방법을 이해하는 데 도움이 되는 필수 구성 요소, 배포 매개 변수, 주요 특성을 자세히 설명합니다.

필수 조건

Azure CNI 노드 서브넷 및 kubenet에는 다음 필수 구성 요소가 필요합니다.

• AKS 클러스터에 대한 가상 네트워크는 아웃바운드 인터넷 연결을 허용해야 합니다.

• AKS 클러스터는 Kubernetes 서비스 주소 범위, Pod 주소 범위 또는 클러스터 가상 네트워크 주소 범위에 대해 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16 또는 192.0.2.0/24를 사용할 수 없습니다.

• AKS 클러스터에서 사용되는 클러스터 ID에는 가상 네트워크 내의 서브넷에서 네트워크 기여자 이상의 권한이 있어야 합니다. 기본 제공 네트워크 기여자 역할을 사용하는 대신 사용자 지정 역할을 정의하려는 경우 다음 권한이 필요합니다.

  • Microsoft.Network/virtualNetworks/subnets/join/action
  • Microsoft.Network/virtualNetworks/subnets/read
  • Microsoft.Authorization/roleAssignments/write

• AKS 노드 풀에 할당된 서브넷은 위임된 서브넷일 수 없습니다.

• AKS는 서브넷에 NSG(네트워크 보안 그룹)를 적용하지 않으며 해당 서브넷과 연결된 NSG를 수정하지 않습니다. 고유한 서브넷을 제공하고 해당 서브넷과 연결된 NSG를 추가하는 경우 NSG의 보안 규칙이 노드 CIDR 범위 내의 트래픽을 허용하는지 확인합니다. 자세한 내용은 네트워크 보안 그룹을 참조하세요.

참고 항목

kubenet은 Windows Server 컨테이너에서 사용할 수 없습니다. Windows Server 노드 풀을 사용하려면 Azure CNI를 사용해야 합니다.

Azure CNI 노드 서브넷

Azure CNI(컨테이너 네트워킹 인터페이스)를 사용하면 모든 pod가 서브넷에서 IP 주소를 가져오고 직접 액세스할 수 있습니다. AKS 클러스터와 동일한 가상 네트워크에 있는 시스템은 Pod에서 들어오는 트래픽에 대한 원본 주소로 Pod IP를 확인합니다. AKS 클러스터 가상 네트워크의 외부 시스템은 Pod에서 들어오는 트래픽에 대한 원본 주소로 노드 IP를 확인합니다. 이러한 IP 주소는 네트워크 공간에서 고유해야 하며 미리 계획되어야 합니다. 각 노드에는 지원하는 최대 Pod 수에 대한 구성 매개 변수가 있습니다. 그러면 노드당 동일한 IP 주소 수가 해당 노드에 대해 미리 예약됩니다. 이 방식을 사용할 경우 더 많은 계획이 필요하며, 애플리케이션 요구가 증가하면서 IP 주소가 고갈되거나 더 큰 서브넷에서 클러스터를 구축해야 할 수 있습니다.

Azure CNI 노드 서브넷을 사용하면 각 Pod는 IP 서브넷에서 IP 주소를 수신하고 다른 Pod 및 서비스와 직접 통신할 수 있습니다. 클러스터는 사용자가 지정하는 IP 주소 범위만큼 클 수 있습니다. 그러나 IP 주소 범위를 미리 계획해야 하며 모든 IP 주소는 지원할 수 있는 최대 Pod 수에 따라 AKS 노드에서 사용됩니다. 가상 노드 또는 네트워크 정책(Azure 또는 Calico)과 같은 고급 네트워크 기능 및 시나리오는 Azure CNI에서 지원됩니다.

배포 매개 변수

AKS 클러스터를 만들 때 Azure CNI 네트워킹에서 다음 매개 변수를 구성할 수 있습니다.

가상 네트워크: Kubernetes 클러스터를 배포하려는 가상 네트워크입니다. 새 가상 네트워크를 만들거나 기존 가상 네트워크를 사용할 수 있습니다. 기존 가상 네트워크를 사용하려면 Kubernetes 클러스터와 동일한 위치 및 Azure 구독에 있는지 확인합니다. Azure Virtual Network의 제한 및 할당량에 대한 내용은 Azure 구독 및 서비스 제한, 할당량 및 제약 조건을 참조하세요.

서브넷: 클러스터를 배포하려는 가상 네트워크 내의 서브넷입니다. 클러스터 생성 프로세스 중 가상 네트워크에 새 서브넷을 추가할 수 있습니다. 하이브리드 연결의 경우 주소 범위가 환경의 다른 가상 네트워크와 겹쳐서는 안 됩니다.

Azure 네트워크 플러그 인: Azure 네트워크 플러그 인을 사용하는 경우 AKS 클러스터에 속하지 않은 clusterCIDR의 IP를 사용하는 VM은 “externalTrafficPolicy=Local”을 포함한 내부 부하 분산 장치 서비스에 액세스할 수 없습니다.

Kubernetes 서비스 주소 범위: 이 매개 변수는 Kubernetes가 클러스터에서 내부 서비스에 할당하는 가상 IP의 세트입니다. 클러스터를 만든 후에는 이 범위를 업데이트할 수 없습니다. 다음 요구 사항을 충족하는 모든 프라이빗 주소 범위를 사용할 수 있습니다.

• 클러스터의 가상 네트워크 IP 주소 범위에 속하지 않아야 합니다.
• 클러스터 가상 네트워크가 피어링된 다른 가상 네트워크와 겹치지 않아야 합니다.
• 온-프레미스 IP와 겹치지 않아야 합니다.
• 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16 또는 192.0.2.0/24 범위 내에 있지 않아야 합니다.

클러스터와 동일한 가상 네트워크 내에서 서비스 주소 범위를 지정할 수 있지만 권장하지는 않습니다. IP 범위가 겹치면 예측할 수 없는 동작이 발생할 수 있습니다. 자세한 내용은 FAQ을 참조하세요. Kubernetes 서비스에 자세한 내용은 Kubernetes 설명서의 서비스를 참조하세요.

Kubernetes DNS 서비스 IP 주소: 클러스터의 DNS 서비스의 IP 주소입니다. 이 주소는 Kubernetes 서비스 주소 범위 내에 있어야 합니다. 주소 범위의 첫 번째 IP 주소를 사용하지 마세요. 서브넷 범위의 첫 번째 주소는 kubernetes.default.svc.cluster.local 주소에 사용됩니다.

Kubenet

AKS 클러스터는 kubenet을 사용하고 기본적으로 Azure Virtual Network와 서브넷을 만듭니다. kubenet을 사용하면 노드는 Azure Virtual Network 서브넷의 IP 주소를 얻습니다. Pod는 논리적으로 다른 주소 공간에서 노드의 Azure 가상 네트워크 서브넷으로 IP 주소를 수신합니다. 그런 후에 NAT(Network Address Translation)는 Pod가 Azure Virtual Network의 리소스에 연결할 수 있도록 구성됩니다. 트래픽의 원본 IP 주소는 노드의 기본 IP 주소로 NAT됩니다. 이 방법을 사용하면 네트워크 공간에서 Pod가 사용하도록 예약해야 하는 IP 주소의 수가 크게 줄어듭니다.

클러스터를 만들 때 또는 새 노드 풀을 만들 때 노드에 배포할 수 있는 최대 Pod 수를 구성할 수 있습니다. 새 노드 풀을 만들 때 maxPods를 지정하지 않으면 kubenet에 대한 기본값인 110을 받게 됩니다.

고유한 서브넷을 사용한 Kubenet 네트워킹 개요

많은 환경에서 IP 주소 범위가 할당된 가상 네트워크와 서브넷을 정의했으며 이러한 리소스를 사용하여 여러 서비스와 애플리케이션을 지원합니다. AKS 클러스터 네트워크 연결을 제공하기 위해 AKS 클러스터는 kubenet(기본 네트워킹) 또는 Azure CNI(고급 네트워킹)을 사용할 수 있습니다.

kubenet을 사용하는 경우 해당 노드만 가상 네트워크 서브넷의 IP 주소를 수신합니다. Pod는 서로 직접 통신할 수 없습니다. 대신 UDR(사용자 정의 라우팅) 및 IP 전달이 노드 전체의 Pod 간 연결을 처리합니다. UDR 및 IP 전달 구성은 기본적으로 AKS 서비스에 의해 만들어지고 유지 관리되지만 원하는 경우 사용자 지정 경로 관리를 위해 자체 경로 테이블을 가져올 수 있습니다. 애플리케이션에 대해 할당된 IP 및 부하 분산 트래픽을 수신하는 서비스 뒤에 pod를 배포할 수도 있습니다. 다음 다이어그램은 AKS 노드가 pod가 아닌 가상 네트워크 서브넷의 IP 주소를 수신하는 방법을 보여 줍니다.

Azure는 UDR에서 최대 400개의 경로를 지원하므로 400개 노드보다 큰 AKS 클러스터를 사용할 수 없습니다. AKS 가상 노드 및 Azure 네트워크 정책은 kubenet에서 지원되지 않습니다. Calico 네트워크 정책이 지원됩니다.

Kubenet의 제한 사항 및 고려 사항

• Kubenet 디자인에는 추가 홉이 필요하며 이는 Pod 통신에 약간의 대기 시간을 추가합니다.
• kubenet을 사용하려면 경로 테이블 및 사용자 정의 경로가 필요하며 이는 작업에 복잡성을 더합니다.
  • 자세한 내용은 AKS에서 사용자 지정 라우팅 테이블을 사용하여 클러스터 송신 사용자 지정 및 AKS에서 아웃바운드 형식으로 클러스터 송신 사용자 지정을 참조하세요.
• Kubenet 디자인으로 인해 kubenet에 직접 Pod 주소 지정은 지원되지 않습니다.
• Azure CNI 클러스터와 달리 여러 kubenet 클러스터는 서브넷을 공유할 수 없습니다.
• AKS는 서브넷에 NSG(네트워크 보안 그룹)를 적용하지 않으며 해당 서브넷과 연결된 NSG를 수정하지 않습니다. 고유한 서브넷을 제공하고 해당 서브넷과 연결된 NSG를 추가하는 경우 NSG의 보안 규칙이 노드와 Pod CIDR 간의 트래픽을 허용하는지 확인해야 합니다. 자세한 내용은 네트워크 보안 그룹을 참조하세요.
• kubenet에서 지원되지 않는 기능은 다음과 같습니다.
  • Azure 네트워크 정책
  • Windows 노드 풀
  • 가상 노드 추가 기능

참고 항목

클러스터 내 konnectivity와 같은 일부 시스템 Pod에서는 오버레이 주소 공간의 IP가 아닌 호스트 노드 IP 주소를 사용합니다. 시스템 Pod는 가상 네트워크의 IP 주소가 아닌 노드 IP만 사용합니다.

IP 주소 가용성 및 고갈

Azure CNI의 일반적인 문제는 할당된 IP 주소 범위가 너무 작아서 클러스터의 크기를 조정하거나 업그레이드할 때 노드를 추가할 수 없다는 것입니다. 또한 네트워크 팀은 예상되는 애플리케이션 요구 사항을 지원하기에 충분히 큰 IP 주소 범위를 발급하지 못할 수도 있습니다. 절충안으로, kubenet을 사용하는 AKS 클러스터를 만들고 기존 가상 네트워크 서브넷에 연결할 수 있습니다. 이 방법을 사용하면 클러스터에서 실행될 수 있는 모든 잠재적 pod를 위해 많은 수의 IP 주소를 미리 예약할 필요가 없이, 노드가 정의된 IP 주소를 수신할 수 있습니다.

kubenet을 사용하면 훨씬 더 작은 IP 주소 범위를 사용하고 대규모 클러스터 및 애플리케이션 요구를 지원할 수 있습니다. 예를 들어, 서브넷의 IP 주소 범위가 /27인 경우 크기 조정 또는 업그레이드할 공간이 충분한 20~25 노드 클러스터를 실행할 수 있습니다. 이 클러스터 크기는 최대 2,200~2,750개의 Pod(기본적으로 노드당 최대 110개의 Pod)를 지원할 수 있습니다. AKS에서 kubenet을 사용하여 구성할 수 있는 노드당 최대 Pod 수는 250입니다.

다음 기본 계산은 네트워크 모델의 차이를 비교합니다.

• kubenet: 간단한 /24 IP 주소 범위는 클러스터에서 최대 251개의 노드를 지원할 수 있습니다. 각 Azure Virtual Network 서브넷은 관리 작업을 위해 처음 3개의 IP 주소를 예약합니다. 이 노드 수는 최대 27,610개의 Pod를 지원할 수 있으며 기본적으로 노드당 최대 Pod 수는 110개입니다.
• Azure CNI: 동일한 기본 /24 서브넷 범위는 클러스터에서 최대 8개의 노드만 지원할 수 있습니다. 이 노드 수는 최대 240개의 Pod만 지원할 수 있으며 기본적으로 노드당 최대 Pod는 30개입니다.

참고 항목

이러한 최대값에는 업그레이드 또는 크기 조정 작업이 고려되지 않습니다. 실제로 서브넷 IP 주소 범위가 지원하는 최대 노드 수를 실행할 수는 없습니다. 크기 조정 또는 업그레이드 작업에 사용할 수 있는 일부 IP 주소를 남겨 두어야 합니다.

가상 네트워크 피어링 및 ExpressRoute 연결

Azure CNI 및 kubenet과 Azure 가상 네트워크 피어링 또는 ExpressRoute 연결을 사용하여 온-프레미스 연결을 제공할 수 있습니다. 중복되거나 잘못된 트래픽 라우팅를 방지하도록 IP 주소를 신중하게 계획해야 합니다. 예를 들어, 여러 온-프레미스 네트워크는 ExpressRoute 연결을 통해 보급되는 10.0.0.0/8 주소 범위를 사용합니다. 172.16.0.0/16과 같이 이 주소 범위 외부의 Azure 가상 네트워크 서브넷에 AKS 클러스터를 만드는 것이 좋습니다.

자세한 내용은 네트워크 모델 및 해당 지원 범위 비교를 참조하세요.

Azure CNI Pod 서브넷

• 내 클러스터 서브넷에 VM을 배포할 수 있나요?

  예, Azure CNI 노드 서브넷의 경우 AKS 클러스터와 동일한 서브넷에 VM을 배포할 수 있습니다.

• Azure CNI 지원 Pod에서 발생하는 트래픽에 대해 외부 시스템에서 확인하는 원본 IP는 무엇인가요?

  AKS 클러스터와 동일한 가상 네트워크에 있는 시스템은 Pod에서 들어오는 트래픽에 대한 원본 주소로 Pod IP를 확인합니다. AKS 클러스터 가상 네트워크의 외부 시스템은 Pod에서 들어오는 트래픽에 대한 원본 주소로 노드 IP를 확인합니다. 하지만 Azure CNI 동적 IP 할당의 경우 연결이 동일한 가상 네트워크 또는 가상 네트워크 간 내에 있더라도 Pod IP는 항상 Pod의 모든 트래픽에 대한 원본 주소입니다. 이는 동적 IP 할당용 Azure CNI가 엔드투엔드 환경을 제공하는 Microsoft Azure Container Networking 인프라를 구현하기 때문입니다. 따라서 ip-masq-agent를 사용하지 않습니다(기존 Azure CNI에서는 계속 사용됨).

• Pod별 네트워크 정책을 구성할 수 있나요?

  예, Kubernetes 네트워크 정책은 AKS에서 사용할 수 있습니다. 시작하려면 AKS에서 네트워크 정책을 사용하여 Pod 간 트래픽 보호를 참조하세요.

• 구성 가능한 노드로 배포할 수 있는 Pod의 최대 수는 얼마나 되나요?

  기본적으로 AKS 클러스터는 kubenet을 사용하며 가상 네트워크 및 서브넷을 만듭니다. Kubenet을 사용하면 노드는 가상 네트워크 서브넷의 IP 주소를 얻습니다. 그런 다음, NAT(Network Address Translation)이 노드에서 구성되며 pod가 노드 IP 뒤에 “숨겨진” IP 주소를 받습니다. 이 방법을 사용하면 네트워크 공간에서 pod가 사용하도록 예약해야 하는 IP 주소의 수가 줄어듭니다.

  Azure CNI(컨테이너 네트워킹 인터페이스)를 사용하면 모든 pod가 서브넷에서 IP 주소를 가져오고 직접 액세스할 수 있습니다. AKS 클러스터와 동일한 가상 네트워크에 있는 시스템은 Pod에서 들어오는 트래픽에 대한 원본 주소로 Pod IP를 확인합니다. AKS 클러스터 가상 네트워크의 외부 시스템은 Pod에서 들어오는 트래픽에 대한 원본 주소로 노드 IP를 확인합니다. 이러한 IP 주소는 네트워크 공간에서 고유해야 하며 미리 계획되어야 합니다. 각 노드에는 지원하는 최대 Pod 수에 대한 구성 매개 변수가 있습니다. 그러면 노드당 동일한 IP 주소 수가 해당 노드에 대해 미리 예약됩니다. 이 방식을 사용할 경우 더 많은 계획이 필요하며, 애플리케이션 요구가 증가하면서 IP 주소가 고갈되거나 더 큰 서브넷에서 클러스터를 구축해야 할 수 있습니다.

• 내 클러스터 서브넷에 VM을 배포할 수 있나요?

  예. 그러나 동적 IP 할당용 Azure CNI의 경우 VM을 Pod의 서브넷에 배포할 수 없습니다.

• Azure CNI 지원 Pod에서 발생하는 트래픽에 대해 외부 시스템에서 확인하는 원본 IP는 무엇인가요?

  AKS 클러스터와 동일한 가상 네트워크에 있는 시스템은 Pod에서 들어오는 트래픽에 대한 원본 주소로 Pod IP를 확인합니다. AKS 클러스터 가상 네트워크의 외부 시스템은 Pod에서 들어오는 트래픽에 대한 원본 주소로 노드 IP를 확인합니다.

  하지만 동적 IP 할당용 Azure CNI의 경우 연결이 동일한 가상 네트워크 또는 가상 네트워크 간 내에 있더라도 Pod IP는 항상 Pod의 모든 트래픽에 대한 원본 주소입니다. 이는 동적 IP 할당용 Azure CNI가 엔드투엔드 환경을 제공하는 Microsoft Azure Container Networking 인프라를 구현하기 때문입니다. 따라서 ip-masq-agent를 사용하지 않습니다(기존 Azure CNI에서는 계속 사용됨).

• Kubernetes Service 주소 범위에 대해 내 클러스터 가상 네트워크 내의 다른 서브넷을 사용할 수 있나요?

  권장되지 않지만 이 구성은 가능합니다. 서비스 주소 범위는 Kubernetes가 클러스터의 내부 서비스에 할당하는 VIP(가상 IP)의 세트입니다. Azure 네트워킹은 Kubernetes 클러스터의 서비스 IP 범위를 볼 수 없습니다. 클러스터의 서비스 주소 범위에 대한 가시성이 부족하면 문제가 발생할 수 있습니다. 나중에 서비스 주소 범위와 겹치는 클러스터 가상 네트워크에 새 서브넷을 만들 수 있습니다. 이러한 중복이 발생하는 경우 Kubernetes는 예기치 않은 동작이나 오류를 일으키는, 서브넷의 다른 리소스에서 이미 사용 중인 IP를 서비스에 할당할 수 있습니다. 클러스터의 가상 네트워크 외부에서 주소 범위를 사용하는 것을 확인하여 겹치는 위험을 방지할 수 있습니다. 예. Azure CLI 또는 Resource Manager 템플릿을 사용하여 클러스터를 배포할 경우입니다. 노드당 최대 포드를 참조하세요.

• Kubernetes Service 주소 범위에 대해 내 클러스터 가상 네트워크 내의 다른 서브넷을 사용할 수 있나요?

  권장되지 않지만 이 구성은 가능합니다. 서비스 주소 범위는 Kubernetes가 클러스터의 내부 서비스에 할당하는 VIP(가상 IP)의 세트입니다. Azure 네트워킹은 Kubernetes 클러스터의 서비스 IP 범위를 볼 수 없습니다. 클러스터의 서비스 주소 범위에 대한 가시성이 부족하면 문제가 발생할 수 있습니다. 나중에 서비스 주소 범위와 겹치는 클러스터 가상 네트워크에 새 서브넷을 만들 수 있습니다. 이러한 중복이 발생하는 경우 Kubernetes는 예기치 않은 동작이나 오류를 일으키는, 서브넷의 다른 리소스에서 이미 사용 중인 IP를 서비스에 할당할 수 있습니다. 클러스터의 가상 네트워크 외부에서 주소 범위를 사용하는 것을 확인하여 겹치는 위험을 방지할 수 있습니다.