AKS(Azure Kubernetes Service)의 배포 및 클러스터 안정성 모범 사례

이 문서에서는 AKS(Azure Kubernetes Service) 워크로드에 대한 배포 및 클러스터 수준에서 구현된 클러스터 안정성에 대한 모범 사례를 제공합니다. 이 문서는 AKS에서 애플리케이션을 배포하고 관리하는 클러스터 운영자 및 개발자를 위한 것입니다.

이 문서의 모범 사례는 다음 범주로 구성됩니다.

범주	모범 사례
배포 수준 모범 사례	• PDB(Pod 중단 예산) • Pod CPU 및 메모리 제한 • 사전 중지 후크 • maxUnavailable • Pod 토폴로지 분산 제약 조건 • 준비 상태, 활동성 및 시작 프로브 • 다중 복제본 애플리케이션
클러스터 및 노드 풀 수준 모범 사례	• 가용성 영역 • 클러스터 자동 스케일링 • 표준 부하 분산 장치 • 시스템 노드 풀 • 가속 네트워킹 • 이미지 버전 • 동적 IP 할당을 위한 Azure CNI • v5 SKU VM • B 시리즈 VM을 사용하지 않음 • 프리미엄 디스크 • Container Insights • Azure Policy

배포 수준 모범 사례

다음 배포 수준 모범 사례는 AKS 워크로드에 대한 고가용성 및 안정성을 보장하는 데 도움이 됩니다. 이러한 모범 사례는 Pod 및 배포에 대한 YAML 파일에서 구현할 수 있는 로컬 구성입니다.

참고 항목

애플리케이션에 업데이트를 배포할 때마다 이러한 모범 사례를 구현해야 합니다. 그렇지 않은 경우 의도하지 않은 애플리케이션 가동 중지 시간과 같은 애플리케이션의 가용성 및 안정성 관련 문제가 발생할 수 있습니다.

PDB(Pod 중단 예산)

모범 사례 지침

PDB(Pod 중단 예산)를 사용하여 업그레이드 작업 또는 우발적인 Pod 삭제와 같은 자발적인 중단 동안 최소 개수의 Pod를 사용할 수 있도록 합니다.

PDB(Pod 중단 예산)를 사용하여 업그레이드 작업 또는 우발적인 Pod 삭제와 같은 자발적인 중단 동안 배포 또는 복제본 세트가 응답하는 방식을 정의할 수 있습니다. PDB를 사용하여 사용할 수 없는 최소 또는 최대 리소스 수를 정의할 수 있습니다. PDB는 자발적 중단에 대한 제거 API에만 영향을 줍니다.

예를 들어 클러스터 업그레이드를 수행해야 하며 이미 PDB가 정의되어 있다고 가정해 보겠습니다. 클러스터 업그레이드를 수행하기 전에 Kubernetes 스케줄러는 PDB에 정의된 최소 Pod 수를 사용할 수 있도록 합니다. 업그레이드로 인해 사용 가능한 Pod 수가 PDB에 정의된 최솟값보다 낮아지면 스케줄러는 업그레이드가 계속되도록 허용하기 전에 다른 노드에서 추가 Pod를 예약합니다. PDB를 설정하지 않으면 스케줄러에 업그레이드 중에 사용할 수 없는 Pod 수에 대한 제약 조건이 없으므로 리소스 부족 및 잠재적인 클러스터 가동 중단이 발생할 수 있습니다.

다음 예제 PDB 정의 파일에서 minAvailable 필드는 자발적 중단 중에 사용 가능한 상태로 유지해야 하는 최소 Pod 수를 설정합니다. 이 값은 절대 숫자(예: 3) 또는 원하는 Pod 수의 백분율(예: 10%)일 수 있습니다.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
   name: mypdb
spec:
   minAvailable: 3 # Minimum number of pods that must remain available during voluntary disruptions
   selector:
    matchLabels:
      app: myapp

자세한 내용은 PDB를 사용하여 가용성 계획 및 애플리케이션에 대한 중단 예산 지정을 참조하세요.

Pod CPU 및 메모리 제한

모범 사례 지침

모든 Pod에 대한 Pod CPU 및 메모리 제한을 설정하여 Pod가 노드의 모든 리소스를 사용하지 않도록 하고, DDoS 공격과 같은 서비스 위협 중에 보호를 제공합니다.

Pod CPU 및 메모리 제한은 Pod에서 사용할 수 있는 최대 CPU 및 메모리 크기를 정의합니다. Pod가 정의된 제한을 초과하면 제거용으로 표시됩니다. 자세한 내용은 Kubernetes의 CPU 리소스 단위 및 Kubernetes의 메모리 리소스 단위를 참조하세요.

CPU 및 메모리 제한을 설정하면 노드 상태를 유지하고 노드의 다른 Pod에 미치는 영향을 최소화할 수 있습니다. 노드에서 지원할 수 있는 것보다 높은 Pod 제한을 설정하지 마세요. 각 AKS 노드는 핵심 Kubernetes 구성 요소의 설정된 CPU 및 메모리 크기를 예약합니다. 노드에서 지원할 수 있는 것보다 높은 Pod 제한을 설정하는 경우 애플리케이션은 너무 많은 리소스를 사용하고 노드의 다른 Pod에 부정적인 영향을 주려고 할 수 있습니다. 클러스터 관리자는 리소스 요청 및 제한을 설정해야 하는 네임스페이스에서 리소스 할당량을 설정해야 합니다. 자세한 내용은 AKS에서 리소스 할당량 적용을 참조하세요.

다음 예제 Pod 정의 파일에서 resources 섹션에서는 Pod에 대한 CPU 및 메모리 제한을 설정합니다.

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 250m
        memory: 256Mi

팁

다음 예제와 같이 kubectl describe node 명령을 사용하여 노드의 CPU 및 메모리 용량을 볼 수 있습니다.

kubectl describe node <node-name>

# Example output
Capacity:
 cpu:                8
 ephemeral-storage:  129886128Ki
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             32863116Ki
 pods:               110
Allocatable:
 cpu:                7820m
 ephemeral-storage:  119703055367
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             28362636Ki
 pods:               110

자세한 내용은 컨테이너 및 Pod에 CPU 리소스 할당 및 컨테이너 및 Pod에 메모리 리소스 할당을 참조하세요.

사전 중지 후크

모범 사례 지침

해당하는 경우 사전 중지 후크를 사용하여 컨테이너의 정상적인 종료를 보장합니다.

선점, 리소스 경합 또는 활동성/시작 프로브 오류와 같은 API 요청 또는 관리 이벤트로 인해 컨테이너가 종료되기 직전에 PreStop 후크가 호출됩니다. 컨테이너가 이미 종료 또는 완료된 상태인 경우 PreStop 후크에 대한 호출이 실패하고 컨테이너를 중지하기 위한 TERM 신호가 전송되기 전에 후크가 완료되어야 합니다. Pod의 종료 유예 기간 카운트다운은 PreStop 후크가 실행되기 전에 시작되므로 컨테이너는 결과적으로 종료 유예 기간 내에 종료됩니다.

다음 예제 Pod 정의 파일은 컨테이너의 정상적인 종료를 보장하기 위해 PreStop 후크를 사용하는 방법을 보여 줍니다.

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
      preStop:
        exec:
          command: ["/bin/sh","-c","nginx -s quit; while killall -0 nginx; do sleep 1; done"]

자세한 내용은 컨테이너 수명 주기 후크 및 Pod 종료를 참조하세요.

maxUnavailable

모범 사례 지침

배포의 maxUnavailable 필드를 사용하여 롤링 업데이트 중에 사용할 수 없는 최대 Pod 수를 정의하여 업그레이드하는 동안 최소 Pod 수를 사용할 수 있도록 합니다.

maxUnavailable 필드는 업데이트 프로세스 중에 사용할 수 없는 최대 Pod 수를 지정합니다. 이 값은 절대 숫자(예: 3) 또는 원하는 Pod 수의 백분율(예: 10%)일 수 있습니다. maxUnavailable은 롤링 업데이트 중에 사용되는 삭제 API와 관련이 있습니다.

다음 예제 배포 매니페스트는 maxAvailable 필드를 사용하여 업데이트 프로세스 중에 사용할 수 없는 최대 Pod 수를 설정합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 3
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.14.2
       ports:
       - containerPort: 80
 strategy:
   type: RollingUpdate
   rollingUpdate:
     maxUnavailable: 1 # Maximum number of pods that can be unavailable during the upgrade

자세한 내용은 최대 사용 불가를 참조하세요.

Pod 토폴로지 분산 제약 조건

모범 사례 지침

Pod 토폴로지 분산 제약 조건을 사용하여 Pod가 다른 노드 또는 영역에 분산되도록 함으로써 가용성 및 안정성을 향상합니다.

Pod 토폴로지 분산 제약 조건을 사용하여 노드의 토폴로지에 따라 클러스터 전체에 Pod가 분산되는 방식을 제어하고, 여러 노드 또는 영역에 Pod를 분산하여 가용성 및 안정성을 개선할 수 있습니다.

다음 예제 Pod 정의 파일은 topologySpreadConstraints 필드를 사용하여 다른 노드에 Pod를 분산하는 방법을 보여 줍니다.

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  # Configure a topology spread constraint
  topologySpreadConstraints:
    - maxSkew: <integer>
      minDomains: <integer> # optional
      topologyKey: <string>
      whenUnsatisfiable: <string>
      labelSelector: <object>
      matchLabelKeys: <list> # optional
      nodeAffinityPolicy: [Honor|Ignore] # optional
      nodeTaintsPolicy: [Honor|Ignore] # optional

자세한 내용은 Pod 토폴로지 분산 제약 조건을 참조하세요.

준비 상태, 활동성 및 시작 프로브

모범 사례 지침

해당되는 경우 높은 부하 및 낮은 컨테이너 다시 시작에 대한 복원력을 개선하도록 준비 상태, 활동성 및 시작 프로브를 구성합니다.

준비 상태 프로브

Kubernetes에서 kubelet은 준비 상태 프로브를 사용하여 컨테이너가 트래픽 허용을 시작할 준비가 되면 알 수 있습니다. Pod는 모든 컨테이너가 준비되면 준비 완료 상태로 간주됩니다. Pod가 준비가 되지 않은 경우 서비스 부하 분산 장치에서 제거됩니다. 자세한 내용은 Kubernetes의 준비 상태 프로브를 참조하세요.

다음 예제 Pod 정의 파일은 준비 상태 프로브 구성을 보여 줍니다.

readinessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

자세한 내용은 준비 상태 프로브 구성을 참조하세요.

활동성 프로브

Kubernetes에서 kubelet은 활동성 프로브를 사용하여 컨테이너를 다시 시작해야 하는 경우를 파악합니다. 컨테이너의 활동성 프로브가 실패하면 컨테이너가 다시 시작됩니다. 자세한 내용은 Kubernetes의 활동성 프로브를 참조하세요.

다음 예제 Pod 정의 파일은 활동성 프로브 구성을 보여 줍니다.

livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy

또 다른 종류의 활동성 프로브는 HTTP GET 요청을 사용합니다. 다음 예제 Pod 정의 파일은 HTTP GET 요청 활동성 프로브 구성을 보여 줍니다.

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

자세한 내용은 활동성 프로브 구성 및 활동성 HTTP 요청 정의를 참조하세요.

시작 프로브

Kubernetes에서 kubelet은 시작 프로브를 사용하여 컨테이너 애플리케이션이 시작된 경우를 파악합니다. 시작 프로브를 구성하면 시작 프로브가 성공할 때까지 준비 상태 및 활동성 프로브가 시작되지 않으므로 준비 상태 및 활동성 프로브가 애플리케이션 시작을 방해하지 않습니다. 자세한 내용은 Kubernetes의 시작 프로브를 참조하세요.

다음 예제 Pod 정의 파일은 시작 프로브 구성을 보여 줍니다.

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

다중 복제본 애플리케이션

모범 사례 지침

노드 다운 시나리오에서 고가용성 및 복원력을 보장하기 위해 애플리케이션의 복제본을 두 개 이상 배포합니다.

Kubernetes에서 배포의 replicas 필드를 사용하여 실행하려는 Pod 수를 지정할 수 있습니다. 애플리케이션의 여러 인스턴스를 실행하면 노드 다운 시나리오에서 고가용성 및 복원력을 보장하는 데 도움이 됩니다. 가용성 영역을 사용하도록 설정하는 경우 replicas 필드를 사용하여 여러 가용성 영역에서 실행하려는 Pod 수를 지정할 수 있습니다.

다음 예제 Pod 정의 파일은 replicas 필드를 사용하여 실행하려는 Pod 수를 지정하는 방법을 보여 줍니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

자세한 내용은 AKS에 권장되는 활성-활성 고가용성 솔루션 개요 및 배포 사양의 복제본을 참조하세요.

클러스터 및 노드 풀 수준 모범 사례

다음 클러스터 및 노드 풀 수준 모범 사례는 AKS 클러스터에 대한 고가용성 및 안정성을 보장하는 데 도움이 됩니다. AKS 클러스터를 만들거나 업데이트할 때 이러한 모범 사례를 구현할 수 있습니다.

가용성 영역

모범 사례 지침

AKS 클러스터를 만들 때 여러 가용성 영역을 사용하여 영역 다운 시나리오에서 고가용성을 보장합니다. 클러스터를 만든 후에는 가용성 영역 구성을 변경할 수 없습니다.

가용성 영역은 지역 내에서 분리된 데이터 센터 그룹입니다. 이러한 영역은 서로 간에 대기 시간이 짧은 연결을 유지할 수 있을 만큼 충분히 가깝지만 둘 이상의 가용성 영역이 지역 중단이나 날씨의 영향을 받을 가능성을 줄일 수 있을 만큼 충분히 떨어져 있습니다. 가용성 영역을 사용하면 영역 다운 시나리오에서 데이터를 동기화하고 액세스할 수 있습니다. 자세한 내용은 여러 영역에서 실행을 참조하세요.

클러스터 자동 크기 조정

모범 사례 지침

클러스터 자동 스케일링을 사용하여 클러스터가 증가된 부하를 처리하고 부하가 낮은 동안 비용을 줄일 수 있도록 합니다.

AKS에서 애플리케이션 수요에 맞추려면 워크로드를 실행하는 노드 수를 조정해야 할 수 있습니다. 클러스터 자동 크기 조정기 구성 요소는 리소스 제약 조건으로 인해 예약할 수 없는 클러스터의 Pod를 감시합니다. 클러스터 자동 크기 조정기가 문제를 검색하면 애플리케이션 요구 사항에 맞게 노드 풀의 노드 수의 크기를 조정합니다. 또한 노드에서 실행 중인 Pod가 부족한지 정기적으로 확인하고 필요에 따라 노드 수의 크기를 조정합니다. 자세한 내용은 AKS의 클러스터 자동 스케일링을 참조하세요.

다음 예제와 같이 AKS 클러스터를 만들 때 --enable-cluster-autoscaler 매개 변수를 사용하여 클러스터 자동 스케일러를 사용하도록 설정할 수 있습니다.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 2 \
    --vm-set-type VirtualMachineScaleSets \
    --load-balancer-sku standard \
    --enable-cluster-autoscaler  \
    --min-count 1 \
    --max-count 3 \
    --generate-ssh-keys

클러스터 전체 자동 스케일러 프로필의 기본값을 변경하여 기존 노드에서 클러스터 자동 스케일러를 사용하도록 설정하고 클러스터 자동 스케일러를 보다 미세하게 구성할 수도 있습니다.

자세한 내용은 AKS에서 클러스터 자동 스케일러 사용을 참조하세요.

표준 Load Balancer

모범 사례 지침

표준 Load Balancer를 사용하여 더 높은 안정성과 리소스를 제공하고, 여러 데이터 센터에서 여러 가용성 영역, HTTP 프로브 및 기능을 지원합니다.

Azure에서 표준 Load Balancer SKU는 높은 성능과 짧은 대기 시간이 필요할 때 네트워크 계층 트래픽 부하를 분산하도록 설계되었습니다. 표준 Load Balancer는 높은 복원력을 위해 지역 내 및 지역 간, 그리고 가용성 영역으로 트래픽을 라우팅합니다. 표준 SKU는 AKS 클러스터를 만들 때 사용할 권장되는 기본 SKU입니다.

Important

2025년 9월 30일에 기본 Load Balancer가 사용 중지됩니다. 자세한 내용은 공식 공지를 참조하세요. 새 배포에 표준 Load Balancer를 사용하고 기존 배포를 표준 Load Balancer로 업그레이드하는 것이 좋습니다. 자세한 내용은 기본 Load Balancer에서 업그레이드를 참조하세요.

다음 예제에서는 표준 Load Balancer를 사용하는 LoadBalancer 서비스 매니페스트를 보여 줍니다.

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-ipv4 # Service annotation for an IPv4 address
  name: azure-load-balancer
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-load-balancer

자세한 내용은 AKS에서 표준 Load Balancer 사용을 참조하세요.

팁

또한 수신 컨트롤러 또는 서비스 메시를 사용하여 네트워크 트래픽을 관리할 수 있으며 각 옵션은 다양한 특성과 기능을 제공합니다.

시스템 노드 풀

전용 시스템 노드 풀 사용

모범 사례 지침

시스템 노드 풀을 사용하여 다른 사용자 애플리케이션이 동일한 노드에서 실행되지 않도록 합니다. 이러한 애플리케이션이 실행되면 리소스 부족을 유발하고 시스템 Pod에 영향을 줄 수 있습니다.

전용 시스템 노드 풀을 사용하여 동일한 노드에서 다른 사용자 애플리케이션이 실행되지 않도록 합니다. 다른 사용자 애플리케이션이 실행되면 경합 조건으로 인해 리소스가 부족하고 클러스터 가동이 중단될 수 있습니다. 전용 시스템 노드 풀을 사용하려면 시스템 노드 풀에서 CriticalAddonsOnly taint를 사용할 수 있습니다. 자세한 내용은 AKS에서 시스템 노드 풀 사용을 참조하세요.

시스템 노드 풀 자동 스케일링

모범 사례 지침

노드 풀에 대한 최소 및 최대 스케일링 제한을 설정하도록 시스템 노드 풀에 대해 자동 스케일러를 구성합니다.

노드 풀에 자동 스케일러를 사용하여 노드 풀에 대해 최소 및 최대 스케일링 제한을 구성합니다. 시스템 노드 풀은 항상 시스템 Pod의 요구에 맞게 스케일링할 수 있어야 합니다. 시스템 노드 풀을 스케일링할 수 없는 경우 클러스터의 리소스가 부족하여 일정, 스케일링 및 부하 분산을 관리하는 데 도움이 되며 이로 인해 클러스터가 응답하지 않을 수 있습니다.

자세한 내용은 노드 풀에 클러스터 자동 스케일러 사용을 참조하세요.

시스템 노드 풀당 3개 이상의 노드

모범 사례 지침

노드가 다시 시작되거나 종료되도록 할 수 있는 중지/업그레이드 시나리오에 대한 복원력을 보장하기 위해 시스템 노드 풀에 3개 이상의 노드가 있는지 확인합니다.

시스템 노드 풀은 kube-proxy, coredns 및 Azure CNI 플러그 인과 같은 시스템 Pod를 실행하는 데 사용됩니다. 노드가 다시 시작되거나 종료되도록 할 수 있는 중지/업그레이드 시나리오에 대한 복원력을 보장하기 위해 시스템 노드 풀에 3개 이상의 노드가 있는지 확인하는 것이 좋습니다. 자세한 내용은 AKS에서 시스템 노드 풀 관리를 참조하세요.

가속화된 네트워킹

모범 사례 지침

가속화된 네트워킹을 사용하여 VM에서 대기 시간을 낮추고, 지터를 줄이고, CPU 사용률을 줄입니다.

가속화된 네트워킹에서는 지원되는 VM 유형에서 단일 루트 I/O 가상화(SR-IOV)를 사용하도록 설정하여 네트워킹 성능을 크게 향상합니다.

다음 다이어그램은 가속화된 네트워킹을 사용하거나 사용하지 않고 두 VM이 통신하는 방법을 보여 줍니다.

자세한 내용은 가속화된 네트워킹 개요를 참조하세요.

이미지 버전

모범 사례 지침

이미지에는 latest 태그가 없습니다.

컨테이너 이미지 태그

컨테이너 이미지 에 latest 태그를 사용하면 예측할 수 없는 동작이 발생할 수 있으며 클러스터에서 실행 중인 이미지 버전을 추적하기가 어려울 수 있습니다. 빌드 및 런타임에 컨테이너에서 검사 및 수정 도구를 통합하고 실행하여 이러한 위험을 최소화할 수 있습니다. 자세한 내용은 AKS의 컨테이너 이미지 관리에 대한 모범 사례를 참조하세요.

노드 이미지 업그레이드

AKS는 노드 OS 이미지 업그레이드를 위한 여러 자동 업그레이드 채널을 제공합니다. 이러한 채널을 사용하여 업그레이드 시간을 제어할 수 있습니다. 노드에서 최신 보안 패치 및 업데이트를 실행하고 있는지 확인하려면 이러한 자동 업그레이드 채널을 조인하는 것이 좋습니다. 자세한 내용은 AKS에서 노드 OS 자동 업그레이드를 참조하세요.

프로덕션 워크로드에 대한 프리미엄 계층

모범 사례 지침

더 큰 클러스터 안정성 및 리소스를 위해 제품 워크로드에 표준 계층을 사용하고, 클러스터에서 최대 5,000개의 노드를 지원하고, 기본적으로 가동 시간 SLA를 사용하도록 설정합니다. LTS가 필요한 경우 프리미엄 계층을 사용하는 것이 좋습니다.

AKS(Azure Kubernetes Service)의 표준 계층은 프로덕션 워크로드에 대해 재정적으로 지원되는 99.9% 가동 시간 SLA(서비스 수준 계약)를 제공합니다. 표준 계층은 더 큰 클러스터 안정성 및 리소스를 제공하고, 클러스터에서 최대 5,000개의 노드를 지원하고, 기본적으로 가동 시간 SLA를 사용하도록 설정합니다. 자세한 내용은 AKS 클러스터 관리에 대한 가격 책정 계층을 참조하세요.

동적 IP 할당을 위한 Azure CNI

모범 사례 지침

IP 사용률을 높이고 AKS 클러스터의 IP 소모를 방지하기 위해 동적 IP 할당에 대해 Azure CNI를 구성합니다.

Azure CNI의 동적 IP 할당 기능을 사용하면 AKS 클러스터를 호스트하는 서브넷과는 별도의 서브넷의 Pod IP를 할당하고, 다음과 같은 이점을 제공합니다.

• IP 사용률 향상: IP가 Pod 서브넷에서 클러스터 Pod으로 동적으로 할당됩니다. 이로 인해 모든 노드에 대해 IP의 정적 할당을 수행하는 기존 CNI 솔루션과 비교하여 클러스터의 IP 사용률이 향상됩니다.
• 확장성 및 유연성: 노드 및 Pod 서브넷은 독립적으로 크기를 조정할 수 있습니다. 단일 Pod 서브넷은 클러스터의 여러 노드 풀에서 또는 동일한 VNet에 배포된 여러 AKS 클러스터에서 공유할 수 있습니다. 또한 노드 풀에 대해 별도의 Pod 서브넷을 구성할 수 있습니다.
• 고성능: Pod에는 가상 네트워크 IP가 할당되므로 VNet의 다른 클러스터 Pod 및 리소스에 직접 연결됩니다. 솔루션은 성능 저하 없이 매우 큰 클러스터를 지원합니다.
• Pod에 대한 별도 VNet 정책: Pod에 별도의 서브넷이 있으므로 노드 정책과 다른 별도의 VNet 정책을 구성할 수 있습니다. 이를 통해 노드가 아닌 Pod에 대해서만 인터넷 연결을 허용하고, Azure NAT Gateway를 사용하여 노드 풀에서 Pod의 원본 IP를 수정하고, NSG를 사용하여 노드 풀 간의 트래픽을 필터링하는 등의 많은 유용한 시나리오가 가능해 집니다.
• Kubernetes 네트워크 정책: Azure 네트워크 정책 및 Calico는 모두 이 솔루션으로 작동합니다.

자세한 내용은 IP의 동적 할당 및 향상된 서브넷 지원을 위해 Azure CNI 네트워킹 구성을 참조하세요.

v5 SKU VM

모범 사례 지침

v5 VM SKU를 사용하여 업데이트 도중 및 이후의 성능 향상, 전반적인 영향 감소 및 애플리케이션에 대한 보다 안정적인 연결을 보장할 수 있습니다.

AKS의 노드 풀에는 임시 OS 디스크가 있는 v5 SKU VM을 사용하여 kube 시스템 Pod에 충분한 컴퓨팅 리소스를 제공합니다. 자세한 내용은 AKS의 대규모 워크로드에 대한 성능 및 스케일링에 대한 모범 사례를 참조하세요.

B 시리즈 VM을 사용하지 않음

모범 사례 지침

B 시리즈 VM은 성능이 낮고 AKS에서 잘 작동하지 않으므로 AKS 클러스터에 사용하지 마세요.

B 시리즈 VM은 성능이 낮으며 AKS에서 잘 작동하지 않습니다. 대신 v5 SKU VM을 사용하는 것이 좋습니다.

프리미엄 디스크

모범 사례 지침

프리미엄 디스크를 사용하여 하나의 VM(가상 머신)에서 99.9%의 가용성을 달성할 수 있습니다.

Azure 프리미엄 디스크는 일관된 밀리초 이하의 디스크 대기 시간과 높은 IOPS/처리량을 제공합니다. 프리미엄 디스크는 VM에 짧은 대기 시간, 고성능 및 일관된 디스크 성능을 제공하도록 설계되었습니다.

다음 예제 YAML 매니페스트는 프리미엄 디스크에 대한 스토리지 클래스 정의 보여 줍니다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: premium2-disk-sc
parameters:
   cachingMode: None
   skuName: PremiumV2_LRS
   DiskIOPSReadWrite: "4000"
   DiskMBpsReadWrite: "1000"
provisioner: disk.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true

자세한 내용은 AKS에서 Azure Premium SSD v2 디스크 사용을 참조하세요.

컨테이너 인사이트

모범 사례 지침

Container Insights를 사용하여 컨테이너화된 애플리케이션의 성능을 모니터링하고 진단할 수 있습니다.

Container Insights는 AKS에서 컨테이너 로그를 수집하고 분석하는 Azure Monitor의 기능입니다. 뷰 컬렉션과 미리 빌드된 통합 문서를 사용하여 수집된 데이터를 분석할 수 있습니다.

다양한 방법을 사용하여 AKS 클러스터에서 Container Insights 모니터링을 사용하도록 설정할 수 있습니다. 다음 예제에서는 Azure CLI를 사용하여 기존 클러스터에서 Container Insights 모니터링을 사용하도록 설정하는 방법을 보여 줍니다.

az aks enable-addons -a monitoring --name myAKSCluster --resource-group myResourceGroup

자세한 내용은 Kubernetes 클러스터에 모니터링 사용을 참조하세요.

Azure Policy

모범 사례 지침

Azure Policy를 사용하여 AKS 클러스터에 대한 보안 및 규정 준수 요구 사항을 적용하고 집행합니다.

Azure Policy를 사용하여 AKS 클러스터에 기본 제공 보안 정책을 적용하고 집행할 수 있습니다. Azure Policy는 대규모로 조직의 표준을 적용하고 규정 준수를 평가하는 데 도움이 됩니다. AKS용 Azure Policy 추가 기능을 설치한 후 개별 정책 정의 또는 이니셔티브라는 정책 정의 그룹을 클러스터에 적용할 수 있습니다.

자세한 내용은 Azure Policy를 사용하여 AKS 클러스터 보안을 참조하세요.

다음 단계

이 문서에서는 AKS(Azure Kubernetes Service) 클러스터의 배포 및 클러스터 안정성에 대한 모범 사례를 중점적으로 살펴보았습니다. 추가 모범 사례에 대해서는 다음 문서를 참조하세요.

• AKS의 고가용성 및 재해 복구 개요
• 대규모로 AKS 클러스터 실행
• AKS 클러스터를 위한 기본 아키텍처