NNetApp

Trident CSI의 리소스 requests 및 limits 구성

0
Shares
0
0
0
0 
NetApp Tech Blog에 갔다가 흥미로운 주제의 글이 보여서 AI 번역(+약간 수정)의 힘을 빌려 읽어보았습니다.
출처: https://community.netapp.com/t5/Tech-ONTAP-Blogs/Configuring-Resource-Requests-and-Limits-for-Trident-CSI/ba-p/464666

소개

파드 확장과 스토리지 요구량 변동이 심한 역동적인 Kubernetes 환경에서 효율적인 리소스 관리는 권장 사항을 넘어 필수 요소입니다. NetApp Trident™ 는 컨테이너화된 애플리케이션을 위한 영구 스토리지를 간소화하는 오픈 소스 스토리지 오케스트레이터입니다.  Trident는 Container Storage Interface (CSI)  드라이버로서 ONTAP, Amazon FSx for NetApp ONTAP( FSxN) , Google Cloud NetApp Volumes (GCNV), Azure NetApp Files( ANF ) 등 다양한 백엔드에서 볼륨 프로비저닝, 스냅샷 등을 처리합니다. 하지만 Trident처럼 강력한 도구조차도 CPU나 메모리 자원이 부족하면 제대로 작동하지 못할 수 있습니다. 바로 이 지점에서 Kubernetes 리소스 요청 및 제한이 중요한 역할을 하며, 클러스터에 과부하를 주지 않고 스토리지 작업이 원활하게 실행되도록 보장합니다.

이 게시물에서는 리소스 요청 및 제한의 기본 사항을 살펴보고  Trident 컨트롤러 및 노드 Pod 컨테이너 에 대한 리소스 요청 및 제한을 구성하는 방법을 알아보겠습니다. Helm을 통해 Trident를 배포하든 TridentOrchestrator CRD를 사용하여 사용자 정의하든,   이 기능은 성능을 향상시키고, 컨테이너 강제  퇴출을 방지하며, 비용을 최적화하는 데 도움이 됩니다. 자세히 살펴보겠습니다.

Kubernetes 리소스 requests 및 limits: 기본 사항

Kubernetes는 기본적으로 리소스 requests 및 limits을 사용하여 컨테이너/파드의 CPU 및 메모리를 할당하고 제한합니다. 이러한 설정은 파드 사양의 resources 필드에 있으며, 스케줄링 결정을 안내하고 런타임 제한을 적용하는 두 가지 역할을 합니다.

  • Requests : Requests은 Kubernetes가 노드에서 컨테이너 또는 파드에 대해 보장하는 리소스입니다. 노드에 파드의 요청을 충족할 만큼 충분한 CPU 또는 메모리 여유 공간이 없으면 파드는 대기(Pending) 상태로 유지됩니다. 스케줄러는 요청된 리소스를 보장할 수 있는 노드에만 파드를 할당하여 중요 워크로드에 대한 예측 가능한 성능을 보장합니다.
  • Limits : Limits는 컨테이너/팟이 사용할 수 있는 최대 리소스입니다.  CPU의 경우, 제한을 초과하면 커널 스로틀링(프로세스 속도 저하)이 발생합니다. 메모리의 경우, 메모리 부족(OOM) 오류가 발생하여 노드를 보호하기 위해 컨테이너가 종료될 위험이 있습니다.


리소스 유형별 차이점은 다음과 같습니다.

자원요청 동작제한 행동
CPU이는 보장되는 최소 CPU 리소스를 정의합니다.스로틀 사용 – 중단되지는 않지만 성능이 저하됩니다.
memory메모리 공간을 예약합니다. 여유 메모리가 있는 경우 Pod는 예약된 공간을 초과할 수 있습니다. 압박이 가중될 때 OOM 킬을 통해 하드 캡을 강제합니다.


설정은 간단합니다. Deployment 또는 Pod 사양에서 다음과 같은 예시를 참고하세요.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app-container
        image: nginx:1.21
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"

이렇게 하면 각 파드가 0.25 CPU와 64MB 메모리를 요청하지만 0.5 CPU 또는 128MB 메모리를 초과하지 않도록 보장합니다. 제한이 없으면 컨테이너가 이론적으로 노드 전체를 독점할 수 있으며, 이는 공유 클러스터에서 위험할 수 있습니다.

트라이던트에게 자원 관리가 중요한 이유

Trident는 컨트롤러 파드(스토리지 작업을 관리하는 단일 인스턴스)와 노드 파드(볼륨 마운트를 위해 워커 노드당 하나씩)로 배포됩니다. 이러한 파드에는 동적 프로비저닝 및 연결을 처리하는 CSI 프로비저너, 어태처, 리사이저와 같은 사이드카 컨테이너가 포함됩니다.

여기서 리소스 설정을 제대로 하지 않으면 다음과 같은 문제가 발생할 수 있습니다.

  • 스케줄링 오류 : 요청량이 적은 Pod는 노드에 배치되지 못하여 스토리지 작업이 지연될 수 있습니다.
  • 성능 병목 현상 : 과부하된 Trident Pod는 최대 I/O 시간 동안 성능 저하를 일으켜 앱 응답 속도가 느려집니다.
  • 클러스터 불안정성 : 무제한 메모리 사용은 클러스터 강제 퇴출을 유발하여 전체 워크로드의 스토리지에 장애를 일으킬 수 있습니다.

requests 및 limits을 설정함으로써 Trident의 핵심 기능(예: 볼륨 프로비저닝, 볼륨 스냅샷)을 보장하고 무단 사용을 방지할 수 있습니다. 이는 영구 볼륨에 의존하는 상태 저장 애플리케이션에 매우 중요합니다.

Trident의 기본 리소스 구성

Trident는 컨트롤러 및 노드 Pod 컨테이너 모두에 대해  적절한 기본 리소스 요청 값을 적용하는 반면, 기본 CPU 및 메모리 제한은 의도적으로 생략합니다 .

Trident의 실제 리소스 사용량은 워커 노드의 크기와  영구 볼륨 수에 따라 크게 달라집니다. 일반적인 프로덕션 환경에서 기본 제한을 너무 엄격하게 설정하면 성능이 저하되거나 Pod가 강제 종료될 수 있습니다. 따라서 Trident는 운영자에게 최대한의 유연성을 제공하기 위해 기본적으로 제한을 설정하지 않고 제공됩니다. 

리소스가 제한적이거나 엄격한 격리가 필요한 멀티테넌트 환경에서 실행할 경우, 관리자는 특정 정책 및 워크로드 특성에 맞춰 Trident 컨트롤러 및 노드 Pod에 명시적인 CPU 및 메모리 제한을 추가할 수 있으며, 추가해야 합니다.

컨트롤러 Pod 기본값

컨테이너CPU 요청메모리 요청CPU 제한메모리 제한
trident-main10m80Mi없음없음
csi-provisioner2m20Mi없음없음
csi-attacher2m20Mi없음없음
csi-resizer3m20Mi없음없음
csi-snapshotter2m20Mi없음없음
trident-autosupport1m30Mi없음없음


노드 포드 기본 설정(리눅스)

컨테이너CPU 요청메모리 요청CPU 제한메모리 제한
trident-main10m60Mi없음없음
node-driver-registrar1m10Mi없음없음

노드 포드 기본 설정(Windows)

컨테이너CPU 요청메모리 요청CPU 제한메모리 제한
trident-main10m60mi없음없음
node-driver-registrar6m40Mi없음없음
liveness-probe2m40Mi없음없음

이 기능을 사용하기 위한 필수 조건입니다.

특정 리소스 요청 및 제한 값을 사용하여 Trident 설치

Trident 컨트롤러 및 노드 파드의 개별 컨테이너에 대한 Kubernetes 리소스 요청 및 제한을 구성하려면 사용자는 다음 두 가지 방법으로 CPU 및 메모리 제약 조건을 지정할 수 있습니다.

  • 오퍼레이터 기반 배포: 사용자는 `spec.resources` 필드를 사용하여 TridentOrchestrator(TORC) 사용자 정의 리소스  정의 에서 CPU 및 메모리 제약 조건을 직접 지정할 수 있습니다 . 이를 통해 각 컨테이너의 리소스 요구 사항을 세부적으로 제어하는 ​​선언적이고 GitOps 친화적인 구성이 가능합니다.
  • Helm 기반 배포: 사용자는 설치 또는 업그레이드 중에 Helm 차트의 values.yaml 파일을 통해 또는 Helm 명령의 –set 플래그를 사용하여 컨트롤러, 노드 및 오퍼레이터 Pod 컨테이너의 리소스를 구성할 수 있습니다. 

두 방법 모두 Linux 및 Windows 노드 플랫폼에서 trident-main, CSI 사이드카(provisioner, attacher, resizer, snapshotter, registrar) 및 trident-autosupport를 포함한 모든 Trident 컨테이너에 대한 세부적인 컨테이너 수준 구성을 지원합니다. 이를 통해 리소스 계획을 개선하고 리소스 경합을 방지할 수 있습니다.

참고: 구문 분석 오류를 방지하려면 항상 정확한 컨테이너 이름과 YAML 들여쓰기를 유지해야 합니다.

예시:
  • Helm을 사용한 설치 방법: 설치 단계는 Helm을 사용한 Trident 오퍼레이터 배포 문서를
    참조하고 , values.yaml 파일에 리소스 요청 및 제한 값을 지정하거나 –set 옵션을 사용하여 리소스 요청 및 제한 값을 지정하십시오. 아래는 예시로 사용할 수 있는 values.yaml 파일의 예입니다.
resources:
  controller:
    trident-main:
      requests:
        cpu: 50m
        memory: 128Mi
      limits:
        cpu: 100m
        memory: 256Mi
    # sidecars
    csi-provisioner:
      requests:
        cpu: 20m
        memory: 50Mi
      limits:
        cpu: 40m
        memory: 100Mi 
    csi-attacher:
      requests:
        cpu: 20m
        memory: 25Mi
      limits:
        cpu: 80m
        memory: 70Mi
    csi-resizer:
      requests:
        cpu: 40m
        memory: 30Mi
      limits:
        cpu: 90m
        memory: 75Mi
    csi-snapshotter:
      requests:
        cpu: 30m
        memory: 22Mi
      limits:
        cpu: 85m
        memory: 68Mi
    trident-autosupport:
      requests:
        cpu: 20m
        memory: 35Mi
      limits:
        cpu: 60m
        memory: 130Mi
  node:
    linux:
      trident-main:
        requests:
          cpu: 75m
          memory: 100Mi
        limits:
          cpu: 150m
          memory: 200Mi
      # sidecars
      node-driver-registrar:
        requests:
          cpu: 20m
          memory: 15Mi
        limits:
          cpu: 55m
          memory: 35Mi
    windows:
      trident-main:
        requests:
          cpu: 8m
          memory: 45Mi
        limits:
          cpu: 180m
          memory: 140Mi
      # sidecars
      node-driver-registrar:
        requests:
          cpu: 30m
          memory: 45Mi
        limits:
          cpu: 90m
          memory: 135Mi
      liveness-probe:
        requests:
          cpu: 20m
          memory: 45Mi
        limits:
          cpu: 55m
          memory: 70Mi
  operator:
    requests:
      cpu: 20m
      memory: 60Mi
    limits:
      cpu: 40m
      memory: 120Mi
apiVersion: trident.netapp.io/v1
kind: TridentOrchestrator
metadata:
  name: trident
spec:
  debug: true
  namespace: trident
  windows: true
  resources:
    controller:
      trident-main:
        requests:
          cpu: 10m
          memory: 80Mi
        limits:
          cpu: 200m
          memory: 256Mi
      # sidecars
      csi-provisioner:
        requests:
          cpu: 20m
          memory: 20Mi
        limits:
          cpu: 100m
          memory: 64Mi
      csi-attacher:
        requests:
          cpu: 50m
          memory: 20Mi
        limits:
          cpu: 100m
          memory: 64Mi
      csi-resizer:
        requests:
          cpu: 30m
          memory: 20Mi
        limits:
          cpu: 100m
          memory: 64Mi
      csi-snapshotter:
        requests:
          cpu: 25m
          memory: 20Mi
        limits:
          cpu: 100m
          memory: 64Mi
      trident-autosupport:
        requests:
          cpu: 10m
          memory: 30Mi
        limits:
          cpu: 50m
          memory: 128Mi
    node:
      linux:
        trident-main:
          requests:
            cpu: 10m
            memory: 60Mi
          limits:
            cpu: 200m
            memory: 256Mi
        # sidecars
        node-driver-registrar:
          requests:
            cpu: 10m
            memory: 10Mi
          limits:
            cpu: 50m
            memory: 32Mi
      windows:
        trident-main:
          requests:
            cpu: 60m
            memory: 40Mi
          limits:
            cpu: 200m
            memory: 128Mi
        # sidecars
        node-driver-registrar:
          requests:
            cpu: 40m
            memory: 40Mi
          limits:
            cpu: 100m
            memory: 128Mi
        liveness-probe:
          requests:
            cpu: 20m
            memory: 40Mi
          limits:
            cpu: 50m
            memory: 64Mi​
  • 중요 고지 사항: 위 예시에 표시된 리소스 값은 데모 목적으로만 제공되며 NetApp의 공식 권장 사항이 아닙니다. 실제 리소스 요구 사항은 클러스터 크기, 영구 볼륨 수, I/O 워크로드 강도, 백엔드 유형, 스냅샷 또는 자동 지원과 같은 기능 사용 여부에 따라 크게 달라집니다. 테스트 또는 스테이징 환경에서 kubectl top, Prometheus 또는 유사한 도구를 사용하여 Trident Pod를 항상 모니터링하고 실제 사용량에 맞춰 요청 및 제한을 조정하십시오.

배포 후에는 `kubectl describe torc trident -n trident` 명령어를 사용하여 리소스 값을 확인 하고 `status.currentInstallationParams.resources`를 확인할 수 있습니다  .

설치 후 리소스 요청 및 제한 업데이트

사용자는 컨트롤러 또는 노드 파드 컨테이너의 CPU 및 메모리 요청 또는 제한 값을 조정해야 할 필요가 있을 수 있습니다. 이러한 리소스를 업데이트하는 방법은 Trident를 Trident Operator(TridentOrchestrator CR) 또는 Helm을  사용하여 설치했는지 에 따라 다릅니다.

Trident Operator, 즉 TridentOrchestrator(TORC) CRD를 통해 Trident를 설치한 경우, 사용자는  kubectl edit 명령을 실행한 다음 spec.resources 섹션을 새 값으로 수정하거나 kubectl patch 명령을 통해 리소스 값을 업데이트할 수 있습니다.

Helm을 통해 설치한 경우,  Helm 차트의 values ​​파일에서 CPU 및 메모리 값을 업데이트한 후 helm upgrade 명령을 사용하거나 `–set` 플래그를 직접 사용하여 업그레이드하십시오.

참고: 리소스 요청 또는 제한을 변경하면 Trident 컨트롤러 및 노드 Pod가 롤링 재시작될 수 있다는 점에 유의하십시오.

모범 사례 및 일반적인 함정

Kubernetes 경험을 바탕으로 Trident를 제대로 구축하는 방법은 다음과 같습니다.

해야할 것들

  • 모니터링 및 반복 : Prometheus 또는 kubectl top과 같은 도구를 사용하여 사용량을 분석하고, 이를 바탕으로 값을 조정하십시오.
  • 스테이징 환경에서 테스트 : 메모리 부족으로 인한 종료 없이 한계를 검증하기 위해 부하를 시뮬레이션합니다.

하지 말아야 할 것들

  • 과도한 요청: 이는 용량을 낭비합니다. Trident는 경량 시스템이므로 실제 필요한 용량 이상으로 용량을 늘리지 않도록 주의해야 합니다.

마무리: 조정, 배포, 번영

리소스 요청 및 제한은 Kubernetes Trident를 위한 만능 도구와 같아서 잠재적인 혼란을 제어된 효율성으로 바꿔줍니다. 기본 사항을 이해하고, 기본 설정을 활용하고, 신중하게 사용자 지정하면 부하가 걸린 상황에서도 원활한 스토리지 오케스트레이션을 보장할 수 있습니다.

최적화할 준비가 되셨나요? Trident Helm 차트 또는 CRD를 가져와 리소스를 조정하고 배포하세요. 클러스터와 애플리케이션이 만족할 것입니다. 

Kubernetes 리소스에 대한 자세한 내용은 K8s 공식 문서를 참조하세요 . Trident 설정 세부 정보는 NetApp Trident 가이드 에서 확인할 수 있습니다 .

프리랜서 강사로 Red Hat, NetApp 솔루션에 대한 입문을 돕고 있습니다.

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

— Previous article

FCP 프로토콜을 사용하는 Kubernetes 블록 스토리지를 위한 NetApp ASA r2 시스템의 잠재력을 최대한 활용하기 

Next article —

NFSv4.1을 활용한 중앙 사용자 관리: SAP 워크로드의 성능 및 유연성 향상

You May Also Like
Read More
  • 27 minute read
NNetApp

SnapMirror active sync and the active-active data center

NetApp Tech Blog에 갔다가 흥미로운 주제의 글이 보여서 AI 번역(+약간 수정)의 힘을 빌려 읽어보았습니다. 출처: https://community.netapp.com/t5/Tech-ONTAP-Blogs/SnapMirror-active-sync-and-the-active-active-data-center/ba-p/455156 SnapMirror 액티브…
Read More
  • 2 minute read
NNetApp

What is NVMe?

NVMe, NVMe-oF, NVMe/FC 및 NVMe/TCP 정의 NVMe(NonVolatile Memory Express)는 모든 유형의 기업 워크로드에 대해 최고의 처리량과 가장 빠른…