AKS 질문과 대답

이 문서는 Azure Kubernetes Service(AKS)에 대한 가장 일반적인 질문 중 일부에 대한 답변을 제공합니다.

지원

AKS는 서비스 수준 계약(SLA)을 제공합니까?

AKS는 Uptime SLA 기능이 포함된 Standard 요금제에서 서비스 수준 계약(SLA) 보장을 제공합니다.

플랫폼 지원이란 무엇이며, 무엇을 포함하나요?

플랫폼 지원은 지원되지 않는 n-3 버전 클러스터에 대한 축소된 지원 계획입니다. 플랫폼 지원에는 Azure 인프라 지원만 포함됩니다.

자세한 내용은 플랫폼 지원 정책을 참조하세요.

AKS는 지원되지 않는 클러스터를 자동으로 업그레이드합니까?

예, AKS는 지원되지 않는 클러스터에 대해 자동 업그레이드를 시작합니다. 클러스터가 n-3 버전(여기서 n은 일반적으로 제공되는 최신 지원 AKS 마이너 버전)에서 n-4로 내려가려고 할 때, AKS는 지원 정책을 유지하기 위해 클러스터를 자동으로 n-2로 업그레이드합니다.

자세한 내용은 지원되는 Kubernetes 버전, 예정된 유지 관리 기간, 자동 업그레이드를 참조하세요.

AKS 에이전트 노드에 Azure 예약 할인을 적용할 수 있나요?

AKS 에이전트 노드는 표준 Azure 가상 머신(VM)으로 요금이 부과됩니다. AKS에서 사용하는 VM 크기에 대해 Azure 예약을 구매한 경우, 해당 할인은 자동으로 적용됩니다.

작업

AKS에서 Windows Server 컨테이너를 실행할 수 있습니까?

예, AKS는 Windows Server 컨테이너도 지원합니다. 자세한 내용은 AKS FAQ에서 Windows Server를 참조하세요.

AKS에서 지원되는 Linux OS(운영 체제)는 무엇인가요?

AKS는 Ubuntu Linux, Azure Linux, Azure Linux OS Guard 및 AKS용 Flatcar Container Linux를 비롯한 4개의 주요 Linux 운영 체제를 지원합니다. 노드 풀 생성 또는 클러스터 --os-type Linux 생성 시 지정할 경우 기본 OS는 Ubuntu Linux입니다.

AKS에서 지원되는 OS(운영 체제) 버전은 무엇인가요?

사용하는 --os-sku Ubuntu경우 AKS는 Kubernetes 버전 1.25-1.34에서 기본적으로 Ubuntu 22.04로 설정됩니다. AKS는 Kubernetes 버전 1.35 이상에서 기본적으로 Ubuntu 24.04로 설정됩니다. 사용하는 --os-sku AzureLinux경우 AKS는 Kubernetes 버전 1.32 이상에서 기본적으로 Azure Linux 3.0으로 설정됩니다. FIPS 사용 노드 풀과 같은 일부 시나리오에서는 기본 OS 버전이 다를 수 있습니다. 자세한 내용은 노드 이미지를 참조하세요.

클러스터를 Azure 테넌트 간에 이동하거나 마이그레이션할 수 있습니까?

아니요. 테넌트 간에 AKS 클러스터를 이동하는 것은 현재 지원되지 않습니다.

클러스터를 구독 간에 이동하거나 마이그레이션할 수 있습니까?

아니요. AKS 클러스터를 구독 간에 이동하는 것은 현재 지원되지 않습니다.

AKS 클러스터 또는 AKS 인프라 리소스를 다른 리소스 그룹으로 이동하거나 이름을 변경할 수 있습니까?

아니요. AKS 클러스터 및 연결된 리소스를 이동하거나 이름을 바꾸는 것은 지원되지 않습니다.

클러스터를 삭제한 후 복원할 수 있나요?

아니요. 클러스터를 삭제한 후에는 복원할 수 없습니다. 클러스터를 삭제하면 노드 리소스 그룹과 그 안의 모든 리소스도 함께 삭제됩니다.

리소스를 유지하려면 클러스터를 삭제하기 전에 다른 리소스 그룹으로 이동하십시오. 실수로 인한 삭제로부터 보호하려는 경우 노드 리소스 그룹 잠금을 사용하여 클러스터 리소스를 호스팅하는 AKS 관리 되는 리소스 그룹을 잠글 수 있습니다.

AKS 클러스터를 0으로 스케일할 수 있습니까?

실행 중인 AKS 클러스터를 완전히 중지하거나 모든 또는 특정 노드 풀User을 스케일 또는 자동 스케일하여 0으로 설정할 수 있습니다.

시스템 노드 풀을 0으로 직접 조정할 수 없습니다.

수동으로 스케일링하기 위해 가상 머신 스케일 세트 API를 사용할 수 있습니까?

아니요. 가상 머신 스케일 세트 API를 사용하는 스케일 작업은 지원되지 않습니다. AKS API(az aks scale)를 사용할 수 있습니다.

가상 머신 스케일 세트를 사용하여 노드를 0으로 수동 스케일링할 수 있습니까?

아니요. 가상 머신 스케일 세트 API를 사용하는 스케일 작업은 지원되지 않습니다. AKS API를 사용하여 비시스템 노드 풀을 0으로 확장하거나 클러스터를 중지할 수 있습니다.

모든 가상 머신(VM)을 중지하거나 할당 해제할 수 있나요?

아니요. 이 구성은 지원되지 않습니다. 대신 클러스터를 중지하세요.

AKS에서 두 개의 리소스 그룹이 생성되는 이유는 무엇인가요?

AKS는 가상 머신 확장 집합, 가상 네트워크 및 Managed Disks를 포함하는 여러 Azure 인프라 리소스를 기준으로 합니다. 이 통합 기능을 통해 AKS에서 제공하는 관리형 Kubernetes 환경 내에서 Azure 플랫폼의 핵심 기능 중 많은 부분을 적용할 수 있습니다. 예를 들어, 대부분의 Azure VM 유형을 AKS와 직접 사용할 수 있으며, Azure 예약을 통해 해당 리소스에 대한 할인을 자동으로 받을 수 있습니다.

이 아키텍처를 활성화하려면, 각 AKS 배포는 두 개의 리소스 그룹에 걸쳐 있습니다.

1. 첫 번째 리소스 그룹을 생성합니다. 이 그룹에는 Kubernetes 서비스 리소스만 포함됩니다. AKS 리소스 공급자는 배포 중에 두 번째 리소스 그룹을 자동으로 생성합니다. 두 번째 리소스 그룹의 예는 MC_myResourceGroup_myAKSCluster_eastus입니다. 이 두 번째 리소스 그룹의 이름을 지정하는 방법에 대한 자세한 내용은 다음 섹션을 참조하세요.
2. 노드 리소스 그룹으로 알려져 있는 두 번째 리소스 그룹에는 클러스터와 연결된 인프라 리소스의 모든 항목이 포함됩니다. 이러한 리소스에는 Kubernetes 노드 VM, 가상 네트워킹 및 스토리지가 포함됩니다. 기본적으로 노드 리소스 그룹에는 MC_myResourceGroup_myAKSCluster_eastus와 같은 이름이 지정됩니다. AKS는 클러스터를 삭제할 때 노드 리소스 그룹을 자동으로 삭제합니다. 이 리소스 그룹은 클러스터의 수명 주기를 공유하는 리소스에만 사용하세요.

참고

AKS 클러스터의 노드 리소스 그룹에 있는 리소스를 수정하는 것은 지원되지 않는 작업이며, 클러스터 작업 실패를 초래할 수 있습니다. 노드 리소스 그룹에 대한 변경이 이루어지지 않도록 설정할 수 있습니다. 사용자가 AKS 클러스터에서 관리하는 리소스를 수정하지 못하도록 차단합니다.

AKS 노드 리소스 그룹에 고유한 이름을 지정할 수 있나요?

기본적으로 AKS는 노드 리소스 그룹 이름을 MC_resourcegroupname_clustername_location로 지정하지만, 사용자가 직접 이름을 지정할 수 있습니다.

고유한 리소스 그룹 이름을 지정하려면 aks-preview Azure CLI 확장 버전 0.3.2 이상을 설치합니다. az aks create 명령을 사용하여 AKS 클러스터를 만들 때 --node-resource-group 매개 변수를 사용하고 리소스 그룹의 이름을 지정합니다. AKS 클러스터를 배포할 때 Azure Resource Manager 템플릿을 사용하는 경우, nodeResourceGroup속성을 사용하여 리소스 그룹 이름을 정의할 수 있습니다.

• Azure 리소스 공급자가 두 번째 리소스 그룹을 자동으로 생성합니다.
• 클러스터를 생성할 때만 사용자 지정 리소스 그룹 이름을 지정할 수 있습니다.

노드 리소스 그룹을 사용할 때 다음을 수행할 수 없습니다.

• 노드 리소스 그룹에 기존 리소스 그룹을 지정할 수 없습니다.
• 노드 리소스 그룹에 다른 구독을 지정할 수 없습니다.
• 클러스터를 생성한 후에 노드 리소스 그룹 이름을 변경할 수 없습니다.
• 노드 리소스 그룹 내 관리되는 리소스의 이름을 지정할 수 없습니다.
• 노드 리소스 그룹 내 관리되는 리소스의 Azure 생성 태그를 수정하거나 삭제할 수 없습니다.

노드 리소스 그룹에서 태그 및 AKS 리소스의 다른 속성을 수정할 수 있나요?

노드 리소스 그룹에서 Azure가 생성한 태그나 기타 리소스 속성을 수정하거나 삭제하면 예기치 않은 확장 및 업그레이드 오류가 발생할 수 있습니다. AKS를 사용하면 최종 사용자가 만든 사용자 지정 태그를 만들고 수정할 수 있으며 노드 풀을 만들 때 이러한 태그를 추가할 수 있습니다. 예를 들어, 비즈니스 부서나 비용 센터를 지정하기 위해 사용자 지정 태그를 생성하거나 수정하고 싶을 수 있습니다. 또 다른 옵션은 특히 클러스터 및 노드 풀을 통해 AKS 리소스 자체를 통해 정책을 적용하고 태그를 수정하는 것입니다.

Azure에서 생성한 태그는 각 Azure 서비스에 대해 생성되며, 항상 허용해야 합니다. AKS의 경우 aks-managed 태그와 k8s-azure 태그가 있습니다. AKS 클러스터의 노드 리소스 그룹에서 리소스에 대해 Azure로 만든 태그를 수정하는 작업은 지원되지 않으며, 이러한 작업은 SLO(서비스 수준 목표)를 중단하게 됩니다.

참고

과거에는 태그 이름이 Owner 부하 분산 장치의 프런트 엔드 IP에 할당된 공용 IP를 관리하기 위해 AKS에 예약되었습니다. 이제 서비스는 접두사를 aks-managed 사용합니다. 레거시 리소스의 경우 Azure 정책을 사용하여 Owner 태그 이름을 적용 하지 마세요. 그렇지 않으면 AKS 클러스터의 모든 리소스 배포 및 업데이트 작업이 중단됩니다. 이 제한은 새로 생성된 리소스에는 적용되지 않습니다.

클러스터에서 aks-managed 접두사가 붙은 Helm 릴리스를 보는 이유와 리비전 수가 계속 증가하는 이유는 무엇인가요?

AKS는 클러스터에 구성 요소를 전달하기 위해 Helm을 사용합니다. aks-managed 접두사 Helm 릴리스를 무시해도 됩니다. 이 Helm 릴리스에서 지속적으로 증가하는 리비전은 예상되는 현상이며 안전합니다.

할당량, 제한, 및 지역 가용성

현재 AKS를 제공하는 Azure 지역은 어디인가요?

사용 가능한 지역의 전체 목록은 AKS 지역 및 가용성을 참조하세요.

AKS 클러스터를 여러 지역에 걸쳐 배포할 수 있나요?

아니요. AKS 클러스터는 지역 리소스로, 여러 지역에 걸쳐 있을 수 없습니다. 여러 지역을 포함하는 아키텍처를 만드는 방법에 대한 지침은 비즈니스 연속성 및 재해 복구에 대한 모범 사례를 참조하세요.

AKS 클러스터를 여러 가용 영역에 걸쳐 배포할 수 있나요?

예, 지원하는 지역에 있는 하나 이상의 가용성 영역에서 AKS 클러스터를 배포할 수 있습니다.

하나의 클러스터에서 서로 다른 VM 크기를 사용할 수 있나요?

예, 여러 노드 풀을 만들어 AKS 클러스터에서 다른 VM 크기를 사용할 수 있습니다.

AKS에서 컨테이너 이미지의 크기 제한은 얼마인가요?

AKS는 컨테이너 이미지 크기에 대해 제한을 설정하지 않습니다. 그러나 이미지가 클수록 메모리 요구량이 높아집니다. 큰 크기는 잠재적으로 리소스 한도나 워커 노드의 전체 사용 가능한 메모리를 초과할 수 있습니다. 기본적으로 AKS 클러스터의 VM 크기 Standard_DS2_v2 메모리는 7GiB로 설정됩니다.

컨테이너 이미지가 테라바이트(TB) 단위처럼 지나치게 큰 경우, 디스크 공간 부족으로 인해 kubelet이 컨테이너 레지스트리에서 노드로 이미지를 가져오지 못할 수 있습니다.

Windows Server 노드의 경우, Windows Update가 자동으로 실행되어 최신 업데이트를 적용하지 않습니다. AKS 클러스터에서 클러스터와 Windows Server 노드 풀을 업그레이드해야 합니다. Windows Update 릴리스 주기와 자체 검증 프로세스를 기반으로 정기적인 일정에 따라 진행하세요. 이 업그레이드 프로세스는 최신 Windows Server 이미지와 패치를 실행하는 노드를 생성한 후, 이전 노드를 제거합니다. 이 프로세스에 대한 자세한 내용은 AKS에서 노드 풀 업그레이드를 참조하세요.

AKS 이미지가 루트로 실행되어야 하나요?

다음 이미지들은 루트 권한으로 실행되어야 하는 기능적 요구 사항이 있으며, 모든 정책에 대해서는 예외를 신청해야 합니다.

• mcr.microsoft.com/oss/kubernetes/coredns
• mcr.microsoft.com/azuremonitor/containerinsights/ciprod
• mcr.microsoft.com/oss/calico/node
• mcr.microsoft.com/oss/kubernetes-csi/azuredisk-csi

보안, 접근, 및 식별

Kubernetes API 서버에 대한 접근 권한을 제한할 수 있나요?

예, API 서버에 대한 접근을 제한하는 두 가지 옵션이 있습니다.

• API 서버에 대한 퍼블릭 엔드포인트를 유지하지만 신뢰할 수 있는 IP 범위 세트로 액세스를 제한하려는 경우 API Server 권한 있는 IP 범위를 사용합니다.
• API 서버를 가상 네트워크 내에서만 액세스할 수 있도록 제한하려는 경우 프라이빗 클러스터를 사용합니다.

AKS 에이전트 노드에 보안 업데이트가 적용되나요?

AKS는 매주 공급업체 픽스가 있는 CVE를 패치합니다. 수정되지 않은 CVE는 벤더의 수정이 적용되기 전까지 해결할 수 없습니다. AKS 이미지는 30일 이내에 자동으로 업데이트됩니다. 최신 패치가 적용된 이미지와 운영 체제 패치가 모두 최신 상태로 유지되도록, 정기적으로 업데이트된 노드 이미지를 적용하는 것을 권장합니다. 다음 작업을 수행할 수 있습니다.

• 수동으로, Azure 포털 또는 Azure CLI를 통해 수행할 수 있습니다.
• AKS 클러스터를 업그레이드하여. 클러스터는 코돈 및 드레이닝 노드를 자동으로 업그레이드합니다. 그런 다음 최신 Ubuntu 이미지와 새로운 패치 버전 또는 마이너 Kubernetes 버전을 가진 새 노드를 온라인으로 가져옵니다. 자세한 내용은 AKS 클러스터 업그레이드를 참조하세요.
• 노드 이미지 업그레이드를 사용합니다.

AKS를 대상으로 하는 보안 위협이 있나요, 알아야 할 사항이 있나요?

Microsoft는 컨테이너용 Microsoft Defender와 같은 서비스를 통해 워크로드를 보호하기 위해 수행할 수 있는 추가 작업에 대한 지침을 제공합니다. AKS 및 Kubernetes와 관련된 보안 위협에 대한 자세한 내용은 새로운 대규모 캠페인 대상 Kubeflow (2021년 6월 8일)를 참조하세요.

AKS가 클러스터 지역 외부에 고객 데이터를 저장하나요?

아니요. 모든 데이터는 클러스터가 위치한 지역에 저장됩니다.

볼륨에 많은 파일이 있을 때 권한 소유 설정 지연 문제를 어떻게 피할 수 있나요?

전통적으로, 파드가 비루트 사용자로 실행되는 경우(그렇게 해야 하며), 파드가 볼륨을 읽고 쓸 수 있도록 하기 위해 파드의 보안 컨텍스트 안에 fsGroup 매개변수를 지정해야 합니다. 이 요구 사항에 대한 자세한 내용은 Pod 또는 컨테이너에 대한 보안 컨텍스트 구성을 참조하세요.

설정 fsGroup 의 부작용은 볼륨이 탑재될 때마다 Kubernetes가 볼륨 내의 모든 파일 및 디렉터리에 대해 재귀적으로 명령과 chown() 명령을 사용해야 chmod() 한다는 것입니다(몇 가지 예외 제외). 이 시나리오는 볼륨의 그룹 소유권이 이미 요청된 fsGroup 매개 변수와 일치하는 경우에도 발생합니다. 이 구성은 많은 작은 파일을 포함한 대용량의 경우 비용이 많이 들 수 있으며, 이로 인해 파드 시작 시간이 길어질 수 있습니다. 이 시나리오는 v1.20 이전에 알려진 문제였습니다. 해결 방법은 파드를 루트 권한으로 실행하도록 설정하는 것입니다.

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

이 문제는 Kubernetes 버전 1.20에서 해결되었습니다. 자세한 내용은 Kubernetes 1.20: 볼륨 권한 변경에 대한 세분화된 제어를 참조하세요.

네트워킹

관리형 컨트롤 플레인이 내 노드와 어떻게 통신하나요?

AKS는 보안 터널 통신을 사용하여 api-server 및 개별 노드 kubelets가 별도의 가상 네트워크에서도 통신할 수 있도록 합니다. 터널은 상호 전송 계층 보안(TLS) 암호화를 통해 보호됩니다. AKS에서 사용되는 현재 주 터널은 이전에 apiserver-network-proxy로 알려진 Konnectivity입니다. 모든 네트워크 규칙이 Azure 필수 네트워크 규칙 및 FQDN(정규화된 도메인 이름)을 따르는지 확인합니다.

내 파드가 클러스터 IP 대신 API 서버 FQDN을 사용할 수 있나요?

예, Pod에 kubernetes.azure.com/set-kube-service-host-fqdn 주석을 추가하여 KUBERNETES_SERVICE_HOST 변수를 클러스터 내 서비스 IP 대신 API 서버의 도메인 이름으로 설정할 수 있습니다. 이 수정은 클러스터가 레이어 7 방화벽을 통해 외부로 나가는 경우에 유용합니다. 예를 들어, Azure Firewall을 애플리케이션 규칙과 함께 사용할 때입니다.

AKS를 통해 NSG를 구성할 수 있나요?

AKS는 서브넷에 네트워크 보안 그룹(NSG)을 적용하지 않으며, 해당 서브넷과 연결된 NSG를 수정하지도 않습니다. AKS는 네트워크 인터페이스의 NSG 설정만 수정합니다. Container Network Interface(CNI)를 사용하는 경우, NSG의 보안 규칙이 노드와 파드의 CIDR 범위 간 트래픽을 허용하도록 설정되어 있는지 확인해야 합니다. kubenet을 사용하는 경우, NSG의 보안 규칙이 노드와 파드 CIDR 간 트래픽을 허용하도록 설정되어 있는지 확인해야 합니다. 자세한 내용은 네트워크 보안 그룹을 참조하세요.

AKS에서 시간 동기화는 어떻게 작동하나요?

AKS 노드는 로컬 호스트에서 시간을 끌어오는 chrony 서비스를 실행합니다. Pod에서 실행되는 컨테이너는 AKS 노드에서 시간을 얻습니다. 컨테이너 내에서 시작된 애플리케이션은 Pod의 컨테이너에서 시간을 사용합니다.

추가 기능, 확장 및 기타 통합

사용자 지정 VM 확장을 사용할 수 있나요?

아니요. AKS는 관리형 서비스입니다. IaaS(Infrastructure as a Service) 리소스 조작은 지원되지 않습니다. 사용자 지정 구성 요소를 설치하려면 Kubernetes API 및 메커니즘을 사용하세요. 예를 들어 DaemonSets를 사용하여 필요한 구성 요소를 설치합니다.

AKS가 지원하는 Kubernetes 허용 컨트롤러는 무엇인가요? 허용 컨트롤러를 추가하거나 제거할 수 있나요?

AKS는 다음과 같은 허용 컨트롤러를 지원합니다.

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultIngressClass
• DefaultStorageClass
• DefaultTolerationSeconds
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook
• ResourceQuota
• PodNodeSelector
• PodTolerationRestriction
• ExtendedResourceToleration

현재, AKS에서 허용 컨트롤러 목록을 수정할 수 없습니다.

AKS에서 허용 컨트롤러 Webhook를 사용할 수 있나요?

예, AKS에서 허용 컨트롤러 웹후크를 사용할 수 있습니다. 레이블로 표시된 control-plane 내부 AKS 네임스페이스를 제외하는 것이 좋습니다. 예를 들어:

namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist

AKS는 API 서버의 아웃바운드를 방화벽으로 보호하므로, 어드미션 컨트롤러 웹후크는 클러스터 내부에서 접근 가능해야 합니다.

어드미션 컨트롤러 웹후크가 kube-system 및 내부 AKS 네임스페이스에 영향을 줄 수 있나요?

시스템의 안정성을 보호하고 kube-system 네임스페이스에서 사용자 지정 승인 컨트롤러가 내부 서비스에 영향을 주는 것을 방지하기 위해, AKS에는 승인 강제기가 있으며, 이는 kube-system 및 AKS 내부 네임스페이스를 자동으로 제외합니다. 이 서비스는 사용자 지정 허용 컨트롤러가 실행되는 kube-system서비스에 영향을 주지 않도록 합니다.

사용자 지정 승인 웹후크를 지원하기 위해 kube-system에 무언가를 배포해야 하는 중요한 사용 사례가 있는 경우(권장되지 않음), 승인 강제기가 이를 무시하도록 다음 레이블 또는 주석을 추가할 수 있습니다.

• 레이블: "admissions.enforcer/disabled": "true"
• 주석: "admissions.enforcer/disabled": true

Azure Key Vault는 AKS와 통합되나요?

비밀 저장소 CSI 드라이버용 Azure Key Vault 공급자는 AKS에 Azure Key Vault의 네이티브 통합을 제공합니다.

AKS 배포에서 FIPS 암호화 라이브러리를 사용할 수 있나요?

FIPS(Federal Information Processing Standards)가 활성화된 노드는 이제 Linux 기반 노드 풀에서 지원됩니다. 자세한 내용은 FIPS 사용 노드 풀 추가를 참조하세요.

AKS 추가 기능은 어떻게 업데이트되나요?

보안 패치를 포함한 모든 패치는 AKS 클러스터에 자동으로 적용됩니다. 패치보다 큰 변경 사항, 예를 들어 메이저 또는 마이너 버전 변경(배포된 객체에 영향이 있을 수 있음)은 새 릴리스가 있는 경우 클러스터를 업데이트할 때 적용됩니다. 새 릴리스를 사용할 수 있는 시기에 대한 자세한 내용은 AKS 릴리스 정보를 참조하세요.

내 Linux 가상 머신 스케일 세트 인스턴스에 설치된 AKS Linux 확장의 목적은 무엇인가요?

AKS Linux 확장은 Kubernetes 워커 노드에 모니터링 도구를 설치하고 구성하는 Azure VM 확장입니다. 이 확장은 모든 신규 및 기존 Linux 노드에 설치됩니다. 다음 모니터링 도구를 구성합니다.

• 노드 내보내기: VM에서 하드웨어 원격 분석을 수집하고 메트릭 엔드포인트를 사용하여 사용할 수 있도록 합니다. 그런 다음 Prometheus와 같은 모니터링 도구가 이러한 메트릭을 폐기할 수 있습니다.
• Node-problem-detector: 클러스터 관리 스택의 업스트림 계층에 다양한 노드 문제를 표시하는 것을 목표로 합니다. 각 노드에서 실행되는 systemd 유닛으로, 노드 문제를 감지하고 Events 및 NodeConditions를 사용하여 클러스터의 API 서버에 보고합니다.
• ig: Linux 및 Kubernetes 시스템을 디버깅하고 관찰하기 위한 eBPF 기반 오픈 소스 프레임워크입니다. 이는 사용자가 성능 문제, 충돌 또는 기타 이상 현상의 원인을 식별하는 데 사용할 수 있는 관련 정보를 수집하는 도구(또는 가젯) 세트를 제공합니다. 특히, Kubernetes와 독립적이기 때문에 사용자는 이를 컨트롤 플레인 문제를 디버깅하는 데에도 사용할 수 있습니다.

이 도구들은 다음과 같은 여러 노드 상태 관련 문제에 대한 관측성을 제공하는 데 도움을 줍니다.

• 인프라 디먼 문제: NTP 서비스 다운
• 하드웨어 문제: CPU, 메모리 또는 디스크가 잘못되었습니다.
• 커널 문제: 커널 교착 상태, 손상된 파일 시스템
• 컨테이너 런타임 문제: 응답하지 않는 런타임 디먼

확장에는 설명된 AKS 송신 요구 사항을 초과하는 URL, IP 주소 또는 포트에 대한 추가 아웃바운드 액세스가 필요하지 않습니다. 이는 Azure에서 특별한 권한을 부여할 필요가 없습니다. API 서버에 연결하여 수집된 모니터링 데이터를 보내는 데 kubeconfig이 사용됩니다.

클러스터 문제 해결

내 클러스터를 삭제하는 데 시간이 오래 걸리는 이유는 무엇인가요?

대부분의 클러스터는 사용자의 요청에 따라 삭제됩니다. 일부 경우, 특히 자체 리소스 그룹을 사용하거나 리소스 그룹 간 작업을 수행하는 경우, 삭제에 더 많은 시간이 걸리거나 실패할 수도 있습니다. 삭제에 문제가 있는 경우, 리소스 그룹에 잠금이 걸려 있지 않은지 다시 확인하세요. 또한, 리소스 그룹 외부에 있는 모든 리소스가 해당 리소스 그룹과 연결 해제되어 있는지 확인하세요.

내 클러스터를 생성하거나 업데이트하는 데 시간이 오래 걸리는 이유는 무엇인가요?

클러스터 생성 및 업데이트에 문제가 있는 경우, AKS 클러스터가 VM, 로드 밸런서 또는 태그와 같은 리소스를 관리하지 못하게 막는 할당된 정책이나 서비스 제약이 없는지 확인하세요.

NodeLost 또는 Unknown 상태의 파드나 배포가 있어도 클러스터를 업그레이드할 수 있나요?

가능하지만 권장하지는 않습니다. 클러스터 상태가 확인되고 정상일 때 업데이트를 수행하세요.

하나 이상의 노드가 Unhealthy 상태이거나 클러스터가 종료된 경우에도 업그레이드를 수행할 수 있나요?

아니요. 업그레이드하기 전에 실패 상태이거나 클러스터에서 제외된 노드를 삭제하거나 제거하세요.

클러스터를 삭제하려고 했지만 "[Errno 11001] getaddrinfo가 실패했습니다." 오류가 표시됩니다.

이 오류는 대부분 클러스터와 여전히 연결된 하나 이상의 NSG를 사용 중일 때 발생합니다. 해당 NSG를 제거한 후 클러스터 삭제를 다시 시도하세요.

업그레이드를 실행했지만, 이제 파드가 충돌 루프에 빠지고 준비 상태 프로브가 실패합니다.

서비스 주체가 만료되지 않았는지 확인합니다. 자세한 내용은 AKS 서비스 주체 및 AKS 업데이트 자격 증명을 참조하세요.

클러스터가 정상적으로 작동했지만, 갑자기 로드 밸런서를 프로비저닝하거나 영구 볼륨 클레임을 마운트할 수 없습니다.

서비스 주체가 만료되지 않았는지 확인합니다. 자세한 내용은 AKS 서비스 주체 및 AKS 업데이트 자격 증명을 참조하세요.

사용 중지 및 사용 중단

AKS에서 더 이상 사용되지 않는 Linux OS 버전은 무엇입니까?

Ubuntu 16.04 및 Ubuntu 18.04는 AKS에서 더 이상 지원되지 않습니다. 2027년 3월 17일부터 AKS는 더 이상 Ubuntu 20.04를 지원하지 않습니다. 이 사용 중지에 대한 자세한 내용은 사용 중지: AKS의 Ubuntu 20.04 노드 풀을 참조하세요.

AKS에서 더 이상 사용되지 않는 Windows OS 버전은 무엇입니까?

2026년 3월 1일부터 AKS는 더 이상 Windows Server 2019 노드 풀을 지원하지 않습니다. Kubernetes 버전 1.33 이상에서는 Windows Server 2019를 사용할 수 없습니다. 이 사용 중지에 대한 자세한 내용은 사용 중지: AKS의 Windows Server 2019 노드 풀을 참조하세요. 2027년 3월 15일부터 AKS는 더 이상 Windows Server 2022 노드 풀을 지원하지 않습니다. Kubernetes 버전 1.36 이상은 Windows Server 2022를 사용할 수 없습니다. 이 사용 중지에 대한 자세한 내용은 사용 중지: AKS의 Windows Server 2022 노드 풀을 참조하세요.

이 문서는 Azure Kubernetes Service(AKS)에 대한 가장 일반적인 질문 중 일부에 대한 답변을 제공합니다.

AKS는 Uptime SLA 기능이 포함된 Standard 요금제에서 서비스 수준 계약(SLA) 보장을 제공합니다.

플랫폼 지원은 지원되지 않는 n-3 버전 클러스터에 대한 축소된 지원 계획입니다. 플랫폼 지원에는 Azure 인프라 지원만 포함됩니다.

자세한 내용은 플랫폼 지원 정책을 참조하세요.

예, AKS는 지원되지 않는 클러스터에 대해 자동 업그레이드를 시작합니다. 클러스터가 n-3 버전(여기서 n은 일반적으로 제공되는 최신 지원 AKS 마이너 버전)에서 n-4로 내려가려고 할 때, AKS는 지원 정책을 유지하기 위해 클러스터를 자동으로 n-2로 업그레이드합니다.

자세한 내용은 지원되는 Kubernetes 버전, 예정된 유지 관리 기간, 자동 업그레이드를 참조하세요.

AKS 에이전트 노드는 표준 Azure 가상 머신(VM)으로 요금이 부과됩니다. AKS에서 사용하는 VM 크기에 대해 Azure 예약을 구매한 경우, 해당 할인은 자동으로 적용됩니다.

예, AKS는 Windows Server 컨테이너도 지원합니다. 자세한 내용은 AKS FAQ에서 Windows Server를 참조하세요.

AKS는 Ubuntu Linux, Azure Linux, Azure Linux OS Guard 및 AKS용 Flatcar Container Linux를 비롯한 4개의 주요 Linux 운영 체제를 지원합니다. 노드 풀 생성 또는 클러스터 --os-type Linux 생성 시 지정할 경우 기본 OS는 Ubuntu Linux입니다.

사용하는 --os-sku Ubuntu경우 AKS는 Kubernetes 버전 1.25-1.34에서 기본적으로 Ubuntu 22.04로 설정됩니다. AKS는 Kubernetes 버전 1.35 이상에서 기본적으로 Ubuntu 24.04로 설정됩니다. 사용하는 --os-sku AzureLinux경우 AKS는 Kubernetes 버전 1.32 이상에서 기본적으로 Azure Linux 3.0으로 설정됩니다. FIPS 사용 노드 풀과 같은 일부 시나리오에서는 기본 OS 버전이 다를 수 있습니다. 자세한 내용은 노드 이미지를 참조하세요.

아니요. 테넌트 간에 AKS 클러스터를 이동하는 것은 현재 지원되지 않습니다.

아니요. AKS 클러스터를 구독 간에 이동하는 것은 현재 지원되지 않습니다.

아니요. AKS 클러스터 및 연결된 리소스를 이동하거나 이름을 바꾸는 것은 지원되지 않습니다.

아니요. 클러스터를 삭제한 후에는 복원할 수 없습니다. 클러스터를 삭제하면 노드 리소스 그룹과 그 안의 모든 리소스도 함께 삭제됩니다.

리소스를 유지하려면 클러스터를 삭제하기 전에 다른 리소스 그룹으로 이동하십시오. 실수로 인한 삭제로부터 보호하려는 경우 노드 리소스 그룹 잠금을 사용하여 클러스터 리소스를 호스팅하는 AKS 관리 되는 리소스 그룹을 잠글 수 있습니다.

실행 중인 AKS 클러스터를 완전히 중지하거나 모든 또는 특정 노드 풀User을 스케일 또는 자동 스케일하여 0으로 설정할 수 있습니다.

시스템 노드 풀을 0으로 직접 조정할 수 없습니다.

아니요. 가상 머신 스케일 세트 API를 사용하는 스케일 작업은 지원되지 않습니다. AKS API(az aks scale)를 사용할 수 있습니다.

아니요. 가상 머신 스케일 세트 API를 사용하는 스케일 작업은 지원되지 않습니다. AKS API를 사용하여 비시스템 노드 풀을 0으로 확장하거나 클러스터를 중지할 수 있습니다.

아니요. 이 구성은 지원되지 않습니다. 대신 클러스터를 중지하세요.

AKS는 가상 머신 확장 집합, 가상 네트워크 및 Managed Disks를 포함하는 여러 Azure 인프라 리소스를 기준으로 합니다. 이 통합 기능을 통해 AKS에서 제공하는 관리형 Kubernetes 환경 내에서 Azure 플랫폼의 핵심 기능 중 많은 부분을 적용할 수 있습니다. 예를 들어, 대부분의 Azure VM 유형을 AKS와 직접 사용할 수 있으며, Azure 예약을 통해 해당 리소스에 대한 할인을 자동으로 받을 수 있습니다.

이 아키텍처를 활성화하려면, 각 AKS 배포는 두 개의 리소스 그룹에 걸쳐 있습니다.

1. 첫 번째 리소스 그룹을 생성합니다. 이 그룹에는 Kubernetes 서비스 리소스만 포함됩니다. AKS 리소스 공급자는 배포 중에 두 번째 리소스 그룹을 자동으로 생성합니다. 두 번째 리소스 그룹의 예는 MC_myResourceGroup_myAKSCluster_eastus입니다. 이 두 번째 리소스 그룹의 이름을 지정하는 방법에 대한 자세한 내용은 다음 섹션을 참조하세요.
2. 노드 리소스 그룹으로 알려져 있는 두 번째 리소스 그룹에는 클러스터와 연결된 인프라 리소스의 모든 항목이 포함됩니다. 이러한 리소스에는 Kubernetes 노드 VM, 가상 네트워킹 및 스토리지가 포함됩니다. 기본적으로 노드 리소스 그룹에는 MC_myResourceGroup_myAKSCluster_eastus와 같은 이름이 지정됩니다. AKS는 클러스터를 삭제할 때 노드 리소스 그룹을 자동으로 삭제합니다. 이 리소스 그룹은 클러스터의 수명 주기를 공유하는 리소스에만 사용하세요.

참고

AKS 클러스터의 노드 리소스 그룹에 있는 리소스를 수정하는 것은 지원되지 않는 작업이며, 클러스터 작업 실패를 초래할 수 있습니다. 노드 리소스 그룹에 대한 변경이 이루어지지 않도록 설정할 수 있습니다. 사용자가 AKS 클러스터에서 관리하는 리소스를 수정하지 못하도록 차단합니다.

기본적으로 AKS는 노드 리소스 그룹 이름을 MC_resourcegroupname_clustername_location로 지정하지만, 사용자가 직접 이름을 지정할 수 있습니다.

고유한 리소스 그룹 이름을 지정하려면 aks-preview Azure CLI 확장 버전 0.3.2 이상을 설치합니다. az aks create 명령을 사용하여 AKS 클러스터를 만들 때 --node-resource-group 매개 변수를 사용하고 리소스 그룹의 이름을 지정합니다. AKS 클러스터를 배포할 때 Azure Resource Manager 템플릿을 사용하는 경우, nodeResourceGroup속성을 사용하여 리소스 그룹 이름을 정의할 수 있습니다.

• Azure 리소스 공급자가 두 번째 리소스 그룹을 자동으로 생성합니다.
• 클러스터를 생성할 때만 사용자 지정 리소스 그룹 이름을 지정할 수 있습니다.

노드 리소스 그룹을 사용할 때 다음을 수행할 수 없습니다.

• 노드 리소스 그룹에 기존 리소스 그룹을 지정할 수 없습니다.
• 노드 리소스 그룹에 다른 구독을 지정할 수 없습니다.
• 클러스터를 생성한 후에 노드 리소스 그룹 이름을 변경할 수 없습니다.
• 노드 리소스 그룹 내 관리되는 리소스의 이름을 지정할 수 없습니다.
• 노드 리소스 그룹 내 관리되는 리소스의 Azure 생성 태그를 수정하거나 삭제할 수 없습니다.

노드 리소스 그룹에서 Azure가 생성한 태그나 기타 리소스 속성을 수정하거나 삭제하면 예기치 않은 확장 및 업그레이드 오류가 발생할 수 있습니다. AKS를 사용하면 최종 사용자가 만든 사용자 지정 태그를 만들고 수정할 수 있으며 노드 풀을 만들 때 이러한 태그를 추가할 수 있습니다. 예를 들어, 비즈니스 부서나 비용 센터를 지정하기 위해 사용자 지정 태그를 생성하거나 수정하고 싶을 수 있습니다. 또 다른 옵션은 특히 클러스터 및 노드 풀을 통해 AKS 리소스 자체를 통해 정책을 적용하고 태그를 수정하는 것입니다.

Azure에서 생성한 태그는 각 Azure 서비스에 대해 생성되며, 항상 허용해야 합니다. AKS의 경우 aks-managed 태그와 k8s-azure 태그가 있습니다. AKS 클러스터의 노드 리소스 그룹에서 리소스에 대해 Azure로 만든 태그를 수정하는 작업은 지원되지 않으며, 이러한 작업은 SLO(서비스 수준 목표)를 중단하게 됩니다.

참고

과거에는 태그 이름이 Owner 부하 분산 장치의 프런트 엔드 IP에 할당된 공용 IP를 관리하기 위해 AKS에 예약되었습니다. 이제 서비스는 접두사를 aks-managed 사용합니다. 레거시 리소스의 경우 Azure 정책을 사용하여 Owner 태그 이름을 적용 하지 마세요. 그렇지 않으면 AKS 클러스터의 모든 리소스 배포 및 업데이트 작업이 중단됩니다. 이 제한은 새로 생성된 리소스에는 적용되지 않습니다.

AKS는 클러스터에 구성 요소를 전달하기 위해 Helm을 사용합니다. aks-managed 접두사 Helm 릴리스를 무시해도 됩니다. 이 Helm 릴리스에서 지속적으로 증가하는 리비전은 예상되는 현상이며 안전합니다.

사용 가능한 지역의 전체 목록은 AKS 지역 및 가용성을 참조하세요.

아니요. AKS 클러스터는 지역 리소스로, 여러 지역에 걸쳐 있을 수 없습니다. 여러 지역을 포함하는 아키텍처를 만드는 방법에 대한 지침은 비즈니스 연속성 및 재해 복구에 대한 모범 사례를 참조하세요.

예, 지원하는 지역에 있는 하나 이상의 가용성 영역에서 AKS 클러스터를 배포할 수 있습니다.

예, 여러 노드 풀을 만들어 AKS 클러스터에서 다른 VM 크기를 사용할 수 있습니다.

AKS는 컨테이너 이미지 크기에 대해 제한을 설정하지 않습니다. 그러나 이미지가 클수록 메모리 요구량이 높아집니다. 큰 크기는 잠재적으로 리소스 한도나 워커 노드의 전체 사용 가능한 메모리를 초과할 수 있습니다. 기본적으로 AKS 클러스터의 VM 크기 Standard_DS2_v2 메모리는 7GiB로 설정됩니다.

컨테이너 이미지가 테라바이트(TB) 단위처럼 지나치게 큰 경우, 디스크 공간 부족으로 인해 kubelet이 컨테이너 레지스트리에서 노드로 이미지를 가져오지 못할 수 있습니다.

Windows Server 노드의 경우, Windows Update가 자동으로 실행되어 최신 업데이트를 적용하지 않습니다. AKS 클러스터에서 클러스터와 Windows Server 노드 풀을 업그레이드해야 합니다. Windows Update 릴리스 주기와 자체 검증 프로세스를 기반으로 정기적인 일정에 따라 진행하세요. 이 업그레이드 프로세스는 최신 Windows Server 이미지와 패치를 실행하는 노드를 생성한 후, 이전 노드를 제거합니다. 이 프로세스에 대한 자세한 내용은 AKS에서 노드 풀 업그레이드를 참조하세요.

다음 이미지들은 루트 권한으로 실행되어야 하는 기능적 요구 사항이 있으며, 모든 정책에 대해서는 예외를 신청해야 합니다.

• mcr.microsoft.com/oss/kubernetes/coredns
• mcr.microsoft.com/azuremonitor/containerinsights/ciprod
• mcr.microsoft.com/oss/calico/node
• mcr.microsoft.com/oss/kubernetes-csi/azuredisk-csi

예, API 서버에 대한 접근을 제한하는 두 가지 옵션이 있습니다.

• API 서버에 대한 퍼블릭 엔드포인트를 유지하지만 신뢰할 수 있는 IP 범위 세트로 액세스를 제한하려는 경우 API Server 권한 있는 IP 범위를 사용합니다.
• API 서버를 가상 네트워크 내에서만 액세스할 수 있도록 제한하려는 경우 프라이빗 클러스터를 사용합니다.

AKS는 매주 공급업체 픽스가 있는 CVE를 패치합니다. 수정되지 않은 CVE는 벤더의 수정이 적용되기 전까지 해결할 수 없습니다. AKS 이미지는 30일 이내에 자동으로 업데이트됩니다. 최신 패치가 적용된 이미지와 운영 체제 패치가 모두 최신 상태로 유지되도록, 정기적으로 업데이트된 노드 이미지를 적용하는 것을 권장합니다. 다음 작업을 수행할 수 있습니다.

• 수동으로, Azure 포털 또는 Azure CLI를 통해 수행할 수 있습니다.
• AKS 클러스터를 업그레이드하여. 클러스터는 코돈 및 드레이닝 노드를 자동으로 업그레이드합니다. 그런 다음 최신 Ubuntu 이미지와 새로운 패치 버전 또는 마이너 Kubernetes 버전을 가진 새 노드를 온라인으로 가져옵니다. 자세한 내용은 AKS 클러스터 업그레이드를 참조하세요.
• 노드 이미지 업그레이드를 사용합니다.

Microsoft는 컨테이너용 Microsoft Defender와 같은 서비스를 통해 워크로드를 보호하기 위해 수행할 수 있는 추가 작업에 대한 지침을 제공합니다. AKS 및 Kubernetes와 관련된 보안 위협에 대한 자세한 내용은 새로운 대규모 캠페인 대상 Kubeflow (2021년 6월 8일)를 참조하세요.

아니요. 모든 데이터는 클러스터가 위치한 지역에 저장됩니다.

전통적으로, 파드가 비루트 사용자로 실행되는 경우(그렇게 해야 하며), 파드가 볼륨을 읽고 쓸 수 있도록 하기 위해 파드의 보안 컨텍스트 안에 fsGroup 매개변수를 지정해야 합니다. 이 요구 사항에 대한 자세한 내용은 Pod 또는 컨테이너에 대한 보안 컨텍스트 구성을 참조하세요.

설정 fsGroup 의 부작용은 볼륨이 탑재될 때마다 Kubernetes가 볼륨 내의 모든 파일 및 디렉터리에 대해 재귀적으로 명령과 chown() 명령을 사용해야 chmod() 한다는 것입니다(몇 가지 예외 제외). 이 시나리오는 볼륨의 그룹 소유권이 이미 요청된 fsGroup 매개 변수와 일치하는 경우에도 발생합니다. 이 구성은 많은 작은 파일을 포함한 대용량의 경우 비용이 많이 들 수 있으며, 이로 인해 파드 시작 시간이 길어질 수 있습니다. 이 시나리오는 v1.20 이전에 알려진 문제였습니다. 해결 방법은 파드를 루트 권한으로 실행하도록 설정하는 것입니다.

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    fsGroup: 0

이 문제는 Kubernetes 버전 1.20에서 해결되었습니다. 자세한 내용은 Kubernetes 1.20: 볼륨 권한 변경에 대한 세분화된 제어를 참조하세요.

AKS는 보안 터널 통신을 사용하여 api-server 및 개별 노드 kubelets가 별도의 가상 네트워크에서도 통신할 수 있도록 합니다. 터널은 상호 전송 계층 보안(TLS) 암호화를 통해 보호됩니다. AKS에서 사용되는 현재 주 터널은 이전에 apiserver-network-proxy로 알려진 Konnectivity입니다. 모든 네트워크 규칙이 Azure 필수 네트워크 규칙 및 FQDN(정규화된 도메인 이름)을 따르는지 확인합니다.

예, Pod에 kubernetes.azure.com/set-kube-service-host-fqdn 주석을 추가하여 KUBERNETES_SERVICE_HOST 변수를 클러스터 내 서비스 IP 대신 API 서버의 도메인 이름으로 설정할 수 있습니다. 이 수정은 클러스터가 레이어 7 방화벽을 통해 외부로 나가는 경우에 유용합니다. 예를 들어, Azure Firewall을 애플리케이션 규칙과 함께 사용할 때입니다.

AKS는 서브넷에 네트워크 보안 그룹(NSG)을 적용하지 않으며, 해당 서브넷과 연결된 NSG를 수정하지도 않습니다. AKS는 네트워크 인터페이스의 NSG 설정만 수정합니다. Container Network Interface(CNI)를 사용하는 경우, NSG의 보안 규칙이 노드와 파드의 CIDR 범위 간 트래픽을 허용하도록 설정되어 있는지 확인해야 합니다. kubenet을 사용하는 경우, NSG의 보안 규칙이 노드와 파드 CIDR 간 트래픽을 허용하도록 설정되어 있는지 확인해야 합니다. 자세한 내용은 네트워크 보안 그룹을 참조하세요.

AKS 노드는 로컬 호스트에서 시간을 끌어오는 chrony 서비스를 실행합니다. Pod에서 실행되는 컨테이너는 AKS 노드에서 시간을 얻습니다. 컨테이너 내에서 시작된 애플리케이션은 Pod의 컨테이너에서 시간을 사용합니다.

아니요. AKS는 관리형 서비스입니다. IaaS(Infrastructure as a Service) 리소스 조작은 지원되지 않습니다. 사용자 지정 구성 요소를 설치하려면 Kubernetes API 및 메커니즘을 사용하세요. 예를 들어 DaemonSets를 사용하여 필요한 구성 요소를 설치합니다.

AKS는 다음과 같은 허용 컨트롤러를 지원합니다.

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultIngressClass
• DefaultStorageClass
• DefaultTolerationSeconds
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook
• ResourceQuota
• PodNodeSelector
• PodTolerationRestriction
• ExtendedResourceToleration

현재, AKS에서 허용 컨트롤러 목록을 수정할 수 없습니다.

예, AKS에서 허용 컨트롤러 웹후크를 사용할 수 있습니다. 레이블로 표시된 control-plane 내부 AKS 네임스페이스를 제외하는 것이 좋습니다. 예를 들어:

namespaceSelector:
    matchExpressions:
    - key: control-plane
      operator: DoesNotExist

AKS는 API 서버의 아웃바운드를 방화벽으로 보호하므로, 어드미션 컨트롤러 웹후크는 클러스터 내부에서 접근 가능해야 합니다.

시스템의 안정성을 보호하고 kube-system 네임스페이스에서 사용자 지정 승인 컨트롤러가 내부 서비스에 영향을 주는 것을 방지하기 위해, AKS에는 승인 강제기가 있으며, 이는 kube-system 및 AKS 내부 네임스페이스를 자동으로 제외합니다. 이 서비스는 사용자 지정 허용 컨트롤러가 실행되는 kube-system서비스에 영향을 주지 않도록 합니다.

사용자 지정 승인 웹후크를 지원하기 위해 kube-system에 무언가를 배포해야 하는 중요한 사용 사례가 있는 경우(권장되지 않음), 승인 강제기가 이를 무시하도록 다음 레이블 또는 주석을 추가할 수 있습니다.

• 레이블: "admissions.enforcer/disabled": "true"
• 주석: "admissions.enforcer/disabled": true

비밀 저장소 CSI 드라이버용 Azure Key Vault 공급자는 AKS에 Azure Key Vault의 네이티브 통합을 제공합니다.

FIPS(Federal Information Processing Standards)가 활성화된 노드는 이제 Linux 기반 노드 풀에서 지원됩니다. 자세한 내용은 FIPS 사용 노드 풀 추가를 참조하세요.

보안 패치를 포함한 모든 패치는 AKS 클러스터에 자동으로 적용됩니다. 패치보다 큰 변경 사항, 예를 들어 메이저 또는 마이너 버전 변경(배포된 객체에 영향이 있을 수 있음)은 새 릴리스가 있는 경우 클러스터를 업데이트할 때 적용됩니다. 새 릴리스를 사용할 수 있는 시기에 대한 자세한 내용은 AKS 릴리스 정보를 참조하세요.

AKS Linux 확장은 Kubernetes 워커 노드에 모니터링 도구를 설치하고 구성하는 Azure VM 확장입니다. 이 확장은 모든 신규 및 기존 Linux 노드에 설치됩니다. 다음 모니터링 도구를 구성합니다.

• 노드 내보내기: VM에서 하드웨어 원격 분석을 수집하고 메트릭 엔드포인트를 사용하여 사용할 수 있도록 합니다. 그런 다음 Prometheus와 같은 모니터링 도구가 이러한 메트릭을 폐기할 수 있습니다.
• Node-problem-detector: 클러스터 관리 스택의 업스트림 계층에 다양한 노드 문제를 표시하는 것을 목표로 합니다. 각 노드에서 실행되는 systemd 유닛으로, 노드 문제를 감지하고 Events 및 NodeConditions를 사용하여 클러스터의 API 서버에 보고합니다.
• ig: Linux 및 Kubernetes 시스템을 디버깅하고 관찰하기 위한 eBPF 기반 오픈 소스 프레임워크입니다. 이는 사용자가 성능 문제, 충돌 또는 기타 이상 현상의 원인을 식별하는 데 사용할 수 있는 관련 정보를 수집하는 도구(또는 가젯) 세트를 제공합니다. 특히, Kubernetes와 독립적이기 때문에 사용자는 이를 컨트롤 플레인 문제를 디버깅하는 데에도 사용할 수 있습니다.

이 도구들은 다음과 같은 여러 노드 상태 관련 문제에 대한 관측성을 제공하는 데 도움을 줍니다.

• 인프라 디먼 문제: NTP 서비스 다운
• 하드웨어 문제: CPU, 메모리 또는 디스크가 잘못되었습니다.
• 커널 문제: 커널 교착 상태, 손상된 파일 시스템
• 컨테이너 런타임 문제: 응답하지 않는 런타임 디먼

확장에는 설명된 AKS 송신 요구 사항을 초과하는 URL, IP 주소 또는 포트에 대한 추가 아웃바운드 액세스가 필요하지 않습니다. 이는 Azure에서 특별한 권한을 부여할 필요가 없습니다. API 서버에 연결하여 수집된 모니터링 데이터를 보내는 데 kubeconfig이 사용됩니다.

대부분의 클러스터는 사용자의 요청에 따라 삭제됩니다. 일부 경우, 특히 자체 리소스 그룹을 사용하거나 리소스 그룹 간 작업을 수행하는 경우, 삭제에 더 많은 시간이 걸리거나 실패할 수도 있습니다. 삭제에 문제가 있는 경우, 리소스 그룹에 잠금이 걸려 있지 않은지 다시 확인하세요. 또한, 리소스 그룹 외부에 있는 모든 리소스가 해당 리소스 그룹과 연결 해제되어 있는지 확인하세요.

클러스터 생성 및 업데이트에 문제가 있는 경우, AKS 클러스터가 VM, 로드 밸런서 또는 태그와 같은 리소스를 관리하지 못하게 막는 할당된 정책이나 서비스 제약이 없는지 확인하세요.

가능하지만 권장하지는 않습니다. 클러스터 상태가 확인되고 정상일 때 업데이트를 수행하세요.

아니요. 업그레이드하기 전에 실패 상태이거나 클러스터에서 제외된 노드를 삭제하거나 제거하세요.

이 오류는 대부분 클러스터와 여전히 연결된 하나 이상의 NSG를 사용 중일 때 발생합니다. 해당 NSG를 제거한 후 클러스터 삭제를 다시 시도하세요.

서비스 주체가 만료되지 않았는지 확인합니다. 자세한 내용은 AKS 서비스 주체 및 AKS 업데이트 자격 증명을 참조하세요.

서비스 주체가 만료되지 않았는지 확인합니다. 자세한 내용은 AKS 서비스 주체 및 AKS 업데이트 자격 증명을 참조하세요.

Ubuntu 16.04 및 Ubuntu 18.04는 AKS에서 더 이상 지원되지 않습니다. 2027년 3월 17일부터 AKS는 더 이상 Ubuntu 20.04를 지원하지 않습니다. 이 사용 중지에 대한 자세한 내용은 사용 중지: AKS의 Ubuntu 20.04 노드 풀을 참조하세요.

2026년 3월 1일부터 AKS는 더 이상 Windows Server 2019 노드 풀을 지원하지 않습니다. Kubernetes 버전 1.33 이상에서는 Windows Server 2019를 사용할 수 없습니다. 이 사용 중지에 대한 자세한 내용은 사용 중지: AKS의 Windows Server 2019 노드 풀을 참조하세요. 2027년 3월 15일부터 AKS는 더 이상 Windows Server 2022 노드 풀을 지원하지 않습니다. Kubernetes 버전 1.36 이상은 Windows Server 2022를 사용할 수 없습니다. 이 사용 중지에 대한 자세한 내용은 사용 중지: AKS의 Windows Server 2022 노드 풀을 참조하세요.