스토리지 버전
스토리지 버전 (Storage Versions)
Kubernetes API 서버는 객체를 저장할 때 etcd 호환 백엔드 스토어(보통은 etcd 자체)에 저장해요. 각 객체는 해당 API 타입의 특정 버전을 사용해서 직렬화되는데, 예를 들어 v1 버전의 ConfigMap 표현처럼요. Kubernetes는 이렇게 객체가 어떻게 저장되는지를 가리키는 용어로 **스토리지 버전(storage version)**이라는 말을 사용합니다.
같은 API가 여러 개의 스토리지 버전을 가질 수 있고, API 서버는 그 버전들을 객체 스키마로 변환할 수 있어요. 어떤 리소스에 속한 단일 객체는 한 시점에 반드시 하나의 스토리지 버전만 가져야 하죠. 즉 API 서버는 객체의 이진 인코딩을 알고 있고, 모든 스토리지 버전 사이에서 변환할 수 있어야 합니다.
객체의 버전은 스토리지 버전과 완전히 별개예요. 예를 들어 같은 리소스의 v1alpha1과 v1beta1 API 객체는, 두 객체 사이에서 스토리지 버전이 갱신되지 않았다면 스토리지에 동일하게 인코딩됩니다.
스토리지 버전과 리소스 매핑 (Storage version to resource mapping)
모든 리소스는 어떤 시점에든 활성 스토리지 버전 1개를 가져요. 즉 객체에 대한 어떤 쓰기든 그 객체를 그 스토리지 버전으로 저장한다는 뜻이죠. 다만 스토리지 버전은 갱신될 수 있어서, 객체들이 서로 다른 버전으로 저장될 수도 있습니다. 한 객체는 어느 시점에든 단 하나의 스토리지 버전으로만 저장돼요.
커스텀 리소스의 스토리지 버전 (Storage versions for custom resources)
커스텀 리소스는 동적으로 정의되기 때문에, 빌트인 Kubernetes 타입과는 스토리지 버전 처리 방식이 달라요. 빌트인 객체는 일반적으로 스토리지 인코딩이 API 타입과 분리되어 정의되는데, 저장된 객체가 허브(hub) 역할을 하고 리소스의 특정 버전은 객체 스키마의 필드로서만 존재합니다.
반면 커스텀 리소스는 특정 버전이 스토리지 버전으로 지정되어야 해요. 그 커스텀 리소스 버전이 정의한 스키마가 스토리지 레이어에서 리소스의 인코딩으로 사용됩니다. API 설정과 버저닝에 대한 자세한 내용은 고급 CRD 기능(advanced CRD featureset)을 참고하세요. 예를 들어 crontabs용 CustomResourceDefinition이 있다고 해봅시다.
v1beta1 API 정의가 스토리지 버전으로 사용된다면, crontabs에 대한 모든 갱신이나 생성이 v1beta1 API의 객체 스키마로 저장되요. 이 경우 실제로는 v1 API 객체도 v1beta1 스키마로 저장되는 셈이죠.
갱신이나 생성만이 새로 정의된 스토리지 버전을 사용하는 효과를 냅니다.
다른 스토리지 버전으로 마이그레이션하기 (Migrating to a different storage version)
단일 리소스에 대해 여러 스토리지 버전이 존재하면 클러스터 관리자에게 문제가 될 수 있어요. 관리자는 모든 객체가 연결된 스토리지 버전을 더 이상 사용하지 않는다는 것을 확신하기 전까지는, 지원이 중단된 CRD의 옛 API 버전을 제거할 수 없습니다.
더 알아보기
- 커스텀 리소스(Custom Resources)와 CRD
- etcd 스토리지 백엔드
- 오브젝트와 API 버저닝
- 저장 데이터 암호화(encryption at rest)