Azure Arc에서 사용하도록 설정된 AKS에 대한 Kubernetes 클러스터 아키텍처 및 워크로드
적용 대상: Azure Stack HCI 22H2의 AKS, Windows Server의 AKS
Azure Local 및 Windows Server의 AKS(Azure Kubernetes Service)는 Azure Local에서 제공하는 엔터프라이즈급 Kubernetes 컨테이너 플랫폼입니다. 여기에는 간단한 배포 및 수명 주기 관리 환경을 목표로 하는 Microsoft 지원 코어 Kubernetes, 특별히 빌드된 Windows 컨테이너 호스트 및 Microsoft 지원 Linux 컨테이너 호스트가 포함됩니다.
이 문서에서는 컨트롤 플레인, 노드 및 노드 풀과 같은 핵심 Kubernetes 인프라 구성 요소를 소개합니다. 리소스를 네임스페이스로 그룹화하는 방법과 함께 Pod, 배포 및 집합과 같은 워크로드 리소스도 도입됩니다.
Kubernetes 클러스터 아키텍처
Kubernetes는 Azure Arc에서 사용하도록 설정된 AKS의 핵심 구성 요소입니다. AKS는 미리 정의된 구성 집합을 사용하여 확장성을 염두에 두고 Kubernetes 클러스터를 효과적으로 배포합니다.
배포 작업은 여러 Linux 또는 Windows 가상 머신을 만들고 함께 조인하여 Kubernetes 클러스터를 만듭니다.
참고 항목
시스템의 안정성을 향상시키기 위해 클러스터에서 여러 CSV(클러스터 공유 볼륨)를 실행하는 경우 기본적으로 가상 머신 데이터는 클러스터의 사용 가능한 모든 CSV에 자동으로 분산됩니다. 이렇게 하면 CSV 중단 시 애플리케이션이 유지됩니다. 이는 업그레이드가 아닌 새 설치에만 적용됩니다.
배포된 시스템은 표준 Kubernetes 워크로드를 수신하거나, 이러한 워크로드의 크기를 조정하거나, 필요에 따라 가상 머신 수와 클러스터 수를 확장 및 축소할 준비가 되어 있습니다.
Azure Kubernetes Service 클러스터에는 다음과 같은 구성 요소가 있습니다.
- 관리 클러스터 (AKS 호스트라고도 함)는 하나 이상의 워크로드 클러스터를 배포하고 관리하기 위한 핵심 오케스트레이션 메커니즘 및 인터페이스를 제공합니다.
- 워크로드 클러스터(대상 클러스터 라고도 함)는 컨테이너화된 애플리케이션이 배포되는 곳입니다.
Arc에서 사용하도록 설정된 AKS 관리
다음 관리 옵션을 사용하여 AKS를 관리할 수 있습니다.
- Windows Admin Center 는 Kubernetes 운영자가 클러스터의 수명 주기를 관리할 수 있는 직관적인 UI를 제공합니다.
- PowerShell 모듈을 사용하면 AKS를 쉽게 다운로드, 구성 및 배포할 수 있습니다. 또한 PowerShell 모듈은 다른 워크로드 클러스터를 배포 및 구성하고 기존 워크로드 클러스터를 다시 구성할 수 있습니다.
관리 클러스터
Kubernetes 클러스터를 만들면 관리 클러스터가 자동으로 만들어지고 구성됩니다. 이 관리 클러스터는 워크로드가 실행되는 워크로드 클러스터를 프로비전하고 관리하는 역할을 담당합니다. 관리 클러스터에는 다음과 같은 핵심 Kubernetes 구성 요소가 포함됩니다.
- API 서버: API 서버는 기본 Kubernetes API가 노출되는 방식입니다. 이 구성 요소는 Windows Admin Center, PowerShell 모듈 또는
kubectl같은 관리 도구에 대한 상호 작용을 제공합니다. - 부하 분산 장치: 부하 분산 장치는 관리 클러스터의 API 서버에 대한 부하 분산 규칙이 있는 단일 전용 Linux VM입니다.
워크로드 클러스터
워크로드 클러스터는 Kubernetes 컨트롤 플레인 구성 요소 및 Linux 작업자 노드를 실행하기 위해 Linux VM을 사용하는 Kubernetes의 고가용성 배포입니다. Windows Server Core 기반 VM은 Windows 작업자 노드를 설정하는 데 사용됩니다. 하나의 관리 클러스터에서 관리되는 워크로드 클러스터가 하나 이상 있을 수 있습니다.
워크로드 클러스터 구성 요소
워크로드 클러스터에는 다음 섹션에 설명된 많은 구성 요소가 있습니다.
제어 평면
- API 서버: API 서버는 Kubernetes API와의 상호 작용을 허용합니다. 이 구성 요소는 Windows Admin Center, PowerShell 모듈 또는
kubectl같은 관리 도구에 대한 상호 작용을 제공합니다. - Etcd: Etcd는 클러스터의 수명 주기 관리에 필요한 데이터를 저장하는 분산 키-값 저장소입니다. 컨트롤 플레인 상태를 저장합니다.
부하 분산 장치
부하 분산 장치는 관리 클러스터에서 배포한 워크로드 클러스터에 부하 분산 서비스를 제공하기 위해 Linux 및 HAProxy + KeepAlive를 실행하는 가상 머신입니다. 각 워크로드 클러스터에 대해 AKS는 하나 이상의 부하 분산 장치 가상 머신을 추가합니다. 워크로드 클러스터에서 만든 유형의 LoadBalancer Kubernetes 서비스는 결국 VM에 부하 분산 규칙을 만듭니다.
작업자 노드
애플리케이션과 지원 서비스를 실행하려면 Kubernetes 노드가 필요합니다. AKS 워크로드 클러스터에는 하나 이상의 작업자 노드가 있습니다. 작업자 노드는 Kubernetes 노드 구성 요소를 실행하고 애플리케이션 워크로드를 구성하는 Pod 및 서비스를 호스트하는 VM(가상 머신) 역할을 합니다.
Pod 및 배포와 같은 AKS 워크로드 클러스터에 배포할 수 있는 핵심 Kubernetes 워크로드 구성 요소가 있습니다.
Pod
Kubernetes는 pods를 사용하여 애플리케이션의 인스턴스를 실행합니다. Pod는 애플리케이션의 단일 인스턴스를 나타냅니다. 일반적으로 Pod에는 컨테이너와 1:1 매핑이 있지만 Pod에 여러 컨테이너가 포함될 수 있는 고급 시나리오가 있습니다. 이러한 다중 컨테이너 Pod는 동일한 노드에서 함께 예약되며 컨테이너가 관련 리소스를 공유할 수 있도록 합니다. 자세한 내용은 Kubernetes Pod 및 Kubernetes Pod 수명 주기를 참조하세요.
배포
배포는 Kubernetes 배포 컨트롤에서 관리되는 하나 이상의 동일한 Pod를 나타냅니다. 배포는 만들 복제본(Pod)의 수를 정의하고 Kubernetes 스케줄러는 Pod 또는 노드에 문제가 발생하는 경우 정상 노드에서 추가 Pod가 예약되도록 합니다. 자세한 내용은 Kubernetes 배포를 참조하세요.
StatefulSets 및 DaemonSets
배포 컨트롤러는 Kubernetes 스케줄러를 사용하여 사용 가능한 리소스가 있는 사용 가능한 노드에서 지정된 수의 복제본을 실행합니다. 배포를 사용하는 이 방법은 상태 비저장 애플리케이션에 충분하지만 영구 명명 규칙 또는 스토리지가 필요한 애플리케이션에는 충분하지 않을 수 있습니다. 클러스터 내의 각 노드(또는 선택한 노드)에 복제본이 있어야 하는 애플리케이션의 경우 배포 컨트롤러는 복제본이 노드 간에 분산되는 방식을 않습니다.
- StatefulSets: StatefulSet은 하나 이상의 동일한 Pod가 만들어지고 관리되는 배포와 유사합니다. StatefulSet의 복제본은 배포, 크기 조정, 업그레이드 및 종료에 대한 정상적이고 순차적인 접근 방식을 따릅니다. StatefulSet을 사용하면(복제본이 다시 예약될 때) 명명 규칙, 네트워크 이름 및 스토리지가 유지됩니다. StatefulSet의 복제본은 Kubernetes 클러스터에서 사용 가능한 모든 노드에서 예약되고 실행됩니다. 집합에서 하나 이상의 Pod가 노드에서 실행되는지 확인해야 하는 경우 대신 DaemonSet을 사용할 수 있습니다. 자세한 내용은 Kubernetes StatefulSets를 참조하세요.
- DaemonSets: 특정 로그 수집 또는 모니터링 요구 사항의 경우 모든 노드 또는 선택한 노드에서 지정된 Pod를 실행해야 할 수 있습니다. DaemonSet은 하나 이상의 동일한 Pod를 배포하는 데 다시 사용되지만 DaemonSet 컨트롤러는 지정된 각 노드가 Pod의 인스턴스를 실행하도록 합니다. 자세한 내용은 Kubernetes DaemonSets를 참조하세요.
네임스페이스
Pod 및 배포와 같은 Kubernetes 리소스는 논리적으로 네임스페이 스로 그룹화됩니다. 이러한 그룹화는 워크로드 클러스터를 논리적으로 나누고 리소스를 만들거나 보거나 관리하기 위한 액세스를 제한하는 방법을 제공합니다. 예를 들어 비즈니스 그룹을 구분하는 네임스페이스를 만들 수 있습니다. 사용자는 할당된 네임스페이스 내의 리소스와만 상호 작용할 수 있습니다. 자세한 내용은 Kubernetes 네임스페이스를 참조하세요.
Arc에서 사용하도록 설정된 AKS에서 Azure Kubernetes Service 클러스터를 만들 때 다음 네임스페이스를 사용할 수 있습니다.
- default: 제공되지 않은 경우 기본적으로 Pod 및 배포가 만들어지는 네임스페이스입니다. 소규모 환경에서는 논리적 구분을 추가로 만들지 않고 애플리케이션을 기본 네임스페이스로 직접 배포할 수 있습니다.
kubectl get pods와 같이 Kubernetes API와 상호 작용할 때 아무 것도 지정되지 않으면 기본 네임스페이스가 사용됩니다. - kube-system: DNS 및 프록시와 같은 네트워크 기능 또는 Kubernetes 대시보드와 같은 핵심 리소스가 있는 네임스페이스입니다. 일반적으로 사용자 고유의 애플리케이션은 이 네임스페이스에 배포하지 않습니다.
- kube-public: 네임스페이스는 일반적으로 사용되지 않지만 리소스가 전체 클러스터에 표시되는 데 사용할 수 있으며 모든 사용자가 볼 수 있습니다.
비밀
Kubernetes 비밀을 사용하면 암호, OAuth 토큰 및 SSH(Secure Shell) 키와 같은 중요한 정보를 저장하고 관리할 수 있습니다. 기본적으로 Kubernetes는 암호를 암호화되지 않은 base64로 인코딩된 문자열로 저장하며 API 액세스 권한이 있는 모든 사용자가 일반 텍스트로 검색할 수 있습니다. 자세한 내용은 Kubernetes 비밀을 참조 하세요.
영구적 볼륨
영구 볼륨은 관리자가 프로비전하거나 스토리지 클래스를 사용하여 동적으로 프로비전된 Kubernetes 클러스터의 스토리지 리소스입니다. 영구 볼륨을 사용하기 위해 Pod는 PersistentVolumeClaim을 사용하여 액세스를 요청합니다. 자세한 내용은 영구 볼륨을 참조하세요.
혼합 OS 배포
지정된 워크로드 클러스터가 Linux 및 Windows 작업자 노드로 구성된 경우 워크로드 프로비전을 지원할 수 있는 OS로 예약해야 합니다. Kubernetes는 워크로드가 대상 운영 체제가 있는 노드에 배치되도록 하는 두 가지 메커니즘을 제공합니다.
- 노드 선택기는 운영 체제와 일치하는 정상 노드로만 예약되도록 Pod를 제한하는 Pod 사양의 간단한 필드입니다.
- Taint 및 toleration은 함께 작동하여 Pod가 의도치 않게 노드에 예약되지 않도록 합니다. 노드는 Pod 사양의 "허용"을 통해 해당 taint를 명시적으로 용납하지 않는 Pod를 허용하지 않도록 "오염"될 수 있습니다.
자세한 내용은 노드 선택기 및 taint 및 toleration을 참조하세요.
다음 단계
이 문서에서는 Azure Arc에서 사용하도록 설정된 AKS의 클러스터 아키텍처 및 워크로드 클러스터 구성 요소에 대해 알아보았습니다. 이러한 개념에 대한 자세한 내용은 다음 문서를 참조하세요.