광고
2026년 10월 16일 공개된 Veeam Kasten 9.0.8은 Kubernetes 1.36 지원과 보안 구성요소 업데이트를 포함합니다. 하지만 운영 환경에서는 기능 목록보다 업그레이드 후 기존 배포가 정상적으로 동작할 조건을 먼저 확인하는 편이 중요합니다.
이번 글은 두 가지 실무 문제에 집중합니다. 첫째, x86-64-v3 CPU·ActionPodSpec 스키마·사용자 지정 RBAC 때문에 업그레이드가 실패하거나 작업이 막힐 수 있는 조건을 걸러냅니다. 둘째, Kubernetes 1.35 이상 사설 레지스트리 환경에서 이미지 Pull Secret을 일시적으로 복사하는 신규 옵션과 적용 범위를 정리합니다.
기준: Veeam Kasten 9.0.8 Release Notes(2026-10-16) 및 해당 버전 설치 문서. 명령어는 운영자가 환경에 맞게 실행할 수 있는 점검·적용 예시입니다. 별도 클러스터에서 직접 업그레이드하거나 성공 결과를 재현한 기록은 포함하지 않았습니다.
버전과 환경 먼저 확인
제품: Veeam Kasten for Kubernetes 9.0.8
새 지원 플랫폼: Kubernetes 1.36
지원 범위에서 제외: 일반 Kubernetes 1.32. 단, OpenShift 4.19는 계속 지원
CPU: x86-64 클러스터에는 x86-64-v3 명령 집합(공식 예: Intel Haswell / AMD Excavator 이상)이 필요하며, 다른 아키텍처는 해당 제한 대상이 아닙니다.
운영 영향: ActionPodSpec 필드 검증, 사설 레지스트리 자격 증명, 자체 구성 RBAC와 배포 위치 선택에 주의해야 합니다.
kubectl version
kubectl get nodes -o wide
helm list --namespace kasten-iokubectl get nodes는 노드 목록과 아키텍처를 살펴보는 출발점일 뿐, x86-64-v3를 완전히 판별하지는 않습니다. CPU 모델과 실제 제공되는 명령 집합을 각 물리/가상 노드에서 확인해야 합니다. 특히 ESXi·KVM의 CPU 호환성 모드나 VM에 노출한 CPU 기능이 영향을 줄 수 있으므로 OS/하이퍼바이저 수준 검증이 필요합니다.
Veeam Kasten 9.0.8 업그레이드 전 CPU, ActionPodSpec, Private Registry, RBAC 네 가지 점검항목
그림 1. 운영 환경별 필수 사전 점검표. 실제 클러스터 검증 화면이 아닌 자체 제작 설명 도식. 출처: Veeam Kasten 9.0.8 Release Notes.
ActionPodSpec 검증이 더 엄격해집니다
9.0.8부터 ActionPodSpec 객체를 만들거나 수정할 때 spec 아래 알 수 없는 필드는 거부됩니다. 리소스 수량 표현도 중요합니다. 예를 들어 다음은 YAML 숫자로 표현한 소수여서 검증에 실패할 수 있습니다.
# 변경 전: 거부될 수 있는 수량 표현 예시
resources:
requests:
cpu: 0.5수정 시 문자열로 감싸거나 millicore 단위를 명시합니다.
# 공식 릴리스 노트의 허용 표현을 이용한 예시
resources:
requests:
cpu: "0.5"
# 또는 cpu: 500m이 YAML은 ActionPodSpec 객체의 부분 예시이지 그대로 적용하는 전체 매니페스트가 아닙니다. 기존 객체의 잘못된 수량은 업그레이드 과정에서 자동 수정되지 않으며, 다음 업데이트 시 검증 오류가 발생할 수 있습니다. 배포 전에 사용자 지정 ActionPodSpec을 백업하고, 기존 오탈자·미지원 필드·CPU 수량 표현을 검토하세요.
또한 같은 Namespace에 ActionPodSpecBinding이 있을 때 저장소 관련 repository-server / delete-collection Pod의 설정 적용 우선순위도 달라집니다. 단일 네임스페이스 작업에서는 애플리케이션 네임스페이스의 바인딩을 우선 사용합니다. 여러 네임스페이스를 처리하는 정책은 다른 규칙이 적용되므로 기존 설치 네임스페이스 바인딩에만 의존하지 않도록 확인해야 합니다.
광고
사설 레지스트리: 9.0.8에서 달라진 점
Kubernetes 1.35 이상에서는 캐시된 이미지도 인증이 요구될 수 있습니다. 이전에 정리했던 Kasten 9.0.6·Kubernetes 1.35 주의사항에서는 이를 해결하기 위해 애플리케이션 Namespace마다 Pull Secret을 복사하고 기본 ServiceAccount에 연결하는 방법을 다뤘습니다.
9.0.8의 새로운 선택지는 global.copyImagePullSecretsToAppNamespaces=true입니다. 기본값은 false이며, 활성화하면 일부 Kanister 작업의 실행 중 필요한 Kasten 이미지 Pull Secret을 애플리케이션 Namespace에 임시 복사했다가 작업이 끝나면 삭제합니다. 다만 기존 비밀값을 무조건 복제하는 기능으로 가정해서는 안 되며, Kasten에 실제 설정한 Secret 참조를 먼저 확인해야 합니다.
공식 문서에서 이 자동 복사를 명시적으로 지원하는 범위는 다음과 같습니다.
Kanister Blueprint로 보호하는 애플리케이션의 백업·복구
실행 중인 워크로드에 연결되지 않은 볼륨의 백업
모든 실행 Hook, 복구 유형, 이미지 접근 실패를 해결하는 범용 설정은 아닙니다. 지원 범위 밖이라면 기존 수동 방식 또는 제품별 조치가 여전히 필요할 수 있습니다.
Kasten 9.0.8이 작업 실행 중 이미지 Pull Secret을 앱 Namespace에 임시 복사하는 흐름
그림 2. Kasten 설치 Namespace → 실행 중 임시 Secret 복사 → 애플리케이션 Namespace의 Worker Pod 인증 흐름. 실제 UI 캡처가 아닌 자체 제작 구성도. 출처: Veeam Kasten Air-Gapped Install.
적용 전에 현재 Helm 값을 확인
helm get values k10 --namespace kasten-io --all \
| grep -E 'imagePullSecret|copyImagePullSecretsToAppNamespaces'이 명령은 관련 설정 이름을 찾는 확인 예시입니다. 전체 Helm 값에는 Registry 인증정보 등 민감정보가 포함될 수 있으므로 터미널 출력이나 저장 파일을 외부에 공개하지 마세요. 설치 시 사용한 global.imagePullSecret 이름과 새 옵션, 공식 문서에 나오는 global.imagePullSecrets 참조를 각각 확인하는 것이 좋습니다. 환경에 따라 Helm 차트의 실제 스키마 및 Secret 설정을 대조해야 합니다.
이미 9.0.8로 설치된 Helm 릴리스에서 변경사항을 적용할 때는 기존 값을 보존하고 업그레이드 계획을 승인받은 뒤 다음 예시를 검토할 수 있습니다.
helm upgrade k10 kasten/k10 \
--namespace kasten-io \
--version 9.0.8 \
--reuse-values \
--set global.copyImagePullSecretsToAppNamespaces=true이 명령은 실제 실행 이력이 없는 적용 예시입니다. --reuse-values가 과거 릴리스의 기본값까지 유지할 수 있고 설치형태·Chart·사용자 지정 값이 다르므로, 업그레이드 경로와 helm get values 백업을 먼저 검토하세요. 이미 수동으로 Namespace에 만들어 놓은 Secret은 이 옵션을 켰다고 자동 정리된다고 가정하지 말아야 합니다.
정상·이상 판단 기준
APP_NS=application-namespace
kubectl get pods --namespace "$APP_NS"
kubectl get events --namespace "$APP_NS" --sort-by=.lastTimestamp위 예시의 APP_NS를 실제 보호 대상 Namespace로 바꿉니다. 대상 작업 시점에 Worker Pod가 생성되고 이미지 Pull에 성공하며 Backup/Restore 작업이 완료되는지 확인합니다. ErrImagePull 또는 ImagePullBackOff가 계속된다면 Pod Event에서 이미지 주소·인증 거부·Secret 연결 여부를 확인하세요. 임시 Secret은 작업 중에만 존재할 수 있으므로 완료 후 Secret이 안 보인다는 사실만으로 장애라고 판단하면 안 됩니다.
사용자 지정 RBAC와 ActionPodSpecBinding도 확인
rbac.create=false로 ServiceAccount 권한을 직접 관리하는 배포는 storage.k8s.io API 그룹의 csinodes 리소스에 대해 list 권한이 필요합니다. 기존 역할에 이 권한이 없는지 확인하고, 실제 서비스 계정과 운영 승인 절차에 맞춰 수정해야 합니다. 권한을 무조건 cluster-admin으로 올리는 방식은 피하세요.
ActionPodSpecBinding을 설치 네임스페이스에서 정의해 repository-server 및 delete-collection Pod에 적용하던 방식은 Deprecated로 안내됐습니다. 관련 정책이 보호하는 네임스페이스 수와 바인딩 위치를 확인한 뒤 공식 대체 경로를 검토하세요.
운영 체크리스트
현재 Kasten 릴리스와 목표 9.0.8, Kubernetes/OpenShift 지원 조합을 공식 지원표로 대조
x86-64 사용 시 실제 모든 실행 가능 노드의 x86-64-v3 지원 확인
Helm 사용자 정의값, ActionPodSpec, ActionPodSpecBinding, 직접 구성한 ServiceAccount RBAC를 별도 보관
Kubernetes 1.35+ Private Registry라면 기존 수동 Secret 구성과 9.0.8 신규 옵션 중 사용 방식 결정
특정 Namespace를 대상으로 백업·복구 테스트하고 Worker Pod Event와 작업 완료 여부 확인
Repository/export/retire 등 평소 운영하던 주요 Policy도 수행해 모니터링
문서에 명시된 CPU·스키마·RBAC 조건을 통과하기 전 운영 환경 업그레이드를 강행하지 않기
정리
9.0.8의 가치 중 하나는 Kubernetes 1.35+ 사설 레지스트리에서 Namespace별 Secret 수동 관리 부담을 낮출 수 있다는 점입니다. 하지만 신규 옵션 적용 범위를 넘는 작업까지 자동 해결된다고 보면 안 됩니다. 또 하나의 중요한 변화는 CPU 요구사항과 ActionPodSpec 검증 강화입니다. 업그레이드 전에는 기능 확인보다 이 호환성 조건을 먼저 점검하는 것이 안전합니다.
공식 참고자료
광고
