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

Kubernetes 클러스터를 생성할 때 다음과 같은 의문이 생길 수 있습니다. 몇 개의 워커 노드를 어떤 유형으로 설정해야 할까요? 온프레미스 클러스터에 더 나은 점은 무엇일까요? 강력한 서버 여러 대를 구매하는 것과 데이터 센터에 있는 오래된 머신 수십 대를 사용하는 것 중 어느 것일까요? 클라우드에서는 싱글 코어 인스턴스 8개를 사용하는 것이 더 나은가요, 아니면 쿼드 코어 인스턴스 2개를 사용하는 것이 더 나은가요?

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

클러스터 용량

일반적으로 쿠버네티스 클러스터는 대규모 "슈퍼노드"로 생각할 수 있습니다. 전체 컴퓨팅 능력은 구성 노드의 모든 거듭제곱의 합입니다.

클러스터의 원하는 목표 용량을 달성하는 방법에는 여러 가지가 있습니다. 예를 들어, 애플리케이션 세트에 해당 양의 리소스가 필요하므로 총 8개의 프로세서 코어와 32GB의 RAM을 갖춘 클러스터가 필요합니다. 그러면 16GB 메모리가 있는 노드 8개를 설치하거나 XNUMXGB 메모리, 쿼드 코어 프로세서 XNUMX개 또는 듀얼 코어 프로세서 XNUMX개가 있는 노드 XNUMX개를 설치할 수 있습니다.

클러스터를 만드는 방법은 두 가지가 있습니다.

두 옵션 모두 동일한 용량의 클러스터를 제공하지만, 하단 구성에는 작은 노드가 4개 있는 반면, 상단 구성에는 큰 노드가 2개 있습니다.

어떤 옵션이 더 낫습니까?

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

여러 개의 큰 노드

작은 매듭이 많아요

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

원활한 자동 확장

(사내에서 사용하는 경우) 더 저렴함

가격은 크게 다르지 않아요(클라우드에서)

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

전체 복제

리소스가 더 효율적으로 사용됩니다(시스템 데몬의 오버헤드 감소)
더 높은 클러스터 장애 허용성

여기서는 작업 노드에 대해서만 이야기하고 있다는 점에 유의하세요. 마스터 노드의 개수와 크기를 선택하는 것은 전혀 다른 주제입니다.

그러면 표의 각 항목에 대해 더 자세히 논의해 보겠습니다.

옵션 1: 여러 개의 대형 노드

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

프로

플러스 #1. 제어하기 더 쉽습니다
전체 차량을 관리하는 것보다 몇 대의 차량을 관리하는 것이 더 쉽습니다. 업데이트와 수정 사항을 더 빠르게 적용하고, 동기화도 더 쉬워졌습니다. 절대적인 숫자로 본 실패 건수도 더 낮습니다.

위에 나열된 모든 내용은 귀하의 하드웨어, 귀하의 서버에만 적용되며 클라우드 인스턴스에는 적용되지 않습니다.

클라우드에서는 상황이 다릅니다. 이 경우 관리 업무는 클라우드 서비스 제공업체가 담당합니다. 따라서 클라우드에서 10개의 노드를 관리하는 것은 1개의 노드를 관리하는 것과 크게 다르지 않습니다.

클라우드 내 포드 간 트래픽 라우팅 및 로드 밸런싱 자동으로 수행됩니다: 인터넷에서 들어오는 트래픽은 메인 로드 밸런서로 전달되고, 메인 로드 밸런서는 이 트래픽을 노드 중 하나의 포트로 전달합니다(NodePort 서비스는 각 클러스터 노드에서 30000~32767 범위의 포트를 설정합니다). kube-proxy가 설정한 규칙은 노드에서 Pod로 트래픽을 리디렉션합니다. XNUMX개의 노드에 XNUMX개의 포드가 있는 경우는 다음과 같습니다.

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

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

따라서 클라우드에서는 일반적으로 더 강력한 서버에 비용을 절감할 수 없습니다.

장점 #3: 리소스를 많이 사용하는 애플리케이션을 실행할 수 있습니다.
일부 애플리케이션에는 클러스터에서 강력한 서버가 필요합니다. 예를 들어, 머신 러닝 시스템에 8GB의 메모리가 필요한 경우, 최소한 하나의 대형 워커 노드가 없다면 1GB 노드에서 이를 실행할 수 없습니다.

죄수 팀은

단점 #1: 노드당 포드가 너무 많음
동일한 작업이 더 적은 노드에서 수행된다면, 각 노드는 자연스럽게 더 많은 포드를 갖게 됩니다.

이는 문제가 될 수 있습니다.

그 이유는 각 포드가 컨테이너 런타임(예: Docker)과 kubelet, cAdvisor에 약간의 오버헤드를 발생시키기 때문입니다.

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

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

모듈의 수가 늘어나면 시스템 속도가 느려지고 심지어 안정성이 떨어질 수도 있습니다.

Kubernetes 저장소에 몇 가지가 있습니다. 불평, 노드가 Ready/NotReady 상태 사이를 오가는 이유는 노드의 모든 컨테이너에 대한 Kubelet 정기 검사에 너무 많은 시간이 걸리기 때문입니다.
이러한 이유로 Kubernetes 노드당 최대 110개의 포드를 배치하는 것이 좋습니다.. 노드의 성능에 따라 노드당 더 많은 Pod를 실행할 수 있지만, 문제가 발생할지 또는 모든 것이 잘 작동할지 예측하기는 어렵습니다. 작업을 미리 테스트해 보는 것이 좋습니다.

마이너스 #2. 복제 제한
노드가 너무 적으면 애플리케이션 복제의 효과적인 정도가 제한됩니다. 예를 들어, 복제본이 5개 있지만 노드가 2개뿐인 고가용성 애플리케이션이 있는 경우 애플리케이션의 효과적인 복제 정도는 2로 줄어듭니다.

5개의 복제본은 2개의 노드에만 분산될 수 있으며, 그 중 하나에 장애가 발생하면 여러 복제본이 즉시 중단됩니다.

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

따라서 높은 가용성 요구 사항을 충족하려면 클러스터에 특정 최소 노드 수가 필요할 수 있습니다.

마이너스 #3. 실패의 더 나쁜 결과
노드 수가 적을 경우, 오류가 발생할 때마다 더 심각한 결과가 초래됩니다. 예를 들어, 노드가 두 개뿐이고 그 중 하나에 장애가 발생하면 모듈의 절반이 한꺼번에 사라집니다.

물론, 쿠버네티스는 실패한 노드의 작업 부하를 다른 노드로 마이그레이션합니다. 하지만 그 수가 적다면 여유 용량이 부족할 수 있습니다. 결과적으로, 실패한 노드를 다시 가동할 때까지 일부 애플리케이션을 사용할 수 없게 됩니다.

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

마이너스 #4. 추가 자동 확장 단계
쿠버네티스는 클라우드 인프라를 위한 클러스터 자동 확장 시스템을 제공하여 현재 요구 사항에 따라 노드를 자동으로 추가하거나 제거할 수 있습니다. 노드가 커질수록 자동 확장은 더 불규칙하고 서투르게 됩니다. 예를 들어, 두 개의 노드에 추가 노드를 추가하면 클러스터 용량이 한 번에 50% 증가합니다. 그리고 필요하지 않더라도 이러한 리소스에 대한 비용을 지불해야 합니다.

따라서 클러스터 자동 확장을 사용할 계획이라면 노드가 작을수록 더 유연하고 비용 효율적인 확장을 얻을 수 있습니다.

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

옵션 2: 여러 개의 작은 노드

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

프로

장점 #1: 실패의 영향이 적음
노드가 많을수록 각 노드에 있는 포드 수는 줄어듭니다. 예를 들어, 10개의 노드에 100개의 모듈이 있다면 각 노드는 평균적으로 10개의 모듈을 갖게 됩니다.

따라서 노드 하나에 장애가 발생해도 작업 부하의 10%만 손실됩니다. 영향을 받는 복제본의 수는 적고, 애플리케이션 전체는 계속 작동할 가능성이 높습니다.

또한 남은 노드에는 실패한 노드의 작업 부하를 처리할 수 있는 충분한 여유 용량이 있을 가능성이 높으므로 Kubernetes가 자유롭게 Pod를 재조정하고 애플리케이션을 비교적 빠르게 다시 백업하고 실행할 수 있습니다.

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

죄수 팀은

단점 #1: 제어하기 더 어려움
노드 수가 많으면 관리하기가 더 어렵습니다. 예를 들어, 각 쿠버네티스 노드는 다른 모든 노드와 통신해야 하므로 연결 수가 이차적으로 늘어나고, 이러한 모든 연결을 추적해야 합니다.

쿠버네티스 컨트롤러 관리자의 노드 컨트롤러는 클러스터의 모든 노드를 정기적으로 검사하여 상태를 확인합니다. 노드가 많을수록 컨트롤러의 부하가 커집니다.

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

일반적으로 각 워커 노드는 메인 노드의 시스템 구성 요소에 추가적인 부하를 줍니다.

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

많은 수의 워커 노드를 관리하려면 더 효율적인 마스터 노드를 선택해야 합니다. 예를 들어, kube-up 자동으로 설치됩니다 워커 노드의 수에 따라 마스터 노드의 올바른 VM 크기가 결정됩니다. 즉, 작업 노드가 많을수록 주요 노드의 생산성이 높아져야 합니다.

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

단점 #2: 오버헤드 증가
각 워커 노드에서 Kubernetes는 일련의 시스템 데몬을 실행합니다. 여기에는 cAdvisor를 비롯하여 컨테이너 런타임(예: Docker), kube-proxy, kubelet이 포함됩니다. 그들은 모두 일정량의 자원을 소모합니다.

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

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

마이너스 #3: 자원의 비효율적 사용
작은 노드에서는 남아 있는 리소스 조각이 너무 작아서 작업 부하를 할당할 수 없는 경우가 있어 사용되지 않는 경우가 있습니다.

예를 들어, 각 포드에는 0,75GB의 메모리가 필요합니다. 메모리가 1GB인 노드가 0,25개 있다면 Pod를 XNUMX개 실행할 수 있는데, 그러면 각 노드에는 XNUMXGB의 사용되지 않는 메모리가 남게 됩니다.

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

메모리가 10GB인 대형 노드에서는 이러한 모듈을 13개 실행해도 사용되지 않은 0,25GB 청크가 하나만 남습니다.

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

따라서 대규모 노드에서는 리소스가 더욱 최적으로 사용됩니다.

큰 노드가 몇 개인가요, 아니면 작은 노드가 여러 개인가요?

그렇다면 클러스터 내의 몇 개의 대형 노드가 더 나은가요, 아니면 여러 개의 작은 노드가 더 나은가요? 언제나 그렇듯이 명확한 답은 없습니다. 많은 부분이 응용 프로그램의 유형에 따라 달라집니다.

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

중간 상황에서는 각 옵션의 장단점을 바탕으로 선택을 하세요. 어쩌면 어떤 주장은 다른 주장보다 귀하의 상황에 더 적합할 수도 있습니다.

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

단일한 조리법은 없고, 각 상황은 고유한 뉘앙스를 지니며, 오직 생산 과정을 통해서만 진실이 드러날 것입니다.

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

Kubernetes에 대해 자세히 알아보기: 클러스터 관리 및 배포를 위한 25가지 유용한 도구.

출처 : habr.com