접속했을 때는 이미 잠잠해진 장애

접속했을 때 확인한 readiness와 현재 프로세스의 로그는 그 시점의 상태를 보여줬다. 하지만 재시작되기 전 프로세스가 왜 종료됐는지는 설명하지 못했다. 종료 직전의 로그와 컨테이너 종료 상태, 재시작 이력을 따로 확인해야 했다.

이전 컨테이너의 로그에는 kube-controller-manager와 kube-scheduler가 리더 자격을 갱신하지 못하고 종료한 기록이 남아 있었다. 재시작이 반복된 직접적인 이유는 확인했지만, 갱신이 왜 제시간에 끝나지 않았는지는 더 살펴봐야 했다.

전체 로그에서 etcd라는 단어를 찾으면 시작 과정의 메시지와 재시도, 장애의 결과로 남은 오류까지 한꺼번에 섞였다. 재시작이 집중된 시간대로 범위를 좁히고, 종료된 프로세스의 마지막 기록부터 API 서버와 etcd의 로그를 맞춰 봤다.

현재 경고 이벤트가 많지 않다는 것도 재시작 이력과 모순되는 상황은 아니었다. 이벤트와 로그, 재시작 횟수는 보존하는 기간과 의미가 다르다. 현재 남은 경고의 수보다 당시 프로세스가 종료되기까지의 순서를 확인하는 것이 필요했다.

kube-controller-manager와 kube-scheduler를 여러 개 실행하는 구성에서는 각 구성 요소의 인스턴스 중 하나가 리더 역할을 맡는다. Kubernetes의 Lease는 누가 그 역할을 맡고 있는지와 갱신 시각을 기록하는 객체다. 리더는 API 서버를 통해 이 기록을 주기적으로 갱신한다.

각 구성 요소에서 여러 인스턴스가 실행 중이어도 리더 역할은 하나가 맡고, 나머지는 역할을 넘겨받을 수 있도록 대기한다. Lease 자체가 리더를 뽑는 것은 아니다. 각 인스턴스의 리더 선출 로직이 API 서버를 통해 Lease의 소유권 획득과 갱신을 시도한다. 기존 리더가 갱신하지 못해 Lease의 유효 기간이 지나면 다른 인스턴스가 소유권 획득을 시도할 수 있다.

갱신 요청이 한 번 실패했다고 바로 리더 자격을 포기하는 것은 아니다. client-go의 리더 선출 구현은 RenewDeadline으로 정한 시간 안에서 갱신을 재시도한다. 그 안에 성공하지 못하면 리더 역할을 내려놓고, OnStoppedLeading 처리를 호출한다.

kube-controller-manager와 kube-scheduler에는 리더 자격을 잃었을 때 프로세스를 종료하는 처리가 있다. 세부 종료 방식은 버전과 설정에 따라 다르며, 종료 이후의 재시작은 이를 실행하는 환경의 정책에 따른다. 따라서 반복 재시작을 조사할 때는 프로세스의 종료 기록과 함께, 리더 갱신이 왜 제시간에 끝나지 않았는지도 확인해야 한다. 아래 코드는 이 동작을 설명하기 위해 Kubernetes v1.37.0에서 발췌했다.

OnStoppedLeading: func() {
    logger.Error(nil, "leaderelection lost/stopped")
    if !utilfeature.DefaultFeatureGate.Enabled(cmfeatures.ControllerManagerReleaseLeaderElectionLockOnExit) {
        klog.FlushAndExit(klog.ExitFlushTimeout, 1)
    }
},

// We lost the lock.
logger.Error(nil, "Leaderelection lost")
klog.FlushAndExit(klog.ExitFlushTimeout, 1)

이 갱신도 API 요청이므로 서버가 응답할 때까지 기다려야 한다. API 서버는 Lease를 비롯한 Kubernetes 객체의 상태를 etcd에 저장한다.

예를 들어 A·B·C 서버에 각 구성 요소를 하나씩 실행한다면, controller-manager의 리더는 A에, scheduler의 리더는 B에, etcd의 리더는 C에 있을 수 있다. API 서버는 세 인스턴스 모두 요청을 받을 수 있으므로, 로드 밸런서로 요청을 나눠 보낼 수 있다.

리더를 선출하는 절차는 각각 독립적이지만, Lease를 저장하는 경로는 etcd로 이어진다. controller-manager나 scheduler가 Lease 갱신을 요청하면 API 서버가 그 변경을 etcd에 저장한다. 따라서 etcd에서 처리가 늦어지면 Lease 갱신 응답도 늦어질 수 있다. Lease 갱신 실패만으로 etcd의 리더가 바뀌었다고 판단할 수는 없지만, 갱신 실패를 조사할 때 etcd의 상태까지 확인해야 하는 이유다.

etcd는 여러 구성원이 같은 변경 기록에 합의하도록 Raft를 사용한다. 리더가 현재 임기(term)에 새로 받은 변경을 로그에 추가하고 다른 구성원에게 복제하면, 자신을 포함한 과반수에 기록된 뒤 그 변경을 확정할 수 있다. 모든 구성원이 응답할 때까지 기다리는 방식은 아니다.

예를 들어 투표 구성원이 세 개인 안정된 클러스터라면 과반수는 둘이다. 리더와 다른 한 구성원이 제때 기록하면 나머지 하나가 늦어도 합의를 진행할 수 있다. 반면 리더와 나머지 구성원 사이의 통신이나 여러 구성원이 함께 사용하는 자원이 지연되면, 과반수의 응답을 모으는 과정도 늦어질 수 있다. 여기서 세 개라는 수는 동작을 설명하기 위한 예시다.

변경 기록은 메모리에 복사하는 것으로 끝나지 않는다. etcd는 복구에 필요한 기록을 WAL(Write-Ahead Log)에 남기며, 저장 장치에 기록을 반영하는 동기화 작업도 필요하다. 합의가 끝나는 시간에는 구성원 사이의 통신 지연과 디스크 기록 지연이 모두 영향을 준다. 전송할 데이터가 적더라도 이 기다림이 길어지면 작은 상태 갱신도 늦어질 수 있다.

Raft의 리더는 다른 구성원에게 주기적으로 heartbeat를 보낸다. 일정 시간 동안 리더의 메시지를 받지 못한 구성원은 새 선거를 시작할 수 있다. 그런데 메시지가 늦었다는 사실만으로 네트워크가 끊겼다고 판단할 수는 없다. etcd의 디스크 기록이 늦거나 프로세스가 CPU를 충분히 할당받지 못한 경우에도 heartbeat 처리가 지연될 수 있다.

따라서 heartbeat 지연을 조사할 때는 네트워크뿐 아니라 디스크 기록과 CPU 할당 지연도 함께 살펴봐야 한다. 어느 과정에서 지연됐는지 좁히려면 같은 시간대의 로그와 VM 지표를 맞춰 봐야 한다.

처음에는 네트워크 단절을 우선 의심했다. etcd의 heartbeat가 늦어지고 리더 유지에 문제가 생겼으며, API 서버 요청도 제한 시간 안에 끝나지 않았다. 구성원들이 잠시 서로 통신하지 못한 상황으로 볼 수 있었다.

하지만 연결이 끊겼다가 복구되는 구간이 뚜렷하지 않았다. 읽기 요청을 조율하는 과정과 요청 처리, heartbeat가 비슷한 시간대에 함께 지연됐다. 하나의 연결이 끊긴 것 외에 프로세스나 VM이 한동안 처리를 진행하지 못한 상황도 확인할 필요가 있었다.

Grafana의 디스크 지표에서는 읽기·쓰기 지연 시간이 늘어나는 동안 I/O 처리량이 급격히 줄었다. 완료된 I/O가 줄었다는 사실만으로 요청량도 줄었다고 볼 수는 없었다. 처리가 지연돼 완료되는 작업이 줄었을 가능성도 있었으므로, 처리량과 지연 시간을 함께 봤다.

이 패턴만으로 저장 장치의 문제를 확정하거나 부하와 자원 경합을 배제할 수는 없었다. 그래서 etcd가 있는 VM에만 나타나는 현상인지 비교했다.

Kubernetes에서 다른 역할을 맡은 VM에서도 같은 시간대에 비슷한 읽기·쓰기 지연이 보였다. 이 점은 etcd만의 부하로 설명하기 어려웠다. 여러 VM이 공유하는 호스트나 가상 디스크, 스토리지와 네트워크 경로를 확인할 이유가 생겼다.

그래서 우선 확인할 가설을 네트워크 단절에서 여러 VM에 걸친 일시적인 처리 정체로 바꿨다. 호스트가 VM에 CPU를 제때 할당하지 못한 경우, VM 자체가 잠시 멈춘 경우, 가상 디스크나 스토리지 경로가 지연된 경우가 모두 가능했다. 네트워크도 후보에서 제외하지 않았다.

남아 있는 로그와 지표를 시간대별로 맞추면 VM에서 보이는 I/O 지연, etcd의 처리 지연, API 서버의 시간 초과, 리더 갱신 실패가 이어지는 흐름을 재구성할 수 있었다. 다만 지표의 수집 간격과 남은 로그만으로 각 사건의 선후관계를 정밀하게 확정하기는 어려웠다. 이 흐름은 인프라 쪽 지연이 상위 구성 요소에 영향을 줬다는 가설을 뒷받침하는 근거로 정리했다.

VM의 디스크 지연과 etcd 내부의 처리 지연은 측정하는 위치가 다르다. 이 둘을 더 세밀하게 연결하려면 WAL 동기화, 내부 데이터베이스 반영, 구성원 사이의 통신 시간을 나눠 볼 수 있다. 아래는 같은 유형의 지연을 조사할 때 참고할 지표이며, 이 사례에서 확인한 측정 결과는 아니다.

Kubernetes와 VM 안에서 보이는 기록만으로는 호스트의 스케줄링이나 가상 디스크 대기열, 실제 스토리지의 상태까지 확인할 수 없었다. 접속할 수 있는 범위와 변경할 수 있는 범위도 달랐다. 지연이 시작된 위치를 더 좁히려면 호스트와 스토리지의 기록이 필요했다.

접속 당시에는 서비스 경로에서 문제가 확인되지 않았다. 추가로 확인해야 할 대상은 VM에 자원을 할당하는 호스트와 스토리지·네트워크 경로였다. 근거 없이 구성 요소를 재시작하거나 설정을 바꾸는 것으로는 이 가설을 확인할 수 없었다.

추가로 확인할 항목에는 해당 VM들이 호스트나 스토리지 경로를 공유했는지, 장애 시간대에 VM 일시 정지나 CPU 할당 지연이 있었는지를 담았다. 가상 디스크와 스토리지의 대기·전환·점검 기록도 확인 대상이었다. 공통 네트워크 경로에서 지연이 발생했을 가능성도 포함했다.

남은 기록으로 확인한 것은 리더 갱신 실패와 프로세스 종료, 같은 시간대에 나타난 API 서버와 etcd의 지연이었다. 지연이 시작된 위치는 추가 확인이 필요했다. 확인한 사실과 추가 확인이 필요한 내용을 구분하고, 장애 시간대와 영향을 받은 VM을 함께 보고서로 정리해 프로젝트 매니저를 통해 인프라 담당자에게 전달했다.