다음을 통해 공유


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

중요합니다

2028년 3월 31일에 AKS(Azure Kubernetes Service)에 대한 kubenet 네트워킹이 사용 중지됩니다.

서비스 중단을 방지하려면 AKS용 kubenet에서 실행되는 워크로드가 더 이상 지원되지 않는 날짜 이전에Azure CNI(Container Networking Interface) 오버레이로 업그레이드해야 합니다.

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

필수 조건

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

  • 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 범위 내의 트래픽을 허용하는지 확인합니다. 자세한 내용은 네트워크 보안 그룹을 참조하세요.

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 주소에 사용됩니다.

  • Azure CNI: 동일한 기본 /24 서브넷 범위는 클러스터에서 최대 8개의 노드만 지원할 수 있습니다. 이 노드 수는 최대 240개의 Pod만 지원할 수 있으며 기본적으로 노드당 최대 Pod는 30개입니다.

참고 항목

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

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

Azure CNIAzure 가상 네트워크 피어링 또는 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의 최대 수는 얼마나 되나요?

    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를 서비스에 할당할 수 있습니다. 클러스터의 가상 네트워크 외부에서 주소 범위를 사용하는 것을 확인하여 겹치는 위험을 방지할 수 있습니다.