Kubernetes 노드 및 노드 풀 관리

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

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

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를 참조하세요.

AKS 노드 및 노드 풀

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

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

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

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

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

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

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

노드 풀 만들기

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이라는 노드 풀을 myResourceGroup 리소스 그룹에 있는 myAKSCluster라는 기존 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를 사용하려면 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 클러스터의 애플리케이션 워크로드를 신속하게 스케일 아웃할 수 있습니다. 가상 노드는 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에 배포하는 서브넷입니다.
• 가상 노드 가상 네트워크는 가상 노드 서브넷을 포함하는 가상 네트워크입니다.

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

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

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

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

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

업데이트 및 업그레이드

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에 사용되는 최대 노드 수는 풀의 노드 수보다 크지 않습니다.

노드 풀 업그레이드

사용 가능한 업그레이드를 확인하려면 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(Azure Kubernetes Service) 노드 이미지 업그레이드
• 클러스터 컨트롤 플레인을 여러 노드 풀로 업그레이드

업그레이드 고려 사항

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

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

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

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

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

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

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

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

노드 가상 네트워크

새 클러스터를 만들거나 기존 클러스터에 새 노드 풀을 추가할 때, 에이전트 노드를 배포하는 클러스터 가상 네트워크 내에서 서브넷의 리소스 ID를 지정합니다. 논리적 격리를 위해 워크로드에서 클러스터의 노드를 별도의 노드 풀로 분할해야 하는 경우가 있습니다. 각각 별도의 노드 풀 전용으로 사용되는 별도의 서브넷으로 이렇게 격리할 수 있습니다. 각 노드 풀 VM은 연결된 서브넷에서 개인 IP 주소를 가져옵니다.

AKS는 다음 두 가지 네트워킹 플러그 인을 지원합니다.

• Kubenet은 Linux를 위한 간단한 기본 네트워크 플러그 인입니다. 이 kubenet경우 노드는 Azure Virtual Network 서브넷에서 개인 IP 주소를 가져옵니다. Pod는 논리적으로 다른 주소 공간에서 IP 주소를 가져옵니다. NAT(Network Address Translation)를 사용하면 원본 트래픽의 IP 주소를 노드의 기본 IP 주소로 변환하여 Pod가 Azure 가상 네트워크의 리소스에 도달할 수 있습니다. 이 방법을 사용하면 네트워크 공간에서 Pod에 대해 예약해야 하는 IP 주소의 수가 줄어듭니다.

• Azure CNI(Container Networking Interface)는 모든 Pod에 직접 호출하고 액세스할 IP 주소를 제공합니다. 이러한 IP 주소는 네트워크 공간에서 고유해야 합니다. 각 노드에는 지원하는 최대 Pod 수에 대한 구성 매개 변수가 있습니다. 그러면 노드당 동일한 IP 주소 수가 해당 노드에 대해 미리 예약됩니다. 이 방식을 사용하려면 미리 계획을 세워야 하며, 애플리케이션의 요구 사항이 증가하면 IP 주소가 소진되거나 더 큰 서브넷에서 클러스터를 다시 빌드해야 할 수 있습니다.

  새 클러스터를 만들거나 Azure CNI를 사용하는 클러스터에 새 노드 풀을 추가할 때, 노드와 Pod에 각각 하나씩 2개의 별도 서브넷의 리소스 ID를 지정할 수 있습니다. 자세한 내용은 동적 IP 할당 및 향상된 서브넷 지원을 참조하세요.

동적 IP 할당

Azure CNI를 사용하는 Pod는 호스팅 노드 풀의 서브넷에서 개인 IP 주소를 가져옵니다. Azure CNI 동적 IP 할당은 서브넷을 호스팅하는 노드 풀과 분리된 서브넷의 Pod에 개인 IP 주소를 할당할 수 있습니다. 이 기능은 다음과 같은 장점을 제공합니다.

• Pod 서브넷은 Pod에 IP를 동적으로 할당합니다. 동적 할당은 모든 노드에 고정 IP를 할당하는 기존 CNI 솔루션에 비해 클러스터의 IP 사용률이 향상됩니다.

• 노드 및 Pod 서브넷을 독립적으로 스케일링하고 공유할 수 있습니다. 동일한 가상 네트워크에 배포된 여러 노드 풀 또는 클러스터에서 단일 Pod 서브넷을 공유할 수 있습니다. 또한 노드 풀에 대해 별도의 Pod 서브넷을 구성할 수 있습니다.

• Pod는 가상 네트워크 개인 IP를 사용하므로 가상 네트워크의 다른 클러스터 Pod 및 리소스에 직접 연결됩니다. 이 기능은 대형 클러스터의 성능을 향상합니다.

• Pod에 별도의 서브넷이 있으면 노드 정책과 다른 별도의 가상 네트워크 정책을 구성할 수 있습니다. 별도의 정책을 사용하면 노드가 아닌 Pod에 대해서만 인터넷 연결을 허용하고, NAT 게이트웨이를 사용하여 노드 풀의 Pod에 대한 원본 IP를 수정하고, NSG(네트워크 보안 그룹)를 사용하여 노드 풀 간의 트래픽을 필터링하는 등 많은 유용한 시나리오를 사용할 수 있습니다.

• 네트워크 정책과 Calico Kubernetes 네트워크 정책 둘 다 동적 IP 할당을 지원합니다.

참가자

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

주요 작성자:

• Paolo Salvatori | 수석 시스템 엔지니어

기타 기여자:

• Laura Nicolas | 선임 소프트웨어 엔지니어
• Chad Kittel | 주 소프트웨어 엔지니어
• Ed Price | 선임 콘텐츠 프로그램 관리자
• Theano Petersen | 기술 작가

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

다음 단계

• Amazon EKS 전문가용 AKS
• Kubernetes ID 및 액세스 관리
• Kubernetes 모니터링 및 로깅
• Kubernetes에 대한 네트워크 액세스 보호
• Kubernetes 클러스터에 대한 스토리지 옵션
• Kubernetes에 대한 비용 관리
• 클러스터 거버넌스
• AKS(Azure Kubernetes Service) 솔루션 경험
• AKS(Azure Kubernetes Services) 2일 차 작업 가이드
• 에지 컴퓨팅 옵션에서 Kubernetes 선택
• Azure Kubernetes Service용 GitOps

관련 참고 자료

• AKS 클러스터 모범 사례
• 퍼블릭 DNS 영역을 사용하여 프라이빗 AKS 클러스터 만들기
• Terraform 및 Azure DevOps를 사용하여 프라이빗 Azure Kubernetes Service 클러스터 만들기
• Azure NAT Gateway 및 Azure Application Gateway를 사용하여 퍼블릭 또는 프라이빗 Azure Kubernetes Service 클러스터 만들기
• 프라이빗 AKS 클러스터에서 프라이빗 엔드포인트 사용
• Application Gateway 수신 컨트롤러를 사용하여 Azure Kubernetes Service 클러스터 만들기
• Kubernetes 소개
• Azure의 Kubernetes 소개
• Azure Kubernetes Service(AKS) 구현
• Kubernetes에서 애플리케이션 개발 및 배포
• AKS(Azure Kubernetes Service)에서 컴퓨팅 비용 최적화