AKS 클러스터를 관리하고 유지 관리할 때 특정 구성 변경 내용을 변경하려면 노드를 이미지로 다시 설치해야 합니다. 이 이미지 다시 설치 작업은 노드를 다시 만드는 롤링 업데이트를 트리거합니다. 재이미징 작업 중에 AKS는 노드를 코든 처리하여(새 Pod가 스케줄링되지 않도록 함) 기존 Pod를 드레이닝하고(Pod 중단 예산을 준수하면서 이를 축출한 후 다른 사용 가능한 노드에 다시 스케줄링함), 그런 다음 업데이트된 구성으로 노드를 재이미징합니다. 이 프로세스는 재부팅이 아니라 전체 노드 재생성이며, 기반이 되는 VM은 새 OS 이미지로 재이미징됩니다. 올바르게 구성된 영구 볼륨(Azure 디스크, Azure Files 또는 기타 외부 스토리지 사용)은 영향을 받지 않지만 노드의 로컬 임시 스토리지(예: EmptyDir 볼륨 또는 로컬 경로)에 저장된 데이터는 영구적으로 손실됩니다. 이러한 작업은 중요한 업데이트를 적용하는 데 필요하지만 실행 중인 워크로드를 방해하고 애플리케이션 가용성에 영향을 미칠 수 있습니다. 노드 중단 정책을 사용하면 이러한 중단 작업을 진행할 수 있는 시기를 세밀하게 제어할 수 있으므로 업데이트의 필요성과 운영 안정성의 균형을 맞출 수 있습니다.
Important
AKS 미리 보기 기능은 셀프 서비스에서 사용할 수 있습니다(옵트인 방식). 미리 보기는 "있는 그대로" 및 "사용 가능한 상태로" 제공되며 서비스 수준 계약 및 제한적 보증에서 제외됩니다. AKS 미리 보기의 일부는 고객 지원팀에서 최선을 다해 지원합니다. 따라서 이러한 기능은 프로덕션 용도로 사용할 수 없습니다. 자세한 내용은 다음 지원 문서를 참조하세요.
노드 중단 정책이란?
노드 중단 정책은 노드 이미지 다시 설치 및 재배포가 필요한 작업을 실행할 수 있는 시기를 제어하는 클러스터 수준 구성입니다. 제어 게이트 역할을 하므로 다음을 수행할 수 있습니다.
- 서비스 중단을 유발하는 작업을 유지 관리 시간대에 맞추세요.
- 노드 이미지 업그레이드 및 보안 패치를 계속 진행하도록 허용하면서 중요한 비즈니스 기간 동안 구성 변경을 차단합니다.
- 트래픽이 많은 이벤트 중에 예측 가능한 클러스터 동작을 유지 관리합니다.
이 정책은 사용자 지정 CA(인증 기관) 트러스트 인증서 업데이트, 보안 프로필 설정 수정 또는 노드 OS 구성 변경과 같이 노드를 다시 작성해야 하는 사용자 시작 구성 변경에 적용됩니다.
메모
중요한 것은 정책이 노드 이미지 버전 업데이트(채널 포함 SecurityPatch 및 NodeImage 업그레이드) 또는 Kubernetes 버전 업그레이드를 차단하지 않는다는 것입니다. 이러한 작업은 정책이 설정된 Block경우에도 구성된 일정에 따라 계속 진행됩니다. 자세한 내용은 노드 중단 정책에 의해 제어되지 않는 업그레이드 작업을 참조하세요. 또한 특정 복구 작업은 클러스터 상태 및 가용성을 보장하기 위해 이 정책에 의해 제어되지 않습니다. 자세한 내용은 노드 중단 정책에 의해 제어되지 않는 복구 작업을 참조하세요.
노드 중단 정책 작동 방식
속성을 통해 클러스터 수준에서 노드 중단 정책을 구성합니다 nodeDisruptionProfile . 노드 이미지 다시 설치가 필요한 작업을 시도하면 AKS는 현재 정책 설정을 확인합니다.
- 정책 평가: AKS는 현재 정책에 따라 작업이 허용되는지 여부를 평가합니다.
-
유지 관리 기간 검사 (해당하는 경우): 사용하는
AllowDuringMaintenanceWindow경우 AKS는 현재 시간이 구성된 유지 관리 기간 내에 속하는지 여부를 확인합니다. - 작업 실행 또는 차단: 노드 중단 작업은 허용되는 경우 진행되거나 차단된 경우 오류 메시지와 함께 거부됩니다.
정책 옵션
노드 중단 정책은 다음 세 가지 정책 구성을 지원합니다.
| Policy | 설명 | 사용 사례 |
|---|---|---|
Allow |
노드 이미지 다시 설치가 필요한 작업이 언제든지 계속 진행되도록 허용합니다. 기본 동작입니다. | 업데이트 적용의 우선 순위를 빠르게 지정하고 워크로드 중단을 허용할 수 있는 경우에 사용합니다. |
AllowDuringMaintenanceWindow |
aksManagedNodeOSUpgradeSchedule 유지 관리 기간 내에 수행되지 않는 한 노드 재이미지가 필요한 작업을 차단합니다. 구성은 인라인 일정을 사용하거나 공유 유지 관리 시간대에 연결할 수 있습니다. |
운영 일정에 맞는 특정 유지 관리 기간으로 중단을 제한하려는 경우에 사용합니다. |
Block |
노드 이미지 다시 설치가 필요한 모든 작업을 차단합니다. | 중요한 비즈니스 기간 또는 트래픽이 많은 이벤트와 같이 노드 중단을 방지해야 하는 경우에 사용합니다. |
메모
AllowDuringMaintenanceWindow 항목을 사용할 때는 aksManagedNodeOSUpgradeSchedule 유지 보수 기간을 구성해야 합니다. 유지 관리 구성은 일정을 인라인으로 정의하거나 공유 유지 관리 기간을 참조할 수 있습니다. 유지 관리 기간을 설정하는 방법에 대한 자세한 내용은 계획된 유지 관리를 사용하여 Azure Kubernetes Service 클러스터에 대한 업그레이드를 예약하고 제어하는 방법을 참조하세요. 유지 관리 기간을 구성하지 않으면 노드 중단 작업이 허용됩니다.
Considerations
노드 중단 정책을 사용할 때는 다음 사항을 고려해야 합니다.
- 범위: 정책은 AKS 시작 시스템 유지 관리가 아니라 노드 이미지 다시 설치가 필요한 사용자 시작 작업에 적용됩니다. 자세한 내용은 노드 중단 정책에 의해 제어되지 않는 복구 작업을 참조하세요.
- 차단된 작업: 중단 작업이 차단되면 오류 메시지와 함께 API 호출이 실패합니다. 정책을 변경하거나 유지 관리 기간을 기다려야 합니다.
- 긴급 유지 관리: Azure 정책 설정에 관계없이 긴급 또는 중요한 유지 관리 작업을 수행할 수 있는 권리를 보유합니다.
-
업데이트 계획: 특정 클러스터 업데이트를 방지하도록
Block정책 설정 자세한 내용은 노드 중단 정책에서 다루는 작업을 참조하세요. 필요에 따라 필요한 업데이트를 적용할 수 있도록 적절하게 계획합니다. -
유지 관리 기간 종속성:
AllowDuringMaintenanceWindow정책을 사용하려면aksManagedNodeOSUpgradeSchedule유지 관리 기간이 구성되어 있어야 합니다. 자세한 내용은 계획된 유지 관리를 사용하여 Azure Kubernetes Service 클러스터에 대한 업그레이드를 예약하고 제어하는 방법을 참조하세요.
노드 중단 정책에서 다루는 작업
클러스터 수준 작업
네트워크 정책 활성화 및 Azure CNI Overlay 업그레이드
필요한 네트워킹 구성 요소를 설치하고 pod 간 통신을 보호하고 관리하는 네트워크 규칙을 구성하려면 노드를 다시 이미지화해야 합니다.
다음 표에서는 이미지 다시 설치를 트리거하는 네트워크 정책 업그레이드에 대해 간략하게 설명합니다.
| 보낸 사람 | 대상 |
|---|---|
| 없음(네트워크 정책 없음) | Azure 네트워크 정책 |
| 없음(네트워크 정책 없음) | 캘리코 |
| Azure CNI | Azure CNI 오버레이 |
| Azure 네트워크 정책 | 없음(네트워크 정책 없음) |
| 캘리코 | 없음(네트워크 정책 없음) |
메모
Azure와 Calico 네트워크 정책 간에, 둘 중 하나가 이미 사용하도록 설정된 후에도 전환하는 데는 노드 재이미징이 필요하지 않습니다.
노드 OS 업그레이드 채널 변경
각 채널은 실행 중인 노드에서 수정할 수 없는 다른 OS 패치 인프라 및 구성을 사용합니다.
다음 표에서는 이미지 다시 설치를 트리거하는 노드 OS 업그레이드 채널 변경 내용을 간략하게 설명합니다.
| 보낸 사람 | 대상 |
|---|---|
| 비관리 | 없음 |
| 지정되지 않음 | 비관리 |
| 보안 패치 | 비관리 |
| NodeImage | 비관리 |
| 없음 | 비관리 |
| 지정되지 않음 | 비관리 |
| 비관리 | 보안 패치 |
| 비관리 | NodeImage |
IPv6 이중 스택 활성화
이중 스택 통신을 지원하려면 노드에 IPv4 및 IPv6 IP 구성과 네트워킹 스택 업데이트(예: nftables 규칙)가 모두 필요합니다.
다음 표에서는 이미지 다시 설치를 트리거하는 IP 구성 및 네트워킹 스택 업데이트를 간략하게 설명합니다.
| 보낸 사람 | 대상 |
|---|---|
| IPv4만 | IPv4 + IPv6(이중 스택) |
Cilium 데이터 평면 변경 내용
커널 수준에서 패킷 처리를 처리하는 eBPF 프로그램을 설치하거나 제거해야 합니다.
다음 표에서는 이미지 다시 설치를 트리거하는 Cilium 데이터 평면 변경 내용을 간략하게 설명합니다.
| 보낸 사람 | 대상 |
|---|---|
| 없음 | 실륨(Cilium) |
| 실륨(Cilium) | 없음 |
HTTP 프록시 구성 업데이트
모든 노드 구성 요소(컨테이너, kubelet, 시스템 서비스)에는 시스템 전체에 적용된 업데이트된 프록시 구성이 필요합니다. HTTP 프록시 구성을 업데이트하면 AKS는 클러스터의 모든 노드 풀을 자동으로 이미지로 다시 설치합니다.
다음 HTTP 프록시 구성 속성을 수정하거나 다음 작업 중 하나를 수행하면 노드 중단 정책이 재이미징을 트리거합니다.
-
httpProxy: HTTP 연결에 대한 프록시 URL -
httpsProxy: HTTPS 연결에 대한 프록시 URL -
noProxy: 프록시에서 제외할 대상 목록 -
trustedCa: Base64로 인코딩된 대체 CA 인증서 - 클러스터에서 HTTP 프록시 활성화(
--enable-http-proxy사용) - 클러스터에서 HTTP 프록시 비활성화(
--disable-http-proxy사용) - 이전에 사용하지 않도록 설정한 클러스터에서 다시 활성화 가능한 HTTP 프록시
사용자 지정 CA 인증서 업데이트
내부 서비스 및 프라이빗 레지스트리에 대한 TLS 유효성 검사에 영향을 주려면 OS 트러스트 저장소에 새 CA 인증서를 설치해야 합니다.
노드 중단 정책은 사용자 지정 CA 인증서를 추가, 제거 또는 업데이트할 때 이미지 다시 설치를 트리거 합니다.
Kubelet ID 변경
노드 구성에 새 ID 자격 증명을 적용해야 합니다. 여기에는 초기 ID 할당, ID 업데이트 및 서비스 주체 프로필 재설정이 포함됩니다.
노드 중단 정책은 kubelet의 관리 ID 또는 사용자 할당 관리 ID를 업데이트할 때 재이미징을 유발합니다.
프라이빗 DNS 영역 변경 사항
새 DNS 영역을 사용하여 프라이빗 API 서버 엔드포인트를 확인하려면 DNS 확인자 설정을 업데이트해야 합니다.
노드 중단 정책은 프라이빗 클러스터에서 프라이빗 DNS 영역 구성을 수정할 때 이미지 다시 설치를 트리거 합니다.
API Server VNet 통합 활성화
위임된 서브넷에 프로젝트되는 내부 부하 분산 장치 IP를 통해 API 서버와 통신하도록 노드를 다시 구성해야 합니다.
노드 중단 정책은 이전에 사용하지 않은 기존 클러스터에서 API Server VNet 통합을 사용하도록 설정할 때 이미지 다시 설치를 트리거 합니다. 이 변경은 apiServerAccessProfile.enableVnetIntegration 속성(내부적으로는 privateConnectProfile.enabled 필드)을 false(또는 설정되지 않은 상태)에서 true(으)로 변경하는 것에 해당합니다:
| 보낸 사람 | 대상 |
|---|---|
apiServerAccessProfile.enableVnetIntegration: false 또는 미설정 |
apiServerAccessProfile.enableVnetIntegration: true |
eBPF 호스트 라우팅 변경 내용
고성능 패킷 전달(BpfVeth 가속 모드)을 제공하는 eBPF 프로그램을 설치하거나 제거해야 합니다.
다음 표에서는 이미지 다시 설치를 트리거하는 eBPF 호스트 라우팅 변경 내용을 간략하게 설명합니다.
| 보낸 사람 | 대상 |
|---|---|
| 표준 라우팅 | eBPF 호스트 라우팅 사용 |
| eBPF 호스트 라우팅 사용 | 표준 라우팅 |
노드 풀 수준 작업
이러한 작업은 변경한 특정 노드 풀에만 영향을 줍니다. 해당 노드 풀 내에서 롤링 재이미징을 시작합니다.
로컬 DNS 프로필 업데이트
노드 수준에서 DNS 캐싱 디먼 및 DNS 전달 규칙에 변경 내용을 적용해야 합니다.
노드 중단 정책은 LocalDNS 프로필 구성을 수정할 때 이미지 다시 설치를 트리거 합니다.
신뢰할 수 있는 시작 보안 변경 내용
실행 중인 VM에서 VM 펌웨어 구성 및 부팅 프로세스 설정을 변경할 수 없습니다. 이러한 변경 내용을 사용하려면 VM을 다시 만들어야 합니다.
다음 표에서는 이미지 다시 설치를 트리거하는 신뢰할 수 있는 시작 보안 변경 내용을 간략하게 설명합니다.
| 구성 / 설정 | 보낸 사람 | 대상 |
|---|---|---|
| vTPM(가상 신뢰할 수 있는 플랫폼 모듈) | Disabled | 활성화됨 |
| vTPM(가상 신뢰할 수 있는 플랫폼 모듈) | 활성화됨 | Disabled |
| 보안 부팅 | Disabled | 활성화됨 |
| 보안 부팅 | 활성화됨 | Disabled |
아티팩트 스트리밍 변경 내용
주문형 이미지 계층을 스트리밍하여 더 빠른 컨테이너 이미지를 끌어낼 수 있도록 아티팩트 스트리밍 구성 요소를 설치하거나 제거해야 합니다.
다음 표에서는 이미지 다시 설치를 트리거하는 아티팩트 스트리밍 변경 내용을 간략하게 설명합니다.
| 보낸 사람 | 대상 |
|---|---|
| Disabled | 활성화됨 |
| 활성화됨 | Disabled |
Windows GMSA 프로필 업데이트(Windows 노드 풀만 해당)
Windows 노드에서 Active Directory 통합하려면 새 GMSA 설정, DNS 서버 구성 및 도메인 조인 자격 증명을 적용해야 합니다.
노드 중단 정책은 GMSA 변경으로 인해 새 노드 구성을 적용해야 하는 경우 Windows 노드 풀을 다시 이미지화하도록 트리거합니다.
| 보낸 사람 | 대상 | 재이미징을 시작함 |
|---|---|---|
| GMSA 사용 안 함 | GMSA 사용하도록 설정됨 | 예 |
| GMSA 활성화됨(DNS 서버 / 루트 도메인 설정 또는 변경됨) | 업데이트된 DNS 서버 또는 루트 도메인으로 사용하도록 설정된 GMSA | 예 |
| GMSA 활성화됨(DNS 서버 설정됨) | GMSA 사용 안 함 | 예 |
| GMSA 사용 설정됨(DNS 서버가 설정되지 않음) | GMSA 사용 안 함 | 아니요(적용할 노드 구성 없음) |
용량 예약 그룹 첨부 파일
CRG(용량 예약 그룹)의 예약된 용량에서 할당되도록 기본 VM을 다시 만들어야 합니다. 기존 노드는 CRG를 기준으로 프로비전되지 않았으므로, AKS는 해당 노드를 예약에 연결하기 위해 노드 풀을 다시 이미징해야 합니다.
노드 중단 정책은 용량 예약 그룹을 아직 없는 기존 노드 풀에 연결할 때 이미지 다시 설치를 트리거 합니다.
| 보낸 사람 | 대상 | 재이미징을 시작함 |
|---|---|---|
| 연결된 용량 예약 그룹 없음 | 용량 예약 그룹 연결됨 | 예 |
Kubernetes 1.37 이상에서 노드 중단 정책에서 다루는 작업
Kubernetes 1.37 이상에서 노드 중단 정책은 노드를 이미지로 다시 설치해야 하는 다음과 같은 구성 변경 내용을 다룹니다. Kubernetes 1.36 및 이전 버전에서는 이러한 구성 변경을 수행한 후 변경 사항을 노드에 적용하려면 --node-image-only과 함께 az aks nodepool upgrade를 수동으로 실행해야 합니다.
- SSH 구성 변경: SSH 액세스 방법 변경(SSH 사용 안 함, Entra ID 기반 SSH 또는 로컬 사용자 SSH) 또는 노드 풀에서 SSH 공개 키 업데이트
- IMDS 제한 변경: IMDS 엔드포인트에 대한 Pod 액세스를 차단하기 위해 IMDS(인스턴스 메타데이터 서비스) 제한을 사용하거나 사용하지 않도록 설정합니다.
-
부트스트랩 프로필 변경: 부트스트랩 프로필 변경(예: 네트워크
artifactSource에 사용되는 Azure Container Registry)Direct을 변경CachecontainerRegistryId합니다. - 아웃바운드 유형 변경: 클러스터의 아웃바운드 연결 유형(loadBalancer, userDefinedRouting, managedNATGateway 또는 userAssignedNATGateway) 수정
노드 중단 정책에 의해 제어되지 않는 업그레이드 작업
노드 중단 정책은 다음 업그레이드 작업을 제어하지 않습니다 . 이러한 업그레이드 작업은 정책 설정에 관계없이 진행됩니다. 업그레이드는 고객이 시작하거나, 계획된 유지 관리 기간 내에 AKS가 시작합니다. 이러한 작업이 예약된 대로 계속 진행되도록 하려면 의도적으로 노드 중단 정책 범위를 벗어나지 않도록 합니다. 또한 노드 중단 정책에서 다루는 작업이 업그레이드와 함께 동일한 구성 변경 내용에 포함된 경우 노드 중단 정책에 의해 제어되지 않습니다.
- 노드 이미지 버전 업데이트: 새 노드 OS 이미지 버전으로 업그레이드(수동 또는 자동 업그레이드 채널을 통해) 이 작업은 가장 일반적인 이미지 다시 설치 작업이며 보안 패치, OS 업데이트 및 AKS 노드 이미지 릴리스를 포함합니다.
- Kubernetes 버전 업그레이드: 새 Kubernetes 이진 파일, 업데이트된 kubelet 구성 및 OS 수준 변경 내용을 적용하는 노드 풀에서 Kubernetes 버전을 업그레이드합니다.
노드 중단 정책에 의해 제어되지 않는 복구 작업
노드 중단 정책은 다음과 같은 자동화된 복구 작업을 제어하지 않습니다 . 이러한 작업은 클러스터 상태 및 복구를 보장하기 위해 정책 설정에 관계없이 발생할 수 있습니다.
- 노드 풀 구성 롤백: 잘못된 구성 또는 인프라 문제로 인해 노드 풀 업데이트 작업이 실패하면 AKS는 마지막으로 알려진 정상 상태로 자동으로 롤백되고 구성을 되돌리기 위해 노드를 이미지로 다시 설치합니다.
- 관리자 클러스터 복원 작업: Azure 지원 엔지니어가 인시던트 해결 중에 관리 클러스터 복원을 수행하는 경우 노드가 이미지로 다시 설치되어 컨트롤 플레인 상태와 노드 구성 간의 일관성을 보장합니다.
- 노드 ID 자격 증명 업데이트: AKS는 보안 및 규정 준수를 위해 노드 ID 자격 증명을 주기적으로 업데이트합니다. 이러한 시스템 시작 업데이트는 노드 이미지 다시 설치를 트리거하여 모든 노드 풀에 새 자격 증명을 적용합니다.
계획된 유지 관리와의 통합
노드 중단 정책은 AKS 예약된 유지 관리 기간과 원활하게 연동됩니다. 정책을 AllowDuringMaintenanceWindow설정하면 중단 작업이 aksManagedNodeOSUpgradeSchedule 유지 관리 기간과 일치합니다. 일정은 인라인으로 또는 공유 유지 관리 기간에 연결할 수 있습니다. 이 통합은 다음을 보장합니다.
- 변경 내용은 승인된 시간 기간 동안에만 발생합니다.
- 작업은 다른 예약된 유지 관리와 조정됩니다.
- 팀은 중단이 발생할 수 있는 시기를 알고 있습니다.
이 통합은 클러스터 변경 내용을 관리하고 실행 중인 워크로드에 미치는 영향을 최소화하는 포괄적인 접근 방식을 제공합니다.
메모
AllowDuringMaintenanceWindow 항목을 사용할 때는 aksManagedNodeOSUpgradeSchedule 유지 보수 기간을 구성해야 합니다.
default 유지 관리 기간 또는 aksManagedAutoUpgradeSchedule (클러스터 자동 업그레이드) 사용은 이 요구 사항을 충족하지 않습니다.
aksManagedNodeOSUpgradeSchedule 공유 유지 관리 기간에 연결된 구성은 이 요구 사항을 분명히 충족합니다.
AllowDuringMaintenanceWindow 창을 구성하지 않은 상태에서 aksManagedNodeOSUpgradeSchedule를 설정하면 모든 서비스 중단 작업이 허용됩니다(정책에서 제한할 창이 없기 때문입니다). 유지 관리 기간을 설정하는 방법에 대한 자세한 내용은 계획된 유지 관리를 사용하여 Azure Kubernetes Service 클러스터에 대한 업그레이드를 예약하고 제어하는 방법을 참조하세요.
모범 사례
노드 중단 정책을 구현할 때 다음 권장 사항을 고려합니다.
-
프로덕션에 사용
AllowDuringMaintenanceWindow: 계획된 유지 관리 기간과 결합하여 프로덕션 환경에서 중단이 발생하는 시기를 제어합니다. -
중요한 기간 동안 설정
Block: 트래픽이 많은 이벤트, 제품 출시 또는 인시던트 대응 중에 중단 작업을 일시적으로 차단합니다.Block을(를) 무기한으로 사용하지 마세요.Block단기 동결(계획된 이벤트, 인시던트 대응)에 적합합니다. -
비프로덕션의 유연성 허용: 빠른 반복이 안정성보다 더 중요한 개발 및 테스트 환경에서 사용합니다
Allow. - 정책 변경 내용 전달: 팀에서 현재 정책을 이해하고 작업이 차단될 수 있는 시기를 알고 있는지 확인합니다.
- 적절한 유지 관리 기간 계획: 수행해야 하는 작업을 수용하도록 유지 관리 기간을 조정합니다.
- 테스트 정책 동작: 프로덕션 클러스터에 적용하기 전에 비프로덕션 환경에서 정책 설정의 유효성을 검사합니다.
- 차단된 작업 모니터링: 유지 관리 일정을 최적화하기 위해 작업이 차단되는 시기를 추적합니다.
관련 콘텐츠
- 노드 중단 정책을 구성하는 방법을 알아봅니다.
- AKS에서 계획된 유지 관리를 이해합니다.