이 섹션에서는 일반적인 Anthos Service Mesh 문제와 해결 방법을 설명합니다. 추가 지원이 필요하면 지원 받기를 참조하세요.
Istio 로그의 API 서버 연결 오류
다음과 유사한 오류가 표시되면 Istiod가 apiserver에 연결될 수 없습니다.
error k8s.io/client-go@v0.18.0/tools/cache/reflector.go:125: Failed to watch *crd.IstioSomeCustomResource`…dial tcp 10.43.240.1:443: connect: connection refused
정규 표현식 문자열 /error.*cannot list resource/를 사용하여 로그에서 이 오류를 찾을 수 있습니다.
이 오류는 일반적으로 일시적이며 kubectl를 사용하여 프록시 로그에 도달한 경우 문제가 이미 해결되었을 수 있습니다. 이 오류는 일반적으로 API 서버가 업그레이드 또는 자동 확장 변경에 대한 고가용성 구성 재부팅에 없는 경우와 같이 API 서버를 일시적으로 사용할 수 없는 경우에 발생합니다.
istio-init 컨테이너가 비정상 종료됨
이 문제는 pod iptables 규칙이 pod 네트워크 네임스페이스에 적용되지 않을 때 발생할 수 있습니다. 이는 다음과 같은 이유로 발생할 수 있습니다.
- 지나치게 제한적인 pod 보안 정책(PSP)
- 완료되지 않은 istio-cni 설치
- 워크로드 pod 권한 부족(
CAP_NET_ADMIN권한 누락)
CAP_NET_ADMIN 권한을 제한하는 pod 보안 정책을 사용하는 경우 Istio CNI 플러그인을 대신 사용하도록 전환합니다.
Istio CNI 플러그인을 사용하는 경우 안내를 완전히 따랐는지 확인합니다.
istio-cni-node 컨테이너가 준비되었는지 확인하고 로그를 확인합니다. 문제가 지속되면 호스트 노드에 보안 셸(SSH)을 설정하고 노드 로그에서 nsenter 명령어를 검색하여 오류가 있는지 확인합니다.
Istio CNI 플러그인 또는 pod 보안 정책을 사용하지 않는 경우 워크로드 pod에 사이드카 인젝터에서 자동으로 설정하는 CAP_NET_ADMIN 권한이 있는지 확인합니다.
pod가 시작된 후 연결이 거부됨
pod가 시작되고 엔드포인트에 연결을 시도하는 connection refused를 수신했을 때 문제는 isto-proxy 컨테이너 이전에 애플리케이션 컨테이너가 시작된 것일 수 있습니다. 이 경우 애플리케이션 컨테이너는 istio-proxy에 요청을 전송하지만, istio-proxy가 아직 포트에서 아직 수신 대기하지 않기 때문에 연결이 거부됩니다.
이 경우 다음을 수행할 수 있습니다.
애플리케이션이 200 코드를 수신할 때까지
istio-proxy상태 엔드포인트에 지속적인 요청을 수행하도록 애플리케이션의 시작 코드를 수정합니다.istio-proxy상태 엔드포인트는 다음과 같습니다.http://localhost:15020/healthz/ready애플리케이션 워크로드에 재시도 요청 메커니즘을 추가합니다.