Kubernetes 작업자 노드: 작은 노드가 많습니까, 아니면 큰 노드가 여러 개 있습니까?

Kubernetes 클러스터를 생성할 때 다음과 같은 질문이 생길 수 있습니다. 구성할 작업자 노드 수와 유형은 무엇입니까? 온프레미스 클러스터에는 어떤 것이 더 좋습니까? 여러 대의 강력한 서버를 구입합니까, 아니면 데이터 센터에 있는 XNUMX개의 오래된 시스템을 사용합니까? 클라우드에서 XNUMX개의 단일 코어 또는 XNUMX개의 쿼드 코어 인스턴스를 사용하는 것이 더 낫습니까?

이 질문에 대한 답변은 기사에 있습니다. Learnk8s 교육 프로젝트의 소프트웨어 엔지니어이자 교사인 Daniel Weibel 명령 번역에서 Mail.ru의 Kubernetes aaS.

클러스터 용량

일반적으로 Kubernetes 클러스터는 대규모 "슈퍼노드"로 간주될 수 있습니다. 총 컴퓨팅 능력은 모든 구성 노드의 능력의 합입니다.

원하는 클러스터 용량 목표를 달성하는 방법에는 여러 가지가 있습니다. 예를 들어, 애플리케이션 세트에는 너무 많은 리소스가 필요하기 때문에 총 용량이 8개의 프로세서 코어와 32GB RAM인 클러스터가 필요합니다. 그런 다음 16GB 메모리가 있는 노드 8개 또는 XNUMXGB 메모리가 있는 노드 XNUMX개, 쿼드 코어 프로세서 XNUMX개 또는 듀얼 코어 프로세서 XNUMX개를 설치할 수 있습니다.

클러스터를 생성하는 두 가지 방법은 다음과 같습니다.

두 옵션 모두 동일한 용량의 클러스터를 생성하지만 하단 구성에는 XNUMX개의 작은 노드가 있고 상단 구성에는 XNUMX개의 더 큰 노드가 있습니다.

어떤 옵션이 더 낫습니까?

이 질문에 답하기 위해 두 옵션의 장점을 살펴보겠습니다. 우리는 이를 표로 요약했습니다.

여러 개의 큰 노드

많은 작은 노드

더 쉬운 클러스터 관리(온프레미스인 경우)

원활한 자동 확장

더 저렴함(구내인 경우)

가격은 조금 다릅니다 (클라우드에서)

리소스 집약적인 애플리케이션을 실행할 수 있습니다.

전체 복제

리소스가 보다 효율적으로 사용됩니다(시스템 데몬에 대한 오버헤드 감소).
더 높은 클러스터 내결함성

우리는 작업자 노드에 대해서만 이야기하고 있다는 점에 유의하십시오. 메인 노드의 수와 크기를 선택하는 것은 완전히 다른 주제입니다.

이제 표의 각 항목을 더 자세히 논의해 보겠습니다.

첫 번째 옵션: 여러 개의 대형 노드

가장 극단적인 옵션은 전체 클러스터 용량에 대해 하나의 작업자 노드를 사용하는 것입니다. 위의 예에서 이는 16개의 CPU 코어와 16GB의 RAM을 갖춘 단일 작업자 노드입니다.

프로

플러스 1. 관리 용이성
전체 시스템보다 몇 대의 시스템을 관리하는 것이 더 쉽습니다. 업데이트와 수정 사항을 더 빠르게 출시하고 동기화하기가 더 쉽습니다. 절대적인 실패 횟수도 적습니다.

위의 모든 내용은 클라우드 인스턴스가 아닌 하드웨어, 서버에 적용된다는 점에 유의하세요.

클라우드에서는 상황이 다릅니다. 여기서 관리는 클라우드 서비스 제공업체가 처리합니다. 따라서 클라우드에서 XNUMX개의 노드를 관리하는 것은 XNUMX개의 노드를 관리하는 것과 크게 다르지 않습니다.

클라우드 내 포드 간 트래픽 라우팅 및 부하 분산 자동으로 수행: 인터넷에서 들어오는 트래픽은 기본 로드 밸런서로 전송되어 노드 중 하나의 포트로 트래픽을 전달합니다(NodePort 서비스는 각 클러스터 노드에서 30000-32767 범위의 포트를 설정합니다). kube-proxy에 의해 설정된 규칙은 노드에서 포드로 트래픽을 리디렉션합니다. 두 개의 노드에 있는 XNUMX개의 포드의 모습은 다음과 같습니다.

장점 #2: 노드당 비용 절감
강력한 자동차는 더 비싸지만 가격 인상이 반드시 선형적인 것은 아닙니다. 즉, 10GB 메모리를 탑재한 XNUMX코어 서버 XNUMX대가 일반적으로 동일한 메모리 양을 탑재한 XNUMX코어 서버보다 저렴합니다.

하지만 이 규칙은 일반적으로 클라우드 서비스에서는 작동하지 않습니다. 모든 주요 클라우드 제공업체의 현재 가격 체계에서는 가격이 용량에 따라 선형적으로 증가합니다.

따라서 클라우드에서는 일반적으로 더 강력한 서버에 저장할 수 없습니다.

장점 #3: 리소스 집약적인 애플리케이션을 실행할 수 있습니다.
일부 애플리케이션에는 클러스터에 강력한 서버가 필요합니다. 예를 들어 기계 학습 시스템에 8GB의 메모리가 필요한 경우 1GB 노드에서는 실행할 수 없고 하나 이상의 대형 작업자 노드에서만 실행할 수 있습니다.

죄수 팀은

단점 1. 노드당 Pod가 많음
동일한 작업이 더 적은 수의 노드에서 수행되면 각 노드에는 자연스럽게 더 많은 포드가 있게 됩니다.

이것은 문제가 될 수 있습니다.

그 이유는 각 모듈이 kubelet 및 cAdvisor뿐만 아니라 컨테이너 런타임(예: Docker)에 약간의 오버헤드를 도입하기 때문입니다.

예를 들어, kubelet은 생존 가능성을 위해 노드의 모든 컨테이너를 정기적으로 조사합니다. 컨테이너가 많을수록 kubelet이 수행해야 하는 작업도 더 많아집니다.

CAdvisor는 노드의 모든 컨테이너에 대한 리소스 사용 통계를 수집하고, kubelet은 이 정보를 정기적으로 쿼리하여 API를 통해 제공합니다. 다시 말하지만, 더 많은 컨테이너는 cAdvisor와 kubelet 모두에 더 많은 작업을 의미합니다.

모듈 수가 증가하면 시스템 속도가 느려지고 안정성이 저하될 수도 있습니다.

Kubernetes 저장소에서 일부 불평노드의 모든 컨테이너를 정기적으로 kubelet에서 확인하는 데 시간이 너무 오래 걸리기 때문에 노드가 Ready/NotReady 상태 사이를 이동합니다.
이런 이유로 쿠버네티스 노드당 Pod를 110개 이하로 배치하는 것이 좋습니다.. 노드의 성능에 따라 노드당 더 많은 Pod를 실행할 수 있지만 문제가 있을지, 모든 것이 잘 작동할지 예측하기 어렵습니다. 작업을 미리 테스트해 볼 가치가 있습니다.

단점 2. 복제의 한계
노드 수가 너무 적으면 애플리케이션 복제의 유효 범위가 제한됩니다. 예를 들어, 복제본이 XNUMX개 있지만 노드가 XNUMX개만 있는 고가용성 애플리케이션이 있는 경우 애플리케이션의 유효 복제 수준은 XNUMX로 줄어듭니다.

XNUMX개의 복제본은 XNUMX개의 노드에만 분산될 수 있으며, 그 중 하나가 실패하면 한 번에 여러 개의 복제본이 중단됩니다.

노드가 XNUMX개 이상인 경우 각 복제본은 별도의 노드에서 실행되며, 한 노드에 장애가 발생하면 최대 XNUMX개의 복제본이 제거됩니다.

따라서 고가용성 요구 사항에 따라 클러스터에 특정 최소 수의 노드가 필요할 수 있습니다.

단점 3번. 실패로 인한 더 나쁜 결과
노드 수가 적을 경우 각 오류는 더 심각한 결과를 초래합니다. 예를 들어 노드가 두 개뿐이고 그 중 하나에 오류가 발생하면 모듈의 절반이 즉시 사라집니다.

물론 Kubernetes는 실패한 노드의 워크로드를 다른 노드로 마이그레이션합니다. 그러나 그 수가 적다면 여유 용량이 충분하지 않을 수 있습니다. 결과적으로 실패한 노드를 불러올 때까지 일부 애플리케이션을 사용할 수 없습니다.

따라서 노드가 많을수록 하드웨어 오류의 영향이 줄어듭니다.

단점 #4: 자동 확장 단계가 더 많음
Kubernetes에는 클라우드 인프라를 위한 클러스터 자동 확장 시스템이 있어 현재 요구 사항에 따라 노드를 자동으로 추가하거나 제거할 수 있습니다. 노드가 커지면 자동 확장이 더욱 갑작스럽고 투박해집니다. 예를 들어 두 개의 노드에서 추가 노드를 추가하면 클러스터 용량이 즉시 50% 증가합니다. 그리고 해당 리소스가 필요하지 않더라도 해당 리소스에 대한 비용을 지불해야 합니다.

따라서 자동 클러스터 조정을 사용하려는 경우 노드가 작을수록 더 유연하고 비용 효과적인 조정을 얻을 수 있습니다.

이제 다수의 작은 노드의 장점과 단점을 살펴보겠습니다.

두 번째 옵션: 많은 작은 노드

이 접근 방식의 장점은 본질적으로 여러 개의 큰 노드가 있는 반대 옵션의 단점에서 비롯됩니다.

프로

장점 #1: 실패의 영향이 적음
노드가 많을수록 각 노드의 Pod 수가 줄어듭니다. 예를 들어, XNUMX개 노드당 XNUMX개의 모듈이 있는 경우 각 노드에는 평균 XNUMX개의 모듈이 있습니다.

이렇게 하면 노드 중 하나에 오류가 발생하더라도 워크로드의 10%만 손실됩니다. 소수의 복제본만 영향을 받고 전체 애플리케이션은 계속 작동할 가능성이 있습니다.

또한 나머지 노드에는 장애가 발생한 노드의 워크로드를 처리할 수 있는 충분한 여유 리소스가 있을 가능성이 높으므로 Kubernetes는 포드 일정을 자유롭게 변경할 수 있으며 애플리케이션은 상대적으로 빠르게 기능 상태로 돌아갑니다.

장점 #2: 우수한 복제
노드가 충분하면 Kubernetes 스케줄러는 모든 복제본에 다른 노드를 할당할 수 있습니다. 이렇게 하면 노드에 오류가 발생하면 하나의 복제본만 영향을 받고 애플리케이션은 계속 사용할 수 있습니다.

죄수 팀은

단점 1. 제어가 어렵다
노드 수가 많으면 관리하기가 더 어렵습니다. 예를 들어 각 Kubernetes 노드는 다른 모든 노드와 통신해야 합니다. 즉, 연결 수가 XNUMX차적으로 증가하고 이러한 모든 연결을 추적해야 합니다.

Kubernetes Controller Manager의 노드 컨트롤러는 정기적으로 클러스터의 모든 노드를 살펴보며 상태를 확인합니다. 노드가 많을수록 컨트롤러에 더 많은 부하가 가해집니다.

etcd 데이터베이스의 로드도 증가하고 있습니다. 각 kubelet 및 kube-proxy 호출 당직자 etcd의 경우(API를 통해) etcd가 객체 업데이트를 브로드캐스트해야 합니다.

일반적으로 각 작업자 노드는 마스터 노드의 시스템 구성 요소에 추가 로드를 부과합니다.

Kubernetes는 공식적으로 다음과 같은 클러스터를 지원합니다. 노드 수 최대 5000개. 그러나 실제로는 이미 500개의 노드가 있습니다. 사소한 문제를 일으킬 수 있습니다.

다수의 작업자 노드를 관리하려면 보다 강력한 마스터 노드를 선택해야 합니다. 예를 들어, 큐브업 자동으로 설치 작업자 노드 수에 따라 마스터 노드의 올바른 VM 크기. 즉, 작업자 노드가 많을수록 마스터 노드의 생산성이 높아집니다.

이러한 특정 문제를 해결하기 위해 다음과 같은 특별한 개발이 있습니다. 가상 큐브 렛. 이 시스템을 사용하면 제한을 우회하고 엄청난 수의 작업자 노드로 클러스터를 구축할 수 있습니다.

단점 #2: 간접비가 더 많이 듭니다.
각 작업자 노드에서 Kubernetes는 시스템 데몬 세트를 실행합니다. 여기에는 cAdvisor를 포함한 컨테이너 런타임(예: Docker), kube-proxy 및 kubelet이 포함됩니다. 함께 그들은 일정한 양의 자원을 소비합니다.

작은 노드가 많으면 각 노드에서 이 오버헤드의 비율이 더 커집니다. 예를 들어 단일 노드의 모든 시스템 데몬이 함께 0,1 CPU 코어와 0,1GB 메모리를 사용한다고 가정해 보겠습니다. 10GB 메모리를 갖춘 1개 코어 노드가 하나 있는 경우 데몬은 클러스터 용량의 1%를 소비합니다. 반면에 10GB 메모리를 갖춘 XNUMX개의 단일 코어 노드에서는 데몬이 클러스터 용량의 XNUMX%를 차지합니다.

따라서 노드 수가 적을수록 인프라가 더 효율적으로 사용됩니다.

단점 3. 자원의 비효율적 사용
작은 노드에서는 나머지 리소스 청크가 너무 작아서 워크로드를 할당할 수 없으므로 사용되지 않은 채로 남아 있을 수 있습니다.

예를 들어 각 포드에는 0,75GB의 메모리가 필요합니다. 각각 1GB의 메모리가 있는 0,25개의 노드가 있는 경우 XNUMX개의 Pod를 실행할 수 있으며 각 노드에는 XNUMXGB의 사용되지 않은 메모리가 남습니다.

이는 전체 클러스터 메모리의 25%가 낭비된다는 의미입니다.

10GB 메모리를 갖춘 대규모 노드에서는 이러한 모듈 중 13개를 실행할 수 있으며, 사용되지 않은 0,25GB 조각은 하나만 남게 됩니다.

이 경우 메모리의 2,5%만 낭비됩니다.

따라서 리소스는 더 큰 노드에서 더 최적으로 사용됩니다.

여러 개의 큰 노드 또는 많은 작은 노드?

그렇다면 클러스터에 몇 개의 큰 노드가 있는 것과 작은 노드가 많은 것 중 어느 것이 더 낫습니까? 언제나 그렇듯이 명확한 답은 없습니다. 많은 것은 응용 프로그램 유형에 따라 다릅니다.

예를 들어 애플리케이션에 10GB의 메모리가 필요한 경우 더 큰 노드를 선택하는 것이 당연합니다. 그리고 애플리케이션에 고가용성을 위해 XNUMX배 복제가 필요한 경우 단 두 개의 노드에만 복제본을 배치하는 위험을 감수할 가치가 거의 없습니다. 클러스터에 최소 XNUMX개의 노드가 있어야 합니다.

중간 상황에서는 각 옵션의 장점과 단점을 고려하여 선택하세요. 아마도 일부 주장은 다른 주장보다 귀하의 상황과 더 관련이 있을 수 있습니다.

그리고 모든 노드를 같은 크기로 만들 필요는 전혀 없습니다. 먼저 동일한 크기의 노드로 실험한 다음 다른 크기의 노드를 추가하여 클러스터로 결합하는 것을 방해하는 것은 없습니다. Kubernetes 클러스터의 작업자 노드는 완전히 이기종일 수 있습니다. 따라서 두 접근 방식의 장점을 결합해 볼 수 있습니다.

단일한 레시피는 없고 상황마다 고유한 뉘앙스가 있으며 오직 생산된 제품만이 진실을 보여줄 것입니다.

클라우드 플랫폼 팀이 준비한 번역 Mail.ru 클라우드 솔루션.

Kubernetes에 대한 추가 정보: 클러스터 관리 및 배포를 위한 25가지 유용한 도구.

출처 : habr.com