AKS(Azure Kubernetes Service) 클러스터에 대한 IP 주소 계획
이 문서에서는 AKS(Azure Kubernetes Service) 클러스터에 대한 IP 주소 계획과 관련된 지침을 제공합니다.
개별 CNI 옵션에 대한 IP 주소 계획과 관련된 구체적인 지침은 다음 단계 섹션에서 플러그 인 설명서 링크를 참조하세요.
서브넷 크기 조정
Azure VNet 서브넷은 클러스터를 수용할 수 있을 만큼 충분히 커야 하는데, 이는 오버레이 네트워크를 사용하는지, 아니면 플랫 네트워크를 사용하는지에 따라 달라집니다.
오버레이 네트워크
Azure CNI 오버레이 같은 오버레이 네트워크를 사용하면 서브넷이 노드에 IP를 할당할 만큼 충분히 커야 합니다. Pod는 별도의 프라이빗 CIDR 범위에서 IP가 할당되며 VNet IP가 필요하지 않습니다. 클러스터에 사용하는 VNet 서브넷은 플랫 네트워크보다 작을 수 있습니다.
Pod가 크기 조정을 고려할 수 있도록 프라이빗 CIDR 범위에 충분한 공간을 할당해야 합니다. IP 주소 범위 크기를 계획할 때는 최대 Pod 수를 계산해야 합니다. 클러스터의 각 노드에는 Pod에 대한 /24(256개의 IP 주소) 서브넷이 할당됩니다. 실행하려는 최대 노드 수를 수용하도록 오버레이 네트워크 서브넷을 계획해야 합니다.
플랫 네트워크
Azure CNI Pod 서브넷 같은 플랫 네트워크에는 노드 및 Pod를 모두 수용할 수 있는 충분한 서브넷이 필요합니다. 노드 및 Pod는 VNet에서 IP를 수신하므로 실행할 최대 노드 및 Pod 수를 계획해야 합니다. Azure CNI Pod 서브넷은 노드에 서브넷을 사용하고 Pod에 대해 별도의 서브넷을 사용하므로 둘 다 계획해야 합니다.
IP 주소 크기 조정
업그레이드 및 크기 조정 관련 고려 사항
AKS 클러스터에 대한 IP 주소 계획을 수립하는 경우 업그레이드 및 크기 조정 작업에 필요한 IP 주소 수를 고려해야 합니다. 고정 노드 수만 지원하는 IP 주소 범위를 설정할 경우 클러스터를 업그레이드하거나 크기 조정할 수 없습니다.
AKS 클러스터를 업그레이드할 경우 새 노드가 클러스터에 배포됩니다. 서비스 및 워크로드가 새 노드에서 실행되기 시작하고 기존 노드가 클러스터에서 제거됩니다. 이 업그레이드 배포 프로세스를 위해서는 최소 하나의 추가 IP 주소 블록을 사용할 수 있어야 합니다. 그러면 노드 수가 n + 1이 되는데, 여기서 n은 클러스터의 노드 수입니다.
AKS 클러스터를 크기 조정할 경우 새 노드가 클러스터에 배포됩니다. 서비스 및 워크로드가 새 노드에서 실행되기 시작합니다. IP 주소 범위에서는 클러스터가 지원할 수 있는 노드 및 Pod 수를 조정하려는 방법을 고려해야 합니다. 업그레이드 작업에 대한 추가 노드 하나도 포함되어야 합니다. 그러면 노드 수가 n + number-of-additional-scaled-nodes-you-anticipate + max surge입니다.
Azure CNI Pod 서브넷을 사용 중인 상황에서 노드가 최대 Pod 수를 실행하도록 하고 Pod를 정기적으로 제거 및 배포하려는 경우 노드당 추가 IP 주소 역시 반영해야 합니다. 서비스를 삭제하고 새 서비스를 배포하고 주소를 획득하기 위해 해당 IP 주소를 해제하는 데 몇 초의 대기 시간이 필요할 수 있습니다. 이러한 추가 IP 주소는 이러한 가능성을 고려합니다.
AKS 클러스터에 대한 IP 주소 계획은 노드 및 Pod에 대한 하나 이상의 서브넷에서 가상 네트워크 및 Kubernetes 서비스 주소 범위로 구성됩니다.
| Azure 리소스 | 주소 범위 | 한도 및 크기 조정 |
|---|---|---|
| Azure Virtual Network | 최대 크기 /8. 65,536개의 구성된 IP 주소 한도. 예외는 Azure CNI Pod 서브넷 정적 블록 할당을 참조하세요. | 네트워크 내에서 주소 공간이 겹치면 문제가 발생할 수 있습니다. |
| 서브넷 | 클러스터의 모든 Kubernetes 및 Azure 리소스, Pod, 노드를 수용할 만큼 커야 합니다. 예를 들어, 내부 Azure Load Balancer를 배포하는 경우, 해당 프런트 엔드 IP는 공용 IP가 아닌 클러스터 서브넷에서 할당됩니다. | 서브넷 크기도 업그레이드 작업이나 향후의 크기 조정 요구를 반영해야 합니다. 다음 수식을 사용하여 업그레이드 작업에 추가 노드를 포함하여 최소 서브넷 크기를 계산합니다. 50개 노드 클러스터의 예: 추가로 10개의 노드를 스케일 업하기 위해 준비하는 50개 노드 클러스터의 예: 클러스터를 만들 때 최대 Pod 수를 지정하지 않으면 노드당 최대 Pod 수는 30으로 설정됩니다. 필요한 최소 IP 주소 수는 이 값을 기준으로 합니다. 다른 최댓값을 기준으로 최소 IP 주소 요구 사항을 계산하는 경우 클러스터를 배포할 때 이 값을 설정하려면 노드당 최대 Pod 수를 참조하세요. |
| Kubernetes 서비스 주소 범위 | 이 가상 네트워크의 네트워크 요소 또는 이 가상 네트워크에 연결된 모든 네트워크 요소는 이 범위를 사용하지 않아야 합니다. | 서비스 주소 CIDR은 /12보다 작아야 합니다. 여러 AKS 클러스터에서 이 범위를 재사용할 수 있습니다. |
| Kubernetes DNS 서비스 IP 주소 | 클러스터 서비스 검색에서 사용하는 Kubernetes 서비스 주소 범위 내에 있는 IP 주소입니다. | 주소 범위의 첫 번째 IP 주소를 사용하지 마세요. 서브넷 범위의 첫 번째 주소는 kubernetes.default.svc.cluster.local 주소에 사용됩니다. |
노드당 최대 포드
AKS 클러스터에서 노드당 최대 Pod 수는 250개입니다. 노드당 기본 최대 pod 수는 Kubenet 및 Azure CNI 네트워킹과 클러스터 배포 방법에 따라 다릅니다.
| CNI | 기본 최대 Pod | 배포 시 구성 가능 |
|---|---|---|
| Azure CNI 오버레이 | 250 | 예(최대 250) |
| Azure CNI Pod 서브넷 | 110 | 예(최대 250) |
| Azure CNI(레거시) | 30 | 예(최대 250) |
| Kubenet | 110 | 예(최대 250) |
클러스터에 대한 노드당 최대 Pod 구성
클러스터 배포 시 또는 새 노드 풀을 추가할 때 노드당 최대 Pod 수를 구성할 수 있습니다. 노드당 최대 Pod 값을 최대 250으로 설정할 수 있습니다.
노드당 최대 Pod 수에 대한 최솟값은 클러스터 상태에 중요한 시스템 Pod 공간을 보장하기 위해 적용됩니다. 각 노드 풀의 구성에 최소 30개 Pod에 해당하는 공간이 있는 경우에만 노드당 최대 Pod 수에 대해 설정할 수 있는 최솟값은 10입니다. 예를 들어 노드당 최대 Pod 수를 최소 10으로 설정하려면 각 개별 노드 풀에 최소 3개의 노드가 있어야 합니다. 이 요구 사항은 생성된 새 노드 풀에도 적용되므로 10이 노드당 최대 Pod 수로 정의된 경우 추가된 각 후속 노드 풀에는 3개 이상의 노드가 있어야 합니다.
| 네트워킹 | 최소 | 최대 |
|---|---|---|
| Azure CNI | 10 | 250 |
| Kubenet | 10 | 250 |
참고 항목
이전 테이블의 최솟값은 AKS 서비스에 의해 엄격하게 적용됩니다. 표시된 최소값보다 낮은 maxPods 값을 설정할 수 없습니다. 이렇게 하면 클러스터가 시작되지 않을 수 있습니다.
새 클러스터
다음 방법 중 하나를 사용하여 새 클러스터를 만들 때 노드당 최대 Pod를 정의할 수 있습니다.
- Azure CLI:
az aks create명령을 사용하여 클러스터를 배포할 때--max-pods인수를 지정합니다. - Azure Resource Manager 템플릿: Azure Resource Manager 템플릿을 사용하여 클러스터를 배포할 때 [ManagedClusterAgentPoolProfile] 개체에
maxPods속성을 지정합니다. - Azure Portal: 클러스터를 만들거나 새 노드 풀을 추가할 때 노드 풀 설정에서
Max pods per node필드를 변경합니다.
기존 클러스터
새 노드 풀을 만들 때 노드당 최대 Pod를 정의할 수 있습니다. 기존 클러스터에서 maxPods 설정을 늘려야 하는 경우 원하는 새 maxPods 수로 새 노드 풀을 추가합니다. Pod를 새 풀로 마이그레이션한 후에는 노드 이전 풀을 삭제합니다.
다음 단계
Azure Kubernetes Service
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기