배포 검증 이후 남은 용량과 백업 및 운영 인수 과제

신규 이미지 재적용을 마친 뒤에는 실행 상태와 함께 운영에 남길 항목을 정리했다. Platform Pod 두 개가 Ready이고 Argo CD가 Healthy/Synced라는 결과를 확인했지만, 용량과 백업 복원, 인증 만료와 관리 접속은 다음 운영에서도 계속 다뤄야 하는 문제였다.

이번 글에서는 배포 전에 공간을 확보한 과정, 작업 전용 접근을 정리한 결과, 아직 남아 있는 운영 과제를 구분해 정리한다. 기능 검증을 마친 상태에서 무엇을 이어받아야 하는지 남기는 것이 연재의 마지막 작업이었다.

새 이미지를 받기 전에 Worker 용량부터 확보했다

첫 롤아웃 전 Worker-01의 imagefs 여유를 확인했을 때 15% 문턱 위 공간이 약 293MB뿐이었다. 회수 가능한 cache도 0이었다. 현재 Pod가 실행 중이어도 다음 이미지와 롤링 업데이트가 사용할 공간은 따로 필요했다. 이 상태에서는 배포를 보류했다.

원인을 살펴보니 기존 40GiB guest disk 안에서 root에 할당한 공간을 더 사용할 수 있었다. 별도 승인 후 root를 16GiB에서 24GiB로 늘렸다. NFS나 VMDK 크기를 바꾸는 작업이 아니라, 기존 guest 안에서 파티션과 커널 인식, PV, LV, ext4를 순서대로 확장하는 작업이었다.

재부팅이나 drain, kubelet 재시작 없이 진행했고 단계별 상태를 확인했다. 확장 뒤에는 30초 간격으로 21회, 약 600초 동안 HTTP와 DB 연결을 관찰했다. 해당 검사에서 모두 성공했고 후속 13개 검사도 통과했다.

확장 직후와 최종 배포 뒤 수치는 시점이 다르다. 두 값을 한 번의 결과처럼 섞지 않고, 각각 어떤 작업 이후의 관찰인지 남겼다.

백업 파일을 보관한 다음에는 실제 복원이 남았다

PostgreSQL은 암호화 백업 생성, 인증된 복호화, 형식과 목록 확인까지 진행했다. 파티션과 LVM 메타데이터도 별도 보존했다. 하지만 애플리케이션 image 복귀와 백업 목록 확인만으로 전체 재해 복구가 검증된 것은 아니다.

다음에는 분리한 환경에서 DB를 실제 복원해 애플리케이션이 기존 데이터를 읽고 동작하는지 확인해야 한다. VM과 부팅 복구도 별도의 시험 대상이다. 이 시험을 해야 현재 백업과 키, 문서로 어느 범위까지 되돌릴 수 있는지 구체적으로 말할 수 있다.

복원 담당자가 암호화 키에 접근할 수 있는지도 확인해야 한다. 파일과 키를 보호된 위치에 보관한 사실과, 필요한 사람이 복구 과정에서 사용할 수 있는지는 다른 확인 항목이었다.

작업 전용 인증과 접속을 정리했다

이번 작업에만 사용한 Jenkins bootstrap API token 한 개를 회수했다. 새 클라이언트에서 해당 인증이 거부되는지 확인했고, 지속적인 CI에 필요한 credential은 유지했다. 검증용 job 두 개는 비활성화하면서 이력을 남겼다. 기존 job과 main polling은 유지했다.

관리용 local listener 여덟 개와 작업에 남아 있던 원격 Argo port-forward도 정리했다. 처음 접속을 닫은 뒤 원격 프로세스 하나가 남아 있어 소유자와 고정 명령을 대조한 후 종료했다. 종료 대상과 포트 부재를 확인했고 Pod나 Service를 변경하는 방식으로 정리하지 않았다.

이 과정을 거치면서 작업 종료도 확인 가능한 결과로 남겨야 한다고 느꼈다. 터미널을 닫았다고 원격 포워드까지 모두 끝났다고 가정할 수는 없었다.

일상 운영에 필요한 담당자와 만료 정보

CI가 PR을 만들 수 있다는 것은 기능이 동작한다는 결과다. 해당 GitOps token이 정확히 어느 저장소와 permission을 허용하고 언제 만료되는지는 별도로 확인해야 했다. 독립적인 scope와 만료일 점검은 후속 인수 항목으로 남겼다.

정리해야 할 항목은 다음과 같다.

• Jenkins와 Argo CD의 비공개 관리 접속 담당자와 접근 방법.
• Registry CA, deploy key, CI credential의 보관과 교체 및 회수 담당자.
• DB backup key의 보관과 실제 복원 담당자.
• CI 실패와 운영 알림을 누가 어느 경로로 확인할지에 대한 기준.

현재 구성의 장애 지점을 정리했다

Platform Pod는 두 Worker에 분산했지만 NFS, Control Plane, PostgreSQL은 단일 구성이다. CI Agent와 Registry도 같은 VM의 다른 계정으로 나눴으므로 VM이나 디스크 장애의 영향은 공유한다.

이 구성에서 확인한 Worker별 Platform 분산과 전체 시스템 HA를 구분해야 했다. NFS나 DB가 중단되면 상위 Pod 두 개만으로 해결할 수 없는 경로가 남는다. 가용성을 더 높이려면 이 의존 관계부터 다시 다뤄야 한다.

RCA Agent도 현재는 한 Worker의 관찰용 canary다. 전체 노드 커버리지와 장기 identity, 토큰 만료 이후 재등록, mTLS는 남은 과제다. 실제 외부 LLM 호출이나 host 수정과 자동 복구도 이번 검증 범위에 포함하지 않았다.

물리 RAID 건강 점검과 보관 중인 스냅샷 네 개의 정리도 함께 관리해야 한다.

다음 변경으로 이어지는 기록

이번 연재는 ESXi와 공유 스토리지부터 VM 자동화, Kubernetes 네트워크와 영속 볼륨, CI와 Registry, GitOps 승인 배포까지 이어졌다. 그 사이에 인증서 신뢰 경로, 테스트 뒤 이미지 검증 실패, 롤아웃 분산 문제를 만났다.

각 문제를 겪으며 확인 항목을 늘렸다. 같은 저장소에 의존하는 경로, 도구마다 읽는 설정, 테스트와 게시 및 배포의 경계, 실제 실행 이미지와 노드 배치를 나눠 살펴봤다. 마지막에는 남은 운영 항목도 완료한 항목과 함께 남겼다.

다음 작업은 실제 DB 복원과 운영 인수부터 시작할 생각이다. 이미 돌아가는 환경을 기준으로 무엇이 실패했을 때 어디까지 복구할지 확인하고, 필요한 담당자와 접근 방법을 구체화하려 한다.

증거 수집 시점의 추가 관찰도 남겼다. vCenter에는 백업 일정 미설정 표시가 있었고, ESXi01은 heartbeat datastore 수와 전원 경보, ESXi02는 Shell 및 CVE 관련 경고가 남아 있었다. 구성 완료와 경고 없는 운영 상태는 같은 판단이 아니다. RAID 레벨·물리 디스크 건강과 실제 DB 복원 시험은 별도 확인 과제다.

배포 이후 자원 관측도 남겼다

배포 이후에는 rca-system Pod의 CPU·메모리 사용량과 requests·limits를 확인했다.