마지막 게시물 이후 2,500 개 노드로 확장 우리는 많은 추가 교훈을 배우는 과정에서 연구원의 요구를 충족시키기 위해 인프라를 지속적으로 성장 시켰습니다. 이 게시물은 Kubernetes 커뮤니티의 다른 사람들이 혜택을 누릴 수 있도록 이러한 교훈을 요약하고 다음에 해결해야 할 문제로 끝납니다.

우리의 업무량

너무 멀리 가기 전에 워크로드를 설명하는 것이 중요합니다. Kubernetes로 실행하는 애플리케이션과 하드웨어는 일반적인 회사에서 접할 수있는 것과 매우 다릅니다. 우리의 문제와 해당 솔루션은 사용자의 설정에 잘 맞을 수도 있고 그렇지 않을 수도 있습니다!

대규모 기계 학습 작업은 여러 노드에 걸쳐 있으며 각 노드의 모든 하드웨어 리소스에 액세스 할 수있을 때 가장 효율적으로 실행됩니다. 이를 통해 GPU는 다음을 사용하여 직접 교차 통신 할 수 있습니다. NVLink또는 GPU를 사용하여 NIC와 직접 통신합니다. GPU다이렉트. 따라서 많은 워크로드에서 단일 포드가 전체 노드를 차지합니다. 모든 NUMA, CPU 또는 PCIE 리소스 경합은 스케줄링의 요소가 아닙니다. 빈 포장 또는 조각화는 일반적인 문제가 아닙니다. 현재 클러스터에는 전체 이분 대역폭이 있으므로 랙 또는 네트워크 토폴로지를 고려하지 않습니다. 이 모든 것은 노드가 많지만 스케줄러에 상대적으로 부담이 적다는 것을 의미합니다.

즉, kube-scheduler에 대한 부담은 뾰족합니다. 새 작업은 한 번에 생성되는 수백 개의 포드로 구성 될 수 있으며 상대적으로 낮은 이탈률로 돌아갑니다.

우리의 가장 큰 작업은 MPI를 실행하고 작업 내의 모든 포드는 단일 MPI 커뮤니케이터에 참여합니다. 참여하는 포드 중 하나라도 죽으면 전체 작업이 중지되고 다시 시작해야합니다. 작업 체크 포인트는 정기적으로 시작되며 다시 시작되면 마지막 체크 포인트부터 다시 시작됩니다. 따라서 우리는 포드가 세미 스테이트 풀— 죽은 포드를 교체하고 작업을 계속할 수 있지만 그렇게하면 방해가되므로 최소한으로 유지해야합니다.

우리는 Kubernetes 부하 분산에 그다지 의존하지 않습니다. A / B 테스트, 블루 / 그린 또는 카나리아가 필요없는 HTTPS 트래픽이 거의 없습니다. 포드는 서비스 엔드 포인트가 아닌 SSH를 통해 MPI를 사용하여 포드 IP 주소에서 서로 직접 통신합니다. 서비스 "검색"은 제한적입니다. 작업 시작시 pod가 MPI에 참여하는 일회성 조회 만 수행합니다.

대부분의 작업은 특정 형태의 Blob 저장소와 상호 작용합니다. 일반적으로 Blob Storage에서 직접 데이터 세트 또는 체크 포인트의 일부 샤드를 스트리밍하거나 빠른 로컬 임시 디스크에 캐시합니다. POSIX 의미 체계가 유용한 경우를 위해 몇 가지 PersistentVolume이 있지만 Blob 저장소는 훨씬 더 확장 가능하고 느린 분리 / 연결 작업이 필요하지 않습니다.

마지막으로 우리 작업의 본질은 근본적으로 연구이며, 이는 작업 부하 자체가 끊임없이 변화하고 있음을 의미합니다. 슈퍼 컴퓨팅 팀은 "프로덕션"품질 수준의 컴퓨팅 인프라를 제공하기 위해 노력하고 있지만 해당 클러스터에서 실행되는 애플리케이션은 수명이 짧고 개발자는 빠르게 반복합니다. 새로운 사용 패턴은 트렌드와 적절한 트레이드 오프에 대한 우리의 가정에 도전하는 언제든지 나타날 수 있습니다. 상황이 변할 때 신속하게 대응할 수있는 지속 가능한 시스템이 필요합니다.

네트워킹

클러스터 내의 노드 및 포드 수가 증가함에 따라 Flannel이 필요한 처리량을 확장하는 데 어려움이 있음을 발견했습니다. 각 클라우드 제공 업체 (GCP의 관리 형 인스턴스 그룹 용 별칭 IP, Azure의 VMSS 용 IP 구성) 및 관련 CNI 플러그인에 대해 기본 포드 네트워킹 기술을 사용하도록 전환했습니다. 이를 통해 포드에서 호스트 수준의 네트워크 처리량을 얻을 수있었습니다.

별칭 기반 IP 주소 지정을 사용하도록 전환 한 또 다른 이유는 가장 큰 클러스터에서 한 번에 약 200,000 개의 IP 주소를 사용할 수 있기 때문입니다. 경로 기반 포드 네트워킹을 테스트했을 때 효과적으로 사용할 수있는 경로 수에 상당한 제한이 있음을 발견했습니다.

캡슐화를 피하면 기본 SDN 또는 라우팅 엔진에 대한 요구가 증가하지만 네트워킹 설정이 간단 해집니다. 추가 어댑터없이 VPN 또는 터널링을 추가 할 수 있습니다. 네트워크의 일부가 MTU가 더 낮기 때문에 패킷 조각화에 대해 걱정할 필요가 없습니다. 네트워크 정책 및 트래픽 모니터링은 간단합니다. 패킷의 소스와 대상에 대한 모호성이 없습니다.

호스트에서 iptables 태깅을 사용하여 네임 스페이스 및 포드 당 네트워크 리소스 사용량을 추적합니다. 이를 통해 연구원은 네트워크 사용 패턴을 시각화 할 수 있습니다. 특히, 많은 실험에서 서로 다른 인터넷 및 포드 내 통신 패턴이 있기 때문에 병목 현상이 발생할 수있는 위치를 조사 할 수 있으면 유용합니다.

iptables에 mangle 규칙을 사용하여 특정 기준과 일치하는 패킷을 임의로 표시 할 수 있습니다. 다음은 트래픽이 내부 트래픽인지 인터넷 경계인지 감지하는 규칙입니다. 그만큼 FORWARD 규칙은 포드의 트래픽을 다룹니다. INPUT 과 OUTPUT 호스트의 트래픽 :

iptables -t mangle -A INPUT ! -s 10.0.0.0/8 -m comment --comment "iptables-exporter openai traffic=internet-in"
iptables -t mangle -A FORWARD ! -s 10.0.0.0/8 -m comment --comment "iptables-exporter openai traffic=internet-in"
iptables -t mangle -A OUTPUT ! -d 10.0.0.0/8 -m comment --comment "iptables-exporter openai traffic=internet-out"
iptables -t mangle -A FORWARD ! -d 10.0.0.0/8 -m comment --comment "iptables-exporter openai traffic=internet-out"

일단 표시되면 iptables는 카운터를 시작하여이 규칙과 일치하는 바이트 및 패킷 수를 추적합니다. 다음을 사용하여이 카운터를 눈으로 볼 수 있습니다. iptables 그 자체:

% iptables -t mangle -L -v
Chain FORWARD (policy ACCEPT 50M packets, 334G bytes) pkts bytes target prot opt in out source destination
....
1253K 555M all -- any any anywhere !10.0.0.0/8 /* iptables-exporter openai traffic=internet-out */
1161K 7937M all -- any any !10.0.0.0/8 anywhere /* iptables-exporter openai traffic=internet-in */

우리는 오픈 소스 Prometheus 내보내기를 사용합니다. iptables 내보내기 모니터링 시스템에 추적 할 수 있습니다. 다양한 유형의 조건과 일치하는 패킷을 추적하는 간단한 방법입니다.

네트워크 모델의 다소 독특한 측면 중 하나는 노드, 포드 및 서비스 네트워크 CIDR 범위를 연구원에게 완전히 노출한다는 것입니다. 허브 및 스포크 네트워크 모델이 있으며 기본 노드 및 포드 CIDR 범위를 사용하여 해당 트래픽을 라우팅합니다. 연구원은 허브에 연결하고 거기에서 개별 클러스터 (스포크)에 액세스 할 수 있습니다. 그러나 클러스터 자체는 서로 통신 할 수 없습니다. 이렇게하면 장애 격리를 중단 할 수있는 클러스터 간 종속성없이 클러스터가 격리 된 상태로 유지됩니다.

“NAT”호스트를 사용하여 클러스터 외부에서 들어오는 트래픽에 대한 서비스 네트워크 CIDR 범위를 변환합니다. 이 설정을 통해 연구원들은 실험을 위해 선택할 수있는 네트워크 구성의 종류와 방법을 선택할 수 있습니다.

API 서버

Kubernetes API 서버 및 etcd는 정상 작동하는 클러스터의 핵심 구성 요소이므로 이러한 시스템의 스트레스에 특히주의를 기울입니다. 우리는에서 제공하는 Grafana 대시 보드를 사용합니다. 쿠베 프로 메테우스, 추가 사내 대시 보드. API 서버에서 HTTP 상태 429 (너무 많은 요청) 및 5xx (서버 오류) 비율을 높은 수준의 문제 신호로 경고하는 것이 유용하다는 사실을 발견했습니다.

일부 사람들은 kube 내에서 API 서버를 실행하지만 우리는 항상 클러스터 자체 외부에서 실행했습니다. etcd 및 API 서버는 모두 자체 전용 노드에서 실행됩니다. 우리의 가장 큰 클러스터는 5 개의 API 서버와 5 개의 etcd 노드를 실행하여 부하를 분산하고 하나가 다운 될 경우 영향을 최소화합니다. Kubernetes 이벤트를 자체 etcd 클러스터로 다시 분할 한 이후로 etcd와 관련하여 주목할만한 문제가 없었습니다. 마지막 블로그 게시물. API 서버는 상태 비 저장이며 일반적으로자가 복구 인스턴스 그룹 또는 확장 집합에서 실행하기 쉽습니다. 사건이 극히 드물기 때문에 아직 etcd 클러스터의자가 치유 자동화를 구축하려고 시도하지 않았습니다.

API 서버는 상당한 양의 메모리를 차지할 수 있으며 이는 클러스터의 노드 수에 따라 선형 적으로 확장되는 경향이 있습니다. 7,500 개의 노드가있는 클러스터의 경우 API 서버 당 최대 70GB의 힙이 사용되는 것을 관찰하므로 다행히도 이는 향후에도 하드웨어 기능 내에서 계속 유지되어야합니다.

API 서버에 대한 한 가지 큰 부담은 Endpoints의 WATCH입니다. 클러스터의 모든 노드가 구성원 인 'kubelet'및 'node-exporter'와 같은 몇 가지 서비스가 있습니다. 클러스터에서 노드를 추가하거나 제거하면이 WATCH가 실행됩니다. 그리고 일반적으로 각 노드 자체가 kubelet kube-proxy를 통한 서비스를 제공하는 경우 이러한 응답에 필요한 # 및 대역폭은 $ N ^ 2 $이며 엄청나게, 때로는 1GB / s 이상입니다. 엔드포인트 슬라이스쿠 버네 티스 1.17에서 출시 된는이로드를 1000 배로 줄인 큰 이점이었습니다.

일반적으로 우리는 클러스터 크기에 따라 확장되는 API 서버 요청을 매우 염두에두고 있습니다. DaemonSet이 API 서버와 상호 작용하지 않도록 노력합니다. 변경 사항을 감시하기 위해 각 노드가 필요한 경우 다음과 같은 중개 캐싱 서비스를 도입합니다. Datadog 클러스터 에이전트, 클러스터 전체의 병목 현상을 방지하는 좋은 패턴 인 것 같습니다.

클러스터가 성장함에 따라 클러스터의 실제 자동 확장을 덜 수행합니다. 하지만 한 번에 너무 많은 자동 확장을 할 때 가끔 문제가 발생합니다. 새 노드가 클러스터에 가입 할 때 생성되는 많은 요청이 있으며 한 번에 수백 개의 노드를 추가하면 API 서버 용량에 과부하가 발생할 수 있습니다. 이를 단 몇 초라도 매끄럽게 처리하면 중단을 피할 수 있습니다.

Prometheus 및 Grafana를 사용한 시계열 메트릭

Prometheus를 사용하여 시계열 메트릭을 수집하고 Grafana를 그래프, 대시 보드 및 경고에 대해 수집합니다. 우리는 쿠베 프로 메테우스 시각화를위한 다양한 메트릭과 좋은 대시 보드를 수집합니다. 시간이 지남에 따라 자체 대시 보드, 메트릭 및 경고를 많이 추가했습니다.

점점 더 많은 노드를 추가함에 따라 Prometheus에서 수집하는 엄청난 양의 메트릭으로 어려움을 겪었습니다. kube-prometheus는 많은 유용한 데이터를 노출하지만 일부는 실제로 살펴 보지 않았고 일부는 효과적으로 수집, 저장 및 쿼리하기에는 너무 세분화되었습니다. 우리는 사용 Prometheus 규칙 이러한 메트릭 중 일부가 수집되지 않도록 "삭제"합니다.

한동안 우리는 Prometheus가 결국 OOM (Out-Of-Memory 오류)에서 컨테이너를 충돌시킬 때까지 점점 더 많은 메모리를 소비하는 문제로 고생했습니다. 이는 애플리케이션에 엄청난 양의 메모리 용량을 투입 한 후에도 발생하는 것 같습니다. 더 나쁜 것은 충돌이 발생했을 때 다시 사용할 수있게되기 전에 미리 쓰기 로그 파일을 재생하는 시작에 많은 시간이 걸린다는 것입니다.

결국 우리 이 OOM의 소스를 추적했습니다. Grafana와 Prometheus 사이의 상호 작용으로 Grafana는 /api/v1/series 쿼리가있는 Prometheus의 API {le!=""} (기본적으로 "모든 히스토그램 메트릭을 제공하십시오"). 구현 /api/v1/series 결과가 많은 쿼리의 경우 시간과 공간 모두에서 제한이 없습니다. 이는 계속해서 더 많은 메모리와 시간을 소비합니다. 요청자가 연결을 포기하고 닫은 후에도 계속 증가합니다. 우리에게는 메모리가 충분하지 않았고 Prometheus는 결국 충돌했습니다. 우리 패치 된 Prometheus는 시간 제한을 적용하기 위해 컨텍스트 내에이 API를 포함하여 완전히 수정했습니다.

Prometheus는 훨씬 덜 자주 충돌했지만 다시 시작해야하는 경우에는 WAL 재생이 문제로 남아있었습니다. Prometheus가 새 메트릭을 수집하고 쿼리를 서비스하기 전에 모든 WAL 로그를 재생하는 데 종종 많은 시간이 걸립니다. 의 도움으로 강력한 인식, 우리는 GOMAXPROCS=24 크게 개선되었습니다. Prometheus는 WAL 재생 중에 모든 코어를 사용하려고하며 코어 수가 많은 서버의 경우 경합으로 인해 모든 성능이 저하됩니다.

모니터링 용량을 늘리기위한 새로운 옵션을 모색하고 있습니다.미해결 문제"섹션을 참조하십시오.

상태 점검

이 정도 규모의 클러스터에서는 물론 자동화에 의존하여 클러스터에서 오작동하는 노드를 감지하고 제거합니다. 시간이 지남에 따라 우리는 여러 건강 검사 시스템을 구축했습니다.

수동적 상태 점검

일부 상태 확인은 수동적이며 항상 모든 노드에서 실행됩니다. 네트워크 연결성, 불량 또는 가득 찬 디스크 또는 GPU 오류와 같은 기본 시스템 리소스를 모니터링합니다. GPU는 여러 가지 방식으로 문제를 나타내지 만 쉬운 일반적인 문제는 "수정할 수없는 ECC 오류"입니다. Nvidia의 DCGM (Data Center GPU Manager) 도구를 사용하면이 오류와 기타 여러 "Xid"오류를 쉽게 쿼리 할 수 ​​있습니다. 이러한 오류를 추적하는 한 가지 방법은 dcgm 내보내기 모니터링 시스템 인 Prometheus에 메트릭을 수집합니다. 이것은 DCGM_FI_DEV_XID_ERRORS 메트릭이며 가장 최근에 발생한 오류 코드로 설정됩니다. 또한 NVML 장치 쿼리 API GPU의 상태 및 작동에 대한 자세한 정보를 제공합니다.

오류를 감지하면 GPU 또는 시스템을 재설정하여 문제를 해결할 수 있지만 경우에 따라 기본 GPU를 물리적으로 교체해야하는 경우도 있습니다.

또 다른 형태의 상태 확인은 업스트림 클라우드 공급자의 유지 관리 이벤트를 추적합니다. 각 주요 클라우드 제공 업체는 현재 VM이 결국 중단을 유발할 예정된 유지 관리 이벤트로 인해 예정되어 있는지 알 수있는 방법을 제공합니다. 기본 하이퍼 바이저 패치를 적용하거나 물리적 노드를 다른 하드웨어로 교체 할 수 있도록 VM을 재부팅해야 할 수 있습니다.

이러한 수동 상태 확인은 모든 노드의 백그라운드에서 지속적으로 실행됩니다. 상태 확인이 실패하기 시작하면 노드가 자동으로 연결되므로 노드에서 새 포드가 예약되지 않습니다. 더 심각한 상태 확인 실패의 경우 현재 실행중인 모든 포드를 즉시 종료하도록 요청하는 포드 제거를 시도합니다. 이 제거를 허용할지 여부를 결정하는 것은 포드 중단 예산을 통해 구성 할 수있는 포드 자체에 달려 있습니다. 결국 모든 포드가 종료되거나 7 일이 경과 한 후 (SLA의 일부) VM을 강제로 종료합니다.

활성 GPU 테스트

불행히도 모든 GPU 문제가 DCGM을 통해 표시되는 오류 코드로 나타나는 것은 아닙니다. 추가 문제를 포착하고 하드웨어와 드라이버가 예상대로 작동하는지 확인하기 위해 GPU를 실행하는 자체 테스트 라이브러리를 구축했습니다. 이러한 테스트는 백그라운드에서 실행할 수 없습니다. 실행하려면 몇 초 또는 몇 분 동안 GPU를 독점적으로 사용해야합니다.

먼저 "프리 플라이트"라고 부르는 시스템의 부팅시 노드에서 이러한 테스트를 실행합니다. 모든 노드는 "프리 플라이트"taint 및 레이블이 적용된 클러스터에 가입합니다. 이 taint는 노드에서 일반 포드가 예약되지 않도록합니다. DaemonSet은이 레이블이있는 모든 노드에서 프리 플라이트 테스트 포드를 실행하도록 구성됩니다. 테스트가 성공적으로 완료되면 테스트 자체가 taint와 레이블을 제거하고 노드를 일반 용도로 사용할 수 있습니다.

그런 다음 노드 수명 동안 주기적으로 이러한 테스트를 실행합니다. 우리는 이것을 CronJob으로 실행하여 클러스터에서 사용 가능한 모든 노드에 착륙 할 수 있도록합니다. 이것은 어느 노드가 테스트되는지에 대해 약간 무작위적이고 통제되지 않지만 시간이 지남에 따라 최소한의 조정 또는 중단으로 충분한 범위를 제공한다는 것을 발견했습니다.

할당량 및 리소스 사용량

클러스터를 확장함에 따라 연구원들은 할당 된 모든 용량을 확보하는 데 어려움을 겪기 시작했습니다. 기존 작업 스케줄링 시스템에는 Kubernetes에는없는 경쟁 팀 간의 작업을 공정하게 실행하는 데 사용할 수있는 다양한 기능이 있습니다. 시간이 지남에 따라 이러한 작업 예약 시스템에서 영감을 얻어 Kubernetes 네이티브 방식으로 여러 기능을 구축했습니다.

팀 오염

각 클러스터에는 여러 기능을 가진 "team-resource-manager"라는 서비스가 있습니다. 데이터 소스는 주어진 클러스터에 용량이있는 모든 연구 팀에 대한 튜플 (노드 선택기, 적용 할 팀 레이블, 할당량)을 지정하는 ConfigMap입니다. 이를 클러스터의 현재 노드와 조정하여 적절한 수의 노드를 openai.com/team=teamname:NoSchedule.

"team-resource-manager"는 또한 각 작업이 제출 될 때 제출자의 팀 멤버십에 따라 해당 허용이 적용되는 승인 웹훅 서비스를 가지고 있습니다. taint를 사용하면 Kubernetes 포드 스케줄러를 유연하게 제한 할 수 있습니다. 예를 들어 우선 순위가 낮은 포드에 대해 "모든"허용을 허용하여 팀이 무거운 조정없이 서로의 용량을 빌릴 수 있습니다.

CPU 및 GPU 풍선

클러스터 자동 확장 처리를 사용하여 VM 지원 클러스터를 동적으로 확장하는 것 외에도 클러스터 내에서 비정상적인 구성원을 수정 (제거 및 다시 추가)하는 데 사용합니다. 클러스터의 "최소 크기"를 XNUMX으로 설정하고 클러스터의 "최대 크기"를 사용 가능한 용량으로 설정하여이를 수행합니다. 그러나 cluster-autoscaler는 유휴 노드를 발견하면 필요한 용량으로 만 축소하려고 시도합니다. 여러 가지 이유로 (VM 스핀 업 지연 시간, 사전 할당 된 비용, 위에서 언급 한 API 서버에 미치는 영향) 이러한 유휴 확장은 이상적이지 않습니다.

그래서 우리는 CPU 전용 호스트와 GPU 호스트 모두를위한 벌룬 배포를 도입했습니다. 이 배포에는 우선 순위가 낮은 포드가 "최대 크기"인 ReplicaSet가 포함되어 있습니다. 이러한 포드는 노드 내에서 리소스를 차지하므로 자동 확장 처리는이를 유휴 상태로 간주하지 않습니다. 그러나 우선 순위가 낮기 때문에 스케줄러가 즉시 제거하여 실제 작업을위한 공간을 확보 할 수 있습니다. (우리는 DaemonSet가 노드에서 유휴 워크로드로 간주되는 것을 방지하기 위해 DaemonSet 대신 배포를 사용하기로 선택했습니다.)

한 가지 주목할 점은 포드 반친 화성을 사용하여 포드가 노드 전체에 균등하게 분산되도록합니다. 이전 버전의 Kubernetes 스케줄러에는 포드 반 친화성에 $ O (N ^ 2) $ 성능 문제가있었습니다. 이것은 Kubernetes 1.18 이후 수정되었습니다.

갱 스케줄링

우리의 실험은 종종 하나 이상의 StatefulSet을 포함하며, 각각은 훈련 노력의 다른 부분을 운영합니다. 옵티마이 저의 경우 연구원은 교육을 수행하기 전에 StatefulSet의 모든 구성원을 예약해야합니다 (우리는 종종 MPI를 사용하여 옵티 마이저 구성원간에 조정하고 MPI는 그룹 구성원 변경에 민감 함).

그러나 기본적으로 Kubernetes는 한 StatefulSet의 모든 요청을 다른 것보다 먼저 처리하는 데 우선 순위를 두지 않습니다. 예를 들어 두 실험이 각각 클러스터 용량의 100 %를 요청한 경우, 한 실험 또는 다른 실험을 모두 예약하는 대신 Kubernetes는 각 실험 포드의 절반 만 예약하여 두 실험 모두 진행할 수없는 교착 상태로 이어질 수 있습니다.

사용자 지정 스케줄러가 필요한 몇 가지 작업을 시도했지만 정상적인 포드 예약 방식과 충돌을 일으키는 엣지 케이스가 발생했습니다. Kubernetes 1.18은 핵심 Kubernetes 스케줄러 용 플러그인 아키텍처를 도입하여 기본적으로 이와 같은 기능을 훨씬 쉽게 추가 할 수 있습니다. 우리는 최근에 Coscheduling 플러그인 이 문제를 해결하는 좋은 방법입니다.

미해결 문제

Kubernetes 클러스터를 확장하면서 해결해야 할 많은 문제가 있습니다. 그중 몇 가지는 다음과 같습니다.

통계

우리의 규모에서 우리는 Prometheus의 내장 TSDB 스토리지 엔진이 압축 속도가 느리고 다시 시작할 때마다 WAL (Write-Ahead-Log)을 재생하는 데 오랜 시간이 필요하다는 점에서 많은 어려움을 겪었습니다. 쿼리는 또한 "쿼리 처리가 너무 많은 샘플을로드 할 것"오류를 발생시키는 경향이 있습니다. 다른 Prometheus 호환 저장소 및 쿼리 엔진으로 마이그레이션하는 중입니다. 어떻게 진행되는지에 대한 향후 블로그 게시물을 기대하십시오!

포드 네트워크 트래픽 형성

클러스터를 확장 할 때 각 포드는 일정량의 인터넷 대역폭을 사용할 수있는 것으로 계산됩니다. XNUMX 인당 총 인터넷 대역폭 요구 사항이 상당 해졌고 이제 연구원들은 다운로드 용 데이터 세트 및 설치할 소프트웨어 패키지와 같은 인터넷의 다른 위치에 의도하지 않게 상당한 리소스 부담을 가할 수 있습니다.

결론

쿠 버네 티스는 우리의 연구 요구에 매우 유연한 플랫폼이라는 것을 알게되었습니다. 가장 까다로운 워크로드를 충족하도록 확장 할 수 있습니다. 아직 개선이 필요한 영역이 많이 있으며 OpenAI의 슈퍼 컴퓨팅 팀은 Kubernetes가 확장 할 수있는 방법을 계속 탐구 할 것입니다. 이런 종류의 작업이 흥미로워 보인다면 적용 OpenAI에서!

출처 : https://openai.com/blog/scaling-kubernetes-to-7500-nodes/