다음을 통해 공유


애플리케이션에 대한 AKS(Azure Kubernetes Service)의 스토리지 옵션

AKS(Azure Kubernetes Service)에서 실행되는 애플리케이션은 데이터를 저장하고 검색해야 할 수 있습니다. 일부 애플리케이션 워크로드는 불필요하고 비어 있는 노드에 있는 고속 스토리지를 사용할 수 있지만, 다른 워크로드는 Azure 플랫폼 내에서 더 일반적인 데이터 볼륨에 유지되는 스토리지가 필요합니다.

여러 Pod는 다음을 수행해야 할 수 있습니다.

  • 동일한 데이터 볼륨을 공유합니다.
  • Pod가 다른 노드에서 다시 예약되면 데이터 볼륨을 다시 연결합니다.

중요한 데이터 또는 애플리케이션 구성 정보를 수집하여 Pod에 저장해야 할 수도 있습니다.

이 문서에서는 AKS에서 스토리지를 애플리케이션에 제공하는 핵심 개념을 소개합니다.

AKS(Azure Kubernetes Services) 클러스터의 애플리케이션에 대한 스토리지 옵션 다이어그램.

기본 OS 디스크 크기 조정

새 클러스터를 만들거나 새 노드 풀을 기존 클러스터에 추가하면 기본적으로 vCPU 수는 OS 디스크 크기에 따라 결정됩니다. vCPU 수는 VM SKU를 기반으로 합니다. 다음 표에는 각 VM SKU의 기본 OS 디스크 크기가 나열되어 있습니다.

VM SKU 코어(vCPU) 수 기본 OS 디스크 계층 프로비전되는 IOPS 프로비전된 처리량(Mbps)
1~7 P10/128G 500 100
8~15 P15/256G 1100 125
16~63 P20/512G 2300 150
64 이상 P30/1024G 5000 200

Important

기본 OS 디스크 크기 조정은 임시 OS 디스크가 지원되지 않고 기본 OS 디스크 크기가 지정되지 않은 경우에만 새 클러스터 또는 노드 풀에서 사용됩니다. 기본 OS 디스크 크기는 클러스터의 성능이나 비용에 영향을 미칠 수 있습니다. 클러스터 또는 노드 풀을 만든 후에는 OS 디스크 크기를 변경할 수 없습니다. 이 기본 디스크 크기 조정은 2022년 7월 이후에 만든 클러스터 또는 노드 풀에 영향을 줍니다.

사용 후 삭제 OS 디스크

기본적으로 Azure는 VM이 다른 호스트로 재배치될 때 데이터 손실을 방지하기 위해 가상 머신의 운영 체제 디스크를 Azure Storage에 자동으로 복제합니다. 그러나 컨테이너는 로컬 상태를 유지하도록 설계되지 않았기 때문에 이 동작은 제한된 가치를 제공하는 동시에 몇 가지 단점을 제공합니다. 이러한 단점에는 더 느린 노드 프로비전과 더 높은 읽기/쓰기 대기 시간이 포함되지만 이에 국한되지 않습니다.

이와 반대로 임시 OS 디스크는 임시 디스크처럼 호스트 머신에만 저장됩니다. 이 구성을 사용하면 더 빠른 노드 크기 조정 및 클러스터 업그레이드와 함께 읽기/쓰기 대기 시간이 줄어듭니다.

참고 항목

OS에 대한 Azure 관리 디스크를 명시적으로 요청하지 않으면 AKS는 지정된 노드 풀 구성에 사용 가능한 경우 임시 OS를 기본적으로 사용합니다.

임시 OS 디스크에 대한 크기 요구 사항 및 권장 사항은 Azure VM 설명서에서 확인할 수 있습니다. 다음은 몇 가지 일반적인 크기 조정 고려 사항입니다.

  • 기본 OS 디스크 크기가 100GiB인 AKS 기본 VM 크기 Standard_DS2_v2 SKU를 사용하도록 선택한 경우 기본 VM 크기는 임시 OS를 지원하지만 캐시 크기는 86GiB뿐입니다. 명시적으로 지정하지 않으면 이 구성은 관리 디스크로 기본 설정됩니다. 임시 OS를 요청하면 유효성 검사 오류가 발생합니다.

  • 60GiB OS 디스크가 있는 동일한 Standard_DS2_v2 SKU를 요청하는 경우 이 구성은 임시 OS로 기본 설정됩니다. 요청된 크기 60GiB는 최대 캐시 크기인 86GiB보다 작습니다.

  • 100GB OS 디스크가 포함된 Standard_D8s_v3 SKU를 선택하면 이 VM 크기는 임시 OS를 지원하고 200GiB의 캐시 공간이 있습니다. OS 디스크 형식을 지정하지 않으면 노드 풀은 기본적으로 임시 OS를 수신합니다.

최신 세대의 VM 시리즈에는 전용 캐시가 없고 임시 스토리지만 있습니다. 예를 들어 기본 OS 디스크 크기가 100GiB인 Standard_E2bds_v5 VM 크기를 선택한 경우 임시 OS 디스크를 지원하지만 75GB의 임시 스토리지만 있습니다. 이 구성은 명시적으로 지정하지 않으면 기본적으로 관리되는 OS 디스크가 됩니다. 임시 OS 디스크를 요청하면 유효성 검사 오류가 발생합니다.

  • 60GiB OS 디스크로 동일한 Standard_E2bds_v5 VM 크기를 요청하는 경우 이 구성은 임시 OS 디스크로 기본 설정됩니다. 요청된 크기 60GiB는 최대 임시 스토리지인 75GiB보다 작습니다.

  • 100GiB OS 디스크가 있는 Standard_E4bds_v5 SKU를 사용하기로 선택한 경우 이 VM 크기는 임시 OS를 지원하고 150GiB의 임시 스토리지가 있습니다. OS 디스크 유형을 지정하지 않으면 기본적으로 Azure는 임시 OS 디스크를 노드 풀에 프로비전합니다.

고객 관리형 키

AKS 클러스터에서 사용자 고유의 키를 사용하여 임시 OS 디스크에 대한 암호화를 관리할 수 있습니다. 자세한 내용은 AKS의 Azure 디스크에서 고객 관리형 키 사용을 참조하세요.

볼륨

Kubernetes는 일반적으로 개별 Pod를 삭제 가능한 임시 리소스로 취급합니다. 애플리케이션은 데이터를 사용하고 유지하는 데 사용할 수 있는 다양한 방법을 제공합니다. 볼륨은 Pod 간에 애플리케이션 수명 주기를 통해 데이터를 저장, 검색 및 유지하는 방법을 나타냅니다.

기존 볼륨은 Azure Storage에서 지원하는 Kubernetes 리소스로 만들어집니다. 데이터 볼륨은 수동으로 만들어 Pod에 직접 할당하거나 Kubernetes에서 자동으로 만들 수 있습니다. 데이터 볼륨은 Azure Disk, Azure Files, Azure NetApp Files 또는 Azure Blob을 사용할 수 있습니다.

참고 항목

사용 중인 VM SKU에 따라 Azure Disks CSI 드라이버에 노드당 볼륨 제한이 있을 수 있습니다. 일부 고성능 VM(예: 16개 코어)의 경우 한도는 노드당 64개 볼륨입니다. VM SKU당 한도를 확인하려면 제공된 각 VM SKU에 대한 최대 데이터 디스크 열을 검토합니다. 제공되는 VM SKU 및 해당 세부 용량 한도의 목록을 보려면 범용 가상 머신 크기를 참조하세요.

Azure Files와 Azure NetApp Files 간의 워크로드에 가장 적합한 항목을 확인하려면 Azure Files 및 Azure NetApp Files 비교 문서에 제공된 정보를 검토하세요.

Azure Disk

Azure Disk를 사용하여 Kubernetes DataDisk 리소스를 만듭니다. 디스크 유형에는 다음이 포함됩니다.

  • 프리미엄 SSD(대부분의 워크로드에 권장)
  • Ultra disks
  • 표준 SSD
  • 표준 HDD

대부분의 프로덕션 및 개발 워크로드에는 Premium SSD를 사용하세요.

Azure Disk는 ReadWriteOnce로 탑재되므로 단일 노드에서만 사용할 수 있습니다. 여러 노드의 Pod에서 동시에 액세스할 수 있는 스토리지 볼륨의 경우 Azure Files를 사용합니다.

Azure 파일

Azure Files를 사용하여 SMB(서버 메시지 블록) 버전 3.1.1 공유 또는 NFS(네트워크 파일 시스템) 버전 4.1 공유를 탑재합니다. Azure Files를 통해 여러 노드 및 Pod 간에 데이터를 공유하고 다음을 사용할 수 있습니다.

  • 고성능 SSD로 지원되는 Azure Premium 스토리지
  • 일반 HDD로 지원되는 Azure Standard 스토리지

Azure NetApp Files

  • Ultra Storage
  • Premium Storage
  • Standard Storage

Azure Blob Storage

Azure Blob Storage를 사용하여 Blob 스토리지 컨테이너를 만들고 NFS v3.0 프로토콜 또는 BlobFuse를 사용하여 이를 탑재합니다.

  • 블록 Blob

볼륨 유형

Kubernetes 볼륨은 단순히 정보를 저장하고 검색하는 데 사용되는 일반적인 디스크를 뛰어넘습니다. 또한 Kubernetes 볼륨은 컨테이너에서 사용할 수 있도록 데이터를 Pod에 삽입하는 방법으로도 사용할 수 있습니다.

Kubernetes의 일반적인 볼륨 유형은 다음과 같습니다.

emptyDir

일반적으로 Pod용 임시 공간으로 사용됩니다. Pod 내의 모든 컨테이너는 볼륨의 데이터에 액세스할 수 있습니다. 이 볼륨 형식에 기록된 데이터는 Pod의 수명 기간 동안에만 지속됩니다. Pod를 삭제하면 볼륨도 삭제됩니다. 이 볼륨은 일반적으로 기본 로컬 노드 디스크 스토리지를 사용하지만 노드의 메모리에만 존재할 수도 있습니다.

secret

비밀 볼륨을 사용하여 암호와 같은 중요한 데이터를 Pod에 삽입할 수 있습니다.

  1. Kubernetes API를 사용하여 비밀을 만듭니다.
  2. Pod 또는 배포를 정의하고 특정 비밀을 요청합니다.
    • 비밀은 비밀을 요구하는 예약된 Pod가 있는 노드에만 제공됩니다.
    • 비밀은 디스크에 기록되지 않고 tmpfs에 저장됩니다.
  3. 비밀을 요구하는 노드에서 마지막 Pod를 삭제하면 해당 비밀이 노드의 tmpfs에서 삭제됩니다.
    • 비밀은 지정된 네임스페이스 내에 저장되며 동일한 네임스페이스 내의 Pod에서만 액세스됩니다.

configMap

configMap을 사용하여 애플리케이션 구성 정보와 같은 키-값 쌍 속성을 Pod에 삽입할 수 있습니다. 애플리케이션 구성 정보를 새 Pod 인스턴스가 배포되면 손쉽게 업데이트하고 적용할 수 있는 Kubernetes 리소스로 정의합니다.

다음과 같이 비밀을 사용하는 것과 같습니다.

  1. Kubernetes API를 사용하여 ConfigMap을 만듭니다.
  2. Pod 또는 배포를 정의할 때 ConfigMap을 요청합니다.
    • ConfigMaps는 지정된 네임스페이스 내에 저장되며 동일한 네임스페이스 내의 Pod에서만 액세스됩니다.

영구적 볼륨

Pod 수명 주기의 일부로 정의되고 만들어진 볼륨은 Pod가 삭제될 때까지만 존재합니다. 유지 관리 이벤트 중에 한 Pod가 다른 호스트에, 특히 StatefulSets에 다시 예약되는 경우 Pods에서 스토리지가 남아 있을 것으로 예상합니다. PV(영구적 볼륨)는 Kubernetes API에서 만들어지고 관리되는 스토리지 리소스로 개별 Pod의 수명을 초과하여 존재할 수 있습니다.

다음 Azure Storage 서비스를 사용하여 영구 볼륨을 제공할 수 있습니다.

볼륨 섹션에서 설명한 대로, 데이터 또는 성능 계층에 대한 동시 액세스의 필요성에 따라 Azure Disks 또는 Azure Files를 선택하는 경우가 많습니다.

AKS(Azure Kubernetes Services) 클러스터의 영구 볼륨 다이어그램.

클러스터 관리자는 PersistentVolume을 정적으로 만들거나 Kubernetes API 서버에서 볼륨을 동적으로 만들 수 있습니다. Pod가 예약되어 있고 현재 사용할 수 없는 스토리지를 요청하는 경우 Kubernetes에서 기본 Azure Disks 또는 Azure File 스토리지를 만들어 해당 Pod에 연결할 수 있습니다. 동적 프로비전은 스토리지 클래스를 사용하여 만들어야 하는 리소스의 유형을 식별합니다.

Important

두 운영 체제 간의 파일 시스템 지원 차이로 인해 Windows 및 Linux Pod에서 영구 볼륨을 공유할 수 없습니다.

데이터에 대한 블록 수준 액세스를 위한 완전 관리형 솔루션을 원하는 경우 CSI 드라이버 대신 Azure Container Storage를 사용하는 것이 좋습니다. Azure Container Storage는 Kubernetes와 통합되어 영구 볼륨의 동적 및 자동 프로비저닝을 허용합니다. Azure Container Storage는 Azure Disks, 임시 디스크 및 Azure Elastic SAN(미리 보기)을 백업 스토리지로 지원하여 Kubernetes 클러스터에서 실행되는 상태 저장 애플리케이션에 유연성과 확장성을 제공합니다.

스토리지 클래스

Premium 또는 Standard와 같은 다른 계층의 스토리지를 지정하기 위해 스토리지 클래스를 만들 수 있습니다.

스토리지 클래스는 회수 정책을 정의합니다. 영구 볼륨을 삭제하면 회수 정책은 기본 Azure Storage 리소스의 동작을 제어합니다. 기본 리소스는 삭제하거나 나중에 Pod에서 사용할 수 있도록 유지할 수 있습니다.

Azure Container Storage를 사용하는 클러스터의 경우 호출acstor-<storage-pool-name>된 추가 스토리지 클래스가 표시됩니다. 내부 스토리지 클래스도 만들어집니다.

CSI(Container Storage Interface) 드라이버를 사용하는 클러스터의 경우 다음과 같은 추가 스토리지 클래스가 만들어집니다.

스토리지 클래스 설명
managed-csi Azure Standard SSD LRS(로컬 중복 스토리지)를 사용하여 관리 디스크를 만듭니다. 회수 정책은 사용된 영구 볼륨이 삭제되면 기본 Azure Disk도 삭제되도록 합니다. 또한 스토리지 클래스는 영구 볼륨을 확장할 수 있도록 구성합니다. 영구 볼륨 클레임을 편집하여 새 크기를 지정할 수 있습니다. Kubernetes 버전 1.29부터 여러 가용성 영역에 배포된 AKS(Azure Kubernetes Service) 클러스터에서 이 스토리지 클래스는 Azure 표준 SSD ZRS(영역 중복 스토리지)를 활용하여 관리 디스크를 만듭니다.
managed-csi-premium Azure Premium LRS(로컬 중복 스토리지)를 사용하여 관리 디스크를 만듭니다. 또 다시 회수 정책은 사용된 영구 볼륨이 삭제되면 기본 Azure Disk도 삭제되도록 합니다. 마찬가지로, 이 스토리지 클래스는 영구 볼륨을 확장할 수 있도록 합니다. Kubernetes 버전 1.29부터 여러 가용성 영역에 배포된 AKS(Azure Kubernetes Service) 클러스터에서 이 스토리지 클래스는 Azure Premium ZRS(영역 중복 스토리지)를 활용하여 관리 디스크를 만듭니다.
azurefile-csi Azure Standard 스토리지를 사용하여 Azure 파일 공유를 만듭니다. 회수 정책을 사용하면 사용된 영구 볼륨이 삭제될 때 기본 Azure 파일 공유가 삭제됩니다.
azurefile-csi-premium Azure Premium Storage를 사용하여 Azure 파일 공유를 만듭니다. 회수 정책을 사용하면 사용된 영구 볼륨이 삭제될 때 기본 Azure 파일 공유가 삭제됩니다.
azureblob-nfs-premium Azure Premium Storage를 사용하여 Azure Blob 스토리지 컨테이너를 만들고 NFS v3 프로토콜을 사용하여 연결합니다. 회수 정책은 사용한 영구 볼륨이 삭제될 때 기본 Azure Blob 스토리지 컨테이너도 삭제되도록 합니다.
azureblob-fuse-premium Azure Premium Storage를 사용하여 Azure Blob 스토리지 컨테이너를 만들고 BlobFuse를 사용하여 연결합니다. 회수 정책은 사용한 영구 볼륨이 삭제될 때 기본 Azure Blob 스토리지 컨테이너도 삭제되도록 합니다.

영구 볼륨에 스토리지 클래스를 지정하지 않으면 기본 스토리지 클래스가 사용됩니다. 영구 볼륨을 요청할 때는 볼륨이 필요한 스토리지를 적절히 사용하도록 해야 합니다.

Important

Kubernetes 버전 1.21부터 AKS는 기본적으로 CSI 드라이버를 사용하고 CSI 마이그레이션을 사용하도록 설정합니다. 기존 트리 내 영구 볼륨은 버전 1.26부터 계속 작동하지만 AKS는 더 이상 파일 및 디스크에 프로비전된 트리 내 드라이버 및 스토리지를 사용하여 만든 볼륨을 지원하지 않습니다.

default 클래스는 managed-csi와 동일합니다.

Kubernetes 버전 1.29부터 효과적으로 AKS(Azure Kubernetes Service) 클러스터를 여러 가용성 영역에 배포할 때 AKS는 이제 ZRS(영역 중복 스토리지)를 활용하여 기본 제공 스토리지 클래스 내에 관리 디스크를 만듭니다. ZRS는 선택한 지역의 여러 Azure 가용성 영역에서 Azure 관리 디스크의 동기 복제를 보장합니다. 이 중복성 전략은 애플리케이션의 복원력을 강화하고 데이터 센터 오류로부터 데이터를 보호합니다.

그러나 ZRS(영역 중복 스토리지)는 LRS(로컬 중복 스토리지)에 비해 비용이 더 높다는 점에 유의해야 합니다. 비용 최적화가 우선 순위인 경우 skuname 매개 변수를 LRS로 설정하여 새 스토리지 클래스를 만들 수 있습니다. 그런 다음 PVC(영구 볼륨 클레임)에서 새 스토리지 클래스를 사용할 수 있습니다.

kubectl을(를) 사용하여 다른 요구 사항에 맞게 스토리지 클래스를 만들 수 있습니다. 다음 예제에서는 Premium Managed Disks를 사용하고, 사용자가 Pod를 삭제하면 기본 Azure Disk를 유지해야 한다고 지정합니다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-premium-retain
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_ZRS
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

참고 항목

AKS는 기본 스토리지 클래스를 조정하고 해당 스토리지 클래스에 대한 모든 변경 내용을 덮어씁니다.

스토리지 클래스에 대한 자세한 내용은 Kubernetes의 StorageClass를 참조하세요.

영구적 볼륨 클레임

PVC(영구 볼륨 클레임)는 특정 스토리지 클래스, 액세스 모드 및 크기의 스토리지를 요청합니다. 정의된 스토리지 클래스에 따라 클레임을 처리할 수 있는 기존 리소스가 없는 경우 Kubernetes API 서버는 기본 Azure 스토리지 리소스를 동적으로 프로비전할 수 있습니다.

볼륨이 Pod에 연결되면 Pod 정의에 볼륨 탑재가 포함됩니다.

AKS(Azure Kubernetes Services) 클러스터의 영구 볼륨 클레임 다이어그램.

사용 가능한 스토리지 리소스가 스토리지를 요청한 Pod에 할당되면 영구 볼륨이 영구 볼륨 클레임에 바인딩됩니다. 영구 볼륨은 클레임에 1:1 매핑됩니다.

다음 예제 YAML 매니페스트는 managed-premium 스토리지 클래스를 사용하고 5Gi의 Azure Disk 크기를 요청하는 영구 볼륨 클레임을 보여 줍니다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azure-managed-disk
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-premium-retain
  resources:
    requests:
      storage: 5Gi

Pod 정의를 만들 때는 다음도 지정합니다.

  • 필요한 스토리지를 요청할 영구 볼륨 클레임
  • 애플리케이션에서 데이터를 읽고 쓰는 데 필요한 볼륨 탑재입니다.

다음 YAML 매니페스트 예제에서는 이전의 영구적 볼륨 클레임을 사용하여 볼륨을 /mnt/azure에 탑재하는 방법을 보여 줍니다.

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      volumeMounts:
      - mountPath: "/mnt/azure"
        name: volume
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: azure-managed-disk

Windows 컨테이너에서 볼륨을 탑재하려면 드라이브 문자 및 경로를 지정합니다. 예시:

...      
      volumeMounts:
      - mountPath: "d:"
        name: volume
      - mountPath: "c:\k"
        name: k-dir
...

다음 단계

관련 모범 사례는 AKS 및 AKS 스토리지 고려 사항의 스토리지 및 백업에 대한 모범 사례를 참조하세요.

Azure Container Storage에 대한 자세한 내용은 다음 문서를 참조하세요.

CSI 드라이버 사용에 대한 자세한 내용은 다음 문서를 참조하세요.

Kubernetes 및 AKS 핵심 개념에 대한 자세한 내용은 다음 문서를 참조하세요.