노드 강화는 워크로드로 인해 노드가 CPU, 메모리 또는 디스크 압박을 받을 때 노드 안정성을 보호하는 Linux 노드 풀에 대한 옵트인 기능입니다. 클러스터에서 노드 강화를 사용하도록 설정하면 AKS는 각 노드가 Kubernetes 구성 요소 및 호스트 서비스에 대한 리소스를 예약 및 적용하는 방법과 리소스가 부족할 때 kubelet이 Pod를 제거하는 방법을 변경합니다.
이 문서에서는 노드 강화 변경 내용을 설명하고, 강화된 기본값과 표준 AKS 기본값을 비교하며, 기능을 사용하도록 설정하고, 확인하고, 사용자 지정하고, 사용하지 않도록 설정하는 방법을 보여 줍니다.
Important
AKS 미리 보기 기능은 셀프 서비스에서 사용할 수 있습니다(옵트인 방식). 미리 보기는 "있는 그대로" 및 "사용 가능한 상태로" 제공되며 서비스 수준 계약 및 제한적 보증에서 제외됩니다. AKS 미리 보기의 일부는 고객 지원팀에서 최선을 다해 지원합니다. 따라서 이러한 기능은 프로덕션 용도로 사용할 수 없습니다. 자세한 내용은 다음 지원 문서를 참조하세요.
노드 강화의 이점
사용량이 많은 노드 또는 일시적으로 사용량이 급증하는 노드에서 워크로드는 kubelet, 컨테이너 런타임 및 호스트 서비스에 필요한 리소스를 사용할 수 있습니다. 이 경우 노드가 응답하지 않거나 NotReady 상태를 보고하거나 갑자기 Pod를 종료할 수 있습니다. 노드 강화는 다음과 같은 방법으로 이러한 위험을 줄입니다.
-
강제 예약: 기본적으로 AKS는 kube 예약 값을 사용하여 스케줄러가 Pod에 할당할 수 있는 용량을 계산합니다. 노드 강화를 사용하여 kubelet은 Linux 제어 그룹(cgroups)을 통해 kube 예약 및 시스템 예약 용량도 적용합니다. kubelet 및 containerd는 전용
kubereserved.slicecgroup에서 실행되므로 Pod가 노드를 포화하는 경우에도 예약된 CPU 공유 및 메모리를 유지합니다. -
호스트 서비스에 대한 전용 용량: Node Hardening은
system.slice에서 실행되는 호스트 운영 체제 서비스에 대해 시스템 예약 할당을 추가합니다. - 추가 메모리 헤드룸: 사용 가능한 메모리에 대한 하드 축출 임계값은 노드 메모리에 따라 조정되므로 kubelet은 노드의 메모리가 심각하게 부족해지기 전에 Pod를 축출합니다.
- Graceful eviction: 소프트 축출 임계값을 사용하면 메모리 또는 디스크 공간이 부족할 때 종료 유예 기간과 함께 kubelet에서 Pod를 정상적으로 축출합니다. Pod를 즉시 종료하는 하드 축출은 그런 다음 최후의 수단으로 사용됩니다.
- Pod 밀도에 따라 확장되는 예약: kube 예약 메모리 계산은 노드당 최대 Pod 수에 따라 증가하며, 이는 더 많은 Pod를 실행할 때의 kubelet 및 containerd 오버헤드를 반영합니다.
노드 강화를 사용하도록 설정하면 변경되는 내용
다음 표에서는 Kubernetes 1.29 이상을 실행하는 Linux 노드의 표준 기본값을 노드 강화가 사용 설정되면 AKS가 적용하는 기본값과 비교합니다.
리소스 예약
| 설정 | 노드 강화 없이 | 노드 강화 |
|---|---|---|
| Kube용 예약 CPU | CPU 코어 수를 기준으로. 자세한 내용은 CPU 예약을 참조하세요. | 변경 안 됨 |
| Kube용 예약 메모리 |
min(20 × maxPods + 50, 25% of node memory) MiB |
min(35 × maxPods + max(250, 2% of node memory), 25% of node memory) MiB |
| Kube용으로 예약된 프로세스 ID(PID) | 1000 |
예약 안 됨 |
| 시스템에 예약된 CPU | None | 100m |
| 시스템 예약 메모리 | None | 200MiB 및 노드 메모리의 전체 32GiB당 100MiB 및 Azure CNI를 사용하는 클러스터의 경우 100MiB |
| 시스템에서 예약한 임시 스토리지 | None | 1Gi |
축출 임계값
| 설정 | 노드 강화 없이 | 노드 강화 |
|---|---|---|
하드 축출: memory.available |
100Mi |
250Mi 메모리가 8GiB 이하인 노드, 375Mi 메모리가 8GiB 초과 32GiB 미만인 노드 및 512Mi 메모리가 32GiB 이상인 노드의 경우 |
하드 축출: nodefs.available 및 nodefs.inodesFree |
10% 및 5% |
변경 안 됨 |
하드 강제 축출: pid.available |
2000 |
설정되지 않음 |
Soft eviction: memory.available |
None |
500Mi, 750Mi, 또는 1Gi에 하드 제거와 동일한 노드 메모리 계층을 사용하고 30초 유예 기간을 적용합니다 |
소프트 축출: nodefs.available 및 nodefs.inodesFree |
None |
12% 및 7%, 각각 2분의 유예 기간 포함 |
| 소프트 축출 중 최대 Pod 종료 유예 기간 | 설정되지 않음 | 60초 |
Cgroup 강제 적용
| 설정 | 노드 강화 없이 | 노드 강화 |
|---|---|---|
| 노드 allocatable 강제 적용 | pods |
pods, kube-reserved 및 system-reserved |
| Kubelet 및 containerd cgroup |
system.slice, 제한 없이 |
kubereserved.slice, 메모리는 kube 예약 메모리로 제한되고 CPU 공유는 kube 예약 CPU에 비례하여## |
| 호스트 서비스 cgroup |
system.slice, 제한 없이 |
system.slice- 메모리가 시스템 예약 메모리로 제한되고 CPU 공유가 시스템 예약 CPU에 비례합니다. |
Node Hardening은 더 많은 용량을 예약하므로 노드는 Pod에 할당할 수 있는 용량이 더 적다고 보고합니다. 예를 들어 Azure CNI를 사용하는 4개의 vCPU와 16GiB의 메모리가 있는 노드에서 노드 강화를 사용하도록 설정하면 다음과 같이 할당 가능한 용량이 줄어듭니다.
- 노드당 기본 최대 250개 Pod, 약 570MiB의 메모리, 100밀리코어의 CPU 및 1GiB의 임시 스토리지.
- 노드당 최대 30개의 Pod, 약 1.3GiB의 메모리, 100밀리코어의 CPU, 1GiB의 임시 스토리지 기준으로.
소프트 축출 임계값은 할당 가능한 용량을 줄이지 않습니다. kubelet이 Pod를 축출하기 시작할 때만 변경됩니다.
Considerations
노드 강화를 사용하도록 설정하기 전에 다음 사항을 고려해야 합니다.
- 클러스터 수준에서 노드 강화를 사용하도록 설정하면 클러스터의 모든 Linux 노드 풀에 적용됩니다. 개별 노드 풀에는 사용하도록 설정할 수 없으며 Windows 노드 풀에는 영향을 주지 않습니다.
- 노드는 할당 가능한 용량이 더 적게 보고되므로 노드 강화를 사용하도록 설정하기 전에 노드에 맞는 Pod는 나중에 적합하지 않을 수 있습니다. Pod 리소스 요청 및 노드 풀 크기를 검토하세요.
-
system.slice의 호스트 서비스는 시스템 예약 메모리와 동일한 하드 메모리 제한을 공유합니다. 노드에서 보안, 모니터링 또는 로그 전달 에이전트와 같은 systemd 서비스로 자체 에이전트를 실행하는 경우 해당 에이전트는 이 제한에 포함됩니다. 프로덕션 환경에서 Node Hardening을 사용하기 전에 메모리 사용량 및 안정성을 검증하세요. - 노드 풀의 사용자 지정 kubelet 구성에서 설정한 값은 해당 노드 강화 기본값을 재정의합니다. 자세한 내용은 노드 강화 설정 사용자 지정을 참조하세요.
- 나중에 노드 하드닝을 사용하지 않도록 설정하면 기존 노드 풀은 노드가 다시 이미지화된 후에도 강화된 소프트 축출 설정을 유지합니다. 이러한 설정을 제거하려면 새 노드 풀을 만들어야 합니다. 자세한 내용은 노드 강화 비활성화을 참조하세요.
- 기능이 미리 보기 상태인 동안 기본값이 변경될 수 있습니다. 비프로덕션 클러스터로 시작하고 대표적인 노드 압력 조건에서 워크로드를 검증하세요.
Prerequisites
- Azure 구독입니다. 계정이 없는 경우, 무료 계정을만드세요.
- Linux 노드 풀이 있는 AKS 클러스터 또는 하나를 만들 수 있는 권한
-
aks-preview다음 섹션에 설명된 대로 Azure CLI 확장 및CustomNodeConfigPreview기능 플래그
aks-preview Azure CLI 확장 설치
aks-preview확장을az extension add명령을 사용하여 설치합니다.az extension add --name aks-previewaz extension update명령을 사용하여 최신 버전의 확장으로 업데이트합니다.az extension update --name aks-preview
CustomNodeConfigPreview 기능 플래그 등록
CustomNodeConfigPreview명령을 사용하여 기능 플래그를 등록합니다az feature register.az feature register --namespace "Microsoft.ContainerService" --name "CustomNodeConfigPreview"상태가 Registered로 표시되는 데 몇 분 정도 걸립니다.
명령을 사용하여 등록 상태를 확인합니다
az feature show.az feature show --namespace "Microsoft.ContainerService" --name "CustomNodeConfigPreview"상태가 Registered로 표시되면 명령을 사용하여
az provider register리소스 공급자의 등록을 새로 고치세요.az provider register --namespace "Microsoft.ContainerService"
노드 강화 활성화
미리 보기 중에 Node Hardening은 기본적으로 사용하도록 설정되지 않습니다.
새 클러스터에 노드 강화 사용 설정
--enable-node-hardening 매개 변수가 있는 az aks create 명령을 사용하여 노드 강화가 활성화된 클러스터를 만듭니다.
이 명령에는 aks-preview 확장과 CustomNodeConfigPreview 기능 플래그가 필요합니다. 자세한 내용은 전제 조건을 참조하세요.
az aks create \
--resource-group <resource-group-name> \
--name <cluster-name> \
--enable-node-hardening \
--generate-ssh-keys
변경 내용을 확인하려면 노드 하드닝 설정 확인을 참조하세요.
기존 클러스터에서 노드 하드닝 활성화
--enable-node-hardening 매개 변수가 있는 az aks update 명령을 사용하여 기존 클러스터에서 노드 강화를 사용하도록 설정합니다.
이 명령에는 aks-preview 확장과 CustomNodeConfigPreview 기능 플래그가 필요합니다. 자세한 내용은 전제 조건을 참조하세요.
az aks update \
--resource-group <resource-group-name> \
--name <cluster-name> \
--enable-node-hardening
변경 내용을 확인하려면 노드 강화 설정 확인을 참조하세요.
노드 강화 설정 확인
az aks get-credentials명령을 사용하여 클러스터의 자격 증명을 가져옵니다.az aks get-credentials --resource-group <resource-group-name> --name <cluster-name>kubelet 구성 엔드포인트를 쿼리하여 노드에서 유효한 kubelet 예약 및 축출 설정을 검토합니다.
kubectl get --raw "/api/v1/nodes/<node-name>/proxy/configz" | jq '.kubeletconfig | {kubeReserved, systemReserved, evictionHard, evictionSoft, evictionSoftGracePeriod, evictionMaxPodGracePeriod, enforceNodeAllocatable}'강화된 노드에서
systemReserved및evictionSoft에는 값이 있습니다. 그리고enforceNodeAllocatable에는kube-reserved및system-reserved가 포함됩니다.노드의 용량을 할당 가능한 리소스와 비교합니다.
kubectl get node <node-name> -o jsonpath='{.status.capacity}{"\n"}{.status.allocatable}{"\n"}'보안 강화된 노드에서 할당 가능한 CPU, 메모리 및 임시 스토리지는 용량보다 낮습니다. 이 차이는 리소스 예약의 kube 예약 및 시스템 예약 값과 제거 임계값의 하드 제거 임계값을 합한 값과 같습니다. 예를 들어 Azure CNI를 사용하는 4개의 vCPU와 16GiB의 메모리가 있는 노드에서 할당 가능한 CPU는 용량보다 240밀리코어 낮습니다( kube 예약 CPU 140밀리코어 및 시스템 예약 CPU 100밀리코어).
노드 강화 설정 사용자 지정
사용자 지정 kubelet 구성을 사용하여 Linux 노드 풀에 대한 kube 예약 및 제거 기본값을 재정의할 수 있습니다. 이러한 설정에는 CustomNodeConfigPreview 기능 플래그가 필요합니다. 클러스터에서 Node Hardening 활성화 여부와 관계없이 사용할 수 있습니다. AKS는 시스템 예약 값 및 cgroup 적용을 관리하며, 이러한 항목은 사용자 지정할 수 없습니다.
각 설정은 리소스 예약 또는 제거 임계값 테이블의 행 하나를 재정의합니다. Kube 예약 행은 kubeReserved 설정에 해당합니다. 하드 축출 행은 hardEvictionThreshold 설정에 해당합니다. 일시 제거 행은 softEvictionGracePeriod 및 softEvictionThreshold 설정에 해당합니다. 최대 Pod 종료 유예 기간은 evictionMaxPodGracePeriodInSeconds에 해당합니다.
다음과 같은 설정을 구성할 수 있습니다.
| 설정 | Overrides | Description |
|---|---|---|
kubeReserved.cpuMillicores |
Kube 예약된 CPU | Kubernetes 시스템 디먼용으로 예약된 CPU(밀리코어)입니다. |
kubeReserved.memoryMB |
Kube 예약된 메모리 | Kubernetes 시스템 디먼용으로 예약된 메모리(MiB)입니다. |
hardEvictionThreshold.memoryAvailable |
하드 강제 퇴거: memory.available |
사용 가능한 메모리에 대한 하드 축출 임계값 |
hardEvictionThreshold.nodeFsAvailable |
하드 축출: nodefs.available |
사용 가능한 노드 파일 시스템 공간에 대한 하드 축출 임계값입니다. |
hardEvictionThreshold.nodeFsInodesFree |
하드 축출: nodefs.inodesFree |
사용 가능한 노드 파일 시스템 inode에 대한 하드 축출 임계값입니다. |
softEvictionThreshold.memoryAvailable |
소프트 축출: memory.available |
사용 가능한 메모리에 대한 소프트 축출 임계값입니다. |
softEvictionThreshold.nodeFsAvailable |
소프트 제거: nodefs.available |
사용 가능한 노드 파일 시스템 공간에 대한 소프트 축출 임계값입니다. |
softEvictionThreshold.nodeFsInodesFree |
소프트 축출: nodefs.inodesFree |
여유 노드 파일 시스템 inode에 대한 소프트 축출 임계값입니다. |
softEvictionGracePeriod.memoryAvailable |
소프트 축출: memory.available 유예 기간 |
kubelet이 Pod를 제거하기 전에 사용 가능한 메모리가 소프트 임계값 아래로 유지되어야 하는 기간입니다. |
softEvictionGracePeriod.nodeFsAvailable |
소프트 축출: nodefs.available 유예 기간 |
kubelet이 Pod를 제거하기 전에 사용 가능한 노드 파일 시스템 공간이 소프트 임계값 아래로 유지되어야 하는 기간입니다. |
softEvictionGracePeriod.nodeFsInodesFree |
소프트 축출: nodefs.inodesFree 유예 기간 |
kubelet이 Pod를 제거하기 전에 노드 파일 시스템의 여유 inode가 소프트 임계값 아래로 유지되어야 하는 기간입니다. |
evictionMaxPodGracePeriodInSeconds |
소프트 축출 중 최대 Pod 종료 유예 기간 | 소프트 축출 중에 kubelet에서 Pod를 종료할 수 있는 최대 시간(초)입니다. |
- 각 설정에 허용되는 값, 최소값 및 유효성 검사 규칙은 AKS에 대한 사용자 지정 노드 구성 매개 변수를 참조하세요.
- 각 축출 신호에 대해 소프트 축출 임계값과 이에 대응하는 유예 기간을 모두 설정하고, 각 소프트 축출 임계값이 동일한 신호에 대한 하드 축출 임계값보다 큰지 확인합니다.
사용자 지정하려는 설정을 사용하여 kubelet 구성 파일(예:
nodehardening-kubelet.json)을 만듭니다. 다음 예제에서는 구성 가능한 모든 값을 설정합니다. kube-reserved를 CPU 200밀리코어와 메모리 1,024MiB로 설정합니다. 사용 가능한 메모리의 하드 제거 임계값10%, 사용 가능한 파일 시스템 공간의 하드 제거 임계값5%, 그리고 사용 가능한 inode 수의 하드 제거 임계값512Mi을 설정합니다. 소프트 축출 임계값1Gi,12%, 및7%을 설정하고 유예 기간은 30초, 2분 및 2분으로 설정합니다. 또한 최대 Pod 종료 유예 기간을 60초로 설정합니다.{ "kubeReserved": { "cpuMillicores": 200, "memoryMB": 1024 }, "hardEvictionThreshold": { "memoryAvailable": "512Mi", "nodeFsAvailable": "10%", "nodeFsInodesFree": "5%" }, "softEvictionThreshold": { "memoryAvailable": "1Gi", "nodeFsAvailable": "12%", "nodeFsInodesFree": "7%" }, "softEvictionGracePeriod": { "memoryAvailable": "30s", "nodeFsAvailable": "2m", "nodeFsInodesFree": "2m" }, "evictionMaxPodGracePeriodInSeconds": 60 }--kubelet-config매개 변수와 함께az aks nodepool add명령을 사용하여 구성 파일을 사용하는 Linux 노드 풀을 만듭니다.az aks nodepool add \ --resource-group <resource-group-name> \ --cluster-name <cluster-name> \ --name <node-pool-name> \ --kubelet-config ./nodehardening-kubelet.jsonaz aks create명령과 함께--kubelet-config매개 변수를 사용하여 클러스터의 초기 노드 풀에 구성을 적용할 수도 있습니다.
노드 강화 비활성화
az aks update 명령을 --disable-node-hardening 매개 변수와 함께 사용하여 노드 강화를 사용하지 않도록 설정합니다.
이 명령에는 aks-preview 확장과 CustomNodeConfigPreview 기능 플래그가 필요합니다. 자세한 내용은 전제 조건을 참조하세요.
az aks update \
--resource-group <resource-group-name> \
--name <cluster-name> \
--disable-node-hardening
노드 강화 기능을 비활성화하면 클러스터 수준 설정이 해제되지만 기존 노드는 즉시 변경되지 않습니다. 기존 노드는 예를 들어 노드 이미지 업그레이드 중에 다시 이미징될 때까지 모든 강화된 설정을 유지합니다. 노드가 다시 이미징되면 다음 변경 내용이 적용됩니다.
- 표준 AKS 기본값으로 되돌렸습니다: Kube 예약 및 시스템 예약 리소스, 하드 제거 임계값 및 cgroup 적용. 노드의 할당 가능한 용량이 그에 따라 증가합니다.
- 유지됨: 소프트 축출 임계값, 소프트 축출 유예 기간 및 소프트 축출 중 최대 Pod 종료 유예 기간입니다.
클러스터 또는 노드 풀을 만들 때만 사용자 지정 kubelet 구성을 설정할 수 있으므로 기존 노드 풀에서 유지된 소프트 축출 설정을 제거할 수 없습니다. 제거하려면 해당 설정을 명시적으로 해제하는 새 노드 풀을 만들고, 워크로드를 새 노드 풀로 이동한 다음, 이전 노드 풀을 삭제합니다.
remove-soft-eviction.json와 같은 kubelet 구성 파일을 만듭니다. 다음 예제에서는 모든 소프트 제거 임계값 및 유예 기간을 빈 문자열로 설정하여 해당 신호에 대한 소프트 제거를 해제합니다. 또한 최대 Pod 종료 유예 기간을 표준 AKS 기본값인0(으)로 설정합니다.{ "softEvictionThreshold": { "memoryAvailable": "", "nodeFsAvailable": "", "nodeFsInodesFree": "" }, "softEvictionGracePeriod": { "memoryAvailable": "", "nodeFsAvailable": "", "nodeFsInodesFree": "" }, "evictionMaxPodGracePeriodInSeconds": 0 }--kubelet-config매개 변수와 함께az aks nodepool add명령을 사용하여 구성 파일을 사용하는 Linux 노드 풀을 만듭니다.az aks nodepool add \ --resource-group <resource-group-name> \ --cluster-name <cluster-name> \ --name <node-pool-name> \ --kubelet-config ./remove-soft-eviction.json워크로드를 새 노드 풀로 이동한 다음 이전 노드 풀을 삭제합니다. 자세한 내용은 AKS의 노드 풀 크기 조정을 참조하세요.
노드의 설정을 확인하려면 노드 하드닝 설정 확인을 참조하세요. 새 노드 풀의 노드에서는 evictionSoft가 비어 있습니다.