진짜 구현에서 같은 일이 일어난다

목표

앞의 세 실습에서 손으로 쓴 규칙이 실제 구현에서도 그대로인지 확인합니다. 같은 파드 안에
etcd 세 멤버를 띄워 리더를 옮기고, 하나를 죽이고, 둘을 죽여 봅니다.

왜 중요한가

습작은 배우기 좋지만 믿을 근거가 되지는 않습니다. 쿠버네티스의 모든 상태가 얹혀 있는
etcd 에서 같은 숫자와 같은 말(term, index, quorum)이 나오는 것을 보아야, 앞에서 만든 규칙이
장난감의 규칙이 아니라는 것이 확인됩니다.

가장 중요한 단계는 여섯 번째입니다. 셋 중 둘이 멈추면 쓰기가 막히는 것은 누구나 예상하지만,
읽기도 함께 막힙니다. etcd 의 기본 읽기는 선형화 읽기라 리더가 '나는 아직 리더다' 를
과반에게 확인받은 뒤에야 답하기 때문입니다. 과반을 잃은 클러스터는 느려지는 것이 아니라
멈춥니다 — 이것이 홀수 대를 쓰고 정족수를 계산하는 진짜 이유입니다.

이 파드에는 다른 실습용 etcd 가 2379 에서 따로 돌고 있습니다. 그래서 이 실습은
22379 부터 시작하는 포트를 씁니다.

단계

1. /root/etcd/start.sh 를 만들어 a, b, c 를 띄웁니다.
2. 지금 리더와 임기를 /root/etcd/leader.json 에 적습니다.
3. /raft/lab 에 hello-raft 를 쓰고 다른 멤버에서 읽어 /root/etcd/kv.json 에 적습니다.
4. move-leader 로 리더를 옮기고 /root/etcd/move.json 에 적습니다.
5. 팔로워 하나를 멈춘 채 써 보고 /root/etcd/one-down.json 에 적습니다.
6. b 와 c 를 멈춘 채 쓰기와 읽기를 시도하고 /root/etcd/quorum-loss.json 에 적습니다.
7. 모두 되살린 뒤 /root/etcd/recover.json 에 적습니다.
8. 앞의 실습과 맞춰 본 판정을 /root/etcd/verdict.json 에 적습니다.

참고

• 엔드포인트 묶음: --endpoints=127.0.0.1:22379,127.0.0.1:22479,127.0.0.1:22579
• 상태 표: etcdctl --endpoints=... endpoint status --write-out=table
• 건강 확인: etcdctl --endpoints=... endpoint health
• 멈추기: pkill -9 -f /root/etcd/b · 되살리기: bash /root/etcd/start.sh
• 곱게(-9 없이) 멈추면 리더가 물러날 곳을 찾다가 끝내 내려가지 못합니다. 고장을 흉내 내는 자리이니 강제로 멈추세요.
• 흔한 실수 1: 세 멤버의 --initial-cluster 문자열이 서로 다른 것. 한 글자만 달라도 클러스터가 되지 않습니다.
• 흔한 실수 2: move-leader 를 팔로워 엔드포인트에 보내는 것. 지금 리더에게 보내야 합니다.
• 응답이 없을 때는 --command-timeout=4s 를 붙이세요. 기본값으로는 오래 기다립니다.

단계 8개

1. 세 멤버를 정적 부트스트랩으로 띄운다
2. 누가 리더인지 읽어 낸다
3. 어디에 물어도 같은 값
4. 리더를 옮기면 임기가 오른다
5. 하나가 죽어도 쓰기는 된다
6. 둘이 죽으면 읽기도 멈춘다
7. 되살아난 뒤에 남는 것
8. 손으로 만든 규칙과 같은가