편집

Azure Stack HCI의 AKS를 위한 네트워크 아키텍처

Azure Stack
Windows Server

이 시나리오에서는 AKS(Azure Kubernetes Service) 하이브리드 클러스터에 AKS 노드를 배포하기 위한 네트워크 개념을 디자인하고 구현하는 방법을 보여 줍니다.

이 문서에는 Kubernetes 노드 및 Kubernetes 컨테이너에 대한 네트워킹 디자인 권장 사항이 포함됩니다. 두 문서의 아키텍처 기준 참고 자료 세트 중 일부입니다. 여기에서 기준 아키텍처 권장 사항을 참조하세요.

아키텍처

다음 이미지는 Azure Stack HCI 또는 Windows Server 2019/2022 데이터 센터 클러스터의 Azure Kubernetes Service를 위한 네트워크 아키텍처를 보여 줍니다.

Conceptual graphic showing network baseline architecture.

이 아키텍처의 Visio 파일을 다운로드합니다.

이 시나리오는 다음과 같은 구성 요소와 기능으로 구성됩니다.

  • Azure Stack HCI(20H2)는 가상화된 Windows 및 Linux 워크로드 및 하이브리드 온-프레미스 환경에서 해당 스토리지를 호스트하는 HCI(하이퍼컨버지드 인프라) 클러스터 솔루션입니다. Azure Stack HCI 클러스터는 2-4 노드 클러스터로 구현됩니다.
  • Windows Server 2019/2022 데이터 센터 장애 조치(failover) 클러스터는 클러스터된 역할의 가용성과 스케일링 성능을 높이기 위해 함께 작동하는 독립적인 컴퓨터 그룹입니다.
  • Azure Stack HCI의 Azure Kubernetes Service(AKS 하이브리드)는 대규모로 컨테이너화된 애플리케이션 실행을 자동화하는 AKS(Azure Kubernetes Service)의 온-프레미스 구현입니다.
  • [Active Directory 도메인 Services][]는 네트워크의 개체에 대한 정보를 저장하는 계층 구조입니다. 이 계층 구조는 보안 경계에 포함된 사용자, 컴퓨터, 애플리케이션 또는 기타 리소스와 연결된 ID에 대한 ID 및 액세스 솔루션을 제공합니다.
  • [관리 클러스터] AKS 호스트라고도 하는 []는 여러 워크로드 클러스터를 배포하고 관리하는 역할을 담당합니다. 관리 클러스터는 노드 풀의 IP 주소 하나를 사용하지만 업데이트 작업을 위해 또 다른 두 개의 IP를 예약해야 합니다. 또한 관리 클러스터는 VIP 풀의 IP 하나를 사용합니다.
  • [워크로드 클러스터] []는 Kubernetes 컨트롤 플레인 구성 요소 및 Linux 및/또는 Windows 작업자 노드를 실행하기 위해 Linux VM을 사용하는 Kubernetes의 고가용성 배포입니다.
    • 컨트롤 플레인입니다. Linux 배포판에서 실행되며 클러스터의 모든 구성 및 데이터를 저장하기 위한 Kubernetes API 및 분산 키-값 저장소, etcd와 상호 작용하기 위한 API 서버 구성 요소를 포함합니다. 노드 풀의 IP 하나와 VIP 풀의 IP 하나를 사용합니다.
    • 부하 분산 장치 Linux VM에서 실행되며 워크로드 클러스터에 대한 부하 분산 서비스를 제공합니다. 노드 풀의 IP 하나와 VIP 풀의 IP 하나를 사용합니다.
    • 작업자 노드입니다. 컨테이너화된 애플리케이션을 호스트하는 Windows 또는 Linux 운영 체제에서 실행됩니다. 노드 풀의 IP 주소를 사용하지만 업데이트 작업을 위해 3개 이상의 IP 주소로 계획해야 합니다.
    • Kubernetes 리소스입니다. Pod는 일반적으로 컨테이너와 1:1 매핑되는 애플리케이션의 단일 인스턴스를 나타내지만, 특정 Pod는 여러 컨테이너를 포함할 수 있습니다. 배포는 하나 이상의 동일한 Pod를 나타냅니다. Pod 및 배포는 논리적으로 리소스 관리에 대한 액세스를 제어하는 네임스페이스에 논리적으로 그룹화됩니다. VIP 풀의 Pod당 IP 하나를 사용합니다.
  • [Azure Arc] []는 Azure Resource Manager 기반 관리 모델을 VM(가상 머신), Kubernetes 클러스터 및 컨테이너화된 데이터베이스를 비롯한 비 Azure 리소스로 확장하는 클라우드 기반 서비스입니다.
  • [Azure Policy] []는 속성을 사용자 지정 가능한 비즈니스 규칙과 비교하여 Azure Arc와의 통합을 통해 Azure 및 온-프레미스 리소스를 평가하는 클라우드 기반 서비스입니다.
  • [Azure Monitor] []는 클라우드 및 온-프레미스 환경에서 원격 분석을 수집, 분석 및 작동하기 위한 포괄적인 솔루션을 제공하여 애플리케이션 및 서비스의 가용성과 성능을 최대화하는 클라우드 기반 서비스입니다.
  • [클라우드용 Microsoft Defender][]은 데이터 센터의 보안 태세를 강화하고 클라우드 및 온-프레미스의 하이브리드 워크로드에서 고급 위협 방지를 제공하는 통합 인프라 보안 관리 시스템입니다.

구성 요소

  • [Azure Stack HCI(20H2)] [1]
  • [Windows Server 2019/2022 데이터 센터 장애 조치(failover) 클러스터] []
  • [AKS(Azure Kubernetes Service)] []
  • [Windows 관리 Center][]
  • [Azure 구독] []
  • [Azure Arc] [2]
  • [Azure RBAC(역할 기반 액세스 제어)] []
  • [Azure Monitor] [3]
  • [클라우드용 Microsoft Defender][4]

시나리오 정보

이 시나리오의 사용 사례는 시리즈의 첫 번째 문서인 기준 아키텍처에 설명되어 있습니다.

Kubernetes 노드 네트워킹

Azure Stack HCI의 AKS에 대한 네트워킹 디자인의 주요 고려 사항은 충분한 IP 주소를 제공하는 네트워크 모델을 선택하는 것입니다. Azure Stack HCI의 AKS는 가상 네트워킹을 사용하여 Kubernetes 노드 리소스에 IP 주소를 할당합니다. 두 개의 IP 주소 할당 모델을 사용할 수 있습니다.

  • 고정 IP 네트워킹은 예측 가능성이 더 높지만 초기 구성에 대한 추가 작업이 필요합니다.
  • DHCP(Dynamic Host Configuration Protocol) 네트워킹은 IP 주소의 동적 할당과 더 적은 작업을 사용하지만 사용 가능한 IP 풀을 소모하지 않도록 주의해야 합니다. 또한 가상 IP 풀 및 클라우드 에이전트 서비스와 같은 특정 클러스터 전체 리소스에 대한 예약 및 제외 범위를 관리해야 합니다.

두 할당 모델은 모두 다음을 위한 IP 주소를 계획해야 합니다.

  • 가상 IP 풀
  • Kubernetes 노드 VM IP 풀

가상 IP 풀

가상 IP 풀은 Azure Stack HCI의 AKS 배포에 필수인 IP 주소 세트입니다. 워크로드 클러스터 및 Kubernetes 서비스 수에 따라 가상 IP 풀의 IP 주소 수를 계획합니다. 가상 IP 풀은 다음 리소스 종류에 대한 IP 주소를 제공합니다.

  • 클라우드 에이전트에는 가상 IP 풀의 부동 IP 주소가 필요합니다.

  • KVA(Kubernetes Virtual Appliance) 가상 머신(관리 클러스터) 내에서 실행되는 API 서버 구성 요소는 가상 IP 풀의 IP 주소를 사용합니다. API 서버는 Kubernetes API를 노출하는 Kubernetes 컨트롤 플레인의 구성 요소입니다. API 서버는 Kubernetes 컨트롤 플레인의 프런트 엔드입니다. KVA는 Mariner Linux를 실행하는 가상 머신이며 Kubernetes 클러스터를 호스트합니다. IP 주소는 부동이며 Azure Stack HCI의 AKS에 배포하는 다른 KVA VM에도 사용됩니다. KVA 가상 머신은 Kubernetes 가상 IP 부하 분산 장치 서비스도 호스트합니다.

  • 가상 IP 풀의 더 많은 IP 주소를 사용하므로 대상 서버에 배포되는 컨트롤 플레인 VM 수에 대한 IP 주소 지정을 계획합니다. 고려 사항은 다음 섹션에서 설명합니다.

  • 대상 클러스터에는 HAProxy이고 대상 클러스터에 대한 가상 IP 풀을 소유하는 부하 분산 장치 VM이 포함되어 있습니다. 이 VM은 가상 IP 풀을 통해 모든 Kubernetes 서비스를 노출합니다.

  • Kubernetes Pod에서 실행되는 애플리케이션은 가상 IP 풀의 IP 주소를 사용합니다.

  • HAProxy 부하 분산 장치는 특수 가상 머신으로 배포되며 여러 엔드포인트에서 들어오는 요청의 부하를 분산하는 데 사용할 수 있습니다. 가상 IP 풀의 IP 주소를 사용하며 모든 워크로드 클러스터에 대한 IP 주소 지정을 계획해야 합니다.

Kubernetes 노드 VM IP 풀

Kubernetes 노드는 Azure Stack HCI의 AKS 배포에서 가상 머신으로 배포됩니다. 총 Kubernetes 노드 수에 따라 IP 주소 수를 계획하고 업그레이드 프로세스 중에 사용되는 IP 주소를 3개 이상 포함해야 합니다. 고정 IP 주소 구성의 경우 Kubernetes 노드 VM IP 풀 범위를 지정해야 합니다. DHCP 할당에는 필요하지 않습니다. 다음을 위해 추가 IP 주소를 계획합니다.

  • 또한 KVA VM은 Kubernetes 노드 VM IP 풀의 Kubernetes에 더 많은 IP 주소를 사용합니다. KVA VM은 API 서비스에 대해 동일한 가상 IP를 사용하지만 Kubernetes 노드 VM IP 풀과 별도의 IP가 필요하기 때문에 업데이트 프로세스 중에 IP 주소를 추가하도록 계획합니다.
  • 컨트롤 플레인 VM은 API 서버 서비스에 대한 Kubernetes 노드 VM IP 풀의 IP 하나를 사용합니다. 또한 이 가상 머신은 관리 목적으로 Azure Portal에 연결하는 Azure ARC 에이전트를 호스트합니다.
  • 노드 풀(Linux 또는 Windows)의 노드는 Kubernetes 노드 VM에 대해 할당된 IP 풀의 IP 주소를 사용합니다.

Microsoft 온-프레미스 클라우드 서비스

관리 스택을 사용하도록 설정하는 MOC(Microsoft 온-프레미스 클라우드)의 IP 주소 범위를 계획하여 Azure Stack HCI의 VM이 클라우드에서 관리되도록 합니다. MOC 서비스에 대한 IP 주소 할당은 기본 실제 네트워크에 있으며 Azure Stack HCI 클러스터 노드에 대해 구성된 IP 주소는 데이터 센터에 있습니다. 다음 중 하나에서 Azure Stack HCI의 실제 노드에 대한 IP 주소를 구성할 수 있습니다.

  • DHCP 기반 IP 주소 할당 모드를 사용하는 Azure Stack HCI 클러스터 노드. MOC 서비스는 실제 네트워크에 표시되는 DHCP 서비스에서 IP 주소를 가져옵니다.
  • 고정 IP 할당 모델을 사용하는 Azure Stack HCI 클러스터 노드. MOC 클라우드 서비스의 IP 주소는 CIDR(Classless Interdomain Routing) 형식의 IP 범위로 명시적으로 지정해야 하며 Azure Stack HCI 클러스터 노드의 IP 주소와 동일한 서브넷에 있어야 합니다.

Azure Stack HCI의 AKS에 있는 부하 분산 장치

소규모 배포의 경우 HAProxy + KeepAlive를 사용하여 AKS 클러스터의 일부로 배포된 애플리케이션 서비스에 트래픽을 보내는 Linux VM으로 배포된 기본 제공 부하 분산 장치를 사용할 수 있습니다. HAProxy 부하 분산 장치는 부하 분산 장치의 엔드포인트로 Pod를 구성합니다. Kubernetes API 서버에 대한 요청의 부하를 분산하고 애플리케이션 서비스에 대한 트래픽을 관리합니다.

서비스에 대한 트래픽을 관리하는 데 사용자 지정 부하 분산 장치를 사용할 수도 있습니다. 사용자 지정 부하 분산 장치는 배포에 유연성을 더하고 Azure Stack HCI의 AKS가 부하 분산 장치를 사용하는 SDN(소프트웨어 정의 네트워크) 배포와 같은 기존 배포와 함께 작동하도록 합니다. 사용자 지정 부하 분산 장치의 경우 kube-virtual IP는 LoadBalancer 형식의 컨트롤 플레인과 Kubernetes Services 모두에 대한 가상 IP 및 부하 분산 장치를 Kubernetes 클러스터에 제공합니다. kube-virtual IP 서비스는 모든 작업자 노드에 자동으로 배포됩니다.

또한 Azure Stack HCI의 AKS는 MetalLB 또는 기타 OSS Kubernetes 기반 부하 분산 장치를 사용하여 워크로드 클러스터의 서비스로 향하는 트래픽의 부하를 분산하는 기능을 지원합니다. MetalLB는 BGP(Border Gateway Protocol)와 같은 표준 라우팅 프로토콜을 사용하는 운영 체제 미설치 Kubernetes 클러스터에 대한 부하 분산 장치 구현입니다. 네트워크 추가 항목인 Calico 및 Flannel 모두에서 작동할 수 있지만 Azure Stack HCI의 AKS를 설치하는 동안 제공된 가상 IP 주소 범위가 사용자 지정 부하 분산 장치에 대해 계획된 IP 주소 범위와 겹치지 않도록 해야 합니다.

시나리오 배포

수신 컨트롤러 배포

TLS 종료, 되돌릴 수 있는 프록시 또는 구성 가능한 트래픽 라우팅을 위해 [수신 컨트롤러][]를 구현하는 것이 좋습니다. 수신 컨트롤러는 계층 7에서 작동하며, 지능형 규칙을 사용하여 애플리케이션 트래픽을 분산시킬 수 있습니다. Kubernetes 수신 리소스는 개별 Kubernetes 서비스에 대한 수신 규칙 및 라우팅을 구성하는 데 사용됩니다. 수신 컨트롤러를 정의할 때 트래픽 라우팅 규칙을 클러스터의 일부로 실행되는 단일 리소스로 통합합니다.

수신 컨트롤러를 사용하여 외부에서 연결할 수 있는 URL을 통해 서비스를 노출합니다. 수신은 클러스터 외부에서 클러스터 내의 서비스로 HTTP 및 HTTPS 경로를 노출합니다. 트래픽 라우팅은 수신 리소스에 정의된 규칙을 통해 제어됩니다. 수신 HTTP 규칙에는 다음 정보가 포함됩니다.

  • 선택적 호스트. 호스트 정보를 제공하지 않으면 규칙이 모든 인바운드 HTTP 트래픽에 적용됩니다.
  • service.name 및 service.port.name 또는 service.port.number로 정의된 연결된 백 엔드가 있는 경로 목록.
  • 서비스와 포트 이름의 조합을 제공하는 백 엔드.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-world
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: test.example.com
     http:
       paths:
       - path: /hello-world
          pathType: Prefix
          backend:
            service:
              name: hello-world
              port:
                 number: 8080

수신 컨트롤러를 사용하여 애플리케이션의 여러 백 엔드 간에 트래픽의 부하를 분산합니다. 트래픽은 경로 정보에 따라 분할되어 여러 서비스 엔드포인트 및 배포에 전송됩니다.

HTTP 트래픽을 동일한 IP 주소의 여러 호스트 이름에 라우팅하기 위해 각 호스트에 대해 다른 수신 리소스를 사용할 수 있습니다. 부하 분산 장치 IP 주소를 통해 들어오는 트래픽은 호스트 이름 및 수신 규칙에 제공된 경로에 따라 라우팅됩니다.

Azure Stack HCI의 AKS(Azure Kubernetes Service)의 컨테이너 네트워킹 개념

Kubernetes는 가상 네트워크에 추상화 계층을 제공하므로 컨테이너 기반 애플리케이션은 내부 또는 외부에서 통신할 수 있습니다. kube-proxy 구성 요소는 각 노드에서 실행되며 서비스에 대한 직접 액세스를 제공하거나, 부하 분산을 사용하여 트래픽을 분산하거나, 더 복잡한 애플리케이션 라우팅을 위해 수신 컨트롤러를 사용할 수 있습니다. Kubernetes는 서비스를 사용하여 Pod 세트를 논리적으로 그룹화하고 네트워크 연결을 제공합니다. 사용할 수 있는 Kubernetes 서비스는 다음과 같습니다.

  • 클러스터 IP: 이 서비스는 내부 전용 애플리케이션에 대한 내부 IP 주소를 만듭니다.
  • NodePort: 이 서비스는 기본 노드에 포트 매핑을 만들어 노드 IP 주소와 포트를 사용하여 애플리케이션에 직접 액세스할 수 있도록 합니다.
  • LoadBalancer: 부하 분산 장치 규칙 또는 수신 컨트롤러를 사용하여 외부에서 Kubernetes 서비스를 노출할 수 있습니다.
  • ExternalName: 이 서비스는 Kubernetes 애플리케이션에 대한 특정 DNS 항목을 사용합니다.

Kubernetes 네트워크

Azure Stack HCI의 AKS에서 클러스터는 다음 네트워크 모델 중 하나를 사용하여 배포할 수 있습니다.

  • [Project Calico 네트워킹] []. 이는 Azure Stack HCI의 AKS에 대한 기본 네트워킹 모델이며 컨테이너, 가상 머신, 네이티브 호스트 기반 워크로드에 대한 네트워크 보안을 제공하는 오픈 소스 네트워킹을 기반으로 합니다. Calico 네트워크 정책은 Pod, 컨테이너, VM 또는 호스트 인터페이스와 같은 모든 종류의 엔드포인트에 적용할 수 있습니다. 각 정책은 원본 엔드포인트와 대상 엔드포인트 간에 트래픽을 허용, 거부, 로그 또는 전달할 수 있는 작업을 사용하여 수신 및 송신 트래픽을 제어하는 규칙으로 구성됩니다. Calico는 트래픽 배달을 위해 Linux eBPF(확장 Berkeley 패킷 필터) 또는 Linux 커널 네트워킹 파이프라인을 사용할 수 있습니다. Calico는 컨테이너 엔드포인트별로 네트워크 네임스페이스를 만들기 위해 HNS(호스트 네트워킹 서비스)를 사용하여 Windows에서도 지원됩니다. Kubernetes 네트워크 모델에서 모든 Pod는 해당 Pod 내의 컨테이너 간에 공유되는 자체 IP 주소를 가져옵니다. Pod는 Pod IP 주소를 사용하여 네트워크에서 통신하고 격리는 네트워크 정책을 사용하여 정의됩니다. Calico는 Kubernetes Pod 네트워크 간에 Pod를 추가하거나 삭제하기 위해 CNI(Container Network Interface) 플러그 인을 사용하고 IP 주소를 할당하고 해제하기 위해 CNI IPAM(IP Address Management) 플러그 인을 사용합니다.
  • [플란넬 오버레이 네트워킹.] [] Flannel은 호스트 네트워크를 오버레이하는 가상 네트워크 계층을 만듭니다. 오버레이 네트워킹은 기존 실제 네트워크를 통해 네트워크 패킷의 캡슐화를 사용합니다. Flannel은 IPAM(IP Address Management)을 간소화하고, 서로 다른 애플리케이션과 네임스페이스 간의 IP 재사용을 지원하며, Kubernetes 노드에서 사용하는 기본 네트워크에서 컨테이너 네트워크를 논리적으로 분리합니다. 네트워크 격리는 기본 계층 3 네트워크를 통해 계층 2 연결을 확대하는 데 터널링을 사용하여 데이터 센터 연결을 제공하는 캡슐화 프로토콜인 VXLAN(Virtual eXtensible Local Area Network)을 사용하여 수행됩니다. Flannel은 DaemonSet를 사용하는 Linux 컨테이너와 Flannel CNI 플러그 인을 사용하는 Windows 컨테이너에서 모두 지원됩니다.

Azure Stack HCI 네트워킹 디자인

전체 네트워킹 디자인에는 Azure Stack HCI에 대한 계획 작업이 포함됩니다.

먼저 Azure Stack HCI의 하드웨어 및 설치를 계획합니다. 미리 설치된 Azure Stack HCI 운영 체제를 사용하여 Microsoft 하드웨어 파트너로부터 통합 시스템을 구매할 수 있고, 유효성이 검사된 노드를 구매하고 운영 체제를 직접 설치할 수도 있습니다. Azure Stack HCI는 가상화 호스트로 사용되어야 하므로 Kubernetes 서버 역할은 VM 내에서 실행되어야 합니다.

Azure Stack HCI에 대한 실제 네트워크 요구 사항

Microsoft는 네트워크 스위치를 인증하지 않지만 장비 공급업체가 충족해야 하는 특정 요구 사항이 있습니다.

  • 표준: VLAN(가상 로컬 영역 네트워크)을 정의하는 IEEE 802.1Q.
  • 표준: PFC(Priority Flow Control)를 정의하는 IEEE 802.1Qbb.
  • 표준: ETS(Enhanced Transmission Selection)를 정의하는 IEEE 802.1Qaz.
  • 표준: LLTD(Link Layer Topology Discovery) 프로토콜을 정의하는 IEEE 802.1AB.

Azure Stack HCI에 대한 호스트 네트워크 요구 사항

표준 또는 프리미엄 AQ(추가 자격)와 함께 Windows Server SDDC(소프트웨어 정의 데이터 센터) 인증을 획득한 네트워크 어댑터를 사용하는 것이 좋습니다.

네트워크 어댑터가 다음을 지원하는지 확인합니다.

  • [동적 Virtual Machine 다중 큐] [] (동적 VMMQ 또는 d.VMMQ)는 CPU 코어에 대한 네트워크 트래픽 처리를 자동으로 조정하기 위한 지능형 수신측 기술입니다.
  • RDMA(원격 직접 메모리 액세스)는 네트워크 어댑터에 대한 네트워크 스택 오프로드입니다. 이를 통해 SMB 스토리지 트래픽이 처리를 위해 운영 체제를 무시할 수 있습니다.
  • 게스트 RDMA를 사용하면 VM에 대한 SMB 워크로드가 호스트에서 RDMA를 사용하는 것과 동일한 이점을 얻을 수 있습니다.
  • SET(Switch Embedded Teaming)는 소프트웨어 기반 팀 기술입니다.

호스트 네트워킹 구성을 간소화하기 위해 의도 기반 제어를 제공하는 [네트워크 ATC][]를 사용하는 것이 좋습니다.

Azure Stack HCI의 AKS에는 각 서버 노드 간에 안정적인 높은 대역폭, 짧은 대기 시간 네트워크 연결이 필요합니다. 하나 이상의 네트워크 어댑터가 사용 가능하고 클러스터 관리 전용인지 확인합니다. 또한 네트워크의 물리적 스위치가 사용할 VLAN의 트래픽을 허용하도록 구성되어 있는지 확인합니다.

가상 스위치

Azure Stack HCI는 네트워크 분류에 사용할 수 있는 가상 스위치를 구성하여 네트워킹 디자인을 간소화합니다. vNIC(가상 네트워크 인터페이스 카드)는 호스트가 다음 네트워크에 대해 서로 다른 트래픽 흐름을 제공하기 위해 여러 VLAN에 배치할 수 있습니다.

  • 관리 네트워크. 관리 네트워크는 북-남 네트워크의 일부이며 호스트 통신에 사용됩니다.
  • 컴퓨팅 네트워크. 컴퓨팅 네트워크는 북-남 네트워크의 일부이며 가상 머신 트래픽에 사용됩니다. QOS(서비스 품질), SR-IOV(단일 루트 I/O 가상화) 및 vRDMA(가상 원격 직접 메모리 액세스)를 사용하여 수요에 따라 네트워크 성능을 조정합니다.
  • 스토리지 네트워크. 스토리지 네트워크는 동-서 네트워크의 일부이며 권장 처리량이 10GB 이상인 RDMA가 필요합니다. VM의 실시간 마이그레이션에 사용됩니다.
  • VM 게스트 네트워크.

RDMA 트래픽의 동-서 트래픽 이점

동-서 네트워크 트래픽은 호스트 간 통신을 나타내며 외부 액세스를 노출하지 않습니다. 트래픽은 ToR(Top of Rack) 스위치 및 계층 2 경계 내에 남아 있습니다. 여기에는 다음 유형의 트래픽이 포함됩니다.

  • 클러스터 하트비트 및 노드 간 통신
  • [SMB] 스토리지 버스 계층
  • [SMB] 클러스터 공유 볼륨
  • [SMB] 스토리지 다시 빌드

북-남 트래픽

북-남 트래픽은 Azure Stack HCI의 AKS 클러스터에 도달하는 외부 트래픽입니다. Azure ARC 통합을 통해 모니터링, 청구 및 보안 관리를 가능하게 하는 Azure 서비스 범위에 대한 트래픽을 계획할 수 있습니다. 북-남 트래픽의 특징은 다음과 같습니다.

  • 트래픽은 ToR 스위치에서 스파인으로 이동하거나 스파인에서 ToR 스위치로 이동합니다.
  • 트래픽은 물리적 랙을 벗어나거나 계층 3 경계(IP)를 교차합니다.
  • 트래픽에는 관리(PowerShell, Windows Admin Center), 컴퓨팅(VM) 및 사이트 간 확대 클러스터 트래픽이 포함됩니다.
  • 실제 네트워크에 연결하기 위해 이더넷 스위치를 사용합니다.

Azure Stack HCI의 AKS는 다음과 같은 여러 클러스터 네트워크 배포 옵션을 사용할 수 있습니다.

  • 여러 네트워크 의도를 결합하는 컨버지드 네트워크(MGMT, 컴퓨팅, 스토리지). 이는 물리적 노드가 3개를 초과하는 경우 권장되는 배포이며 모든 실제 네트워크 어댑터가 동일한 ToR 스위치에 연결되어야 합니다. ROCEv2를 사용하는 것이 좋습니다.
  • 스위치 없는 배포는 컴퓨팅 및 관리 네트워크를 결합하여 네트워크 팀으로 북-남 통신을 사용합니다.
  • 두 배포의 조합으로 하이브리드 배포.

권장 사항

대부분의 시나리오의 경우 다음 권장 사항을 적용합니다. 재정의해야 하는 요구 사항이 없는 한 이 권장 사항을 따릅니다.

네트워크 권장 사항

Azure Stack HCI의 AKS에 대한 네트워킹 디자인의 주요 고려 사항은 Kubernetes 클러스터와 해당 서비스 및 애플리케이션에 충분한 IP 주소를 제공하는 네트워크 모델을 선택하는 것입니다.

  • Azure Stack HCI의 AKS가 IP 주소 할당을 제어할 수 있도록 고정 IP 주소를 구현하는 것이 좋습니다.

  • Kubernetes 노드 풀 및 가상 IP 풀에 대해 충분한 사용 가능한 IP 주소를 포함하도록 IP 주소 범위를 적절하게 조정합니다. 업그레이드할 때마다 더 많은 IP 주소가 필요한 롤링 업그레이드를 사용할 수 있도록 가상 IP 풀이 충분히 큰지 확인합니다. 다음을 계획할 수 있습니다.

    • 프록시 설정의 주소 지정/호스트 이름
    • 대상 클러스터 컨트롤 플레인의 IP 주소
    • Azure ARC의 IP 주소
    • 대상 클러스터에서 작업자 및 컨트롤 플레인 노드의 수평 스케일링을 위한 IP 주소

  • 가상 IP 풀은 외부 라우터에 연결해야 하는 애플리케이션 서비스의 배포를 지원할 수 있을 만큼 커야 합니다.

  • Calico CNI를 구현하여 Pod 및 애플리케이션 통신을 제어하기 위한 향상된 네트워크 정책을 제공합니다.

  • 물리적 클러스터 노드(HCI 또는 Windows Server)가 동일한 랙에 있고 동일한 ToR 스위치에 연결되어 있는지 확인합니다.

  • 모든 네트워크 어댑터에서 IPv6을 사용하지 않도록 설정합니다.

  • 기존 가상 스위치와 해당 이름이 모든 클러스터 노드에서 동일한지 확인합니다.

  • 클러스터에 대해 정의한 모든 서브넷이 서로 간에 그리고 인터넷으로 라우팅 가능한지 확인합니다.

  • Azure Stack HCI 호스트와 테넌트 VM 간에 네트워크 연결이 있는지 확인합니다.

  • Azure Stack HCI의 AKS가 검색을 위해 DNS 시스템에 클라우드 에이전트 일반 클러스터 이름을 등록할 수 있도록 DNS 환경에서 동적 DNS 업데이트를 사용하도록 설정합니다.

  • 네트워크 트래픽의 분류를 해당 방향으로 구현하는 것이 좋습니다.

    • 남북 트래픽은 Azure Stack HCI 및 나머지 네트워크의 트래픽입니다.
      • 관리
      • 컴퓨팅
      • 사이트 간 확대 클러스터 트래픽
    • Azure Stack HCI 내의 동서 트래픽:
      • 동일한 클러스터의 노드 간 실시간 마이그레이션을 포함한 스토리지 트래픽
      • 이더넷 스위치 또는 직접 연결

스토리지 트래픽 모델

  • 여러 서브넷 및 VLAN을 사용하여 Azure Stack HCI에서 스토리지 트래픽을 구분합니다.
  • 다양한 트래픽 유형의 트래픽 대역폭 할당을 구현하는 것이 좋습니다.

고려 사항

[Microsoft Azure Well-Architected Framework][]는 이 시나리오에서 이어지는 지침의 집합입니다. 다음 고려 사항은 이러한 원칙의 컨텍스트에서 구성되었습니다.

안정성

  • Microsoft 소프트웨어 정의 컴퓨팅(Hyper-V 노드의 장애 조치 클러스터), 스토리지(스토리지 공간 다이렉트 중첩된 복원력) 및 네트워킹(소프트웨어 방식 네트워킹)에 고유한 기본 제공 복원력입니다.
  • 업계 표준을 지원하고 노드 간에 안정적인 통신을 보장하는 네트워크 스위치를 선택하는 것이 좋습니다. 다음 표준은 다음과 같습니다.
    • 표준: IEEE 802.1Q
    • 표준 IEEE 802.1Qbb
    • 표준 IEEE 802.1 Qas
    • 표준 IEEE 802.1 AB
  • 워크로드에 대한 최소 가용성 수준을 충족하려면 관리 클러스터 및 Kubernetes 클러스터에서 여러 호스트를 구현하는 것이 좋습니다.
  • Azure Stack HCI의 AKS는 고가용성 및 내결함성을 위해 장애 조치 클러스터링 및 실시간 마이그레이션을 사용합니다. 실시간 마이그레이션은 가동 중지 시간을 인식하지 않고 실행 중인 가상 머신을 하나의 Hyper-V 호스트에서 다른 호스트로 투명하게 이동할 수 있는 Hyper-V 기능입니다.
  • 아키텍처 섹션에 언급된 서비스들이 Azure Arc가 배포되는 지역에서 지원되는지 확인해야 합니다.

보안

  • Azure Stack HCI의 AKS에서 네트워크 정책을 사용하는 Pod 간 트래픽을 보호합니다.
  • Azure Stack HCI의 AKS에 있는 API 서버에는 Kubernetes API 서버에서 kubelet으로 통신을 위한 인증서에 서명하는 인증 기관이 포함되어 있습니다.
  • Microsoft Entra SSO(Single Sign-On)를 사용하여 Kubernetes API 서버에 대한 보안 연결을 만듭니다.
  • Azure RBAC를 사용하여 Microsoft Entra ID를 사용하여 Azure 및 온-프레미스 환경에서 Azure Arc 지원 Kubernetes에 대한 액세스를 관리할 수 있습니다. 자세한 내용은 [Kubernetes 권한 부여에 Azure RBAC 사용][]을 참조하세요.

비용 최적화

  • [Azure 가격 계산기][]를 사용하여 아키텍처에 사용되는 서비스에 대한 비용을 예측합니다. 기타 모범 사례는 [Microsoft Azure Well-Architected Framework]의 [비용 최적화][] 섹션에 설명되어 있습니다. []
  • Azure Stack HCI의 AKS 청구 단위가 가상 코어이므로 비용을 최적화하려면 물리적 컴퓨터에서 하이퍼 스레딩을 구현하는 것이 좋습니다.
  • Azure Arc 컨트롤 플레인 기능은 추가 비용 없이 제공됩니다. 여기에는 Azure 관리 그룹 및 태그를 통한 리소스 조직 지원과 Azure RBAC를 통한 액세스 제어가 포함됩니다. Azure Arc 지원 서버와 함께 사용되는 Azure 서비스는 사용량에 따라 비용이 발생합니다.
  • 비용 효율성을 위해 4개 디스크와 노드당 64GB(기가바이트) 메모리만 있는 클러스터 노드를 두 개만 사용할 수 있습니다. 비용을 더욱 최소화하기 위해 노드 간에 스위치 없는 상호 연결을 사용하면 중복 스위치 디바이스가 필요하지 않습니다.

운영 우수성

  • Windows Admin Center를 사용하여 간소화된 관리 Windows Admin Center는 Azure Stack HCI의 AKS를 만들고 관리하기 위한 사용자 인터페이스입니다. Azure에 등록되어야 하고 Azure Stack HCI 또는 Windows Server Datacenter 클러스터와 동일한 도메인에 있는 Windows 10/11 또는 Windows Server VM에 설치할 수 있습니다.
  • Azure Arc 또는 더 많은 관리, 유지 관리 및 복원력 기능을 제공하는 다양한 Azure 서비스와 통합(Azure Monitor, Azure Backup).
  • Kubernetes 클러스터가 [Azure Arc에 연결][Azure Arc 지원 Kubernetes 서비스]인 경우 [GitOps를 사용하여 Kubernetes 클러스터 관리][]를 수행할 수 있습니다. 하이브리드 Kubernetes 클러스터를 Azure Arc에 연결하는 모범 사례를 검토하려면 [Kubernetes 클러스터에 대한 Azure Arc 하이브리드 관리 및 배포][] 시나리오를 참조하세요.
  • 또한 Azure Stack HCI 플랫폼은 고가용성 방식으로 “기본” 네트워크를 제공하여 Azure Stack HCI의 AKS 클러스터에 대한 가상 네트워킹을 간소화하는 데 도움이 됩니다.

성능 효율성

  • Azure Stack HCI 인증 하드웨어를 사용하여 애플리케이션 작동 시간 및 성능을 개선하고, 관리 및 운영을 간소화하며, 총 소유 비용을 낮춥니다.
  • 스토리지: 저장소 공간 Direct
    • 볼륨 구성(중첩된 양방향 미러 및 중첩된 미러 가속 패리티)
    • 디스크 구성(캐싱, 계층)
  • 클러스터 노드가 물리적으로 동일한 랙에 있고 동일한 ToR 스위치에 연결되어 있는지 확인합니다.
  • IP 주소 예약을 계획하여 AKS 호스트, 워크로드 클러스터, 클러스터 API 서버, Kubernetes Service 및 애플리케이션 서비스를 구성합니다. Microsoft는 Azure Stack HCI의 AKS 배포를 위해 최소 256개의 IP 주소를 예약할 것을 권장합니다.
  • 계층 7에서 작동하고 더 지능적인 규칙을 사용하여 애플리케이션 트래픽을 분산하는 수신 컨트롤러를 구현하는 것이 좋습니다.
  • 광범위한 워크로드에 대해 GPU(그래픽 처리 장치) 가속을 사용합니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

주요 작성자:

기타 기여자:

다음 단계