...

이 Kubernetes 모범 사례 에피소드에서는 리소스 요청 및 제한을 사용하여 이러한 문제를 해결하는 방법을 살펴 보겠습니다.

요청 및 제한

요청 및 제한은 Kubernetes가 CPU 및 메모리와 같은 리소스를 제어하는 ​​데 사용하는 메커니즘입니다. 요청은 컨테이너가 보장받는 것입니다. 컨테이너가 리소스를 요청하면 Kubernetes는 해당 리소스를 제공 할 수있는 노드에서만이를 예약합니다. 반면 제한은 컨테이너가 특정 값을 초과하지 않도록합니다. 컨테이너는 한도까지만 올라갈 수 있으며 제한됩니다.

...

컨테이너가 가질 수있는 요청과 제한을 제어하기 위해 컨테이너 수준과 네임 스페이스 수준에서 할당량을 설정할 수 있습니다. 네임 스페이스에 대해 자세히 알아 보려면 블로그 시리즈의 이전 기사 를 참조하십시오 !

이것이 어떻게 작동하는지 봅시다.

컨테이너 설정

리소스에는 CPU와 메모리의 두 가지 유형이 있습니다. Kubernetes 스케줄러는이를 사용하여 포드를 실행할 위치를 파악합니다.

...

Pod의 각 컨테이너는 자체 요청 및 제한을 설정할 수 있으며 모두 가산 적입니다. 따라서 위의 예에서 포드에는 총 500mCPU 요청과 128MiB 메모리, 총 1 CPU 및 256MiB 메모리 제한이 있습니다.

CPU

CPU 리소스는 밀리 코르 단위로 정의됩니다. 컨테이너를 실행하는 데 2 ​​개의 전체 코어가 필요한 경우 "2000m"값을 입력합니다. 컨테이너에 ¼ 코어 만 필요한 경우 "250m"값을 입력합니다.

...

앱이 다중 코어 (과학 컴퓨팅 및 일부 데이터베이스가 떠오르는 경우)를 활용하도록 특별히 설계되지 않은 경우 일반적으로 CPU 요청을 '1'이하로 유지하고 더 많은 복제본을 실행하여 확장하는 것이 좋습니다. 이것은 시스템에 더 많은 유연성과 신뢰성을 제공합니다.

흥미로운 것은 CPU 제한에 관한 것입니다. CPU는 "압축 가능한"리소스로 간주됩니다. 앱이 CPU 제한에 도달하기 시작하면 Kubernetes가 컨테이너 조절을 시작합니다. 즉, CPU가 인위적으로 제한되어 앱 성능이 저하 될 수 있습니다! 그러나 종료되거나 제거되지는 않습니다. 활성 상태 확인 을 사용하여 성능이 영향을받지 않았는지 확인할 수 있습니다 .

Memory

메모리 리소스는 바이트 단위로 정의됩니다. 일반적으로 메모리에 메비 바이트 값 (기본적으로 메가 바이트와 동일)을 제공하지만 바이트에서 페타 바이트까지 무엇이든 제공 할 수 있습니다 .

...

CPU 리소스와 달리 메모리는 압축 할 수 없습니다. 메모리 사용량을 조절할 수있는 방법이 없기 때문에 컨테이너가 메모리 제한을 초과하면 종료됩니다. 팟 (Pod)이 Deployment , StatefulSet , DaemonSet 또는 다른 유형의 컨트롤러에서 관리되는 경우 컨트롤러가 교체를 시작합니다.

Nodes

노드에서 제공하는 리소스보다 큰 요청은 설정할 수 없다는 점을 기억하는 것이 중요합니다. 예를 들어 듀얼 코어 머신 클러스터가있는 경우 2.5 코어 요청이있는 포드는 예약되지 않습니다. 여기 에서 Kubernetes Engine VM의 총 리소스를 찾을 수 있습니다 .

네임 스페이스 설정

이상적인 세상에서 Kubernetes의 컨테이너 설정은 모든 것을 처리하기에 충분하지만 세상은 어둡고 끔찍한 곳입니다. 사람들은 리소스를 설정하는 것을 쉽게 잊거나 불량 팀이 요청과 제한을 매우 높게 설정하고 클러스터에서 공정한 점유율보다 더 많은 것을 차지할 수 있습니다.

이러한 시나리오를 방지하기 위해 네임 스페이스 수준에서 ResourceQuotas 및 LimitRanges를 설정할 수 있습니다.

ResourceQuotas

네임 스페이스를 만든 후 ResourceQuotas를 사용하여 잠글 수 있습니다. ResourceQuotas는 매우 강력하지만이를 사용하여 CPU 및 메모리 리소스 사용을 제한하는 방법을 살펴 보겠습니다.

...

LimitRange

네임 스페이스에 LimitRange를 만들 수도 있습니다. 네임 스페이스 전체를 보는 Quota와 달리 LimitRange는 개별 컨테이너에 적용됩니다. 이렇게하면 사람들이 네임 스페이스 내부에 초소형 또는 초대형 컨테이너를 만드는 것을 방지 할 수 있습니다.

LimitRange는 다음과 같습니다.

이 예를 보면 네 개의 섹션이 있음을 알 수 있습니다. 다시 말하지만, 이러한 각 섹션을 설정하는 것은 선택 사항입니다.

Kubernetes 포드의 수명주기

하루가 끝나면 이러한 리소스 요청은 Kubernetes 스케줄러에서 워크로드를 실행하는 데 사용됩니다. 컨테이너를 올바르게 튜닝하려면 이것이 어떻게 작동하는지 이해하는 것이 중요합니다.

...

매우 드문 시나리오에서 Kubernetes는 요청 내에있는 포드를 강제로 종료 할 수 있습니다. 이는 kubelet 또는 docker와 같은 중요한 시스템 구성 요소가 예약 된 것보다 더 많은 리소스를 사용하기 시작할 때 발생할 수 있습니다.

결론

리소스 요청 및 제한을 설정하지 않고도 Kubernetes 클러스터가 제대로 작동 할 수 있지만 팀과 프로젝트가 성장함에 따라 안정성 문제가 발생하기 시작합니다. Pod 및 네임 스페이스에 요청 및 제한을 추가하는 것은 약간의 추가 노력 만 필요하며, 많은 골칫거리에 빠지지 않도록 할 수 있습니다!