Kubernetes 모범 사례. 리소스 요청 및 한도 설정

Kubernetes 모범 사례. 작은 컨테이너 만들기
Kubernetes 모범 사례. 네임스페이스가 있는 Kubernetes의 구성
Kubernetes 모범 사례. 준비 상태 및 활동성 테스트를 통해 Kubernetes 활동성 검증

각 Kubernetes 리소스에 대해 요청 및 제한이라는 두 가지 유형의 요구 사항을 구성할 수 있습니다. 첫 번째는 컨테이너 또는 포드를 실행하는 데 필요한 무료 노드 리소스의 가용성에 대한 최소 요구 사항을 설명하고, 두 번째는 컨테이너에 사용 가능한 리소스를 엄격하게 제한합니다.

Kubernetes가 포드를 예약할 때 컨테이너가 제대로 작동하는 데 충분한 리소스를 확보하는 것이 매우 중요합니다. 리소스가 제한된 노드에 대규모 애플리케이션을 배포하려는 경우 노드의 메모리가 부족하거나 CPU 성능이 부족하기 때문에 실행되지 않을 수 있습니다. 이 기사에서는 리소스 요청 및 제한을 사용하여 컴퓨팅 성능 부족을 해결하는 방법을 살펴보겠습니다.

요청 및 제한은 Kubernetes가 CPU 및 메모리와 같은 리소스를 관리하는 데 사용하는 메커니즘입니다. 요청은 컨테이너가 요청된 리소스를 수신하는지 확인하는 것입니다. 컨테이너가 리소스를 요청하면 Kubernetes는 이를 제공할 수 있는 노드에서만 이를 예약합니다. 컨테이너가 요청한 리소스가 특정 값을 초과하지 않도록 제어를 제한합니다.

컨테이너는 컴퓨팅 성능을 특정 한도까지만 늘릴 수 있으며, 그 이후에는 제한됩니다. 그것이 어떻게 작동하는지 봅시다. 따라서 리소스에는 프로세서와 메모리라는 두 가지 유형이 있습니다. Kubernetes 스케줄러는 이러한 리소스에 대한 데이터를 사용하여 Pod를 실행할 위치를 파악합니다. Pod의 일반적인 리소스 사양은 다음과 같습니다.

Pod의 각 컨테이너는 자체 쿼리와 제한을 설정할 수 있으며 모두 추가됩니다. 프로세서 리소스는 밀리코어 단위로 정의됩니다. 컨테이너를 실행하는 데 2000개의 전체 코어가 필요한 경우 값을 1m로 설정합니다. 컨테이너에 코어의 4/250 전력만 필요한 경우 값은 XNUMXm가 됩니다. 가장 큰 노드의 코어 수보다 큰 CPU 리소스 값을 할당하면 포드가 전혀 시작되도록 예약되지 않습니다. XNUMX개의 코어가 필요한 포드가 있고 Kubernetes 클러스터가 XNUMX개의 기본 가상 머신으로만 구성된 경우 비슷한 상황이 발생합니다.

응용 프로그램이 다중 코어(복잡한 과학 컴퓨팅 및 데이터베이스 작업과 같은 프로그램을 염두에 두는 등)를 활용하도록 특별히 설계되지 않은 경우 가장 좋은 방법은 CPU 요청을 1 이하로 설정한 다음 확장성을 위해 더 많은 복제본을 실행하는 것입니다. 이 솔루션은 시스템에 더 큰 유연성과 신뢰성을 제공합니다.

CPU 제한과 관련하여 압축 가능한 리소스로 간주되므로 상황이 더욱 흥미로워집니다. 애플리케이션이 프로세서 전력 제한에 접근하기 시작하면 Kubernetes는 CPU 조절을 사용하여 컨테이너 속도를 늦추기 시작하여 프로세서 주파수를 줄입니다. 이는 CPU가 인위적으로 조절되어 애플리케이션의 성능이 저하될 수 있지만 프로세스가 종료되거나 제거되지는 않음을 의미합니다.

메모리 리소스는 바이트 단위로 정의됩니다. 일반적으로 설정 값은 메비바이트 Mib 단위로 측정되지만 바이트에서 페타바이트까지 어떤 값이든 설정할 수 있습니다. CPU와 동일한 상황이 여기에 적용됩니다. 노드의 메모리 양보다 더 많은 메모리 양을 요청하면 해당 포드는 실행되도록 예약되지 않습니다. 하지만 CPU 리소스와 달리 메모리는 사용을 제한할 방법이 없기 때문에 압축되지 않습니다. 따라서 할당된 메모리를 초과하는 즉시 컨테이너 실행이 중지됩니다.

노드가 제공할 수 있는 리소스를 초과하는 요청은 구성할 수 없다는 점을 기억하는 것이 중요합니다. GKE 가상 머신의 공유 리소스 사양은 이 동영상 아래 링크에서 확인할 수 있습니다.

이상적인 상황에서는 컨테이너의 기본 설정만으로도 워크플로를 원활하게 실행하는 데 충분합니다. 그러나 현실 세계는 그렇지 않습니다. 사람들은 리소스 사용 구성을 쉽게 잊어버리거나 해커가 인프라의 실제 기능을 초과하는 요청과 제한을 설정합니다. 이러한 시나리오가 발생하지 않도록 하려면 ResourceQuota 및 LimitRange 리소스 할당량을 구성할 수 있습니다.

네임스페이스가 생성되면 할당량을 사용하여 차단할 수 있습니다. 예를 들어, prod 및 dev 네임스페이스가 있는 경우 프로덕션 할당량이 전혀 없고 매우 엄격한 개발 할당량이 패턴으로 나타납니다. 이를 통해 트래픽이 급증하는 경우 prod가 사용 가능한 전체 리소스를 차지하여 dev를 완전히 차단할 수 있습니다.

리소스 할당량은 다음과 같습니다. 이 예에는 4개의 섹션이 있습니다. 이는 코드의 맨 아래 4줄입니다.

각각을 살펴보겠습니다. Requests.cpu는 네임스페이스의 모든 컨테이너에서 올 수 있는 결합된 CPU 요청의 최대 수입니다. 이 예에서는 50m 요청이 있는 10개의 컨테이너, 100m 요청이 있는 500개의 컨테이너 또는 500m 요청이 있는 XNUMX개의 컨테이너가 있을 수 있습니다. 특정 네임스페이스의 총 request.cpu 수가 XNUMXm 미만이면 모든 것이 정상입니다.

메모리 요청 요청.memory는 네임스페이스의 모든 컨테이너가 가질 수 있는 결합된 메모리 요청의 최대량입니다. 이전 사례와 마찬가지로 네임스페이스에서 요청된 총 메모리 양이 50메비바이트 미만인 경우 2개의 20 mib 컨테이너, 100개의 100 mib 컨테이너 또는 단일 XNUMX mib 컨테이너를 가질 수 있습니다.

Limits.cpu는 네임스페이스의 모든 컨테이너가 사용할 수 있는 CPU 성능의 최대 결합량입니다. 우리는 이것이 프로세서 전력 요청의 한계라고 생각할 수 있습니다.

마지막으로limits.memory는 네임스페이스의 모든 컨테이너가 사용할 수 있는 최대 공유 메모리 양입니다. 이는 총 메모리 요청에 대한 제한입니다.
따라서 기본적으로 Kubernetes 클러스터의 컨테이너는 무제한 컴퓨팅 리소스로 실행됩니다. 리소스 할당량을 사용하면 클러스터 관리자는 네임스페이스를 기반으로 리소스 소비 및 리소스 생성을 제한할 수 있습니다. 네임스페이스에서 Pod 또는 컨테이너는 네임스페이스 리소스 할당량에 따라 결정된 만큼의 CPU 성능과 메모리를 소비할 수 있습니다. 하지만 하나의 Pod나 컨테이너가 사용 가능한 모든 리소스를 독점할 수 있다는 우려가 있습니다. 이러한 상황을 방지하기 위해 제한 범위, 즉 네임스페이스에서 리소스(포드 또는 컨테이너용) 할당을 제한하는 정책이 사용됩니다.

제한 범위는 다음과 같은 제한 사항을 제공합니다.

• 네임스페이스의 각 모듈 또는 컨테이너에 대한 컴퓨팅 리소스의 최소 및 최대 사용량을 보장합니다.
• 네임스페이스의 각 PertantVolumeClaim에 대해 최소 및 최대 Starage Request 스토리지 요청을 적용합니다.
• 네임스페이스의 리소스에 대한 요청과 제한 간의 관계를 적용합니다.
• 네임스페이스의 컴퓨팅 리소스에 대한 기본 요청/제한을 설정하고 런타임 시 자동으로 컨테이너에 삽입합니다.

이 방법으로 네임스페이스에 제한 범위를 만들 수 있습니다. 전체 네임스페이스에 적용되는 할당량과 달리 제한 범위는 개별 컨테이너에 사용됩니다. 이는 사용자가 네임스페이스 내에서 매우 작거나 반대로 거대한 컨테이너를 만드는 것을 방지할 수 있습니다. 한계 범위는 다음과 같습니다.

이전 사례와 마찬가지로 여기서도 4개의 섹션을 구분할 수 있습니다. 각각을 살펴보겠습니다.
기본 섹션은 포드의 컨테이너에 대한 기본 제한을 설정합니다. 이러한 값을 극단적인 범위로 설정하면 해당 값이 명시적으로 설정되지 않은 모든 컨테이너는 기본값을 따릅니다.

기본 요청 섹션 defaultRequest는 포드의 컨테이너에 대한 기본 요청을 구성합니다. 다시 말하지만, 이러한 값을 극단적인 범위로 설정하면 이러한 옵션을 명시적으로 설정하지 않은 모든 컨테이너는 기본적으로 이러한 값을 사용하게 됩니다.

max 섹션은 포드의 컨테이너에 대해 설정할 수 있는 최대 제한을 지정합니다. 기본 섹션 및 컨테이너 제한의 값은 이 제한 이상으로 설정할 수 없습니다. 값이 max로 설정되고 기본 섹션이 없으면 최대값이 기본값이 된다는 점에 유의하는 것이 중요합니다.

min 섹션은 포드의 컨테이너에 대해 설정할 수 있는 최소 요청을 지정합니다. 단, 컨테이너에 대한 기본 섹션 및 쿼리의 값은 이 한도 이하로 설정할 수 없습니다.

다시 말하지만, 이 값이 설정되면 기본값은 설정되지 않으며 최소값이 기본 프롬프트가 된다는 점에 유의하는 것이 중요합니다.

이러한 리소스 요청은 궁극적으로 Kubernetes 스케줄러에서 워크로드를 실행하는 데 사용됩니다. 컨테이너를 올바르게 구성하려면 컨테이너 작동 방식을 이해하는 것이 매우 중요합니다. 클러스터에서 여러 포드를 실행한다고 가정해 보겠습니다. 포드 사양이 유효하다고 가정하면 Kubernetes 일정은 라운드 로빈 밸런싱을 사용하여 워크로드를 실행할 노드를 선택합니다.

Kubernetes는 노드 1에 포드 컨테이너의 요청을 이행하기에 충분한 리소스가 있는지 확인하고, 그렇지 않은 경우 다음 노드로 이동합니다. 시스템의 어떤 노드도 요청을 충족할 수 없는 경우 포드는 보류 중 상태로 전환됩니다. GKE는 노드 자동 확장과 같은 Google Kubernetes 엔진 기능을 사용하여 대기 상태를 자동으로 감지하고 몇 개의 추가 노드를 더 만들 수 있습니다.

나중에 노드 용량이 부족해지면 자동 확장을 통해 노드 수가 줄어들어 비용이 절약됩니다. 이것이 Kubernetes가 요청에 따라 Pod를 예약하는 이유입니다. 그러나 한도는 요청보다 높을 수 있으며 경우에 따라 노드에 실제로 리소스가 부족할 수도 있습니다. 우리는 이 상태를 과잉 커밋 상태라고 부릅니다.

앞서 말했듯이 CPU와 관련하여 Kubernetes는 포드를 제한하기 시작합니다. 각 포드는 요청한 만큼 수신하지만, 제한에 도달하지 않으면 제한이 적용되기 시작합니다.

메모리 리소스와 관련하여 Kubernetes는 시스템 리소스를 확보하거나 전체 시스템이 충돌할 때까지 삭제할 포드와 유지할 포드를 결정해야 합니다.

머신의 메모리가 부족한 시나리오를 상상해 봅시다. Kubernetes는 이를 어떻게 처리할까요?

Kubernetes는 요청한 것보다 더 많은 리소스를 사용하는 포드를 찾습니다. 따라서 컨테이너에 요청이 전혀 없다면 이는 아무것도 요청하지 않았기 때문에 요청한 것보다 더 많은 것을 기본적으로 사용한다는 의미입니다! 이러한 컨테이너는 폐쇄의 주요 후보가 됩니다. 다음 후보는 모든 요청을 충족했지만 여전히 최대 한도 미만인 컨테이너입니다.

따라서 Kubernetes가 요청 매개변수를 초과한 여러 Pod를 발견하면 우선순위별로 정렬한 다음 우선순위가 가장 낮은 Pod를 제거합니다. 모든 포드의 우선순위가 동일한 경우 Kubernetes는 다른 포드보다 요청을 초과하는 포드를 종료합니다.

매우 드문 경우지만 Kubernetes는 여전히 요청 범위 내에 있는 Pod를 중단할 수 있습니다. 이는 Kubelet 에이전트 또는 Docker와 같은 중요한 시스템 구성 요소가 예약된 것보다 더 많은 리소스를 소비하기 시작할 때 발생할 수 있습니다.
따라서 소규모 회사의 초기 단계에서는 Kubernetes 클러스터가 리소스 요청 및 제한을 설정하지 않고도 잘 작동할 수 있지만 팀과 프로젝트의 규모가 커지기 시작하면 이 영역에서 문제가 발생할 위험이 있습니다. 모듈과 네임스페이스에 쿼리와 제약 조건을 추가하면 추가 노력이 거의 필요하지 않으며 많은 번거로움을 줄일 수 있습니다.

Kubernetes 모범 사례. 올바른 종료 종료

일부 광고 🙂

우리와 함께있어 주셔서 감사합니다. 우리 기사가 마음에 드십니까? 더 재미있는 콘텐츠를 보고 싶다면? 주문하거나 친구에게 추천하여 우리를 지원하십시오. $4.99부터 시작하는 개발자용 클라우드 VPS, 귀하를 위해 우리가 발명한 고유한 보급형 서버 아날로그: VPS(KVM) E5-2697 v3(6코어) 10GB DDR4 480GB SSD 1Gbps에 대한 전체 진실 또는 서버 공유 방법은? (RAID1 및 RAID10에서 사용 가능, 최대 24개 코어 및 최대 40GB DDR4).

Dell R730xd는 암스테르담의 Equinix Tier IV 데이터 센터에서 2배 더 저렴합니까? 여기서 만 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199부터 네덜란드에서! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 최저 $99! 에 대해 읽다 인프라 공사를 구축하는 방법. 730페니에 5유로 상당의 Dell R2650xd E4-9000 vXNUMX 서버를 사용하는 클래스?

출처 : habr.com