...
이 Kubernetes 모범 사례 에피소드에서는 리소스 요청 및 제한을 사용하여 이러한 문제를 해결하는 방법을 살펴 보겠습니다.
요청 및 제한
요청 및 제한은 Kubernetes가 CPU 및 메모리와 같은 리소스를 제어하는 데 사용하는 메커니즘입니다. 요청은 컨테이너가 보장받는 것입니다. 컨테이너가 리소스를 요청하면 Kubernetes는 해당 리소스를 제공 할 수있는 노드에서만이를 예약합니다. 반면 제한은 컨테이너가 특정 값을 초과하지 않도록합니다. 컨테이너는 한도까지만 올라갈 수 있으며 제한됩니다.
...
컨테이너가 가질 수있는 요청과 제한을 제어하기 위해 컨테이너 수준과 네임 스페이스 수준에서 할당량을 설정할 수 있습니다. 네임 스페이스에 대해 자세히 알아 보려면 블로그 시리즈의 이전 기사 를 참조하십시오 !
이것이 어떻게 작동하는지 봅시다.
컨테이너 설정
리소스에는 CPU와 메모리의 두 가지 유형이 있습니다. Kubernetes 스케줄러는이를 사용하여 포드를 실행할 위치를 파악합니다.
...
Pod의 각 컨테이너는 자체 요청 및 제한을 설정할 수 있으며 모두 가산 적입니다. 따라서 위의 예에서 포드에는 총 500mCPU 요청과 128MiB 메모리, 총 1 CPU 및 256MiB 메모리 제한이 있습니다.
CPU
CPU 리소스는 밀리 코르 단위로 정의됩니다. 컨테이너를 실행하는 데 2 개의 전체 코어가 필요한 경우 "2000m"값을 입력합니다. 컨테이너에 ¼ 코어 만 필요한 경우 "250m"값을 입력합니다.
...
흥미로운 것은 CPU 제한에 관한 것입니다. CPU는 "압축 가능한"리소스로 간주됩니다. 앱이 CPU 제한에 도달하기 시작하면 Kubernetes가 컨테이너 조절을 시작합니다. 즉, CPU가 인위적으로 제한되어 앱 성능이 저하 될 수 있습니다! 그러나 종료되거나 제거되지는 않습니다. 활성 상태 확인 을 사용하여 성능이 영향을받지 않았는지 확인할 수 있습니다 .
Memory
메모리 리소스는 바이트 단위로 정의됩니다. 일반적으로 메모리에 메비 바이트 값 (기본적으로 메가 바이트와 동일)을 제공하지만 바이트에서 페타 바이트까지 무엇이든 제공 할 수 있습니다 .
...
CPU 리소스와 달리 메모리는 압축 할 수 없습니다. 메모리 사용량을 조절할 수있는 방법이 없기 때문에 컨테이너가 메모리 제한을 초과하면 종료됩니다. 팟 (Pod)이 Deployment , StatefulSet , DaemonSet 또는 다른 유형의 컨트롤러에서 관리되는 경우 컨트롤러가 교체를 시작합니다.
Nodes
노드에서 제공하는 리소스보다 큰 요청은 설정할 수 없다는 점을 기억하는 것이 중요합니다. 예를 들어 듀얼 코어 머신 클러스터가있는 경우 2.5 코어 요청이있는 포드는 예약되지 않습니다. 여기 에서 Kubernetes Engine VM의 총 리소스를 찾을 수 있습니다 .
네임 스페이스 설정
이상적인 세상에서 Kubernetes의 컨테이너 설정은 모든 것을 처리하기에 충분하지만 세상은 어둡고 끔찍한 곳입니다. 사람들은 리소스를 설정하는 것을 쉽게 잊거나 불량 팀이 요청과 제한을 매우 높게 설정하고 클러스터에서 공정한 점유율보다 더 많은 것을 차지할 수 있습니다.
이러한 시나리오를 방지하기 위해 네임 스페이스 수준에서 ResourceQuotas 및 LimitRanges를 설정할 수 있습니다.
ResourceQuotas
네임 스페이스를 만든 후 ResourceQuotas를 사용하여 잠글 수 있습니다. ResourceQuotas는 매우 강력하지만이를 사용하여 CPU 및 메모리 리소스 사용을 제한하는 방법을 살펴 보겠습니다.
...
| 구성 | 내용 |
|---|---|
| requests.cpu | 네임 스페이스의 모든 컨테이너에 대한 최대 결합 CPU 요청 (밀리 코르)입니다. 위의 예에서는 요청이 10m 인 컨테이너 50 개, 요청이 100m 인 컨테이너 5 개 또는 요청이 500m 인 컨테이너 하나를 가질 수 있습니다. 네임 스페이스에서 요청 된 총 CPU가 500m 미만인 한! |
| requests.memory | 네임 스페이스의 모든 컨테이너에 대해 결합 된 최대 메모리 요청입니다. 위의 예에서 2MiB 요청이있는 컨테이너 50 개, CPU 요청이 20MiB 인 컨테이너 5 개 또는 100MiB 요청이있는 단일 컨테이너를 가질 수 있습니다. 네임 스페이스에서 요청 된 총 메모리가 100MiB 미만인 한! |
| limits.cpu | 네임 스페이스의 모든 컨테이너에 대해 결합 된 최대 CPU 제한입니다. requests.cpu와 비슷하지만 제한이 있습니다. |
| limits.memory | 네임 스페이스의 모든 컨테이너에 대한 최대 결합 메모리 제한입니다. requests.memory와 비슷하지만 한계가 있습니다. 프로덕션 및 개발 네임 스페이스를 사용하는 경우 (팀 또는 서비스 당 네임 스페이스와 달리) 일반적인 패턴은 프로덕션 네임 스페이스에 할당량을 지정하지 않고 개발 네임 스페이스에 엄격한 할당량을 지정하는 것입니다. 이를 통해 트래픽이 급증하는 경우 프로덕션에서 필요한 모든 리소스를 사용할 수 있습니다. |
LimitRange
네임 스페이스에 LimitRange를 만들 수도 있습니다. 네임 스페이스 전체를 보는 Quota와 달리 LimitRange는 개별 컨테이너에 적용됩니다. 이렇게하면 사람들이 네임 스페이스 내부에 초소형 또는 초대형 컨테이너를 만드는 것을 방지 할 수 있습니다.
...
| Section | 내용 |
|---|---|
| Default | 기본 설정 한계 포드의 컨테이너를. limitRange에서 이러한 값을 설정하면 이러한 값을 명시 적으로 설정하지 않은 모든 컨테이너에 기본값이 할당됩니다. |
| defaultRequest | 기본 설정 요청 포드의 컨테이너를. limitRange에서 이러한 값을 설정하면 이러한 값을 명시 적으로 설정하지 않은 모든 컨테이너에 기본값이 할당됩니다. |
| max | 셋업 할 최대 한계 포드에서 컨테이너가 설정할 수 있습니다. 기본 섹션은이 값보다 클 수 없습니다. 마찬가지로 컨테이너에 설정된 제한은이 값보다 클 수 없습니다. 이 값이 설정되고 기본 섹션이 설정되지 않은 경우 이러한 값을 명시 적으로 설정하지 않은 컨테이너에는 최대 값이 제한으로 할당된다는 점에 유의해야합니다. |
| min | 위로 설정 최소 요청 포드 용기가 설정할 수있다. defaultRequest 섹션은이 값보다 낮을 수 없습니다. 마찬가지로 컨테이너에 설정된 요청도이 값보다 낮을 수 없습니다. 이 값이 설정되고 defaultRequest 섹션이 설정되지 않은 경우 min 값도 defaultRequest 값이됩니다. |
Kubernetes 포드의 수명주기
하루가 끝나면 이러한 리소스 요청은 Kubernetes 스케줄러에서 워크로드를 실행하는 데 사용됩니다. 컨테이너를 올바르게 튜닝하려면 이것이 어떻게 작동하는지 이해하는 것이 중요합니다.
...
매우 드문 시나리오에서 Kubernetes는 요청 내에있는 포드를 강제로 종료 할 수 있습니다. 이는 kubelet 또는 docker와 같은 중요한 시스템 구성 요소가 예약 된 것보다 더 많은 리소스를 사용하기 시작할 때 발생할 수 있습니다.
결론
리소스 요청 및 제한을 설정하지 않고도 Kubernetes 클러스터가 제대로 작동 할 수 있지만 팀과 프로젝트가 성장함에 따라 안정성 문제가 발생하기 시작합니다. Pod 및 네임 스페이스에 요청 및 제한을 추가하는 것은 약간의 추가 노력 만 필요하며, 많은 골칫거리에 빠지지 않도록 할 수 있습니다!