고급 AKS(Azure Kubernetes Service) 마이크로 서비스 아키텍처

이 참조 아키텍처는 AKS(Azure Kubernetes Service)에서 마이크로 서비스를 실행할 때 고려해야 할 몇 가지 구성에 대해 설명합니다. 이 문서에서는 마이크로 서비스 기반 애플리케이션에서 네트워크 정책 구성, Pod 자동 크기 조정 및 분산 추적에 대해 설명합니다.

이 아키텍처는 AKS 인프라의 시작점 역할을 하는 AKS 기준 아키텍처를 기반으로 합니다. AKS 기준은 Microsoft Entra 워크로드 ID, 수신 및 송신 제한, 리소스 제한 및 기타 보안 AKS 인프라 구성과 같은 인프라 기능을 설명합니다. 이러한 기능은 이 문서에서 다루지 않습니다. 마이크로 서비스 콘텐츠를 진행하기 전에 AKS 기준 아키텍처를 숙지하는 것이 좋습니다.

아키텍처

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

AKS에서 보다 기본적인 마이크로 서비스 예제로 시작하려면 AKS의 마이크로 서비스 아키텍처를 참조하세요.

워크플로

이 요청 흐름은 게시자-구독자, 경쟁 소비자 및 게이트웨이 라우팅 클라우드 디자인 패턴을 구현합니다.

다음 워크플로는 이전 다이어그램에 해당합니다.

1. 드론 픽업을 예약하기 위해 HTTPS 요청이 제출됩니다. 요청은 Azure Application Gateway를 통해 AKS에서 클러스터 내 마이크로 서비스로 실행되는 수집 웹 애플리케이션으로 전달됩니다.

2. 수집 웹 애플리케이션은 메시지를 생성하고 Azure Service Bus 메시지 큐로 보냅니다.

3. 백 엔드 시스템은 드론을 할당하고 사용자에게 알깁니다. 워크플로 마이크로 서비스는 다음 작업을 수행합니다.

   • 서비스 버스 메시지 큐에서 메시지 정보를 소비합니다.

   • Azure Managed Redis 외부 데이터 스토리지에 데이터를 전달하는 배달 마이크로 서비스에 HTTPS 요청을 보냅니다.

   • 드론 스케줄러 마이크로 서비스에 HTTPS 요청을 보냅니다.

   • Azure DocumentDB 외부 데이터 스토리지에 데이터를 전달하는 패키지 마이크로 서비스에 HTTPS 요청을 보냅니다.

   • 고급 컨테이너 네트워킹 서비스 정책(Cilium NetworkPolicy)은 클러스터 내의 서비스 간 트래픽을 제어하며, 데이터 평면은 선택적 노드 간 Pod 암호화(WireGuard)를 투명하게 적용합니다. 고급 컨테이너 네트워킹 서비스는 기본적으로 사용하도록 설정되지 않습니다. 노드 수준 및 Pod 수준 데이터를 가져와서 엔드 투 엔드 가시성을 위해 Azure Monitor에 수집합니다.

4. 아키텍처는 HTTPS GET 요청을 사용하여 배달 상태를 반환합니다. 이 요청은 Application Gateway를 통해 배달 마이크로 서비스로 전달됩니다.

5. 배달 마이크로 서비스는 Azure Managed Redis에서 데이터를 읽습니다.

구성 요소

• AKS 는 컨테이너화된 애플리케이션을 배포하고 크기 조정하기 위해 관리형 클러스터를 제공하는 관리되는 Kubernetes 플랫폼입니다. AKS를 사용하는 경우 Azure는 Kubernetes API 서버를 관리합니다. 클러스터 운영자는 Kubernetes 노드 또는 노드 풀에 액세스하고 관리할 수 있습니다. 이 아키텍처는 다음 AKS 인프라 기능을 사용합니다.

  • Azure RBAC(Azure 역할 기반 액세스 제어)용 AKS 관리 Microsoft Entra ID 는 ID 기반 액세스 제어를 적용하기 위해 AKS와 Microsoft Entra ID를 통합하는 기능입니다. 이 아키텍처에서는 클러스터 사용자 및 워크로드에 대한 안전하고 중앙 집중식 인증 및 권한 부여를 보장합니다.

  • Cilium에서 제공하는 Azure CNI 는 Azure 가상 네트워크에 직접 연결하는 데 권장되는 네트워킹 솔루션입니다. 이 아키텍처에서는 기본 제공 네트워크 정책 기능 및 트래픽 가시성을 제공하면서 가상 네트워크의 IP 주소를 Pod에 할당합니다.

  • Advanced Container Networking Services 는 AKS에 대한 관리형 네트워킹 기능 모음으로, 네트워크 가시성과 향상된 클러스터 내 보안을 제공합니다.

    • Container Network Observability는 Hubble 및 Retina와 같은 eBPF(확장 버클리 패킷 필터) 기반 도구를 사용하여 DNS(도메인 이름 시스템) 쿼리, Pod 간 및 Pod-서비스 간 흐름, 패킷 손실 및 기타 메트릭을 수집합니다. Cilium 및 비 Cilium Linux 데이터 평면에서 작동합니다. 또한 시각화 및 경고를 위해 Prometheus용 Azure Monitor 관리형 서비스 및 Azure Managed Grafana와 통합됩니다. 이 아키텍처에서 Container Network Observability는 마이크로 서비스에서 정책 구성 오류, DNS 대기 시간 또는 오류 및 트래픽 불균형을 진단합니다.

    • Container Network Security는 Cilium에서 제공하는 Azure CNI를 사용하는 클러스터에 적용됩니다. Cilium NetworkPolicy 리소스를 적용하여, 정규화된 도메인 이름(FQDN) 기반의 송신 필터링을 포함하여 제로 트러스트 네트워크 세분화를 구현하고 운영 오버헤드를 줄입니다. 이 아키텍처에서 클러스터 내 FQDN 정책은 Azure Firewall 또는 Azure NAT Gateway와 함께 작동하여 정책 유지 관리를 간소화하면서 최소 권한 송신을 적용합니다.

  • AKS용 Azure Policy 추가 기능은 거버넌스 및 규정 준수 제어를 AKS 클러스터로 직접 가져오는 기본 제공 확장입니다. Azure Policy를 사용하여 AKS 리소스에 거버넌스 규칙을 적용합니다. 이 아키텍처에서는 구성의 유효성을 검사하고 권한 없는 배포를 제한하여 규정 준수를 적용합니다.

  • 애플리케이션 라우팅 추가 기능을 활용하는 관리형 NGINX 인그레스은 HTTP 또는 HTTPS 트래픽을 사용하여 애플리케이션을 인터넷에 노출하는 데 도움이 되는 AKS의 기능입니다. AKS에 대해 미리 구성된 NGINX 수신 컨트롤러를 제공합니다. 이 아키텍처에서는 서비스에 대한 트래픽 라우팅을 처리하고 Application Gateway에 Pod를 노출할 수 있도록 합니다.

  • 시스템 및 사용자 노드 풀 분리 는 클러스터 노드를 두 가지 유형의 노드 풀로 나누고 AKS 인프라 구성 요소를 애플리케이션 워크로드에서 격리하는 아키텍처 사례입니다. 이 아키텍처에서는 노드 풀을 특정 운영 역할에 할당하여 보안 및 리소스 효율성을 향상합니다.

  • 워크로드 ID 는 Kubernetes 워크로드가 클러스터에 저장된 비밀 또는 자격 증명 없이 Microsoft Entra ID를 사용하여 Azure 리소스에 액세스할 수 있는 안전하고 확장 가능한 방법입니다. 워크로드 ID를 사용하면 AKS 워크로드가 페더레이션 ID를 사용하여 Azure 리소스에 안전하게 액세스할 수 있습니다. 이 아키텍처에서는 비밀에 대한 필요성을 없애고 ID 기반 액세스를 통해 보안 태세를 개선합니다.

• Application Gateway 는 계층 7 부하 분산 및 WAF(웹 애플리케이션 방화벽) 기능을 제공하는 Azure 관리형 서비스입니다. 이 아키텍처에서는 수집 마이크로 서비스를 퍼블릭 엔드포인트로 노출하고 들어오는 웹 트래픽을 애플리케이션에 분산합니다.

• Azure Firewall 은 지능형 클라우드 네이티브 네트워크 보안 및 위협 방지를 제공하는 Azure 관리형 서비스입니다. 이 아키텍처에서는 마이크로 서비스에서 외부 리소스로의 아웃바운드 통신을 제어하여 승인된 FQDN만 송신 트래픽으로 허용합니다.

• Azure Private Link 는 Microsoft 백본 네트워크를 통해 Azure PaaS(Platform as a Service) 제품에 대한 프라이빗 연결을 가능하게 하는 Azure 관리형 서비스입니다. 이 아키텍처에서는 프라이빗 IP 주소를 할당하여 프라이빗 엔드포인트를 통해 AKS 노드 풀에서 Azure Container Registry 및 Azure Key Vault에 액세스합니다.

• Azure Virtual Network 는 애플리케이션 및 VM(가상 머신)을 실행하기 위해 격리되고 안전한 환경을 제공하는 Azure 관리형 서비스입니다. 이 아키텍처에서는 피어된 허브-스포크 토폴로지 사용 허브 네트워크는 Azure Firewall 및 Azure Bastion을 호스트합니다. 스포크 네트워크에는 Application Gateway 서브넷과 함께 AKS 시스템 및 사용자 노드 풀 서브넷이 포함됩니다.

외부 스토리지 및 기타 구성 요소

• Azure Managed Redis 는 캐싱, 세션 스토리지 및 실시간 데이터 액세스를 위한 고성능 메모리 내 데이터 저장소를 제공하는 Azure 관리형 서비스입니다. 기존 캐싱 외에도 JSON 문서 스토리지, 전체 텍스트 및 벡터 검색 및 스트림 처리와 같은 고급 데이터 형식 및 기능에 대한 지원이 포함됩니다. 이 아키텍처에서 배달 마이크로 서비스는 Azure Managed Redis를 상태 저장소 및 사이드 캐시 로 사용하여 트래픽이 많은 동안 속도와 응답성을 향상시킵니다.

• Container Registry 는 AKS에서 배포할 프라이빗 컨테이너 이미지를 저장하는 Azure 관리형 서비스입니다. 이 아키텍처에서는 마이크로 서비스에 대한 컨테이너 이미지를 보유하고 AKS는 Microsoft Entra 관리 ID를 사용하여 인증합니다. Docker 허브와 같은 다른 레지스트리를 사용할 수도 있습니다.

• Azure Cosmos DB 는 Azure 관리형, 전역적으로 분산된 NoSQL, 관계형 및 벡터 데이터베이스 서비스입니다. 이 아키텍처에서 Azure Cosmos DB 및 Azure DocumentDB 는 각 마이크로 서비스에 대한 외부 데이터 저장소 역할을 합니다.

• Key Vault 는 비밀, 키 및 인증서를 안전하게 저장하고 관리하는 Azure 관리 서비스입니다. 이 아키텍처에서 Key Vault는 마이크로 서비스에서 Azure Cosmos DB 및 Azure Managed Redis에 액세스하는 데 사용하는 자격 증명을 저장합니다.

• Azure Monitor 는 서비스 전반에 걸쳐 메트릭, 로그 및 원격 분석을 수집하는 Azure 관리형 관찰 플랫폼입니다. 이 아키텍처에서는 AKS 및 통합 서비스의 오류에 대한 애플리케이션, 경고, 대시보드 및 근본 원인 분석을 모니터링할 수 있습니다.

  고급 컨테이너 네트워킹 서비스에 대한 컨테이너 네트워크 관찰성은 흐름 가시성에 허블을 사용하고, 큐레이팅된 네트워크 원격 분석에는 Retina를 사용합니다. 이러한 도구는 문제 해결 및 SLO(서비스 수준 목표) 보고를 위해 Prometheus 및 Azure Managed Grafana용 Azure Monitor 관리 서비스와 같은 관리되는 관찰성 백 엔드와 통합됩니다.

• Service Bus 는 분산 애플리케이션 간의 안정적이고 비동기적인 통신을 지원하는 Azure 관리형 메시징 서비스입니다. 이 아키텍처에서 Service Bus는 수집 및 워크플로 마이크로 서비스 간의 큐 계층 역할을 하므로 분리되고 확장 가능한 메시지 교환이 가능합니다.

기타 작업에서 시스템 구성 요소를 지원합니다.

• Flux 는 AKS에서 GitOps를 사용하도록 설정하는 Kubernetes에 대한 Azure 지원 오픈 소스 및 확장 가능한 지속적인 업데이트 솔루션입니다. 이 아키텍처에서 Flux는 Git 리포지토리에서 애플리케이션 매니페스트 파일을 동기화하여 배포를 자동화하여 AKS 클러스터에 일관되고 선언적인 마이크로 서비스를 제공합니다.

• Helm 은 Kubernetes 개체를 게시, 배포, 버전 관리 및 업데이트를 위한 단일 단위로 번들로 묶는 Kubernetes 네이티브 패키지 관리자입니다. 이 아키텍처에서 Helm은 마이크로 서비스를 패키지하고 AKS 클러스터에 배포하는 데 사용됩니다.

• Key Vault 비밀 저장소 CSI 드라이버 공급자 는 AKS 클러스터가 CSI 볼륨을 사용하여 Key Vault에서 비밀을 탑재할 수 있도록 하는 Azure 통합 드라이버입니다. 이 아키텍처에서 비밀은 마이크로 서비스 컨테이너에 직접 탑재되므로 Azure Cosmos DB 및 Azure Managed Redis에 대한 자격 증명을 안전하게 검색할 수 있습니다.

대안

애플리케이션 라우팅 추가 기능을 사용하는 대신 컨테이너용 Application Gateway 및 Istio 게이트웨이 추가 기능과 같은 대안을 사용할 수 있습니다. AKS의 수신 옵션 비교는 AKS의 수신을 참조하세요. 컨테이너용 Application Gateway는 Application Gateway 수신 컨트롤러의 진화이며 트래픽 분할 및 가중 라운드 로빈 부하 분산과 같은 추가 기능을 제공합니다.

Flux 대신 GitOps 도구로 ArgoCD를 사용할 수 있습니다. Flux 및 ArgoCD는 모두 클러스터 확장으로 사용할 수 있습니다.

키 자격 증명 모음에 Azure Cosmos DB 및 Azure Managed Redis에 대한 자격 증명을 저장하는 대신 암호 없는 인증 메커니즘이 더 안전하기 때문에 관리 ID를 사용하여 인증하는 것이 좋습니다. 자세한 내용은 관리 ID를 사용하여 Azure VM에서 Azure Cosmos DB에 연결 하고 Microsoft Entra ID를 사용하여 관리 ID를 인증하여 Service Bus 리소스에 액세스하는 방법을 참조하세요. 또한 Azure Managed Redis는 관리 ID를 사용하여 인증을 지원합니다.

시나리오 정보

이 예제에서 가상의 회사인 Fabrikam, Inc.는 드론 항공기를 관리합니다. 기업들이 서비스에 등록하며, 사용자는 배달할 상품을 드론이 픽업하도록 요청할 수 있습니다. 고객이 픽업을 예약할 때 백 엔드 시스템은 드론을 할당하고 예상 배달 시간을 사용자에게 알깁니다. 고객은 드론의 위치를 추적하고 배달이 진행되는 동안 지속적으로 업데이트된 예상 도착 시간을 볼 수 있습니다.

권장 사항

대부분의 시나리오에 다음 권장 사항을 적용할 수 있습니다. 특정 요구 사항이 이를 적용하지 않을 것을 요구하지 않는다면 이러한 권장 사항을 따르십시오.

애플리케이션 라우팅 추가 기능을 사용하여 관리되는 NGINX 수신

API 게이트웨이 라우팅은 일반적인 마이크로 서비스 디자인 패턴입니다. API 게이트웨이는 클라이언트에서 마이크로 서비스로 요청을 라우팅하는 역방향 프록시로 작동합니다. Kubernetes 수신 리소스 및 수신 컨트롤러 는 다음 작업을 수행하여 대부분의 API 게이트웨이 기능을 처리합니다.

• 클라이언트에 단일 엔드포인트를 제공하고 서비스에서 클라이언트를 분리하는 데 도움이 되도록 올바른 백 엔드 서비스로 클라이언트 요청을 라우팅

• 클라이언트와 백 엔드 간의 잡담을 줄이기 위해 여러 요청을 단일 요청으로 집계

• 백 엔드 서비스에서 SSL(Secure Sockets Layer) 종료, 인증, IP 주소 제한 및 클라이언트 속도 제한 또는 제한과 같은 기능 오프로드

수신 컨트롤러는 AKS 클러스터로의 트래픽 수집을 간소화하고, 안전성과 성능을 향상시키고, 리소스를 절약합니다. 이 아키텍처는 수신 제어 를 위해 애플리케이션 라우팅 추가 기능과 함께 관리되는 NGINX 수신 을 사용합니다.

내부(프라이빗) IP 주소 및 내부 부하 분산 장치와 함께 수신 컨트롤러를 사용하고 마이크로 서비스의 호스트 이름 확인을 위해 Azure 프라이빗 DNS 영역에 통합하는 것이 좋습니다. 수신 컨트롤러의 개인 IP 주소 또는 호스트 이름을 Application Gateway의 백 엔드 풀 주소로 구성합니다. Application Gateway는 공용 엔드포인트에서 트래픽을 수신하고 WAF 검사를 수행하며 트래픽을 수신 개인 IP 주소로 라우팅합니다.

트래픽이 엔드투엔드 암호화되도록 사용자 지정 도메인 이름 및 SSL 인증서 를 사용하여 수신 컨트롤러를 구성합니다. Application Gateway는 HTTPS 수신기에서 트래픽을 수신합니다. WAF 검사 후 Application Gateway는 트래픽을 수신 컨트롤러의 HTTPS 엔드포인트로 라우팅합니다. AKS 클러스터 내에서 마이크로 서비스 간 통신을 보호하는 사용자 지정 도메인 이름 및 SSL 인증서를 사용하도록 모든 마이크로 서비스를 구성합니다.

다중 테넌트 워크로드 또는 개발 및 테스트 환경을 지원하는 단일 클러스터에는 더 많은 수신 컨트롤러가 필요할 수 있습니다. 애플리케이션 라우팅 추가 기능은 동일한 AKS 클러스터 내의 여러 수신 컨트롤러 및 주석을 사용하여 수신 리소스를 구성하는 등 고급 구성 및 사용자 지정을 지원합니다.

네트워킹 및 네트워크 정책

Cilium에서 제공하는 Azure CNI를 사용합니다. eBPF 데이터 평면은 적절한 라우팅 성능을 가지며 모든 크기 클러스터를 지원합니다. Cilium은 기본적으로 Kubernetes NetworkPolicy를 적용하고 풍부한 트래픽을 관찰할 수 있습니다. 자세한 내용은 AKS에서 Cilium으로 구동되는 Azure CNI 구성을 참조하세요.

특정 IP 주소 관리 요구 사항을 위해 Cilium에서 제공하는 Azure CNI는 가상 네트워크 라우팅 및 오버레이 Pod IP 모델을 모두 지원합니다. 자세한 내용은 Cilium에서 제공하는 Azure CNI를 참조하세요.

제로 트러스트 네트워크 정책

네트워크 정책은 AKS Pod가 서로 및 다른 네트워크 엔드포인트와 통신하는 방법을 지정합니다. 기본적으로 모든 수신 및 송신 트래픽은 Pod를 오가는 것이 허용됩니다. 마이크로 서비스가 서로 및 다른 엔드포인트와 통신하는 방식을 디자인할 때 모든 서비스, 디바이스, 애플리케이션 또는 데이터 리포지토리에 액세스하려면 명시적 구성이 필요한 제로 트러스트 원칙을 따르는 것이 좋습니다. Kubernetes NetworkPolicy(고급 컨테이너 네트워킹 서비스/Cilium에서 구현)를 정의하고 적용하여 마이크로 서비스 간의 트래픽을 분할하고 송신을 허용된 FQDN으로만 제한합니다.

제로 트러스트 정책을 구현하는 한 가지 전략은 대상 네임스페이스 내의 모든 Pod에 대한 모든 수신 및 송신 트래픽을 거부하는 네트워크 정책을 만드는 것입니다. 다음 예제에서는 네임스페이스에 있는 모든 Pod에 적용되는 모든 정책을 거부 합니다 backend-dev .

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: deny-all
  namespace: backend-dev
spec:
  endpointSelector: {}  # Applies to all pods in the namespace
  ingress:
  - fromEntities: []
  egress:
  - toEntities: []

제한적인 정책이 적용된 후 마이크로 서비스의 각 Pod로 들어오고 나가는 트래픽을 허용하는 특정 네트워크 규칙을 정의하기 시작합니다. 다음 예제에서는 Cilium 네트워크 정책이 backend-dev 네임스페이스 내 app.kubernetes.io/component: backend와 일치하는 레이블이 있는 모든 Pod에 적용됩니다. 일치하는 레이블 app.kubernetes.io/part-of: dronedelivery이 있는 Pod에서 소스를 제공하지 않는 한 정책은 트래픽을 거부합니다.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: package-v010-dev-np-allow-ingress-traffic
  namespace: backend-dev
spec:
  endpointSelector:
    matchLabels:
      app.kubernetes.io/component: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app.kubernetes.io/part-of: dronedelivery
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP

Kubernetes 네트워크 정책 및 잠재적인 기본 정책의 더 많은 예제에 대한 자세한 내용은 Kubernetes 설명서의 네트워크 정책을 참조하세요. AKS의 네트워크 정책에 대한 모범 사례는 AKS에서 네트워크 정책 사용을 참조하세요.

Cilium에서 제공하는 Azure CNI를 사용하는 경우 Kubernetes NetworkPolicy는 Cilium에 의해 적용됩니다. 특수 요구 사항을 위해 Azure는 Azure 네트워크 정책 관리자 및 Calico를 비롯한 다른 네트워크 정책 엔진을 제공합니다. Cilium을 기본 네트워크 정책 엔진으로 사용하는 것이 좋습니다.

리소스 할당량

관리자는 리소스 할당량을 사용하여 개발 팀 또는 프로젝트에서 리소스를 예약하고 제한합니다. 네임스페이스에서 리소스 할당량을 설정하고 이를 사용하여 다음 리소스에 대한 제한을 설정할 수 있습니다.

• CPU(중앙 처리 장치), 메모리 및 GPU(그래픽 처리 장치)와 같은 컴퓨팅 리소스

• 특정 스토리지 클래스의 볼륨 수 또는 디스크 공간 양을 포함한 스토리지 리소스

• 개체 수, 예를 들어 만들 수 있는 최대 비밀, 서비스, 작업 등의 수

총 리소스 요청 또는 제한의 누적 합계가 할당된 할당량을 통과하면 더 이상 배포에 성공하지 않습니다.

리소스 할당량을 사용하면 네임스페이스에 할당되는 총 Pod 세트가 네임스페이스의 리소스 할당량을 초과할 수 없습니다. 프런트 엔드는 백 엔드 서비스에 모든 리소스를 사용할 수 없으며 백 엔드는 프런트 엔드 서비스에 모든 리소스를 사용할 수 없습니다.

리소스 할당량을 정의하는 경우 네임스페이스에 만들어진 모든 Pod는 해당 Pod 사양의 한도 또는 요청을 제공해야 합니다. 이러한 값이 제공되지 않으면 배포가 거부됩니다.

다음 예제에서는 리소스 할당량 요청 및 제한을 설정하는 Pod 사양을 보여 줍니다.

requests:
  cpu: 100m
  memory: 350Mi
limits:
  cpu: 200m
  memory: 500Mi

리소스 할당량에 대한 자세한 내용은 다음 문서를 참조하세요.

• 리소스 할당량 적용
• 리소스 할당량

자동 확장

Kubernetes는 배포에 할당된 Pod 수를 늘리거나 클러스터의 노드를 늘려 사용 가능한 총 컴퓨팅 리소스를 늘리도록 자동 크기 조정 을 지원합니다. 자동 크기 조정은 자체적으로 수정되는 자율 피드백 시스템입니다. Pod 및 노드의 크기를 수동으로 조정할 수 있지만 자동 크기 조정은 서비스가 높은 부하에서 리소스 제한에 도달할 가능성을 최소화합니다. 자동 크기 조정 전략은 Pod와 노드를 모두 고려해야 합니다.

클러스터 자동 크기 조정

클러스터 자동 크기 조정기(CA)는 노드 수를 조정합니다. 리소스 제약 조건으로 인해 Pod를 예약할 수 없는 경우 CA는 더 많은 노드를 프로비전합니다. AKS 클러스터 및 워크로드가 운영되도록 유지하기 위한 최소 노드 수와 트래픽이 많은 노드의 최대 수를 정의합니다. CA는 몇 초마다 보류 중인 Pod 또는 빈 노드를 확인하여 AKS 클러스터의 크기를 적절하게 조정합니다.

다음 예제에서는 클러스터의 Bicep 템플릿에서 CA 구성을 보여줍니다.

autoScalerProfile: {
  'scan-interval': '10s'
  'scale-down-delay-after-add': '10m'
  'scale-down-delay-after-delete': '20s'
  'scale-down-delay-after-failure': '3m'
  'scale-down-unneeded-time': '10m'
  'scale-down-unready-time': '20m'
  'scale-down-utilization-threshold': '0.5'
  'max-graceful-termination-sec': '600'
  'balance-similar-node-groups': 'false'
  expander: 'random'
  'skip-nodes-with-local-storage': 'true'
  'skip-nodes-with-system-pods': 'true'
  'max-empty-bulk-delete': '10'
  'max-total-unready-percentage': '45'
  'ok-total-unready-count': '3'
}

Bicep 템플릿의 다음 줄은 CA에 대한 최소 및 최대 노드 예제를 설정합니다.

minCount: 2
maxCount: 5

Horizontal Pod 자동 크기 조정

HPA(Horizontal Pod Autoscaler)는 관찰된 CPU, 메모리 또는 사용자 지정 메트릭에 따라 Pod 크기를 조정합니다. 수평 Pod 크기 조정을 구성하려면 Kubernetes 배포 Pod 사양에서 대상 메트릭과 최소 및 최대 복제본 수를 지정합니다. 부하를 테스트하여 이러한 숫자를 확인합니다.

CA와 HPA는 함께 작동하므로 AKS 클러스터에서 두 자동 크기 조정기 옵션을 모두 사용하도록 설정합니다. HPA는 애플리케이션의 크기를 조정하고 CA는 인프라의 크기를 조정합니다.

다음 예제에서는 HPA에 대한 리소스 메트릭을 설정합니다.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: delivery-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: delivery
  minReplicas: 2
  maxReplicas: 5
  metrics:
  - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

HPA는 실제로 소비된 리소스나 실행 중인 파드에서 수집된 다른 메트릭을 살펴봅니다. CA는 아직 예약되지 않은 Pod에 대한 노드를 프로비전합니다. 결과적으로 CA는 Pod 사양에 지정된 대로 요청된 리소스를 확인합니다. 부하 테스트를 사용하여 이러한 값을 미세 조정합니다.

자세한 내용은 AKS의 애플리케이션에 대한 크기 조정 옵션을 참조하세요.

Vertical Pod 자동 크기 조정

VPA(Vertical Pod Autoscaler)는 워크로드의 사용 패턴과 일치하도록 Pod에 대한 CPU 및 메모리 요청을 자동으로 조정합니다. 구성되면 VPA는 과거 사용량에 따라 각 워크로드에 대한 컨테이너에 대한 리소스 요청 및 제한을 자동으로 설정합니다. VPA를 사용하면 다른 Pod에 CPU 및 메모리를 사용할 수 있으며 AKS 클러스터를 효과적으로 활용할 수 있습니다.

이 아키텍처에서 VPA는 과거 사용량에 따라 마이크로 서비스에 대한 CPU 및 메모리 요청 및 제한을 증가합니다. 예를 들어 워크플로 마이크로 서비스가 다른 마이크로 서비스에 비해 더 많은 CPU를 사용하는 경우 VPA는 이 사용량을 모니터링하고 워크플로 마이크로 서비스에 대한 CPU 제한을 늘릴 수 있습니다.

Kubernetes 이벤트 기반 자동 크기 조정

Kubernetes Event-Driven 자동 크기 조정(KEDA) 추가 기능을 사용하면 이벤트 기반 자동 크기 조정을 통해 지속 가능하고 비용 효율적인 방식으로 수요를 충족하도록 마이크로 서비스의 크기를 조정할 수 있습니다. 예를 들어 KEDA는 Service Bus 큐의 메시지 수가 특정 임계값을 초과할 때 마이크로 서비스를 확장할 수 있습니다.

Fabrikam 드론 배달 시나리오에서 KEDA는 Service Bus 큐 깊이 및 수집 마이크로 서비스 출력에 따라 워크플로 마이크로 서비스를 확장합니다. Azure 서비스에 대한 KEDA 스칼라 목록은 AKS의 KEDA와 통합을 참조하세요.

상태 프로브

Kubernetes는 서비스의 레이블 선택기와 일치하는 Pod에 트래픽 부하를 분산합니다. 정상적으로 시작되고 상태가 좋은 포드만 트래픽을 받습니다. 컨테이너가 충돌하면 Kubernetes는 해당 Pod를 제거하고 대체 Pod를 예약합니다. Kubernetes는 Pod가 노출할 수 있는 세 가지 유형의 상태 프로브를 정의합니다.

• 준비 프로브는 Pod가 요청을 수락할 준비가 되었는지 여부를 Kubernetes에 알려줍니다.

• 활동성 프로브는 Pod를 제거하고 새 인스턴스를 시작해야 하는지 여부를 Kubernetes에 알려줍니다.

• 시작 프로브는 Pod가 시작되었는지 여부를 Kubernetes에 알려줍니다.

활동성 프로브는 여전히 실행 중이지만 비정상 상태이므로 재활용해야 하는 Pod를 처리합니다. 예를 들어 HTTP 요청을 제공하는 컨테이너가 중단되는 경우 컨테이너는 충돌하지 않지만 요청 제공을 중지합니다. HTTP 활동성 프로브는 응답을 중지하여 Kubernetes가 Pod를 다시 시작하도록 경고합니다.

경우에 따라 Pod가 성공적으로 시작되더라도, 트래픽을 수신할 준비가 되어 있지 않을 수 있습니다. 예를 들어 컨테이너에서 실행되는 애플리케이션이 초기화 작업을 수행할 수 있습니다. 준비 상태 프로브는 Pod가 트래픽을 받을 준비가 되었는지 여부를 나타냅니다.

마이크로 서비스는 성능 프로브를 용이하게 하는 엔드포인트를 코드에 노출해야 하며, 지연 및 시간 제한은 수행되는 검사에 맞게 조정됩니다. HPA 수식은 Pod의 준비 단계에 의존하므로 상태 프로브가 존재하고 정확한 것이 중요합니다.

모니터링

모니터링은 이상을 감지하고, 문제를 진단하고, 서비스 종속성을 이해하기 위해 마이크로 서비스 아키텍처에서 필수적입니다. Azure Monitor의 일부인 Application Insights는 .NET, Node.js, Java 및 기타 여러 언어로 작성된 애플리케이션에 대한 APM(애플리케이션 성능 모니터링)을 제공합니다. Azure는 엔드 투 엔드 가시성을 위한 몇 가지 통합 기능을 제공합니다.

• Prometheus용 Azure Monitor 관리형 서비스는 인프라 및 워크로드 메트릭에 대한 경고를 수집하고 경고합니다.

• Container Insights의 라이브 데이터 기능은 AKS 클러스터, 노드 및 컨테이너에서 상태 및 리소스 사용을 모니터링합니다.

• Azure Managed Grafana 는 클러스터 및 마이크로 서비스에 대한 메트릭 및 대시보드를 시각화합니다.

고급 컨테이너 네트워킹 서비스 관찰성은 AKS 클러스터의 네트워크 동작에 대한 심층적인 eBPF 기반 가시성을 제공하여 이러한 도구를 보완합니다. DNS 대기 시간, Pod 간 및 서비스 간 흐름, 네트워크 정책 차단, HTTP 상태 코드 및 응답 시간을 포함한 7계층 프로토콜 메트릭을 캡처합니다. 이 원격 분석은 메트릭용 Prometheus용 Azure Monitor 관리 서비스 및 대시보드용 Azure Managed Grafana와 통합됩니다. Cilium eBPF 데이터 평면은 흐름 수준의 가시성 및 문제 해결을 제공합니다. 고급 컨테이너 네트워킹 서비스 및 Azure Monitor와 결합하면 이 기능은 엔드 투 엔드 네트워크 관찰 가능성을 제공합니다. 이러한 통합을 통해 기존 APM에서 놓칠 수 있는 네트워크 병목 상태, 정책 구성 오류 및 통신 문제를 검색할 수 있습니다.

고려 사항

이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일련의 기본 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Well-Architected Framework를 참조하세요.

보안

보안은 의도적인 공격 및 중요한 데이터 및 시스템의 오용에 대한 보증을 제공합니다. 자세한 내용은 보안대한 디자인 검토 검사 목록을 참조하세요.

보안을 계획할 때 다음 사항을 고려합니다.

• AKS 클러스터에서 배포 보호 장치를 사용합니다. 배포 세이프가드는 Azure Policy 제어를 통해 AKS 클러스터에 Kubernetes 모범 사례를 적용합니다.

• 마이크로 서비스 빌드 및 배포 파이프라인에 보안 검사를 통합합니다. Microsoft Defender for Cloud DevOps 보안을 사용하여 DevOps 환경을 관리합니다. 빌드 및 배포 프로세스의 일부로 마이크로 서비스 코드 취약성을 식별하고 해결할 수 있도록 CI/CD(지속적인 통합 및 지속적인 배포) 파이프라인의 일부로 에이전트 없는 코드 검색 을 사용하고 정적 코드 분석 도구를 실행합니다.

• AKS Pod는 Microsoft Entra ID에 저장된 워크로드 ID 를 사용하여 자체 인증합니다. 클라이언트 암호가 필요하지 않으므로 워크로드 ID를 사용해야 합니다.

• 관리 ID를 사용하는 경우 애플리케이션은 실행 시 Azure Resource Manager OAuth 2.0 토큰을 신속하게 가져올 수 있습니다. 암호 또는 연결 문자열이 필요하지 않습니다. AKS에서는 워크로드 ID를 사용하여 개별 Pod에 ID를 할당할 수 있습니다.

• 최소 권한의 Azure RBAC 할당을 용이하게 하려면 마이크로 서비스 애플리케이션의 각 서비스에 고유한 워크로드 ID를 할당해야 합니다. ID가 필요한 서비스에만 ID를 할당합니다.

• 애플리케이션 구성 요소에 Kubernetes API 액세스가 필요한 경우 적절하게 범위가 지정된 API 액세스가 있는 서비스 계정을 사용하도록 애플리케이션 Pod가 구성되어 있는지 확인합니다. 자세한 내용은 Kubernetes 서비스 계정 관리를 참조하세요.

• 모든 Azure 서비스가 데이터 평면 인증을 위해 Microsoft Entra ID를 지원하는 것은 아닙니다. 이러한 서비스, 비 Microsoft 서비스 또는 API 키에 대한 자격 증명 또는 애플리케이션 비밀을 저장하려면 Key Vault를 사용합니다. 중앙 집중식 관리, 액세스 제어, 미사용 암호화 및 모든 키 및 비밀에 대한 감사를 제공합니다.

• AKS에서는 Key Vault에서 하나 이상의 비밀을 볼륨으로 탑재할 수 있습니다. 그러면 Pod가 정규 볼륨처럼 Key Vault 비밀을 읽을 수 있습니다. 자세한 내용은 AKS 클러스터에서 비밀 저장소 CSI 드라이버에 대한 Key Vault 공급자 사용을 참조하세요. 각 마이크로 서비스에 대해 별도의 키 자격 증명 모음을 유지하는 것이 좋습니다.

고급 컨테이너 네트워킹 서비스는 AKS 클러스터에 대한 클러스터 내 네트워크 세분화 및 제로 트러스트 컨트롤을 제공합니다. Cilium에서 제공하는 Azure CNI에서 Cilium 네트워크 정책을 사용하여 클러스터 내에서 계층 3 및 계층 4 분할을 구현합니다. 고급 컨테이너 네트워킹 서비스 보안은 고급 기능을 추가하여 이 기반을 확장합니다.

• 승인된 도메인으로 아웃바운드 트래픽을 제한하기 위해 FQDN 기반 출구 필터링을 사용합니다.

• 애플리케이션 수준 통신의 유효성을 검사하고 제어하기 위한 HTTP 및 gRPC(원격 프로시저 호출)와 같은 프로토콜에 대한 수준 7 인식 정책입니다.

• Pod 간 트래픽을 암호화하고 전송 중인 민감한 데이터를 보호하기 위한 WireGuard 암호화입니다.

  이러한 기능은 NSG(네트워크 보안 그룹) 및 Azure Firewall과 같은 경계 방어와 함께 작동하여 클러스터 내에서 트래픽 제어를 적용하는 계층화된 보안 접근 방식을 제공합니다.

• 마이크로 서비스가 클러스터 외부의 외부 URL과 같은 리소스와 통신해야 하는 경우 Azure Firewall을 통해 액세스를 제어합니다. 마이크로 서비스가 아웃바운드 호출을 수행할 필요가 없는 경우 네트워크 격리 클러스터를 사용합니다.

• Microsoft Defender for Containers를 사용하여 보안 상태 관리, 마이크로 서비스에 대한 취약성 평가, 런타임 위협 방지 및 기타 보안 기능을 제공할 수 있습니다.

네트워킹 데이터 평면 및 정책 엔진

AKS의 Cilium은 현재 Linux 노드에 대해 지원되며 데이터 평면에서 NetworkPolicy를 적용합니다. 노드 IP 주소 및 Pod IP 주소 사용 및 호스트 네트워크 Pod가 호스트 ID를 사용하는 것과 같은 ipBlock 정책 주의 사항에 유의하세요. Pod 수준 정책은 적용되지 않습니다. AKS 및 Cilium 버전을 지원되는 버전 매트릭스에 맞춥니다. 자세한 내용은 Cilium 제한으로 구동되는 Azure CNI를 참조하세요.

비용 최적화

비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 개선하는 방법에 중점을 둡니다. 자세한 내용은 비용 최적화대한 디자인 검토 검사 목록을 참조하세요.

• Well-Architected Framework의 비용 최적화 섹션에서는 비용 고려 사항을 설명합니다.

• Azure 가격 계산기를 사용하여 특정 시나리오에 대한 비용을 예측합니다.

• 무료 계층에서 AKS는 Kubernetes 클러스터의 배포, 관리 및 운영과 관련된 비용이 없습니다. 클러스터에서 사용하는 VM 인스턴스, 스토리지 및 네트워킹 리소스에 대해서만 비용을 지불합니다. 클러스터 자동 크기 조정 기능은 비어 있거나 사용되지 않는 노드를 제거하여 클러스터 비용을 크게 줄일 수 있습니다.

• 개발 워크로드에 AKS의 무료 계층을 사용하고 프로덕션 워크로드에 표준 및 프리미엄 계층을 사용하는 것이 좋습니다.

• Kubernetes별 구성에 따른 세분화된 클러스터 인프라 비용 할당을 위해 AKS 비용 분석을 활성화하는 것을 고려하세요.

운영 우수성

운영 우수성은 애플리케이션을 배포하고 프로덕션 환경에서 계속 실행하는 운영 프로세스를 다룹니다. 자세한 내용은 운영 우수성대한 디자인 검토 검사 목록을 참조하세요.

관리 효율성을 계획할 때 다음 사항을 고려합니다.

• GitHub Actions 워크플로와 같은 자동화된 배포 파이프라인을 통해 AKS 클러스터 인프라를 관리합니다.

• 워크플로 파일은 워크로드가 아닌 인프라만 기존 가상 네트워크 및 Microsoft Entra 구성에 배포합니다. 인프라와 워크로드를 별도로 배포하면 고유한 수명 주기 및 운영 문제를 해결할 수 있습니다.

• 지역 오류가 있는 경우 워크플로를 다른 지역에 배포하는 메커니즘으로 간주합니다. 매개 변수 및 입력 변경 내용을 사용하여 새 지역에 새 클러스터를 배포할 수 있도록 파이프라인을 빌드합니다.

성능 효율성

성능 효율성은 사용자 요구를 효율적으로 충족하기 위해 워크로드의 크기를 조정하는 기능을 의미합니다. 자세한 내용은 성능 효율성대한 디자인 검토 검사 목록을 참조하세요.

확장성을 계획할 때 다음 사항을 고려합니다.

• 복제본 수의 자동 크기 조정 및 명령적 관리 또는 선언적 관리를 결합하지 않습니다. 사용자와 자동 크기 조정기 모두 복제본 수를 변경하려고 하면 예기치 않은 동작이 발생할 수 있습니다. HPA를 사용하도록 설정하면 복제본 수를 배포하려는 최소 수로 줄입니다.

• Pod 자동 크기 조정의 부작용은 애플리케이션이 스케일 인되거나 스케일 아웃될 때 Pod가 자주 생성되거나 제거될 수 있다는 것입니다. 이러한 효과를 완화하려면 다음 작업을 수행합니다.

  • 새 Pod가 트래픽을 허용할 준비가 완료되면 준비 상태 프로브를 사용하여 Kubernetes에 그 사실을 알립니다.

  • Pod 중단 예산을 사용하여 서비스에서 한 번에 제거할 수 있는 Pod 수를 제한합니다.

• 마이크로 서비스에서 많은 수의 아웃바운드 흐름이 있는 경우 NAT(네트워크 주소 변환) 게이트웨이 를 사용하여 SNAT(원본 네트워크 주소 변환) 포트 고갈을 방지하는 것이 좋습니다.

• 다중 테넌트 또는 기타 고급 워크로드에는 더 작은 서브넷을 요구하는 노드 풀 격리 요구 사항이 있을 수 있습니다. 자세한 내용은 고유한 서브넷이 있는 노드 풀 추가를 참조하세요. 조직마다 허브 스포크 구현에 대한 서로 다른 표준을 가지고 있습니다. 따라서 조직의 지침을 따라야 합니다.

• 오버레이 네트워킹과 함께 Azure CNI를 사용하여 네트워크 주소 공간을 절약하는 것이 좋습니다.

다음 단계

• AKS 소개
• Virtual Network란?
• Private Link란?
• Application Gateway란?
• Azure Bastion 정보
• Key Vault 소개
• Container Registry 소개
• Azure Monitor 개요
• 고급 컨테이너 네트워킹 서비스

관련 리소스

• AKS 클러스터를 위한 기본 아키텍처
• Kubernetes를 사용하여 Azure에서 마이크로 서비스 디자인, 빌드 및 운영
• AKS의 마이크로서비스 아키텍처
• Kubernetes에서 마이크로서비스를 위한 CI/CD 파이프라인 빌드하기