EnvoyFilter 확인

6문항. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

1. `applyTo: HTTP_FILTER`, `subFilter.name: envoy.filters.http.router`, `operation: INSERT_BEFORE` 인 패치가 Envoy 설정에서 되는 것은?

   1. router 필터의 typed_config 안에 value 가 합쳐져 router 의 동작이 바뀐다
   2. 리스너 앞에 새 리스너가 하나 더 생겨 요청이 먼저 그쪽을 지난다
   3. HTTP 연결 관리자의 필터 목록에서 router 바로 앞에 value 가 항목 하나로 끼워진다
   4. router 가 목록에서 빠지고 value 가 그 자리를 대신한다

2. 같은 fault 필터를 `INSERT_AFTER` 로 router 뒤에 끼웠다. istioctl validate 와 Envoy 의 반응으로 맞는 것은?

   1. istioctl 이 필터 순서를 검사해 rc=1 로 막는다
   2. 둘 다 통과하고, fault 가 응답이 돌아올 때 적용된다
   3. Envoy 는 받아들이지만 fault 필터가 조용히 무시된다
   4. istioctl 은 통과시키고, Envoy 는 router 가 마지막이어야 한다며 그 설정을 거절한다

3. EnvoyFilter 에 VirtualService 식 `percentage: { value: 100 }` 을 적었더니 `istioctl validate` 가 rc=0 이었다. 이 결과가 말해 주는 것은?

   1. Envoy 도 같은 규칙으로 검사하므로 그대로 배포해도 된다
   2. 겉 구조는 맞지만 값 안의 모르는 필드는 경고로만 알렸을 뿐, Envoy 가 받아들인다는 보장은 아니다
   3. istioctl 이 value 를 numerator 로 자동 변환해 저장했다
   4. 퍼센트 필드는 Envoy 가 무시하므로 결과에 영향이 없다

4. `workloadSelector` 없는 EnvoyFilter 를 메시 설정의 루트 네임스페이스(`istio-system`)에 두었다. 적용 범위는?

   1. 모든 네임스페이스의 해당 워크로드, 곧 메시 전체
   2. istio-system 네임스페이스의 워크로드만
   3. 선택자가 없으므로 어디에도 적용되지 않는다
   4. 인그레스 게이트웨이에만 적용된다

5. 패치에 `match.proxy.proxyVersion: '^1\.24.*'` 를 거는 가장 큰 이유는?

   1. 1.24 판 프록시의 성능을 높이는 전용 최적화를 켜기 위해
   2. istioctl 이 판을 알아야 값을 검사할 수 있기 때문에
   3. 프록시가 이 정규식으로 istiod 의 판을 확인해 연결을 거절하게 하려고
   4. 판이 바뀐 프록시에는 패치가 붙지 않게 해, 업그레이드로 Envoy 내부가 바뀌어도 옛 패치가 새 프록시를 깨지 않게 하려고

6. `operation: REPLACE` 로 지정한 필터 이름이 대상 목록에 없으면 어떻게 되는가?

   1. 아무 일도 일어나지 않는다 — 오류도 없어서 패치가 빠진 것을 알아채기 어렵다
   2. istiod 가 그 이름으로 새 필터를 목록 끝에 추가한다
   3. Envoy 가 설정을 거절해 리스너 갱신이 NACK 된다
   4. istioctl validate 가 rc=1 로 막는다