Kubernetes v1.35: 가변 PersistentVolume Node Affinity (alpha)
Source: Kubernetes Blog
위의 소스 링크 아래에 번역하고 싶은 텍스트를 제공해 주시면, 해당 내용을 한국어로 번역해 드리겠습니다. 현재는 번역할 본문이 없으므로, 번역이 필요한 전체 텍스트를 알려 주세요.
PersistentVolume 노드 어피니티
PersistentVolume 노드 어피니티 API( Kubernetes documentation 참고)는 Kubernetes v1.10부터 제공되었습니다. 이는 볼륨이 클러스터의 모든 노드에서 동일하게 접근 가능하지 않을 수 있음을 나타내는 데 일반적으로 사용됩니다.
- 이전 동작:
nodeAffinity필드는 불변이었습니다. - 새 동작 (v1.35 – 알파): 이 필드는 이제 변경 가능하며, 보다 유연한 온라인 볼륨 관리를 가능하게 합니다.
왜 노드 어피니티를 변경 가능하게 해야 할까요?
Kubernetes는 전통적으로 PersistentVolume (PV) 의 노드 어피니티를 불변(immutable)으로 취급해 왔습니다.
무상태 워크로드(예: Deployments)에서는 문제가 되지 않습니다—Pod 사양을 변경하면 롤아웃이 트리거되어 Pod가 재생성되기 때문입니다.
하지만 상태 저장 워크로드는 데이터를 잃을 위험 없이 PV를 재생성할 수 없기 때문에 문제가 됩니다.
지금 왜 바꾸어야 할까요?
- 스토리지 백엔드의 진화 – 많은 공급자가 이제 리전 디스크를 제공하고, 심지어 작업 중단 없이 존 디스크에서 리전 디스크로의 실시간 마이그레이션을 지원합니다.
- 새로운 디스크 세대 – 최신 디스크는 일부 노드(예: 최신 인스턴스 타입)에서만 연결될 수 있습니다.
두 경우 모두 기본 스토리지가 변경된 후 올바른 노드에 Pod가 스케줄될 수 있도록 PV의 노드 어피니티를 업데이트할 필요가 있습니다.
예시 1 – 존 디스크에서 리전 디스크로 마이그레이션
원래 특정 존에 바인딩된 PV:
spec:
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: topology.kubernetes.io/zone
operator: In
values:
- us-east1-b
볼륨을 리전 디스크로 마이그레이션한 후에는 어피니티를 리전 수준으로 완화해야 합니다:
spec:
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: topology.kubernetes.io/region
operator: In
values:
- us-east1
예시 2 – 새로운 디스크 세대로 전환
세대‑1 디스크에서만 동작하는 PV:
spec:
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: provider.com/disktype.gen1
operator: In
values:
- available
볼륨을 세대‑2 디스크로 업그레이드하면 어피니티를 그에 맞게 업데이트해야 합니다:
spec:
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: provider.com/disktype.gen2
operator: In
values:
- available
Source:
더 큰 그림
노드 어피니티를 변경 가능하게 만드는 것은 보다 유연한 온라인 볼륨 관리를 향한 첫 번째 단계입니다.
변경 내용은 간단합니다—API 서버에서 검증 체크를 제거하는 것이지만, 이를 통해 Kubernetes 생태계와의 더 깊은 통합(예: 자동 마이그레이션 도구, 동적 스토리지 클래스 업데이트 등)이 가능해집니다.
아직 갈 길이 멀지만, 이 기능만으로도 다음을 실현할 수 있습니다:
- 영역/리전 간 볼륨의 원활한 마이그레이션.
- 변화하는 하드웨어 요구사항에 맞춘 PV 정렬.
- 상태 저장 워크로드에 대한 운영 마찰 감소.
사용해 보기
이 기능은 스토리지 공급자가 온라인 업데이트를 지원하는 Kubernetes 클러스터 관리자를 위한 것입니다. 볼륨을 업데이트하면 접근성에 영향을 줄 수 있으므로 다음을 수행해야 합니다:
- 스토리지 공급자에서 기본 볼륨을 먼저 업데이트합니다.
- 업데이트 후 어떤 노드가 볼륨에 접근할 수 있는지 확인합니다.
- 기능을 활성화하고 PersistentVolume(PV) 노드 어피니티를 동기화합니다.
참고: PV 노드 어피니티만 변경해도 기본 볼륨의 접근성은 변경되지 않습니다.
기능 상태
- Alpha – 기본적으로 비활성화되어 있으며 향후 릴리스에서 변경될 수 있습니다.
- 사용해 보려면 API 서버에서
MutablePVNodeAffinity기능 게이트를 활성화하고 PV의spec.nodeAffinity필드를 편집합니다. - 일반적으로 PV를 편집할 수 있는 권한은 관리자에게만 부여되므로, 적절한 RBAC 권한이 있는지 확인하십시오.
업데이트와 스케줄링 사이의 레이스 컨디션
PV 노드 어피니티는 파드 외부에서 스케줄링 결정에 영향을 줄 수 있는 몇 안 되는 요소 중 하나입니다.
- 노드 어피니티 완화(볼륨에 접근할 수 있는 노드를 늘리는 것)는 안전합니다.
- 노드 어피니티 강화(접근을 제한하는 것)는 레이스 컨디션을 초래합니다:
- 스케줄러가 아직 이전 PV 정보를 캐시하고 있을 수 있습니다.
- 볼륨에 더 이상 접근할 수 없는 노드에 파드를 스케줄링할 수 있습니다.
- 파드는
ContainerCreating상태에 머물게 됩니다.
현재 완화 방안 (논의 중)
- Kubelet 수준 검사: PersistentVolume의 노드 어피니티가 위배될 경우 파드 시작을 실패 처리합니다.
- 이 변경 사항은 아직 병합되지 않았습니다.
실무 가이드
- PV를 업데이트한 후, 그 PV를 사용하는 이후 파드들을 모니터링하여 볼륨에 접근 가능한 노드에 스케줄링되는지 확인합니다.
- 스크립트에서 PV 업데이트 직후에 새로운 파드를 바로 실행하지 마세요. 스케줄러 캐시가 오래되어 스케줄링 실패가 발생할 수 있습니다.
요약: 기본 스토리지를 업데이트하고 노드 접근성을 확인한 뒤에만 MutablePVNodeAffinity를 활성화하세요. 특히 노드 어피니티를 강화할 때는 kubelet 수준의 보호 장치가 도입될 때까지 파드 스케줄링 동작을 주시하십시오.
CSI (Container Storage Interface)와의 향후 통합
현재 클러스터 관리자는 수동으로 다음 작업을 수행해야 합니다:
- PersistentVolume (PV) 노드 어피니티 수정
- 스토리지 공급자에서 기본 볼륨 업데이트
이러한 수동 단계는 오류가 발생하기 쉽고 시간이 많이 소요됩니다.
원하는 워크플로우
- 목표: 권한이 제한된 사용자가
PersistentVolumeClaim(PVC)만 수정하면 스토리지 측 업데이트가 자동으로 트리거되도록 합니다. - 메커니즘:
VolumeAttributesClass(또는 유사한 CSI 기능)를 활용하여:- PVC 변경 사항이 스토리지 공급자에 자동으로 전파됩니다.
- 필요에 따라 PV의 노드 어피니티가 자동으로 업데이트됩니다.
- 이점: 클러스터 관리자 개입이 필요 없어 운영 부담과 인적 오류 위험이 감소합니다.
다음 단계
- CSI 지원 조사 –
VolumeAttributesClass를 통한 동적 업데이트 가능 여부 검토. - 컨트롤러 프로토타입 제작 – PVC 변경을 감시하고 다음을 조정하도록 구현:
- 스토리지 측 설정.
- PV 노드 어피니티.
- RBAC 정책 정의 – 권한이 제한된 사용자가 PVC를 수정할 수 있게 하면서, 직접 PV를 편집하는 권한은 제한합니다.
여러분의 피드백을 환영합니다
앞서 언급했듯이, 이것은 첫 번째 단계에 불과합니다.
- Kubernetes 사용자 – PV 노드 어피니티를 어떻게 사용하고 계신지(또는 사용할 계획인지) 알고 싶습니다. 귀하의 경우 온라인으로 업데이트하는 것이 유용한가요?
- CSI 드라이버 개발자 – 이 기능을 구현할 의향이 있으신가요? API가 어떻게 보였으면 좋겠습니까?
다음 채널 중 하나를 통해 의견을 공유해 주세요:
- Slack: #sig‑storage
- Mailing list: kubernetes‑sig‑storage
- KEP issue: Mutable PersistentVolume Node Affinity (KEP‑5381)
이 기능에 대한 문의나 구체적인 질문이 있으면 언제든지 **SIG Storage 커뮤니티**에 연락해 주세요.