Azure 컨테이너 스토리지 문제 해결
Azure Container Storage는 기본적으로 컨테이너용으로 구축된 클라우드 기반 볼륨 관리, 배포 및 오케스트레이션 서비스입니다. 이 문서를 사용하여 Azure Container Storage의 일반적인 문제를 해결하고 문제에 대한 해결 방법을 찾습니다.
설치 문제 해결
구성 누락으로 인해 Azure Container Storage를 설치하지 못함
실행az aks create한 후 Azure Container Storage를 설치하지 못했다는 메시지가 표시될 수 있습니다. AKS 클러스터가 만들어집니다. 함께 --enable-azure-container-storage 실행 az aks update 하여 Azure Container Storage를 사용하도록 설정합니다.
이 메시지는 Azure Container Storage가 설치되지 않았지만 AKS(Azure Kubernetes Service) 클러스터가 제대로 생성되었음을 의미합니다.
클러스터에 Azure Container Storage를 설치하고 스토리지 풀을 만들려면 다음 명령을 실행합니다. <cluster-name> 및 <resource-group>를 사용자 고유의 값으로 바꿉니다. <storage-pool-type>을 azureDiskephemeraldisk 또는elasticSan으로 바꿉니다.
az aks update -n <cluster-name> -g <resource-group> --enable-azure-container-storage <storage-pool-type>
Azure Policy 제한으로 인해 Azure Container Storage를 설치하지 못함
Azure Policy 제한이 적용된 경우 Azure Container Storage를 설치하지 못할 수 있습니다. 특히 Azure Container Storage는 권한 있는 컨테이너를 사용합니다. 권한 있는 컨테이너를 차단하도록 Azure Policy를 구성할 수 있습니다. 차단되면 Azure Container Storage 설치 시간이 초과되거나 실패할 수 있으며 로그에 gatekeeper-controller 다음과 같은 오류가 표시될 수 있습니다.
$ kubectl logs -n gatekeeper-system deployment/gatekeeper-controller
...
{"level":"info","ts":1722622443.9484184,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: prereq, securityContext: {\"privileged\": true, \"runAsUser\": 0}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-prereq-gt58x","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
{"level":"info","ts":1722622443.9839077,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: metrics-exporter, securityContext: {\"privileged\": true}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-metrics-exporter-286np","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
{"level":"info","ts":1722622444.0515249,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: csi-node, securityContext: {\"privileged\": true}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-csi-node-7hcd7","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
{"level":"info","ts":1722622444.0729053,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: io-engine, securityContext: {\"privileged\": true}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-io-engine-84hwx","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
{"level":"info","ts":1722622444.0742755,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: ndm, securityContext: {\"privileged\": true}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-ndm-x6q5n","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
{"level":"info","ts":1722622449.2412128,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: ndm, securityContext: {\"privileged\": true}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-ndm-b5nfg","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
차단을 해결하려면 네임스페이 acstor 스를 Azure Policy의 제외 목록에 추가해야 합니다. Azure Policy는 AKS 클러스터를 포함하여 Azure 내에서 리소스를 관리하기 위한 규칙을 만들고 적용하는 데 사용됩니다. 경우에 따라 정책이 Azure Container Storage Pod 및 구성 요소 생성을 차단할 수 있습니다. Kubernetes용 Azure Policy를 참조하여 Kubernetes용 Azure Policy 작업에 대한 자세한 내용을 확인할 수 있습니다.
제외 목록에 네임스페이 acstor 스를 추가하려면 다음 단계를 수행합니다.
- Azure Kubernetes 클러스터를 만듭니다.
- AKS에 Azure Policy를 사용하도록 설정합니다.
- Azure Container Storage 설치를 차단하는 것으로 의심되는 정책을 만듭니다.
- AKS 클러스터에 Azure Container Storage를 설치하려고 시도합니다.
- 게이트키퍼 컨트롤러 Pod에 대한 로그를 확인하여 정책 위반을 확인합니다.
- 정책의
acstor제외 목록에 네임스페이스 및azure-extensions-usage-system네임스페이스를 추가합니다. - AKS 클러스터에 Azure Container Storage를 다시 설치합니다.
taint가 있는 노드 풀에서 Azure Container Storage를 설치하고 사용하도록 설정할 수 없습니다.
노드 풀에서 노드 taint를 구성하여 이러한 노드 풀에서 Pod가 예약되지 않도록 제한할 수 있습니다. 이러한 노드 풀에서 필요한 Pod를 만들 수 없으므로 이러한 노드 풀에 Azure Container Storage를 설치하고 사용하도록 설정하면 차단될 수 있습니다. 이 동작은 설치 시 시스템 노드 풀과 사용하도록 설정할 때 사용자 노드 풀 모두에 적용됩니다.
다음 예제를 사용하여 노드 taints를 확인할 수 있습니다.
$ az aks nodepool list -g $resourceGroup --cluster-name $clusterName --query "[].{PoolName:name, nodeTaints:nodeTaints}"
[
...
{
"PoolName": "nodepoolx",
"nodeTaints": [
"sku=gpu:NoSchedule"
]
}
]
설치하고 성공적으로 사용하도록 설정한 후 차단을 해제하고 다시 구성하기 위해 이러한 taint를 일시적으로 제거할 수 있습니다. Azure Portal > AKS 클러스터 > 노드 풀로 이동하여 노드 풀을 클릭하고 "Taints 및 레이블" 섹션에서 taints를 제거할 수 있습니다. 또는 다음 명령을 사용하여 taint를 제거하고 변경 사항을 확인할 수 있습니다.
$ az aks nodepool update -g $resourceGroup --cluster-name $clusterName --name $nodePoolName --node-taints ""
$ az aks nodepool list -g $resourceGroup --cluster-name $clusterName --query "[].{PoolName:name, nodeTaints:nodeTaints}"
[
...
{
"PoolName": "nodepoolx",
"nodeTaints": null
}
]
노드 taints를 성공적으로 제거한 후 설치 또는 활성화를 다시 시도합니다. 성공적으로 완료되면 노드 taints를 다시 구성하여 Pod 예약 제한 사항을 다시 시작할 수 있습니다.
스토리지 풀 형식을 NVMe로 설정할 수 없습니다.
임시 디스크, 특히 VM(가상 머신) SKU에 NVMe 드라이브가 없는 클러스터에서 로컬 NVMe를 사용하여 Azure Container Storage를 설치하려고 하면 다음 오류 메시지가 표시됩니다. Cannot set --storage- 노드 풀 중 어느 것도 임시 NVMe 디스크를 지원할 수 없으므로 풀 옵션을 NVMe로 사용합니다.
문제를 수정하려면 NVMe 드라이브가 있는 VM SKU로 노드 풀을 만들고 다시 시도합니다. 스토리지 최적화 VM을 참조하세요.
스토리지 풀 문제 해결
스토리지 풀의 상태를 확인하려면 kubectl describe sp <storage-pool-name> -n acstor를 실행합니다. 발생할 수 있는 몇 가지 문제는 다음과 같습니다.
임시 스토리지 풀은 다른 디먼셋에서 임시 디스크를 사용하는 경우 용량을 클레임하지 않습니다.
임시 SSD 또는 로컬 NVMe 디스크가 있는 노드 풀에서 임시 스토리지 풀을 사용하도록 설정하면 다른 디먼셋이 사용하는 경우 이러한 디스크에서 용량을 클레임하지 않을 수 있습니다.
다음 단계를 실행하여 Azure Container Storage가 이러한 로컬 디스크를 단독으로 관리할 수 있도록 합니다.
다음 명령을 실행하여 임시 스토리지 풀에서 클레임된 용량을 확인합니다.
$ kubectl get sp -A NAMESPACE NAME CAPACITY AVAILABLE USED RESERVED READY AGE acstor ephemeraldisk-nvme 0 0 0 0 False 82s이 예제에서는 스토리지 풀에서 클레임하는 용량이 0개
ephemeraldisk-nvme인 것을 보여 줍니다.다음 명령을 실행하여 이러한 로컬 블록 디바이스의 클레임되지 않은 상태를 확인하고 디스크의 기존 파일 시스템을 확인합니다.
$ kubectl get bd -A NAMESPACE NAME NODENAME SIZE CLAIMSTATE STATUS AGE acstor blockdevice-1f7ad8fa32a448eb9768ad8e261312ff aks-nodepoolnvme-38618677-vmss000001 1920383410176 Unclaimed Active 22m acstor blockdevice-9c8096fc47cc2b41a2ed07ec17a83527 aks-nodepoolnvme-38618677-vmss000000 1920383410176 Unclaimed Active 23m $ kubectl describe bd -n acstor blockdevice-1f7ad8fa32a448eb9768ad8e261312ff Name: blockdevice-1f7ad8fa32a448eb9768ad8e261312ff … Filesystem: Fs Type: ext4 …이 예제에서는 블록 디바이스
Unclaimed가 상태이며 디스크에 기존 파일 시스템이 있음을 보여 줍니다.계속하기 전에 Azure Container Storage를 사용하여 로컬 데이터 디스크를 단독으로 관리하려는지 확인합니다.
로컬 데이터 디스크를 관리하는 디먼셋 또는 구성 요소를 중지하고 제거합니다.
로컬 데이터 디스크가 있는 각 노드에 로그인합니다.
모든 로컬 데이터 디스크에서 기존 파일 시스템을 제거합니다.
ndm 디먼셋을 다시 시작하여 사용되지 않는 로컬 데이터 디스크를 검색합니다.
$ kubectl rollout restart daemonset -l app=ndm -n acstor daemonset.apps/azurecontainerstorage-ndm restarted $ kubectl rollout status daemonset -l app=ndm -n acstor --watch … daemon set "azurecontainerstorage-ndm" successfully rolled out몇 초 정도 기다렸다가 임시 스토리지 풀이 로컬 데이터 디스크의 용량을 클레임하는지 확인합니다.
$ kubectl wait -n acstor sp --all --for condition=ready storagepool.containerstorage.azure.com/ephemeraldisk-nvme condition met $ kubectl get bd -A NAMESPACE NAME NODENAME SIZE CLAIMSTATE STATUS AGE acstor blockdevice-1f7ad8fa32a448eb9768ad8e261312ff aks-nodepoolnvme-38618677-vmss000001 1920383410176 Claimed Active 4d16h acstor blockdevice-9c8096fc47cc2b41a2ed07ec17a83527 aks-nodepoolnvme-38618677-vmss000000 1920383410176 Claimed Active 4d16h $ kubectl get sp -A NAMESPACE NAME CAPACITY AVAILABLE USED RESERVED READY AGE acstor ephemeraldisk-nvme 3840766820352 3812058578944 28708241408 26832871424 True 4d16h이 예제에서는 스토리지 풀이 노드의 로컬 NVMe 디스크에서 용량을 성공적으로 클레임하는 것을 보여
ephemeraldisk-nvme줍니다.
Azure Disks 스토리지 풀을 확장하려고 할 때 오류 발생
기존 스토리지 풀이 4TiB(4,096GiB) 미만인 경우 최대 4,095GiB까지만 확장할 수 있습니다. 제한을 초과하여 확장하려고 하면 내부 PVC에 디스크 크기 또는 캐싱 형식 제한에 대한 오류 메시지가 표시됩니다. VM을 중지하거나 디스크를 분리하고 작업을 다시 시도하세요."
오류를 방지하려면 처음에 4TiB(4,096GiB)보다 작은 경우 현재 스토리지 풀을 4,095GiB 이상으로 확장하지 마세요. 4TiB보다 큰 스토리지 풀은 사용 가능한 최대 스토리지 용량까지 확장 가능합니다.
이 제한은 Premium_LRS, Standard_LRS, StandardSSD_LRS, Premium_ZRS 및 StandardSSD_ZRS 디스크 SKU를 사용하는 경우에만 적용됩니다.
탄력적 SAN 만들기 실패
Elastic SAN 스토리지 풀을 만들려고 하면 Azure Elastic SAN 만들기 실패: 이미 만들어진 구독에 대해 가능한 최대 Elastic SAN 수라는 메시지가 표시될 수 있습니다. 즉, 구독당 지역에 배포할 수 있는 Elastic SAN 리소스 수에 대한 제한에 도달합니다. Elastic SAN 확장성 및 성능 대상에서 한도를 확인할 수 있습니다. 구독에서 더 이상 사용되지 않는 기존 Elastic SAN 리소스를 삭제하거나 다른 지역에 스토리지 풀을 만들어 보세요.
차단 디바이스를 찾을 수 없습니다.
이 메시지가 표시되면 VM SKU에 NVMe 드라이브가 없는 클러스터에서 임시 디스크 스토리지 풀을 만들려고 할 가능성이 높습니다.
문제를 수정하려면 NVMe 드라이브가 있는 VM SKU로 노드 풀을 만들고 다시 시도합니다. 스토리지 최적화 VM을 참조하세요.
스토리지 풀 형식이 이미 사용하도록 설정되었습니다.
존재하는 스토리지 풀 유형을 사용하도록 설정하려고 하면 잘못된 --enable-azure-container-storage 값이라는 메시지가 표시됩니다. Azure Container Storage는 클러스터의 스토리지 풀 유형 <storage-pool-type> 에 대해 이미 사용하도록 설정되어 있습니다. kubectl get sp -n acstor를 실행하여 만들어진 기존 스토리지 풀이 있는지 확인할 수 있습니다.
스토리지 풀 형식 사용 안 함
az aks update --disable-azure-container-storage <storage-pool-type>을 통해 스토리지 풀 형식을 사용하지 않도록 설정하거나 az aks update --disable-azure-container-storage all을 통해 Azure Container Storage를 제거할 때 해당 형식의 기존 스토리지 풀이 있는 경우 다음 메시지가 표시됩니다.
스토리지 풀 유형 <storage-pool-type> 에 대해 Azure Container Storage를 사용하지 않도록 설정하면 동일한 유형의 모든 스토리지 풀이 강제로 삭제되고 이러한 스토리지 풀을 사용하는 애플리케이션에 영향을 줍니다. 스토리지 풀을 강제로 삭제하면 사용 중인 스토리지 리소스가 누출될 수도 있습니다. Azure Container Storage를 사용하지 않도록 설정하기 전에 <storage-pool-type> 형식의 스토리지 풀이 사용되고 있는지 유효성을 검사하려고 하나요? (Y/n)
Y를 선택하면 자동 유효성 검사가 실행되어 스토리지 풀에서 만들어진 영구 볼륨이 없는지 유효성을 검사합니다. n을 선택하면 의 유효성이 검사를 무시하고 스토리지 풀 형식을 사용하지 않도록 설정하여 기존 스토리지 풀을 삭제하고 잠재적으로 애플리케이션에 영향을 미칠 수 있습니다.
볼륨 문제 해결
사용 가능한 용량을 초과하는 임시 볼륨 크기로 인해 Pod 만들기 보류 중
임시 볼륨은 단일 노드에 할당됩니다. Pod의 임시 볼륨 크기를 구성할 때 크기는 단일 노드 임시 디스크의 사용 가능한 용량보다 작아야 합니다. 그렇지 않으면 Pod 만들기가 보류 중입니다.
다음 명령을 사용하여 Pod 만들기가 보류 중 상태인지 확인합니다.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
fiopod 0/1 Pending 0 17s
이 예에서 Pod fiopod는 Pending 상태입니다.
다음 명령을 사용하여 Pod에 영구 볼륨 클레임 만들기에 대한 경고 이벤트가 있는지 확인합니다.
$ kubectl describe pod fiopod
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 40s default-scheduler 0/3 nodes are available: waiting for ephemeral volume controller to create the persistentvolumeclaim "fiopod-ephemeralvolume". preemption: 0/3 nodes are available: 3 Preemption is not helpful for scheduling..
이 예에서 Pod는 영구 볼륨 클레임 fiopod-ephemeralvolume 만들기에 대한 경고 이벤트를 표시합니다.
다음 명령을 사용하여 용량 부족으로 인해 영구 볼륨 클레임 프로비전에 실패했는지 확인합니다.
$ kubectl describe pvc fiopod-ephemeralvolume
...
Warning ProvisioningFailed 107s (x13 over 20m) containerstorage.csi.azure.com_aks-nodepool1-29463073-vmss000000_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx failed to provision volume with StorageClass "acstor-ephemeraldisk-temp": rpc error: code = Internal desc = Operation failed: GenericOperation("error in response: status code '507 Insufficient Storage', content: 'RestJsonError { details: \"Operation failed due to insufficient resources: Not enough suitable pools available, 0/1\", message: \"SvcError :: NotEnoughResources\", kind: ResourceExhausted }'")
이 예에서는 볼륨 프로비전 실패의 원인으로 Insufficient Storage가 표시됩니다.
단일 노드 임시 디스크의 사용 가능한 용량을 확인하려면 다음 명령을 실행합니다.
$ kubectl get diskpool -n acstor
NAME CAPACITY AVAILABLE USED RESERVED READY AGE
ephemeraldisk-temp-diskpool-jaxwb 75660001280 75031990272 628011008 560902144 True 21h
ephemeraldisk-temp-diskpool-wzixx 75660001280 75031990272 628011008 560902144 True 21h
ephemeraldisk-temp-diskpool-xbtlj 75660001280 75031990272 628011008 560902144 True 21h
이 예에서 단일 노드에 사용 가능한 임시 디스크 용량은 75031990272바이트 또는 69GiB입니다.
사용 가능한 용량보다 작은 볼륨 스토리지 크기를 조정하고 Pod를 다시 배포합니다. 제네릭 임시 볼륨을 사용하여 Pod 배포를 참조하세요.
메타데이터 저장소가 오프라인 상태여서 볼륨을 연결하지 못함
Azure 컨테이너 스토리지는 신뢰할 수 있는 분산된 키-값 스토리지 etcd를 사용하여 볼륨의 메타데이터를 저장하고 관리하여 볼륨 오케스트레이션 작업을 지원합니다. 고가용성 및 복원력을 위해 세 개의 Pod에서 etcd번 실행됩니다. 실행 중인 인스턴스가 2 etcd 개 미만인 경우 Azure Container Storage는 볼륨에 대한 데이터 액세스를 허용하면서 볼륨 오케스트레이션 작업을 중지합니다. Azure 컨테이너 스토리지는 etcd 인스턴스가 오프라인 상태일 때 자동으로 감지하여 복구합니다. 그러나 AKS 클러스터를 다시 시작한 후 볼륨 오케스트레이션 오류가 발견되면 인스턴스가 etcd 자동 복구에 실패했을 수 있습니다. 이 섹션의 지침에 따라 etcd 인스턴스의 상태를 확인합니다.
다음 명령을 실행하여 Pod 목록을 가져옵니다.
kubectl get pods
다음과 유사한 출력이 표시 될 수 있습니다.
NAME READY STATUS RESTARTS AGE
fiopod 0/1 ContainerCreating 0 25m
Pod에 대해 설명합니다.
kubectl describe pod fiopod
일반적으로 메타데이터 저장소가 오프라인인 경우 볼륨 오류 메시지가 표시됩니다. 이 예제에서 fiopod는 ContainerCreating 상태이며, FailedAttachVolume 경고는 볼륨 연결 실패로 인해 생성이 보류 중임을 나타냅니다.
Name: fiopod
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 25m default-scheduler Successfully assigned default/fiopod to aks-nodepool1-xxxxxxxx-vmss000009
Warning FailedAttachVolume 3m8s (x6 over 23m) attachdetach-controller AttachVolume.Attach failed for volume "pvc-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" : timed out waiting for external-attacher of containerstorage.csi.azure.com CSI driver to attach volume xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
다음 명령을 실행하여 etcd 인스턴스의 상태를 확인할 수도 있습니다.
kubectl get pods -n acstor | grep "^etcd"
다음과 유사한 출력이 표시되며 모든 인스턴스가 실행 중 상태여야 합니다.
etcd-azurecontainerstorage-bn89qvzvzv 1/1 Running 0 4d19h
etcd-azurecontainerstorage-phf92lmqml 1/1 Running 0 4d19h
etcd-azurecontainerstorage-xznvwcgq4p 1/1 Running 0 4d19h
두 개 미만의 인스턴스가 실행 중인 경우 메타데이터 저장소가 오프라인 상태이고 자동화된 복구가 실패했기 때문에 볼륨이 연결되지 않습니다. 그렇다면 Azure 지원에 지원 티켓을 제출합니다.