노드에 리소스가 부족할 때 Kubernetes 노드 확장
pod 리소스 요청을 고려할 충분한 여유 리소스가있는 노드가 없기 때문에 pod가 Pending 상태에있을 때마다 클러스터 자동 확장 처리가 pod 생성 후 30 초 이내에 다른 노드를 생성합니다 (합리적인 크기의 클러스터의 경우). .
그러나 노드가 꽤 압축 된 경우를 고려하십시오. 노드에 2 개의 CPU 코어가 있고 0.5 CPU 요청과 1.0 CPU 제한을 정의하는 4 개의 포드가 있다고 가정 해 보겠습니다. 갑자기 부하가 발생하고 4 개의 포드가 모두 4 개의 실행중인 포드가 이미 모든 CPU를 차지했기 때문에 노드가 제공 할 수없는 추가 0.5 CPU를 갑자기 요청합니다.
이 상황에서 Kubernetes는 제공 할 수없는 포드를 실행하여 보류중인 리소스 요청이 있음을 '이해'하고 해당 포드를 해당 요청을 존중할 수있는 다른 노드로 '이동'(파괴 및 생성)합니다. 현재 사용 중). 그러한 노드가없는 경우-Kubernetes가 추가 노드를 만들고 포드를 그곳으로 이동시킬 것으로 예상했습니다.
그러나 나는 이런 일이 일어나지 않는다. pod가 존중할 수없는 리소스 요청과 결과적으로 성능 저하에 관계없이 동일한 노드에서 실행되고 있음을 알 수 있습니다 (노드를 오버 프로비저닝이라고 할 수 있음).
내 질문은 포드 리소스 요청과 제한 간의 비율을 1 : 1로 설정하는 것 외에는이 동작을 피할 수 있는지 여부입니다 (포드가 초기 할당 된 것보다 더 많은 리소스를 요청할 수없는 경우). 분명히 저는 부족한 프로비저닝을 방지하고 필요한 것보다 더 많은 비용을 지불하기 위해 요청과 제한을 동일하게 설정하는 것을 피할 것입니다.
답변
여기서 requestPodSpec의 CPU와 프로세스가 사용하려는 CPU 양의 차이를 인식하는 것이 중요 합니다. Kubernetes 프로비저닝 및 클러스터 자동 확장은 전적으로 requestPodSpec을 기반으로합니다 . 실제 사용은 이러한 결정과 관련이 없습니다.
설명하는 경우 포드는 여전히 0.5 CPU 만 요청합니다. 해당 필드는 변경할 수 없습니다. 이 프로세스는 이제 CPU 1 개를 사용하려고합니다. 그러나 이것은 살펴 보지 않았습니다.
CPU 제한이 요청보다 높으면 해당 용량을 최대한 활용할 수 있지만 보시다시피 보장되지는 않습니다.
이 시나리오에서는 Horizontal Pod Autoscaler와 클러스터 자동 확장 처리를 모두 사용하는 것이 좋을 것 같습니다. 부하가 증가하는 상황 (예 : 포드가 CPU의 80 % 이상을 사용하기 시작하는 경우 request)에서 HPA는 수요를 처리하기 위해 서비스에 대한 포드 수를 늘립니다. 해당 포드에 설치할 수있는 위치가 없으면 클러스터 자동 확장 처리가 더 많은 노드를 프로비저닝합니다. 이러한 방식으로 Pod는 요청 값까지 계속 사용할 수 있으며, 더 많은 노드가 프로비저닝되기 시작하면 더 많은 노드가 프로비저닝되므로 미리 리소스를 과도하게 프로비저닝하지 않습니다.