[k8s] 기록 - etcd 리더 선출 실패로 실행되지 않을 경우 리더 선출 없이 실행

문제

control plane A에 control plane을 추가하던 중 control plane A가 죽으면서 control plane B의 etcd 복제가 중지되고 control plane B 추가 과정이 멈추게 되었다.
문제 발생 후 control plane A의 etcd에서 control plane B의 etcd를 찾을 수 없어 리더 선출 실패라는 메시지와 함께 리더 선출을 계속 실패했다.
느낌상 두번째 control plane을 붙이는 중 실패하면서 노드가 짝수가 되어(split-brain) 실패하는걸로 보였다.
리더 선출 실패는 control plane B의 ip가 미사용 interface에 셋팅된 ip로 설정되면서 A와 B의 통신 실패로 리더 선출 과정이 정상적으로 이루어 지지 않았다.
control plane B의 미사용 network interface 내리고 다시 붙여봤지만, A의 etcd 가 죽은 상황이라 k8s api server도 죽은 상황이라 다음 단계를 진행할 수가 없었다.
etcdctl 를 통해 etcd에서 B를 제거하고 싶어도 etcd 리더 선출이 되질 않아 etcdctl는 계속 context expire만 발생해서 etcd member를 제거할수도 없었다. 백업도 해두지 않은 상황이라 control plane A의 etcd를 꼭 다시 살려야만 했다.

해결

여러 삽질 후 강제로 leader로 만드는 옵션을 찾았다. etcd 같은 버전으로 수동으로 실행시켜 보았다.

etcd --data-dir=/var/lib/etcd --force-new-cluster

 해당 옵션으로 잘 실행되고 etcd api 서버도 잘 실행되고, member가 하나만 존재하는 상태로 잘 올라왔다.
데이터도 정상이어서 다행히 k8s cluster가 날라가는 일은 없었다.

• etcd 2버전대 backup을 복구할 경우 사용하던 옵션 같다.
  • https://etcd.io/docs/v2.3/admin_guide/#restoring-a-backup

복구 후 드는 생각들

• 작업 전 백업 필수
• 주기적인 백업 셋팅 필요해 보임
• control plane 붙이기 전 설정 확인
• 휴먼 에러 줄이기 위해 노드 셋팅 자동화
• etcd 3버전에선 snapshot으로 백업을 하는데 snapshot의 경우 etcd api server가 살아 있어야 restore 가능해 보였다. 동일한 문제가 발생한 경우 snapshot으로 복구가 가능할지 테스트 필요함