Envoy 내부 구조 · 장애를 다루는 장치들 · 실습
Envoy 를 직접 띄우고 부순다
목표
Envoy 를 직접 띄워서 라우팅·타임아웃·재시도·아웃라이어 감지를 하나씩
만들고 부숴 봅니다. Istio 의 데이터 플레인이 바로 이 Envoy 이므로, 여기서
배우는 것은 그대로 메시 장애 대응에 쓰입니다.
환경
envoy --versioncurl -s localhost:9901/stats # admin (띄운 뒤)시작 설정이 /opt/lab/envoy/minimal.yaml 에 있습니다. 베껴서 고치세요.
업스트림 만들기
python3 -m http.server 8081 & # 정상실패하거나 느린 업스트림이 필요하면 /opt/lab/envoy/upstream.py 를 쓰세요.
python3 /opt/lab/envoy/upstream.py 8082 fail & # 항상 503python3 /opt/lab/envoy/upstream.py 8083 slow & # 3초 걸림띄우고 다시 띄우기
setsid --fork nohup envoy -c e.yaml --log-level warn > envoy.log 2>&1 </dev/null# 고친 뒤에는pkill -f 'envoy -c'setsid --fork nohup envoy -c e.yaml --log-level warn > envoy.log 2>&1 </dev/nullsetsid --fork 를 꼭 붙이세요. 그냥 & 로 띄우면 셸이 바뀔 때 같이 죽습니다.--fork 없이 setsid nohup … & 로 띄우면 대화형 셸에서는 살아남지만, 채점이나
단계 준비처럼 셸이 짧게 붙었다 떨어지는 경로에서는 그 셸이 끝날 때 함께 죽습니다.--fork 는 한 번 더 갈라져 나와 PID 1 에 붙으므로 어느 쪽에서든 살아 있습니다.
채점은 살아 있는 Envoy 의 admin 을 보므로, 죽어 있으면 1단계부터 떨어집니다.
설정이 잘못되면 Envoy 는 뜨지 않고 죽습니다. envoy.log 첫 줄에 이유가 있습니다.
Envoy 는 한 번에 하나만 뜬다
포트를 다르게 줘도 두 번째는 이렇게 죽습니다.
unable to bind domain socket with base_id=0, errno=98 (see --base-id option)포트 문제가 아니라 공유 메모리 도메인 소켓이 겹치는 것입니다. 설정 두 개를
비교할 때는 pkill -f 'envoy -c' 로 끄고 다시 띄우세요(또는 --base-id 1).
접근 로그가 안 보일 때
두 가지가 흔합니다.
- Envoy 는 파일 접근 로그를 모아서 씁니다. 요청 직후에 grep 하면 아직 없습니다 — 10초쯤 기다리세요.
- 다시 띄우면
> envoy.log가 파일을 비웁니다. 모으는 중이었다면 다시 만들어야 합니다.
읽는 순서
Envoy 설정은 이 순서로 읽으면 헷갈리지 않습니다.
listener → filter chain → http_connection_manager → route_config → cluster단계
1. 최소 설정으로 띄우기 → 01-boot.txt
2. admin 들여다보기 → 02-admin.txt
3. 라우트 순서 → 03-route.txt
4. 타임아웃 → 04-timeout.txt
5. 재시도 → 05-retry.txt
6. 아웃라이어 감지 → 06-outlier.txt
7. 응답 플래그 → 07-flags.txt
8. 정리 → 08-notes.md
단계 8개
- 최소 설정으로 띄운다
- admin 으로 들여다본다
- 먼저 쓴 라우트가 이긴다
- 느린 업스트림을 끊는다
- 재시도가 실제로 몇 번 나갔나
- 고장난 엔드포인트를 빼낸다
- 응답 플래그를 읽는다
- 세 가지를 정리한다