2,500 노드로 Kubernetes 확장

OpenAI는 D15v2와 NC24 VM의 조합을 사용하여 Azure에서 딥러닝 연구를 지원하기 위해 Kubernetes 인프라를 2,500 노드 이상으로 확장했습니다. 이 확장 작업은 상태 저장소, pod 스케줄링, 컨테이너 이미지 배포, 네트워크 구성에서의 상당한 병목 현상을 극복해야 했습니다.

etcd 성능 및 안정성 최적화

Kubernetes 상태 저장소는 클러스터가 500 및 1,000 노드를 초과함에 따라 심각한 지연 및 용량 문제를 겪었습니다.

쓰기 지연 시간 감소

클러스터가 500 노드를 초과했을 때, 네트워크 연결 SSD에서의 높은 쓰기 지연으로 인해 kubectl 타임아웃이 발생했습니다. OpenAI는 etcd 디렉터리를 인스턴스에 직접 연결된 로컬 임시 디스크(SSD)로 이동시켜 이를 해결했으며, 이로 인해 쓰기 지연이 2ms에서 200us로 감소했습니다.

API 서버 부하 관리

1,000 노드에서 kube-apiservers가 etcd로부터 초당 500MB 이상을 읽으면서 높은 커밋 지연이 다시 발생했습니다. 이는 모든 노드에서 API 서버를 쿼리하는 모니터링 프로세스(Fluentd 및 Datadog)의 적극적인 폴링 때문에 발생했습니다. 이러한 프로세스의 폴링 빈도를 줄여 안정성을 회복했습니다.

이벤트 및 저장소 할당량 격리

이벤트 생성 급증이 메인 클러스터 상태에 영향을 미치지 않도록 방지하기 위해, OpenAI는 --etcd-servers-overrides 플래그를 사용하여 별도의 etcd 클러스터에 Kubernetes Events를 저장했습니다. 또한, --quota-backend-bytes 플래그를 사용하여 기본 2GB etcd 저장소 한도를 증가시켜, etcd가 쓰기를 중지한 후 오토스케일러가 워커를 종료하는 캐스케이드 실패를 방지했습니다.

Kube 마스터 및 스케줄링 조정

OpenAI는 Kubernetes를 배치 스케줄링 시스템으로 사용하며, 유휴 노드의 비용을 최소화하기 위해 커스텀 오토스케일러를 고용합니다.

Bin-Packing 스케줄링 정책

사용되지 않은 노드를 종료하고 대형 pod를 빠르게 스케줄링할 수 있도록 하기 위해, OpenAI는 기본 로드-스프레딩 정책을 'MostRequestedPriority' 정책으로 교체했습니다. 이는 pod를 균등하게 분산시키는 대신 fewer 노드에 bin-packing하도록 장려합니다.

KubeDNS 신뢰성

Bin-Packing 정책으로 인해 일부 머신에서 KubeDNS가 10+ copies 실행되어 Azure VM 외부 도메인 조회 한도(~200 QPS)를 초과하는 핫스팟이 발생했습니다. OpenAI는 pod 반-친화성 규칙을 구현하여 KubeDNS pod가 다른 호스트명에 분산되도록 함으로써 이를 해결했습니다.

Docker 이미지 pull 가속

Dota 프로젝트에 사용된 17GB 이미지와 같은 대용량 컨테이너 이미지는 pod가 Pending 상태에 오래 머무르게 만들었습니다.

Pull 병렬화 및 타임아웃 튜닝

기본적으로 kubelet은 이미지 풀을 직렬화합니다(--serialize-image-pulls=true). 즉, 하나의 큰 이미지가 다른 모든 이미지를 차단할 수 있습니다. OpenAI는 이를 false로 설정하고 Docker 스토리지 드라이버를 overlay2로 전환했습니다. 또한 Docker 루트를 인스턴스에 연결된 SSD로 이동했습니다.

큰 이미지의 추출이 느려 발생하는 rpc error: code = 2 desc = net/http: request canceled 오류를 방지하기 위해, 그들은 --image-pull-progress-deadline를 30분으로 증가시키고 Docker 데몬에서 max-concurrent-downloads를 10으로 설정했습니다.

일반 이미지 사전 로드

노드가 NAT를 통해 Google Container Registry(gcr.io)에 접근할 때 per-IP 할당량 한도에 도달하지 않도록 하기 위해, OpenAI는 docker image save와 docker image load를 사용하여 pod-infra-container-image 및 기타 일반적인 내부 이미지를 워커 머신 이미지에 직접 사전 로드합니다.

네트워킹 및 커널 튜닝

대규모 분산 실험에서 네트워크 스택과 관련된 상당한 처리량 저하 및 연결 문제가 드러났습니다.

Flannel 오버헤드 극복

OpenAI는 Flannel을 사용하는 pod의 처리량이 약 2Gbit/s로 제한되어 있으며, 베어 머신 간에는 10-15Gbit/s임을 관찰했습니다. 고성능 워크로드에 대한 이 오버헤드를 우회하려면 사용자는 pod에 hostNetwork: true 및 dnsPolicy: ClusterFirstWithHostNet를 설정할 수 있습니다.

ARP 캐시 오버플로 해결

간헐적인 DNS 해결 실패 및 연결 정지는 대형 클러스터의 각 pod가 ARP 항목을 소비하여 커널의 ARP 캐시 공간이 부족해져 발생했습니다. 이는 dmesg에서 neighbor table overflow! 메시지로 확인되었습니다. OpenAI는 /etc/sysctl.conf에서 ARP 캐시 임계값을 증가시켜 이를 해결했습니다.

net.ipv4.neigh.default.gc_thresh1 = 80000
net.ipv4.neigh.default.gc_thresh2 = 90000
net.ipv4.neigh.default.gc_thresh3 = 100000