적용 대상: Azure 로컬의 AKS
Azure Arc에서 사용하도록 설정된 Azure Kubernetes Service를 사용하여 AKS 배포에서 실행되는 애플리케이션은 데이터를 저장하고 검색해야 할 수 있습니다. 일부 애플리케이션 워크로드의 경우 Pod가 삭제될 때 데이터가 불필요한 노드에서 로컬의 빠른 스토리지를 사용할 수 있습니다(Kubernetes는 Pod를 사용하여 애플리케이션 인스턴스를 실행).
다른 워크로드에는 더 많은 일반 데이터 볼륨에 유지되는 스토리지가 필요할 수 있습니다. 여러 Pod가 동일한 데이터 볼륨을 공유하거나 Pod가 다른 노드에서 다시 예약된 경우 데이터 볼륨을 다시 연결해야 할 수 있습니다. 또한 Pod에 중요한 데이터 또는 애플리케이션 구성 정보가 포함된 경우 스토리지 옵션이 필요할 수 있습니다.
이 문서에서는 다음을 포함하여 AKS Arc의 애플리케이션에 스토리지를 제공하는 핵심 개념을 소개합니다.
- 볼륨
- 영구적 볼륨
- 스토리지 클래스
- PVC(영구 볼륨 청구)
볼륨
애플리케이션은 종종 데이터를 저장하고 검색할 수 있어야 합니다. Kubernetes는 일반적으로 개별 Pod를 임시, 삭제 가능한 리소스로 처리하므로 애플리케이션에서 데이터를 사용하고 유지하는 데 다양한 방법을 사용할 수 있습니다. 볼륨은 Pod 간에 애플리케이션 수명 주기를 통해 데이터를 저장, 검색 및 유지하는 방법을 나타냅니다.
Kubernetes에서 볼륨은 정보가 저장 및 검색되는 기존 볼륨 이상을 나타낼 수 있습니다. Kubernetes 볼륨은 데이터를 컨테이너에서 사용할 수 있도록 파드에 삽입하는 방법으로도 사용할 수 있습니다. 몇 가지 일반적인 Kubernetes 볼륨 유형은 다음과 같습니다.
emptyDir - 이 볼륨은 일반적으로 Pod의 임시 공간으로 사용됩니다. Pod 내의 모든 컨테이너는 볼륨의 데이터에 액세스할 수 있습니다. 이 볼륨 형식에 기록된 데이터는 Pod의 수명 동안만 유지됩니다. Pod가 삭제되면 볼륨이 삭제됩니다. 이 볼륨은 일반적으로 기본 로컬 노드 디스크 스토리지를 사용하지만 노드의 메모리에만 존재할 수도 있습니다.
비밀 - 이 볼륨은 암호와 같은 중요한 데이터를 Pod에 포함하는 데 사용됩니다. 먼저 Kubernetes API를 사용하여 비밀을 만듭니다. Pod 또는 배포를 정의할 때 특정 비밀을 요청할 수 있습니다. 비밀은 필요한 예약된 Pod가 있는 노드에만 제공되며, 비밀은 디스크에 기록되지 않고 tmpfs에 저장됩니다. 비밀이 필요한 노드의 마지막 Pod가 삭제되면 노드의 tmpfs에서 비밀이 삭제됩니다. 비밀은 지정된 네임스페이스 내에 저장되며 동일한 네임스페이스 내의 Pod에서만 액세스할 수 있습니다.
configMap - 이 볼륨 형식은 애플리케이션 구성 정보와 같은 키-값 쌍 속성을 Pod에 삽입하는 데 사용됩니다. 컨테이너 이미지 내에서 애플리케이션 구성 정보를 정의하는 대신 배포될 때 Pod의 새 인스턴스에 쉽게 업데이트하고 적용할 수 있는 Kubernetes 리소스로 정의할 수 있습니다. 비밀을 사용하는 것과 마찬가지로 먼저 Kubernetes API를 사용하여 ConfigMap 을 만듭니다. 그런 다음 Pod 또는 배포를 정의할 때 이 ConfigMap 을 요청할 수 있습니다. ConfigMaps 는 지정된 네임스페이스 내에 저장되며 동일한 네임스페이스 내의 Pod에서만 액세스할 수 있습니다.
영구적 볼륨
Pod 수명 주기의 일부로 정의 및 생성되는 볼륨은 Pod가 삭제될 때까지만 존재합니다. 작업 이벤트 중에 특히 StatefulSets에서 한 Pod가 다른 호스트로 다시 예약될 경우, Pods는 스토리지가 그대로 남아 있을 것으로 기대합니다. 영구 볼륨은 개별 Pod의 수명 외에 존재할 수 있는 Kubernetes API에서 만들고 관리하는 스토리지 리소스입니다.
AKS 디스크 볼륨은 VHDX로 백업된 것들이며, ReadWriteOnce로 마운트되어 한 번에 하나의 노드에서만 액세스할 수 있습니다. 또는 SMB 또는 NFS 파일 공유에서 지원되는 AKS 파일 볼륨을 사용할 수 있습니다. ReadWriteMany로 탑재된 것은 여러 노드에서 동시에 사용할 수 있습니다.
클러스터 관리자는 정적으로 영구 볼륨을 만들거나 Kubernetes API 서버에서 볼륨을 동적으로 만들 수 있습니다. Pod가 예약되고 현재 사용할 수 없는 스토리지를 요청하는 경우 Kubernetes는 기본 VHDX 파일을 만든 다음 Pod에 연결할 수 있습니다. 동적 프로비전은 StorageClass를 사용하여 만들어야 하는 스토리지 유형을 식별합니다.
스토리지 클래스
스토리지의 다른 계층(및 위치)을 정의하려면 StorageClass를 만들 수 있습니다. StorageClass는 reclaimPolicy도 정의합니다. 이 reclaimPolicy 는 Pod가 삭제되고 영구 볼륨이 더 이상 필요하지 않을 수 있는 경우 기본 스토리지 리소스의 동작을 제어합니다. 향후 Pod에서 사용하기 위해 기본 스토리지 리소스를 삭제하거나 보존할 수 있습니다.
AKS Arc 에서 기본 스토리지 클래스는 자동으로 만들어지고 CSV를 사용하여 VHDX 지원 볼륨을 만듭니다. 회수 정책은 사용된 영구 볼륨이 삭제될 때 기본 VHDX가 삭제되도록 합니다. 또한 스토리지 클래스는 영구 볼륨을 확장 가능하도록 구성하므로 새 크기로 영구 볼륨 클레임을 편집하기만 하면 됩니다.
영구 볼륨에 대해 StorageClass가 지정되지 않은 경우 기본 StorageClass가 사용됩니다. 영구 볼륨을 요청할 때 적절한 스토리지를 사용해야 합니다. 추가 요구 사항에 맞게 StorageClass 를 만들 수 있습니다.
영구적 볼륨 클레임
PersistentVolumeClaim은 특정 StorageClass 및 크기의 ReadWriteOnce 또는 ReadWriteMany 스토리지를 요청합니다. 정의된 StorageClass에 따라 클레임을 수행할 기존 리소스가 없는 경우 Kubernetes API 서버는 AKS Arc에서 기본 스토리지 리소스를 동적으로 프로비전할 수 있습니다. 볼륨이 Pod에 연결된 후, Pod 정의에는 볼륨 마운트가 포함됩니다.
PersistentVolume은 사용 가능한 스토리지 리소스를 요청하는 Pod에 할당되면 PersistentVolumeClaim에 바인딩됩니다. 클레임과 영구적 볼륨은 1:1로 매핑되어 있습니다.
다음 예제 YAML 매니페스트는 기본 StorageClass 를 사용하고 5Gi 디스크를 요청하는 영구 볼륨 클레임을 보여 줍니다.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: aks-hci-vhdx
spec:
accessModes:
- ReadWriteOnce
storageClassName: default
resources:
requests:
storage: 5Gi
Pod 정의를 만들 때 원하는 스토리지를 요청하도록 영구 볼륨 클레임을 지정합니다. 그런 다음 애플리케이션이 volumeMount
데이터를 읽고 쓸 수 있도록 지정합니다. 다음 YAML 매니페스트 예제에서는 이전 영구 볼륨 클레임을 사용하여 다음 위치에서 /mnt/aks-hci
볼륨을 탑재하는 방법을 보여줍니다.
kind: Pod
apiVersion: v1
metadata:
name: nginx
spec:
containers:
- name: myfrontend
image: k8s.gcr.io/nginx
volumeMounts:
- mountPath: "/mnt/aks-hci"
name: volume
nodeSelector:
kubernetes.io/os: linux
volumes:
- name: volume
persistentVolumeClaim:
claimName: aks-hci-vhdx
다음 예제에서는 Windows 컨테이너에 볼륨을 탑재하고 드라이브 문자와 경로를 지정하는 방법을 보여 줍니다.
volumeMounts:
- mountPath: "d:"
name: volume
- mountPath: "c:\k"
name: k-dir
탑재된 볼륨에 대한 보안 Pod 액세스
애플리케이션이 올바르게 실행되도록 Pod는 루트가 아닌 정의된 사용자 또는 그룹으로 실행되어야 합니다.
securityContext
Pod 또는 컨테이너의 경우 fsGroup과 같은 설정을 정의하여 탑재된 볼륨에 대한 적절한 권한을 가정할 수 있습니다.
fsGroup 은 Kubernetes Pod 사양 내 securityContext
의 필드입니다. Kubernetes가 Pod의 모든 프로세스에 할당하고 탑재된 볼륨의 파일에 재귀적으로 할당하는 추가 그룹 ID를 정의합니다. 이렇게 하면 Pod가 공유 스토리지 볼륨에 대한 올바른 그룹 수준 액세스 권한을 갖습니다.
볼륨이 탑재되면 Kubernetes는 fsGroup 값과 일치하도록 볼륨 콘텐츠의 소유권을 변경합니다. 컨테이너가 루트가 아닌 사용자로 실행되고 공유 볼륨에 대한 쓰기 액세스 권한이 필요한 경우에 특히 유용합니다.
다음 예제 YAML은 fsgroup 값을 보여 줍니다.
securityContext:
fsGroup: 2000
이 예제에서는 탑재된 볼륨의 모든 파일에 GID 2000에서 액세스할 수 있습니다.
다음 단계
- Azure CSI(로컬 디스크 컨테이너 스토리지 인터페이스) 드라이버에서 AKS를 사용합니다.