istioCon 2022 - Egress Woes: Debugging External service Traffic in istio

Egress Woes: Debugging external service traffic in Istio

https://youtu.be/opLiXzkseCI

발표자료: https://events.istio.io/istiocon-2022/slides/f5b-EgressWoes.pdf

 

VirtualService, DestinationRule, ServiceEntry 등을 만들었다. 그럼 failed Communication을 확인하고 로그 보는 것도 필요함.

• debugging 관련 내용은 이미 많이 알려져 있으니
• Few Common mistakes regarding External Service Traffic을 소개하려 함.

1. istioctl ps / istioctl analyze 써라

 

일반적으로 failed request가 발생할 경우, 아래의 컴포넌트를 확인하는 경우가 많다.

• ServiceEntry를 확인
• sidecar -> egressgateway로 넘어가는 VirtualService 값을 확인

쟤네들 보지 말고 istioctl ps 보는 걸 추천한다.

• request에 문제가 생겼다면, sidecar나 gateway가 통신에 필요한 config정보를 control plane으로부터 받지 못했을 가능성이 매우 높음.
  • 보통은 conflict 또는 misconfiguration가 원인임
• istioctl 명령어의 응답값으로 나오는 'stale' 필드에서 gives you a pointer to the troublesome CRD.
  • LDS (Listener Discovery Service)의 경우 serviceEntry의 port & protocol / VirtualService의 tls block 값에 영향을 받는다.
  • RDS (Router Discovery Service)의 경우 virtualService의 http routing logic에 영향을 받는다
  • CDS (Cluster Discovery Serivce)는 DestinationRule 설정값에 영향을 받는다.

istioctl analyze 도 항상 체크하는 것이 좋다. 여기서 필요한 정보를 확인할 수 있다면, 별도로 디버깅할 이유가 없다.

2. Enable Access logs

Request Fail이 생기기 시작하면 Access Log를 활성화

• 애플리케이션의 failed log는 유용한 정보가 거의 없지만, istio access log는 거의 모든 정보가 다 있다.
  • v1.12 부터 지원하기 시작한 Telemetry CR에서는 workload 단위로 access log을 enabled / disabled 설정할 수 있다. (설치할 때 enable / disable 설정 해뒀는지와는 무관하다)
• 만약 failed request를 확인할 access log가 안 보이거나 app에서 failed to connect 에러 메시지가 보인다면, LDS listener가 잘못된 port / protocol로 설정되어 있을 수 있음.
  • Access log 관련 configuration은 listener level에서 관리됨. 즉 listener 설정이 잘못되어 있다면, access log가 안 보임
  • ServiceEntry 또는 virtualService의 port / protocol 확인해볼 것
• ServiceEntry / VirtualService의 port와 protocol을 제대로 설정했는데도 Access log에서 PassThrough 로그가 나온다?
  • envoy의 해당 트래픽을 관리하는 configuration이 잘못된 상태

모든 external service traffic을 egress gateway를 통해서 나가도록 관리하고 있다면

• sidecar / egressgateway의 access log 둘 다 확인해야 한다.
  • sidecar -> egressgateway? access log의 'upstream cluster name'을 확인하면 된다

 

access log의 필드 이해를 돕기 위한 tool이 있음. Engarde.

• envoy log을 pretty json 형태로, labeled fieldname 형태로 리턴해주는 기능
• includes a special flag for parsing istios custom log format.
• Web ui로도 볼 수 있게 프로젝트 만들었다고 함

 

istio의 request routing 관련한 정보 확인 - why istio decided to route the request the way it did.

• envoy config을 직접 봐야 함. 다만 envoy config raw file을 직접 보면 너무 복잡하다.
• istioctl로 break into smaller chunks. 각 컴포넌트별 config는 어떤 때 봐야 하는지 설명
  • Listeners
    • trace through a request, leaving a sidecar
    • tls / sni based matching 정보 확인
  • Routes
    • serviceEntry + egressgateway 사용해서 specific hosts에 접근하는 로직의 로그
  • Clusters
    • mtls / tls 써서 serviceEntry + egressgateway 통신하는 경우.
  • Endpoints
    • serviceEntry에 endpoint가 정의되어 있는 경우, ip / port가 제대로 정의되어 있는지.
  • secrets
    • mtls나 tls 적용을 위해 custom certificate를 사용할 경우, loaded currectly & not expired 확인.

istioctl 기본 옵션은 high level 응답값을 리턴할 수 있음. 필요한 값이 안 나오면, -o json 옵션으로 필요한 옵션을 전부 확인.

 

그럼에도 istioctl pc listener 에서 리턴하는 필드가 너무 많다.

• envoyctl 사용해서 json parsing을 더 쉽게 할 수 있다.
• envoyui.solo.io 에 업로드해서 parsing할 수도 있다.

Common mistakes

 

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: my-se
spec:
  hosts:
  - this.hostname.does.not.matter
  addresses: # these actually matter
  - 1.2.3.4
  ports:
  - number: 443
    name: tcp
    protocol: TCP

ServiceEntry를 tcp로 생성할 때

• address 필드에 ip나 cidr blocks를 직접 지정하지 않으면
  • 이 serviceEntry는 해당 포트로 들어오는 모든 트래픽을 capture.
  • regardless of hostname.
• there are no hostname headers for traffic defined as tcp / envoy. 따라서 hostname does not matter.

 

Sidecar CR로 sidecar scoping을 너무 크게 잡지 마라.

• Designed to limit the amount of configs that get pushed to a particular envoy sidecar, with performance in mind.

여기 설명은 맥락상 이게 무슨소리인지 이해가 안되서 원문을 그대로 옮김.

if you are not seeing hostnames for services in other namespaces, or the hosts in your serviceEntry from any of the istioctl pc command, make sure they are not getting filtered.

 

Per the docs (문서에 따르면)

• protocol: TLS는 'connection will be routed based on the sni header to the destination, without terminating the tls connection' 를 의미한다.
  • serviceEntry의 경우, istio proxy에서 initial tls connection (originally captured from the application) 을 terminate하지 않는다는 뜻.
  • 이 상황에서 sidecar -> egressagateway 에 additional tls policy / destinationRule을 적용하면, tls가 double encrypted된다.
• 따라서 egressgateway 또는 external Service에서 'malformed request body / unexpected characters' 에러 로그가 보이면, double encryption 때문일 수 있다.