복구는 다음 파드가 태어나도 유지되어야 한다

한 줄 요약

안전한 복구는 정상 응답 한 번으로 증명되지 않습니다. 현재 선언을 관측한 컨트롤러 상태, 그 선언에서 나온 파드, 실제 응답, 그리고 대체 파드의 설정이 함께 맞아야 합니다.

왜 이게 필요했나

새 파드가 준비 검사에 실패해도 서비스는 정상일 수 있습니다. 이전 파드가 계속 요청을 처리하기 때문입니다. 이것은 무조건 이상한 상태가 아니라, 나쁜 배포가 기존 용량을 한꺼번에 없애지 않도록 설계한 결과일 수 있습니다.

문제는 정상 HTTP를 보고 새 버전까지 성공했다고 판단할 때입니다. 기존 파드가 응답했다면 새 버전의 성공 증거가 아닙니다. 반대로 새 파드가 하나 준비되지 않았다고 모든 사용자가 장애를 겪는다고 단정해도 안 됩니다. 배포 진행과 사용자 영향은 연결되어 있지만 같은 값은 아닙니다.

실제 탐침에서는 기존 정상 파드 두 개와 준비되지 않은 새 파드 한 개가 함께 존재했습니다. 서비스는 기존 파드로 정상 응답했습니다. 첫 롤백은 완료됐지만 기존 파드 교체 후 일부 용량이 다시 준비되지 않았습니다. 복구의 정의에 파드 교체를 포함해야 한다는 근거가 여기서 나왔습니다.

어떻게 동작하나

선언을 읽었는지부터 확인한다

변경을 저장한 API 응답은 컨트롤러가 이미 처리했다는 뜻이 아닙니다. Deployment의 metadata.generation과 status.observedGeneration을 함께 읽어 현재 선언을 관측했는지 봅니다. 이어서 새 템플릿의 복제본 수, 준비된 수, 가용 수를 구분합니다. 이전 상태의 Available 조건만 남아 있을 수도 있습니다.

이번 예제는 복제본 두 개, maxSurge: 1, maxUnavailable: 0을 사용합니다. 새 파드가 준비되지 않으면 기존 정상 용량을 먼저 줄이지 않도록 하는 설정입니다. 종료 중인 파드가 잠시 추가로 보일 수 있으므로, 단순 목록 길이와 배포의 용량 계산을 혼동하지 마세요.

관측 명령이 정해진 시간 안에 끝나지 않았다는 사실도 정확히 표현해야 합니다. 그것은 그 관측창에서 완료를 보지 못했다는 뜻입니다. 배포 컨트롤러가 보고하는 진행 기한 초과나 실제 앱의 준비 실패와는 별도 증거입니다. 타임아웃만 보고 같은 설치를 다시 시작하면 원인을 지우거나 실행을 겹칠 수 있습니다.

응답한 파드가 누구인지 연결한다

예제 앱은 응답에 파드 이름, 읽은 설정 버전, 정상 여부를 담습니다. 이 값만 믿는 것은 부족합니다. 조회한 Pod가 해당 ReplicaSet에 속하고, 그 ReplicaSet이 이번 Deployment에 속하는지도 UID로 대조합니다. 이름은 재사용될 수 있기 때문입니다.

개별 파드의 /readyz 응답과 Kubernetes의 Ready 조건을 함께 봅니다. 프로세스가 살아 있다는 liveness와 트래픽을 받아도 된다는 readiness는 다릅니다. 예제는 잘못된 설정에서도 프로세스가 살아 있지만 준비 응답은 503입니다. 서비스의 성공 응답이 어느 정상 파드에서 왔는지도 연결합니다.

실무 앱이 이런 정보를 외부 사용자에게 항상 노출해야 한다는 뜻은 아닙니다. 이 작은 교육용 응답은 관측 대상의 관계를 드러내기 위한 장치입니다. 운영에서는 내부 진단 경로, 로그, 배포 메타데이터 등 접근을 통제한 관측 수단을 선택합니다.

다음 파드로 복구를 시험한다

이전 버전으로 돌아온 뒤 정상 파드 한 개를 교체합니다. 기존 UID가 사라지고 새 UID가 생겼는지 확인한 후, 그 새 파드가 이전 설정을 실제로 읽고 준비되었는지 봅니다. 이전 정상 파드의 응답을 새 파드의 성공으로 재사용하지 않습니다.

이 교체는 자기 개인 VM 안의 지정된 워크로드에서만 합니다. 실제 운영에서 복구를 확인하겠다며 임의의 파드를 삭제하는 절차가 아닙니다. 운영에서는 용량, 중단 예산, 트래픽, 승인된 시험 범위를 먼저 고려해야 합니다. 탐침의 삭제 요청도 UID와 resourceVersion 조건을 붙여 다른 객체나 동시 변경을 무시하지 않게 했습니다.

현장에서 만나는 모습

플랫폼 팀은 배포 도구를 제공하는 동시에 실패를 이해할 수 있는 단서를 제공해야 합니다. “배포 실패” 한 줄보다 “현재 새 복제본 하나가 설정 v2로 실행됐지만 준비 응답이 503이고, 기존 v1 두 개가 서비스 중”이라는 설명이 개발자가 다음 행동을 정하는 데 훨씬 유용합니다.

복구 기록에는 무엇을 바꿨는지뿐 아니라 무엇을 보존했는지도 남깁니다. 이 실험은 다른 팀의 Deployment UID와 정상 응답을 마지막에 다시 확인했습니다. 이것이 모든 테넌트 격리를 증명하지는 않지만, 내 앱을 살리려고 다른 앱을 지우는 방식의 잘못된 성공은 배제합니다.

기록을 저장할 때는 현재 실행과 대상 UID를 연결하고, 이후 단계가 과거 관측을 덮어쓰지 않도록 합니다. 조회 실패를 빈 목록이나 정상 상태로 기록하지 않습니다. 완주한 뒤 같은 단계를 다시 채점해도 이전 증거의 의미가 유지되어야 학습자가 무엇을 배웠는지 돌아볼 수 있습니다.

다음 실습에서 할 것

변경 가능한 설정으로 배포와 롤백을 수행하고 파드 교체 뒤 재발을 관측합니다. 그다음 버전별 불변 설정 참조로 복구해 대체 파드까지 정상인 결과를 비교합니다. 명령의 종료 코드, 컨트롤러 상태, 실제 응답, 설정 원본을 서로 다른 증거로 읽는 것이 목표입니다.

공식 문서

• [Deployment 업데이트와 상태](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)
• [ConfigMap 사용 방식](https://kubernetes.io/docs/concepts/configuration/configmap/)