EnvoyFilter の確認

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

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

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

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

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

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

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

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

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

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

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

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