Kubernetes 아키텍처는 컨트롤 플레 인과 노드 풀의 노드 하나 이상의 두 계층으로 구성됩니다. 이 문서에서는 Amazon Elastic Kubernetes Service(EKS) 및 AKS(Azure Kubernetes Service)가 에이전트 노드 및 작업자 노드를 관리하는 방법을 설명하고 비교합니다.
비고
이 문서는 Amazon EKS에 익숙한 전문가가 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가 실패하거나 다른 노드에 다시 예약될 때 클러스터의 작업자 노드 수를 자동으로 조정합니다. 지역 내의 여러 가용성 영역에서 실행되도록 각 노드 그룹을 구성할 수 있습니다.
자세한 내용은 관리되는 노드 그룹 만들기 및 관리되는 노드 그룹 업데이트를 참조하세요.
AWS Fargate에서 Kubernetes Pod를 실행할 수도 있습니다. Fargate는 컨테이너에 적절한 크기의 주문형 컴퓨팅 용량을 제공합니다. 자세한 내용은 컴퓨팅 관리 간소화를 참조하세요.
카르펜터 (미국)
Karpenter 는 Kubernetes 클러스터 내에서 노드 수명 주기 관리를 개선하는 데 도움이 되는 오픈 소스 프로젝트입니다. Pod의 특정 일정 요구 사항에 따라 노드의 프로비저닝 및 프로비전 해제를 자동화하여 크기 조정 및 비용 최적화를 개선합니다. 다음 주요 함수에 Karpenter를 사용합니다.
리소스 제약 조건으로 인해 Kubernetes 스케줄러가 예약할 수 없는 Pod를 모니터링합니다.
스케줄링 불가능한 포드의 리소스 요청, 노드 선택자, 친화성, 관용성과 같은 스케줄링 요구 사항을 평가합니다.
예약할 수 없는 Pod의 요구 사항을 충족할 수 있는 새 노드를 설정합니다.
노드가 더 이상 필요하지 않은 경우 노드를 제거합니다.
Karpenter를 사용하여 taint, 레이블, 요구 사항(인스턴스 유형 및 영역) 및 프로비전된 총 리소스에 대한 제한과 같은 노드 프로비저닝에 제약 조건이 있는 노드 풀을 정의할 수 있습니다. 워크로드를 배포할 때 Pod 사양에 다양한 일정 제약 조건을 지정합니다. 예를 들어, 리소스 요청 또는 제한, 노드 선택기, 노드 또는 Pod 선호도, 관용, 그리고 토폴로지 확산 제한을 지정할 수 있습니다. 그런 다음 Karpenter는 이러한 사양에 따라 올바른 크기의 노드를 구성합니다.
Karpenter가 출시되기 전에 Amazon EKS 사용자는 주로 Amazon EC2 자동 크기 조정 그룹과Kubernetes 클러스터 자동 크기 조정기를 사용하여 클러스터의 컴퓨팅 용량을 동적으로 조정했습니다. Karpenter가 제공하는 유연성과 다양성을 달성하기 위해 수십 개의 노드 그룹을 만들 필요가 없습니다. Kubernetes 클러스터 자동 크기 조정기와 달리 Karpenter는 Kubernetes 버전에 덜 의존하며 AWS와 Kubernetes API 간의 전환이 필요하지 않습니다.
Karpenter는 단일 시스템 내에서 인스턴스 오케스트레이션 책임을 통합하므로 더 간단하고 안정적이며 클러스터를 더 잘 인식할 수 있습니다. Karpenter는 다음과 같은 간소화된 방법을 제공하여 클러스터 자동 크기 조정기의 문제를 해결하는 데 도움이 됩니다.
워크로드 요구 사항에 따라 노드를 구성합니다.
유연한 노드 풀 옵션을 사용하여 인스턴스 유형별로 다양한 노드 구성을 만듭니다. 몇 가지 특정 사용자 지정 노드 그룹을 관리하는 대신 Karpenter를 사용하여 유연한 단일 노드 풀을 사용하여 다양한 워크로드 용량을 관리합니다.
노드를 빠르게 시작하고 Pod를 예약하여 대규모로 Pod 예약을 개선합니다.
자동 크기 조정 그룹 및 관리 노드 그룹에 비해 Karpenter는 Kubernetes 네이티브 API와 크기 조정 관리를 더 긴밀하게 통합합니다. 자동 크기 조정 그룹 및 관리 노드 그룹은 EC2 CPU 로드와 같은 AWS 수준 메트릭에 따라 크기 조정을 트리거하는 AWS 네이티브 추상화입니다. 클러스터 자동 크기 조정기는 Kubernetes 추상화와 AWS 추상화에 연결되지만 특정 가용성 영역 예약과 같은 유연성을 희생합니다.
Karpenter는 KUbernetes 내에서 직접 더 큰 유연성을 제공하는 AWS 관련 구성 요소를 제거하여 노드 관리를 간소화합니다. 수요가 많고 급격하게 변동하거나 다양한 컴퓨팅 요구 사항이 있는 워크로드를 실행하는 클러스터에는 Karpenter를 사용합니다. 더 정적이고 일관된 워크로드를 실행하는 클러스터에 대해 관리되는 노드 그룹 및 자동 크기 조정 그룹을 사용합니다. 요구 사항에 따라 동적 및 정적으로 관리되는 노드의 조합을 사용할 수 있습니다.
Kata 컨테이너
Kata Containers 는 매우 안전한 컨테이너 런타임을 제공하는 오픈 소스 프로젝트입니다. 컨테이너의 간단한 특성과 VM(가상 머신)의 보안 이점을 결합합니다. Kata Containers는 워크로드 간에 동일한 Linux 커널을 공유하는 기존 컨테이너와 달리 다른 게스트 운영 체제로 각 컨테이너를 시작하여 워크로드 격리 및 보안을 향상시킵니다. Kata Containers는 동일한 호스트 컴퓨터의 컨테이너 간에 엄격한 격리를 제공하는 OCI(Open Container Initiative) 규격 VM에서 컨테이너를 실행합니다. Kata 컨테이너는 다음과 같은 기능을 제공합니다.
향상된 워크로드 격리: 각 컨테이너는 자체 경량 VM에서 실행되어 하드웨어 수준에서 격리를 보장합니다.
향상된 보안: VM 기술을 사용하면 컨테이너 중단의 위험을 줄이는 추가 보안 계층을 제공합니다.
업계 표준과의 호환성: Kata Containers는 OCI 컨테이너 형식 및 Kubernetes 컨테이너 런타임 인터페이스와 같은 업계 표준 도구와 통합됩니다.
여러 아키텍처 및 하이퍼바이저에 대한 지원: Kata Containers는 AMD64 및 ARM 아키텍처를 지원하며 클라우드 하이퍼바이저 및 폭죽과 같은 하이퍼바이저에서 사용할 수 있습니다.
쉬운 배포 및 관리: Kata Containers는 Kubernetes 오케스트레이션 시스템을 사용하기 때문에 워크로드 오케스트레이션을 간소화합니다.
AWS에서 Kata Containers를 설정하고 실행하려면 Firecracker를 사용하도록 Amazon EKS 클러스터를 구성합니다. Firecracker는 Amazon의 오픈 소스 가상화 기술로, 안전한 다중 테넌트 컨테이너 기반 및 함수 기반 서비스를 만들고 관리하는 데 도움이 됩니다. Firecracker를 사용하여 기존 VM에 비해 향상된 보안 및 워크로드 격리를 제공하는 microVM이라는 경량 VM에 워크로드를 배포합니다. 마이크로VM은 컨테이너의 속도와 리소스 효율성도 향상시킵니다. 단계에 따라 AWS EKS에서 Kata Containers를 실행합니다.
전용 호스트
Amazon EKS를 사용하여 컨테이너를 배포하고 실행하는 경우 Amazon EC2 전용 호스트에서 컨테이너를 실행할 수 있습니다. 그러나 이 기능은 자체 관리 노드 그룹에만 사용할 수 있습니다. 따라서 시작 템플릿 및 자동 크기 조정 그룹을 수동으로 만들어야 합니다. 그런 다음 EKS 클러스터에 전용 호스트, 시작 템플릿 및 자동 크기 조정 그룹을 등록합니다. 이러한 리소스를 만들려면 일반 EC2 자동 크기 조정과 동일한 방법을 사용합니다.
AWS EKS를 사용하여 EC2 전용 호스트에서 컨테이너를 실행하는 방법에 대한 자세한 내용은 다음 리소스를 참조하세요.
- Amazon EKS 노드
- 전용 호스트 제한 사항
- 전용 호스트 할당
- 전용 호스트 예약 구매
- 자동 배치
AKS 노드 및 노드 풀
AKS 클러스터를 자동으로 만들 때 핵심 Kubernetes 서비스 및 애플리케이션 워크로드 오케스트레이션을 제공하는 컨트롤 플레인을 만들고 구성합니다. Azure 플랫폼은 관리되는 Azure 리소스로 AKS 컨트롤 플레인을 비용 없이 제공합니다. 컨트롤 플레인 및 해당 리소스는 클러스터를 만드는 지역에만 존재합니다.
에이전트 노드 또는 작업자 노드라고도 하는 노드가 워크로드 및 애플리케이션을 호스트합니다. AKS에서는 AKS 클러스터에 연결된 에이전트 노드를 완전히 관리하고 비용을 지불합니다.
애플리케이션 및 지원 서비스를 실행하려면 AKS 클러스터에 Kubernetes 노드 구성 요소 및 컨테이너 런타임을 실행하는 Azure VM인 노드가 하나 이상 필요합니다. 모든 AKS 클러스터에는 하나 이상의 노드가 있는 하나 이상의 시스템 노드 풀 이 포함되어야 합니다.
AKS는 동일한 구성의 노드를 AKS 워크로드를 실행하는 VM의 노드 풀로 결합합니다. 시스템 노드 풀을 사용하여 CoreDNS와 같은 중요한 시스템 Pod를 호스트합니다. 사용자 노드 풀을 사용하여 워크로드 파드를 호스팅합니다. 예를 들어 개발 환경과 같이 AKS 클러스터에서 하나의 노드 풀만 원하는 경우 시스템 노드 풀에서 애플리케이션 Pod를 예약할 수 있습니다.
여러 사용자 노드 풀을 만들어 서로 다른 노드에서 다른 워크로드를 분리할 수도 있습니다. 이 방법은 시끄러운 인접 문제를 방지하고 컴퓨팅 또는 스토리지 요구 사항이 다른 애플리케이션을 지원합니다.
시스템 또는 사용자 노드 풀 내의 모든 에이전트 노드는 기본적으로 VM입니다. Azure Virtual Machine Scale Sets 는 VM을 구성하고 AKS 클러스터는 VM을 관리합니다. 자세한 내용은 노드 풀을 참조하세요.
AKS 클러스터를 만들거나 기존 AKS 클러스터에 새 노드 및 노드 풀을 추가할 때 작업자 노드의 초기 수와 크기를 정의할 수 있습니다. VM 크기를 지정하지 않으면 Windows 노드 풀의 기본 크기는 Standard_D2s_v3이고, Linux 노드 풀의 기본 크기는 Standard_DS2_v2입니다.
중요합니다
내부 노드 호출 및 플랫폼 서비스와의 통신에 더 나은 대기 시간을 제공하려면 가속화된 네트워킹을 지원하는 VM 시리즈를 선택합니다.
노드 풀 만들기
새 노드 풀을 만들 때 연결된 가상 머신 확장 집합이 노드 리소스 그룹에 만들어집니다. 이 Azure 리소스 그룹에 는 AKS 클러스터에 대한 모든 인프라 리소스가 포함됩니다. 이러한 리소스에는 Kubernetes 노드, 가상 네트워킹 리소스, 관리 ID 및 스토리지가 포함됩니다.
기본적으로 노드 리소스 그룹에는 MC_<resourcegroupname>_<clustername>_<location>와 같은 이름이 지정됩니다. AKS는 클러스터를 삭제할 때 노드 리소스 그룹을 자동으로 삭제합니다. 클러스터의 수명 주기를 공유하는 리소스에 대해서만 이 리소스 그룹을 사용해야 합니다.
자세한 내용은 AKS에서 클러스터에 대한 노드 풀 만들기를 참조하세요.
노드 풀 추가
새 AKS 클러스터 또는 기존 AKS 클러스터에 노드 풀을 추가하려면 Azure Portal, Azure CLI 또는 AKS REST API를 사용합니다. Bicep, Azure Resource Manager 템플릿 또는 Terraform과 같은 IaC(코드) 도구로 인프라를 사용할 수도 있습니다.
다음 코드 예제에서는 Azure CLI az aks nodepool add 명령을 사용하여 3개의 노드가 있는 노드 풀을 mynodepool 추가합니다. 기존 AKS 클러스터 myAKSCluster에 노드 풀이 myResourceGroup 리소스 그룹에 추가됩니다.
az aks nodepool add \
--resource-group myResourceGroup \
--cluster-name myAKSCluster \
--node-vm-size Standard_D8ds_v4 \
--name mynodepool \
--node-count 3
스폿 노드 풀
스폿 노드 풀은 스폿 가상 머신 확장 집합 이 지원하는 노드 풀입니다. AKS 클러스터의 노드에 스폿 VM을 사용하여 사용되지 않는 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 클러스터에 스폿 노드 풀 추가를 참조하세요.
임시 OS 디스크
기본적으로 Azure는 VM OS 디스크를 Azure Storage에 자동으로 복제합니다. 이 방법은 VM을 다른 호스트로 재배치해야 하는 경우 데이터 손실을 방지합니다. 그러나 컨테이너는 로컬 상태를 유지하도록 설계되지 않았으므로 AZURE Storage에 OS 디스크를 저장하면 AKS에 대한 제한된 이점이 제공됩니다. 이 방법을 사용하면 노드 프로비저닝 속도가 느려지고 읽기 및 쓰기 대기 시간이 증가할 수 있습니다.
반면 임시 OS 디스크는 임시 디스크와 같이 호스트 컴퓨터에만 저장됩니다. 또한 읽기 및 쓰기 대기 시간이 짧고 노드 크기 조정 및 클러스터 업그레이드가 더 빨라집니다. 임시 디스크와 마찬가지로 VM 가격에는 임시 OS 디스크가 포함되어 있으므로 추가 스토리지 비용이 발생하지 않습니다.
중요합니다
OS에 대한 관리 디스크를 명시적으로 요청하지 않으면 AKS는 지정된 노드 풀 구성에 사용 가능한 경우 임시 OS를 기본적으로 사용합니다.
임시 OS를 사용하려면 OS 디스크가 VM 캐시에 맞아야 합니다. Azure VM 설명서에는 입력/출력(I/O) 처리량 옆에 괄호 안에 GiB(기비바이트) 단위의 VM 캐시 크기로 표시됩니다.
예를 들어 기본 100GB OS 디스크 크기의 AKS 기본 Standard_DS2_v2 VM 크기는 임시 OS를 지원하지만 캐시 크기는 86GB에 불과합니다. 달리 명시적으로 지정하지 않으면 이 구성은 기본적으로 관리 디스크로 설정됩니다. 이 크기에 임시 OS를 명시적으로 요청하면 유효성 검사 오류가 발생합니다.
OS 디스크가 60GB인 동일한 Standard_DS2_v2 VM을 요청하면 기본적으로 임시 OS가 제공됩니다. 요청된 60GB OS 크기는 최대 86GB 캐시 크기보다 작습니다.
100GB OS 디스크가 있는 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 디스크를 참조하세요.
AKS의 Azure Virtual Machines 노드 풀
EKS의 모든 관리 노드 그룹은 Amazon EKS에서 관리하는 Amazon EC2 자동 크기 조정 그룹에 의해 지원됩니다. 이 통합을 통해 EKS는 노드 그룹 내에서 EC2 인스턴스를 자동으로 구성하고 크기를 조정할 수 있습니다.
여러 EC2 인스턴스 유형을 지원하도록 자동 크기 조정 그룹을 구성할 수 있지만 각 인스턴스 유형에 대해 만들거나 크기를 조정할 노드 수를 지정할 수는 없습니다. 대신 EKS는 원하는 구성 및 정책에 따라 노드 그룹의 크기 조정을 관리합니다. 이 방법은 워크로드 요구 사항에 맞는 EC2 인스턴스 유형을 선택할 수 있도록 노드 그룹에 대한 관리 프로세스를 간소화하고 자동화합니다. 명령줄 도구 또는 AWS 관리 콘솔을 사용하여 eksctl를 시작할 수도 있습니다.
Azure Virtual Machines 노드 풀의 경우 AKS는 각 에이전트 노드를 구성하고 부트스트랩합니다. Azure Virtual Machine Scale Sets 노드 풀의 경우 AKS는 Virtual Machine Scale Sets의 모델을 관리하고 이를 사용하여 노드 풀의 모든 에이전트 노드에서 일관성을 달성합니다. Virtual Machines 노드 풀을 사용하여 개별 워크로드에 가장 적합한 VM으로 클러스터를 오케스트레이션할 수 있습니다. 각 VM 크기에 대해 만들거나 크기를 조정할 노드 수를 지정할 수도 있습니다.
노드 풀은 크기가 다른 VM 집합으로 구성됩니다. 각 VM은 다른 유형의 워크로드를 지원합니다. SKU라고 하는 이러한 VM 크기는 특정 용도로 최적화된 여러 제품군으로 분류됩니다. 자세한 내용은 Azure의 VM 크기를 참조하세요.
여러 VM 크기의 스케일링을 활성화하기 위해 Virtual Machines 노드 풀 유형은 ScaleProfile을 사용합니다. 이 프로필은 원하는 VM 크기 및 수를 지정하여 노드 풀의 크기를 조정하는 방법을 구성합니다. A ManualScaleProfile 는 원하는 VM 크기 및 개수를 지정하는 배율 프로필입니다. 에 하나의 VM 크기만 허용됩니다 ManualScaleProfile. 노드 풀의 각 VM 크기에 대해 별도의 ManualScaleProfile 항목을 만들어야 합니다.
새 Virtual Machines 노드 풀을 만들 때는 ManualScaleProfile에 최소한 ScaleProfile 하나가 필요합니다. 단일 Virtual Machines 노드 풀에 대한 여러 수동 확장 프로필을 만들 수 있습니다.
Virtual Machines 노드 풀의 이점은 다음과 같습니다.
융통성: 워크로드 및 요구 사항에 맞게 노드 사양을 업데이트할 수 있습니다.
미세 조정된 컨트롤: 단일 노드 수준 컨트롤은 서로 다른 사양의 노드를 지정하고 결합하여 일관성을 향상시키는 데 도움이 됩니다.
능률: 운영 요구 사항을 간소화하기 위해 클러스터의 노드 공간을 줄일 수 있습니다.
Virtual Machines 노드 풀은 동적 워크로드 및 고가용성 요구 사항에 대한 더 나은 환경을 제공합니다. 이를 사용하여 한 노드 풀에서 동일한 제품군의 여러 VM을 설정할 수 있으며, 구성한 사용 가능한 리소스에서 워크로드가 자동으로 예약됩니다.
다음 표에서는 Virtual Machines 노드 풀과 표준 Virtual Machine Scale Sets 노드 풀을 비교합니다.
| 노드 풀 유형 | 역량 |
|---|---|
| 가상 머신 노드 풀 | 노드 풀에서 노드를 추가, 제거 또는 업데이트할 수 있습니다. VM 형식은 D 시리즈 또는 A 시리즈와 같은 동일한 패밀리 형식의 모든 VM일 수 있습니다. |
| 가상 머신 확장 집합 노드 풀 | 노드 풀에서 동일한 크기 및 형식의 노드를 추가하거나 제거할 수 있습니다. 클러스터에 새 VM 크기를 추가하는 경우 새 노드 풀을 만들어야 합니다. |
Virtual Machines 노드 풀에는 다음과 같은 제한 사항이 있습니다.
- 클러스터 자동 크기 조정기는 지원되지 않습니다.
- InfiniBand 를 사용할 수 없습니다.
- Windows 노드 풀은 지원되지 않습니다.
- 이 기능은 Azure Portal에서 사용할 수 없습니다. Azure CLI 또는 REST API를 사용하여 CRUD(만들기, 읽기, 업데이트 및 삭제) 작업을 수행하거나 풀을 관리합니다.
- 노드 풀 스냅샷은 지원되지 않습니다.
- 노드 풀의 모든 VM 크기는 동일한 VM 제품군에 있어야 합니다. 예를 들어 N 시리즈 VM 형식을 동일한 노드 풀의 D 시리즈 VM 형식과 결합할 수 없습니다.
- Virtual Machines 노드 풀은 노드 풀당 최대 5개의 서로 다른 VM 크기를 허용합니다.
가상 노드
가상 노드를 사용하여 AKS 클러스터의 애플리케이션 워크로드를 신속하게 스케일 아웃할 수 있습니다. 가상 노드는 빠른 Pod 프로비저닝을 제공하며 런타임에 대해 초당만 지불합니다. 클러스터 자동 크기 조정기가 새 작업자 노드를 배포하여 더 많은 Pod 복제본을 실행할 때까지 기다릴 필요가 없습니다. Linux Pod 및 노드만 가상 노드를 지원합니다. AKS용 가상 노드 추가 항목은 오픈 소스 Virtual Kubelet 프로젝트를 기반으로 합니다.
가상 노드 기능은 Azure Container Instances에 따라 달라집니다. 자세한 내용은 가상 노드를 사용하도록 AKS 클러스터 만들기 및 구성을 참조하세요.
테인트, 레이블 및 태그
노드 풀을 만들 때 Kubernetes taints, 레이블, 및 Azure 태그를 추가할 수 있습니다. 각 taint, 레이블 또는 태그는 해당 노드 풀 내의 모든 노드에 적용됩니다.
taint가 있는 노드 풀을 만들려면 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 사용을 위해 예약되어 있고 노드에 사용할 수 없는 레이블이 나열되어 있습니다. 표에서 가상 노드 사용 열은 가상 노드 가 레이블을 지원하는지 여부를 지정합니다.
가상 노드 사용 열에서 다음을 수행합니다.
- N/A 는 호스트를 수정해야 하므로 속성이 가상 노드에 적용되지 않음을 의미합니다.
- 가상 노드 풀 및 표준 노드 풀에 대해 예상 값이 동일하다는 의미도 같습니다.
- 가상은 VM SKU 값을 대체합니다. 이는 가상 노드 Pod가 기본 VM을 노출하지 않기 때문입니다.
- 가상 노드 버전은 가상 Kubelet-ACI 커넥터 릴리스의 현재 버전을 나타냅니다.
- 가상 노드 서브넷 이름은 컨테이너 인스턴스에 가상 노드 포드(Pod)를 배포하는 서브넷입니다.
- 가상 노드 가상 네트워크는 가상 노드 서브넷을 포함하는 가상 네트워크입니다.
| 라벨 | 가치 | 예제 또는 옵션 | 가상 노드 사용량 |
|---|---|---|---|
kubernetes.azure.com/agentpool |
<agent pool name> |
nodepool1 |
동일 |
kubernetes.io/arch |
amd64 |
runtime.GOARCH |
해당 없음(N/A) |
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 |
해당 없음(N/A) |
kubernetes.io/hostname |
<hostname> |
aks-nodepool-00000000-vmss000000 |
동일 |
kubernetes.azure.com/storageprofile |
<OS disk storage profile> |
Managed |
해당 없음(N/A) |
kubernetes.azure.com/storagetier |
<OS disk storage tier> |
Premium_LRS |
해당 없음(N/A) |
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 |
해당 없음(N/A) |
kubernetes.azure.com/encrypted-set |
<nodepool encrypted-set name> |
encrypted-set-name |
해당 없음(N/A) |
kubernetes.azure.com/accelerator |
<accelerator> |
nvidia |
해당 없음(N/A) |
kubernetes.azure.com/fips_enabled |
<fips enabled> |
True |
해당 없음(N/A) |
kubernetes.azure.com/os-sku |
<os/sku> |
OS SKU 만들기 또는 업데이트 참조 | Linux 재고 관리 코드 |
윈도우 노드 풀
AKS를 사용하여 Azure Container Networking Interface 네트워크 플러그 인을 통해 Windows Server 컨테이너 노드 풀을 만들고 사용할 수 있습니다. 필요한 서브넷 범위 및 네트워크 고려 사항을 계획하려면 Azure Container Networking Interface 구성을 참조하세요.
다음 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 클러스터에 시스템 노드 풀을 대체할 다른 시스템 노드 풀이 있으면 시스템 노드 풀을 삭제해도 됩니다. 사용자 노드 풀은 0개 이상의 노드를 포함할 수 있습니다.
노드 풀을 만든 후에는 노드 풀의 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에서 클러스터 자동 크기 조정기 사용을 참조하세요.
Pod 샌드박싱
AKS에서 Kata Containers 를 완전 관리형 솔루션으로 쉽게 설정하고 실행하려면 Pod Sandboxing을 사용합니다. Pod Sandboxing은 컨테이너 애플리케이션과 컨테이너 호스트의 공유 커널 및 컴퓨팅 리소스(예: CPU, 메모리 및 네트워킹) 간에 격리 경계를 만드는 AKS 기능입니다.
Pod Sandboxing은 테넌트 워크로드가 중요한 정보를 보호하고 규제, 산업 또는 거버넌스 규정 준수 요구 사항을 충족할 수 있도록 다른 보안 조치 또는 데이터 보호 제어를 보완합니다. 이러한 요구 사항에는 PCI DSS(Payment Card Industry Data Security Standard), ISO(International Organization for Standardization) 27001, HIPAA(Health Insurance Portability and Accountability Act)가 포함됩니다.
서로 다른 팀 또는 고객의 테넌트 워크로드를 격리하는 데 도움이 되도록 별도의 클러스터 또는 노드 풀에 애플리케이션을 배포합니다. 조직 또는 SaaS(Software as a Service) 솔루션에 필요한 경우 여러 클러스터 및 노드 풀을 사용할 수 있습니다. 그러나 일부 시나리오는 공유 VM 노드 풀이 있는 단일 클러스터의 이점을 누릴 수 있습니다. 예를 들어, 단일 클러스터를 사용하여 동일한 노드에서 신뢰할 수 없는 Pod와 신뢰할 수 있는 Pod를 실행하거나, 더 빠른 로컬 통신과 기능 그룹화를 위해 동일한 노드에 DaemonSets와 권한 있는 컨테이너를 공동 배치할 수 있습니다.
Pod 샌드박싱을 사용하면 별도의 클러스터 또는 노드 풀에서 이러한 워크로드를 실행할 필요 없이 동일한 클러스터 노드에서 테넌트 애플리케이션을 격리할 수 있습니다. 다른 메서드를 사용하려면 코드를 다시 컴파일해야 하거나 다른 호환성 문제가 발생할 수 있습니다. AKS의 Pod 샌드박싱은 향상된 보안 VM 경계 내에서 수정되지 않은 컨테이너를 실행할 수 있습니다.
Pod Sandboxing은 AKS 스택용 Azure Linux 컨테이너 호스트에서 실행되어 하드웨어 적용 격리를 제공하는 Kata Containers를 기반으로 합니다. AKS의 Kata Containers는 보안이 강화된 Azure 하이퍼바이저를 기반으로 합니다. 부모 VM 노드의 리소스를 사용하는 중첩된 경량 Kata VM을 통해 각 Pod에 대한 격리를 달성합니다. 이 모델에서 각 Kata Pod는 중첩된 Kata 게스트 VM에서 자체 커널을 가져옵니다. 이 모델을 사용하여 부모 VM에서 컨테이너를 계속 실행하는 동안 여러 Kata 컨테이너를 단일 게스트 VM에 배치합니다. 이 모델은 공유 AKS 클러스터에서 강력한 격리 경계를 제공합니다.
자세한 내용은 AKS for Pod 샌드박싱에서 Kata VM 격리 컨테이너에 대한 지원을 참조하세요.
Azure 전용 호스트
Azure Dedicated Host 는 물리적 서버 수준에서 하드웨어 격리를 보장하기 위해 단일 Azure 구독 전용 물리적 서버를 제공하는 서비스입니다. 지역, 가용성 영역 및 장애 도메인 내에서 이러한 전용 호스트를 프로비전할 수 있습니다. VM을 프로비전된 호스트에 직접 배치할 수 있습니다.
AKS와 함께 전용 호스트를 사용하여 다음과 같은 이점을 제공합니다.
하드웨어 격리는 다른 VM이 전용 호스트에 배치되지 않도록 하며, 이는 테넌트 워크로드에 대한 추가 격리 계층을 제공합니다. 전용 호스트는 동일한 데이터 센터에 배포되며 인식되지 않는 다른 호스트와 동일한 네트워크 및 기본 스토리지 인프라를 공유합니다.
전용 호스트는 Azure 플랫폼이 시작하는 유지 관리 이벤트를 제어합니다. 유지 관리 기간을 선택하여 서비스에 미치는 영향을 줄이고 테넌트 워크로드의 가용성 및 개인 정보를 보장할 수 있습니다.
전용 호스트는 SaaS 공급자가 테넌트 애플리케이션이 규제, 산업 및 거버넌스 규정 준수 요구 사항을 충족하여 중요한 정보를 보호하는 데 도움이 될 수 있습니다. 자세한 내용은 AKS 클러스터에 전용 호스트 추가를 참조하세요.
카르펜터 (미국)
Karpenter 는 Kubernetes용으로 빌드된 오픈 소스 노드 수명 주기 관리 프로젝트입니다. Kubernetes 클러스터에 Karpenter를 추가하여 해당 클러스터에서 워크로드를 실행하는 효율성과 비용을 개선합니다. Karpenter는 Kubernetes 스케줄러가 예약할 수 없는 것으로 표시하는 Pod를 감시합니다. 또한 Pod 요구 사항을 충족할 수 있는 노드를 동적으로 프로비전하고 관리합니다.
Karpenter는 관리형 클러스터의 노드 프로비저닝 및 워크로드 배치에 대한 세분화된 제어를 제공합니다. 이 컨트롤은 리소스 할당을 최적화하고, 각 테넌트의 애플리케이션 간의 격리를 보장하며, 운영 비용을 줄여 다중 테넌트성을 향상시킵니다. AKS에서 다중 테넌트 솔루션을 빌드할 때 Karpenter는 다양한 테넌트를 지원하기 위해 다양한 애플리케이션 요구 사항을 관리하는 데 유용한 기능을 제공합니다.
예를 들어 GPU 최적화 노드 풀에서 실행하려면 일부 테넌트의 애플리케이션이 필요하고 메모리 최적화 노드 풀에서 실행하려면 다른 테넌트의 애플리케이션이 필요할 수 있습니다. 애플리케이션에 스토리지 대기 시간이 짧은 경우 Karpenter를 사용하여 Pod에 특정 가용성 영역에서 실행되는 노드가 필요함을 나타낼 수 있습니다. 그런 다음 스토리지 및 애플리케이션 계층을 공동 배치할 수 있습니다.
AKS는 Karpenter를 통해 AKS 클러스터에서 노드 자동 프로비전을 사용하도록 설정합니다. 대부분의 사용자는 노드 자동 프로비전 모드를 사용하여 Karpenter를 관리되는 추가 기능으로 사용하도록 설정해야 합니다. 자세한 내용은 노드 자동 프로비전참조하세요. 고급 사용자 지정이 필요한 경우 Karpenter를 자체 호스팅할 수 있습니다. 자세한 내용은 AKS Karpenter 공급자를 참조하세요.
기밀 가상 머신
기밀 컴퓨팅은 소프트웨어 지원 또는 하드웨어 지원 격리 및 암호화를 통해 사용 중인 데이터를 보호하는 데 도움이 되는 보안 조치입니다. 이 기술은 기존 접근 방식에 추가적인 보안 계층을 추가하여 미사용 데이터와 전송 중인 데이터를 보호하는 데 도움이 됩니다.
AWS 플랫폼은 EC2 인스턴스 및 Amazon EKS에서 사용할 수 있는 Nitro Enclave를 통한 기밀 컴퓨팅을 지원합니다. Amazon EC2 인스턴스는 AMD 보안 암호화 가상화 보안 중첩 페이징(SEV-SNP)도 지원합니다. 런타임 증명 GitHub 리포지토리는 AMD SEV-SNP 지원을 사용하여 EKS용 Amazon Machine Image를 빌드하고 배포하는 아티팩트를 제공합니다.
Azure는 AKS 클러스터 내에서 엄격한 격리, 개인 정보 보호 및 보안 요구 사항을 충족하는 데 도움이 되는 기밀 VM을 고객에게 제공합니다. 이러한 기밀 VM은 하드웨어 기반 신뢰할 수 있는 실행 환경을 사용합니다. 특히 Azure 기밀 VM은 AMD SEV-SNP 기술을 사용합니다. 이 기술은 VM 메모리 및 상태에 대한 하이퍼바이저 및 기타 호스트 관리 코드 액세스를 거부합니다. 이 방법을 사용하여 운영자 액세스에 대한 추가 방어 및 보호 계층을 추가합니다. 자세한 내용은 AKS 클러스터에서 기밀 VM 사용 및 Azure의 기밀 VM 개요를 참조하세요.
연방 정보 프로세스 표준
FIPS(Federal Information Process Standards) 140-3 은 정보 기술 제품 및 시스템의 암호화 모듈에 대한 최소 보안 요구 사항을 정의하는 미국 정부 표준입니다. AKS 노드 풀에 대한 FIPS 규정 준수를 사용하도록 설정하여 테넌트 워크로드의 격리, 개인 정보 보호 및 보안을 향상시킵니다. FIPS 규정 준수는 암호화, 해시 및 기타 보안 관련 작업에 유효성이 검사된 암호화 모듈을 사용하는 데 도움이 됩니다. FIPS 지원 AKS 노드 풀을 사용하여 규제 및 업계 규정 준수 요구 사항을 충족하는 데 도움이 되는 강력한 암호화 알고리즘 및 메커니즘을 사용합니다. 다중 테넌트 AKS 환경의 보안 태세를 강화하는 방법에 대한 자세한 내용은 AKS 노드 풀에 FIPS 사용 설정을 참조하세요.
호스트 기반 암호화
EKS에서 아키텍처는 다음 기능을 사용하여 데이터 보안을 강화할 수 있습니다.
EBS(Amazon Elastic Block Store) 암호화: EKS 작업자 노드에 연결된 Amazon EBS 볼륨에서 미사용 데이터를 암호화할 수 있습니다.
AWS KMS(키 관리 서비스) : AWS KMS를 사용하여 암호화 키를 관리하고 미사용 데이터의 암호화를 적용할 수 있습니다. 비밀 암호화를 사용하도록 설정하는 경우 고유한 AWS KMS 키를 사용하여 Kubernetes 비밀을 암호화할 수 있습니다. 자세한 내용은 기존 클러스터에서 AWS KMS를 사용하여 Kubernetes 비밀 암호화참조하세요.
Amazon S3 서버 쪽 암호화: EKS 애플리케이션이 Amazon S3과 상호 작용하는 경우 S3 버킷에 대해 서버 쪽 암호화를 사용하도록 설정하여 미사용 데이터를 보호할 수 있습니다.
AKS의 호스트 기반 암호화
AKS에서 OS 디스크 및 데이터 디스크는 기본적으로 플랫폼 관리 키를 통해 서버 쪽 암호화를 사용합니다. 이러한 디스크의 캐시는 플랫폼 관리형 키를 통해 미사용 시 암호화됩니다. 사용자 고유 의 키 암호화 키를 사용하여 데이터 보호 키를 암호화할 수 있습니다. 이 메서드를 봉투 암호화 또는 래핑이라고 합니다. 지정한 암호화 키 는 OS 디스크 및 데이터 디스크에 대한 캐시도 암호화합니다.
호스트 기반 암호화는 다중 테넌트 환경에 대한 보안 계층을 추가합니다. OS 디스크 및 데이터 디스크 캐시에 있는 각 테넌트의 데이터는 선택한 디스크 암호화 유형에 따라 고객 관리형 또는 플랫폼 관리형 키를 통해 미사용 시 암호화됩니다. 자세한 내용은 다음 리소스를 참조하세요.
- AKS 호스트 기반 암호화
- AKS Azure 디스크를 사용하여 BYOK
- Azure Disk Storage의 서버 쪽 암호화
업데이트 및 업그레이드
Azure는 VM 호스팅 플랫폼을 주기적으로 업데이트하여 안정성, 성능 및 보안을 개선합니다. 이러한 업데이트는 호스팅 환경의 소프트웨어 구성 요소 패치에서 네트워킹 구성 요소 업그레이드 또는 하드웨어 서비스 해제에 이르기까지 다양합니다. 자세한 내용은 Azure의 VM에 대한 유지 관리를 참조하세요.
VM 호스팅 인프라 업데이트는 일반적으로 기존 AKS 클러스터의 에이전트 노드와 같은 호스트된 VM에 영향을 주지 않습니다. 호스트된 VM에 영향을 주는 업데이트의 경우 Azure는 호스트를 업데이트하는 동안 VM을 일시 중지하거나 VM을 이미 업데이트된 호스트로 실시간 마이그레이션하여 다시 부팅이 필요한 경우를 최소화합니다.
업데이트에 다시 부팅이 필요한 경우 Azure는 업데이트를 시작할 수 있는 알림 및 시간 창을 제공합니다. 유지 관리가 긴급하지 않은 경우 일반적으로 호스트 머신의 셀프 유지 관리 기간은 35일입니다.
계획된 유지 관리를 사용하여 VM을 업데이트할 수 있습니다. Azure CLI, Azure PowerShell 또는 AzurePortal을 사용하여 계획된 유지 관리 알림을 관리합니다. 계획된 유지 관리는 클러스터 자동 업그레이드 기능을 사용하는지 여부를 감지하고 유지 관리 기간 동안 업그레이드를 자동으로 예약합니다. 자세한 정보를 보려면 계획된 유지 관리를 통해 AKS 클러스터의 유지 관리 기간을 예약하기 및 az aks maintenanceconfiguration 명령어를 참조하세요.
Kubernetes 업그레이드
AKS 클러스터 수명 주기의 일부에는 정기적으로 최신 Kubernetes 버전으로 업그레이드하는 것이 포함됩니다. 업그레이드를 적용하여 최신 보안 릴리스 및 기능을 가져와야 합니다. 기존 노드 풀 VM의 Kubernetes 버전을 업그레이드하려면 노드를 차단 및 드레이닝하고 업데이트된 Kubernetes 디스크 이미지 기반의 새 노드로 바꿔야 합니다.
기본적으로 AKS는 하나의 추가 노드를 사용하여 업그레이드가 급격하게 이루어지도록 구성합니다. 설정에 대한 기본값을 1로 설정하면 워크로드 중단이 최소화됩니다. 이 구성은 기존 애플리케이션을 조정하거나 드레이닝하기 전에 이전 버전의 노드를 대체하는 추가 노드를 만듭니다.
max-surge 값을 노드 풀별로 사용자 지정하여 업그레이드 속도와 업그레이드 중단 간의 균형을 최적화할 수 있습니다. 값이 높을 max-surge 수록 업그레이드 프로세스의 속도가 증가하지만 값이 크 max-surge 면 업그레이드 프로세스 중에 중단이 발생할 수 있습니다.
예를 들어 max-surge 100% 값은 노드 수를 두 배로 늘려 가능한 가장 빠른 업그레이드 프로세스를 제공합니다. 그러나 이 값은 노드 풀의 모든 노드를 동시에 비우게 합니다. 이 높은 값을 테스트에 사용할 수도 있지만 프로덕션 노드 풀의 경우 33%설정을 사용합니다 max-surge .
AKS는 값의 정수 및 백분율 값을 max-surge 모두 허용합니다.
5와 같은 정수는 네트워크에서 추가할 5개의 노드를 증가시킨다는 것을 나타냅니다.
max-surge부터 1%까지 설정할 수 있는 백분율 값을 가장 가까운 노드 수로 반올림하여 100%에 설정할 수 있습니다.
50%는 풀에 있는 현재 노드 수의 절반에 해당하는 서지 값을 나타냅니다.
업그레이드하는 동안 max-surge 값을 최소 1으로 설정하고, 최대값은 노드 풀의 노드 수와 동일하게 설정할 수 있습니다. 더 큰 값을 설정할 수 있지만 최대 노드 max-surge 수는 풀의 노드 수를 초과할 수 없습니다.
중요합니다
업그레이드 작업의 경우, 요청된 max-surge 개수를 처리하기 위해 필요한 만큼의 구독 할당량이 노드 급증에 있어야 합니다. 예를 들어 노드 풀이 5개 있고 각 노드 풀에는 4개의 노드가 있는 클러스터의 총 노드 수는 20개입니다. 각 노드 풀에 max-surge 값이 50%인 경우 업그레이드를 완료하려면 추가 컴퓨팅과 10개의 노드에 대한 IP 할당량이 필요하거나 5개의 풀에 각각 2개의 노드를 배치해야 합니다.
Azure Container Networking Interface를 사용하는 경우 AKS에 대한 요구 사항을 충족하기에 충분한 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 업그레이드를 사용합니다.
az aks nodepool upgrade \
--resource-group <myResourceGroup> \
--cluster-name <myAKSCluster> \
--name <mynodepool> \
--kubernetes-version <KUBERNETES_VERSION>
자세한 내용은 다음 리소스를 참조하세요.
업그레이드 고려 사항
AKS 클러스터에서 Kubernetes 버전을 업그레이드할 때 다음 모범 사례를 고려합니다.
AKS 클러스터의 모든 노드 풀을 동일한 Kubernetes 버전으로 업그레이드해야 합니다.
az aks upgrade의 기본 동작은 모든 노드 풀과 컨트롤 플레인을 업그레이드하는 것입니다.수동으로 업그레이드를 수행하거나 클러스터에서 자동 업그레이드 채널을 설정합니다. 계획된 유지 관리를 사용하여 VM을 패치하는 경우 지정된 유지 관리 기간 동안 자동 업그레이드도 시작됩니다. 자세한 내용은 AKS 클러스터 업그레이드을 참조하세요.
az aks upgrade플래그가 있는--control-plane-only명령은 클러스터 컨트롤 플레인을 업그레이드하고 클러스터의 연결된 노드 풀을 변경하지 않습니다. 개별 노드 풀을 업그레이드하려면 명령에서az aks nodepool upgrade대상 노드 풀 및 Kubernetes 버전을 지정합니다.AKS 클러스터 업그레이드는 노드의 차단 및 드레이닝을 트리거합니다. 사용 가능한 컴퓨팅 할당량이 낮으면 업그레이드가 실패할 수 있습니다. 자세한 내용은 지역 vCPU 할당량 늘리기를 참조하세요.
max-surge필요에 따라 매개 변수를 구성합니다. 정수 또는 백분율 값을 사용합니다. 프로덕션 노드 풀은max-surge를 33%로 설정합니다. 자세한 내용은 노드 서지 업그레이드 사용자 지정을 참조하세요.Azure Container Networking Interface 네트워킹을 사용하는 AKS 클러스터를 업그레이드하는 경우 서브넷에 설정이 만드는 추가 노드에 대해 사용 가능한 개인 IP 주소가
max-surge충분한지 확인합니다. 자세한 내용은 AKS에서 Azure Container Networking Interface 네트워킹 구성을 참조하세요.클러스터 노드 풀이 지역 내의 여러 가용성 영역에 걸쳐 있는 경우 업그레이드 프로세스는 일시적으로 불균형 영역 구성을 만들 수 있습니다. 자세한 내용은 여러 가용성 영역에 걸쳐 있는 노드 풀을 참조하세요.
기여자
Microsoft는 이 문서를 유지 관리합니다. 다음 기여자는 이 문서를 작성했습니다.
주요 작성자:
- Paolo Salvatori | 수석 시스템 엔지니어
기타 기여자:
- Laura Nicolas | 선임 소프트웨어 엔지니어
- 채드 키텔 | 주요 소프트웨어 엔지니어 - Azure 패턴 및 사례
- Ed Price | 선임 콘텐츠 프로그램 관리자
- Theano Petersen | 기술 작가
LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.
다음 단계
- AKS 클러스터 모범 사례
- 공용 DNS 영역을 사용하여 프라이빗 AKS 클러스터 만들기
- Terraform 및 Azure DevOps를 사용하여 프라이빗 AKS 클러스터 만들기
- Azure NAT Gateway 및 Azure Application Gateway를 사용하여 공용 또는 프라이빗 AKS 클러스터 만들기
- 프라이빗 AKS 클러스터에서 프라이빗 엔드포인트 사용
- Application Gateway 수신 컨트롤러를 사용하여 AKS 클러스터 만들기
- 교육: Kubernetes 소개
- 교육: Azure의 Kubernetes 소개
- 교육: Kubernetes에서 애플리케이션 개발 및 배포
- 교육: AKS에서 컴퓨팅 비용 최적화