IL-0033 Airbnb · 2019-11-21 (게시일)kubernetesawsnetworking
Airbnb 는 EC2 인스턴스에서 따로 돌던 서비스를 쿠버네티스와 컨테이너로 옮기고 있었다. 운영 이전은 2018년 초에 본격적으로 시작했고 2019년 9월에는 쿠버네티스에서 도는 서비스가 약 천 개였다. 발표는 이전 과정에서 나온 성능 문제 여러 건을 다루며, 이 사례는 그중 kube-dns 가 느려진 건이다.
파드의 DNS 요청은 iptables 를 거쳐 kube-dns 의 클러스터 IP 로 가고, iptables 는 kube-dns 파드 가운데 하나를 무작위로 고른다. 무작위 선택은 부하를 고르게 나누지 못해서 일부 kube-dns 파드에 트래픽이 몰렸다. 그 결과 DNS 초당 패킷 한도에 걸렸고, 여러 서비스에서 응답이 느려지고 타임아웃이 났다.
파드의 기본 DNS 정책은 ClusterFirst 다. 그래서 클러스터 안의 서비스 주소가 아닌 외부 이름을 조회할 때도 질의가 먼저 kube-dns 를 거친다. 영향받은 서비스들은 모두 DNS 에 크게 의존하고 외부 DNS 조회를 많이 하는 서비스였다.
한 서비스의 지연 시간 그래프에 5월 10일부터 스파이크가 보이기 시작했다. 처음에는 1초 안팎까지 튀었고, 이어서 5초, 다시 20초로 올라간 뒤 꽤 오랫동안 그 수준에 머물렀다.
한 서비스만의 일이 아니었다. 여러 서비스의 그래프에서 지연 시간이 올라갔다. 영향받은 서비스들의 공통점은 DNS 에 크게 의존하고 외부 DNS 조회를 많이 한다는 것이었다.
팀이 kube-dns 부하를 들여다보니 어떤 kube-dns 파드는 초당 질의 수가 꽤 높았고 어떤 파드는 낮았다. kube-dns 파드 사이에 트래픽이 고르게 나뉘지 않았다.
문제는 서비스의 지연 시간 그래프에서 처음 드러났다. 같은 모양이 여러 서비스에서 나타나자 팀은 공통점을 찾았고, kube-dns 파드별 질의량을 비교해 불균형을 찾아냈다.
–
–
기본 설정에서 파드는 클러스터 IP 로 DNS 서버를 찾고, dnsPolicy 기본값인 ClusterFirst 때문에 외부 이름 조회도 kube-dns 를 먼저 거친다. 쿠버네티스 DNS 해석이 필요 없는 파드는 dnsPolicy 를 Default 로 두거나, None 으로 두고 세부 값을 직접 정할 수 있다. iptables 는 로드 밸런서가 아니어서 클러스터 IP 뒤의 파드에 부하를 고르게 나누지 못한다. 발표자들은 DNS 정책을 초기부터 자주 확인하고 용도에 맞는 정책을 쓰라고 했다.
같은 원인 · 공통 클라이언트 쪽 DNS 리졸버와 캐시
같은 원인 · 공통 kube-dns
같은 원인 · 공통 클라이언트 쪽 DNS 리졸버와 캐시
같은 원인 · 공통 kube-proxy
같은 원인 · 공통 클라이언트 쪽 DNS 리졸버와 캐시