Kubernetes의 자동 크기 조정 및 리소스 관리(개요 및 동영상 보고서)

27월 XNUMX일 컨퍼런스에서 파업 2019, "DevOps" 섹션의 일부로 "Kubernetes의 자동 확장 및 리소스 관리" 보고서가 제공되었습니다. K8을 사용하여 애플리케이션의 고가용성을 보장하고 최고의 성능을 보장하는 방법에 대해 설명합니다.

전통에 따라 우리는 이를 기쁘게 생각합니다. 보고서 영상 (44분, 기사보다 훨씬 더 유익함) 및 텍스트 형식의 주요 요약입니다. 가다!

보고서의 주제를 한 단어씩 분석하고 끝부터 시작하겠습니다.

Kubernetes

호스트에 Docker 컨테이너가 있다고 가정해 보겠습니다. 무엇을 위해? 반복성과 격리를 보장하여 간단하고 우수한 배포를 가능하게 하는 CI/CD입니다. 우리는 컨테이너를 갖춘 차량을 많이 보유하고 있습니다.

이 경우 Kubernetes는 무엇을 제공합니까?

1. 우리는 이러한 기계에 대한 생각을 멈추고 "클라우드"를 사용하여 작업을 시작합니다. 컨테이너 클러스터 또는 포드(컨테이너 그룹).
2. 게다가 개별 포드까지 생각하지 않고 더 많은 것을 관리합니다.о더 큰 그룹. 그런 높은 수준의 프리미티브 특정 워크로드를 실행하기 위한 템플릿이 있고 이를 실행하는 데 필요한 인스턴스 수는 다음과 같습니다. 나중에 템플릿을 변경하면 모든 인스턴스가 변경됩니다.
3. 과 선언적 API 일련의 특정 명령을 실행하는 대신 Kubernetes가 생성하는 "세계의 구조"(YAML)를 설명합니다. 그리고 다시 말하지만, 설명이 변경되면 실제 표시도 변경됩니다.

자원 관리

CPU

서버에서 nginx, php-fpm 및 mysql을 실행해 보겠습니다. 이러한 서비스에는 실제로 더 많은 프로세스가 실행되며 각 프로세스에는 컴퓨팅 리소스가 필요합니다.

(슬라이드의 숫자는 컴퓨팅 능력에 대한 각 프로세스의 추상적인 필요성인 "앵무새"입니다)

이 작업을 더 쉽게 하려면 프로세스를 그룹으로 결합하는 것이 논리적입니다(예: 모든 nginx 프로세스를 하나의 그룹 "nginx"로). 이를 수행하는 간단하고 확실한 방법은 각 그룹을 컨테이너에 넣는 것입니다.

계속하려면 (Linux에서) 컨테이너가 무엇인지 기억해야 합니다. 꽤 오래 전에 구현된 커널의 세 가지 주요 기능 덕분에 이러한 모습이 가능해졌습니다. 기능, 네임 스페이스 и cgroup. 그리고 다른 기술(Docker와 같은 편리한 "셸" 포함)을 통해 추가 개발이 촉진되었습니다.

보고서의 맥락에서 우리는 다음에만 관심이 있습니다. cgroup, 제어 그룹은 리소스 관리를 구현하는 컨테이너(Docker 등) 기능의 일부이기 때문입니다. 우리가 원하는 대로 그룹으로 결합된 프로세스가 제어 그룹입니다.

이러한 프로세스와 프로세스 그룹에 대한 CPU 요구 사항으로 돌아가 보겠습니다.

(모든 숫자는 자원 필요성을 추상적으로 표현한 것임을 반복합니다)

동시에 CPU 자체에는 특정 유한 리소스가 있습니다. (예에서는 1000입니다), 이는 모든 사람에게 부족할 수 있습니다(모든 그룹의 요구 사항의 합은 150+850+460=1460입니다). 이 경우 어떻게 될까요?

커널은 리소스 배포를 시작하고 "공정하게" 이를 수행하여 각 그룹에 동일한 양의 리소스를 제공합니다. 그러나 첫 번째 경우에는 필요한 것보다 더 많으므로(333>150) 초과분(333-150=183)은 예비로 남아 있으며 이는 다른 두 컨테이너 간에 균등하게 분배됩니다.

결과적으로 첫 번째 컨테이너에는 리소스가 충분했고, 두 번째 컨테이너에는 리소스가 충분하지 않았으며, 세 번째 컨테이너에는 리소스가 충분하지 않았습니다. 이것이 행동의 결과이다 Linux의 "정직한" 스케줄러 - CFS. 할당을 사용하여 작동을 조정할 수 있습니다. 무게 각 컨테이너. 예를 들어 다음과 같습니다.

두 번째 컨테이너(php-fpm)의 리소스가 부족한 경우를 살펴보겠습니다. 모든 컨테이너 리소스는 프로세스 간에 균등하게 배포됩니다. 결과적으로 마스터 프로세스는 잘 작동하지만 모든 작업자는 속도가 느려지고 필요한 것의 절반도 받지 못합니다.

이것이 CFS 스케줄러가 작동하는 방식입니다. 컨테이너에 할당하는 가중치를 추가로 호출하겠습니다. 요청. 그 이유는 다음과 같습니다.

반대편에서 전체 상황을 살펴 보겠습니다. 아시다시피 모든 길은 로마로 통하고, 컴퓨터의 경우에는 CPU로 통합니다. 하나의 CPU, 많은 작업 - 신호등이 필요합니다. 리소스를 관리하는 가장 간단한 방법은 "트래픽 라이트"입니다. 즉, 한 프로세스에 CPU에 대한 고정 액세스 시간을 부여한 후 다음 프로세스에 액세스하는 등의 방식을 제공합니다.

이 접근 방식을 하드 할당량이라고 합니다. (하드 제한). 간단하게 기억해두자 제한. 그러나 모든 컨테이너에 제한을 분배하면 문제가 발생합니다. mysql이 도로를 따라 운전하고 어느 시점에서 CPU에 대한 요구가 종료되었지만 다른 모든 프로세스는 CPU가 완료될 때까지 기다려야 합니다. 게으른.

Linux 커널과 CPU와의 상호 작용으로 돌아가 보겠습니다. 전체 그림은 다음과 같습니다.

cgroup에는 두 가지 설정이 있습니다. 기본적으로 이는 다음을 결정할 수 있는 두 가지 간단한 "비틀기"입니다.

1. 컨테이너 중량(요청)은 다음과 같습니다. 주식;
2. 컨테이너 작업(한도) 작업에 소요되는 총 CPU 시간의 비율은 다음과 같습니다. 할당량.

CPU를 측정하는 방법은 무엇입니까?

다양한 방법이 있습니다:

1. 무엇인가 앵무새, 아무도 모릅니다. 매번 협상해야합니다.
2. 이자 더 명확하지만 상대적입니다. 50개 코어가 있는 서버와 4개 코어가 있는 서버의 20%는 완전히 다릅니다.
3. 이미 언급한 것을 사용할 수 있습니다. 무게, Linux가 알고 있지만 상대적이기도 합니다.
4. 가장 적절한 옵션은 컴퓨팅 리소스를 측정하는 것입니다. 초. 저것들. 실제 시간(초)에 대한 프로세서 시간(초): 실제 1초당 1초의 프로세서 시간이 제공되었습니다. 이는 하나의 전체 CPU 코어입니다.

말하기를 더욱 쉽게 하기 위해 그들은 직접 측정하기 시작했습니다. 커널, 이는 실제 CPU 시간과 동일한 CPU 시간을 의미합니다. Linux는 가중치를 이해하지만 CPU 시간/코어는 그리 많지 않기 때문에 하나에서 다른 것으로 변환하는 메커니즘이 필요했습니다.

3개의 CPU 코어가 있는 서버의 간단한 예를 고려해 보겠습니다. 여기서 500개의 포드에는 할당된 코어의 해당 부분(1000, 1500 및 0,5)으로 쉽게 변환되는 가중치(1, 1,5 및 XNUMX)가 지정됩니다.

두 배의 코어(6개)가 있는 두 번째 서버를 가져와 동일한 포드를 거기에 배치하는 경우 간단히 2(각각 1, 2, 3)를 곱하여 코어 분포를 쉽게 계산할 수 있습니다. 그러나 편의상 무게가 3000이 되는 네 번째 포드가 이 서버에 나타날 때 중요한 순간이 발생합니다. 이는 CPU 리소스의 일부(코어의 절반)를 가져가고 나머지 포드에 대해서는 다시 계산됩니다(절반).

Kubernetes 및 CPU 리소스

Kubernetes에서 CPU 리소스는 일반적으로 다음과 같이 측정됩니다. 밀리아드락스, 즉. 0,001 코어가 기본 중량으로 사용됩니다. (Linux/cgroups 용어에서는 동일한 것을 CPU 공유라고 합니다. 더 정확하게는 1000밀리코어 = 1024 CPU 공유입니다.) K8s는 모든 포드의 가중치 합계에 대한 CPU 리소스보다 더 많은 포드를 서버에 배치하지 않도록 보장합니다.

어떻게 이런 일이 발생하나요? Kubernetes 클러스터에 서버를 추가하면 사용 가능한 CPU 코어 수가 보고됩니다. 그리고 새 포드를 생성할 때 Kubernetes 스케줄러는 이 포드에 필요한 코어 수를 알고 있습니다. 따라서 포드는 코어가 충분한 서버에 할당됩니다.

다음과 같은 경우 어떻게 될까요? 아니 요청이 지정되었습니까(즉, 포드에 필요한 코어 수가 정의되어 있지 않음)? Kubernetes가 일반적으로 리소스를 계산하는 방법을 알아 보겠습니다.

Pod의 경우 요청(CFS 스케줄러)과 제한(신호등을 기억하시나요?)을 모두 지정할 수 있습니다.

• 동일하게 지정되면 포드에 QoS 클래스가 할당됩니다. 보장. 항상 사용 가능한 코어 수가 보장됩니다.
• 요청이 한도 미만인 경우 - QoS 클래스 파열 가능. 저것들. 예를 들어 포드는 항상 1개의 코어를 사용할 것으로 예상하지만 이 값은 이에 대한 제한이 아닙니다. 때로는 Pod는 더 많은 것을 사용할 수 있습니다(서버에 이를 위한 여유 리소스가 있는 경우).
• QoS 클래스도 있습니다 최선의 노력 — 요청이 지정되지 않은 바로 그 포드를 포함합니다. 자원은 마지막에 그들에게 주어집니다.

기억

메모리의 경우 상황은 비슷하지만 약간 다릅니다. 결국 이러한 리소스의 성격은 다릅니다. 일반적으로 비유는 다음과 같습니다.

요청이 메모리에서 어떻게 구현되는지 살펴보겠습니다. Pod 중 하나가 너무 커져서 메모리가 부족해질 때까지 메모리 소비를 변경하면서 Pod를 서버에 유지하세요. 이 경우 OOM 킬러가 나타나 가장 큰 프로세스를 종료합니다.

이것이 항상 우리에게 적합한 것은 아니므로 어떤 프로세스가 우리에게 중요하고 종료되어서는 안 되는지 규제하는 것이 가능합니다. 이렇게 하려면 매개변수를 사용하십시오. oom_score_adj.

CPU의 QoS 클래스로 돌아가서 포드의 메모리 소비 우선순위를 결정하는 oom_score_adj 값으로 ​​비유해 보겠습니다.

• Pod의 가장 낮은 oom_score_adj 값(-998)은 해당 Pod가 마지막에 종료되어야 함을 의미합니다. 보장.
• 가장 높은 1000은 다음과 같습니다. 최선의 노력, 그러한 포드는 먼저 종료됩니다.
• 나머지 값을 계산하려면 ​​(파열 가능) 공식이 있는데, 그 핵심은 포드가 더 많은 리소스를 요청할수록 포드가 종료될 가능성이 낮아진다는 사실로 귀결됩니다.

두 번째 "비틀림" - limit_in_bytes - 한계를 위해. 이를 사용하면 모든 것이 더 간단해집니다. 발행된 메모리의 최대 양을 할당하기만 하면 되며 여기에서는 (CPU와 달리) 메모리를 측정하는 방법에 대한 의문이 없습니다.

전체로

Kubernetes의 각 포드에는 requests и limits - CPU 및 메모리에 대한 매개변수:

1. 요청에 따라 Kubernetes 스케줄러가 작동하여 서버 간에 포드를 배포합니다.
2. 모든 매개변수를 기반으로 포드의 QoS 클래스가 결정됩니다.
3. 상대 가중치는 CPU 요청을 기준으로 계산됩니다.
4. CFS 스케줄러는 CPU 요청을 기반으로 구성됩니다.
5. OOM 킬러는 메모리 요청을 기반으로 구성됩니다.
6. "신호등"은 CPU 제한에 따라 구성됩니다.
7. 메모리 제한에 따라 cgroup에 대한 제한이 구성됩니다.

일반적으로 이 그림은 Kubernetes에서 리소스 관리의 주요 부분이 어떻게 발생하는지에 대한 모든 질문에 답합니다.

자동 확장

K8s 클러스터 자동 크기 조정기

전체 클러스터가 이미 사용 중이고 새 포드를 생성해야 한다고 가정해 보겠습니다. Pod가 나타날 수 없지만 상태가 멈춥니다. 대기중. 이를 표시하려면 새 서버를 클러스터에 연결하거나... Cluster-autoscaler를 설치하면 됩니다. 그러면 이 작업이 자동으로 수행됩니다. 클라우드 공급자에게 API 요청을 사용하여 가상 머신을 주문하고 클러스터에 연결합니다. , 그 후에 포드가 추가됩니다.

이는 Kubernetes 클러스터의 자동 크기 조정이며 (우리 경험에 따르면) 훌륭하게 작동합니다. 그러나 다른 곳과 마찬가지로 여기에도 약간의 뉘앙스가 있습니다.

클러스터 크기를 늘리는 한 모든 것이 괜찮았지만 클러스터가 커지면 어떻게 될까요? 자신을 자유롭게 하기 시작했다? 문제는 호스트를 확보하기 위해 포드를 마이그레이션하는 것이 기술적으로 매우 어렵고 리소스 측면에서 비용이 많이 든다는 것입니다. Kubernetes는 완전히 다른 접근 방식을 사용합니다.

배포 기능이 있는 3개의 서버로 구성된 클러스터를 생각해 보세요. 6개의 포드가 있습니다. 이제 각 서버마다 2개가 있습니다. 어떤 이유로 우리는 서버 중 하나를 끄고 싶었습니다. 이를 위해 우리는 명령을 사용합니다 kubectl drain, 어느:

• 이 서버에 새 포드를 보내는 것이 금지됩니다.
• 서버의 기존 포드를 삭제합니다.

Kubernetes는 Pod 수(6)를 유지하는 역할을 담당하므로 간단히 재현할 것이다 다른 노드에는 있지만 비활성화된 노드에는 없습니다. 이미 새 포드를 호스팅할 수 없는 것으로 표시되어 있기 때문입니다. 이는 Kubernetes의 기본 메커니즘입니다.

그러나 여기에도 뉘앙스가 있습니다. 비슷한 상황에서 (배포 대신) StatefulSet의 경우 작업이 달라집니다. 이제 우리는 이미 상태 저장 애플리케이션을 보유하고 있습니다. 예를 들어 MongoDB가 포함된 XNUMX개의 포드가 있는데 그 중 하나에는 일종의 문제가 있습니다(데이터가 손상되었거나 포드가 올바르게 시작되지 못하게 하는 또 다른 오류). 그리고 우리는 다시 하나의 서버를 비활성화하기로 결정했습니다. 무슨 일이 일어날 것?

MongoDB의 할 수 있었다 쿼럼이 필요하기 때문에 죽습니다. 세 개의 설치로 구성된 클러스터의 경우 최소한 두 개가 작동해야 합니다. 그러나 이 일어나지 않는 - 덕분에 PodDisruptionBudget. 이 매개변수는 필요한 최소 작업 포드 수를 결정합니다. MongoDB Pod 중 하나가 더 이상 작동하지 않는다는 것을 알고 PodDisruptionBudget이 MongoDB에 대해 설정되어 있음을 확인합니다. minAvailable: 2, Kubernetes에서는 포드 삭제를 허용하지 않습니다.

요점: 클러스터가 릴리스될 때 포드의 이동(실제로 재생성)이 올바르게 작동하려면 PodDisruptionBudget을 구성해야 합니다.

수평적 확장

또 다른 상황을 고려해 봅시다. Kubernetes에 배포로 실행되는 애플리케이션이 있습니다. 사용자 트래픽은 포드(예: 포드가 XNUMX개 있음)로 들어오고 포드에서 특정 지표(예: CPU 로드)를 측정합니다. 부하가 증가하면 일정에 따라 기록하고 Pod 수를 늘려 요청을 분산시킵니다.

현재 Kubernetes에서는 이 작업을 수동으로 수행할 필요가 없습니다. 측정된 로드 표시기의 값에 따라 포드 수의 자동 증가/감소가 구성됩니다.

여기서 주요 질문은 다음과 같습니다. 정확히 무엇을 측정해야 하는가 и 해석하는 방법 얻은 값 (포드 수 변경 결정) 많은 것을 측정할 수 있습니다:

이를 기술적으로 수행하는 방법 - 측정항목 수집 등 — 나는 보고서에서 자세히 이야기했습니다. 모니터링 및 Kubernetes. 최적의 매개변수를 선택하기 위한 주요 조언은 다음과 같습니다. 실험!

이 사용방법 (활용도 포화 및 오류), 그 의미는 다음과 같다. 예를 들어 php-fpm과 같이 어떤 기준으로 확장하는 것이 합리적입니까? 근로자가 부족하다는 사실을 바탕으로, 이용. 작업자가 종료되고 새 연결이 허용되지 않으면 이는 이미 완료되었습니다. 채도. 이 두 가지 매개변수를 모두 측정해야 하며, 값에 따라 스케일링을 수행해야 합니다.

대신 결론

보고서에는 수직적 확장과 올바른 리소스를 선택하는 방법에 대한 내용이 계속됩니다. 이에 대해서는 향후 동영상에서 다루겠습니다. 우리 유튜브 - 놓치지 않으려면 구독하세요!

비디오 및 슬라이드

공연 영상(44분):

보고서 발표:

PS

블로그의 Kubernetes에 대한 기타 보고서:

• «Kubernetes 확장 및 보완» (Andrey Polovov; 8년 2019월 XNUMX일 Saint HighLoad++);
• «데이터베이스와 Kubernetes» (Dmitry Stolyarov; HighLoad++에서 8년 2018월 XNUMX일);
• «모니터링 및 Kubernetes» (Dmitry Stolyarov; 28년 2018월 XNUMX일 RootConf에서);
• «Kubernetes 및 GitLab을 사용한 CI/CD 모범 사례» (Dmitry Stolyarov; HighLoad++에서 7년 2017월 XNUMX일);
• «소규모 프로젝트에서의 Kubernetes 경험» (Dmitry Stolyarov; 6년 2017월 XNUMX일 RootConf에서).

출처 : habr.com