LabHub

Envoy 내부 구조 · 장애를 다루는 장치들 · 실습

Envoy 를 직접 띄우고 부순다

LabHub 에서 이어서 보기

목표

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/null

setsid --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 설정은 이 순서로 읽으면 헷갈리지 않습니다.

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개

  1. 최소 설정으로 띄운다
  2. admin 으로 들여다본다
  3. 먼저 쓴 라우트가 이긴다
  4. 느린 업스트림을 끊는다
  5. 재시도가 실제로 몇 번 나갔나
  6. 고장난 엔드포인트를 빼낸다
  7. 응답 플래그를 읽는다
  8. 세 가지를 정리한다