대규모 클러스터 구축하기

클러스터는 쿠버네티스 에이전트를 실행하는 노드(물리 또는 가상 머신)의 집합으로, 컨트롤 플레인이 관리해요. 쿠버네티스 v1.37은 최대 5,000개 노드의 클러스터를 지원합니다. 더 구체적으로 쿠버네티스는 다음 조건을 모두 충족하는 구성을 수용하도록 설계되었어요:

노드당 110개 이하의 파드
5,000개 이하의 노드
150,000개 이하의 총 파드
300,000개 이하의 총 컨테이너

노드를 추가하거나 제거해 클러스터를 스케일링할 수 있어요. 그 방법은 클러스터가 어떻게 배포되었는지에 따라 달라집니다.

출처: 문서

본문

클라우드 제공자 리소스 쿼터

많은 노드를 가진 클러스터를 만들 때 클라우드 제공자 쿼터 문제에 부딪히지 않으려면 다음을 고려해요:

클라우드 리소스에 대한 쿼터 증가를 요청한다. 예를 들어:
- 컴퓨트 인스턴스
- CPU
- 스토리지 볼륨
- 사용 중인 IP 주소
- 패킷 필터링 규칙 세트
- 로드 밸런서 수
- 네트워크 서브넷
- 로그 스트림
일부 클라우드 제공자는 새 인스턴스 생성을 속도 제한하므로, 배치 사이에 일시 중지하며 새 노드를 배치로 가져오도록 클러스터 스케일링 작업을 조절한다.

컨트롤 플레인 구성 요소

대규모 클러스터에는 충분한 컴퓨트와 다른 리소스를 가진 컨트롤 플레인이 필요해요.

보통은 실패 영역(failure zone)당 컨트롤 플레인 인스턴스를 하나 또는 둘 실행하고, 먼저 인스턴스를 수직으로 스케일링한 뒤 (수직) 스케일링 수익이 감소하는 지점에 도달하면 수평으로 스케일링해요.

내결함성을 위해 실패 영역당 최소한 하나의 인스턴스를 실행해야 해요. 쿠버네티스 노드는 같은 실패 영역에 있는 컨트롤 플레인 엔드포인트로 트래픽을 자동으로 보내지 않지만, 클라우드 제공자는 이를 수행하는 자체 메커니즘이 있을 수 있어요.

예를 들어 관리형 로드 밸런서를 사용해 실패 영역 _A_의 kubelet과 파드에서 발생하는 트래픽을 보내도록 로드 밸런서를 구성하고, 그 트래픽을 같은 영역 _A_에 있는 컨트롤 플레인 호스트로만 보낼 수 있어요. 실패 영역 _A_의 컨트롤 플레인 호스트·엔드포인트 하나가 오프라인이 되면, 영역 _A_의 노드에 대한 모든 컨트롤 플레인 트래픽이 이제 영역 사이로 보내집니다. 각 영역에서 여러 컨트롤 플레인 호스트를 실행하면 그런 결과가 발생할 가능성이 줄어듭니다.

etcd 스토리지

대규모 클러스터의 성능을 개선하려면 Event 오브젝트를 별도의 전용 etcd 인스턴스에 저장할 수 있어요.

클러스터를 만들 때 (커스텀 도구로) 다음을 할 수 있습니다:

추가 etcd 인스턴스를 시작·구성한다.
컨트롤 플레인(kube-apiserver)이 이벤트 저장에 그 인스턴스를 사용하도록 구성한다.

대규모 클러스터의 etcd 구성·관리 방법은 쿠버네티스용 etcd 클러스터 운영하기와 kubeadm으로 고가용성 etcd 클러스터 설정하기를 참고하세요.

애드온 리소스

쿠버네티스 리소스 limit은 메모리 누수와 파드·컨테이너가 다른 구성 요소에 영향을 줄 수 있는 다른 방식의 영향을 최소화하는 데 도움을 줘요. 이 리소스 limit은 애플리케이션 워크로드에 적용되는 것과 마찬가지로 애드온 리소스에도 적용됩니다.

예를 들어 로깅 구성 요소에 CPU·메모리 limit을 설정할 수 있어요:

  ...
  containers:
  - name: fluentd-cloud-logging
    image: fluent/fluentd-kubernetes-daemonset:v1
    resources:
      limits:
        cpu: 100m
        memory: 200Mi

애드온의 기본 limit은 보통 각 애드온을 소형·중형 쿠버네티스 클러스터에서 실행한 경험으로 수집한 데이터를 기반으로 해요. 대규모 클러스터에서 실행하면 애드온이 종종 기본 limit보다 일부 리소스를 더 많이 소비합니다. 이 값을 조정하지 않고 대규모 클러스터를 배포하면 애드온이 계속 메모리 limit에 부딪혀 반복적으로 죽을 수 있어요. 또는 애드온이 CPU 시간 슬라이스 제한 때문에 성능이 낮게 실행될 수도 있습니다.

클러스터 애드온 리소스 문제를 피하려면 많은 노드를 가진 클러스터를 만들 때 다음을 고려해요:

일부 애드온은 수직으로 스케일링된다. 즉 클러스터당 또는 실패 영역 전체를 서비스하는 애드온 복제본이 하나 있다. 이런 애드온은 클러스터를 확장할 때 request와 limit을 늘린다.
많은 애드온은 수평으로 스케일링된다. 더 많은 파드를 실행해 용량을 추가하지만, 매우 큰 클러스터에서는 CPU·메모리 limit을 약간 올려야 할 수도 있다. Vertical Pod Autoscaler는 recommender 모드로 실행해 request와 limit의 제안 값을 제공할 수 있어요.
일부 애드온은 DaemonSet이 제어하는 노드당 사본 하나로 실행된다. 예를 들어 노드 레벨 로그 수집기가 그렇다. 수평 스케일링 애드온의 경우와 비슷하게 CPU·메모리 limit을 약간 올려야 할 수도 있다.

클러스터 필수 구성 요소 우선순위 지정

클러스터 필수 구성 요소(CoreDNS, metrics-server, 기타 중요한 애드온)가 다른 워크로드보다 먼저 스케줄되고 낮은 우선순위 파드에 선점되지 않도록, system-cluster-critical이나 system-node-critical 같은 시스템 PriorityClass로 실행해요.

더 알아보기 (Learn more)

VerticalPodAutoscaler는 클러스터에 배포해 파드의 리소스 request·limit을 관리하도록 돕는 커스텀 리소스예요. Vertical Pod Autoscaler와 그것으로 클러스터 중요 애드온을 포함한 클러스터 구성 요소를 스케일링하는 방법을 알아보세요.
노드 오토스케일링 읽어보기.
addon resizer는 클러스터 규모가 변함에 따라 애드온 크기를 자동으로 조정하는 데 도움을 줘요.