이 참조 아키텍처는 Azure Kubernetes Services에서 마이크로 서비스를 실행할 때 고려해야 할 몇 가지 구성을 자세히 설명합니다. 다룰 주제에는 네트워크 정책 구성, Pod 자동 크기 조정 및 마이크로 서비스 기반 애플리케이션에서의 분산 추적이 포함됩니다.
이 아키텍처는 AKS(Azure Kubernetes Service) 인프라에 대한 Microsoft의 권장 시작점인 AKS 기준 아키텍처를 기반으로 합니다. AKS 기준선에는 Microsoft Entra 워크로드 ID, 수신 및 송신 제한, 리소스 제한 및 기타 보안 AKS 인프라 구성과 같은 인프라 기능이 자세히 설명되어 있습니다. 이러한 인프라의 세부 정보는 이 문서에서 다루지 않습니다. 마이크로 서비스 콘텐츠를 계속 진행하기 전에 AKS 기준에 익숙해지는 것이 좋습니다.
이 아키텍처의 참조 구현은 GitHub에서 사용할 수 있습니다.
아키텍처
이 아키텍처의 Visio 파일을 다운로드합니다.
AKS에서 보다 기본적인 마이크로 서비스 예제로 시작하려면 AKS의 마이크로 서비스 아키텍처를 참조하세요.
워크플로
이 요청 흐름은 게시자-구독자, 경쟁 소비자 및 게이트웨이 라우팅 클라우드 디자인 패턴을 구현합니다. 메시징 흐름은 다음과 같이 진행됩니다.
드론 픽업을 예약하기 위해 HTTPS 요청이 제출됩니다. 요청은 Azure Application Gateway를 통해 AKS에서 클러스터 내 마이크로 서비스로 실행되는 수집 웹 애플리케이션으로 전달됩니다.
수집 웹 애플리케이션은 메시지를 생성하여 Service Bus 메시지 큐로 보냅니다.
백 엔드 시스템이 드론을 할당하고 사용자에게 알립니다. 워크플로는 다음을 수행합니다.
- Service Bus 메시지 큐의 메시지 정보를 사용합니다.
- 배달 마이크로 서비스에 HTTPS 요청을 전송하면 배달 마이크로 서비스에서 데이터를 Azure Cache for Redis 외부 데이터 스토리지로 전달합니다.
- 드론 스케줄러 마이크로 서비스에 HTTPS 요청을 보냅니다.
- 패키지 마이크로 서비스에 HTTPS 요청을 전송하면 패키지 마이크로 서비스에서 데이터를 MongoDB 외부 데이터 스토리지로 전달합니다.
HTTPS GET 요청이 배달 상태를 반환하는 데 사용됩니다. 이 요청은 Application Gateway를 통해 배달 마이크로 서비스로 전달됩니다.
배달 마이크로 서비스가 Azure Cache for Redis에서 데이터를 읽습니다.
구성 요소
이 아키텍처에서는 다음 Azure 구성 요소를 사용합니다.
Azure Kubernetes Service는 관리되는 Kubernetes 클러스터를 제공하는 Azure 제품입니다. AKS를 사용하는 경우 Kubernetes API 서버는 Azure에서 관리됩니다. Kubernetes 노드 또는 노드 풀은 클러스터 운영자가 액세스하고 관리할 수 있습니다.
이 아키텍처에 사용되는 AKS 인프라 기능은 다음과 같습니다.
- 시스템 및 사용자 노드 풀 분리
- RBAC(역할 기반 액세스 제어)에 대한 AKS 관리 Microsoft Entra ID
- Microsoft Entra 워크로드 ID
- AKS용 Azure Policy 추가 기능
- Azure CNI(Container Networking Interface)
- Azure Monitor 컨테이너 인사이트
Azure 가상 네트워크는 VM(가상 머신) 및 애플리케이션을 실행하기 위한 격리되고 매우 안전한 환경입니다. 이 참조 아키텍처는 피어링된 허브 스포크 가상 네트워크 토폴로지를 사용합니다. 허브 가상 네트워크에는 Azure 방화벽 및 Azure Bastion 서브넷이 있습니다. 스포크 가상 네트워크에는 AKS 시스템 및 사용자 노드 풀 서브넷과 Azure Application Gateway 서브넷이 있습니다.
Azure Private Link는 AKS 시스템 및 사용자 노드 풀 서브넷 내의 프라이빗 엔드포인트에서 Azure Container Registry와 Key Vault에 액세스할 수 있도록 특정 개인 IP 주소를 할당합니다.
Azure Application Gateway는 WAF(웹 애플리케이션 방화벽)를 사용하며, AKS 클러스터에 HTTP(S) 경로를 노출하고 웹 애플리케이션에 웹 트래픽 부하를 분산합니다. 이 아키텍처는 Azure AGIC(Azure Application Gateway 수신 컨트롤러)를 Kubernetes 수신 컨트롤러로 사용합니다.
Azure Bastion은 공용 IP 주소를 통해 VM을 노출할 필요 없이 SSL(보안 소켓 레이어)을 사용하여 가상 네트워크의 VM에 대한 안전한 RDP(원격 데스크톱 프로토콜) 및 SSH(보안 셸) 액세스를 제공합니다.
Azure Firewall은 모든 Azure Virtual Network 리소스를 보호하는 네트워크 보안 서비스입니다. 방화벽은 승인된 서비스 및 FQDN(정규화된 도메인 이름)만 송신 트래픽으로 허용합니다.
외부 스토리지 및 기타 구성 요소:
Azure Key Vault는 AKS 서비스를 위한 보안 키를 저장하고 관리합니다.
Azure Container Registry는 AKS 클러스터에서 실행할 수 있는 프라이빗 컨테이너 이미지를 저장합니다. AKS는 Microsoft Entra 관리 ID를 사용하여 Container Registry로 인증합니다. 또한 Docker Hub와 같은 다른 컨테이너 레지스트리도 사용할 수 있습니다.
Azure Cosmos DB는 오픈 소스 Azure Cosmos DB for MongoDB를 사용하여 데이터를 저장합니다. 마이크로 서비스는 일반적으로 상태 비저장으로, 외부 데이터 저장소에 상태를 씁니다. Azure Cosmos DB는 MongoDB 및 Cassandra용 오픈 소스 API를 사용하는 NoSQL 데이터베이스입니다.
Azure Service Bus는 안정적인 클라우드 MaaS(Messaging as a Service) 및 간단한 하이브리드 통합을 제공합니다. Service Bus는 마이크로 서비스 애플리케이션과 공통적인 비동기 메시징 패턴을 지원합니다.
Azure Cache for Redis는 애플리케이션 아키텍처에 캐싱 레이어를 추가하여 많은 트래픽 부하에서 속도와 성능을 향상시킵니다.
Azure Monitor는 애플리케이션 원격 분석 및 Azure 플랫폼과 서비스 메트릭을 포함한 메트릭과 로그를 수집하고 저장합니다. 이 데이터를 사용하여 애플리케이션을 모니터링하고, 경고 및 대시보드를 설정하고, 실패의 근본 원인 분석을 수행할 수 있습니다.
기타 OSS(운영 지원 시스템) 구성 요소:
Helm은 Kubernetes용 패키지 관리자로, Kubernetes 개체를 게시, 배포, 버전 관리 및 업데이트 가능한 단일 단위로 번들링합니다.
Azure Key Vault Secret Store CSI 공급자는 Azure Key Vault에 저장된 비밀을 가져와서 Secret Store CSI 드라이버 인터페이스를 사용하여 Kubernetes Pod에 탑재합니다.
Flux는 GitOps 도구 키트로 구동되며 Kubernetes에 대한 개방적이고 확장 가능한 지속적인 업데이트 솔루션입니다.
시나리오 정보
이전 다이어그램에 표시된 Fabrikam 드론 배달 앱 예제는 이 문서에서 설명하는 아키텍처 구성 요소 및 사례를 구현합니다. 이 예제에서 가상의 회사인 Fabrikam, Inc.는 드론 항공기를 관리합니다. 기업들이 서비스에 등록하며, 사용자는 배달할 상품을 드론이 픽업하도록 요청할 수 있습니다. 사용자가 픽업을 예약하면 백 엔드 시스템이 드론을 할당하고 사용자에게 예상 배달 시간을 알립니다. 배달이 진행되는 동안 지속적으로 업데이트되는 ETA를 통해 고객은 드론의 위치를 추적할 수 있습니다.
잠재적인 사용 사례
이 솔루션은 항공기, 항공 우주 및 항공 산업에 적합합니다.
권장 사항
고급 AKS 마이크로 서비스 아키텍처를 배포할 때 이러한 권장 사항을 구현합니다.
AGIC(Application Gateway 수신 컨트롤러)
API 게이트웨이 라우팅은 일반적인 마이크로 서비스 디자인 패턴입니다. API 게이트웨이는 클라이언트에서 마이크로 서비스로 요청을 라우팅하는 역방향 프록시 역할을 합니다. Kubernetes 수신 리소스 및 수신 컨트롤러는 다음을 통해 대부분의 API 게이트웨이 기능을 처리합니다.
클라이언트 요청을 올바른 백 엔드 서비스로 라우팅하여 클라이언트에 대한 단일 엔드포인트를 제공하고 클라이언트를 서비스에서 분리하는 데 도움을 줍니다.
- 여러 요청을 단일 요청으로 집계하여 클라이언트와 백 엔드 사이의 대화량을 줄입니다.
- SSL 종료, 인증, IP 제한 및 백 엔드 서비스에서 클라이언트 속도 제한 또는 대역폭 제한과 같은 기능을 오프로드합니다.
AKS 클러스터의 상태는 Application Gateway 특정 구성으로 변환되고 Azure Resource Manager를 통해 적용됩니다.
외부 수신 컨트롤러는 AKS 클러스터로의 트래픽 수집을 간소화하고, 안전성과 성능을 향상시키고, 리소스를 저장합니다. 이 아키텍처는 수신 제어에 Azure AGIC(Azure Application Gateway 수신 컨트롤러)를 사용합니다. Application Gateway를 사용하여 모든 트래픽을 처리하면 추가 부하 분산 장치가 필요하지 않습니다. Pod는 Application Gateway에 직접 연결되므로 필요한 홉 수가 감소하여 성능이 향상됩니다.
Application Gateway에는 원치 않는 양의 컴퓨팅 리소스를 사용하는 경우 스케일 아웃해야 하는 클러스터 내 수신 컨트롤러와 달리 기본 제공되는 자동 크기 조정 기능이 있습니다. Application Gateway는 계층 7 라우팅 및 SSL 종료를 수행할 수 있으며 기본 제공 WAF(웹 애플리케이션 방화벽)와 통합된 TLS(엔드투엔드 전송 계층 보안)가 있습니다.
AGIC 수신 옵션의 경우 AKS 가상 네트워크의 서브넷에 Application Gateway가 배포되므로 AKS 클러스터를 구성할 때 CNI 네트워킹을 사용하도록 설정해야 합니다. 다중 테넌트 워크로드 또는 개발 및 테스트 환경을 지원하는 단일 클러스터에는 더 많은 수신 컨트롤러가 필요할 수 있습니다.
제로 트러스트 네트워크 정책
네트워크 정책은 AKS Pod가 서로 통신하고 다른 네트워크 엔드포인트와 통신할 수 있는 방법을 지정합니다. 기본적으로 모든 수신 및 송신 트래픽은 Pod를 오가는 것이 허용됩니다. 마이크로 서비스가 서로 통신하고 다른 엔드포인트와 통신하는 방법을 디자인할 때는 서비스, 디바이스, 애플리케이션 또는 데이터 리포지토리에 액세스하려면 명시적 구성이 필요한 제로 트러스트 원칙을 따르는 것이 좋습니다.
제로 트러스트 정책을 구현하는 한 가지 전략은 대상 네임스페이스 내의 모든 Pod에 대한 모든 수신 및 송신 트래픽을 거부하는 네트워크 정책을 만드는 것입니다. 다음 예제에서는 backend-dev 네임스페이스에 있는 모든 Pod에 적용되는 '모든 정책 거부'를 보여 줍니다.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: backend-dev
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
제한적인 정책이 적용되면 마이크로 서비스의 각 Pod로 들어오고 나가는 트래픽을 허용하는 특정 네트워크 규칙을 정의하기 시작합니다. 다음 예제에서 네트워크 정책은 일치하는 app.kubernetes.io/component: backend레이블이 있는 백 엔드-개발 네임스페이스의 모든 Pod에 적용됩니다. 일치하는 레이블 app.kubernetes.io/part-of: dronedelivery이 있는 Pod에서 소스를 제공하지 않는 한 정책은 트래픽을 거부합니다.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: package-v010-dev-np-allow-ingress-traffic
namespace: backend-dev
spec:
podSelector:
matchLabels:
app.kubernetes.io/component: backend
ingress:
- from:
- podSelector:
matchLabels:
app.kubernetes.io/part-of: dronedelivery
ports:
- port: 80
protocol: TCP
Kubernetes 네트워크 정책 및 잠재적인 기본 정책의 추가 예제에 대한 자세한 내용은 Kubernetes 설명서의 네트워크 정책을 참조하세요.
리소스 할당량
리소스 할당량은 관리자가 개발 팀 또는 프로젝트에서 리소스를 예약하고 제한할 수 있는 방법입니다. 네임스페이스에서 리소스 할당량을 설정하고 이를 사용하여 다음을 제한할 수 있습니다.
- CPU 및 메모리 또는 GPU와 같은 컴퓨팅 리소스.
- 지정된 스토리지 클래스에 대한 총 볼륨 수 또는 디스크 공간의 크기를 포함하는 스토리지 리소스.
- 개체 개수(예: 만들 수 있는 비밀, 서비스 또는 작업의 최대 개수).
리소스 요청 또는 한도의 누적 총계가 지정된 할당량을 초과하면 추가 배포가 수행되지 않습니다.
리소스 할당량을 사용하면 네임스페이스에 할당되는 총 Pod 세트가 네임스페이스의 리소스 할당량을 초과할 수 없습니다. 프런트 엔드가 리소스의 백 엔드 서비스를 고갈시킬 수 없으며 그 반대도 마찬가지입니다.
리소스 할당량을 정의하는 경우 네임스페이스에 만들어진 모든 Pod는 해당 Pod 사양의 한도 또는 요청을 제공해야 합니다. 이러한 값이 제공되지 않으면 배포가 거부됩니다.
다음 예제에서는 리소스 할당량 요청 및 제한을 설정하는 Pod 사양을 보여 줍니다.
requests:
cpu: 100m
memory: 350Mi
limits:
cpu: 200m
memory: 500Mi
리소스 할당량에 대한 자세한 내용은 다음을 참조하세요.
자동 확장
Kubernetes는 자동 크기 조정을 지원하여 배포에 할당되는 Pod 수를 늘리거나 클러스터의 노드를 늘려 사용 가능한 총 컴퓨팅 리소스를 늘릴 수 있습니다. 자동 크기 조정은 자체적으로 수정되는 자율 피드백 시스템입니다. Pod 및 노드의 크기를 사용자가 조정할 수 있지만 자동 크기 조정 기능을 사용하면 높은 부하에서 서비스의 리소스가 부족하게 될 가능성을 최소화합니다. 자동 크기 조정 전략은 Pod와 노드를 모두 고려해야 합니다.
클러스터 자동 크기 조정
CA(클러스터 자동 크기 조정기)는 노드 수를 자동으로 조정합니다. 리소스 제약으로 인해 Pod를 예약할 수 없는 경우 클러스터 자동 크기 조정기가 추가 노드를 프로비전합니다. AKS 클러스터 및 워크로드가 운영되도록 유지하기 위한 최소 노드 수와 트래픽이 많은 노드의 최대 수를 정의합니다. CA는 몇 초마다 보류 중인 Pod 또는 빈 노드를 확인하여 AKS 클러스터의 크기를 적절하게 조정합니다.
다음 예제에서는 ARM 템플릿의 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"
},
ARM 템플릿에서 다음 줄은 CA에 대한 최소 및 최대 노드 예를 설정합니다.
"minCount": 2,
"maxCount": 5,
Pod 자동 크기 조정
HPA(Horizontal Pod Autoscaler)는 관찰된 CPU, 메모리 또는 사용자 지정 메트릭에 따라 Pod의 크기를 조정합니다. 수평 Pod 크기 조정을 구성하려면 Kubernetes 배포 Pod 사양에서 대상 메트릭과 최소 및 최대 복제본 수를 지정합니다. 이들 숫자를 결정하려면 서비스의 부하를 테스트합니다.
CA와 HPA는 함께 잘 작동하므로 AKS 클러스터에서 두 자동 크기 조정기 옵션을 모두 사용하도록 설정합니다. HPA는 애플리케이션의 크기를 조정하고 CA는 인프라의 크기를 조정합니다.
다음 예제에서는 HPA에 대한 리소스 메트릭을 설정합니다.
apiVersion: autoscaling/v2beta2
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
targetAverageUtilization: 60
HPA는 사용된 실제 리소스 또는 실행 중인 Pod의 다른 메트릭을 확인하지만 CA는 아직 예약되지 않은 Pod의 노드를 프로비전합니다. 따라서 CA는 Pod 사양에 지정된 대로 요청된 리소스를 확인합니다. 이러한 값을 미세 조정하려면 부하 테스트를 사용합니다.
상태 프로브
Kubernetes는 서비스의 레이블 선택기와 일치하는 Pod에 트래픽 부하를 분산합니다. 성공적으로 시작되고 상태가 정상인 Pod만 트래픽을 수신합니다. 컨테이너가 충돌하면 Kubernetes는 해당 Pod를 제거하고 대체 Pod를 예약합니다.
Kubernetes에서 Pod는 다음 두 가지 유형의 상태 프로브를 노출할 수 있습니다.
- 활동성 프로브는 Pod가 성공적으로 시작되었고 정상 상태인지 여부를 Kubernetes에 알려줍니다.
- 준비 상태 프로브는 Pod가 요청을 수락할 준비가 되었는지 여부를 Kubernetes에 알려줍니다.
활동성 프로브는 여전히 실행 중이지만 비정상 상태이므로 재활용해야 하는 Pod를 처리합니다. 예를 들어 HTTP 요청을 제공하는 컨테이너가 중단되면 컨테이너는 충돌하지 않지만 요청 제공이 중지됩니다. HTTP 활동성 프로브는 응답을 중지하여 Kubernetes에 Pod를 다시 시작하도록 알릴 수 있습니다.
Pod가 성공적으로 시작되더라도 트래픽을 받을 준비가 완료되지 않은 경우가 가끔 있습니다. 예를 들어 컨테이너에서 실행되는 애플리케이션이 초기화 작업을 수행하는 중일 수 있습니다. 준비 상태 프로브는 Pod가 트래픽을 받을 준비가 되었는지 여부를 나타냅니다.
마이크로 서비스는 상태 프로브의 작업을 용이하게 하는 엔드포인트를 코드에 노출해야 하며, 지연 및 시간 제한은 수행하는 검사에 맞게 조정됩니다. HPA 수식 키는 Pod의 준비 단계에서 거의 단독으로 해제되므로 상태 프로브가 존재하고 정확해야 합니다.
모니터링
마이크로 서비스 애플리케이션에서 APM(애플리케이션 성능 관리) 모니터링은 변칙 검색, 문제 진단 및 서비스 간 종속성의 신속한 파악에 매우 중요합니다. Azure Monitor의 일부인 Application Insights는 .NET Core, Node.js, Java 및 기타 여러 애플리케이션 언어로 작성된 라이브 애플리케이션에 대한 APM 모니터링을 제공합니다.
Application Insights:
- 대기 시간 및 결과 코드를 포함하여 HTTP 요청을 기록합니다.
- 기본적으로 분산 추적을 사용하도록 설정합니다.
- 추적에 작업 ID를 포함하므로 특정 작업에 대한 모든 추적을 일치시킬 수 있습니다.
- 추적에 추가적인 컨텍스트 정보가 포함되는 경우가 많습니다.
Kubernetes 세계와 서비스 원격 분석을 컨텍스트화하려면 AKS와 Azure Monitor 원격 분석을 통합하여 컨트롤러, 노드 및 컨테이너뿐만 아니라 컨테이너 및 노드 로그에서도 메트릭을 수집합니다. .NET을 사용하는 경우 Application Insights for Kubernetes 라이브러리는 이미지, 컨테이너, 노드, Pod, 레이블 및 복제본 집합 정보를 사용하여 Application Insights 원격 분석을 보강합니다.
다음 다이어그램에서는 Application Insights가 AKS 마이크로 서비스 원격 분석 추적에 대해 생성하는 애플리케이션 종속성 맵의 예를 보여 줍니다.
Application Insights 통합을 위한 공용 언어 계측 옵션에 대한 자세한 내용은 Kubernetes에 대한 애플리케이션 모니터링을 참조하세요.
고려 사항
이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일단의 지침 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.
확장성
확장을 계획할 때는 다음 사항을 고려합니다.
복제본 수의 자동 크기 조정 및 명령적 관리 또는 선언적 관리를 결합하지 않습니다. 사용자와 자동 크기 조정기가 모두 복제본 수를 수정하려고 하면 예기치 않은 동작이 발생할 수 있습니다. HPA를 사용하도록 설정하면 복제본 수를 배포하려는 최소 수로 줄일 수 있습니다.
Pod 자동 크기 조정의 부작용으로 스케일 아웃 및 스케일 인 이벤트가 발생할 때 Pod가 좀 더 자주 생성 또는 제거될 수 있습니다. 이러한 효과를 완화하려면 다음을 수행합니다.
- 새 Pod가 트래픽을 허용할 준비가 완료되면 준비 상태 프로브를 사용하여 Kubernetes에 그 사실을 알립니다.
- Pod 중단 예산을 사용하여 서비스에서 한 번에 제거할 수 있는 Pod 수를 제한합니다.
클러스터를 만든 후에는 VM 크기를 변경할 수 없으므로 클러스터를 만들 때 에이전트 노드에 적절한 VM 크기를 선택하려면 초기 용량 계획을 세워야 합니다.
다중 테넌트 또는 기타 고급 워크로드에는 더 작은 서브넷을 요구하는 노드 풀 격리 요구 사항이 있을 수 있습니다. 고유한 서브넷을 사용하여 노드 풀을 만드는 방법에 대한 자세한 내용은 고유한 서브넷이 있는 노드 풀 추가를 참조하세요. 조직마다 허브 스포크 구현에 대한 서로 다른 표준을 가지고 있습니다. 따라서 조직의 지침을 따라야 합니다.
관리 효율
관리 효율을 계획할 때는 다음 사항을 고려합니다.
자동화된 배포 파이프라인을 통해 AKS 클러스터 인프라를 관리합니다. 이 아키텍처에 대한 참조 구현은 파이프라인을 빌드할 때 참조할 수 있는 GitHub Actions 워크플로를 제공합니다.
워크플로 파일은 워크로드가 아닌 인프라만 기존 가상 네트워크 및 Microsoft Entra 구성에 배포합니다. 인프라와 워크로드를 별도로 배포하면 고유한 수명 주기 및 운영 문제를 해결할 수 있습니다.
지역 오류가 있는 경우 워크플로를 다른 지역에 배포할 메커니즘으로 고려합니다. 매개 변수 및 입력 변경을 통해 새 지역에 새 클러스터를 배포할 수 있도록 파이프라인을 빌드합니다.
보안
우수한 보안은 중요한 데이터 및 시스템에 대한 고의적인 공격과 악용을 방어합니다. 자세한 내용은 보안 요소의 개요를 참조하세요.
보안을 계획할 때는 다음 사항을 고려합니다.
AKS Pod는 Microsoft Entra ID에 저장된 워크로드 ID를 사용하여 자체 인증합니다. 클라이언트 암호가 필요하지 않으므로 워크로드 ID를 사용하는 것이 좋습니다.
관리 ID를 사용하면 실행 프로세스에서 Azure Resource Manager OAuth 2.0 토큰을 빠르게 가져올 수 있으며 암호나 연결 문자열은 필요하지 않습니다. AKS에서는 Microsoft Entra 워크로드 ID 사용하여 개별 Pod에 ID를 할당할 수 있습니다.
최소 권한 RBAC 할당을 용이하게 하려면 마이크로 서비스 애플리케이션의 각 서비스에 고유한 워크로드 ID가 할당되어야 합니다. ID가 필요한 서비스에만 ID를 할당해야 합니다.
애플리케이션 구성 요소에 Kubernetes API 액세스가 필요한 경우 적절하게 범위가 지정된 API 액세스가 있는 서비스 계정을 사용하도록 애플리케이션 Pod가 구성되어 있는지 확인합니다. Kubernetes 서비스 계정 구성 및 관리에 대한 자세한 내용은 Kubernetes 서비스 계정 관리를 참조하세요.
모든 Azure 서비스가 Microsoft Entra ID를 사용하여 데이터 평면 인증을 지원하는 것은 아닙니다. 해당 서비스, 타사 서비스 또는 API 키에 대한 자격 증명 또는 애플리케이션 비밀을 저장하려면 Azure Key Vault를 사용합니다. Azure Key Vault는 모든 키와 비밀에 대한 중앙 집중식 관리, 액세스 제어, 휴지 상태의 암호화 및 감사를 제공합니다.
AKS에서는 Key Vault에서 하나 이상의 비밀을 볼륨으로 탑재할 수 있습니다. 그러면 Pod가 정규 볼륨처럼 Key Vault 비밀을 읽을 수 있습니다. 자세한 내용은 GitHub에서 secrets-store-csi-driver-provider-azure 프로젝트를 참조하세요.
비용 최적화
비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 방법을 찾는 것입니다. 자세한 내용은 비용 최적화 핵심 요소 개요를 참조하세요.
Microsoft Azure Well-Architected Framework의 비용 섹션에서 비용 관련 고려 사항을 설명합니다. Azure 가격 계산기를 사용하여 특정 시나리오에 대한 비용을 예측합니다.
AKS는 Kubernetes 클러스터의 배포, 관리 및 운영과 관련된 비용이 없습니다. VM 인스턴스, 스토리지 및 클러스터가 사용하는 네트워킹 리소스에 대해서만 지불하면 됩니다. 클러스터 자동 크기 조정 기능은 비어 있거나 사용되지 않는 노드를 제거하여 클러스터 비용을 크게 줄일 수 있습니다.
필요한 리소스의 비용을 예측하려면 Container Services 계산기를 참조하세요.
Kubernetes 특정 구문별로 세분화된 클러스터 인프라 비용 할당에 AKS 비용 분석을 사용하도록 설정하는 것이 좋습니다.
다음 단계
- Azure Kubernetes Service 소개
- Azure Virtual Network란?
- Azure Private Link란?
- Azure Application Gateway란?
- Azure Bastion 정보
- Azure Key Vault 정보
- Azure Container Registry 소개
- Azure Cosmos DB 시작
- Azure Monitor 개요