다음을 통해 공유

Kubernetes 클러스터에 대한 스토리지 옵션

이 문서에서는 Amazon Elastic Kubernetes Service(EKS) 및 AKS(Azure Kubernetes Service)의 스토리지 기능을 비교합니다. 또한 AKS의 워크로드 데이터에 대한 스토리지 옵션에 대해서도 설명합니다.

참고

이 문서는 Amazon EKS에 익숙한 전문가가 AKS(Azure Kubernetes Service)를 이해하는 데 도움이 되는 일련의 문서의 일부입니다.

Amazon EKS 스토리지 옵션

Amazon EKS는 데이터 스토리지가 필요한 애플리케이션에 대해 다양한 유형의 스토리지 볼륨을 제공합니다. 이러한 볼륨은 일시적이고 오래 지속되는 스토리지에 사용할 수 있습니다.

단기 볼륨

임시 로컬 볼륨이 필요하지만 다시 시작한 후 데이터를 유지할 필요가 없는 애플리케이션의 경우 임시 볼륨을 사용합니다. Kubernetes는 emptyDir, ConfigMap, downwardAPI, secret 및 hostPath와 같은 다양한 유형의 임시 볼륨을 지원합니다. 비용 효율성과 성능을 보장하려면 가장 적절한 호스트 볼륨을 선택합니다. Amazon EKS에서는 gp3 를 호스트 루트 볼륨으로 사용할 수 있습니다. 이 볼륨은 gp2 볼륨보다 저렴합니다.

EC2 인스턴스에 대한 임시 블록 수준 스토리지를 제공하는 Amazon EC2 인스턴스 저장소를 사용할 수도 있습니다. 이러한 볼륨은 호스트에 물리적으로 연결되며 인스턴스의 수명 동안에만 존재합니다. Kubernetes에서 로컬 저장소 볼륨을 사용하려면 Amazon EC2 사용자 데이터를 사용하여 디스크를 분할, 구성 및 포맷해야 합니다.

영구 볼륨

일반적으로 Kubernetes를 사용하여 상태 비저장 애플리케이션을 실행하지만 경우에 따라 영구 데이터 스토리지가 필요합니다. Kubernetes 영구 볼륨을 사용하여 데이터가 지정된 Pod의 수명 이후에도 지속될 수 있도록 Pod와 독립적으로 데이터를 저장할 수 있습니다. Amazon EKS는 Amazon EBS, Amazon ElasticFile System(EFS),Amazon FSx for Lustre 및 NetApp ONTAP용 Amazon FSx를 포함하여 영구 볼륨에 대한 다양한 유형의 스토리지 옵션을 지원합니다.

블록 수준 스토리지 및 데이터베이스 및 처리량이 많은 애플리케이션에 Amazon EBS 볼륨을 사용합니다. Amazon EKS 사용자는 가격과 성능 간의 균형을 위해 최신 세대의 블록 스토리지 gp3 사용할 수 있습니다. 고성능 애플리케이션의 경우 io2 블록 Express 볼륨을 사용할 수 있습니다.

Amazon EFS 는 여러 컨테이너 및 노드에서 공유할 수 있는 서버리스 탄력적 파일 시스템입니다. 파일이 추가되거나 제거되면 자동으로 증가 및 축소되므로 용량 계획이 필요하지 않습니다. Amazon EFS CSI(Container Storage Interface) 드라이버는 Amazon EFS를 Kubernetes와 통합합니다.

Lustre용 Amazon FSx 는 고성능 병렬 파일 스토리지를 제공합니다. 처리량이 높고 대기 시간이 짧은 작업이 필요한 시나리오에는 이 유형의 스토리지를 사용합니다. 이 파일 스토리지를 Amazon S3 데이터 리포지토리에 연결하여 큰 데이터 세트를 저장할 수 있습니다. NetApp ONTAP용 Amazon FSx는 NetApp의 ONTAP 파일 시스템을 기반으로 하는 완전 관리형 공유 스토리지 솔루션입니다.

스토리지 구성을 최적화하고 백업 및 스냅샷을 관리하려면 AWS 컴퓨팅 최적화 프로그램 및 Velero와 같은 도구를 사용합니다.

AKS 스토리지 옵션

AKS에서 실행되는 애플리케이션은 데이터를 저장하고 검색해야 할 수 있습니다. 일부 애플리케이션 워크로드는 불필요한 빈 노드에서 로컬의 빠른 스토리지를 사용할 수 있습니다. 그러나 다른 애플리케이션 워크로드에는 Azure 플랫폼 내에서 더 일반적인 데이터 볼륨에 유지되는 스토리지가 필요합니다. 여러 파드는 다음 작업을 수행할 필요가 있을 수 있습니다.

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

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

볼륨 유형

Kubernetes 볼륨은 정보를 저장하고 검색하는 기존 디스크 이상을 나타냅니다. Kubernetes 볼륨을 사용하여 해당 컨테이너에서 사용할 데이터를 Pod에 삽입할 수도 있습니다.

Kubernetes의 일반적인 볼륨 유형에는 emptyDirs, 비밀 및 ConfigMaps가 포함됩니다.

EmptyDirs

emptyDir 볼륨을 정의하는 Pod의 경우 Pod가 노드에 할당될 때 볼륨이 생성됩니다. 이름에서 설명한 대로 emptyDir 볼륨은 처음에 비어 있습니다. 이 볼륨은 각 컨테이너의 동일하거나 다른 경로에 탑재할 수 있지만 Pod의 모든 컨테이너는 emptyDir 볼륨에서 동일한 파일을 읽고 쓸 수 있습니다. 어떤 이유로든 노드에서 Pod가 제거되면 emptyDir의 데이터가 영구적으로 삭제됩니다.

비밀

비밀은 암호, 토큰 또는 키와 같은 소량의 중요한 데이터를 보유하는 개체입니다. 비밀을 사용하지 않는 경우 이 정보는 Pod 사양 또는 컨테이너 이미지에 포함됩니다. 비밀은 기밀 데이터를 애플리케이션 코드에 직접 포함할 필요가 없도록 합니다. Pod을 사용하는 것과 관계없이 비밀을 만들 수 있습니다. 이렇게 하면 Pod를 만들고, 보고, 편집할 때 비밀 및 해당 데이터를 노출할 위험이 줄어듭니다. Kubernetes 및 클러스터에서 실행되는 애플리케이션은 중요한 데이터가 비휘발성 스토리지에 기록되지 않도록 방지하는 등 비밀에 대한 추가 예방 조치를 취할 수 있습니다. 비밀은 ConfigMaps와 유사하지만 기밀 데이터를 저장하도록 특별히 설계되었습니다.

다음과 같은 용도로 비밀을 사용할 수 있습니다.

또한 Kubernetes 컨트롤 플레인은 부트스트랩 토큰 비밀과 같은 비밀을 사용하여 노드 등록을 자동화합니다.

ConfigMaps

ConfigMap은 비밀이 아닌 데이터를 키-값 쌍으로 저장하는 데 사용하는 Kubernetes 개체입니다. Pods 환경 변수, 명령줄 인수로 또는 볼륨의구성 파일로 ConfigMaps를 사용할 수 있습니다. ConfigMap을 사용하여 컨테이너 이미지에서 환경별 구성을 분리하여 애플리케이션을 쉽게 이식할 수 있습니다.

ConfigMaps는 비밀 또는 암호화를 제공하지 않습니다. 기밀 데이터를 저장하려면 ConfigMap 대신 비밀을 사용하거나 다른 파트너 도구를 사용하여 데이터를 비공개로 유지합니다.

ConfigMap을 사용하여 애플리케이션 코드와 별도로 구성 데이터를 설정할 수 있습니다. 예를 들어 개발을 위해 컴퓨터에서 실행하고 실제 트래픽을 처리하기 위해 클라우드에서 실행할 애플리케이션을 개발할 수 있습니다. 라는 환경 변수 DATABASE_HOST를 찾는 코드를 작성할 수 있습니다. 로컬에서 해당 변수를 .로 localhost설정합니다. 클라우드에서 데이터베이스 구성 요소를 클러스터에 노출하는 Kubernetes 서비스를 참조하도록 설정합니다. 이 방법을 사용하면 클라우드에서 실행되는 컨테이너 이미지를 가져오고 필요한 경우 동일한 코드를 로컬로 디버그할 수 있습니다.

영구 볼륨

Pod 수명 주기의 일부로 정의되고 생성된 볼륨은 Pod를 삭제할 때까지만 존재합니다. Pod는 유지보수 이벤트 동안, 특히 StatefulSets의 경우, Pod가 다른 호스트에 다시 예약될 때 스토리지가 계속 유지되기를 기대합니다. 영구 볼륨은 Kubernetes API가 만들고 관리하는 스토리지 리소스입니다. 영구적 볼륨은 개별 Pod의 수명 외에 존재할 수 있습니다. 다음 Azure Storage 도구를 사용하여 영구 볼륨을 제공할 수 있습니다.

Azure Disk Storage 또는 Azure Files 중에서 결정하려면 애플리케이션에 동시 데이터 액세스 또는 특정 성능 계층이 필요한지 여부를 고려합니다.

AKS 클러스터의 영구 볼륨 다이어그램

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

중요하다

운영 체제가 다른 파일 시스템을 지원하므로 Windows 및 Linux Pod는 영구 볼륨을 공유할 수 없습니다.

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

스토리지 클래스

프리미엄 또는 표준과 같은 다른 스토리지 계층을 지정하려면 스토리지 클래스를 만들 수 있습니다.

스토리지 클래스는 회수 정책정의합니다. 영구 볼륨을 삭제하면 회수 정책이 기본 Azure Storage 리소스의 동작을 제어합니다. 기본 리소스는 삭제하거나 향후 Pod와 함께 사용하기 위해 보관할 수 있습니다.

Azure Container Storage를 사용하는 클러스터에는 추가 스토리지 클래스가 있습니다acstor-<storage-pool-name>. 내부 스토리지 클래스도 만들어집니다.

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

저장소 클래스 설명
managed-csi LRS(로컬 중복 스토리지)와 함께 Azure Standard SSD를 사용하여 관리 디스크를 만듭니다. 회수 정책을 사용하면 사용된 영구 볼륨이 삭제될 때 기본 Azure 디스크가 삭제됩니다. 또한 스토리지 클래스는 영구 볼륨을 확장할 수 있도록 구성합니다. 영구 볼륨 클레임을 편집하여 새 크기를 지정할 수 있습니다.

Kubernetes 버전 1.29 이상의 경우 이 스토리지 클래스는 ZRS(영역 중복 스토리지)와 표준 SSD를 사용하여 여러 가용성 영역에 배포된 AKS 클러스터용 관리 디스크를 만듭니다.
managed-csi-premium LRS와 함께 Azure Premium SSD를 사용하여 관리 디스크를 만듭니다. 회수 정책을 사용하면 사용된 영구 볼륨이 삭제될 때 기본 Azure 디스크가 삭제됩니다. 이 스토리지 클래스를 사용하면 영구 볼륨을 확장할 수 있습니다.

Kubernetes 버전 1.29 이상의 경우 이 스토리지 클래스는 ZRS와 함께 프리미엄 SSD를 사용하여 여러 가용성 영역에 배포된 AKS 클러스터용 관리 디스크를 만듭니다.
azurefile-csi 표준 SSD 스토리지를 사용하여 Azure 파일 공유를 만듭니다. 회수 정책을 사용하면 사용된 영구 볼륨이 삭제될 때 기본 Azure 파일 공유가 삭제됩니다.
azurefile-csi-premium 프리미엄 SSD 스토리지를 사용하여 Azure 파일 공유를 만듭니다. 회수 정책을 사용하면 사용된 영구 볼륨이 삭제될 때 기본 Azure 파일 공유가 삭제됩니다.
azureblob-nfs-premium 프리미엄 SSD 스토리지를 사용하여 Blob Storage 컨테이너를 만들고 NFS(네트워크 파일 시스템) v3 프로토콜을 통해 연결합니다. 회수 정책은 사용된 영구 볼륨이 삭제될 때 기본 Blob Storage 컨테이너가 삭제되도록 합니다.
azureblob-fuse-premium 프리미엄 SSD 스토리지를 사용하여 Blob Storage 컨테이너를 만들고 BlobFuse를 통해 연결합니다. 회수 정책은 사용된 영구 볼륨이 삭제될 때 기본 Blob Storage 컨테이너가 삭제되도록 합니다.

영구 볼륨에 대한 스토리지 클래스를 지정하지 않는 한 기본 스토리지 클래스가 사용됩니다. 볼륨이 영구 볼륨을 요청할 때 필요한 스토리지를 사용하는지 확인합니다.

중요하다

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

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

Kubernetes 버전 1.29 이상의 경우 여러 가용성 영역에 AKS 클러스터를 배포할 때 AKS는 ZRS를 사용하여 기본 제공 스토리지 클래스 내에서 관리 디스크를 만듭니다. ZRS는 선택한 지역의 여러 Azure 가용성 영역에서 Azure 관리 디스크의 동기 복제를 보장합니다. 이 중복 전략은 애플리케이션의 복원력을 향상시키고 데이터 센터 오류으로부터 데이터를 보호하는 데 도움이 됩니다.

그러나 ZRS는 LRS보다 더 많은 비용이 듭니다. 비용 최적화가 우선 순위인 경우 매개 변수가 LRS로 설정된 새 스토리지 클래스를 skuname 만들 수 있습니다. 그런 다음 영구 볼륨 클레임에서 새 스토리지 클래스를 사용할 수 있습니다.

를 사용하여 kubectl다른 요구 사항에 맞게 스토리지 클래스를 만들 수 있습니다. 다음 예제에서는 프리미엄 관리 디스크를 사용하고 Pod를 삭제할 때 기본 Azure 디스크 를 보존 해야 한다고 지정합니다.

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를 참조하세요.

영구 볼륨 클레임

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

Pod 정의에는 볼륨이 Pod에 연결된 후에 볼륨 마운트가 포함됩니다.

AKS 클러스터의 영구 볼륨 클레임 다이어그램.

스토리지를 요청하는 Pod에 사용 가능한 스토리지 리소스가 할당되면 영구 볼륨이 영구 볼륨 클레임에 바인딩 됩니다. 각 영구 볼륨은 전용 스토리지를 보장하기 위해 하나의 영구 볼륨 클레임과 연결됩니다.

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

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
...

임시 OS 디스크

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

반면 임시 OS 디스크는 임시 디스크와 같이 호스트 컴퓨터에만 저장됩니다. 이 구성은 읽기 및 쓰기 대기 시간을 낮추고 노드 크기 조정 및 클러스터 업그레이드를 더 빠르게 제공합니다.

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

크기 요구 사항 및 권장 사항은 Azure VM에 대한 임시 OS 디스크를 참조하세요. 다음 크기 조정 고려 사항을 고려합니다.

  • 기본 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 크기를 선택하면 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 디스크 스토리지, Azure Files, Azure NetApp Files 또는 Blob Storage를 사용할 수 있습니다.

참고

VM SKU에 따라 Azure 디스크 CSI 드라이버에 각 노드에 대한 볼륨 제한이 있을 수 있습니다. 16개 코어와 같은 일부 고성능 VM의 경우 한도는 노드당 64개 볼륨입니다. VM SKU당 제한을 식별하려면 각 VM SKU에 대한 최대 데이터 디스크 열을 검토합니다. VM SKU 및 해당 용량 제한 목록은 범용 VM 크기를 참조하세요.

Azure Files와 Azure NetApp Files 중에서 결정하려면 Azure Files 및 Azure NetApp Files 비교를 참조하세요.

Azure 디스크 스토리지

기본적으로 AKS 클러스터는 managed-csi를 managed-csi-premium 사용하는 미리 생성된 스토리지 클래스와 함께 제공됩니다. Amazon EBS와 마찬가지로 이러한 클래스는 Pod 액세스를 위해 노드에 연결된 관리 디스크 또는 차단 디바이스를 만듭니다.

디스크 클래스는 정적 및 동적 볼륨 프로비저닝을 모두 허용합니다. 회수 정책은 영구 볼륨을 사용하여 디스크가 삭제되도록 합니다. 디스크를 확장하려면 영구 볼륨 클레임을 편집합니다.

이러한 스토리지 클래스는 LRS에서 Azure 관리 디스크를 사용합니다. LRS의 데이터에는 Azure 주 지역의 단일 물리적 위치 내에 세 개의 동기 복사본이 있습니다. LRS는 가장 저렴한 복제 옵션이지만 데이터 센터 오류에 대한 보호를 제공하지 않습니다. ZRS 관리 디스크를 사용하는 사용자 지정 스토리지 클래스를 정의할 수 있습니다.

ZRS는 해당 지역의 세 Azure 가용성 영역에서 Azure 관리 디스크를 동기적으로 복제합니다. 각 가용성 영역은 독립적인 전원, 냉각 및 네트워킹이 있는 별도의 물리적 위치입니다. ZRS 디스크는 지정된 1년 동안 최소 99.99999999999999% 내구성을 제공합니다. ZRS 관리 디스크는 다른 가용성 영역의 VM에 의해 연결될 수 있습니다. ZRS 디스크는 모든 Azure 지역에서 사용할 수 없습니다. 자세한 내용은 가용성을 개선하기 위해 Azure 디스크에 대한 ZRS 옵션을 참조하세요.

데이터 손실의 위험을 완화하려면 AKS 백업 을 사용하여 디스크 스토리지 데이터의 정기적인 백업 또는 스냅샷을 만듭니다. 또는 기본 제공 스냅샷 기술이 있는 Velero 또는 Azure Backup과 같은 파트너 솔루션을 사용할 수 있습니다.

Azure Disk Storage를 사용하여 Kubernetes DataDisk 리소스를 만들 수 있습니다. 다음 디스크 유형을 사용할 수 있습니다.

팁

대부분의 프로덕션 및 개발 워크로드의 경우 프리미엄 SSD를 사용합니다.

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

프리미엄 SSD v2 디스크

프리미엄 SSD v2 디스크 는 입/출력(I/O)의 강력한 엔터프라이즈 워크로드용으로 설계되었습니다. 일관된 하위 밀리초 디스크 대기 시간, IOPS(초당 높은 입력/출력 작업) 및 높은 처리량을 제공합니다. 언제든지 프리미엄 SSD v2 디스크의 성능(용량, IOPS 및 처리량)을 독립적으로 구성할 수 있습니다. 따라서 성능 요구 사항을 충족하는 동안 비용 효율성을 쉽게 향상시킬 수 있습니다. Azure Premium SSD v2 디스크를 사용하도록 새 AKS 클러스터 또는 기존 AKS 클러스터를 구성하는 방법에 대한 자세한 내용은 AKS에서 프리미엄 SSD v2 디스크 사용을 참조하세요.

울트라 디스크 스토리지

Ultra Disk Storage는 Azure VM에 대해 높은 처리량, 높은 IOPS 및 일관된 짧은 대기 시간 디스크 스토리지를 제공하는 Azure 관리 디스크 계층입니다. 데이터 집약적이고 트랜잭션이 많은 워크로드에 Ultra Disk Storage를 사용합니다. 다른 디스크 스토리지 SKU 및 Amazon EBS와 마찬가지로 Ultra Disk Storage는 한 번에 하나의 Pod를 탑재하며 동시 액세스를 제공하지 않습니다.

AKS 클러스터에서 Ultra Disk Storage를 사용하도록 설정하려면 플래그--enable-ultra-ssd를 사용합니다.

Ultra Disk Storage 제한 사항에 유의하고 호환되는 VM 크기를 선택합니다. Ultra Disk Storage에는 LRS 복제가 있습니다.

사용자 고유의 키(BYOK)를 가져옵니다.

Azure는 AKS 클러스터의 OS 및 데이터 디스크를 포함하여 미사용 관리 디스크의 모든 데이터를 암호화합니다. 기본적으로 데이터는 Microsoft 관리형 키로 암호화됩니다. 암호화 키를 보다 제어하기 위해 AKS 클러스터의 OS 및 데이터 디스크 모두에 미사용 암호화를 제공하는 고객 관리형 키를 제공할 수 있습니다. 자세한 내용은 AKS의 Azure 관리 디스크를 사용한 BYOK 및 Azure 디스크 스토리지의 서버 쪽 암호화를 참조하세요.

Azure 파일 서비스

디스크 스토리지는 볼륨에 대한 동시 액세스를 제공할 수 없지만 Azure Files를 사용하여 Azure Storage 에서 지원되는 SMB(서버 메시지 블록) 버전 3.1.1 공유 또는 NFS 버전 4.1 공유를 탑재할 수 있습니다. 이 프로세스는 Amazon EFS와 유사한 네트워크 연결 스토리지를 제공합니다. Azure Files에는 다음 두 가지 스토리지 옵션이 있습니다.

  • Azure Files Standard 스토리지는 일반 HDD(하드 디스크 드라이브)를 사용하여 파일 공유를 백업합니다.

  • Azure Files Premium Storage는 고성능 SSD(반도체 드라이브)를 사용하여 파일 공유를 백업합니다. 프리미엄의 최소 파일 공유 크기는 100GB입니다.

Azure Files에는 오류가 발생하는 경우 데이터를 보호하기 위한 다음과 같은 스토리지 계정 복제 옵션이 있습니다.

Azure Files의 비용을 최적화하려면 Azure Files 용량 예약을 구매합니다.

Azure NetApp 파일

Azure NetApp Files는 Azure 에서 실행되며 NFS(NFSv3 또는 NFSv4.1), SMB 및 이중 프로토콜 (NFSv3 및 SMB 또는 NFSv4.1 및 SMB) 볼륨을 사용하여 볼륨을 지원하는 엔터프라이즈급 고성능 요금제 파일 스토리지 서비스입니다. Kubernetes 사용자에게는 Kubernetes 워크로드에 Azure NetApp Files 볼륨을 사용하는 두 가지 옵션이 있습니다.

  • Azure NetApp Files 볼륨을 정적으로 만듭니다. Azure CLI 또는 Azure Portal을 통해 AKS 외부에서 볼륨을 만듭니다. 만든 후, 이러한 볼륨은 PersistentVolume을 만들어 Kubernetes에 노출됩니다. 정적으로 생성된 Azure NetApp Files 볼륨에는 많은 제한 사항이 있습니다. 예를 들어 확장할 수 없으며 과도하게 프로비전해야 합니다. 대부분의 사용 사례에는 정적으로 생성된 볼륨을 권장하지 않습니다.

  • Kubernetes를 통해 동적으로 Azure NetApp Files 볼륨을 만듭니다. 이는 Astra Trident를 사용하여 Kubernetes를 통해 직접 여러 볼륨을 만드는 기본 방법입니다. Astra Trident는 Kubernetes를 통해 기본적으로 볼륨을 프로비전하는 데 도움이 되는 CSI 규격 동적 스토리지 오케스트레이터입니다.

자세한 내용은 AKS용 Azure NetApp Files 구성을 참조하세요.

블롭 저장소

Blob Storage CSI 드라이버는 AKS가 Blob Storage의 수명 주기를 관리하는 데 사용하는 CSI 사양 규격 드라이버입니다. CSI는 Kubernetes의 컨테이너화된 워크로드에 임의 블록 및 파일 스토리지 시스템을 노출하는 표준입니다.

AKS에서 플러그 인을 작성, 배포 및 반복할 수 있도록 CSI를 채택하고 사용합니다. 플러그 인은 새 스토리지 시스템을 노출하거나 Kubernetes의 기존 스토리지 시스템을 개선합니다. AKS의 CSI 드라이버는 핵심 Kubernetes 코드를 수정하고 릴리스 주기를 기다릴 필요가 없습니다.

Blob Storage를 파일 시스템으로 컨테이너 또는 Pod에 탑재하는 경우 다음과 같이 많은 양의 구조화되지 않은 데이터를 처리하는 애플리케이션에서 사용할 수 있습니다.

  • 로그 파일 데이터입니다.
  • 이미지, 문서 및 스트리밍 비디오 또는 오디오.
  • 재해 복구 데이터입니다.

애플리케이션은 BlobFuse 또는 NFS 3.0 프로토콜을 통해 개체 스토리지의 데이터에 액세스할 수 있습니다. Blob Storage CSI 드라이버가 도입되기 전에 유일한 옵션은 AKS에서 실행되는 애플리케이션에서 Blob Storage에 액세스하기 위해 지원되지 않는 드라이버를 수동으로 설치하는 것이었습니다. AKS에서 사용하도록 설정된 Blob Storage CSI 드라이버에는 azureblob-fuse-premium 및 azureblob-nfs-premium의 두 가지 기본 제공 스토리지 클래스가 있습니다.

CSI 드라이버가 지원되는 AKS 클러스터를 만들려면 AKS에서 CSI 드라이버를 참조하세요. 자세한 내용은 NFS를 사용하여 Azure Files, Blob Storage 및 Azure NetApp Files에 대한 액세스 비교를 참조하세요.

Azure HPC 캐시

HPC Cache는 고성능 컴퓨팅 작업을 위한 데이터 액세스를 가속화하고, 클라우드 솔루션의 확장성을 제공합니다. 이 스토리지 솔루션을 선택하는 경우 HPC Cache를 지원하는 지역에 AKS 클러스터를 배포해야 합니다.

NFS 서버

공유 NFS 액세스의 경우 Azure Files 또는 Azure NetApp Files를 사용해야 합니다. 또한 볼륨을 내보내는 Azure VM에 NFS 서버를 만들 수도 있습니다.

이 옵션은 정적 프로비저닝만 지원합니다. 서버에서 NFS 공유를 수동으로 프로비전해야 합니다. AKS에서는 NFS 공유를 자동으로 프로비전할 수 없습니다.

이 솔루션은 PaaS(Platform as a Service)가 아닌 IaaS(Infrastructure as a Service)를 기반으로 합니다. OS 업데이트, 고가용성, 백업, 재해 복구 및 확장성을 포함하여 NFS 서버를 관리합니다.

Azure 컨테이너 스토리지

Azure Container Storage 는 컨테이너용으로 기본적으로 빌드된 클라우드 기반 볼륨 관리, 배포 및 오케스트레이션 서비스입니다. Kubernetes 클러스터에서 실행되는 상태 저장 애플리케이션에 대한 데이터를 저장하기 위해 영구 볼륨을 동적으로 자동으로 프로비전할 수 있도록 Kubernetes와 통합됩니다.

Azure Container Storage는 실제 데이터 스토리지에 기존 Azure Storage 제품을 사용하고 컨테이너용으로 의도적으로 빌드된 볼륨 오케스트레이션 및 관리 솔루션을 제공합니다. Azure Container Storage는 다음과 같은 백업 스토리지를 지원합니다.

  • Azure 디스크: 스토리지 SKU 및 구성에 대한 세부적인 제어를 제공합니다. Azure 디스크는 계층 1 및 범용 데이터베이스에 적합합니다.

  • 임시 디스크: AKS 노드(NVMe 또는 임시 SSD)에서 로컬 스토리지 리소스를 사용합니다. 임시 디스크는 데이터 내구성 요구 사항이 없거나 기본 제공 데이터 복제 지원이 있는 애플리케이션에 적합합니다. AKS는 AKS 노드에서 사용 가능한 임시 스토리지를 검색하고 볼륨 배포를 위해 획득합니다.

  • 탄력적 SAN: 주문형 완전 관리형 리소스를 프로비전합니다. Elastic SAN은 범용 데이터베이스, 스트리밍 및 메시징 서비스, 지속적인 통합 및 지속적인 업데이트 환경, 기타 계층 1 또는 계층 2 워크로드에 적합합니다. 여러 클러스터가 SAN(단일 스토리지 영역 네트워크)에 동시에 액세스할 수 있습니다. 그러나 영구 볼륨은 한 번에 한 소비자만 연결할 수 있습니다.

이전에는 컨테이너에 클라우드 스토리지를 제공하기 위해 개별 CSI 드라이버가 IaaS 중심 워크로드용 스토리지 서비스를 조정해야 했습니다. 이 메서드는 운영 오버헤드를 발생시키고 애플리케이션 가용성, 확장성, 성능, 유용성 및 비용과 관련된 문제의 위험을 증가했습니다.

Azure Container Storage는 Kubernetes에 컨테이너 스토리지 기능을 제공하는 오픈 소스 솔루션인 OpenEBS에서 파생된 것입니다. Azure Container Storage는 Kubernetes 환경에서 마이크로 서비스 기반 스토리지 컨트롤러를 통해 관리되는 볼륨 오케스트레이션 솔루션을 제공합니다. 이 기능을 사용하면 진정한 컨테이너 네이티브 스토리지를 사용할 수 있습니다.

Azure Container Storage는 다음과 같은 시나리오에 적합합니다.

  • VM-컨테이너 이니셔티브 가속화: Azure Container Storage는 이전에는 VM에서만 사용할 수 있었던 Azure 블록 스토리지 제품의 전체 범위를 보여 주고 컨테이너에 사용할 수 있게 합니다. 이 스토리지에는 Cassandra와 같은 워크로드에 매우 짧은 대기 시간을 제공하는 임시 디스크 스토리지가 포함되어 있습니다. 또한 네이티브 iSCSI 및 공유 프로비저닝된 대상을 제공하는 Elastic SAN도 포함됩니다.

  • Kubernetes를 사용하여 볼륨 관리를 간소화합니다 . Azure Container Storage는 Kubernetes 컨트롤 플레인을 통해 볼륨 오케스트레이션을 제공합니다. 이 기능은 서로 다른 컨트롤 플레인 간에 전환할 필요 없이 Kubernetes 내에서 볼륨의 배포 및 관리를 간소화합니다.

  • 총 소유 비용을 줄입니다. 비용 효율성을 향상하려면 각 Pod 또는 노드에 대해 지원되는 영구 볼륨의 규모를 늘입니다. 프로비저닝에 필요한 스토리지 리소스를 줄이려면 스토리지 리소스를 동적으로 공유합니다. 스토리지 풀 자체에 대한 강화 지원은 포함되지 않습니다.

Azure Container Storage는 다음과 같은 주요 이점을 제공합니다.

  • 스테이트풀 Pod를 신속하게 확장합니다: Azure Container Storage는 NVMe-oF 또는 iSCSI 같은 네트워크 블록 스토리지 프로토콜을 통해 영구 볼륨을 탑재합니다. 이 기능은 영구 볼륨의 빠른 첨부 및 분리를 보장합니다. 작은 리소스를 시작하고 필요에 따라 리소스를 배포하여 초기화 중 또는 프로덕션 환경에서 애플리케이션이 부족하거나 중단되지 않도록 할 수 있습니다. 클러스터에서 Pod가 재실행될 때, 애플리케이션의 복원력을 유지하기 위해 해당 영구 볼륨을 새 Pod로 신속하게 이전해야 합니다. Azure Container Storage는 원격 네트워크 프로토콜을 사용하여 Pod 수명 주기와 긴밀하게 결합하여 AKS에서 복원력이 뛰어나고 대규모 상태 저장 애플리케이션을 지원합니다.

  • 상태 저장 워크로드의 성능 향상: Azure Container Storage는 뛰어난 읽기 성능을 가능하게 하고 RDMA를 통해 NVMe-oF를 사용하여 거의 디스크에 가까운 쓰기 성능을 제공합니다. 이 기능을 사용하면 계층 1 I/O 집약적, 범용, 처리량 구분 및 개발/테스트 워크로드를 포함하여 다양한 컨테이너 워크로드에 대한 성능 요구 사항을 비용 효율적으로 충족할 수 있습니다. 영구 볼륨의 연결 및 분리 시간을 단축하고 파드 장애 조치 시간을 최소화합니다.

  • Kubernetes 네이티브 볼륨 오케스트레이션: 다른 컨트롤 플레인 작업에 대한 도구 세트 간에 전환하지 않고 명령을 사용하여 kubectl 스토리지 풀 및 영구 볼륨을 만들고, 스냅샷을 캡처하고, 볼륨의 전체 수명 주기를 관리합니다.

파트너 솔루션

Amazon EKS와 마찬가지로 AKS는 Kubernetes 구현이며 파트너 Kubernetes 스토리지 솔루션을 통합할 수 있습니다. Kubernetes에 대한 파트너 스토리지 솔루션의 몇 가지 예는 다음과 같습니다.

  • Rook 은 Azure Storage 관리자 작업을 자동화하여 분산 스토리지 시스템을 자체 관리 스토리지 서비스로 전환합니다. Rook은 각 스토리지 공급자에 대해 Kubernetes 운영자를 통해 서비스를 제공합니다.

  • GlusterFS는 일반적인 상용 하드웨어를 사용하여 데이터 사용량이 많고 대역폭 집약적인 작업을 위한 대규모 분산 스토리지 솔루션을 만드는 무료 오픈 소스 확장성 있는 네트워크 파일 시스템입니다.

  • Ceph 는 상용 하드웨어 구성 요소에서 빌드된 단일 클러스터의 개체, 블록 및 파일 인터페이스를 포함하는 안정적이고 확장 가능한 통합 스토리지 서비스를 제공합니다.

  • MinIO 다중 클라우드 개체 스토리지를 통해 기업은 모든 클라우드에서 AWS S3 호환 데이터 인프라를 빌드할 수 있습니다. 데이터 및 애플리케이션에 일관되고 이식 가능한 인터페이스를 제공합니다.

  • Portworx는 Kubernetes 프로젝트 및 컨테이너 기반 이니셔티브를 위한 엔드투엔드 스토리지 및 데이터 관리 솔루션입니다. Portworx는 컨테이너 세분화된 스토리지, 재해 복구, 데이터 보안 및 다중 클라우드 마이그레이션을 제공합니다.

  • Quobyte 는 성능을 조정하고, 대량의 데이터를 관리하고, 관리를 간소화하기 위해 모든 서버 또는 클라우드에 배포할 수 있는 고성능 파일 및 개체 스토리지를 제공합니다.

  • Ondat은 모든 플랫폼에서 일관된 스토리지 계층을 제공합니다. 스토리지 계층을 관리할 필요 없이 Kubernetes 환경에서 데이터베이스 또는 영구 워크로드를 실행할 수 있습니다.

Kubernetes 스토리지 고려 사항

Amazon EKS 또는 AKS용 스토리지 솔루션을 선택할 때는 다음 요소를 고려합니다.

스토리지 클래스 액세스 모드

Kubernetes 버전 1.21 이상에서는 기본적으로 AKS 및 Amazon EKS 스토리지 클래스는 CSI 드라이버 만 사용합니다.

다른 서비스는 액세스 모드가 다른 스토리지 클래스를 지원합니다.

서비스 읽기 또는 쓰기 한 번만 가능 ReadOnlyMany ReadWriteMany
Azure 디스크 스토리지 X
Azure 파일 서비스 X X X
Azure NetApp 파일 X X X
NFS 서버 X X X
HPC 캐시 X X X

동적 프로비전 및 정적 프로비전

볼륨을 동적으로 프로비전하여 영구 볼륨을 정적으로 만드는 관리 오버헤드를 줄입니다. Pod를 삭제할 때 사용되지 않는 디스크를 제거하도록 적절한 회수 정책을 설정합니다.

백업

영구 데이터를 백업하는 도구를 선택합니다. 이 도구는 스냅샷, Azure Backup, Velero 또는 Kasten과 같은 스토리지 유형과 일치해야 합니다.

비용 최적화

Azure Storage 비용을 최적화하려면 서비스에서 지원하는 경우 Azure 예약을 사용합니다. 자세한 내용은 Kubernetes 클러스터에 대한 비용 관리를 참조하세요.

참가자

Microsoft는 이 문서를 유지 관리합니다. 다음 기여자는 이 문서를 작성했습니다.

주요 작성자:

기타 기여자:

LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.

다음 단계