Azure Arc에서 사용하도록 설정된 AKS의 애플리케이션 가용성

  • 아티클

적용 대상: Azure Stack HCI 22H2의 AKS, Windows Server의 AKS

Azure Arc에서 사용하도록 설정된 AKS(Azure Kubernetes Service)는 Kubernetes 컨테이너 오케스트레이션 플랫폼에서 클라우드 네이티브 애플리케이션을 실행할 수 있는 완전히 지원되는 컨테이너 플랫폼을 제공합니다. 아키텍처는 가상화된 Windows 및 Linux 워크로드 실행을 지원합니다.

AKS 아키텍처는 대상(워크로드) 클러스터에 대해 자동으로 사용하도록 설정되는 장애 조치(failover) 클러스터링 및 실시간 마이그레이션을 사용하여 빌드됩니다. 다양한 중단 이벤트 중에 고객 워크로드를 호스트하는 가상 머신은 인식된 애플리케이션 가동 중지 시간 없이 자유롭게 이동할 수 있습니다. 이 아키텍처는 레거시 애플리케이션을 Azure Stack HCI 또는 Windows Server의 AKS에 대한 싱글톤으로 관리하는 기존 엔터프라이즈 고객이 레거시 VM 애플리케이션에서 현재 경험했던 것과 비슷하거나 더 나은 작동 시간을 얻게 됨을 의미합니다.

이 문서에서는 중단 중에 애플리케이션을 사용할 수 있도록 실시간 마이그레이션을 사용하도록 설정된 AKS Arc에서 컨테이너화된 애플리케이션을 실행하려는 사용자를 위한 몇 가지 기본 개념을 설명합니다. 자발적 중단 및 비자발적 중단과 같은 Kubernetes 용어는 Pod에서 실행되는 애플리케이션의 가동 중지 시간을 참조하는 데 사용됩니다.

실시간 마이그레이션이란?

실시간 마이그레이션 은 가동 중지 시간을 인식하지 않고 실행 중인 가상 머신을 한 Hyper-V 호스트에서 다른 호스트로 투명하게 이동할 수 있는 Hyper-V 기능입니다. 실시간 마이그레이션의 주요 이점은 유연성입니다. 실행 중인 가상 머신은 단일 호스트 컴퓨터에 연결되지 않습니다. 이를 통해 사용자는 호스트를 해제하거나 업그레이드하기 전에 특정 가상 머신 호스트를 드레이닝하는 등의 작업을 수행할 수 있습니다. Windows 장애 조치(Failover) 클러스터링과 페어링하면 실시간 마이그레이션을 통해 고가용성 및 내결함성 시스템을 만들 수 있습니다.

Azure Stack HCI 및 Windows Server의 AKS 현재 아키텍처에서는 Azure Stack HCI 클러스터형 환경에서 실시간 마이그레이션을 사용하도록 설정했다고 가정합니다. 따라서 모든 Kubernetes 작업자 노드 VM은 실시간 마이그레이션이 구성된 상태에서 만들어집니다. 이러한 노드는 플랫폼의 고가용성을 보장하기 위해 중단이 발생할 경우 실제 호스트를 중심으로 이동할 수 있습니다.

장애 조치(failover) 클러스터링을 사용하도록 설정된 Azure Stack HCI 및 Windows Server의 AKS를 보여 주는 다이어그램

Kubernetes를 기반으로 레거시 애플리케이션을 싱글톤으로 실행하는 경우 이 아키텍처는 고가용성 요구 사항을 충족합니다. Kubernetes는 사용 가능한 작업자 노드에서 Pod 예약을 관리하고 실시간 마이그레이션은 사용 가능한 실제 호스트에서 작업자 노드 VM의 예약을 관리합니다.

싱글톤으로 실행되는 예제 레거시 애플리케이션을 보여 주는 다이어그램

애플리케이션 중단 시나리오

Azure Stack HCI 및 Windows Server의 AKS에서 VM에서 실행되는 애플리케이션의 복구 시간에 대한 비교 연구는 일반적인 중단 이벤트가 발생할 때 애플리케이션에 최소한의 영향이 있음을 분명히 보여줍니다. 중단 시나리오의 세 가지 예는 다음과 같습니다.

  • 물리적 컴퓨터를 다시 부팅하는 업데이트를 적용합니다.
  • 작업자 노드를 다시 만드는 것과 관련된 업데이트를 적용합니다.
  • 물리적 컴퓨터의 계획되지 않은 하드웨어 오류입니다.

참고

이러한 시나리오에서는 애플리케이션 소유자가 여전히 Kubernetes 선호도 및 선호도 방지 설정을 사용하여 작업자 노드에서 Pod의 적절한 일정을 보장한다고 가정합니다.

중단 이벤트 Azure Stack HCI의 VM에서 애플리케이션 실행 Azure Stack HCI 또는 Windows Server의 AKS에서 VM에서 애플리케이션 실행
물리적 머신을 다시 부팅하는 업데이트를 적용합니다. 영향 없음 영향 없음
작업자 노드를 다시 만들거나 VM을 다시 부팅하는 업데이트를 적용합니다. 영향 없음 상황에 따라 다름
물리적 컴퓨터의 계획되지 않은 하드웨어 오류 6-8분 6-8분

물리적 머신을 다시 부팅하는 업데이트를 적용합니다.

호스트 컴퓨터의 재부팅을 초래하는 업데이트를 적용하는 것과 같은 물리적 호스트 유지 관리 이벤트 중에는 클러스터에서 실행되는 애플리케이션에 영향을 주지 않습니다. 클러스터 관리자는 호스트를 드레이닝하고 업데이트를 적용하기 전에 모든 VM이 실시간 마이그레이션되도록 합니다.

작업자 노드를 다시 만드는 것과 관련된 업데이트 적용

이 시나리오에는 일상적인 유지 관리를 수행하기 위해 작업자 노드 VM을 중단하는 작업이 포함됩니다. 업데이트를 준비하기 위해 클러스터 관리자는 노드를 드레이닝하고 격리하므로 업데이트를 적용하기 전에 모든 Pod가 사용 가능한 작업자 노드로 제거됩니다. 업데이트가 완료되면 작업자 노드가 다시 가입되어 예약에 사용할 수 있게 됩니다.

참고

애플리케이션의 가용성은 특히 퍼블릭 클라우드에 저장된 더 큰 이미지의 경우 기본 컨테이너 이미지를 다운로드하는 데 걸리는 시간을 포함하므로 달라집니다. 따라서 작은 기본 컨테이너 이미지를 사용하는 것이 좋습니다. Windows 컨테이너의 경우 기본 이미지를 사용하는 nano server 것이 좋습니다.

물리적 컴퓨터의 계획되지 않은 하드웨어 오류

이 시나리오에서는 작업자 노드 VM 중 하나에서 레거시 애플리케이션 컨테이너/Pod를 호스트하는 물리적 컴퓨터에 비자발적 중단 이벤트가 발생합니다. 장애 조치(failover) 클러스터링 호스트를 격리된 상태로 전환한 다음 6~8분 후에 이러한 VM을 남은 호스트로 실시간 마이그레이션하는 프로세스를 시작합니다. 이 경우 애플리케이션 가동 중지 시간은 호스트 및 작업자 노드 VM을 다시 시작하는 데 걸리는 시간과 동일합니다.

결론

AKS 장애 조치(failover) 클러스터링 기술은 Azure Stack HCI와 Windows Server의 컴퓨팅 환경이 고가용성 및 내결함성을 갖도록 설계되었습니다. 그러나 애플리케이션 소유자는 중단 시나리오에서 Pod의 복원력을 보장하기 위해 , , Affinity Mapping, RelicaSets등의 DeploymentsKubernetes 기능을 사용하도록 배포를 구성해야 합니다.

다음 단계

Windows Server 및 Azure Stack HCI의 AKS 개요