우리는 준정기적으로 1~5분 정도의 중단을 겪고 있는 프로덕션 kubernetes 클러스터를 보유하고 있습니다. 문제를 해결하려고 노력하고 있지만 정보/지식의 다양한 격차가 있으므로 도움을 주시면 감사하겠습니다.
우리의 모든 사용자 정의 코드 및 소프트웨어는 고가용성이며 최소 2개의 복제본에 배포되며 고가용성은 로드 상태에서 테스트되었습니다.
쿠버네티스 클러스터~이다스팟 인스턴스를 실행하고 포드만 포함하는 스팟 인스턴스가 실행되면 중단 없이 원활하게 계속 실행됩니다. 그러나 우리가 발견한 것은 노드가 해당 노드를 포함할 때 항상 그런 kube-dns
것은 아니지만 이러한 중단이 발생하는 경향이 있다는 것입니다.
GKE에서 1.25를 실행 중이므로 사용이 제한됩니다 kube-dns
. 우리는 3개 노드당 1개의 복제본을 실행하고 있습니다 kube-dns
(일반적으로 9개의 노드가 실행됩니다).그리고kube-dns
configmap을 통해 최소 3개의 노드를 지정했습니다 kube-dns-autoscaler
. 우리는 또한 다양한 이유로 Istio 1.17.1을 실행하고 있지만~ 아니다mTLS용. 또한 중단을 1번만 허용하는 PDB도 있습니다 kube-dns
.
우리가 보는 것은 대부분의 서비스가 서로에 대한 요청에서 시간 초과를 시작하고( istio-proxy
액세스 로그는 오류를 기록하는 경향이 있음 504
UT
) 일부 서비스는 실제로 EAI_AGAIN
오류를 기록한다는 것입니다. 이는 DNS 시간이 초과되었음을 의미합니다. 또한 서비스 이름과 서비스의 IP 주소를 직접 핑하는 별도의 애플리케이션이 실행되고 있습니다(문제 해결 목적으로 이 작업을 시작함). EAI_AGAIN
오류가 발생하는 동안 IP 주소 핑은 성공했지만 서비스 이름 요청은 성공하지 못했습니다. 추가로 kube-dns
문제와 관련이 있음을 나타냅니다.
또한 사이드카가 있는 포드와 없는 포드에 대해 서비스 대 IP 핑을 확인했으며 istio-proxy
동일한 동작을 볼 수 있어 문제가 있음을 암시합니다.~ 아니다때문에 istio
.
우리가 생각하기 시작한 유일한 일은 NodeLocal DNSCache
모든 노드에 DNS 캐시가 있고 간헐적인 문제를 해결할 수 있도록 구현하는 것입니다 kube-dns
. 그러나 이것이 도움이 될지는 확신할 수 없으며 더 큰 문제를 가릴까 봐 걱정됩니다.
비프로덕션 환경에서도 이와 동일한 문제가 실행되는 것을 볼 수 있지만 아직 어디에서나 이를 재현할 수는 없습니다. 그냥 그런 일이 일어납니다. 노드를 다시 시작하거나 삭제해도 이런 일이 발생하지 않는 것 같습니다.
kube-dns
또한 GKE가 배포 리소스를 잠그고 로깅 수준을 되돌렸기 때문에 로깅 수준을 높일 수 없습니다 .
이 문제를 추가로 해결하는 방법에 대한 조언을 바랍니다. 감사합니다