AKS(Azure Kubernetes Service)의 Core Kubernetes 개념

이 문서에서는 Azure에서 대규모로 컨테이너화된 애플리케이션을 배포하고 운영하는 데 사용할 수 있는 관리되는 Kubernetes Service인 AKS(Azure Kubernetes Service)의 핵심 개념을 설명합니다. Kubernetes의 인프라 구성 요소에 대해 배우고 AKS에서 Kubernetes가 작동하는 방식을 더 깊이 이해하는 데 도움이 됩니다.

Kubernetes란?

Kubernetes는 컨테이너 기반 애플리케이션과 관련 네트워킹 및 스토리지 구성 요소를 관리하는 플랫폼으로서 빠르게 진화하고 있습니다. Kubernetes는 기본 인프라 구성 요소가 아닌 애플리케이션 워크로드에 중점을 두고 있습니다. Kubernetes는 관리 작업을 위한 강력한 API 집합을 통해 지원되는 선언적 배포 방식을 제공합니다.

Kubernetes를 사용하여 애플리케이션 구성 요소의 가용성을 오케스트레이션하고 관리할 수 있는 이식 가능 마이크로 서비스 기반 최신 애플리케이션을 빌드하고 실행할 수 있습니다. Kubernetes는 상태 비저장 애플리케이션과 상태 저장 애플리케이션을 모두 지원합니다.

오픈 플랫폼인 Kubernetes를 사용하면 기본 설정 프로그래밍 언어, OS, 라이브러리 또는 메시지 버스를 사용하여 애플리케이션을 빌드할 수 있습니다. 기존의 CI/CD(지속적인 통합 및 지속적인 업데이트) 도구는 Kubernetes와 통합되어 릴리스를 예약하고 배포할 수 있습니다.

AKS는 배포 및 핵심 관리 작업의 복잡성을 줄이는 관리되는 Kubernetes Service를 제공합니다. Azure 플랫폼에서 AKS 컨트롤 플레인을 관리하며, 애플리케이션을 실행하는 AKS 노드에 대해서만 비용을 지불합니다.

Kubernetes 클러스터 아키텍처

Kubernetes 클러스터는 다음 두 가지 구성 요소로 구분됩니다.

• 핵심 Kubernetes 서비스 및 애플리케이션 워크로드 오케스트레이션을 제공하는 컨트롤 플레인 및
• 애플리케이션 워크로드를 실행하는 노드입니다.

제어 평면

AKS 클러스터를 만들면 Azure 플랫폼은 연결된 컨트롤 플레인을 자동으로 만들고 구성합니다. 이 단일 테넌트 컨트롤 플레인은 사용자로부터 추상화된 관리 Azure 리소스로 무료로 제공됩니다. AKS 클러스터에 연결된 노드에 대해서만 비용을 지불합니다. 컨트롤 플레인 및 해당 리소스는 클러스터를 만든 지역에만 상주합니다.

컨트롤 플레인에 포함되는 핵심 Kubernetes 구성 요소는 다음과 같습니다.

구성 요소	설명
kube-apiserver	API 서버는 기본 Kubernetes API를 노출하고 kubectl 또는 Kubernetes 대시보드와 같은 관리 도구에 대한 상호 작용을 제공합니다.
etcd	etcd는 Kubernetes 클러스터 및 구성의 상태를 유지하는 데 도움이 되는 Kubernetes 내의 고가용성 키-값 저장소입니다.
kube-scheduler	애플리케이션을 만들거나 크기 조정할 때 스케줄러는 워크로드를 실행할 수 있는 노드를 결정하고 식별된 노드를 시작합니다.
kube-controller-manager	컨트롤러 관리자는 Pod 복제 및 노드 작업 처리와 같은 작업을 수행하는 여러 작은 컨트롤러를 감독합니다.

컨트롤 플레인에 직접 액세스할 수 없다는 점에 유의해야 합니다. Kubernetes 컨트롤 플레인 및 노드 업그레이드는 Azure CLI 또는 Azure Portal을 통해 오케스트레이션됩니다. 가능한 문제를 해결하려면 Azure Monitor를 사용하여 컨트롤 플레인 로그를 검토할 수 있습니다.

노드

애플리케이션과 지원 서비스를 실행하려면 Kubernetes 노드가 필요합니다. 각 AKS 클러스터에는 Kubernetes 노드 구성 요소 및 컨테이너 런타임을 실행하는 하나 이상의 노드, 즉 Azure VM(Virtual Machines)이 있습니다.

노드에는 다음과 같은 핵심 Kubernetes 구성 요소가 포함됩니다.

구성 요소	설명
kubelet	요청된 컨테이너의 예약 및 실행과 함께 컨트롤 플레인의 오케스트레이션 요청을 처리하는 Kubernetes 에이전트입니다.
kube-proxy	프록시는 각 노드의 가상 네트워킹을 처리하고 네트워크 트래픽을 라우팅하며 서비스 및 Pod에 대한 IP 주소 지정을 관리합니다.
컨테이너 런타임	컨테이너 런타임을 사용하면 컨테이너화된 애플리케이션이 가상 네트워크 또는 스토리지와 같은 다른 리소스를 실행하고 상호 작용할 수 있습니다. 자세한 내용은 컨테이너 런타임 구성을 참조하세요.

노드의 Azure VM 크기는 CPU, 메모리, 크기, 사용 가능한 스토리지 유형(예: 고성능 SSD 또는 일반 HDD)을 정의합니다. 애플리케이션에 많은 양의 CPU 및 메모리 또는 고성능 스토리지가 필요한지 여부를 기준으로 노드 크기를 계획합니다. 요구 사항에 맞게 AKS 클러스터의 노드 수를 스케일 아웃합니다. 크기 조정에 대한 자세한 내용은 AKS의 애플리케이션에 대한 크기 조정 옵션을 참조하세요.

AKS에서 클러스터 노드의 VM 이미지는 Ubuntu Linux, Azure Linux 또는 Windows Server 2022를 기반으로 합니다. AKS 클러스터를 만들거나 노드 수를 스케일 아웃하면 Azure 플랫폼에서 요청된 수의 VM을 자동으로 만들고 구성합니다. 에이전트 노드는 표준 VM으로 청구되므로 VM 크기 할인(Azure Reservations 포함)이 자동으로 적용됩니다.

관리 디스크의 경우 선택한 VM SKU 및 vCPU 수에 따라 기본 디스크 크기 및 성능이 할당됩니다. 자세한 내용은 기본 OS 디스크 크기를 참조하세요.

OS 구성

AKS는 Kubernetes 1.25 이상이 있는 클러스터의 노드 OS(운영 체제)로 Ubuntu 22.04 및 Azure Linux 2.0을 지원합니다. Kubernetes 버전 1.24 이하의 노드 풀을 만들 때 Ubuntu 18.04를 지정할 수도 있습니다.

AKS는 Kubernetes 1.25 이상이 설치된 클러스터에서 Windows 노드 풀의 기본 OS로 Windows Server 2022를 지원합니다. Kubernetes 버전 1.32 이하의 경우 노드 풀을 만들 때 Windows Server 2019를 지정할 수도 있습니다. Windows Server 2019는 Kubernetes 버전 1.32가 수명 사용 중지에 도달하면 사용 중지되며 향후 릴리스에서 지원되지 않습니다. 이 사용 중지에 대한 자세한 내용은 AKS 릴리스 정보를 참조하세요.

컨테이너 런타임 구성

컨테이너 런타임은 컨테이너를 실행하고 노드에서 컨테이너 이미지를 관리하는 소프트웨어입니다. 런타임은 Linux 또는 Windows에서 컨테이너를 실행하기 위해 sys 호출 또는 OS 관련 기능을 추상화하는 데 도움이 됩니다. Linux 노드 풀의 경우 containerd는 Kubernetes 버전 1.19 이상에서 사용됩니다. Windows Server 2019 및 2022 노드 풀의 경우 containerd는 일반적으로 사용할 수 있으며 Kubernetes 버전 1.23 이상에서 유일한 런타임 옵션입니다. 2023년 5월 현재 Docker가 사용 중지되고 더 이상 지원되지 않습니다. 이 사용 중지에 대한 자세한 내용은 AKS 릴리스 정보를 참조하세요.

Containerd는 노드에서 컨테이너를 실행하고 이미지를 관리하는 데 필요한 최소한의 기능 세트를 제공하는 OCI(Open Container Initiative) 준수 핵심 컨테이너 런타임입니다. containerd 기반 노드 및 노드 풀을 사용하면 kubelet은 CRI(컨테이너 런타임 인터페이스) 플러그 인을 사용하여 containerd와 직접 통신하여 Docker CRI 구현과 비교할 때 데이터 흐름에서 추가 홉을 제거합니다. 따라서 Pod 시작 대기 시간이 단축되고 리소스(CPU 및 메모리) 사용량이 줄어듭니다.

Containerd는 AKS의 모든 GA 버전, v1.19부터 시작하는 모든 Kubernetes 버전에서 작동하며 모든 Kubernetes 및 AKS 기능을 지원합니다.

containerd 제한 사항/차이점

• containerd의 경우 Kubernetes 노드의 Pod, 컨테이너 및 컨테이너 이미지 문제 해결을 위해 Docker CLI 대신 crictl을 사용하는 것이 좋습니다. crictl에 대한 자세한 내용은 일반 사용 및 클라이언트 구성 옵션을 참조하세요.

  • Containerd는 Docker CLI의 전체 기능을 제공하지 않습니다. 문제 해결에만 사용할 수 있습니다.
  • crictl은 Pod 등과 같은 개념이 있는 컨테이너에 대한 Kubernetes 친화적 보기를 제공합니다.

• Containerd는 표준화된 cri 로깅 형식을 사용하여 로깅을 설정합니다. 로깅 솔루션은 cri 로깅 형식(예: Azure Monitor for Containers)을 지원해야 합니다.

• 더 이상 Docker 엔진 /var/run/docker.sock에 액세스하거나 DinD(Docker-in-Docker)를 사용할 수 없습니다.

  • 현재 Docker Engine에서 애플리케이션 로그 또는 모니터링 데이터를 추출하는 경우 대신 컨테이너 Insights를 사용합니다. AKS는 불안정을 유발할 수 있는 에이전트 노드에서 대역 외 명령 실행을 지원하지 않습니다.
  • 이미지를 빌드하거나 Docker 엔진을 직접 사용하는 것은 권장되지 않습니다. Kubernetes는 소비된 리소스를 완전히 인식하지 못하며 이러한 방법은 여기 및 여기에 설명된 대로 수많은 문제를 나타냅니다.

• 이미지 빌드 - AKS 클러스터 내에서 이미지를 빌드하지 않는 한 현재 Docker 빌드 워크플로를 정상적으로 계속 사용할 수 있습니다. 이 경우 ACR 작업 또는 Docker Buildx와 같은 보다 안전한 클러스터 내 옵션을 사용하여 이미지를 빌드하는 데 권장되는 접근 방식으로 전환하는 것이 좋습니다.

리소스 예약

AKS는 노드 리소스를 사용하여 노드가 클러스터의 일부로 작동하도록 지원합니다. 이를 사용하면 노드의 총 리소스와 AKS의 할당 가능한 리소스 간에 불일치가 발생할 수 있습니다. 사용자가 배포한 Pod에 대한 요청 및 제한을 설정할 때 이 정보를 잊지 마세요.

노드의 할당 가능한 리소스를 찾으려면 kubectl describe node 명령을 사용할 수 있습니다.

kubectl describe node [NODE_NAME]

노드 성능과 기능을 유지하기 위해 AKS는 각 노드에 CPU와 메모리라는 두 가지 형식의 리소스를 예약합니다. 노드가 리소스에서 더 커질수록 사용자가 배포한 Pod를 관리할 필요성이 높아지므로 리소스 예약도 증가합니다. 리소스 예약은 변경할 수 없다는 점에 유의해야 합니다.

CPU

예약된 CPU는 노드 형식 및 클러스터 구성에 따라 달라지며, 추가 기능 실행으로 인해 할당 가능한 CPU가 줄어들 수 있습니다. 다음 표는 밀리코어 단위의 CPU 예약을 보여 줍니다.

호스트의 CPU 코어 수	1	2	4	8	16	32	64
kube-reserved(밀리코어)	60	100	140	180	260	420	740

메모리

AKS의 예약된 메모리에는 다음 두 값의 합계가 포함됩니다.

AKS 1.29 이상

1. kubelet 디먼에는 기본적으로 memory.available<100Mi 제거 규칙이 있습니다. 이 규칙은 노드에 항상 최소 100Mi를 할당할 수 있도록 보장합니다. 호스트가 사용 가능한 메모리 임계값보다 낮으면 kubelet은 실행 중인 Pod 중 하나의 종료를 트리거하고 호스트 컴퓨터에서 메모리를 확보합니다.

2. 메모리 예약 비율은 20MB * 노드에서 지원되는 최대 Pod + 50MB 또는 총 시스템 메모리 리소스의 25% 중 더 작은 값에 따라 설정됩니다.

   예:

   • VM이 8GB의 메모리를 제공하고 노드가 최대 30개의 Pod를 지원하는 경우 AKS는 kube 예약을 위해 20MB * 30 Max Pods + 50MB = 650MB를 예약합니다. Allocatable space = 8GB - 0.65GB (kube-reserved) - 0.1GB (eviction threshold) = 7.25GB or 90.625% allocatable.
   • VM이 4GB의 메모리를 제공하고 노드가 최대 70개의 Pod를 지원하는 경우, 20MB * 70개의 최대 Pod + 50MB = 1450MB 미만이므로 AKS는 kube-reserved를 위해 25% * 4GB = 1000MB를 예약합니다.

   자세한 내용은 AKS 클러스터의 노드당 최대 Pod 구성을 참조하세요.

1.29 이전 AKS 버전

1. kubelet 디먼에는 기본적으로 memory.available<750Mi 제거 규칙이 있습니다. 이 규칙은 노드에 항상 최소 750Mi를 할당할 수 있도록 보장합니다. 호스트가 사용 가능한 메모리 임계값보다 낮으면 kubelet은 실행 중인 Pod 중 하나의 종료를 트리거하고 호스트 컴퓨터에서 메모리를 확보합니다.
2. kubelet 디먼이 제대로 작동하기 위한 메모리 예약의 회귀 비율(kube-reserved)
   • 처음 4GB 메모리의 25%
   • 다음 4GB 메모리의 20%(최대 8GB)
   • 다음 8GB 메모리의 10%(최대 16GB)
   • 다음 112GB 메모리의 6%(최대 128GB)
   • 128GB 이상의 메모리 중 2%

메모리 및 CPU 배정 규칙은 다음을 위해 설계되었습니다.

• 클러스터 상태에 중요한 일부 호스팅 시스템 Pod를 포함하여 에이전트 노드를 정상 상태로 유지합니다.
• 노드에서 할당 가능한 메모리 및 CPU를 Kubernetes 클러스터의 일부가 아닌 경우보다 더 적게 보고하도록 합니다.

예를 들어 노드에서 7GB를 제공하는 경우 750Mi 하드 제거 임계값을 포함하여 할당할 수 없는 메모리의 34%를 보고합니다.

0.75 + (0.25*4) + (0.20*3) = 0.75GB + 1GB + 0.6GB = 2.35GB / 7GB = 33.57% reserved

또한 기본 노드 OS는 Kubernetes 자체에 대한 예약 외에도 OS 기능을 유지하기 위해 많은 CPU 및 메모리 리소스를 예약합니다.

관련 모범 사례는 AKS의 기본 스케줄러 기능 모범 사례를 참조하세요.

노드 풀

동일한 구성의 노드는 노드 풀로 그룹화됩니다. 각 Kubernetes 클러스터에는 하나 이상의 노드 풀이 포함됩니다. 기본 노드 풀을 만드는 AKS 클러스터를 만들 때 초기 노드 수와 크기를 정의합니다. AKS의 기본 노드 풀에는 에이전트 노드를 실행하는 기본 VM이 포함됩니다.

AKS 클러스터를 기본 노드 풀에 대해 스케일링하거나 업그레이드합니다. 특정 노드 풀을 스케일링하거나 업그레이드하도록 선택할 수 있습니다. 업그레이드 작업의 경우, 모든 노드가 성공적으로 업그레이드될 때까지 실행 중인 컨테이너는 노드 풀의 다른 노드에 예약됩니다.

자세한 내용은 노드 풀 만들기 및 노드 풀 관리를 참조하세요.

기본 OS 디스크 크기 조정

새 클러스터를 만들거나 새 노드 풀을 기존 클러스터에 추가하면 기본적으로 vCPU 수는 OS 디스크 크기에 따라 결정됩니다. vCPU 수는 VM SKU를 기반으로 합니다. 다음 표에는 각 VM SKU의 기본 OS 디스크 크기가 나열되어 있습니다.

VM SKU 코어(vCPU) 수	기본 OS 디스크 계층	프로비전되는 IOPS	프로비전된 처리량(Mbps)
1~7	P10/128G	500	100
8~15	P15/256G	1100	125
16~63	P20/512G	2300	150
64 이상	P30/1024G	5000	200

노드 선택기

여러 노드 풀이 있는 AKS 클러스터에서는 지정된 리소스에 사용할 노드 풀을 Kubernetes 스케줄러에 알려야 할 수 있습니다. 예를 들어 수신 컨트롤러는 Windows Server 노드에서 실행되지 않습니다. 노드 선택기를 사용하여 노드 OS와 같은 다양한 매개 변수를 정의하여 Pod를 예약해야 하는 위치를 제어합니다.

다음 기본 예제에서는 "kubernetes.io/os": linux 노드 선택기를 사용하여 Linux 노드에서 NGINX 인스턴스를 예약합니다.

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.12-alpine
  nodeSelector:
    "kubernetes.io/os": linux

자세한 내용은 AKS의 고급 스케줄러 기능 우수 사례를 참조하세요.

노드 리소스 그룹

AKS 클러스터를 만들 때 클러스터 리소스를 만들 Azure 리소스 그룹을 지정합니다. AKS 리소스 공급자는 이 리소스 그룹 외에도 노드 리소스 그룹이라는 별도의 리소스 그룹을 만들고 관리합니다. 노드 리소스 그룹에는 다음 인프라 리소스가 포함됩니다.

• 노드 풀의 모든 노드에 대한 가상 머신 확장 집합 및 VM
• 클러스터의 가상 네트워크
• 클러스터의 스토리지

노드 리소스 그룹에는 기본적으로 MC_resourceGroupName_clusterName_location 형식의 이름이 할당됩니다. 클러스터를 만드는 동안 노드 리소스 그룹에 할당된 이름을 할당할 수 있습니다. Azure Resource Manager 템플릿을 사용하는 경우 nodeResourceGroup 속성을 사용하여 이름을 정의할 수 있습니다. Azure CLI를 사용하는 경우 다음 예와 같이 az aks create 명령과 함께 --node-resource-group 매개 변수를 사용합니다.

az aks create --name myAKSCluster --resource-group myResourceGroup --node-resource-group myNodeResourceGroup

AKS 클러스터를 삭제하면 AKS 리소스 공급자가 노드 리소스 그룹을 자동으로 삭제합니다.

노드 리소스 그룹에는 다음과 같은 제한 사항이 있습니다.

• 노드 리소스 그룹에 기존 리소스 그룹을 지정할 수 없습니다.
• 노드 리소스 그룹에 다른 구독을 지정할 수 없습니다.
• 클러스터를 만든 후 노드 리소스 그룹 이름을 변경할 수 없습니다.
• 노드 리소스 그룹 내에서 관리되는 리소스의 이름을 지정할 수 없습니다.
• 노드 리소스 그룹 내에서 관리되는 리소스의 Azure에서 만든 태그를 수정하거나 삭제할 수 없습니다.

AKS 클러스터의 노드 리소스 그룹에서 리소스에 대해 Azure로 만든 태그를 수정하는 작업은 지원되지 않으며, 이러한 작업은 SLO(서비스 수준 목표)를 중단하게 됩니다. Azure에서 만든 태그 또는 노드 리소스 그룹의 기타 리소스 속성을 수정하거나 삭제하면 크기 조정 및 업그레이드 오류와 같은 예기치 않은 결과가 발생할 수 있습니다. AKS는 노드 리소스 그룹의 인프라 수명 주기를 관리하므로 변경 내용이 있으면 클러스터가 지원되지 않는 상태로 전환됩니다. 자세한 내용은 AKS는 서비스 수준 계약을 제공합니까?를 참조하세요.

AKS를 사용하면 노드 리소스 그룹의 리소스에 전파되는 태그를 만들고 수정할 수 있으며 클러스터를 만들거나 업데이트 할 때 해당 태그를 추가할 수 있습니다. 예를 들어, 사업부 또는 비용 센터를 할당하기 위해 사용자 지정 태그를 만들거나 수정할 수 있습니다. 관리되는 리소스 그룹의 범위를 사용하여 Azure Policy를 만들 수도 있습니다.

클러스터에 영향을 주는 노드 리소스 그룹의 변경 가능성을 줄이기 위해 노드 리소스 그룹 잠금을 사용하도록 설정하여 AKS 리소스에 거부 할당을 적용할 수 있습니다. 자세한 내용은 완전 관리형 리소스 그룹(미리 보기)을 참조하세요.

Pod

Kubernetes는 Pod를 사용하여 애플리케이션 인스턴스를 실행합니다. 단일 Pod는 애플리케이션의 단일 인스턴스를 나타냅니다.

Pod는 일반적으로 컨테이너와 1:1로 매핑됩니다. 고급 시나리오에서는 Pod에 여러 컨테이너가 포함될 수 있습니다. 다중 컨테이너 Pod는 모두 동일한 노드에서 예약되며, 컨테이너에서 관련 리소스를 공유할 수 있습니다.

Pod를 만들 때 특정 양의 CPU 또는 메모리에 대한 리소스 요청을 정의할 수 있습니다. Kubernetes Scheduler는 사용 가능한 리소스가 있는 노드에서 실행되도록 Pod를 예약하여 요청을 충족하려고 합니다. Pod가 기본 노드에서 너무 많은 컴퓨팅 리소스를 소비하지 못하도록 최대 리소스 한도를 지정할 수도 있습니다. Kubernetes 스케줄러에서 허용되는 필수 리소스를 식별하는 데 도움이 되도록 모든 Pod에 대한 리소스 제한을 포함하는 것이 좋습니다.

자세한 내용은 Kubernetes Pod 및 Kubernetes Pod 수명 주기를 참조하세요.

Pod는 논리적인 리소스이지만 애플리케이션 워크로드는 컨테이너에서 실행됩니다. Pod는 일반적으로 일시적인 일회용 리소스입니다. 개별적으로 예약된 Pod에는 일부 고가용성 및 중복성 Kubernetes 기능 중의 일부가 포함되지 않습니다. 대신 배포 컨트롤러와 같은 Kubernetes 컨트롤러가 Pod를 배포하고 관리합니다.

배포 및 YAML 매니페스트

배포는 Kubernetes 배포 컨트롤에서 관리하는 것과 동일한 Pod를 나타냅니다. 배포는 만들 Pod 복제본 수를 정의합니다. Kubernetes 스케줄러는 Pod나 노드에 문제가 발생할 경우 정상 노드에 추가 Pod가 예약되도록 합니다. 배포를 업데이트하여 Pod, 컨테이너 이미지 또는 연결된 스토리지의 구성을 변경할 수 있습니다.

배포 컨트롤러는 배포 수명 주기를 관리하고 다음 작업을 수행합니다.

• 지정된 수의 복제본을 드레이닝하고 종료합니다.
• 새 배포 정의에서 복제본을 만듭니다.
• 배포의 모든 복제본이 업데이트될 때까지 프로세스를 계속합니다.

AKS의 상태 비저장 애플리케이션 대부분은 개별 Pod를 예약하는 것이 아니라 배포 모델을 사용해야 합니다. Kubernetes는 배포 상태를 모니터링하여 필요한 수의 복제본이 클러스터 내에서 실행되는지 확인할 수 있습니다. 개별적으로 예약할 때 문제가 발생하면 Pod가 다시 시작되지 않고, 현재 노드에 문제가 발생하면 정상 노드에서 일정 변경되지 않습니다.

애플리케이션에 최소한의 사용 가능한 인스턴스 수가 필요한 경우 업데이트 프로세스를 사용하여 관리 결정을 중단하지 않으려고 합니다. Pod 중단 예산은 업데이트 또는 노드 업그레이드 중에 분해할 수 있는 배포의 복제본 수를 정의합니다. 예를 들어, 배포에 5개의 복제본이 있는 경우 한 번에 하나의 복제본만 삭제하거나 일정 변경하도록 Pod 중단을 4로 정의할 수 있습니다. Pod 리소스 제한과 마찬가지로 Pod 중단 예산을 항상 최소 복제본 수가 필요한 애플리케이션에 정의하는 것이 가장 좋습니다.

배포는 일반적으로 kubectl create 또는 kubectl apply를 사용하여 만들어지고 관리됩니다. YAML 형식의 매니페스트 파일을 정의하여 배포를 만들 수 있습니다. 다음 예에서는 NGINX 웹 서버에 대한 기본 배포 매니페스트 파일을 보여 줍니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: mcr.microsoft.com/oss/nginx/nginx:1.15.2-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 250m
            memory: 64Mi
          limits:
            cpu: 500m
            memory: 256Mi

YAML 매니페스트 파일의 배포 사양에 대한 분석은 다음과 같습니다.

규격	설명
.apiVersion	리소스를 만들 때 사용할 API 그룹 및 API 리소스를 지정합니다.
.kind	만들려는 리소스의 유형을 지정합니다.
.metadata.name	배포의 이름을 지정합니다. 이 예 YAML 파일은 Docker Hub에서 nginx 이미지를 실행합니다.
.spec.replicas	만들 Pod 수를 지정합니다. 이 예 YAML 파일은 세 개의 중복 Pod를 만듭니다.
.spec.selector	이 배포의 영향을 받을 Pod를 지정합니다.
.spec.selector.matchLabels	배포에서 만든 Pod를 찾아 관리할 수 있는 {키, 값} 쌍의 맵을 포함합니다.
.spec.selector.matchLabels.app	.spec.template.metadata.labels를 일치시켜야 합니다.
.spec.template.labels	개체에 연결된 {키, 값} 쌍을 지정합니다.
.spec.template.app	.spec.selector.matchLabels를 일치시켜야 합니다.
.spec.spec.containers	Pod에 속하는 컨테이너 목록을 지정합니다.
.spec.spec.containers.name	DNS 레이블로 지정된 컨테이너의 이름을 지정합니다.
.spec.spec.containers.image	컨테이너 이미지 이름을 지정합니다.
.spec.spec.containers.ports	컨테이너에서 노출할 포트 목록을 지정합니다.
.spec.spec.containers.ports.containerPort	Pod의 IP 주소에 노출할 포트 수를 지정합니다.
.spec.spec.resources	컨테이너에 필요한 컴퓨팅 리소스를 지정합니다.
.spec.spec.resources.requests	필요한 컴퓨팅 리소스의 최소 크기를 지정합니다.
.spec.spec.resources.requests.cpu	필요한 최소 CPU 양을 지정합니다.
.spec.spec.resources.requests.memory	필요한 최소 메모리 양을 지정합니다.
.spec.spec.resources.limits	허용되는 최대 컴퓨팅 리소스 양을 지정합니다. kubelet은 이 제한을 적용합니다.
.spec.spec.resources.limits.cpu	허용되는 최대 CPU 양을 지정합니다. kubelet은 이 제한을 적용합니다.
.spec.spec.resources.limits.memory	허용되는 최대 메모리 양을 지정합니다. kubelet은 이 제한을 적용합니다.

서비스(예: 부하 분산 장치)를 YAML 매니페스트 내에 포함하여 더 복잡한 애플리케이션을 만들 수 있습니다.

자세한 내용은 Kubernetes 배포를 참조하세요.

Helm을 사용한 패키지 관리

Helm은 일반적으로 Kubernetes에서 애플리케이션을 관리하는 데 사용됩니다. 패키지 버전의 애플리케이션 코드와 Kubernetes YAML 매니페스트가 포함된 기존 퍼블릭 Helm 차트를 빌드하고 사용하여 리소스를 배포할 수 있습니다. Helm 차트는 로컬로 또는 원격 리포지토리(예: Azure Container Registry Helm 차트 리포지토리)에 저장할 수 있습니다.

Helm을 사용하려면 Helm 클라이언트를 컴퓨터에 설치하거나 Azure Cloud Shell에서 Helm 클라이언트를 사용합니다. Helm 차트를 검색하거나 만든 다음, Kubernetes 클러스터에 설치합니다. 자세한 내용은 AKS에서 Helm을 사용하여 기존 애플리케이션 설치를 참조하세요.

StatefulSets 및 DaemonSets

배포 컨트롤러는 Kubernetes Scheduler를 사용하고 사용 가능한 리소스가 있는 사용 가능한 모든 노드에서 복제본을 실행합니다. 상태 비저장 애플리케이션에는 이 방식이 충분할 수 있지만 배포 컨트롤러는 다음 사양이 필요한 애플리케이션에는 적합하지 않습니다.

• 영구적 명명 규칙 또는 스토리지
• 클러스터 내의 각 선택 노드에 있는 복제본

그러나 두 가지 Kubernetes 리소스(StatefulSets 및 DaemonSets)를 사용하면 이러한 형식의 애플리케이션을 관리할 수 있습니다.

StatefulSets는 개별 Pod 수명 주기 이후에도 애플리케이션 상태를 유지합니다. DaemonSet는 Kubernetes 부트스트랩 프로세스의 초기에 각 노드에서 실행 중인 인스턴스를 보장합니다.

StatefulSets

최신 애플리케이션 개발은 상태 비저장 애플리케이션을 목표로 하는 경우가 많습니다. 데이터베이스 구성 요소를 포함하는 것과 같은 상태 저장 애플리케이션의 경우 StatefulSet를 사용할 수 있습니다. 배포와 마찬가지로 StatefulSet도 하나 이상의 동일한 Pod를 만들고 관리합니다. StatefulSet의 복제본은 배포, 크기 조정링, 업그레이드 및 종료 작업에 대한 정상적이고 순차적인 방법을 따릅니다. 명명 규칙, 네트워크 이름 및 스토리지는 복제본이 StatefulSet를 사용하여 다시 예약될 때 유지됩니다.

kind: StatefulSet를 사용하여 YAML 형식으로 애플리케이션을 정의할 수 있습니다. 여기서 StatefulSet 컨트롤러는 필요한 복제본의 배포 및 관리를 처리합니다. Azure Managed Disks 또는 Azure Files에서 제공하는 영구 스토리지에 데이터를 씁니다. StatefulSet를 사용하면 StatefulSet가 삭제된 경우에도 기본 영구 스토리지가 유지됩니다.

자세한 내용은 Kubernetes StatefulSets를 참조하세요.

DaemonSets

특정 로그 컬렉션 또는 모니터링을 위해 모든 노드 또는 일부 노드 집합에서 Pod를 실행해야 할 수도 있습니다. DaemonSets를 사용하여 하나 이상의 동일한 Pod에 배포할 수 있습니다. DaemonSet 컨트롤러는 지정된 각 노드가 Pod의 인스턴스를 실행하도록 보장합니다.

기본 Kubernetes 스케줄러가 시작되기 전에 DaemonSet 컨트롤러에서 클러스터 부팅 프로세스의 초기에 Pod를 노드에 예약할 수 있습니다. 이 기능을 사용하면 배포 또는 StatefulSet의 기존 Pod가 예약되기 전에 DaemonSet 상태의 Pod가 예약됩니다.

StatefulSet와 마찬가지로 kind: DaemonSet를 사용하여 DaemonSet를 YAML 정의의 일부로 정의할 수 있습니다.

자세한 내용은 Kubernetes DaemonSets를 참조하세요.

네임스페이스

Pod 및 배포와 같은 Kubernetes 리소스는 AKS 클러스터를 분할하고 리소스에 대한 액세스의 만들기, 보기 및 관리하도록 논리적으로 네임스페이스로 그룹화됩니다. 예를 들어 비즈니스 그룹을 구분하는 네임스페이스를 만들 수 있습니다. 사용자는 할당된 네임스페이스 내의 리소스와만 상호 작용할 수 있습니다.

AKS 클러스터를 만들 때 사용할 수 있는 네임스페이스는 다음과 같습니다.

네임스페이스	설명
default	아무것도 제공되지 않을 때 기본적으로 Pod와 배포가 만들어지는 곳입니다. 소규모 환경에서는 논리적 구분을 추가로 만들지 않고 애플리케이션을 기본 네임스페이스로 직접 배포할 수 있습니다. kubectl get pods와 같이 Kubernetes API와 상호 작용할 때 아무 것도 지정되지 않으면 기본 네임스페이스가 사용됩니다.
kube-system	DNS 및 프록시와 같은 네트워크 기능이나 Kubernetes 대시보드와 같은 핵심 리소스가 존재하는 곳입니다. 일반적으로 사용자 고유의 애플리케이션은 이 네임스페이스에 배포하지 않습니다.
kube-public	일반적으로 사용되지 않으며 전체 클러스터에서 리소스를 표시하고 모든 사용자가 볼 수 있도록 하는 데 사용할 수 있습니다.

자세한 내용은 Kubernetes 네임스페이스를 참조하세요.

다음 단계

Kubernetes 및 AKS 핵심 개념에 대한 자세한 내용은 다음 문서를 참조하세요.

• AKS 액세스 및 ID
• AKS 보안
• AKS 가상 네트워크
• AKS 스토리지
• AKS 규모