Azure Kubernetes Service의 Core Kubernetes 개념

  • 아티클

애플리케이션 개발은 컨테이너 기반 방법으로 계속 이동하여 리소스를 오케스트레이션하고 관리해야 하는 필요성이 증가하고 있습니다. 선도적인 플랫폼인 Kubernetes는 내결함성 애플리케이션 워크로드를 안정적으로 예약합니다. 관리되는 Kubernetes 제품인 AKS(Asure Kubernetes Service)는 컨테이너 기반 애플리케이션 배포 및 관리를 더 간소화합니다.

이 문서에서는 핵심 개념을 소개합니다.

  • Kubernetes 인프라 구성 요소:

    • 컨트롤 플레인
    • 노드
    • 노드 풀

  • 워크로드 리소스:

    • Pod
    • 배포
    • 집합

  • 네임스페이스를 사용하여 리소스를 그룹화합니다.

Kubernetes란?

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

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

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

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

Kubernetes 클러스터 아키텍처

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

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

Kubernetes control plane and node components

제어 평면

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

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

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

AKS는 전용 API 서버, 스케줄러 등이 포함된 단일 테넌트 컨트롤 플레인을 제공합니다. 노드의 수와 크기를 정의하고, Azure 플랫폼에서 컨트롤 플레인과 노드 간의 보안 통신을 구성합니다. 컨트롤 플레인과의 상호 작용은 kubectl 또는 Kubernetes 대시보드와 같은 Kubernetes API를 통해 수행됩니다.

이 관리형 컨트롤 플레인을 사용하여 구성 요소(예: 고가용성 etcd 저장소)를 구성할 필요는 없으며, 컨트롤 플레인에 직접 액세스할 수 없습니다. Kubernetes 컨트롤 플레인 및 노드 업그레이드는 Azure CLI 또는 Azure Portal을 통해 오케스트레이션됩니다. 가능한 문제를 해결하기 위해 Azure Monitor 로그를 통해 컨트롤 플레인 로그를 검토할 수 있습니다.

컨트롤 플레인을 구성하거나 직접 액세스하려면 클러스터 API 공급자 Azure를 사용하여 자체 관리되는 Kubernetes 클러스터를 배포합니다.

관련 모범 사례는 AKS의 클러스터 보안 및 업그레이드 모범 사례를 참조하세요.

AKS 비용 관리 정보는 AKS 비용 기본 사항 및 AKS 가격 책정을 참조하세요.

노드 및 노드 풀

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

구성 요소 설명
kubelet 요청된 컨테이너의 예약 및 실행과 함께 컨트롤 플레인의 오케스트레이션 요청을 처리하는 Kubernetes 에이전트입니다.
kube-proxy 각 노드에서 가상 네트워킹을 처리합니다. 프록시는 네트워크 트래픽을 라우팅하고 서비스와 Pod에 대한 IP 주소 지정을 관리합니다.
컨테이너 런타임 컨테이너화된 애플리케이션에서 가상 네트워크 또는 스토리지와 같은 추가 리소스를 실행하고 상호 작용할 수 있도록 합니다. Linux용 Kubernetes 버전 1.19 이상 노드 풀을 사용하는 AKS 클러스터는 containerd를 컨테이너 런타임으로 사용합니다. Windows용 Kubernetes 버전 1.20 노드 풀부터 containerd는 컨테이너 런타임에 대한 미리 보기에서 사용할 수 있지만 Docker는 여전히 기본 컨테이너 런타임입니다. 노드 풀에 이전 버전의 Kubernetes를 사용하는 AKS 클러스터는 Docker를 컨테이너 런타임으로 사용합니다.

Azure virtual machine and supporting resources for a Kubernetes node

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

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

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

Kubernetes 노드 컨테이너 런타임 및 OS에 대한 고급 구성 및 제어가 필요한 경우 클러스터 API 공급자 Azure를 사용하여 자체 관리형 클러스터를 배포할 수 있습니다.

리소스 예약

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

노드의 할당 가능한 리소스를 찾으려면 다음을 실행합니다.

kubectl describe node [NODE_NAME]

AKS는 노드 성능 및 기능을 유지하기 위해 각 노드에서 리소스를 예약합니다. 노드가 리소스에서 더 커질수록 사용자가 배포한 Pod를 관리할 필요성이 높아지므로 리소스 예약도 증가합니다.

참고 항목

컨테이너 인사이트(OMS)와 같은 AKS 추가 기능을 사용하는 경우 추가 노드 리소스가 사용됩니다.

두 가지 종류의 리소스가 예약됩니다.

CPU

예약 CPU는 노드 유형 및 클러스터 구성에 따라 달라지므로 추가 기능 실행으로 인해 할당 가능한 CPU가 줄어들 수 있습니다.

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

메모리

AKS에서 사용하는 메모리에는 다음 두 값의 합계가 포함됩니다.

Important

AKS 1.29는 2024년 1월에 미리 보기로 제공되며 메모리 예약에 대한 특정 변경 내용을 포함합니다. 이러한 변경 내용은 다음 섹션에 자세히 설명되어 있습니다.

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 디먼은 컨테이너 만들기 및 종료를 관리하기 위해 모든 Kubernetes 에이전트 노드에 설치됩니다. 기본적으로 AKS에서 kubelet 디먼에는 memory.available<750Mi 제거 규칙이 있으므로 노드는 항상 750Mi 이상을 할당할 수 있어야 합니다. 호스트가 사용 가능한 메모리 임계값보다 낮은 경우 kubelet은 실행 중인 Pod 중 하나를 종료하고 호스트 컴퓨터에서 메모리를 확보하도록 트리거합니다.

  2. kubelet 디먼이 제대로 작동하기 위한 메모리 예약의 회귀 비율(kube-reserved)

    • 처음 4GB 메모리의 25%
    • 다음 4GB 메모리의 20%(최대 8GB)
    • 다음 8GB 메모리의 10%(최대 16GB)
    • 다음 112GB 메모리의 6%(최대 128GB)
    • 128GB 이상 메모리의 2%

참고 항목

AKS는 계산된 메모리의 일부가 아닌 Windows 노드의 시스템 프로세스를 위해 추가로 2GB를 예약합니다.

메모리 및 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의 기본 스케줄러 기능 모범 사례를 참조하세요.

노드 풀

참고 항목

이제 Azure Linux 노드 풀이 GA(일반 공급)됩니다. 이점과 배포 단계에 대해 알아보려면 AKS용 Azure Linux 컨테이너 호스트 소개를 참조하세요.

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

참고 항목

클러스터가 안정적으로 작동하도록 하려면 기본 노드 풀에서 둘 이상의 노드를 실행해야 합니다.

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

AKS에서 여러 노드 풀을 사용하는 방법에 대한 자세한 내용은 AKS에서 클러스터에 대한 여러 노드 풀 만들기를 참조하세요.

노드 선택기

여러 노드 풀이 있는 AKS 클러스터에서는 지정된 리소스에 사용할 노드 풀을 Kubernetes 스케줄러에 알려야 할 수 있습니다. 예를 들어 수신 컨트롤러는 Windows Server 노드에서 실행되지 않습니다.

노드 선택기를 사용하면 Pod를 예약해야 하는 위치를 제어하는 노드 OS와 같은 다양한 매개 변수를 정의할 수 있습니다.

다음 기본 예제에서는 "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

Pod가 예약되는 위치를 제어하는 방법에 대한 자세한 내용은 AKS의 고급 스케줄러 기능 모범 사례를 참조하세요.

노드 리소스 그룹

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

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

노드 리소스 그룹에는 기본적으로 MC_myResourceGroup_myAKSCluster_eastus와 같은 이름이 할당됩니다. 클러스터를 만드는 동안 노드 리소스 그룹에 할당된 이름을 지정하는 옵션도 있습니다. AKS 클러스터를 삭제하면 AKS 리소스 공급자가 노드 리소스 그룹을 자동으로 삭제합니다.

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

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

노드 리소스 그룹에서 Azure에서 만든 태그 및 기타 리소스 속성을 수정하거나 삭제하는 경우 크기 조정 및 업그레이드 오류와 같은 예기치 않은 결과가 발생할 수 있습니다. AKS는 노드 리소스 그룹에서 인프라의 수명 주기를 관리하므로 변경 내용이 있을 경우 클러스터가 지원되지 않는 상태로 전환됩니다.

고객이 리소스를 수정하려는 일반적인 시나리오는 태그를 통해서입니다. AKS를 사용하면 노드 리소스 그룹의 리소스에 전파되는 태그를 만들고 수정할 수 있으며 클러스터를 만들거나 업데이트 할 때 해당 태그를 추가할 수 있습니다. 예를 들어 사업부 또는 비용 센터를 할당하기 위해 사용자 지정 태그를 만들거나 수정할 수 있습니다. 이는 관리되는 리소스 그룹의 범위를 사용하여 Azure 정책을 만들어 수행할 수도 있습니다.

AKS 클러스터의 노드 리소스 그룹에서 리소스에 대해 Azure로 만든 태그를 수정하는 작업은 지원되지 않으며, 이러한 작업은 SLO(서비스 수준 목표)를 중단하게 됩니다. 자세한 내용은 AKS는 서비스 수준 계약을 제공합니까?를 참조하세요.

클러스터에 영향을 주는 노드 리소스 그룹의 변경 가능성을 줄이기 위해 노드 리소스 그룹 잠금을 사용하도록 설정하여 AKS 리소스에 거부 할당을 적용할 수 있습니다. 자세한 내용은 AKS의 클러스터 구성에서 확인하세요.

Warning

노드 리소스 그룹 잠금을 사용하도록 설정하지 않은 경우 노드 리소스 그룹의 리소스를 직접 수정할 수 있습니다. 노드 리소스 그룹에서 리소스를 직접 수정하면 클러스터가 불안정하거나 응답하지 않게 될 수 있습니다.

Pod

Kubernetes는 pods를 사용하여 애플리케이션의 인스턴스를 실행합니다. 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 복제본 수를 정의합니다. Pod 또는 노드에 문제가 발생하는 경우 Kubernetes 스케줄러는 추가 Pod가 정상 노드에서 예약되도록 합니다.

Pod, 사용된 컨테이너 이미지 또는 연결된 스토리지의 구성을 변경하도록 배포를 업데이트할 수 있습니다. 배포 컨트롤러에서 수행하는 작업은 다음과 같습니다.

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

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

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

배포는 일반적으로 kubectl create 또는 kubectl apply를 사용하여 만들어지고 관리됩니다. YAML 형식의 매니페스트 파일을 정의하여 배포를 만듭니다.

다음 예제에서는 NGINX 웹 서버의 기본 배포를 만듭니다. 배포에서 만들 3개의 복제본을 지정하고, 컨테이너에서 80 포트를 열어야 합니다. CPU 및 메모리에 대한 리소스 요청 및 제한도 정의됩니다.

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 배포의 이름을 지정합니다. 이 파일은 Docker Hub에서 nginx 이미지를 실행합니다.
.spec.replicas 만들 Pod 수를 지정합니다. 이 파일은 세 개의 복제 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 스케줄러를 사용하면 배포 컨트롤러에서 사용 가능한 리소스가 있는 사용 가능한 노드에서 복제본을 실행합니다. 이 방법은 상태 비저장 애플리케이션에 충분할 수 있지만 배포 컨트롤러는 다음이 필요한 애플리케이션에 적합하지 않습니다.

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

그러나 두 개의 Kubernetes 리소스를 사용하면 다음과 같은 유형의 애플리케이션을 관리할 수 ​​있습니다.

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

StatefulSets

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

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

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

StatefulSet의 복제본은 AKS 클러스터의 사용 가능한 모든 노드에서 예약되고 실행됩니다. 집합에 있는 하나 이상의 Pod가 노드에서 실행되도록 하려면 DaemonSet를 대신 사용합니다.

DaemonSets

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

기본 Kubernetes 스케줄러가 시작되기 전에 DaemonSet 컨트롤러에서 클러스터 부팅 프로세스의 초기에 Pod를 노드에 예약할 수 있습니다. 이 기능은 Deployment 또는 StatefulSet의 기존 Pod가 예약되기 전에 DaemonSet의 Pod가 시작되도록 합니다.

StatefulSet과 마찬가지로 DaemonSet은 kind: DaemonSet을 사용하여 YAML 정의의 일부로 정의됩니다.

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

참고 항목

가상 노드 추가 기능을 사용하는 경우 DaemonSet는 Pod를 가상 노드에 만들지 않습니다.

네임스페이스

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

Kubernetes namespaces to logically divide resources and applications

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

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

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

다음 단계

이 문서에서는 Kubernetes 핵심 구성 요소 중 일부와 AKS 클러스터에 이를 적용하는 방법에 대해 설명하고 있습니다. Kubernetes 및 AKS 핵심 개념에 대한 자세한 내용은 다음 문서를 참조하세요.