편집

다음을 통해 공유

Kubernetes 노드 및 노드 풀 관리

AKS(Azure Kubernetes Service)
Azure Virtual Machines

Kubernetes 아키텍처는 컨트롤 플레인과 하나 이상의 노드 풀 속의 노드라는 2개 레이어를 기반으로 합니다. 이 문서에서는 Amazon EKS(Amazon Elastic Kubernetes Service) 및 AKS(Azure Kubernetes Service)가 에이전트 또는 작업자 노드를 관리하는 방법을 설명하고 비교합니다.

참고 항목

이 문서는 Amazon EKS에 익숙한 전문가가 Azure Kubernetes Service(AKS)를 이해하는 데 도움이 되는 일련의 문서의 일부입니다.

Amazon EKS와 AKS 모두에서 클라우드 플랫폼은 컨트롤 플레인 레이어를 제공하고 관리하며, 고객은 노드 레이어를 관리합니다. 다음 다이어그램은 AKS Kubernetes 아키텍처의 컨트롤 플레인과 노드 간의 관계를 보여줍니다.

AKS 아키텍처의 컨트롤 플레인과 노드를 보여 주는 다이어그램

Amazon EKS 관리형 노드 그룹

Amazon EKS 관리형 노드 그룹은 Amazon EKS 클러스터용 Amazon EC2(Elastic Compute Cloud) 작업자 노드의 프로비저닝 및 수명 주기 관리를 자동화합니다. AWS(Amazon Web Services) 사용자는 eksctl 명령줄 유틸리티를 사용하여 EKS 클러스터용 노드를 만들거나, 업데이트하거나, 종료할 수 있습니다. 노드 업데이트 및 종료는 애플리케이션을 계속 사용할 수 있도록 자동으로 노드를 차단하고 드레이닝합니다.

모든 관리형 노드는 Amazon EKS가 운영하고 제어하는 Amazon EC2 자동 크기 조정 그룹의 일부로 프로비저닝됩니다. Kubernetes 클러스터 자동 크기 조정기는 Pod가 실패하거나 다른 노드에 다시 예약될 때 클러스터의 작업자 노드 수를 자동으로 조정합니다. 각 노드 그룹은 지역 내의 여러 가용성 영역에서 실행되도록 구성할 수 있습니다.

Amazon EKS 관리형 노드에 대한 자세한 내용은 관리형 노드 그룹 만들기 및 관리형 노드 그룹 업데이트를 참조하세요.

AWS Fargate에서 Kubernetes Pod를 실행할 수도 있습니다. Fargate는 컨테이너에 적절한 크기의 주문형 컴퓨팅 용량을 제공합니다. Amazon EKS에서 Fargate를 사용하는 방법에 대한 자세한 내용은 AWS Fargate를 참조하세요.

카르펜터 (미국)

Karpenter Kubernetes 클러스터 내에서 노드 수명 주기 관리를 향상시키기 위해 설계된 오픈 소스 프로젝트입니다. Pod의 특정 일정 요구 사항에 따라 노드 프로비저닝 및 프로비전 해제를 자동화하여 효율적인 크기 조정 및 비용 최적화를 허용합니다. 주요 함수는 다음과 같습니다.

  • 리소스 제약 조건으로 인해 Kubernetes 스케줄러가 예약할 수 없는 Pod를 모니터링합니다.
  • 예약할 수 없는 Pod의 일정 요구 사항(리소스 요청, 노드 선택기, 친화성, 내성 등)을 평가합니다.
  • 해당 Pod의 요구 사항을 충족하는 새 노드를 프로비전합니다.
  • 노드가 더 이상 필요하지 않은 경우 제거합니다.

Karpenter를 사용하면 taint, 레이블, 요구 사항(인스턴스 유형, 영역 등)과 같은 노드 프로비저닝에 대한 제약 조건과 프로비전된 총 리소스에 대한 제한을 사용하여 NodePools를 정의합니다. 워크로드를 배포할 때 리소스 요청/제한, 노드 선택기, 노드/Pod 친화, 관용 및 토폴로지 분산 제약 조건과 같은 다양한 일정 제약 조건을 Pod 사양에 지정합니다. 그런 다음 Karpenter는 이러한 사양에 따라 올바른 크기의 노드를 프로비전합니다.

Karpenter가 출시되기 전에 Amazon EKS 사용자는 주로 Amazon EC2 자동 크기 조정 그룹 및 Kubernetes CAS(클러스터 자동 크기 조정기) 의존하여 클러스터의 컴퓨팅 용량을 동적으로 조정했습니다. Karpenter에서 얻을 수 있는 유연성과 다양성을 달성하기 위해 수십 개의 노드 그룹을 만들 필요가 없습니다. Kubernetes 클러스터 자동 크기 조정기와 달리 Karpenter는 Kubernetes 버전과 긴밀하게 결합되지 않으며 AWS와 Kubernetes API 간에 이동할 필요가 없습니다.

Karpenter는 단일 시스템 내에서 인스턴스 오케스트레이션 책임을 통합하여 더 간단하고 안정적이며 클러스터를 인식합니다. Karpenter는 다음과 같은 간소화된 방법을 제공하여 클러스터 자동 크기 조정기에서 제시하는 몇 가지 문제를 해결하도록 설계되었습니다.

  • 워크로드 요구 사항에 따라 노드를 프로비전합니다.
  • 유연한 NodePool 옵션을 사용하여 인스턴스 유형별로 다양한 노드 구성을 만듭니다. Karpenter는 여러 특정 사용자 지정 노드 그룹을 관리하는 대신 유연한 단일 NodePool을 사용하여 다양한 워크로드 용량을 관리할 수 있습니다.
  • 노드를 빠르게 시작하고 Pod를 예약하여 대규모로 Pod 예약을 개선합니다.

Karpenter 사용에 대한 정보 및 설명서는 karpenter.sh 사이트를 방문하세요.

Karpenter는 ASG(자동 크기 조정 그룹 ) 및 관리 노드 그룹(MNG) 것보다 Kubernetes 네이티브 API에 더 가깝게 크기 조정 관리를 제공합니다. ASG 및 MNG는 EC2 CPU 로드와 같은 AWS 수준 메트릭에 따라 크기 조정이 트리거되는 AWS 네이티브 추상화입니다. 클러스터 자동 크기 조정기 Kubernetes 추상화는 AWS 추상화로 연결되지만 특정 가용성 영역에 대한 예약과 같이 유연성이 떨어집니다.

Karpenter는 AWS 추상화 계층을 제거하여 일부 유연성을 Kubernetes로 직접 가져옵니다. Karpenter는 수요가 많거나 수요가 많거나 다양한 컴퓨팅 요구 사항이 있는 워크로드가 있는 클러스터에 가장 적합합니다. MNG 및 ASG는 더 정적이고 일관된 경향이 있는 워크로드를 실행하는 클러스터에 적합합니다. 요구 사항에 따라 동적 및 정적으로 관리되는 노드를 혼합하여 사용할 수 있습니다.

Kata 컨테이너

Kata Containers 컨테이너의 간단한 특성과 가상 머신의 보안 이점을 결합하는 보안 컨테이너 런타임을 제공하는 오픈 소스 프로젝트입니다. 워크로드 간에 동일한 Linux 커널을 공유하는 기존 컨테이너와 달리 각 컨테이너를 다른 게스트 운영 체제로 부팅하여 더 강력한 워크로드 격리 및 보안의 필요성을 해결합니다. Kata 컨테이너는 OCI 규격 가상 머신에서 컨테이너를 실행하여 동일한 호스트 머신의 컨테이너 간에 엄격한 격리를 제공합니다. Kata 컨테이너는 다음 기능을 제공할 있습니다.

  • 향상된 워크로드 격리: 각 컨테이너는 자체 경량 VM에서 실행되어 하드웨어 수준에서 격리를 보장합니다.
  • 향상된 보안: VM 기술을 사용하면 추가 보안 계층을 제공하여 컨테이너 중단의 위험을 줄입니다.
  • 업계 표준과의 호환성: Kata Containers는 OCI 컨테이너 형식 및 Kubernetes CRI 인터페이스와 같은 업계 표준 도구와 통합됩니다.
  • 여러 아키텍처 및 하이퍼바이저지원: Kata Containers는 AMD64 및 ARM 아키텍처를 지원하며 Cloud-Hypervisor 및 폭죽과 같은 하이퍼바이저에서 사용할 수 있습니다.
  • 쉬운 배포 및 관리: Kata Containers는 Kubernetes 오케스트레이션 시스템을 활용하여 워크로드 오케스트레이션의 복잡성을 추상화합니다.

AWS 고객은 Amazon에서 개발한 오픈 소스 가상화 기술인 폭죽사용하여 안전한 다중 테넌트 컨테이너 및 함수 기반 서비스를 만들고 관리하도록 EKS(Amazon Elastic Kubernetes Service) 클러스터를 구성하여 AWS에서 Kata Containers 설정하고 실행할 수 있습니다. Firecracker를 사용하면 고객이 마이크로VM이라는 경량 가상 머신에 워크로드를 배포할 수 있으며, 이를 통해 기존 가상 머신에 비해 보안 및 워크로드 격리가 강화되고 컨테이너의 속도와 리소스 효율성이 향상됩니다. AWS EKS에서 Kata Containers를 사용하도록 설정하려면 Kata Containers사용하여 Kubernetes 워크로드 격리 및 보안 강화에 설명된 일련의 수동 단계가 필요합니다.

전용 호스트

Amazon Elastic Kubernetes Service(EKS) 사용하여 컨테이너를 배포하고 실행하는 경우 Amazon EC2 전용 호스트실행할 수 있습니다. 그러나 이 기능은 자체 관리 노드 그룹에만 사용할 수 있다는 점에 유의해야 합니다. 즉, 고객은 자동 크기 조정 그룹 시작 템플릿수동으로 만들고 EKS 클러스터에 등록해야 합니다. 이러한 리소스에 대한 생성 프로세스는 일반 EC2 자동 크기 조정과 동일합니다.

AWS EKS를 사용하여 EC2 전용 호스트에서 컨테이너를 실행하는 방법에 대한 자세한 내용은 다음 설명서를 참조하세요.

AKS 노드 및 노드 풀

AKS 클러스터를 만들면 핵심 Kubernetes 서비스 및 애플리케이션 워크로드 오케스트레이션을 제공하는 컨트롤 플레인이 자동으로 만들어지고 구성됩니다. Azure 플랫폼은 AKS 컨트롤 플레인을 관리형 Azure 리소스로 비용 없이 제공합니다. 컨트롤 플레인 및 해당 리소스는 클러스터를 만든 지역에만 있습니다.

에이전트 노드 또는 작업자 노드라고도 하는 노드가 워크로드 및 애플리케이션을 호스트합니다. AKS에서는 AKS 클러스터에 연결된 에이전트 노드를 전적으로 고객이 관리하고 비용을 지불합니다.

애플리케이션 및 지원 서비스를 실행하려면 AKS 클러스터에 하나 이상의 노드, 즉, Kubernetes 노드 구성 요소 및 컨테이너 런타임을 실행할 Azure VM(가상 머신)이 필요합니다. 모든 AKS 클러스터에는 노드가 하나 이상 있는 시스템 노드 풀이 하나 이상 포함되어야 합니다.

AKS는 구성이 동일한 노드를 AKS 워크로드를 실행하는 VM의 노드 풀로 그룹화합니다. 시스템 노드 풀의 주요 목적은 CoreDNS와 같은 중요 시스템 Pod를 호스트하는 것입니다. 사용자 노드 풀의 기본 목적은 워크로드 Pod를 호스트하는 것입니다. AKS 클러스터, 예를 들어 개발 환경에 노드 풀을 하나만 두려면 시스템 노드 풀에서 애플리케이션 Pod를 예약하면 됩니다.

단일 Kubernetes 노드를 보여 주는 다이어그램

여러 사용자 노드 풀을 만들어 워크로드를 서로 다른 노드에 분리하여 노이지 네이버 문제를 방지하거나 컴퓨팅 또는 스토리지 요구 사항이 다른 애플리케이션을 지원할 수도 있습니다.

시스템 또는 사용자 노드 풀의 모든 에이전트 노드는 Azure Virtual Machine Scale Sets의 일부로 프로비저닝되고 AKS 클러스터를 통해 관리되는 VM입니다. 자세한 내용은 노드 및 노드 풀을 참조하세요.

AKS 클러스터를 만들 때 또는 기존 AKS 클러스터에 새 노드 및 노드 풀을 추가할 때 작업자 노드의 초기 수와 크기를 정의할 수 있습니다. VM 크기를 지정하지 않으면 Windows 노드 풀의 기본 크기는 Standard_D2s_v3이고, Linux 노드 풀의 기본 크기는 Standard_DS2_v2입니다.

중요

노드 내 호출 및 플랫폼 서비스와의 통신에 더 나은 대기 시간을 제공하려면 가속화된 네트워킹을 지원하는 VM 시리즈를 선택합니다.

노드 풀 만들기

Azure Portal, Azure CLI, AKS REST API 또는 Bicep, Azure Resource Manager 템플릿 또는 Terraform과 같은 IaC(Infrastructure as Code) 도구를 사용하여 새 AKS 또는 기존 AKS 클러스터에 노드 풀을 추가할 수 있습니다. 기존 AKS 클러스터에 노드 풀을 추가하는 방법에 대한 자세한 내용은 AKS(Azure Kubernetes Service)에서 클러스터에 대한 여러 노드 풀 만들기 및 관리를 참조하세요.

새 노드 풀을 만들 때, 연결된 가상 머신 확장 집합은 AKS 클러스터에 대한 모든 인프라 리소스를 포함하는 Azure 리소스 그룹인 노드 리소스 그룹에 만들어집니다. 이러한 리소스에는 Kubernetes 노드, 가상 네트워킹 리소스, 관리 ID 및 스토리지가 포함됩니다.

기본적으로 노드 리소스 그룹에는 MC_<resourcegroupname>_<clustername>_<location>와 같은 이름이 지정됩니다. 클러스터가 삭제될 때 AKS가 노드 리소스 그룹을 자동으로 삭제하므로, 클러스터의 수명 주기를 공유하는 리소스에만 이 리소스 그룹을 사용해야 합니다.

노드 풀 추가

다음 코드 예제에서는 Azure CLI az aks nodepool add 명령을 사용하여 3개의 노드가 있는 mynodepool이라는 노드 풀을 myAKSCluster 리소스 그룹에 있는 myResourceGroup라는 기존 AKS 클러스터에 추가합니다.

az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --node-vm-size Standard_D8ds_v4 \
      --name mynodepool \
      --node-count 3

스폿 노드 풀

스폿 노드 풀은 스폿 가상 머신 확장 집합으로 지원되는 노드 풀입니다. AKS 클러스터에서 노드에 스폿 가상 머신을 사용하면 미사용 Azure 용량을 매우 저렴하게 활용할 수 있습니다. 사용 가능한 미사용 용량의 양은 노드 크기, 지역, 하루 중 시간을 비롯한 여러 요인에 따라 달라집니다.

스폿 노드 풀을 배포할 때, Azure는 사용 가능한 용량이 있는 경우 스폿 노드를 할당합니다. 그러나 스폿 노드에 대한 SLA(서비스 수준 계약)는 없습니다. 스폿 노드 풀을 백업하는 스폿 확장 집합은 단일 장애 도메인에 배포되며 고가용성 보장을 제공하지 않습니다. Azure에 다시 용량이 필요한 경우 Azure 인프라는 스폿 노드를 제거합니다. 스폿 노드를 제거하기 전에 사용자에게 최대 30초 길이의 알림이 제공됩니다. 스폿 노드 풀은 클러스터의 기본 노드 풀이 될 수 없습니다. 스폿 노드 풀은 보조 풀에만 사용할 수 있습니다.

스폿 노드는 중단, 조기 종료 또는 제거를 처리할 수 있는 워크로드에 사용됩니다. 예를 들어 일괄 처리 작업, 개발 및 테스트 환경, 대규모 컴퓨팅 워크로드는 스폿 노드 풀에 예약하기에 적합합니다. 자세한 내용은 스폿 인스턴스의 제한 사항을 참조하세요.

다음 az aks nodepool add 명령은 자동 크기 조정을 사용하도록 설정된 기존 클러스터에 스폿 노드 풀을 추가합니다.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name myspotnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --priority Spot \
      --eviction-policy Delete \
      --spot-max-price -1 \
      --enable-cluster-autoscaler \
      --min-count 1 \
      --max-count 3 \
      --no-wait

스폿 노드 풀에 대한 자세한 내용은 AKS(Azure Kubernetes Service) 클러스터에 스폿 노드 풀 추가를 참조하세요.

사용 후 삭제 OS 디스크

기본적으로 Azure는 VM을 다른 호스트로 재배치해야 할 때 데이터 손실을 방지하기 위해 VM OS(운영 체제) 디스크를 Azure Storage에 자동으로 복제합니다. 그러나 컨테이너는 로컬 상태를 유지하도록 설계되지 않았기 때문에 OS 디스크를 스토리지에 유지하면 AKS의 값이 제한됩니다. 노드 프로비저닝 속도 저하 및 읽기/쓰기 대기 시간 증가와 같은 몇 가지 단점이 있습니다.

반면 임시 OS 디스크는 임시 디스크와 같은 호스트 머신에만 저장되며, 읽기/쓰기 대기 시간이 짧고 노드 스케일링 및 클러스터 업그레이드 속도가 빠릅니다. 임시 디스크와 마찬가지로, 임시 OS 디스크는 VM 가격에 포함되어 있으므로 추가 스토리지 비용이 발생하지 않습니다.

중요

OS에 대한 관리 디스크를 명시적으로 요청하지 않으면 AKS는 지정된 노드 풀 구성에 사용 가능한 경우 임시 OS를 기본적으로 사용합니다.

임시 OS를 사용하려면 OS 디스크가 VM 캐시에 맞아야 합니다. Azure VM 설명서에는 IO 처리량 옆에 있는 괄호로 된 VM 캐시 크기가 GiB(기비바이트)의 캐시 크기로 표시됩니다.

예를 들어 기본 OS 디스크 크기가 100GB인 AKS 기본 Standard_DS2_v2 VM 크기는 임시 OS를 지원하지만 캐시 크기가 86GB에 불과합니다. 명시적으로 지정하지 않으면 기본적으로 이 구성이 관리 디스크로 설정됩니다. 이 크기에 임시 OS를 명시적으로 요청하면 유효성 검사 오류가 발생합니다.

OS 디스크가 60GB인 동일한 Standard_DS2_v2 VM을 요청하면 기본적으로 임시 OS가 제공됩니다. 요청된 60GB OS 크기는 최대 86GB 캐시 크기보다 작습니다.

OS 디스크가 100GB인 Standard_D8s_v3는 임시 OS를 지원하며 캐시 공간은 200GB입니다. 사용자가 OS 디스크 유형을 지정하지 않으면 노드 풀은 기본적으로 임시 OS를 사용합니다.

다음 az aks nodepool add 명령은 임시 OS 디스크를 사용하는 기존 클러스터에 새 노드 풀을 추가하는 방법을 보여줍니다. --node-osdisk-type 매개 변수는 OS 디스크 유형을 Ephemeral로 설정하고, --node-osdisk-size 매개 변수는 OS 디스크 크기를 정의합니다.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynewnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --node-osdisk-type Ephemeral \
      --node-osdisk-size 48

임시 OS 디스크에 대한 자세한 내용은 임시 OS를 참조하세요.

AKS(Azure Kubernetes Service)의 Virtual Machines 노드 풀

EKS 모든 관리 노드 그룹은 Amazon EKS에서 관리하는 Amazon EC2 자동 크기 조정 그룹의해 지원됩니다. 이 통합을 통해 EKS는 노드 그룹 내에서 EC2 인스턴스의 프로비전 및 크기 조정을 자동으로 처리할 수 있습니다. 자동 크기 조정 그룹은 여러 EC2 인스턴스 유형을 지원하도록 구성할 수 있지만 각 인스턴스 형식에 대해 만들거나 크기를 조정할 노드 수를 지정하는 기능은 제공하지 않습니다. 대신 EKS는 사용자가 정의한 원하는 구성 및 정책에 따라 노드 그룹의 크기 조정을 관리합니다. 이렇게 하면 노드 그룹에 대한 간소화되고 자동화된 관리 프로세스가 보장되며 워크로드 요구 사항에 맞는 EC2 인스턴스 유형을 유연하게 선택할 수 있습니다. 그러나 AWS 고객은 또는 AWS 관리 콘솔을 사용하여 eksctl 시작할 수 있습니다.

Virtual Machines 노드 풀AKS(Azure Kubernetes Service)는 각 에이전트 노드의 프로비전 및 부트스트랩을 관리합니다. Virtual Machine Scale Sets 노드 풀의 경우 AKS는 Virtual Machine Scale Sets의 모델을 관리하고 이를 사용하여 노드 풀의 모든 에이전트 노드에서 일관성을 달성합니다. 대신 Virtual Machines 노드 풀을 사용하면 개별 워크로드에 가장 적합한 가상 머신으로 클러스터를 오케스트레이션하고 각 가상 머신 크기에 대해 만들거나 크기를 조정할 노드 수를 지정할 수 있습니다.

노드 풀은 다양한 유형의 워크로드를 지원하도록 지정된 SKU(크기)가 다른 가상 머신 집합으로 구성됩니다. SKU라고 하는 이러한 가상 머신 크기는 특정 용도로 최적화된 여러 제품군으로 분류됩니다. VM SKU에 대한 자세한 내용은 VM SKU 개요참조하세요.

여러 가상 머신 크기의 크기 조정을 사용하도록 설정하기 위해 Virtual Machines 노드 풀 유형은 노드 풀 크기 조정 방법, 특히 원하는 가상 머신 크기 및 개수 목록을 구성하는 ScaleProfile 사용합니다. ManualScaleProfile 원하는 가상 머신 크기 및 수를 지정하는 확장 프로필입니다. ManualScaleProfile하나의 가상 머신 크기만 허용됩니다. 노드 풀의 각 가상 머신 크기에 대해 별도의 ManualScaleProfile 만들어야 합니다.

새 Virtual Machines 노드 풀을 만들 때 ManualScaleProfile하나 이상의 ScaleProfile 필요합니다. 단일 Virtual Machines 노드 풀에 대해 여러 수동 크기 조정 프로필을 만들 수 있습니다.

Virtual Machines 노드 풀의 이점은 다음과 같습니다.

  • 유연성: 노드 사양은 워크로드 및 요구 사항에 맞게 업데이트할 수 있습니다.
  • 미세 조정된 컨트롤: 단일 노드 수준 컨트롤을 사용하면 서로 다른 사양의 노드를 지정하고 혼합하여 일관성을 향상시킬 수 있습니다.
  • 효율성: 클러스터의 노드 공간을 줄여 운영 요구 사항을 간소화할 수 있습니다.

Virtual Machines 노드 풀은 동적 워크로드 및 고가용성 요구 사항에 대한 더 나은 환경을 제공합니다. 이를 통해 구성한 사용 가능한 리소스에서 워크로드가 자동으로 예약되어 있는 한 노드 풀에 동일한 패밀리의 여러 가상 머신을 설정할 수 있습니다.

다음 표에서는 Virtual Machines 노드 풀과 표준 확장 집합 노드 풀을 비교합니다.

노드 풀 유형 기능
Virtual Machines 노드 풀 노드 풀에서 노드를 추가, 제거 또는 업데이트할 수 있습니다. 가상 머신 유형은 동일한 패밀리 형식(예: D 시리즈, A 시리즈 등)의 모든 가상 머신일 수 있습니다.
Virtual Machine Scale Set 기반 노드 풀 노드 풀에서 동일한 크기 및 형식의 노드를 추가하거나 제거할 수 있습니다. 클러스터에 새 가상 머신 크기를 추가하는 경우 새 노드 풀을 만들어야 합니다.

가상 머신 노드 풀에는 다음과 같은 제한 사항이 있습니다.

  • 클러스터 자동 크기 조정기 지원되지 않습니다.
  • InfiniBand 사용할 수 없습니다.
  • Windows 노드 풀은 지원되지 않습니다.
  • 이 기능은 Azure Portal에서 사용할 수 없습니다. Azure CLI 또는 REST API를 사용하여 CRUD 작업을 수행하거나 풀을 관리합니다.
  • 노드 풀 스냅샷 지원되지 않습니다.
  • 노드 풀에서 선택한 모든 VM 크기는 동일한 가상 머신 패밀리에 있어야 합니다. 예를 들어 N 시리즈 가상 머신 형식을 동일한 노드 풀의 D 시리즈 가상 머신 형식과 혼합할 수 없습니다.
  • Virtual Machines 노드 풀은 노드 풀당 최대 5개의 서로 다른 가상 머신 크기를 허용합니다.

가상 노드

가상 노드를 사용하여 AKS 클러스터의 애플리케이션 워크로드를 신속하게 스케일 아웃할 수 있습니다. 가상 노드는 Pod 프로비저닝 속도가 빠르며, 실행한 시간(초)만큼만 비용을 지불하면 됩니다. 클러스터 자동 크기 조정기가 새 작업자 노드를 배포하여 더 많은 Pod 복제본을 실행할 때까지 기다릴 필요가 없습니다. 가상 노드는 Linux Pod 및 노드에서만 지원됩니다. AKS용 가상 노드 추가 항목은 오픈 소스 Virtual Kubelet 프로젝트를 기반으로 합니다.

가상 노드 기능은 Azure Container Instances에 따라 달라집니다. 가상 노드에 대한 자세한 내용은 AKS(Azure Kubernetes Service) 클러스터 만들기 및 가상 노드를 사용하도록 구성을 참조하세요.

테인트, 레이블 및 태그

노드 풀을 만들 때 Kubernetes 테인트, 레이블 및 Azure 태그를 해당 노드 풀에 추가할 수 있습니다. 테인트, 레이블 또는 태그를 추가하면 해당 노드 풀의 모든 노드에도 해당 테인트, 레이블 또는 태그가 지정됩니다.

테인트를 사용하여 노드 풀을 만들려면 az aks nodepool add 명령과 --node-taints 매개 변수를 사용하면 됩니다. 노드 풀의 노드에 레이블을 지정하려면 다음 코드와 같이 --labels 매개 변수를 사용하고 레이블 목록을 지정하면 됩니다.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mynodepool \
      --node-vm-size Standard_NC6 \
      --node-taints sku=gpu:NoSchedule \
      --labels dept=IT costcenter=9999

자세한 내용은 노드 풀에 대한 taint, 레이블 또는 태그 지정.

예약된 시스템 레이블

Amazon EKS는 용량 유형을 지정하는 eks.amazonaws.com/capacityType처럼 관리형 노드 그룹의 모든 노드에 자동화된 Kubernetes 레이블을 추가합니다. 또한 AKS는 에이전트 노드에 시스템 레이블을 자동으로 추가합니다.

다음 접두사는 AKS에 사용하도록 예약되어 있으므로 노드에 사용할 수 없습니다.

  • kubernetes.azure.com/
  • kubernetes.io/

예약된 다른 접두사는 Kubernetes의 잘 알려진 레이블, 주석 및 테인트를 참조하세요.

다음 표에는 AKS에 사용하도록 예약되어 있으므로 노드에 사용할 수 없는 레이블이 나열되어 있습니다. 이 표의 가상 노드 사용 열은 가상 노드에서 레이블 지원 여부를 지정합니다.

가상 노드 사용 열에서 다음을 수행합니다.

  • 해당 없음은 속성을 가상 노드에 적용하려면 호스트를 수정해야 하므로 적용하지 않는다는 뜻입니다.
  • 동일은 가상 노드 풀과 표준 노드 풀의 예상 값이 동일하다는 뜻입니다.
  • 가상은 VM SKU 값을 대체합니다. 가상 노드 Pod는 기본 VM을 노출하지 않기 때문입니다.
  • 가상 노드 버전은 가상 Kubelet-ACI 커넥터 릴리스의 현재 버전을 나타냅니다.
  • 가상 노드 서브넷 이름은 가상 노드 Pod를 Azure Container Instance에 배포하는 서브넷입니다.
  • 가상 노드 가상 네트워크는 가상 노드 서브넷을 포함하는 가상 네트워크입니다.
레이블 값 예제, 옵션 가상 노드 사용량
kubernetes.azure.com/agentpool <agent pool name> nodepool1 동일
kubernetes.io/arch amd64 runtime.GOARCH 해당 없음
kubernetes.io/os <OS Type> Linux 또는 Windows Linux
node.kubernetes.io/instance-type <VM size> Standard_NC6 Virtual
topology.kubernetes.io/region <Azure region> westus2 동일
topology.kubernetes.io/zone <Azure zone> 0 동일
kubernetes.azure.com/cluster <MC_RgName> MC_aks_myAKSCluster_westus2 동일
kubernetes.azure.com/mode <mode> User 또는 System User
kubernetes.azure.com/role agent Agent 동일
kubernetes.azure.com/scalesetpriority <scale set priority> Spot 또는 Regular 해당 없음
kubernetes.io/hostname <hostname> aks-nodepool-00000000-vmss000000 동일
kubernetes.azure.com/storageprofile <OS disk storage profile> Managed 해당 없음
kubernetes.azure.com/storagetier <OS disk storage tier> Premium_LRS 해당 없음
kubernetes.azure.com/instance-sku <SKU family> Standard_N Virtual
kubernetes.azure.com/node-image-version <VHD version> AKSUbuntu-1804-2020.03.05 가상 노드 버전
kubernetes.azure.com/subnet <nodepool subnet name> subnetName 가상 노드 서브넷 이름
kubernetes.azure.com/vnet <nodepool virtual network name> vnetName 가상 노드 가상 네트워크
kubernetes.azure.com/ppg <nodepool ppg name> ppgName 해당 없음
kubernetes.azure.com/encrypted-set <nodepool encrypted-set name> encrypted-set-name 해당 없음
kubernetes.azure.com/accelerator <accelerator> Nvidia 해당 없음
kubernetes.azure.com/fips_enabled <fips enabled> True 해당 없음
kubernetes.azure.com/os-sku <os/sku> OS SKU 만들기 또는 업데이트 참조 Linux SKU

Windows 노드 풀

AKS는 Azure CNI(컨테이너 네트워크 인터페이스) 네트워크 플러그 인을 통해 Windows Server 컨테이너 노드 풀을 만들고 사용할 수 있습니다. 필요한 서브넷 범위 및 네트워크 고려 사항을 계획하려면 Azure CNI 네트워킹 구성을 참조 하세요.

다음 az aks nodepool add 명령은 Windows Server 컨테이너를 실행하는 노드 풀을 추가합니다.

  az aks nodepool add \
      --resource-group myResourceGroup \
      --cluster-name myAKSCluster \
      --name mywindowsnodepool \
      --node-vm-size Standard_D8ds_v4 \
      --os-type Windows \
      --node-count 1

위의 명령은 AKS 클러스터 가상 네트워크의 기본 서브넷을 사용합니다. Windows 노드 풀을 사용하여 AKS 클러스터를 빌드하는 방법에 대한 자세한 내용은 AKS에서 Windows Server 컨테이너 만들기를 참조하세요.

노드 풀 고려 사항

노드 풀 및 여러 노드 풀을 만들고 관리할 때 적용되는 고려 사항 및 제한 사항은 다음과 같습니다.

  • 할당량, VM 크기 제한 및 지역 가용성은 AKS 노드 풀에 적용됩니다.
  • 시스템 풀에 하나 이상의 노드가 있어야 합니다. AKS 클러스터에 시스템 노드 풀을 대체할 다른 시스템 노드 풀이 있으면 시스템 노드 풀을 삭제해도 됩니다. 사용자 노드 풀은 노드를 포함할 수 없습니다.
  • 노드 풀을 만든 후에는 노드 풀의 VM 크기를 변경할 수 없습니다.
  • 노드 풀이 여러 개 있는 경우 AKS 클러스터는 표준 SKU 부하 분산 장치를 사용해야 합니다. 기본 SKU 부하 분산 장치는 여러 노드 풀을 지원하지 않습니다.
  • 모든 클러스터 노드 풀은 동일한 가상 네트워크에 있어야 하며, 노드 풀에 할당된 모든 서브넷은 동일한 가상 네트워크에 있어야 합니다.
  • 클러스터를 만들 때 여러 노드 풀을 만드는 경우 모든 노드 풀의 Kubernetes 버전이 컨트롤 플레인 버전과 일치해야 합니다. 노드별 풀 작업을 사용하여 클러스터가 프로비저닝된 후 버전을 업데이트할 수 있습니다.

노드 풀 스케일링

애플리케이션 워크로드가 변하면 노드 풀의 노드 수를 변경해야 할 수도 있습니다. az aks nodepool scale 명령을 사용하여 수동으로 노드 수를 스케일 업 또는 다운할 수 있습니다. 다음 예제에서는 mynodepool의 노드 수를 5개로 스케일링합니다.

az aks nodepool scale \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --node-count 5

클러스터 자동 크기 조정기를 사용하여 노드 풀을 자동으로 스케일링

AKS는 클러스터 자동 크기 조정기를 통해 노드 풀 자동 크기 조정을 지원합니다. 각 노드 풀에서 이 기능을 사용하도록 설정하고, 최소 및 최대 노드 수를 정의하세요.

다음 az aks nodepool add 명령은 mynodepool이라는 새 노드 풀을 기존 클러스터에 추가합니다. --enable-cluster-autoscaler 매개 변수는 새 노드 풀에서 클러스터 자동 크기 조정기를 사용하도록 설정하고, --min-count 및 --max-count 매개 변수는 풀의 최소 및 최대 노드 수를 지정합니다.

  az aks nodepool add \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --node-vm-size Standard_D8ds_v4 \
  --enable-cluster-autoscaler \
  --min-count 1 \
  --max-count 5

다음 az aks nodepool update 명령은 mynewnodepool 노드 풀의 최소 노드 수를 1에서 3으로 업데이트합니다.

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynewnodepool \
  --update-cluster-autoscaler \
  --min-count 1 \
  --max-count 3

az aks nodepool update 매개 변수를 전달하고 --disable-cluster-autoscaler 명령을 사용하여 클러스터 자동 크기 조정기를 사용하지 않도록 설정할 수 있습니다.

  az aks nodepool update \
  --resource-group myResourceGroup \
  --cluster-name myAKSCluster \
  --name mynodepool \
  --disable-cluster-autoscaler

기존 클러스터에서 클러스터 자동 크기 조정기를 다시 사용하도록 설정하려면 , az aks nodepool update및 --enable-cluster-autoscaler 매개 변수를 지정하여 --min-count사용합니다--max-count.

개별 노드 풀에 클러스터 자동 크기 조정기를 사용하는 방법에 대한 자세한 내용은 AKS(Azure Kubernetes Service)에서 애플리케이션 수요에 맞게 자동으로 클러스터 크기 조정을 참조하세요.

Pod 샌드박싱

AKS 고객은 완전히 관리되는 방식으로 AKS에서 Kata Containers 쉽게 설정 및 실행할 수 있습니다. 이는 컨테이너 애플리케이션과 컨테이너 호스트의 공유 커널 및 컴퓨팅 리소스 간에 격리 경계를 만드는 기능인 Pod Sandboxing사용하여 가능합니다.

AKS에는 컨테이너 애플리케이션과 CPU, 메모리 및 네트워킹과 같은 컨테이너 호스트의 공유 커널 및 컴퓨팅 리소스 간에 격리 경계를 제공하는 Pod Sandboxing이라는 메커니즘이 포함되어 있습니다. Pod Sandboxing은 테넌트 워크로드가 중요한 정보를 보호하고 PCI DSS(Payment Card Industry Data Security Standard), ISO(International Organization for Standardization) 27001, HIPAA(Health Insurance Portability and Accountability Act)와 같은 규제, 산업 또는 거버넌스 규정 준수 요구 사항을 충족할 수 있도록 다른 보안 조치 또는 데이터 보호 제어를 보완합니다.

별도의 클러스터 또는 노드 풀에 애플리케이션을 배포하면 서로 다른 팀 또는 고객의 테넌트 워크로드를 강력하게 격리할 수 있습니다. 여러 클러스터 및 노드 풀을 사용하는 것은 많은 조직 및 SaaS 솔루션의 격리 요구 사항에 적합할 수 있지만 공유 VM 노드 풀이 있는 단일 클러스터가 더 효율적인 시나리오가 있습니다. 예를 들어 동일한 노드에서 신뢰할 수 없는 신뢰할 수 있는 Pod를 실행하거나 동일한 노드에 DaemonSets 및 권한 있는 컨테이너를 공동 배치하여 로컬 통신 및 기능 그룹화 속도를 높이면 단일 클러스터를 사용할 수 있습니다. Pod Sandboxing 별도의 클러스터 또는 노드 풀에서 이러한 워크로드를 실행할 필요 없이 동일한 클러스터 노드에서 테넌트 애플리케이션을 강력하게 격리하는 데 도움이 될 수 있습니다. 다른 방법을 사용하려면 코드를 다시 컴파일하거나 다른 호환성 문제를 발생해야 하지만 AKS의 Pod Sandboxing은 향상된 보안 VM 경계 내에서 수정되지 않은 모든 컨테이너를 실행할 수 있습니다.

AKS의 Pod 샌드박싱은 AKS 스택용 Azure Linux 컨테이너 호스트에서 실행되는 Kata Containers 기반으로 하드웨어 적용 격리를 제공합니다. AKS의 Kata 컨테이너는 보안이 강화된 Azure 하이퍼바이저를 기반으로 합니다. 부모 VM 노드의 리소스를 활용하는 중첩된 경량 Kata VM을 통해 Pod당 격리를 달성합니다. 이 모델에서 각 Kata Pod는 중첩된 Kata 게스트 VM에서 자체 커널을 가져옵니다. 이 모델을 사용하여 부모 VM에서 컨테이너를 계속 실행하는 동안 여러 Kata 컨테이너를 단일 게스트 VM에 배치합니다. 이 모델은 공유 AKS 클러스터에서 강력한 격리 경계를 제공합니다.

자세한 내용은 다음을 참조하세요.

Azure 전용 호스트

Azure Dedicated Host 단일 Azure 구독 전용 물리적 서버를 제공하고 물리적 서버 수준에서 하드웨어 격리를 제공하는 서비스입니다. 지역, 가용성 영역 및 장애 도메인 내에서 이러한 전용 호스트를 프로비전할 수 있으며 VM을 프로비전된 호스트에 직접 배치할 수 있습니다.

AKS에서 Azure Dedicated Host를 사용하는 경우 다음과 같은 몇 가지 이점이 있습니다.

  • 하드웨어 격리는 다른 VM이 전용 호스트에 배치되지 않도록 하며, 이는 테넌트 워크로드에 대한 추가 격리 계층을 제공합니다. 전용 호스트는 동일한 데이터 센터에 배포되며 격리되지 않은 다른 호스트와 동일한 네트워크 및 기본 스토리지 인프라를 공유합니다.
  • Azure Dedicated Host는 Azure 플랫폼이 시작하는 유지 관리 이벤트를 제어합니다. 유지 관리 기간을 선택하여 서비스에 미치는 영향을 줄이고 테넌트 워크로드의 가용성 및 개인 정보를 보장할 수 있습니다.

Azure Dedicated Host는 SaaS 공급자가 테넌트 애플리케이션이 중요한 정보를 보호하기 위한 규정, 산업 및 거버넌스 규정 준수 요구 사항을 충족하도록 할 수 있습니다. 자세한 내용은 AKS 클러스터 Azure Dedicated Host 추가참조하세요.

카르펜터 (미국)

Karpenter Kubernetes용으로 빌드된 오픈 소스 노드 수명 주기 관리 프로젝트입니다. Kubernetes 클러스터에 Karpenter를 추가하면 해당 클러스터에서 워크로드를 실행하는 효율성과 비용이 향상될 수 있습니다. Karpenter는 Kubernetes 스케줄러가 예약할 수 없는 것으로 표시하는 Pod를 감시합니다. 또한 Pod 요구 사항을 충족할 수 있는 노드를 동적으로 프로비전하고 관리합니다.

Karpenter는 관리형 클러스터의 노드 프로비저닝 및 워크로드 배치에 대한 세분화된 제어를 제공합니다. 이 컨트롤은 리소스 할당을 최적화하고, 각 테넌트의 애플리케이션 간에 격리를 보장하고, 운영 비용을 줄여 다중 테넌트가 향상됩니다. AKS에서 다중 테넌트 솔루션을 빌드할 때 Karpenter는 다양한 테넌트를 지원하기 위해 다양한 애플리케이션 요구 사항을 관리하는 데 도움이 되는 유용한 기능을 제공합니다. 예를 들어 GPU 최적화 노드 풀에서 실행하려면 일부 테넌트의 애플리케이션이 필요하고 메모리 최적화 노드 풀에서 실행하려면 다른 테넌트의 애플리케이션이 필요할 수 있습니다. 애플리케이션에 스토리지 대기 시간이 짧은 경우 Karpenter를 사용하여 스토리지 및 애플리케이션 계층을 공동 배치할 수 있도록 특정 가용성 영역에서 실행되는 노드가 Pod에 필요함을 나타낼 수 있습니다.

AKS는 Karpenter를 통해 AKS 클러스터에서 노드 자동 프로비전을 사용하도록 설정합니다. 대부분의 사용자는 노드 자동 프로비전 모드를 사용하여 Karpenter를 관리되는 추가 기능으로 사용하도록 설정해야 합니다. 자세한 내용은 노드 자동 프로비전참조하세요. 고급 사용자 지정이 필요한 경우 Karpenter를 자체 호스팅하도록 선택할 수 있습니다. 자세한 내용은 AKS Karpenter 공급자 참조하세요.

기밀 VM

기밀 컴퓨팅은 소프트웨어 또는 하드웨어 지원 격리 및 암호화를 통해 사용하는 동안 데이터를 보호하기 위한 보안 조치입니다. 이 기술은 기존 접근 방식에 추가적인 보안 계층을 추가하여 미사용 데이터와 전송 중인 데이터를 보호합니다.

AWS 플랫폼은 EC2 인스턴스뿐만 아니라 Amazon EKS(Elastic Kubernetes Service)사용할 수 있는 Nitro Enclaves통해 기밀 컴퓨팅을 지원합니다. 자세한 내용은 Amazon 설명서에 이 문서를 참조하세요. 또한 Amazon EC2 인스턴스는 AMD SEV-SNP 지원합니다. 이 GitHub 리포지토리 AMD SEV-SNP 지원을 EKS용 AMI(Amazon Machine Image) 빌드하고 배포하는 아티팩트를 제공합니다.

반면, Azure는 AKS 클러스터 내에서 엄격한 격리, 개인 정보 보호 및 보안 요구 사항을 충족하는 기밀 VM을 고객에게 제공합니다. 이러한 기밀 VM은 하드웨어 기반 신뢰할 수 있는 실행 환경활용합니다. 특히 Azure 기밀 VM은 VM 메모리 및 상태에 대한 하이퍼바이저 및 기타 호스트 관리 코드 액세스를 거부하는 AMD 보안 암호화 가상화 -SEV-SNP(Secure Nested Paging) 기술을 활용합니다. 이렇게 하면 운영자 액세스에 대한 추가 방어 및 보호 계층이 추가됩니다. 자세한 내용은 AKS 클러스터 기밀 VM을 사용하는 설명서와 Azure 기밀 VM에 대한개요를 참조하세요.

FIPS(Federal Information Process Standards)

FIPS 140-3 정보 기술 제품 및 시스템의 암호화 모듈에 대한 최소 보안 요구 사항을 정의하는 미국 정부 표준입니다. AKS 노드 풀에FIPS 규정 준수를 사용하도록 설정하면 테넌트 워크로드의 격리, 개인 정보 보호 및 보안을 향상시킬 수 있습니다. FIPS 규정 준수는 암호화, 해시 및 기타 보안 관련 작업에 유효성이 검사된 암호화 모듈을 사용하도록 보장합니다. FIPS 사용 AKS 노드 풀을 사용하면 강력한 암호화 알고리즘 및 메커니즘을 사용하여 규정 및 업계 규정 준수 요구 사항을 충족할 수 있습니다. Azure는 AKS 노드 풀에 FIPS를 사용하도록 설정하는 방법에 대한 설명서를 제공하므로 다중 테넌트 AKS 환경의 보안 태세를 강화할 수 있습니다. 자세한 내용은 AKS 노드 풀에 FIPS 사용참조하세요.

호스트 기반 암호화

EKS에서 아키텍처는 데이터 보안을 강화하기 위해 다음 기능을 활용했을 수 있습니다.

  • amazon EBS 암호화 : EKS 작업자 노드에 연결된 EBS(Amazon Elastic Block Store) 볼륨에서 미사용 데이터를 암호화할 수 있습니다.
  • KMS(AWS 키 관리 서비스): AWS KMS를 사용하여 암호화 키를 관리하고 미사용 데이터의 암호화를 적용할 수 있습니다. 비밀 암호화사용하도록 설정하는 경우 고유한 AWS KMS 키를 사용하여 Kubernetes 비밀을 암호화할 수 있습니다. 자세한 내용은 기존 클러스터에서 AWS KMS를 사용하여 Kubernetes 비밀 암호화참조하세요.
  • Amazon S3 Server-Side 암호화 : EKS 애플리케이션이 Amazon S3과 상호 작용하는 경우 S3 버킷에 대한 서버 쪽 암호화를 사용하도록 설정하여 미사용 데이터를 보호할 수 있습니다.

AKS의 호스트 기반 암호화 테넌트 워크로드 격리, 개인 정보 보호 및 보안을 더욱 강화합니다. 호스트 기반 암호화를 사용하도록 설정하면 AKS는 기본 호스트 컴퓨터에서 미사용 데이터를 암호화하므로 중요한 테넌트 정보가 무단 액세스로부터 보호되도록 합니다. 임시 디스크 및 임시 OS 디스크는 엔드투엔드 암호화를 사용하도록 설정할 때 플랫폼 관리형 키를 사용하여 미사용 시 암호화됩니다.

AKS에서 OS 및 데이터 디스크는 기본적으로 플랫폼 관리형 키로 서버 쪽 암호화를 사용합니다. 이러한 디스크의 캐시는 플랫폼 관리형 키를 사용하여 미사용 시 암호화됩니다. 래핑이라고도 하는 봉투 암호화를 사용하여 데이터 보호 키 암호화하는 고유한 키 암호화 키 지정할 수 있습니다. OS 및 데이터 디스크에 대한 캐시는 지정한 BYOK 통해 암호화됩니다.

호스트 기반 암호화는 다중 테넌트 환경에 대한 보안 계층을 추가합니다. OS 및 데이터 디스크 캐시에 있는 각 테넌트의 데이터는 선택한 디스크 암호화 유형에 따라 고객 관리형 또는 플랫폼 관리형 키를 사용하여 미사용 시 암호화됩니다. 자세한 내용은 다음을 참조하세요.

업데이트 및 업그레이드

Azure는 VM 호스팅 플랫폼을 주기적으로 업데이트하여 안정성, 성능 및 보안을 개선합니다. 이러한 업데이트는 호스팅 환경의 소프트웨어 구성 요소 패치에서 네트워킹 구성 요소 업그레이드 또는 하드웨어 서비스 해제에 이르기까지 다양합니다. Azure가 VM을 업데이트하는 방법에 대한 자세한 내용은 Azure에서 가상 머신 유지 관리를 참조하세요.

인프라 업데이트를 호스트하는 VM은 일반적으로 기존 AKS 클러스터의 에이전트 노드와 같은 호스트된 VM에 영향을 주지 않습니다. 호스트된 VM에 영향을 주는 업데이트의 경우 Azure는 호스트를 업데이트하는 동안 VM을 일시 중지하거나 VM을 이미 업데이트된 호스트로 실시간 마이그레이션하여 재부팅이 필요한 상황을 최소화합니다.

업데이트 후 재부팅이 필요한 경우 적당한 시간에 업데이트를 시작할 수 있도록 Azure는 알림 및 기간을 제공합니다. 유지 관리가 긴급하지 않은 경우 일반적으로 호스트 머신의 셀프 유지 관리 기간은 35일입니다.

계획된 유지 관리를 사용하여 VM을 업데이트하고 Azure CLI, PowerShell 또는 Azure Portal을 사용하여 계획된 유지 관리 알림을 관리할 수 있습니다. 계획된 유지 관리는 사용자가 클러스터 자동 업그레이드를 사용하는지 탐지하고, 유지 관리 기간 동안 자동으로 업그레이드를 예약합니다. 계획된 유지 관리에 대한 자세한 내용은 az aks maintenanceconfiguration 명령 및 계획된 유지 관리를 사용하여 AKS(Azure Kubernetes Service) 클러스터의 유지 관리 기간 예약을 참조하세요.

Kubernetes 업그레이드

AKS 클러스터 수명 주기 동안 정기적으로 최신 Kubernetes 버전으로 업그레이드됩니다. 업그레이드를 적용하여 최신 보안 릴리스 및 기능을 받는 것이 중요합니다. 기존 노드 풀 VM의 Kubernetes 버전을 업그레이드하려면 노드를 차단 및 드레이닝하고 업데이트된 Kubernetes 디스크 이미지 기반의 새 노드로 바꿔야 합니다.

기본적으로 AKS는 하나의 추가 노드를 사용하여 서지로 업그레이드를 구성합니다. max-surge 설정의 기본값은 기존 애플리케이션을 통제하거나 드레이닝하기 전에 이전 버전 노드를 대체할 추가 노드를 만들어 워크로드 중단을 최소화합니다. 노드 풀당 max-surge 값을 사용자 지정하여 업그레이드 속도와 업그레이드 중단 간의 절충안을 허용할 수 있습니다. max-surge 값을 증가시키면 업그레이드 프로세스가 더 빠르게 완료되지만, max-surge 값이 크면 업그레이드 프로세스 중에 중단이 발생할 수 있습니다.

예를 들어 max-surge 값이 100%면 노드 수를 2배로 들려 가능한 가장 빠른 업그레이드 프로세스를 제공하지만, 노드 풀의 모든 노드가 동시에 드레이닝됩니다. 이 높은 값을 테스트 목적으로 사용할 수 있지만, 프로덕션 노드 풀은 max-surge를 33%로 설정하는 것이 더 좋습니다.

AKS는 max-surge 값으로 정수와 백분율을 모두 허용합니다. 5와 같은 정수는 서지할 5개의 추가 노드를 나타냅니다. 백분율 max-surge 값은 최소 1%부터 최대 100%까지 가능하며, 가장 가까운 노드 수로 반올림됩니다. 50%는 풀에 있는 현재 노드 수의 절반에 해당하는 서지 값을 나타냅니다.

업그레이드하는 동안 max-surge는 최소 1이고 최댓값은 노드 풀에 있는 노드 수와 같습니다. 더 큰 값을 설정할 수 있지만, max-surge에 사용되는 최대 노드 수는 풀의 노드 수보다 크지 않습니다.

중요

업그레이드 작업의 경우 요청된 max-surge 수를 처리하기에 충분한 구독이 노드 서지에 할당되어야 합니다. 예를 들어 노드 풀이 5개 있고 각 노드 풀에는 4개의 노드가 있는 클러스터의 총 노드 수는 20개입니다. 각 노드 풀의 max-surge 값이 50%인 경우 업그레이드를 완료하려면 추가 컴퓨팅 및 IP 할당량으로 10개 노드(노드 2개 x 풀 5개)가 더 필요합니다.

Azure CNI(Container Networking Interface)를 사용하는 경우 AKS의 CNI 요구 사항을 충족하기에 충분한 IP가 서브넷에 있어야 합니다.

노드 풀 업그레이드

사용 가능한 업그레이드를 확인하려면 az aks get-upgrades를 사용합니다.

az aks get-upgrades --resource-group <myResourceGroup> --name <myAKSCluster>

노드 풀의 상태를 보려면 az aks nodepool list를 사용합니다.

  az aks nodepool list -g <myResourceGroup> --cluster-name <myAKSCluster>

다음 명령은 az aks nodepool upgrade를 사용하여 단일 노드 풀을 업그레이드합니다.

  az aks nodepool upgrade \
      --resource-group <myResourceGroup> \
      --cluster-name <myAKSCluster> \
      --name <mynodepool> \
      --kubernetes-version <KUBERNETES_VERSION>

클러스터 컨트롤 플레인 및 노드 풀에 대한 Kubernetes 버전을 업그레이드하는 방법에 대한 자세한 내용은 다음을 참조하세요.

업그레이드 고려 사항

AKS 클러스터에서 Kubernetes 버전을 업그레이드하는 방법에 대한 모범 사례 및 고려 사항에 유의하세요.

  • AKS 클러스터의 모든 노드 풀을 동일한 Kubernetes 버전으로 업그레이드하는 것이 가장 좋습니다. az aks upgrade의 기본 동작은 모든 노드 풀과 컨트롤 플레인을 업그레이드하는 것입니다.

  • 수동으로 업그레이드하거나 클러스터에서 자동 업그레이드 채널을 설정합니다. 계획된 유지 관리를 사용하여 VM을 패치하는 경우 지정된 유지 관리 기간에 자동 업그레이드도 시작됩니다. 자세한 내용은 AKS(Azure Kubernetes Service) 클러스터 업그레이드를 참조하세요.

  • az aks upgrade 플래그가 있는 --control-plane-only 명령은 클러스터 컨트롤 플레인만 업그레이드하고 클러스터의 연결된 노드 풀을 변경하지 않습니다. 개별 노드 풀을 업그레이드하려면 명령에서 az aks nodepool upgrade 대상 노드 풀 및 Kubernetes 버전을 지정합니다.

  • AKS 클러스터 업그레이드는 노드의 차단 및 드레이닝을 트리거합니다. 사용 가능한 컴퓨팅 할당량이 적은 경우 업그레이드가 실패할 수 있습니다. 할당량을 늘리는 방법에 대한 자세한 내용은 지역 vCPU 할당량 늘리기를 참조하세요.

  • 정수 또는 백분율 값을 사용하여 필요한 대로 max-surge 매개 변수를 구성합니다. 프로덕션 노드 풀은 max-surge를 33%로 설정합니다. 자세한 내용은 노드 서지 업그레이드 사용자 지정을 참조하세요.

  • CNI 네트워킹을 사용하는 AKS 클러스터를 업그레이드할 때, max-surge 설정에서 만드는 추가 노드에 사용할 개인 IP 주소가 서브넷에 충분히 있어야 합니다. 자세한 내용은 AKS(Azure Kubernetes Service)에서 Azure CNI 네트워킹 구성을 참조하세요.

  • 클러스터 노드 풀이 지역 내의 여러 가용성 영역에 걸쳐 있는 경우 업그레이드 프로세스에서 일시적으로 불균형 영역 구성이 발생할 수 있습니다. 자세한 내용은 여러 가용성 영역에 걸쳐 있는 노드 풀에 대한 특별 고려 사항을 참조하세요.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

주요 작성자:

기타 기여자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계