Kubernetes의 세 가지 자동 크기 조정 수준: 이를 효과적으로 사용하는 방법

Kubernetes를 완벽하게 마스터하려면 클러스터 리소스를 확장하는 다양한 방법을 알아야 합니다. 시스템 개발자에 따르면, 이는 Kubernetes의 주요 작업 중 하나입니다. 수평 및 수직 자동 확장과 클러스터 크기 조정 메커니즘에 대한 높은 수준의 개요와 이를 효과적으로 사용하는 방법에 대한 권장 사항을 제공했습니다.

조 Kubernetes Autoscaling 101: 클러스터 자동 크기 조정기, 수평 자동 크기 조정기 및 수직형 포드 자동 크기 조정기 자동 확장을 구현한 팀이 번역함 Mail.ru의 Kubernetes aaS.

스케일링에 대해 생각하는 것이 중요한 이유

Kubernetes - 리소스 관리 및 조정을 위한 도구입니다. 물론 포드(Pod) 배포, 모니터링, 관리의 멋진 기능을 살펴보는 것도 좋습니다. 포드(Pod)는 요청에 대한 응답으로 실행되는 컨테이너 그룹입니다.

그러나 다음 질문도 생각해 보아야 합니다.

1. 모듈과 애플리케이션을 확장하는 방법은 무엇입니까?
2. 컨테이너의 운영 및 효율성을 유지하는 방법은 무엇입니까?
3. 사용자의 코드 및 워크로드의 지속적인 변화에 대응하는 방법은 무엇입니까?

리소스와 성능의 균형을 맞추도록 Kubernetes 클러스터를 구성하는 것은 어려울 수 있으며 Kubernetes의 내부 작동에 대한 전문 지식이 필요합니다. 애플리케이션이나 서비스의 워크로드는 하루 종일 또는 심지어 한 시간 동안 변동될 수 있으므로 균형 조정은 지속적인 프로세스로 생각하는 것이 가장 좋습니다.

Kubernetes 자동 확장 수준

효과적인 자동 확장을 위해서는 두 가지 수준 간의 조정이 필요합니다.

1. 수평(Horizontal Pod Autoscaler, HPA) 및 수직 자동 크기 조정기(Vertical Pod Autoscaler, VPA)를 포함한 Pod 수준입니다. 이는 컨테이너에 사용 가능한 리소스를 확장하는 것입니다.
2. CA(Cluster Autoscaler)에 의해 관리되는 클러스터 수준. 클러스터 내의 노드 수를 늘리거나 줄입니다.

HPA(수평 자동 크기 조정기) 모듈

이름에서 알 수 있듯이 HPA는 포드 복제본 수를 확장합니다. 대부분의 DevOps는 복제본 수를 변경하기 위한 트리거로 CPU 및 메모리 로드를 사용합니다. 그러나 시스템을 기반으로 확장하는 것은 가능합니다. 맞춤 측정항목, 그들 결합 또는 외부 지표.

높은 수준의 HPA 운영 다이어그램:

1. HPA는 기본 간격인 30초마다 설치 중에 지정된 메트릭 값을 지속적으로 확인합니다.
2. HPA는 지정된 임계값에 도달하면 모듈 수를 늘리려고 시도합니다.
3. HPA는 배포/복제 컨트롤러 내의 복제본 수를 업데이트합니다.
4. 그런 다음 배포/복제 컨트롤러는 필요한 추가 모듈을 배포합니다.

HPA는 측정항목 임계값에 도달하면 모듈 배포 프로세스를 시작합니다.

HPA를 사용할 때는 다음 사항을 고려하세요.

• 기본 HPA 확인 간격은 30초입니다. 깃발로 정해져있어요 수평-포드-자동 크기 조정기-동기화 기간 컨트롤러 관리자에서.
• 기본 상대 오차는 10%입니다.
• 모듈 수가 마지막으로 증가한 후 HPA는 측정항목이 XNUMX분 이내에 안정화될 것으로 예상합니다. 이 간격은 플래그에 의해 설정됩니다. 수평-포드-자동 스케일러-업스케일-지연.
• 모듈 수를 마지막으로 줄인 후 HPA는 안정화될 때까지 XNUMX분 동안 기다립니다. 이 간격은 플래그에 의해 설정됩니다. 수평-포드-자동 스케일러-다운스케일-지연.
• HPA는 복제 컨트롤러가 아닌 배포 개체에서 가장 잘 작동합니다. 수평 자동 확장은 복제 컨트롤러를 직접 조작하는 롤링 업데이트와 호환되지 않습니다. 배포 시 복제본 수는 배포 개체에 따라 직접적으로 달라집니다.

포드의 수직 자동 확장

수직 자동 확장(VPA)은 기존 Pod에 더 많은(또는 더 적은) CPU 시간이나 메모리를 할당합니다. 상태 저장 또는 상태 비저장 포드에 적합하지만 주로 상태 저장 서비스에 사용됩니다. 그러나 처음에 할당된 리소스의 양을 자동으로 조정해야 하는 경우 상태 비저장 모듈에 VPA를 사용할 수도 있습니다.

VPA는 OOM(메모리 부족) 이벤트에도 응답합니다. CPU 시간과 메모리를 변경하려면 Pod를 다시 시작해야 합니다. 다시 시작되면 VPA는 할당 예산(포드 배포 예산, PDB) 필요한 최소 모듈 수를 보장합니다.

각 모듈의 최소 및 최대 리소스를 설정할 수 있습니다. 따라서 할당된 메모리의 최대 양을 8GB로 제한할 수 있습니다. 이는 현재 노드가 컨테이너당 8GB 이상의 메모리를 할당할 수 없는 경우에 유용합니다. 자세한 사양 및 작동 메커니즘은 공식 VPA 위키.

또한 VPA에는 흥미로운 추천 기능(VPA Recommender)이 있습니다. 모든 모듈의 리소스 사용량과 OOM 이벤트를 모니터링하여 과거 지표를 기반으로 한 지능형 알고리즘을 기반으로 새로운 메모리 및 CPU 시간 값을 제안합니다. Pod 핸들을 가져와 제안된 리소스 값을 반환하는 API도 있습니다.

VPA 추천자는 리소스 "한도"를 추적하지 않는다는 점에 주목할 가치가 있습니다. 이로 인해 모듈이 노드 내의 리소스를 독점하게 될 수 있습니다. 막대한 메모리나 CPU 소비를 방지하려면 네임스페이스 수준에서 제한을 설정하는 것이 좋습니다.

높은 수준의 VPA 작동 방식:

1. VPA는 기본 10초 간격으로 설치 중에 지정된 메트릭 값을 지속적으로 확인합니다.
2. 지정된 임계값에 도달하면 VPA는 할당된 리소스 양을 변경하려고 시도합니다.
3. VPA는 배포/복제 컨트롤러 내의 리소스 수를 업데이트합니다.
4. 모듈이 다시 시작되면 생성된 인스턴스에 모든 새 리소스가 적용됩니다.

VPA는 필요한 양의 리소스를 추가합니다.

VPA를 사용할 때 다음 사항에 유의하세요.

• 크기를 조정하려면 포드를 필수로 다시 시작해야 합니다. 이는 변경 후 불안정한 작동을 방지하기 위해 필요합니다. 안정성을 위해 모듈은 새로 할당된 리소스를 기반으로 노드 전체에 다시 시작되고 배포됩니다.
• VPA와 HPA는 아직 서로 호환되지 않으며 동일한 Pod에서 실행할 수 없습니다. 동일한 클러스터에서 두 가지 크기 조정 메커니즘을 모두 사용하는 경우 설정이 동일한 객체에서 활성화되지 않도록 방지해야 합니다.
• VPA는 과거 및 현재 사용량만을 기준으로 리소스에 대한 컨테이너 요청을 조정합니다. 리소스 사용 제한을 설정하지 않습니다. 애플리케이션이 제대로 작동하지 않고 점점 더 많은 리소스를 차지하기 시작하는 데 문제가 있을 수 있습니다. 이로 인해 Kubernetes에서 이 포드가 꺼지게 됩니다.
• VPA는 아직 개발 초기 단계에 있습니다. 가까운 시일 내에 시스템이 일부 변경될 수 있다는 점에 대비하세요. 당신은 읽을 수 있습니다 알려진 제한사항 и 개발 계획. 따라서 VPA와 HPA의 공동 운영을 구현하고 수직적 자동 확장 정책과 함께 모듈을 배포할 계획이 있습니다(예: 특수 라벨 'VPA 필요').

Kubernetes 클러스터 자동 크기 조정

CA(Cluster Autoscaler)는 대기 중인 Pod 수에 따라 노드 수를 변경합니다. 시스템은 정기적으로 보류 중인 모듈을 확인하고 더 많은 리소스가 필요하고 클러스터가 설정된 제한을 초과하지 않는 경우 클러스터 크기를 늘립니다. CA는 클라우드 서비스 공급자와 통신하고 추가 노드를 요청하거나 유휴 노드를 해제합니다. CA의 첫 번째 일반적으로 사용 가능한 버전은 Kubernetes 1.8에 도입되었습니다.

SA 운영의 상위 수준 계획:

1. CA는 기본 간격인 10초마다 보류 상태의 모듈을 확인합니다.
2. 클러스터에 할당할 수 있는 사용 가능한 리소스가 부족하여 하나 이상의 Pod가 대기 상태인 경우 하나 이상의 추가 노드를 프로비저닝하려고 시도합니다.
3. 클라우드 서비스 공급자가 필요한 노드를 할당하면 클러스터에 참여하고 포드를 제공할 준비가 됩니다.
4. Kubernetes 스케줄러는 보류 중인 Pod를 새 노드에 배포합니다. 이후에도 일부 모듈이 여전히 대기 상태로 남아 있으면 프로세스가 반복되고 새 노드가 클러스터에 추가됩니다.

클라우드에서 클러스터 노드 자동 프로비저닝

CA를 사용할 때 다음 사항을 고려하십시오.

• CA는 CPU 로드에 관계없이 클러스터의 모든 Pod에 실행 공간이 있는지 확인합니다. 또한 클러스터에 불필요한 노드가 없는지 확인하려고 시도합니다.
• CA는 약 30초 후에 확장이 필요하다고 등록합니다.
• 노드가 더 이상 필요하지 않으면 CA는 기본적으로 시스템을 확장하기 전에 10분을 기다리게 됩니다.
• 자동 확장 시스템에는 확장기라는 개념이 있습니다. 이는 새 노드가 추가될 노드 그룹을 선택하기 위한 다양한 전략입니다.
• 책임감 있게 옵션을 사용하세요 Cluster-autoscaler.kubernetes.io/safe-to-evict (true). 많은 포드를 설치하거나 그 중 많은 포드가 모든 노드에 분산되어 있는 경우 클러스터를 확장하는 기능이 크게 손실됩니다.
• 사용 PodDisruptionBudgetsPod가 삭제되는 것을 방지하기 위해 애플리케이션의 일부가 완전히 중단될 수 있습니다.

Kubernetes 자동 확장 처리가 서로 상호 작용하는 방법

완벽한 조화를 위해서는 포드 수준(HPA/VPA)과 클러스터 수준 모두에서 자동 확장을 적용해야 합니다. 그들은 상대적으로 간단하게 서로 상호 작용합니다.

1. HPA 또는 VPA는 기존 포드에 할당된 포드 복제본 또는 리소스를 업데이트합니다.
2. 계획된 확장에 필요한 노드가 충분하지 않은 경우 CA는 대기 상태에 있는 포드가 있음을 감지합니다.
3. CA는 새 노드를 할당합니다.
4. 모듈은 새 노드에 배포됩니다.

협업형 Kubernetes 스케일아웃 시스템

Kubernetes 자동 크기 조정의 일반적인 실수

자동 확장을 구현하려고 할 때 DevOps에서 발생하는 몇 가지 일반적인 문제가 있습니다.

HPA 및 VPA는 측정항목과 일부 기록 데이터에 따라 달라집니다. 할당된 리소스가 부족하면 모듈이 최소화되어 메트릭을 생성할 수 없습니다. 이 경우 자동 크기 조정은 절대 발생하지 않습니다.

크기 조정 작업 자체는 시간에 민감합니다. 우리는 사용자가 문제나 실패를 인지하기 전에 모듈과 클러스터가 빠르게 확장되기를 원합니다. 따라서 포드와 클러스터의 평균 확장 시간을 고려해야 합니다.

이상적인 시나리오 - 4분:

1. 30 초. 목표 측정항목 업데이트: 30~60초.
2. 30 초. HPA는 측정항목 값을 확인합니다: 30초.
3. 2초 미만. 포드가 생성되고 대기 상태로 전환됩니다: 1초.
4. 2초 미만. CA는 대기 중인 모듈을 확인하고 프로비저닝 노드에 호출을 보냅니다: 1초.
5. 3 분. 클라우드 공급자가 노드를 할당합니다. K8은 준비될 때까지 기다립니다. 최대 10분(여러 요인에 따라 다름)

최악의 경우(더 현실적인) 시나리오 - 12분:

1. 30 초. 목표 측정항목을 업데이트하세요.
2. 30 초. HPA는 측정항목 값을 확인합니다.
3. 2초 미만. Pod가 생성되고 대기 상태로 들어갑니다.
4. 2초 미만. CA는 대기 중인 모듈을 확인하고 노드 프로비저닝을 호출합니다.
5. 10 분. 클라우드 공급자가 노드를 할당합니다. K8은 준비될 때까지 기다립니다. 대기 시간은 공급업체 지연, OS 지연, 지원 도구 등 여러 요인에 따라 달라집니다.

클라우드 공급자의 확장 메커니즘과 CA를 혼동하지 마십시오. 후자는 Kubernetes 클러스터 내에서 실행되는 반면 클라우드 공급자 엔진은 노드 배포 기반으로 작동합니다. 포드나 애플리케이션에 무슨 일이 일어나고 있는지 알 수 없습니다. 이러한 시스템은 병렬로 작동합니다.

Kubernetes에서 확장을 관리하는 방법

1. Kubernetes는 리소스 관리 및 조정 도구입니다. Pod 및 클러스터 리소스 관리 작업은 Kubernetes를 마스터하는 데 있어서 중요한 단계입니다.
2. HPA 및 VPA를 고려한 포드 확장성의 논리를 이해합니다.
3. CA는 포드와 컨테이너의 요구 사항을 잘 이해하고 있는 경우에만 사용해야 합니다.
4. 클러스터를 최적으로 구성하려면 다양한 확장 시스템이 함께 작동하는 방식을 이해해야 합니다.
5. 확장 시간을 예측할 때 최악의 경우와 최상의 시나리오를 염두에 두십시오.

출처 : habr.com