Azure Operator Nexus Kubernetes의 리소스 배치
Operator Nexus 인스턴스는 고객 구내에 배포됩니다. 각 인스턴스는 하나 이상의 운영 체제 미설치 서버 랙으로 구성됩니다.
사용자는 NKS(Nexus Kubernetes Cluster)를 만들 때 Kubernetes 컨트롤 플레인과 하나 이상의 에이전트 풀을 구성하는 VM(가상 머신)의 수와 SKU(Stock Keeping Unit)를 지정합니다. 에이전트 풀은 고객의 컨테이너화된 네트워크 기능이 실행되는 작업자 노드 집합입니다.
Nexus 플랫폼은 각 NKS VM이 시작되는 운영 체제 미설치 서버를 결정하는 역할을 담당합니다.
Nexus 플랫폼이 Nexus Kubernetes 클러스터 VM을 예약하는 방법
Nexus는 먼저 NKS VM SKU의 모든 리소스 요구 사항을 충족하는 잠재적 운영 체제 미설치 서버 집합을 식별합니다. 예를 들어, 사용자가 에이전트 풀에 대해 NC_G48_224_v1 VM SKU를 지정한 경우 Nexus는 48 vCPU, 224Gi RAM 등의 사용 가능한 용량이 있는 운영 체제 미설치 서버를 수집합니다.
그런 다음 Nexus는 예약 중인 에이전트 풀 또는 컨트롤 플레인에 대한 AvailabilityZones 필드를 검사합니다. 이 필드가 비어 있지 않으면 Nexus는 잠재적 운영 체제 미설치 서버 목록을 지정된 가용성 영역(랙)에 있는 서버로만 필터링합니다. 이 동작은 하드 예약 제약 조건입니다. 필터링된 목록에 운영 체제 미설치 서버가 없으면 Nexus는 NKS VM을 예약하지 않으며 클러스터가 프로비전되지 않습니다.
Nexus가 NKS VM을 배치할 잠재적 운영 체제 미설치 서버 목록을 식별하면 Nexus는 다음 정렬 규칙을 적용한 후 운영 체제 미설치 서버 중 하나를 선택합니다.
이 NKS 클러스터의 NKS VM이 없는 가용성 영역(랙)의 운영 체제 미설치 서버를 선호합니다. 즉, NKS 클러스터용 NKS VM을 가용성 영역 전체에 분산합니다.
동일한 NKS 클러스터의 다른 NKS VM이 없는 단일 가용성 영역(랙) 내의 운영 체제 미설치 서버를 선호합니다. 즉, 가용성 영역 내의 운영 체제 미설치 서버에 NKS 클러스터용 NKS VM을 분산합니다.
NKS VM SKU가
NC_G48_224_v1또는NC_P46_224_v1인 경우 이미 다른 NKS 클러스터의NC_G48_224_v1또는NC_P46_224_v1NKS VM을 수용하는 운영 체제 미설치 서버를 선호합니다. 즉, 동일한 운영 체제 미설치 서버에 있는 다양한 NKS 클러스터의 초대형 VM을 그룹화합니다. 이 규칙은 사용 가능한 컴퓨팅 리소스의 조각화를 줄이기 위해 초대형 VM을 "bin pack"합니다.위에서 언급한 "bin packing" 규칙은 대형 VM 외에 더 작은 VM에도 적용됩니다. 이렇게 하면 여러 클러스터의 작은 VM을 동일한 baremetal 머신으로 "압축"하여 전반적인 배치 효율성을 높일 수 있습니다. 예를 들어 서로 다른 클러스터의 컨트롤 플레인 노드 및 작은 SKU 노드(에이전트 풀)가 함께 사용됩니다.
배치 시나리오의 예
다음 섹션에서는 Operator Nexus 환경에 대해 NKS 클러스터를 만들 때 Nexus 사용자가 예상해야 하는 동작을 강조 표시합니다.
힌트: NKS KubernetesCluster 리소스의
nodes.bareMetalMachineId속성을 검사하거나 Azure Portal의 Kubernetes 클러스터 노드 표시에서 "호스트" 열을 보면 NKS VM이 예약된 운영 체제 미설치 서버를 확인할 수 있습니다.
Operator Nexus 환경 사양 예는 다음과 같습니다.
- 운영 체제 미설치 서버 16개로 구성된 랙 8개
- 각 운영 체제 미설치 서버에는 두 개의 NUMA(Non-Uniform Memory Access) 셀이 포함되어 있습니다.
- 각 NUMA 셀은 48개의 CPU와 224Gi RAM을 제공합니다.
빈 환경
지정된 용량을 갖춘 비어 있는 Operator Nexus 환경이 주어지면 크기가 다른 3개의 Nexus Kubernetes 클러스터를 만듭니다.
NKS 클러스터에 이러한 사양이 있고, 이 연습의 목적을 위해 사용자가 다음 순서로 세 개의 클러스터를 만든다고 가정합니다.
클러스터 A
- 컨트롤 플레인,
NC_G12_56_v1SKU, 3개 - 에이전트 풀 #1,
NC_P46_224_v1SKU, 24개 - 에이전트 풀 #2,
NC_G6_28_v1SKU, 6개
클러스터 B
- 컨트롤 플레인,
NC_G24_112_v1SKU, 5개 - 에이전트 풀 #1,
NC_P46_224_v1SKU, 48개 - 에이전트 풀 #2,
NC_P22_112_v1SKU, 24개
클러스터 C
- 컨트롤 플레인,
NC_G12_56_v1SKU, 3개 - 에이전트 풀 #1,
NC_P46_224_v1SKU, 12개,AvailabilityZones = [1,4]
다음은 빈 Operator Nexus 환경에서 클러스터 A, B, C를 시작한 후 사용자에게 표시되는 내용을 요약한 표입니다.
| 클러스터 | 풀 | SKU | 총 개수 | 예상 랙 수 | 실제 랙 수 | 랙당 예상되는 VM 수 | 랙당 실제 VM 수 |
|---|---|---|---|---|---|---|---|
| A | 컨트롤 플레인 | NC_G12_56_v1 |
3 | 3 | 3 | 1 | 1 |
| A | 에이전트 풀 #1 | NC_P46_224_v1 |
24 | 8 | 8 | 3 | 3 |
| A | 에이전트 풀 #2 | NC_G6_28_v1 |
6 | 6 | 6 | 1 | 1 |
| B | 컨트롤 플레인 | NC_G24_112_v1 |
5 | 5 | 5 | 1 | 1 |
| B | 에이전트 풀 #1 | NC_P46_224_v1 |
48 | 8 | 8 | 6 | 6 |
| B | 에이전트 풀 #2 | NC_P22_112_v1 |
24 | 8 | 8 | 3 | 3 |
| C | 컨트롤 플레인 | NC_G12_56_v1 |
3 | 3 | 3 | 1 | 1 |
| C | 에이전트 풀 #1 | NC_P46_224_v1 |
12 | 2 | 2 | 6 | 6 |
8개의 랙이 있으므로 각 풀의 VM은 최대 8개의 랙에 분산됩니다. 8개 이상의 VM이 포함된 풀에는 다양한 운영 체제 미설치 서버에 분산된 랙당 여러 VM이 필요합니다.
클러스터 C 에이전트 풀 #1에는 AvailabilityZones[1, 4]로 제한된 12개의 VM이 있으므로 12개의 운영 체제 미설치 서버에 12개의 VM이 있으며, 랙 1과 4 각각에 6개가 있습니다.
다른 클러스터의 초대형 VM(NC_P46_224_v1 SKU)이 동일한 운영 체제 미설치 서버에 배치됩니다(Nexus 플랫폼이 Nexus Kubernetes 클러스터 VM을 예약하는 방법의 규칙 #3 참조).
다음은 클러스터 A, B, C를 빈 환경에 배포한 후 사용자가 볼 수 있는 레이아웃의 시각화입니다.
절반만 채워진 환경
이제 대상 환경이 절반쯤 찼을 때 다른 NKS 클러스터를 시작하는 예를 살펴보겠습니다. 클러스터 A, B, C가 대상 환경에 배포된 후 대상 환경은 절반 정도 채워집니다.
클러스터 D의 사양은 다음과 같습니다.
- 컨트롤 플레인,
NC_G24_112_v1SKU, 5개 - 에이전트 풀 #1,
NC_P46_224_v1SKU, 24개,AvailabilityZones = [7,8] - 에이전트 풀 #2,
NC_P22_112_v1SKU, 24개
다음은 클러스터 A, B, C를 시작한 후 존재하는 절반만 채워진 Operator Nexus 환경에서 클러스터 D를 시작한 후 사용자에게 표시되는 내용을 요약한 표입니다.
| 클러스터 | 풀 | SKU | 총 개수 | 예상 랙 수 | 실제 랙 수 | 랙당 예상되는 VM 수 | 랙당 실제 VM 수 |
|---|---|---|---|---|---|---|---|
| D | 컨트롤 플레인 | NC_G12_56_v1 |
5 | 5 | 5 | 1 | 1 |
| D | 에이전트 풀 #1 | NC_P46_224_v1 |
24 | 2 | 2 | 12 | 12 |
| D | 에이전트 풀 #2 | NC_P22_112_v1 |
24 | 8 | 8 | 3 | 3 |
클러스터 D 에이전트 풀 #1에는 AvailabilityZones[7, 8]로 제한된 12개의 VM이 있으므로 12개의 운영 체제 미설치 서버에 12개의 VM이 있으며, 랙 7과 8 각각에 6개가 있습니다. 이러한 VM은 다른 클러스터의 초대형 VM을 동일한 운영 체제 미설치 서버로 그룹화하는 정렬 규칙으로 인해 다른 클러스터의 초대형 VM도 수용하는 운영 체제 미설치 서버에 위치합니다.
클러스터 D 컨트롤 플레인 VM이 랙 7 또는 8에 배치되는 경우 하나의 클러스터 D 에이전트 풀 #1 VM이 해당 클러스터 D 컨트롤 플레인 VM과 동일한 운영 체제 미설치 서버에 배치될 가능성이 높습니다. 이 동작은 에이전트 풀 #1이 랙 7과 8에 "고정"되어 있기 때문에 발생합니다. 해당 랙의 용량 제약 조건으로 인해 스케줄러는 동일한 NKS 클러스터에서 컨트롤 플레인 VM과 에이전트 풀 #1 VM을 배치하게 됩니다.
클러스터 D의 에이전트 풀 #2에는 8개의 랙 각각에 있는 서로 다른 운영 체제 미설치 서버에 3개의 VM이 있습니다. 클러스터 D의 에이전트 풀 #1이 랙 7과 8에 고정되어 용량 제약 조건이 발생했습니다. 따라서 클러스터 D의 에이전트 풀 #1과 에이전트 풀 #2의 VM은 랙 7과 8의 동일한 운영 체제 미설치 서버에 배치됩니다.
다음은 클러스터 D를 대상 환경에 배포한 후 사용자가 볼 수 있는 레이아웃의 시각화입니다.
거의 찬 환경
예 대상 환경에서는 8개 랙 중 4개가 용량에 거의 도달했습니다. 다른 NKS 클러스터를 시작하겠습니다.
클러스터 E의 사양은 다음과 같습니다.
- 컨트롤 플레인,
NC_G24_112_v1SKU, 5개 - 에이전트 풀 #1,
NC_P46_224_v1SKU, 32개
다음은 클러스터 E를 대상 환경으로 시작한 후 사용자에게 표시되는 내용을 요약한 표입니다.
| 클러스터 | 풀 | SKU | 총 개수 | 예상 랙 수 | 실제 랙 수 | 랙당 예상되는 VM 수 | 랙당 실제 VM 수 |
|---|---|---|---|---|---|---|---|
| E | 컨트롤 플레인 | NC_G24_112_v1 |
5 | 5 | 5 | 1 | 1 |
| E | 에이전트 풀 #1 | NC_P46_224_v1 |
32 | 8 | 8 | 4 | 3, 4 또는 5 |
클러스터 E의 에이전트 풀 #1은 8개 랙 전체에 고르지 않게 분산됩니다. 랙 7과 랙 8에는 클러스터 A~D를 예약한 후 해당 랙의 초대형 SKU VM을 위한 용량이 더 이상 없기 때문에 예상했던 4개의 NKS VM 대신 에이전트 풀 #1의 3개 NKS VM이 있습니다. 랙 7과 랙 8에 에이전트 풀 #1의 네 번째 초대형 SKU를 위한 용량이 없기 때문에 사용률이 가장 낮은 2개의 랙에 5개의 NKS VM이 배치됩니다. 이 예에서는 활용도가 가장 낮은 랙이 랙 3과 6이었습니다.
다음은 클러스터 E를 대상 환경에 배포한 후 사용자가 볼 수 있는 레이아웃의 시각화입니다.
런타임 업그레이드 중에 배치
2024년 4월(Network Cloud 2304.1 릴리스)부터 런타임 업그레이드는 랙별 전략을 사용하여 수행됩니다. 랙 1의 운영 체제 미설치 서버는 한꺼번에 이미지로 다시 생성됩니다. 모든 운영 체제 미설치 서버가 성공적으로 다시 시작되고 Nexus에 워크로드를 수신할 준비가 되었음을 알릴 때까지 업그레이드 프로세스가 일시 중지됩니다.
참고 항목
Operator Nexus에 랙에 있는 운영 체제 미설치 서버의 일부를 한 번에 이미지로 다시 설치하도록 지시할 수 있지만, 기본값은 랙에 있는 모든 운영 체제 미설치 서버를 병렬로 이미지로 다시 설치하는 것입니다.
개별 운영 체제 미설치 서버의 이미지를 다시 작성하면 모든 NKS VM을 포함하여 해당 운영 체제 미설치 서버에서 실행되는 모든 워크로드의 전원이 꺼지고 연결이 끊어집니다. 그러면 NKS VM에서 실행되는 워크로드 컨테이너가 전원과 연결이 끊어집니다. 해당 워크로드 컨테이너에 연결할 수 없게 된 후 1분을 경과하면 NKS 클러스터의 Kubernetes 컨트롤 플레인에서 해당 Pod를 비정상으로 표시합니다. Pod가 배포 또는 StatefulSet의 멤버인 경우 NKS 클러스터의 Kubernetes 컨트롤 플레인은 배포 또는 StatefulSet의 관찰된 복제본 수를 원하는 복제본 수로 다시 가져오기 위해 대체 Pod를 시작하려고 시도합니다.
새 Pod는 나머지 정상 NKS VM에 Pod에 사용할 수 있는 용량이 있는 경우에만 시작됩니다. 2024년 4월(Network Cloud 2304.1 릴리스) 현재 이미지로 다시 설치되는 운영 체제 미설치 서버에 있던 NKS VM을 대체할 새로운 NKS VM은 생성되지 않습니다.
운영 체제 미설치 서버의 이미지가 성공적으로 다시 생성되고 새 NKS VM을 허용할 수 있게 되면 원래 동일한 운영 체제 미설치 서버에 있던 NKS VM이 새로 이미지로 다시 생성된 운영 체제 미설치 서버에서 다시 시작됩니다. 그러면 워크로드 컨테이너가 해당 NKS VM에 예약되어 잠재적으로 운영 체제 미설치 서버에 있던 NKS VM에 Pod가 있는 배포 또는 StatefulSet을 복원할 수 있습니다.
참고 항목
이 동작은 사용자에게 NKS VM이 운영 체제 미설치 서버에서 "이동"하지 않은 것처럼 보일 수 있지만 실제로는 동일한 NKS VM의 새 인스턴스가 이름은 동일하게 유지한 채 새로 이미지로 다시 설치된 운영 체제 미설치 서버에서 실행되었습니다.
모범 사례
Operator Nexus와 협력할 때 다음 모범 사례를 염두에 둡니다.
- 에이전트 풀에 대해
AvailabilityZones를 지정하지 마세요. - 큰 NKS 클러스터를 작은 NKS 클러스터보다 먼저 시작합니다.
- VM SKU 크기를 줄이기 전에 에이전트 풀 수를 줄입니다.
에이전트 풀에 AvailabilityZone을 지정하지 마세요.
위 배치 시나리오에서 알 수 있듯이 에이전트 풀에 대해 AvailabilityZones를 지정하는 것이 동일한 NKS 클러스터의 NKS VM이 동일한 운영 체제 미설치 서버에 있게 되는 주된 이유입니다. AvailabilityZones를 지정하면 에이전트 풀을 랙의 하위 집합에 "고정"하게 되므로 동일한 NKS 클러스터에 있는 다른 NKS 클러스터 및 다른 에이전트 풀 VM에 대한 해당 랙 집합의 잠재적인 운영 체제 미설치 서버 수가 제한됩니다.
따라서 첫 번째 모범 사례는 에이전트 풀에 대해 AvailabilityZones를 지정하지 않는 것입니다. 에이전트 풀을 가용성 영역 집합에 고정해야 하는 경우 발생할 수 있는 불균형을 최소화하기 위해 해당 집합을 최대한 크게 만듭니다.
이 모범 사례의 한 가지 예외는 에이전트 풀에 VM이 2~3개만 있는 시나리오가 있는 경우입니다. 런타임 업그레이드 중에 가용성을 높이려면 해당 에이전트 풀의 AvailabilityZones를 [1,3,5,7] 또는 [0,2,4,6]으로 설정하는 것을 고려할 수 있습니다.
큰 NKS 클러스터를 작은 NKS 클러스터보다 먼저 시작
2024년 4월 현재 Network Cloud 2403.1 릴리스부터 NKS 클러스터는 만들어지는 순서대로 예약됩니다. 대상 환경을 가장 효율적으로 압축하려면 작은 NKS 클러스트보다 큰 클러스터를 먼저 만드는 것이 좋습니다. 마찬가지로 더 작은 에이전트 풀보다 더 큰 에이전트 풀을 예약하는 것이 좋습니다.
이 권장 사항은 초대형 NC_G48_224_v1 또는 NC_P46_224_v1 SKU를 사용하는 에이전트 풀에 중요합니다. 이러한 초대형 SKU VM 수가 가장 많은 에이전트 풀을 예약하면 다른 NKS 클러스터에 있는 에이전트 풀의 다른 초대형 SKU VM이 배치될 수 있는 더 큰 운영 체제 미설치 서버 집합이 만들어집니다.
VM SKU 크기를 줄이기 전에 에이전트 풀 수 줄이기
NKS 클러스터 또는 에이전트 풀을 시작할 때 용량 제약 조건이 발생하는 경우 VM SKU 크기를 조정하기 전에 에이전트 풀 수를 줄입니다. 예를 들어, VM SKU 크기는 NC_P46_224_v1이고 에이전트 풀은 24개인 NKS 클러스터를 만들려고 시도하지만 리소스 부족으로 인해 NKS 클러스터를 프로비전하지 못하는 경우 VM SKU 크기는 NC_P36_168_v1로 줄이고 풀 개수는 24개를 유지해 볼 수 있습니다. 그러나 워크로드 VM을 운영 체제 미설치 서버의 단일 NUMA 셀에 정렬해야 한다는 요구 사항으로 인해 동일한 요청으로 인해 비슷한 리소스 부족 오류가 발생할 가능성이 높습니다. VM SKU 크기를 줄이는 대신 에이전트 풀 수를 20으로 줄이는 것이 좋습니다. VM SKU 크기를 축소한 경우보다 요청이 대상 환경의 리소스 용량 내에 적합하고 전체 배포에 CPU 코어가 더 많을 가능성이 더 높습니다.
메모리 최적화 VM SKU
NC_E94_448_v1 물리적 컴퓨터의 고객이 사용할 수 있는 모든 리소스를 사용합니다. NC_E70_336_v1 고객이 사용할 수 있는 리소스의 75%를 소비하고 있지만, 이것이 정확히 하나의 전체 NUMA 셀과 절반의 NUMA 셀이 될 것이라는 것은 보증되지 않습니다. 즉, NC_E70_336_v1 VM이 NUMA 셀 간에 예약되는 방식에 따라 NC_E70_336_v1 실행하는 컴퓨터에서 NC_G24_112_v1 예약하거나 예약하지 못할 수 있습니다.