Share via

AKS(Azure Kubernetes Service)의 중소 워크로드에 대한 성능 및 크기 조정 모범 사례

  • 아티클

참고 항목

이 문서에서는 중소 규모 워크로드에 대한 일반적인 모범 사례에 중점을 둡니다. 대규모 워크로드와 관련된 모범 사례는 AKS(Azure Kubernetes Service)의 대규모 워크로드에 대한 성능 및 크기 조정 모범 사례를 참조하세요.

AKS에서 클러스터를 배포하고 유지 관리하는 경우 다음 모범 사례를 사용하여 성능 및 크기 조정을 최적화할 수 있습니다.

이 문서에서는 다음에 대해 알아봅니다.

  • 워크로드 자동 크기 조정을 위한 절충 및 권장 사항입니다.
  • 워크로드 요구에 따라 노드 크기 조정 및 효율성 관리
  • 수신 및 송신 트래픽에 대한 네트워킹 고려 사항입니다.
  • 제어 평면 및 노드 성능 모니터링 및 문제 해결
  • 용량 계획, 서지 시나리오 및 클러스터 업그레이드.
  • 데이터 평면 성능에 대한 스토리지 및 네트워킹 고려 사항.

애플리케이션 자동 크기 조정 및 인프라 자동 크기 조정

애플리케이션 자동 크기 조정

애플리케이션 자동 크기 조정은 비용 최적화 또는 인프라 제한 사항을 처리할 때 유용합니다. 잘 구성된 자동 크기 조정기는 비용을 최소화하면서 애플리케이션에 대한 고가용성을 유지합니다. 수요에 관계없이 가용성을 유지하는 데 필요한 리소스에 대해서만 비용을 지불합니다.

예를 들어 기존 노드에 공간이 있지만 서브넷에 IP가 충분하지 않은 경우 새 노드 생성을 건너뛰고 대신 새 Pod에서 애플리케이션 실행을 즉시 시작할 수 있습니다.

Horizontal Pod 자동 크기 조정

수평 Pod 자동 크기 조정을 구현하는 것은 안정적이고 예측 가능한 리소스 수요가 있는 애플리케이션에 유용합니다. HPA(Horizontal Pod Autoscaler)는 Pod 복제본 수를 동적으로 확장하여 여러 Pod 및 노드에 부하를 효과적으로 분산합니다. 이 크기 조정 메커니즘은 일반적으로 병렬로 실행할 수 있는 더 작고 독립적인 구성 요소로 분해할 수 있는 애플리케이션에 가장 유용합니다.

HPA는 기본적으로 리소스 사용률 메트릭을 제공합니다. 사용자 지정 메트릭을 통합하거나 Kubernetes KEDA(Event-Driven Autoscaler)(미리 보기)와 같은 도구를 활용할 수도 있습니다. 이러한 확장을 통해 HPA는 여러 관점 및 기준에 따라 크기 조정 결정을 내릴 수 있으므로 애플리케이션의 성능을 보다 전체적으로 볼 수 있습니다. 이는 복잡한 크기 조정 요구 사항이 다양한 애플리케이션에 특히 유용합니다.

참고 항목

애플리케이션의 고가용성을 유지하는 것이 최우선 순위인 경우 확장 시간을 고려하여 HPA의 최소 Pod 수에 대해 약간 더 높은 버퍼를 남겨 두는 것이 좋습니다.

Vertical Pod 자동 크기 조정

수직 Pod 자동 크기 조정을 구현하는 것은 변동이 심하고 예측할 수 없는 리소스 수요가 있는 애플리케이션에 유용합니다. VPA(Vertical Pod Autoscaler)를 사용하면 개별 Pod에 대한 CPU 및 메모리를 포함한 리소스 요청을 미세 조정하여 리소스 할당을 정밀하게 제어할 수 있습니다. 이 세분성은 리소스 낭비를 최소화하고 클러스터 사용률의 전반적인 효율성을 향상시킵니다. 또한 VPA는 리소스 할당을 자동화하고 중요한 작업에 대한 리소스를 확보하여 애플리케이션 관리를 간소화합니다.

Warning

동일한 CPU 또는 메모리 메트릭에서 HPA와 함께 VPA를 사용하면 안 됩니다. 두 자동 크기 조정기 모두 동일한 메트릭을 사용하여 수요 변화에 대응하려고 시도하므로 이 조합으로 인해 충돌이 발생할 수 있습니다. 그러나 CPU 또는 메모리용 VPA를 사용자 지정 메트릭용 HPA와 함께 사용하여 중복을 방지하고 각 자동 확장 처리가 워크로드 확장의 고유한 측면에 집중하도록 할 수 있습니다.

참고 항목

VPA는 기록 데이터를 기반으로 작동합니다. 권장 사항 데이터를 수집할 시간을 주기 위해 변경 내용을 적용하기 전에 VPA를 배포한 후 최소 24시간을 기다리는 것이 좋습니다.

인프라 자동 크기 조정

클러스터 자동 크기 조정

클러스터 자동 크기 조정 구현은 새 노드를 확장하고 프로비전하는 데 도움이 되므로 기존 노드에 충분한 용량이 부족한 경우에 유용합니다.

클러스터 자동 크기 조정을 고려할 때 노드를 제거할 시기를 결정하는 데는 리소스 사용률 최적화와 리소스 가용성 보장 간의 절충이 포함됩니다. 사용률이 저조한 노드를 제거하면 클러스터 사용률이 향상되지만 새 워크로드에서 리소스가 프로비전될 때까지 기다려야 배포할 수 있습니다. 클러스터 및 워크로드 요구 사항에 맞는 이러한 두 요소 간의 균형을 찾고 그에 따라 클러스터 자동 크기 조정기 프로필 설정을 구성하는 것이 중요합니다.

클러스터 자동 크기 조정기 프로필 설정은 클러스터의 모든 자동 크기 조정기 사용 노드 풀에 보편적으로 적용됩니다. 즉, 한 자동 크기 조정기 사용 노드 풀에서 발생하는 모든 크기 조정 작업이 다른 노드 풀의 자동 크기 조정 동작에 영향을 미칠 수 있습니다. 자동 크기 조정기가 예상대로 동작하도록 모든 관련 노드 풀에 일관되고 동기화된 프로필 설정을 적용하는 것이 중요합니다.

오버프로비전

오버프로비전은 쉽게 사용할 수 있는 리소스가 초과되도록 하여 애플리케이션 압력의 위험을 완화하는 데 도움이 되는 전략입니다. 이 방법은 자주 스케일 업 및 스케일 다운을 표시하는 매우 가변적인 부하 및 클러스터 크기 조정 패턴을 경험하는 애플리케이션에 특히 유용합니다.

최적의 오버프로비전 양을 확인하려면 다음 수식을 사용할 수 있습니다.

1-buffer/1+traffic

예를 들어 클러스터에서 100% CPU 사용률에 도달하는 것을 방지하려는 경우를 가정해 보겠습니다. 안전 마진을 유지하기 위해 30% 버퍼를 선택할 수 있습니다. 평균 트래픽 증가율이 40%로 예상되는 경우 수식에서 계산한 대로 50%까지 오버프로비전하는 것을 고려할 수 있습니다.

1-30%/1+40%=50%

효과적인 오버프로비전 방법에는 일시 중지 Pod를 사용하는 것이 포함됩니다. 일시 중지 Pod는 우선 순위가 높은 배포로 쉽게 대체할 수 있는 우선 순위가 낮은 배포입니다. 버퍼 공간을 예약하는 유일한 목적을 제공하는 낮은 우선 순위 Pod를 만듭니다. 우선 순위가 높은 Pod에 공간이 필요한 경우 우선 순위가 높은 Pod를 수용하기 위해 일시 중지 Pod가 제거되고 다른 노드 또는 새 노드에서 다시 예약됩니다.

다음 YAML은 Pod 매니페스트 일시 중지 예제를 보여줍니다.

apiVersion: scheduling.k8s.io/v1 
kind: PriorityClass 
metadata: 
  name: overprovisioning 
value: -1 
globalDefault: false 
description: "Priority class used by overprovisioning." 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: overprovisioning 
  namespace: kube-system 
spec: 
  replicas: 1 
  selector: 
    matchLabels: 
      run: overprovisioning 
  template: 
    metadata: 
      labels: 
        run: overprovisioning 
    spec: 
      priorityClassName: overprovisioning 
      containers: 
      - name: reserve-resources 
        image: your-custome-pause-image 
        resources: 
          requests: 
            cpu: 1 
            memory: 4Gi

노드 크기 조정 및 효율성

모범 사례 지침:

리소스 사용률 및 예약 정책을 주의 깊게 모니터링하여 노드가 효율적으로 사용되고 있는지 확인합니다.

노드 크기 조정을 사용하면 워크로드 요구에 따라 클러스터의 노드 수를 동적으로 조정할 수 있습니다. 클러스터에 노드를 더 추가하는 것이 항상 성능 향상을 위한 최상의 솔루션은 아님을 이해하는 것이 중요합니다. 최적의 성능을 보장하려면 리소스 사용률 및 예약 정책을 주의 깊게 모니터링하여 노드가 효율적으로 사용되고 있는지 확인해야 합니다.

노드 이미지

모범 사례 지침:

최신 노드 이미지 버전을 사용하여 최신 보안 패치 및 버그 수정이 있는지 확인합니다.

최신 노드 이미지 버전을 사용하면 최상의 성능 환경을 제공합니다. AKS는 주간 이미지 릴리스 내에서 성능 향상을 제공합니다. 최신 디먼셋 이미지는 노드 프로비저닝 및 부트스트래핑에 더 낮은 대기 시간 이점을 제공하는 최신 VHD 이미지에 캐시됩니다. 업데이트에서 뒤처지는 것은 성능에 부정적인 영향을 미칠 수 있으므로 버전 간의 큰 격차를 피하는 것이 중요합니다.

Azure Linux

AKS의 Azure Linux 컨테이너 호스트는 네이티브 AKS 이미지를 사용하며 Linux 개발을 위한 단일 위치를 제공합니다. 모든 패키지는 원본에서 빌드되고 유효성이 검사되어 입증된 구성 요소에서 서비스가 실행되도록 합니다.

Azure Linux는 컨테이너 워크로드를 실행하는 데 필요한 패키지 집합만 포함하는 경량입니다. Mariner는 공격 표면을 줄이고 불필요한 패키지의 패치 및 유지 관리를 제거합니다. 기본 계층에는 Azure에 맞게 조정된 Microsoft 강화 커널이 있습니다. 이 이미지는 성능에 민감한 워크로드 및 AKS 클러스터의 플릿을 관리하는 플랫폼 엔지니어 또는 운영자에게 적합합니다.

Ubuntu 2204

Ubuntu 2204 이미지는 AKS의 기본 노드 이미지입니다. 컨테이너화된 워크로드를 실행하기 위해 최적화된 가볍고 효율적인 운영 체제입니다. 즉, 리소스 사용량을 줄이고 전반적인 성능을 향상시키는 데 도움이 될 수 있습니다. 이 이미지에는 워크로드가 취약성으로부터 보호되는 데 도움이 되는 최신 보안 패치 및 업데이트가 포함되어 있습니다.

Ubuntu 2204 이미지는 Microsoft, Canonical 및 Ubuntu 커뮤니티에서 완벽하게 지원되며 컨테이너화된 워크로드의 성능과 보안을 향상하는 데 도움이 될 수 있습니다.

VM(가상 컴퓨터)

모범 사례 지침:

VM을 선택할 때 OS 디스크 및 VM SKU의 크기와 성능이 크게 불일치하지 않는지 확인합니다. 크기 또는 성능이 불일치하면 성능 문제 및 리소스 경합이 발생할 수 있습니다.

애플리케이션 성능은 워크로드에서 사용하는 VM SKU와 밀접한 관련이 있습니다. 더 크고 강력한 VM은 일반적으로 더 나은 성능을 제공합니다. 중요 업무용 또는 제품 워크로드의 경우 8코어 CPU 이상의 VM을 사용하는 것이 좋습니다. v4 및 v5와 같은 최신 하드웨어 세대의 VM도 성능을 향상시키는 데 도움이 될 수 있습니다. 대기 시간 만들기 및 크기 조정은 사용하는 VM SKU에 따라 달라질 수 있습니다.

전용 시스템 노드 풀 사용

성능 및 안정성을 조정하려면 전용 시스템 노드 풀을 사용하는 것이 좋습니다. 이 구성을 사용하면 전용 시스템 노드 풀은 시스템 OS 디먼과 같은 중요한 시스템 리소스에 대한 공간을 예약합니다. 그러면 애플리케이션 워크로드가 사용자 노드 풀에서 실행되어 애플리케이션에 할당 가능한 리소스의 가용성을 높일 수 있습니다. 또한 이 구성은 시스템과 애플리케이션 간의 리소스 경쟁 위험을 완화하는 데 도움이 됩니다.

작업 만들기

프로비저닝을 만드는 동안 사용하도록 설정한 확장 및 추가 기능을 검토합니다. 확장 및 추가 기능은 만들기 작업의 전체 기간에 대기 시간을 추가할 수 있습니다. 확장 또는 추가 기능이 필요하지 않은 경우 이를 제거하여 생성 대기 시간을 개선하는 것이 좋습니다.

가용성 영역을 사용하여 잠재적인 하드웨어 오류 또는 계획된 유지 관리 이벤트로부터 보호하기 위해 더 높은 수준의 가용성을 제공할 수도 있습니다. AKS 클러스터는 기본 Azure 인프라의 논리 섹션에 리소스를 배포합니다. 가용성 영역은 단일 오류가 애플리케이션의 가용성에 영향을 주지 않도록 하기 위해 노드를 다른 노드와 물리적으로 분리합니다. 가용성 영역은 특정 영역에서만 사용할 수 있습니다. 자세한 내용은 Azure의 가용성 영역을 참조하세요.

Kubernetes API 서버

LIST 및 WATCH 작업

Kubernetes는 LIST 및 WATCH 작업을 사용하여 Kubernetes API 서버와 상호 작용하고 클러스터 리소스에 대한 정보를 모니터링합니다. 이러한 작업은 Kubernetes가 리소스 관리를 수행하는 방식의 기본 사항입니다.

LIST 작업은 특정 네임스페이스의 모든 Pod 또는 클러스터의 모든 서비스와 같은 특정 기준에 맞는 리소스 목록을 검색합니다. 이 작업은 클러스터 리소스에 대한 개요를 살펴보거나 여러 리소스에 대해 한 번에 연산해야 하는 경우에 유용합니다.

LIST 작업은 특히 여러 리소스가 있는 큰 클러스터에서 많은 양의 데이터를 검색할 수 있습니다. 무제한이거나 빈번한 LIST 호출은 API 서버에 상당한 부하를 가하고 응답 시간을 단축할 수 있다는 사실에 유의해야 합니다.

WATCH 작업은 실시간 리소스 모니터링을 수행합니다. 리소스에 WATCH를 설정하면 API 서버는 해당 리소스에 변경 내용이 있을 때마다 업데이트를 보냅니다. 이는 WATCH를 사용하여 원하는 리소스 상태를 유지하는 ReplicaSet 컨트롤러와 같은 컨트롤러에 중요합니다.

변경 가능한 리소스를 너무 많이 감시하거나 동시 WATCH 요청을 너무 많이 만들면 API 서버에 과부하가 걸리고 과도한 리소스 소비가 발생할 수 있습니다.

잠재적인 문제를 방지하고 Kubernetes 컨트롤 플레인의 안정성을 보장하려면 다음 전략을 사용할 수 있습니다.

리소스 할당량

과도한 호출을 방지하기 위해 특정 사용자 또는 네임스페이스가 나열하거나 감시할 수 있는 리소스 수를 제한하도록 리소스 할당량을 구현합니다.

API 우선 순위 및 공정성

Kubernetes는 API 요청의 우선 순위를 지정하고 관리하는 APF(API 우선 순위 및 공정성)의 개념을 도입했습니다. Kubernetes에서 APF를 사용하여 클러스터의 API 서버를 보호하고 클라이언트 애플리케이션에서 볼 수 있는 HTTP 429 Too Many Requests 응답 수를 줄일 수 있습니다.

사용자 지정 리소스 주요 특징
PriorityLevelConfigurations • API 요청에 대해 다른 우선 순위 수준을 정의합니다.
• 고유한 이름을 지정하고 우선 순위 수준을 나타내는 정수 값을 할당합니다. 우선 순위 수준이 높을수록 정수 값이 낮아 더 중요함을 나타냅니다.
• 요청을 중요도에 따라 여러 우선 순위 수준으로 분류하는 데 여러 가지 용도로 사용할 수 있습니다.
• 특정 우선 순위 수준의 요청에 속도 제한이 적용되는지 여부를 지정할 수 있습니다.
FlowSchemas • 요청 특성에 따라 API 요청을 다른 우선 순위 수준으로 라우팅하는 방법을 정의합니다.
• API 그룹, 버전 및 리소스와 같은 조건에 따라 요청과 일치하는 규칙을 지정합니다.
• 요청이 지정된 규칙과 일치하면 요청은 연결된 PriorityLevelConfiguration에 지정된 우선 순위 수준으로 전달됩니다.
• 여러 FlowSchemas가 요청과 일치하여 특정 규칙이 우선하도록 하는 경우 평가 순서를 설정하는 데 사용할 수 있습니다.

PriorityLevelConfigurations 및 FlowSchemas를 사용하여 API를 구성하면 덜 중요한 요청보다 중요한 API 요청의 우선 순위를 설정할 수 있습니다. 이렇게 하면 우선 순위가 낮은 요청으로 인해 필수 작업이 굶주리거나 지연되지 않습니다.

레이블 지정 및 선택기 최적화

LIST 작업을 사용하는 경우 레이블 선택기를 최적화하여 쿼리하려는 리소스의 범위를 좁혀 반환되는 데이터의 양과 API 서버의 로드를 줄입니다.

Kubernetes CREATE 및 UPDATE 작업에서는 클러스터 리소스를 관리하고 수정하는 작업을 참조합니다.

CREATE 및 UPDATE 작업

CREATE 작업은 Kubernetes 클러스터에 Pod, 서비스, 배포, 구성맵 및 비밀과 같은 새 리소스를 만듭니다. CREATE 작업 중에 클라이언트(예: kubectl 또는 컨트롤러)는 Kubernetes API 서버에 요청을 보내 새 리소스를 생성합니다. API 서버는 요청의 유효성을 검사하고, 허용 컨트롤러 정책을 준수한 다음, 클러스터의 원하는 상태로 리소스를 만듭니다.

UPDATE 작업은 복제본 수, 컨테이너 이미지, 환경 변수 또는 레이블과 같은 리소스 사양 변경을 포함하여 Kubernetes 클러스터의 기존 리소스를 수정합니다. UPDATE 작업 중에 클라이언트는 API 서버에 요청을 보내 기존 리소스를 업데이트합니다. API 서버는 요청의 유효성을 검사하고, 변경 내용을 리소스 정의에 적용하고, 클러스터 리소스를 업데이트합니다.

CREATE 및 UPDATE 작업은 다음 조건에서 Kubernetes API 서버의 성능에 영향을 미칠 수 있습니다.

  • 높은 동시성: 여러 사용자 또는 애플리케이션이 동시 CREATE 또는 UPDATE 요청을 수행하면 동시에 서버에 도착하는 API 요청이 급증할 수 있습니다. 이로 인해 API 서버의 처리 용량이 강조되고 성능 문제가 발생할 수 있습니다.
  • 복잡한 리소스 정의: 지나치게 복잡하거나 여러 개의 중첩된 개체가 포함된 리소스 정의는 API 서버가 CREATE 및 UPDATE 요청의 유효성을 검사하고 처리하는 데 걸리는 시간을 늘려 성능 저하를 초래할 수 있습니다.
  • 리소스 유효성 검사 및 허용 제어: Kubernetes는 들어오는 CREATE 및 UPDATE 요청에 대해 다양한 허용 제어 정책 및 유효성 검사를 적용합니다. 광범위한 주석 또는 구성을 사용하는 것과 같은 대규모 리소스 정의에는 더 많은 처리 시간이 필요할 수 있습니다.
  • 사용자 지정 컨트롤러: 배포 또는 StatefulSet 컨트롤러와 같은 리소스의 변경 내용을 감시하는 사용자 지정 컨트롤러는 변경 내용을 확장하거나 롤아웃할 때 상당한 수의 업데이트를 생성할 수 있습니다. 이러한 업데이트는 API 서버의 리소스에 부담을 줄 수 있습니다.

자세한 내용은 AKS에서 API 서버 및 etcd 문제 해결을 참조하세요.

데이터 평면 성능

Kubernetes 데이터 평면은 컨테이너와 서비스 간의 네트워크 트래픽을 관리합니다. 데이터 평면과 관련된 문제로 인해 응답 시간이 느려지고 성능이 저하되고 애플리케이션 가동 중지 시간이 발생할 수 있습니다. 네트워크 지연 시간, 리소스 할당, 컨테이너 밀도 및 네트워크 정책과 같은 데이터 플레인 구성을 신중하게 모니터링하고 최적화하여 컨테이너화된 애플리케이션이 원활하고 효율적으로 실행되도록 하는 것이 중요합니다.

저장소 유형

AKS는 임시 OS 디스크를 사용하는 것이 좋습니다. 임시 OS 디스크는 로컬 VM 스토리지에 만들어지고 관리되는 OS 디스크와 같은 원격 Azure Storage에 저장되지 않습니다. 이미지 다시 설치 및 부팅 시간이 빨라 클러스터 작업이 더 빨라지고 AKS 에이전트 노드의 OS 디스크에서 읽기/쓰기 대기 시간이 짧아집니다. 임시 OS 디스크는 애플리케이션이 개별 VM 오류를 허용하지만 VM 배포 시간 또는 개별 VM 이미지로 다시 설치 인스턴스를 허용하지 않는 상태 비저장 워크로드에 적합합니다. 특정 VM SKU만 임시 OS 디스크를 지원하므로 원하는 SKU 생성 및 크기가 호환되는지 확인해야 합니다. 자세한 내용은 AKS(Azure Kubernetes Service)의 임시 OS 디스크를 참조하세요.

워크로드가 임시 OS 디스크를 사용할 수 없는 경우 AKS는 기본적으로 프리미엄 SSD OS 디스크를 사용합니다. 프리미엄 SSD OS 디스크가 워크로드와 호환되지 않는 경우 AKS는 기본적으로 표준 SSD 디스크로 설정됩니다. 현재 사용 가능한 다른 OS 디스크 유형은 표준 HDD뿐입니다. 자세한 내용은 AKS(Azure Kubernetes Service)의 스토리지 옵션을 참조하세요.

다음 표에서는 AKS에서 지원되는 OS 디스크에 대해 제안된 사용 사례를 분석하여 제공합니다.

OS 디스크 유형 주요 특징 제안된 사용 사례
임시 OS 디스크 • 이미지 재이미징 및 부팅 시간이 빨라집니다.
• AKS 에이전트 노드의 OS 디스크에서 읽기/쓰기 대기 시간을 낮춥니다.
• 고성능 및 가용성.		 • SQL Server, Oracle, Dynamics, Exchange Server, MySQL, Cassandra, MongoDB, SAP Business Suite 등과 같은 수요가 높은 엔터프라이즈 워크로드
• 고가용성과 짧은 대기 시간이 필요한 상태 비저장 프로덕션 워크로드.
프리미엄 SSD OS 디스크 • 일관된 성능 및 짧은 대기 시간.
• 고가용성.		 • SQL Server, Oracle, Dynamics, Exchange Server, MySQL, Cassandra, MongoDB, SAP Business Suite 등과 같은 수요가 높은 엔터프라이즈 워크로드
• IO(입출력) 집약적인 엔터프라이즈 워크로드.
표준 SSD OS 디스크 • 일관된 성능.
• 표준 HDD 디스크에 비해 가용성 및 대기 시간이 향상되었습니다.		 • 웹 서버.
• IOPS(초당 낮은 입력/출력 작업) 애플리케이션 서버
• 가볍게 사용되는 엔터프라이즈 애플리케이션.
• 개발/테스트 워크로드.
표준 HDD 디스크 • 저렴한 비용.
• 성능 및 대기 시간의 가변성을 보여 줍니다.		 • 백업 스토리지.
• 자주 액세스하지 않는 대량 스토리지.

IOPS 및 처리량

IOPS(초당 입력/출력 작업)는 디스크가 1초 안에 수행할 수 있는 읽기 및 쓰기 작업 수를 나타냅니다. 처리량은 지정된 기간 동안 전송할 수 있는 데이터의 양을 나타냅니다.

OS 디스크는 운영 체제 및 관련 파일을 저장해야 하며 VM은 애플리케이션 실행을 담당합니다. VM을 선택할 때 OS 디스크 및 VM SKU의 크기와 성능이 크게 불일치하지 않는지 확인합니다. 크기 또는 성능이 불일치하면 성능 문제 및 리소스 경합이 발생할 수 있습니다. 예를 들어 OS 디스크가 VM보다 훨씬 작은 경우 애플리케이션 데이터에 사용할 수 있는 공간의 양을 제한하고 시스템에서 디스크 공간이 부족해질 수 있습니다. OS 디스크의 성능이 VM보다 낮으면 병목 상태가 되어 시스템의 전반적인 성능을 제한할 수 있습니다. Kubernetes에서 최적의 성능을 보장하기 위해 크기와 성능이 균형잡힌지 확인합니다.

다음 단계를 사용하여 Azure Portal의 OS 디스크에서 IOPS 및 대역폭 미터를 모니터링할 수 있습니다.

  1. Azure Portal로 이동합니다.
  2. 가상 머신 확장 집합을 검색하고 가상 머신 확장 집합을 선택합니다.
  3. 모니터링에서 메트릭을 선택합니다.

임시 OS 디스크는 애플리케이션에 동적 IOPS 및 처리량을 제공할 수 있는 반면 관리 디스크는 IOPS 및 처리량을 제한했습니다. 자세한 내용은 Azure VM용 임시 OS 디스크를 참조하세요.

Azure 프리미엄 SSD v2는 디스크 대기 시간이 밀리초 미만이고 낮은 비용에 높은 IOPS 및 처리량이 필요한 IO 집약적인 엔터프라이즈 워크로드용으로 설계되었습니다. SQL Server, Oracle, MariaDB, SAP, Cassandra, MongoDB, 빅 데이터/분석, 게임 등과 같은 광범위한 워크로드에 적합합니다. 이 디스크 유형은 현재 영구 볼륨에 사용할 수 있는 성능이 가장 높은 옵션입니다.

Pod 예약

VM에 할당된 메모리 및 CPU 리소스는 VM에서 실행되는 Pod의 성능에 직접적인 영향을 줍니다. Pod를 만들면 애플리케이션을 실행하는 데 사용되는 특정 양의 메모리 및 CPU 리소스가 할당됩니다. VM에 사용 가능한 메모리 또는 CPU 리소스가 충분하지 않은 경우 Pod의 속도가 느려지거나 충돌할 수 있습니다. VM에 사용 가능한 메모리 또는 CPU 리소스가 너무 많은 경우 Pod가 비효율적으로 실행되어 리소스를 낭비하고 비용이 증가할 수 있습니다. 최상의 예약 예측 가능성 및 성능을 위해 할당 가능한 총 리소스에 대해 워크로드 전체의 총 Pod 요청을 모니터링하는 것이 좋습니다. --max-pods을(를) 사용하여 용량 계획에 따라 노드당 최대 Pod를 설정할 수도 있습니다.