편집

다중 테넌트 Azure Kubernetes Service와 함께 AGIC(Application Gateway 수신 컨트롤러) 사용

Azure Application Gateway
Azure Key Vault
Azure Container Registry
AKS(Azure Kubernetes Service)
Azure Bastion

이 솔루션에서 WAF(Azure Web Application Firewall)는 일반적인 악용 및 취약성으로부터 다중 테넌트 AKS(Azure Kubernetes Service) 클러스터에 배포된 웹 애플리케이션에 대한 중앙 집중식 보호를 제공합니다. AKS(Azure Kubernetes Service) 클러스터에서 실행되고 AGIC(Application Gateway 수신 컨트롤러)를 통해 노출되는 웹 애플리케이션은 Azure Application Gateway의 WAF 정책을 사용하여 SQL 삽입 및 사이트 간 스크립팅과 같은 악의적인 공격으로부터 보호할 수 있습니다. Azure Application Gateway의 WAF 정책은 OWASP 핵심 규칙 집합으로 미리 구성되어 있으며 지원되는 다른 OWASP CRS 버전으로 변경할 수 있습니다.

아키텍처

이 Application Gateway 수신 컨트롤러 솔루션의 다이어그램을 표시하는 다이어그램.

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

워크플로

컴패니언 ARM 템플릿은 4개의 서브넷이 있는 새 가상 네트워크를 배포합니다.

  • AksSubnet: AKS 클러스터 호스팅
  • VmSubnet: 점프 박스 가상 머신 및 프라이빗 엔드포인트를 호스팅합니다.
  • AppGatewaySubnet: Application Gateway WAF2 티어 호스팅.
  • AzureBastionSubnet: Azure Bastion 호스팅

AKS(Azure Kubernetes Service) 클러스터는 사용자 정의 관리 ID를 사용하여 Azure의 부하 분산 장치 및 관리 디스크와 같은 추가 리소스를 만듭니다. ARM 템플릿을 사용하면 다음 기능을 사용하여 AKS 클러스터를 배포할 수 있습니다.

AKS 클러스터는 다음으로 구성됩니다.

  • 중요한 시스템 Pod 및 서비스만 호스팅하는 시스템 노드 풀. 작업자 노드에는 이 노드 풀에서 애플리케이션 Pod가 예약되지 않도록 하는 노드 taint가 있습니다.
  • 사용자 워크로드 및 아티팩트를 호스팅하는 사용자 노드 풀.

VM(가상 머신)은 AKS 클러스터를 호스팅하는 동일한 가상 네트워크에 배포됩니다. Azure Kubernetes Service를 프라이빗 클러스터로 배포하면 시스템 관리자가 이 VM을 사용하여 Kubernetes 명령줄 도구를 통해 클러스터를 관리할 수 있습니다. 가상 머신의 부팅 진단 로그는 Azure Storage 계정에 저장됩니다.

Azure Bastion 호스트는 SSL을 통해 Azure Portal에서 직접 점프 박스 VM에 대한 안전하고 원활한 SSH 연결을 제공합니다. ACR(Azure Container Registry)은 컨테이너 이미지 및 아티팩트(예: Helm 차트)를 빌드, 저장 및 관리하는 데 사용됩니다.

아키텍처에는 수신 컨트롤러에서 사용하는 Application Gateway가 포함됩니다. Application Gateway는 전용 서브넷에 배포되고 모든 테넌트 워크로드에서 공유하는 공용 IP 주소를 통해 공용 인터넷에 노출됩니다. WAF(웹 액세스 방화벽) 정책은 루트 수준 및 HTTP 수신기 수준에서 Application Gateway에 연결되어 악의적인 공격으로부터 테넌트 워크로드를 보호합니다. 정책은 방지 모드에서 구성되며 OWASP 3.1을 사용하여 규칙에 의해 검색되는 침입 및 공격을 차단합니다. 공격자는 "403 무단 액세스" 예외를 수신하고, 연결이 종료됩니다. 방지 모드는 이러한 공격을 WAF 로그에 기록합니다.

Key Vault는 AKS(Azure Kubernetes Service)에서 실행되는 워크로드에 의해 비밀 저장소로 사용되어 클라이언트 라이브러리, 비밀 저장소 CSI 드라이버 또는 Dapr을 통해 키, 인증서 및 비밀을 검색합니다. Azure Private Link를 사용하면 AKS 워크로드가 가상 네트워크의 프라이빗 엔드포인트를 통해 Key Vault와 같은 Azure PaaS 서비스에 액세스할 수 있습니다.

샘플 토폴로지에는 다음과 같은 프라이빗 엔드포인트가 포함됩니다.

  • Blob Storage 계정에 대한 프라이빗 엔드포인트
  • ACR(Azure Container Registry)에 대한 프라이빗 엔드포인트
  • Key Vault에 대한 프라이빗 엔드포인트
  • 프라이빗 AKS 클러스터를 선택하는 경우 Kubernetes 클러스터의 API 서버에 대한 프라이빗 엔드포인트

아키텍처에는 PaaS 서비스의 FQDN(정규화된 도메인 이름)을 연결된 프라이빗 엔드포인트의 개인 IP 주소로 이름 확인하기 위한 다음과 같은 프라이빗 DNS 영역도 포함되어 있습니다.

  • Azure Blob Storage 계정에 대한 프라이빗 엔드포인트의 이름 확인을 위한 프라이빗 DNS 영역
  • ACR(Azure Container Registry)에 대한 프라이빗 엔드포인트의 이름 확인을 위한 프라이빗 DNS 영역
  • Azure Key Vault에 대한 프라이빗 엔드포인트의 이름 확인을 위한 프라이빗 DNS 영역
  • 클러스터를 프라이빗으로 배포하는 경우 Kubernetes Server API에 대한 프라이빗 엔드포인트의 이름 확인을 위한 프라이빗 DNS 영역

Virtual Network 링크는 AKS 클러스터를 호스팅하는 가상 네트워크와 위의 프라이빗 DNS 영역 사이에 존재합니다. Log Analytics 작업 영역은 다음 원본에서 진단 로그 및 메트릭을 수집하는 데 사용됩니다.

  • Azure Kubernetes Service 클러스터
  • 점프 박스 가상 머신
  • Azure Application Gateway
  • Azure Key Vault
  • Azure 네트워크 보안 그룹

구성 요소

  • Azure Container Registry는 Docker Registry 2.0 오픈 소스에 기반한 관리형의 프라이빗 Docker 레지스트리 서비스입니다. 기존 컨테이너 개발 및 배포 파이프라인과 함께 Azure Container Registry를 사용하거나 Azure Container Registry 작업을 사용하여 Azure에서 컨테이너 이미지를 빌드할 수 있습니다. 요청에 따라 빌드하거나 소스 코드 커밋 및 기본 이미지 업데이트와 같은 트리거를 사용하여 빌드를 완전히 자동화합니다.

  • Azure Kubernetes Services는 운영 오버헤드를 Azure로 오프로드하여 Azure에서 관리되는 Kubernetes 클러스터 배포를 단순화합니다. 호스팅되는 Kubernetes 서비스인 Azure는 상태 모니터링 및 유지 관리 같은 중요 작업을 처리합니다. Kubernetes 마스터는 Azure에서 관리되므로 에이전트 노드만 관리하고 유지 관리합니다.

  • Azure Key Vault는 API 키, 암호, 인증서 및 비밀화 키와 같은 비밀을 안전하게 저장하고 액세스를 제어합니다. 또한 Azure Key Vault를 사용하면 Azure 및 연결된 내부 리소스에 사용할 공용 및 프라이빗 TLS/SSL(Transport Layer Security/Secure Sockets Layer) 인증서를 쉽게 프로비저닝, 관리 및 배포할 수 있습니다.

  • Azure Application Gateway Azure Application Gateway는 여러 다운스트림 웹 애플리케이션 및 REST API에 대한 인바운드 트래픽을 관리할 수 있는 웹 트래픽 부하 분산 장치입니다. 기존 부하 분산 장치는 전송 계층(OSI 계층 4 - TCP 및 UDP)에서 작동하며 원본 IP 주소 및 포트를 기반으로 트래픽을 대상 IP 주소 및 포트로 라우팅합니다. 대신 Application Gateway는 애플리케이션 계층(OSI 계층 7) 부하 분산 장치입니다. (OSI는 Open Systems Interconnection을 의미하고, TCP는 전송 제어 프로토콜을 의미하며, UDP는 사용자 데이터그램 프로토콜을 의미합니다.)

  • 웹 애플리케이션 방화벽 또는 WAF는 일반적인 악용 및 취약성으로부터 웹 애플리케이션을 중앙 집중식으로 보호하는 서비스입니다. WAF는 OWASP(Open Web Application Security Project) 핵심 규칙 집합의 규칙을 기반으로 합니다. Azure WAF를 사용하면 정책을 통과하는 각 요청에 대해 평가되는 사용자 지정 규칙을 만들 수 있습니다. 이러한 규칙은 관리형 규칙 세트의 나머지 규칙보다 높은 우선 순위를 갖습니다. 사용자 지정 규칙에는 규칙 이름, 규칙 우선 순위 및 일치 조건의 배열이 포함되어 있습니다. 이러한 조건이 충족되면 작업이 허용 또는 차단됩니다.

  • Azure Bastion은 가상 네트워크 내부에 프로비저닝하는 완전 관리형 PaaS(Platform as a Service)입니다. Azure Bastion은 TLS를 통해 Azure Portal에서 직접 가상 네트워크의 VM에 대한 안전하고 원활한 RDP(원격 데스크톱 프로토콜) 및 SSH(보안 셸) 연결을 제공합니다.

  • Azure Virtual Machines는 실제 하드웨어를 구입하고 유지 관리할 필요 없이 가상화의 유연성을 제공하는 확장성 있는 주문형 컴퓨팅 리소스를 제공합니다.

  • Azure Virtual Network는 Azure 개인 네트워크의 기본 빌딩 블록입니다. Virtual Network를 사용하면 VM과 같은 Azure 리소스가 서로 간, 인터넷 및 온-프레미스 네트워크와 안전하게 통신할 수 있습니다. Azure Virtual Network는 온-프레미스에 있는 기존 네트워크와 유사하지만 확장성, 가용성 및 격리와 같은 Azure 인프라 이점이 포함되어 있습니다.

  • Virtual Network 인터페이스를 사용하면 Azure 가상 머신이 인터넷, Azure 및 온-프레미스 리소스와 통신할 수 있습니다. 하나의 Azure VM에 여러 네트워크 인터페이스 카드를 추가하여 자식 VM이 고유한 전용 네트워크 인터페이스 디바이스와 IP 주소를 가질 수 있도록 할 수 있습니다.

  • Azure Managed Disks는 Azure가 Azure VM에서 관리하는 블록 수준 스토리지 볼륨을 제공합니다. 사용 가능한 디스크 유형은 Ultra 디스크, 프리미엄 SSD(반도체 드라이브), 표준 SSD 및 표준 HDD(하드 디스크 드라이브)입니다.

  • Azure Blob Storage는 클라우드를 위한 Microsoft의 개체 스토리지 솔루션입니다. Blob Storage는 구조화되지 않은 대량의 데이터를 저장하는 데 최적화되어 있습니다. 비정형 데이터는 텍스트 또는 이진 데이터와 같은 특정 데이터 모델이나 정의를 따르지 않는 데이터입니다.

  • Azure Private Link를 사용하면 가상 네트워크의 프라이빗 엔드포인트를 통해 Azure PaaS 서비스(예: Azure Blob Storage 및 Key Vault) 및 Azure에서 호스팅하는 고객 소유/파트너 서비스에 액세스할 수 있습니다.

대안

이 아키텍처에서는 AKS(Azure Kubernetes Service)용 AGIC 추가 기능을 사용하여 AGIC(Application Gateway 수신 컨트롤러)를 설치했습니다. Helm 차트를 통해 Application Gateway 수신 컨트롤러를 설치할 수도 있습니다. 새 설정의 경우 Azure CLI에서 단 한 줄을 사용하여 새 Application Gateway 및 새 AKS 클러스터(AGIC가 추가 항목으로 사용하도록 설정됨)를 배포할 수 있습니다. 또한 추가 기능은 완전히 관리되는 서비스이며, 자동 업데이트 및 지원 증가와 같은 추가 이점을 제공합니다. AGIC(Helm 및 AKS 추가 항목)를 배포하는 두 가지 방법 모두 Microsoft에서 완전히 지원됩니다. 또한 추가 기능을 사용하면 AKS를 첫 번째 클래스 추가 기능으로 사용하여 AKS와의 통합을 개선할 수 있습니다.

AGIC(Application Gateway 수신 컨트롤러) 추가 항목은 여전히 AKS 클러스터에 Pod로 배포됩니다. 그러나 Helm 배포 버전과 AGIC의 추가 항목 버전 간에는 몇 가지 차이점이 있습니다. 다음 목록에는 두 버전 간의 차이점이 포함되어 있습니다.

  • AKS 추가 기능에서는 Helm 배포 값을 수정할 수 없습니다.

    • usePrivateIp는 기본적으로 false로 설정됩니다. 이는 use-private-ip 주석으로 덮어쓸 수 있습니다.
    • shared는 추가 항목에서 지원되지 않습니다.

  • Helm을 통해 배포된 AGIC는 ProhibitedTargets를 지원합니다. 즉, AGIC는 다른 기존 백 엔드에 영향을 주지 않고 오직 AKS 클러스터용으로 특별히 Application Gateway를 구성할 수 있습니다.

  • AGIC 추가 항목은 관리되는 서비스이므로 Helm을 통해 배포(이 경우 AGIC를 수동으로 업데이트해야 함)된 AGIC와 달리 최신 버전의 AGIC 추가 항목으로 자동 업데이트됩니다.

  • AKS 클러스터당 하나의 AGIC 추가 항목만 배포할 수 있으며, 각 AGIC 추가 항목은 현재 하나의 Application Gateway 인스턴스만 대상으로 할 수 있습니다. 클러스터당 둘 이상의 AGIC가 필요한 배포 또는 하나의 Application Gateway를 대상으로 하는 여러 AGIC의 경우 Helm을 통해 배포된 AGIC를 계속 사용할 수 있습니다.

Azure Application Gateway AGIC(Kubernetes 수신 컨트롤러)의 단일 인스턴스는 여러 Kubernetes 네임스페이스에서 이벤트를 수집할 수 있습니다. AKS 관리자가 Application Gateway를 수신으로 사용하기로 결정한 경우 모든 네임스페이스는 Application Gateway의 동일한 인스턴스를 사용합니다. 수신 컨트롤러의 단일 설치는 액세스 가능한 네임스페이스를 모니터링하고 연결된 Application Gateway를 구성합니다. 자세한 내용은 Application Gateway 수신 컨트롤러가 있는 AKS 클러스터에서 여러 네임스페이스 지원 사용하도록 설정을 참조하세요.

다중 네임스페이스 지원을 사용하도록 설정하려면 다음을 수행합니다.

  • 다음 방법 중 하나로 helm-config.yaml 파일을 수정합니다.

    • watchNamespace helm-config.yaml 파일에서 키를 완전히 삭제합니다. AGIC는 모든 네임스페이스를 관찰합니다.
    • watchNamespace를 빈 문자열로 설정합니다. AGIC는 모든 네임스페이스를 관찰합니다.
    • 쉼표(watchNamespace: default,secondNamespace)로 구분하여 여러 네임스페이스를 추가합니다. AGIC는 이러한 네임스페이스를 단독으로 관찰합니다.

  • 다음 스크립트를 사용하여 Helm 템플릿 변경 내용을 적용합니다. helm install -f helm-config.yaml application-gateway-kubernetes-ingress/ingress-azure

여러 네임스페이스를 관찰할 수 있는 기능이 배포되면 AGIC는 다음을 수행합니다.

  • 액세스 가능한 모든 네임스페이스의 수신 리소스 나열
  • kubernetes.io/ingress.class 주석이 달린 수신 리소스로 필터링: azure/application-gateway
  • 결합된 Application Gateway 구성 작성
  • ARM을 통해 연결된 Application Gateway에 구성 적용

시나리오 정보

다중 테넌트 Kubernetes 클러스터는 일반적으로 "테넌트"라고 하는 여러 사용자 및 워크로드에서 공유됩니다. 이 정의에는 조직 내의 여러 팀 또는 부서에서 공유하는 Kubernetes 클러스터가 포함됩니다. 또한 SaaS(Software-as-a-Service) 애플리케이션의 고객별 인스턴스에서 공유하는 클러스터도 포함됩니다. 클러스터 다중 테넌트는 많은 단일 테넌트 전용 클러스터를 관리하는 대안입니다. 다중 테넌트 Kubernetes 클러스터의 운영자는 테넌트를 서로 격리해야 합니다. 이 격리는 손상된 테넌트 또는 악의적인 테넌트가 클러스터 및 다른 테넌트에서 수행할 수 있는 손상을 최소화합니다. 여러 사용자 또는 팀이 고정된 수의 노드로 동일한 클러스터를 공유하는 경우 한 팀이 공평하게 정해진 리소스 점유율 이상을 사용할 수 있다는 우려가 있습니다. 관리자는 리소스 할당량이라는 도구를 통해 이 문제를 해결할 수 있습니다.

다중 테넌트 AKS(Azure Kubernetes Service) 클러스터를 구축하려는 경우 Kubernetes에서 제공하는 리소스 격리 계층(클러스터, 네임스페이스, 노드, Pod 및 컨테이너)을 고려해야 합니다. 또한 여러 테넌트 간에 서로 다른 유형의 리소스를 공유할 때 보안에 미치는 영향도 고려해야 합니다. 예를 들어, 동일한 노드에 있는 다른 테넌트의 Pod를 예약하면 클러스터에 필요한 컴퓨터 수를 줄일 수 있습니다. 반면에 특정 워크로드가 같은 위치에 배치되는 것을 방지해야 할 수도 있습니다. 예를 들어 조직 외부의 신뢰할 수 없는 코드가 중요한 정보를 처리하는 컨테이너와 동일한 노드에서 실행되는 것을 허용하지 않을 수 있습니다. Azure Policy를 사용하여 신뢰할 수 있는 레지스트리에서만 AKS로 배포하도록 제한할 수 있습니다.

Kubernetes는 테넌트 간의 완벽한 보안 격리를 보장할 수 없지만 특정 사용 사례에 충분할 수 있는 기능을 제공합니다. 각 테넌트와 해당 Kubernetes 리소스를 자체 네임스페이스로 분리하는 것이 모범 사례입니다. 그런 다음 Kubernetes RBAC 및 네트워크 정책을 사용하여 테넌트 격리를 적용할 수 있습니다. (RBAC는 역할 기반 액세스 제어의 약자입니다.) 예를 들어 다음 그림은 각 테넌트에 대해 하나씩 동일한 클러스터에서 동일한 애플리케이션의 여러 인스턴스를 호스팅하는 일반적인 SaaS 공급자 모델을 보여 줍니다. 각 애플리케이션은 별도의 네임스페이스에 있습니다. 테넌트에 더 높은 수준의 실제 격리와 보장된 성능이 필요한 경우 해당 워크로드를 전용 노드 집합, 전용 풀 또는 전용 클러스터에 배포할 수 있습니다.

다중 테넌트 다이어그램

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

AGIC(Application Gateway Ingress Controller)는 AKS(Azure Kubernetes Service) 고객이 Azure Application Gateway를 사용하여 컨테이너화된 애플리케이션을 인터넷에 노출하는 작업을 수행할 수 있게 해주는 Kubernetes 애플리케이션입니다. AGIC는 호스팅되는 Kubernetes 클러스터를 모니터링하고 Application Gateway를 지속적으로 업데이트하여 선택한 서비스가 인터넷에 노출되도록 합니다. 수신 컨트롤러는 고객의 AKS 인스턴스에 있는 자체 Pod에서 실행됩니다. AGIC는 Kubernetes 리소스의 하위 집합에서 변경 내용을 모니터링합니다. AKS 클러스터의 상태는 Application Gateway 특정 구성으로 변환되고 ARM(Azure Resource Manager)에 적용됩니다. 이 아키텍처 샘플은 Azure Application Gateway 및 Application Gateway 수신 컨트롤러 추가 항목을 사용하여 공용 또는 비공용 AKS(Azure Kubernetes Service) 클러스터를 배포하는 입증된 사례를 보여 줍니다.

Azure AGIC(Application Gateway Kubernetes 수신 컨트롤러)의 단일 인스턴스는 여러 네임스페이스에서 이벤트를 수집하고 이를 관찰할 수 있습니다. AKS 관리자가 Application Gateway를 수신으로 사용하기로 결정한 경우 모든 네임스페이스는 Application Gateway의 동일한 인스턴스를 사용합니다. 수신 컨트롤러의 단일 설치는 액세스 가능한 네임스페이스를 모니터링하고 연결된 Application Gateway를 구성합니다.

잠재적인 사용 사례

AGIC(Application Gateway 수신 컨트롤러)를 사용하여 다중 테넌트 환경의 AKS(Azure Kubernetes Service) 클러스터에서 실행되는 인터넷 연결 워크로드를 노출하고 보호합니다.

고려 사항

다음 고려 사항 중 일부는 AKS(Azure Kubernetes Service)의 다중 테넌트와 완전히 관련되어 있지는 않지만 이 솔루션을 배포할 때 필수 요구 사항이 된다고 생각합니다. 여기에는 보안, 성능, 가용성 및 안정성, 스토리지, 스케줄러, 서비스 메시 및 모니터링 고려 사항이 포함됩니다.

다중 테넌트 지원 고려 사항

  • 다중 테넌트를 위한 AKS 클러스터를 설계합니다. Kubernetes는 동일한 클러스터에서 팀 및 워크로드를 논리적으로 격리할 수 있는 기능을 제공합니다. 목표는 각 팀이 필요로 하는 리소스 범위에서 최소한의 권한을 제공하는 것이어야 합니다. Kubernetes의 네임스페이스는 논리적 격리 경계를 만듭니다.
  • 논리적 격리를 사용하여 팀과 프로젝트를 분리합니다. 팀 또는 애플리케이션을 격리하기 위해 배포하는 실제 AKS 클러스터의 수를 최소화합니다. 클러스터의 논리적 분리는 일반적으로 실제로 격리된 클러스터보다 더 높은 Pod 밀도를 제공합니다.
  • 엄격한 실제 격리를 구현해야 할 때마다 전용 노드 풀 또는 전용 AKS 클러스터를 사용합니다. 예를 들어 작업자 노드 풀 또는 전체 클러스터를 다중 테넌트 환경의 팀이나 테넌트에 전용으로 사용할 수 있습니다.
    • taint 및 toleration의 조합을 사용하여 특정 노드 풀에 대한 Pod 배포를 제어할 수 있습니다. AKS의 노드는 노드 풀을 만들 때만 오염될 수 있습니다. 또는 레이블 및 nodePool 선택기를 사용하여 특정 노드 풀에 대한 워크로드 배포를 제어할 수 있습니다.

보안 고려 사항

보안 고려 사항이 AKS의 다중 테넌트와 완전히 관련되어 있지는 않지만 이 솔루션을 배포할 때 필수 요구 사항이 된다고 생각합니다.

네트워크 보안

  • Key Vault, Service Bus 또는 Azure SQL Database와 같은 AKS 워크로드에서 사용되는 모든 PaaS 서비스에 대한 프라이빗 엔드포인트를 만듭니다. 이는 애플리케이션과 이러한 서비스 간의 트래픽이 공용 인터넷에 노출되지 않도록 하기 위한 것입니다. 자세한 내용은 Azure Private Link란?을 참조하세요.
  • HTTPS를 통해 워크로드를 노출하도록 Kubernetes 수신 리소스를 구성하고 각 테넌트에 대해 별도의 하위 도메인 및 디지털 인증서를 사용합니다. AGIC(Application Gateway 수신 컨트롤러)는 SSL(Secure Socket Layer) 종료를 위해 Azure Application Gateway 수신기를 자동으로 구성합니다.
  • Web Application Firewall 정책을 사용하도록 Azure Application Gateway를 구성하여 AKS에서 실행되는 공용 워크로드를 악의적인 공격으로부터 보호합니다.
  • 기존 가상 네트워크 또는 온-프레미스 네트워크와의 통합을 위해 AKS에서 Azure CNI 네트워킹을 사용합니다. 또한 이 네트워크 모델을 사용하면 엔터프라이즈 환경에서 리소스 관리와 제어를 보다 유용하게 구분할 수 있습니다.
  • 네트워크 정책을 사용하여 서로 통신할 수 있는 구성 요소를 제어하여 서비스 내 통신을 분리하고 보호합니다. 기본적으로 Kubernetes 클러스터의 모든 Pod는 제한 없이 트래픽을 보내고 받을 수 있습니다. 보안을 개선시키기 위해 Azure 네트워크 정책 또는 Calico 네트워크 정책을 사용하여 서로 다른 마이크로 서비스 간의 트래픽 흐름을 제어하는 규칙을 정의할 수 있습니다. 자세한 내용은 네트워크 정책을 참조하세요.
  • AKS 노드에 대한 원격 연결을 노출하지 마십시오. 관리 가상 네트워크에서 요새 호스트 또는 점프 상자를 만듭니다. 요새 호스트를 사용하여 트래픽을 원격 관리 작업을 위한 AKS 클러스터로 안전하게 라우팅할 수 있습니다.
  • 프로덕션 환경에서 프라이빗 AKS 클러스터를 사용하거나 적어도 Azure Kubernetes Service에서 승인된 IP 주소 범위를 사용하여 API 서버에 대한 보안 액세스를 고려합니다.
  • 애플리케이션 설계 모범 사례와 결합된 Azure DDoS Protection은 향상된 DDoS 완화 기능을 제공하여 DDoS 공격에 대한 방어력을 높입니다. 경계 가상 네트워크에서 Azure DDOS Protection을 사용하도록 설정해야 합니다.

인증 및 권한 부여

  • Microsoft Entra 통합을 통해 AKS 클러스터를 배포합니다. 자세한 내용은 AKS에서 관리하는 Microsoft Entra 통합을 참조 하세요. Microsoft Entra ID를 사용하면 ID 관리 구성 요소가 중앙 집중화됩니다. 사용자 계정 또는 그룹 상태의 변경 내용은 AKS 클러스터에 액세스할 때 자동으로 업데이트됩니다. 역할 또는 ClusterRoles 및 결합을 사용하여 필요한 최소한의 권한으로 사용자 또는 그룹의 범위를 지정합니다.
  • Kubernetes RBAC를 사용하여 사용자 또는 그룹이 클러스터의 리소스에 대해 갖는 권한을 정의합니다. 필요한 최소한의 권한을 할당하는 역할 및 바인딩을 만듭니다. Kubernetes RBAC를 Microsoft Entra ID와 통합하여 사용자 상태 또는 그룹 멤버 자격의 변경 내용이 자동으로 업데이트되고 클러스터 리소스에 대한 액세스가 최신 상태입니다.
  • Azure RBAC를 사용하여 사용자 또는 그룹이 하나 이상의 구독에서 AKS 리소스에 대해 가져야 하는 최소 필수 권한을 정의합니다. 자세한 내용은 Kubernetes RBAC 및 Kubernetes 권한 부여에 Azure RBAC 사용을 참조하세요.
  • Microsoft Entra 워크로드 ID 사용하여 관리되는 리소스(예: Azure Key Vault, SQL Database, Service Bus 및 Cosmos DB)에 액세스하는 데 사용할 수 있는 개별 마이크로 서비스에 Azure 리소스의 관리 ID를 할당하는 것이 좋습니다. Kubernetes 비밀에서 연결 문자열 또는 자격 증명을 저장하고 검색할 필요가 없습니다.
  • Kubernetes 비밀이 아닌 Key Vault에서 자격 증명 및 연결 문자열과 같은 비밀에 액세스하려면 Azure Key Vault용 Secret Store CSI Driver를 사용하는 것이 좋습니다.
  • Dapr Secrets Stores 빌딩 블록을 Kubernetes의 관리 ID가 있는 Azure Key Vault 저장소와 함께 사용하여 Key Vault에서 비밀(자격 증명 및 연결 문자열)을 검색하는 것이 좋습니다.

워크로드 및 클러스터

  • Kubernetes API 서버에 대한 액세스 보호는 클러스터를 보호하기 위해 수행할 수 있는 가장 중요한 작업 중 하나입니다. Kubernetes RBAC(Kubernetes 역할 기반 액세스 제어)를 Microsoft Entra ID와 통합하여 API 서버에 대한 액세스를 제어합니다. 이러한 제어를 통해 AKS Azure 구독에 대한 액세스를 보호할 때와 동일한 방식으로 AKS를 보호할 수 있습니다.
  • 컨테이너가 수행할 수 있는 작업에 대한 액세스를 제한합니다. Pod 보안 허용을 사용하여 Pod 만들기 및 업데이트에 대한 세분화된 권한 부여를 사용하도록 설정합니다. 최소 개수의 권한을 제공하고, 루트/권한 에스컬레이션을 사용하지 않도록 합니다. 추가 모범 사례에 대해서는 리소스에 대한 pod 액세스 보안 유지를 참조하세요.
  • 가능하면 컨테이너를 루트 사용자로 실행하지 마세요.
  • AppArmor Linux 커널 보안 모듈을 사용하여 컨테이너가 수행할 수 있는 작업을 제한합니다.
  • AKS 클러스터를 최신 Kubernetes 버전으로 정기적으로 업그레이드하여 새로운 기능과 버그 수정을 활용합니다.
  • AKS는 각 Linux 노드에 보안 수정 사항을 자동으로 다운로드하여 설치하지만 필요한 경우 노드를 자동으로 다시 부팅하지 않습니다. kured를 사용하여 보류 중인 다시 부팅, cordon 및 drain 노드를 관찰하고 마지막으로 업데이트를 적용합니다. Windows Server 노드의 경우 AKS 업그레이드 작업을 정기적으로 실행하여 Pod를 안전하게 차단하고 드레이닝하고 업데이트된 노드를 배포합니다.
  • 모든 Pod 내 통신에 HTTPS 및 gRPC 보안 전송 프로토콜을 사용하고 OAuth 또는 JWT와 같이 모든 요청에 대해 일반 자격 증명을 보낼 필요가 없는 고급 인증 메커니즘을 사용하는 것을 고려합니다. Istio, Linkerd 또는 Consul과 같은 서비스 메시를 활용하거나 Dapr을 사용하여 서비스 내 통신을 보호할 수 있습니다.

Azure Container Registry

  • 컨테이너 이미지에 취약성이 있는지 검사하고 유효성 검사를 통과한 이미지만 배포합니다. 정기적으로 기본 이미지 및 애플리케이션 런타임을 업데이트한 후 AKS 클러스터에서 워크로드를 다시 배포합니다. CI/CD 배포 워크플로에는 컨테이너 이미지를 검사하는 프로세스가 포함되어야 합니다. 클라우드용 Microsoft Defender DevOps 보안을 사용하여 자동화된 파이프라인에서 빌드/배포 시간 동안 코드에서 취약성을 검사할 수 있습니다. 또는 Prisma Cloud 또는 Aqua와 같은 도구를 사용하여 확인된 이미지만 검사하고 배포할 수 있습니다.
  • 애플리케이션 이미지에 대해 기본 이미지를 사용할 경우 기본 이미지가 업데이트될 때 자동화를 통해 새 이미지를 빌드합니다. 이러한 기본 이미지에는 일반적으로 보안 수정 사항이 포함되어 있으므로 다운스트림 애플리케이션 컨테이너 이미지를 업데이트합니다. 기본 이미지 업데이트에 대한 자세한 내용은 Azure Container Registry 작업을 사용하여 기본 이미지 업데이트 시 이미지 빌드 자동화를 참조하세요.

성능 고려 사항

성능 고려 사항이 AKS(Azure Kubernetes Service)의 다중 테넌트와 완전히 관련되어 있지는 않지만 이 솔루션을 배포할 때 필수 요구 사항이 된다고 생각합니다.

  • 대기 시간이 짧은 워크로드의 경우 근접 배치 그룹에 전용 노드 풀을 배포하는 것이 좋습니다. Azure에서 애플리케이션을 배포할 때 지역 또는 가용성 영역에 걸쳐 VM(가상 머신) 인스턴스를 분산하면 네트워크 대기 시간이 발생하여 애플리케이션의 전체 성능에 영향을 줄 수 있습니다. 근접 배치 그룹은 Azure 컴퓨팅 리소스가 실제로 서로 가까이 있는지 확인하는 데 사용되는 논리적 그룹입니다. 게임, 엔지니어링 시뮬레이션 및 HFT(고주파 거래)와 같은 일부 사용 사례에는 짧은 대기 시간과 빠르게 완료되는 작업이 필요합니다. 이러한 HPC(고성능 컴퓨팅) 시나리오에서는 클러스터의 노드 풀에 PPG(근접 배치 그룹)를 사용하는 것이 좋습니다.
  • 더 빠른 빌드를 만드는 데 도움이 되므로 항상 더 작은 컨테이너 이미지를 사용합니다. 작은 이미지는 또한 공격 표면이 줄어들기 때문에 공격 벡터에 덜 취약합니다.
  • Kubernetes 자동 크기 조정을 사용하여 트래픽이 증가할 때 AKS 클러스터의 작업자 노드 수를 동적으로 스케일 아웃합니다. 수평형 Pod 자동 크기 조정기 및 클러스터 자동 크기 조정기를 사용하면 노드 및 Pod 볼륨이 실시간으로 동적으로 조정되어 트래픽 조건과 일치하게 되고 용량 문제로 인한 가동 중지 시간을 방지할 수 있습니다. 자세한 내용은 AKS(Azure Kubernetes Service)에서 클러스터 자동 크기 조정기 사용을 참조하세요.

가용성 및 안정성 고려 사항

가용성 및 안정성 고려 사항이 AKS(Azure Kubernetes Service)의 다중 테넌트와 완전히 관련되어 있지는 않지만 이 솔루션을 배포할 때는 필수 요구 사항이 된다고 생각합니다. AKS 클러스터 및 워크로드에 대한 가용성을 최적화하려면 다음 방법을 고려합니다.

컨테이너

  • Kubernetes 상태 프로브를 사용하여 컨테이너가 활성 상태이고 정상인지 확인합니다.

    • livenessProbe는 컨테이너가 실행 중인지 여부를 나타냅니다. 활동성 프로브가 실패하면 kubelet이 컨테이너를 종료하고 컨테이너는 다시 시작 정책을 따릅니다.
    • readinessProbe는 컨테이너가 요청에 응답할 준비가 되었는지 여부를 나타냅니다. 준비 상태 프로브가 실패하면 엔드포인트 컨트롤러는 Pod과 일치하는 모든 서비스의 엔드포인트에서 Pod의 IP 주소를 제거합니다. 초기 지연 전의 기본 준비 상태는 실패입니다.
    • 시작 프로브는 컨테이너 내의 애플리케이션이 시작되었는지 여부를 나타냅니다. 시작 프로브가 제공되면 성공할 때까지 다른 모든 프로브는 사용하지 않도록 설정됩니다. 시작 프로브가 실패하면 kubelet이 컨테이너를 종료하고 컨테이너는 다시 시작 정책을 따릅니다.

  • 리소스 경합은 서비스 가용성에 영향을 줄 수 있습니다. 단일 컨테이너가 클러스터 메모리 및 CPU 리소스에 과부하를 일으킬 수 없도록 컨테이너 리소스 제약 조건을 정의합니다. AKS 진단을 사용하여 클러스터의 문제를 식별할 수 있습니다.

  • 리소스 제한을 사용하여 컨테이너에 허용되는 총 리소스를 제한하여 특정 컨테이너에 리소스가 몰리지 않도록 합니다.

컨테이너 레지스트리

  • Azure Container Registry에 컨테이너 이미지를 저장한 다음 Azure Container Registry 지역 복제를 사용하여 각 AKS 지역에 레지스트리를 지역 복제하는 것이 좋습니다. 지역 복제는 프리미엄 SKU ACR 레지스트리의 기능입니다.
  • 컨테이너 이미지에 취약성이 있는지 검사하고 유효성 검사를 통과한 이미지만 배포합니다. 기본 이미지와 애플리케이션 런타임을 정기적으로 업데이트한 다음 AKS 클러스터에 워크로드를 다시 배포합니다.
  • Pod 및 배포에서 사용할 수 있는 이미지 레지스트리를 제한합니다. 사용할 수 있는 이미지의 유효성을 검사하고 제어하는 신뢰할 수 있는 레지스트리만 허용합니다.
  • 애플리케이션 이미지에 대해 기본 이미지를 사용할 경우 기본 이미지가 업데이트될 때 자동화를 통해 새 이미지를 빌드합니다. 이러한 기본 이미지에는 일반적으로 보안 수정 사항이 포함되어 있으므로 다운스트림 애플리케이션 컨테이너 이미지를 업데이트합니다. 컨테이너 레지스트리에 이미지를 게시하기 전에 CI/CD 파이프라인의 일부로 컨테이너 이미지에서 취약성을 검사하는 것이 좋습니다. 컨테이너용 Azure Defender를 CI/CD 워크플로에 통합할 수 있습니다.
  • Azure Container Registry의 ACR 작업을 활용하여 Docker 컨테이너에 대한 OS 및 프레임워크 패치를 자동화합니다. ACR 작업은 기본 이미지 중 하나에서 OS 또는 애플리케이션 프레임워크를 패치할 때와 같이 컨테이너의 기본 이미지가 업데이트될 때 자동화된 빌드 실행을 지원합니다.

지역 내 복원력

  • AKS 클러스터의 노드 풀을 지역 내의 모든 가용성 영역에 배포하고 노드 풀 전면에 Azure Standard Load Balancer 또는 Azure Application Gateway를 사용하는 것을 고려합니다. 이 토폴로지는 단일 데이터 센터가 중단된 경우 더 나은 복원력을 제공합니다. 이러한 방식으로 클러스터 노드는 지역 내 3개의 개별 가용성 영역에 있는 여러 데이터 센터에 분산됩니다.
  • 지역 내 복원력 및 고가용성을 위해 Azure Container Registry에서 영역 중복성을 사용하도록 설정합니다.
  • Pod 토폴로지 확산 제약 조건을 사용하여 지역, 가용성 영역, 노드와 같은 장애 도메인 간에 AKS 클러스터에서 Pod가 분산되는 방식을 제어합니다.
  • 중요 업무용 워크로드를 호스팅하는 AKS 클러스터에 대해 작동 시간 SLA를 사용하는 것이 좋습니다. 작동 시간 SLA는 재정적 지원을 받는 상위 SLA를 클러스터에 설정하는 선택적 기능입니다. 작동 시간 SLA는 가용성 영역을 사용하는 클러스터에 대해 Kubernetes API 서버 엔드포인트의 99.95% 가용성을 보장합니다. 또한 가용성 영역을 사용하지 않는 클러스터에 대해 99.9% 가용성을 보장합니다. AKS는 SLA 요구 사항이 충족되도록 업데이트 및 오류 도메인에서 마스터 노드 복제본을 사용합니다.

재해 복구 및 비즈니스 연속성

  • 한 지역 내에서 최소 두 쌍의 Azure 지역에 솔루션을 배포하는 것이 좋습니다. 또한 비즈니스 연속성 및 재해 복구를 보장하기 위해 활성/활성 또는 활성/수동 라우팅 방법으로 Azure Traffic Manager 또는 Azure Front Door와 같은 글로벌 부하 분산 장치를 채택해야 합니다.
  • 핵심 서비스가 주 지역의 중단으로 인해 영향을 받는 경우 예측할 수 없는 문제를 방지하기 위해 QA 환경에서 모든 지역 장애 조치(failover) 프로세스를 스크립팅, 문서화 및 주기적으로 테스트해야 합니다.
  • 또한 이러한 테스트는 장애 조치(failover)에 필요한 최종 수동 프로세스 및 개입과 함께 DR 접근 방식이 RPO/RTO 대상을 충족하는지 유효성 검사하기 위한 것입니다.
  • 예상대로 작동하는지 이해하기 위해 장애 복구 절차를 테스트해야 합니다.
  • Azure Container Registry에 컨테이너 이미지를 저장하고 레지스트리를 각 AKS 지역에 지역 복제합니다. 자세한 내용은 Azure Container Registry의 지역에서 복제를 참조하세요.
  • 가능하면 컨테이너 내부에 서비스 상태를 저장하지 마세요. 대신, 다중 지역 복제를 지원하는 Azure PaaS(Platform as a Service)를 사용하세요.
  • Azure Storage를 사용하는 경우 주 지역에서 백업 지역으로 스토리지를 마이그레이션하는 방법을 준비하고 테스트합니다.
  • GitOps를 사용하여 클러스터 구성을 배포하는 것이 좋습니다. GitOps를 사용하면 주 클러스터와 DR 클러스터 간의 균일성을 제공하며 클러스터 손실 시 새 클러스터를 빠르게 다시 빌드할 수 있습니다.
  • Azure Kubernetes Service 백업 또는 Velero와 같은 도구를 사용하여 클러스터 구성의 백업/복원을 고려합니다.

스토리지 고려 사항

스토리지 고려 사항이 AKS(Azure Kubernetes Service)의 다중 테넌트와 완전히 관련되어 있지는 않지만 이 솔루션을 배포할 때 필수 요구 사항이 된다고 생각합니다.

  • 더 빠른 노드 크기 조정 및 클러스터 업그레이드와 함께 더 낮은 읽기/쓰기 대기 시간을 제공하는 임시 OS 디스크로 AKS 클러스터를 배포하는 것이 좋습니다.
  • 올바른 스토리지를 선택하기 위해 애플리케이션 요구를 이해합니다. 프로덕션 워크로드를 위해서는 고성능의 SSD 기반 스토리지를 사용합니다. 여러 Pod가 동일한 파일에 동시에 액세스해야 하는 경우 Azure Files와 같은 네트워크 기반 스토리지 시스템을 계획합니다. 자세한 내용은 AKS(Azure Kubernetes Service)의 애플리케이션에 대한 스토리지 옵션을 참조하세요.
  • 각 노드 크기가 최대 디스크 수를 지원합니다. 또한 다양한 노드 크기는 다양한 양의 로컬 스토리지 및 네트워크 대역폭을 제공합니다. 애플리케이션 요구 사항을 계획하여 적절한 크기의 노드를 배포하세요.
  • 관리 오버헤드를 줄이고 크기 조정을 허용하려면 영구 볼륨을 정적으로 만들고 할당하지 마세요. 동적 프로비저닝을 사용합니다. 스토리지 클래스에서 pod가 삭제될 때 불필요한 스토리지 비용을 최소화하도록 적절한 회수 정책을 정의합니다.

스케줄러 고려 사항

스케줄러 고려 사항 중 일부는 AKS(Azure Kubernetes Service)의 다중 테넌트와 완전히 관련되어 있지는 않지만 이 솔루션을 배포할 때 필수 요구 사항이 된다고 생각합니다.

  • 클러스터 운영자와 애플리케이션 개발자가 AKS(Azure Kubernetes Service)에서 애플리케이션을 성공적으로 빌드하고 실행할 수 있도록 모범 사례를 검토하고 구현해야 합니다.
  • 모든 네임스페이스에 대해 네임스페이스 수준에서 리소스 할당량을 계획하고 적용합니다. Pod가 리소스 요청 및 제한을 정의하지 않으면 배포를 거부합니다. 리소스 사용량을 모니터링한 다음 필요에 따라 할당량을 조정합니다. 여러 팀 또는 테넌트가 고정된 수의 노드가 있는 AKS 클러스터를 공유하는 경우 리소스 할당량을 사용하여 각 팀 또는 테넌트에 공정한 리소스 공유를 할당할 수 있습니다.
  • 범위 제한을 채택하여 CPU 및 메모리 측면에서 네임스페이스의 리소스 할당(Pod 또는 컨테이너에 대한)을 제한합니다.
  • 애플리케이션 배포에 사용하는 YAML 매니페스트 또는 Helm 차트에서 Pod의 CPU 및 메모리 사용량에 대한 리소스 요청 및 제한을 명시적으로 정의합니다. Pod의 컨테이너에 대한 리소스 요청을 지정할 때 Kubernetes 스케줄러는 이 정보를 사용하여 Pod를 배치할 노드를 결정합니다. 컨테이너에 대한 리소스 제한(예: CPU 또는 메모리)을 지정할 때 kubelet은 실행 중인 컨테이너가 설정한 제한보다 더 많은 리소스를 사용할 수 없도록 이러한 제한을 적용합니다.
  • 애플리케이션의 가용성을 유지하려면 Pod 중단 예산을 정의하여 클러스터에서 최소 수의 Pod를 사용할 수 있도록 합니다.
  • 우선 순위 클래스는 Pod의 중요성을 나타내는 데 사용할 수 있습니다. Pod를 예약할 수 없는 경우 스케줄러는 보류 중인 Pod의 예약을 가능하게 하기 위해 우선 순위가 낮은 Pod를 선점(축출)하려고 합니다.
  • Kubernetes taint 및 tolerations를 사용하여 리소스 집약적인 애플리케이션을 특정 노드에 배치하고 노이즈가 많은 이웃 문제를 방지합니다. 노드 리소스를 필요로 하는 워크로드에 대해 사용 가능한 노드 리소스를 유지하고 다른 워크로드가 노드에서 예약되도록 허용하지 마세요.
  • 노드 선택기, 노드 선호도 또는 Pod 간 선호도를 사용하여 노드의 Pod 일정을 제어합니다. Pod 간 선호도 및 반선호도 설정을 사용하여 수다스러운 통신이 있는 Pod를 함께 배치하고, Pod를 서로 다른 노드에 배치하고, 동일한 노드에서 동일한 Pod 종류의 여러 인스턴스를 실행하지 않도록 합니다.

서비스 메시 고려 사항

서비스 메시 고려 사항이 AKS의 다중 테넌트와 완전히 관련되어 있지는 않지만 이 솔루션을 배포할 때 필수 요구 사항이 된다고 생각합니다.

  • 상호 TLS를 통해 마이크로 서비스의 가시성, 안정성 및 보안을 개선하기 위해 AKS 클러스터에서 오픈 소스 서비스 메시(예: Istio, Linkerd 또는 Consul)를 사용하는 것이 좋습니다. 트래픽 분할 전략(예: 블루/그린 배포 및 카나리아 배포)을 구현할 수도 있습니다. 간단히 말해서 서비스 메시는 서비스 간 통신을 안전하고 빠르고 안정적으로 만들기 위한 전용 인프라 계층입니다. AKS 통합 Istio 추가 기능을 보려면 다음을 참조하세요 . Istio 서비스 메시 AKS 추가 기능

  • Dapr을 채택하여 탄력적인 마이크로 서비스 스테이트리스(Stateless) 및 스테이트풀(Stateful) 애플리케이션을 구축하는 것이 좋습니다. 모든 프로그래밍 언어와 개발자 프레임워크를 사용할 수 있습니다.

DevOps 고려 사항

  • GitHub Actions 또는 Azure DevOps와 같은 DevOps 시스템을 사용하여 CI/CD 파이프라인의 Helm 차트를 사용하여 AKS(Azure Kubernetes Service)에 워크로드를 배포합니다. 자세한 내용은 Azure Kubernetes Service 빌드 및 배포를 참조하세요.

  • 애플리케이션 수명 주기 관리에 A/B 테스트 및 카나리아 배포를 도입하여 모든 사용자가 사용할 수 있도록 하기 전에 애플리케이션을 적절하게 테스트합니다. 동일한 서비스의 서로 다른 버전 간에 트래픽을 분할하는 데 사용할 수 있는 몇 가지 기술이 있습니다.

  • 또는 서비스 메시 구현에서 제공하는 트래픽 관리 기능을 사용할 수 있습니다. 자세한 내용은 다음을 참조하세요.

  • Azure Container Registry 또는 다른 컨테이너 레지스트리(예: Docker Hub)를 사용하여 클러스터에 배포된 프라이빗 Docker 이미지를 저장합니다. AKS는 Microsoft Entra ID를 사용하여 Azure Container Registry로 인증할 수 있습니다.

모니터링 고려 사항

모니터링 고려 사항이 AKS(Azure Kubernetes Service)의 다중 테넌트와 완전히 관련되어 있지는 않지만 이 솔루션을 배포할 때 필수 요구 사항이 된다고 생각합니다.

  • AKS 클러스터 및 워크로드의 상태 상태 모니터링하는 Azure 통합 모니터링 옵션을 고려합니다.
  • 진단 로그 및 메트릭을 수집하도록 모든 PaaS 서비스(예: Azure Container Registry 및 Key Vault)를 Azure Monitor Log Analytics로 구성합니다.

비용 최적화

이 아키텍처의 비용은 다음과 같은 구성 측면에 따라 다릅니다.

  • 서비스 계층
  • 확장성, 주어진 수요를 지원하기 위해 서비스에 의해 동적으로 할당되는 인스턴스의 수를 의미합니다.
  • 자동화 스크립트
  • 재해 복구 수준

이러한 측면을 평가한 후 Azure 가격 계산기로 이동하여 비용을 예상합니다. 또한 가격 최적화 옵션에 대한 자세한 내용은 Microsoft Azure Well-Architected Framework의 비용 최적화 원칙을 참조하세요.

시나리오 배포

이 시나리오의 소스 코드는 GitHub에서 사용할 수 있습니다. 다음 그림과 같이 이 GitHub 리포지토리에서 데모 애플리케이션을 찾을 수도 있습니다.

다이어그램은 AKS 아키텍처를 사용하여 이 AGIC의 배포를 보여 줍니다.

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

필수 구성 요소

온라인 배포의 경우 기존 Azure 계정이 있어야 합니다. 계정이 필요한 경우 시작하기 전에 무료 Azure 계정을 만듭니다.

Azure에 배포

  1. Azure 구독 정보가 준비되어 있는지 확인합니다.

  2. 워크벤치 GitHub 리포지토리를 복제하여 시작합니다.

    git clone https://github.com/Azure-Samples/aks-agic.git

  3. README.md 파일에 제공된 지침을 따릅니다.

참가자

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

주요 작성자:

다음 단계

Azure Kubernetes Service

Azure Application Gateway

Azure Application Gateway 수신 컨트롤러

Azure Application Gateway WAF

아키텍처 지침

참조 아키텍처