引导配置检查

envoy --mode validate -c boot.yaml 이 하는 일로 맞는 것은?

• 설정을 읽어 스키마까지 확인하고, 리스너 포트는 하나도 잡지 않은 채 종료 코드만 남긴다
• 설정을 읽고 리스너를 잠깐 열었다 닫아 포트 충돌까지 함께 확인한다
• 설정 파일의 YAML 문법만 보고 필터 이름이 실재하는지는 보지 않는다
• 이미 떠 있는 Envoy 에 설정을 밀어 넣어 반영 가능한지 물어본다

부트스트랩의 static_resources 안을 요청이 지나가는 순서대로 나열한 것은?

• route_config → listener → cluster → filter_chain → http_connection_manager
• cluster → listener → route_config → filter_chain → http_connection_manager
• listener → filter_chain → http_connection_manager → route_config → cluster
• listener → route_config → cluster → filter_chain → http_connection_manager

한 기계에서 두 번째 Envoy 를 띄웠더니 포트를 전부 비켜 놓았는데도 unable to bind domain socket with base_id=0 으로 죽었다. 원인은?

• 관리 포트가 겹쳐 두 프로세스가 같은 통계 소켓을 열려 했다
• 핫 리스타트용 공유 메모리 영역의 이름이 base id 로 정해지는데 기본값이 둘 다 0 이다
• 리스너 주소가 같은 루프백이라 커널이 두 번째 바인드를 거절했다
• 설정 파일 경로가 같아 두 프로세스가 같은 파일 잠금을 얻으려 했다

admin.address 를 0.0.0.0 으로 두면 안 되는 가장 직접적인 이유는?

• 관리 포트가 평문 HTTP 라 통계 값이 도청될 수 있다
• 관리 포트가 리스너 포트와 같은 워커 스레드를 써서 처리량이 떨어진다
• 관리 포트에는 인증이 없고 /quitquitquit 로 프로세스를 끝낼 수 있다
• 관리 포트는 IPv6 를 지원하지 않아 주소 해석이 어긋난다

엔드포인트 세 개에 요청 아홉 번을 보내 분배를 셌더니 3·3·3 이 아니라 매번 다른 숫자가 나온다. 가장 먼저 의심할 것은?

• --concurrency 기본값이 코어 수라 워커마다 부하 분산 상태가 따로 놀고 있다
• connect_timeout 이 짧아 일부 요청이 다른 엔드포인트로 넘어갔다
• 업스트림 셋의 응답 속도가 달라 최소 요청 방식으로 동작했다
• /config_dump 와 실제 설정이 어긋나 엔드포인트가 둘만 등록됐다

node 를 부트스트랩에 적는 이유로 가장 정확한 것은?

• 정적 설정만 쓸 때도 리스너 이름을 통계에 붙이려면 반드시 있어야 한다
• 관리 포트의 /config_dump 를 활성화하는 열쇠가 node.id 다
• 클러스터 이름과 겹치지 않는 이름을 정해 두어야 라우트가 해석된다
• xDS 서버가 이 이름표를 보고 어느 프록시에 무슨 설정을 줄지 고른다