IL-0182 이언철 · 2024-04-16 (게시일)kubernetesaws
글쓴이의 EKS 클러스터에서는 트래픽이 급변할 때 CoreDNS 에 부하가 몰려 네트워크 문제와 지연 급증이 생겼다. HPA 가 파드를 늘리면서 데이터베이스 커넥션이 급증했고, 영향은 서비스 전체로 번졌다. 요청이 들어올 때 동작하는 작업용 파드들은 CoreDNS 수가 모자라 네트워크가 간헐적으로 끊겼다.
글쓴이는 먼저 세 가지를 적용했다. 첫째, 클러스터 크기에 맞춰 CoreDNS 를 늘리는 Cluster Proportional Autoscaler 를 설정했다. CPA 라고 부르는 이 도구에 인스턴스 타입에 맞는 nodesPerReplica 와 coresPerReplica 를 정하고, 모니터링하며 replica 최솟값과 최댓값을 조정했다. 둘째, CoreDNS 에 anti-affinity 대신 topologySpreadConstraints 를 걸고 ScheduleAnyway 로 제약을 느슨하게 해 Karpenter 의 Consolidation 과 Drift 가 CoreDNS 에 막히지 않게 했다. 이는 Karpenter 가 권하는 방식이다. CoreDNS EKS 애드온은 v1.9.3-eksbuild.11 과 v1.10.1-eksbuild.7 부터 topologySpreadConstraints 를 기본값으로 넣는다. 셋째, CoreDNS 의 Error Rate, Panics, Request Duration, Request Rate 에 임곗값 알림을 만들었다.
이렇게 운영하던 중 CoreDNS replica 를 과하게 늘린 것이 새 문제를 낳았다. 모든 노드에 taint 가 있어 CoreDNS 가 특정 노드에만 몰렸다. maxSkew 1 을 지키려다 노드마다 CoreDNS 파드가 3~4개씩 생겼고, 이 노드들은 Consolidation 되지 못했다. 글쓴이는 메인 CoreDNS 의 부하 자체를 낮추려고 NodeLocal DNSCache 를 적용했다. 노드마다 DaemonSet 으로 뜬 로컬 CoreDNS 가 DNS 캐시 역할을 하고, 그 노드의 파드는 모두 로컬 CoreDNS 에 질의한다. 로컬 CoreDNS 는 캐시에서 답하거나 질의를 메인 CoreDNS 로 넘긴다. 적용 뒤 운영 지표가 크게 나아졌고, 노드가 Consolidation 되지 못해 과하게 늘어나던 문제도 풀렸다.
트래픽이 급하게 오르내리는 환경에서 CoreDNS 에 부하가 몰렸다. 네트워크 문제가 생기고 응답 지연이 크게 늘었다.
지연이 늘자 HPA 가 파드를 늘렸고, 늘어난 파드가 데이터베이스 커넥션을 급격히 늘렸다. 문제는 서비스 전체로 번졌다. 요청이 들어올 때 뜨는 작업용 파드들은 노드를 유연하게 쓰는 구조였는데, 수가 적은 CoreDNS 가 이들을 감당하지 못했다. 이 파드들은 네트워크가 간헐적으로 끊겨 제대로 동작하지 못했다.
글쓴이는 CoreDNS 를 클러스터 크기에 맞춰 늘리는 Cluster Proportional Autoscaler 인 CPA, topologySpreadConstraints, 알림 조건을 적용해 운영하다가 새 문제를 발견했다. 안정성을 위해 CoreDNS replica 를 지나치게 늘린 것이 문제였다. 모든 노드에 taint 가 걸려 있어서 Deployment 로 띄운 CoreDNS 는 default 같은 특정 노드에만 떴다. topologySpreadConstraints 의 maxSkew 1 을 지키려다 노드 하나에 CoreDNS 파드가 3~4개씩 생겼고, 그 노드들은 Karpenter 의 노드 통합 기능인 Consolidation 으로 정리되지 못했다. 노드는 필요 이상으로 늘어난 채 남았다.
원인 ? 용량 한계
–
–
CoreDNS 가 감당할 수 있는 양은 파드에 준 리소스에 따라 다르고, 그에 따라 평균 지연과 초당 질의 수인 QPS 도 달라진다. CoreDNS replica 를 무작정 늘리면 taint 와 topologySpreadConstraints 때문에 파드가 몇몇 노드에 몰려 Karpenter 의 Consolidation 을 막을 수 있다. 노드 하나가 드레인될 때 그 노드의 CoreDNS 가 한꺼번에 많이 종료되면 서비스에 영향이 갈 수 있다. NodeLocal DNSCache 를 쓰면 메인 CoreDNS 로 가는 DNS 질의가 크게 줄고 스파이크를 다루기 쉬워진다. 어느 노드에서 문제가 생겨도 메인 CoreDNS 는 영향을 받지 않는다. 그래서 서비스 전체 장애로 번질 일이 노드 하나의 문제로 그친다. 글쓴이는 CPA 와 NodeLocal DNSCache 를 함께 적용해 CoreDNS 부하 문제를 거의 없앴다고 보았다.
같은 원인 · 공통 수평 파드 오토스케일러, CoreDNS
같은 원인 · 공통 CoreDNS
같은 원인 · 공통 수평 파드 오토스케일러
같은 원인 · 공통 파드 스케줄링과 배치
같은 원인 · 공통 CoreDNS
같은 원인 · 공통 CoreDNS
같은 원인 · 공통 CoreDNS
같은 원인 · 공통 CoreDNS
같은 원인 · 공통 Karpenter
같은 원인 · 공통 파드 스케줄링과 배치
같은 원인 · 공통 파드 스케줄링과 배치