Azure Kubernetes Service의 마이크로 서비스 아키텍처

이 참조 아키텍처는 AKS(Azure Kubernetes Service)에 배포된 마이크로 서비스 애플리케이션을 보여 줍니다. 대부분의 배포에서 시작점으로 사용할 수 있는 기본 AKS 구성을 설명합니다. 이 문서에서는 Kubernetes에 대한 기본 지식을 다룹니다. 이 문서는 AKS에서 마이크로 서비스 아키텍처를 실행하기 위한 인프라 및 DevOps 고려 사항에 중점을 둡니다. 마이크로 서비스를 설계하는 방법에 대한 참고 자료는 Azure에서 마이크로 서비스 빌드를 참조하세요.

이 아키텍처의 참조 구현은 GitHub에서 사용할 수 있습니다.

아키텍처

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

AKS 기준 아키텍처를 기반으로 하는 고급 마이크로 서비스 예제를 보려면 고급 AKS(Azure Kubernetes Service) 마이크로 서비스 아키텍처를 참조하세요.

워크플로

이 아키텍처는 다음 구성 요소로 구성됩니다.

AKS(Azure Kubernetes Service). AKS는 Azure 클라우드에서 호스트되는 관리되는 Kubernetes 클러스터입니다. Azure가 Kubernetes API 서비스를 관리하므로 사용자는 에이전트 노드만 관리하면 됩니다.

가상 네트워크. 기본적으로 AKS는 에이전트 노드가 연결된 가상 네트워크를 만듭니다. 먼저 고급 시나리오에 대한 가상 네트워크를 만들어서 서브넷 구성 방법, 온-프레미스 연결, IP 주소 지정 등을 제어할 수 있습니다. 자세한 내용은 AKS(Azure Kubernetes Service)에서 고급 네트워킹 구성을 참조하세요.

수신. 수신 서버는 클러스터 내부의 서비스에 대한 HTTP(S) 경로를 공개합니다. 자세한 내용은 아래의 API 게이트웨이를 참조하세요.

Azure Load Balancer. AKS 클러스터를 만들면 클러스터는 부하 분산 장치를 사용할 준비가 됩니다. 그런 다음 NGINX 서비스가 배포되면 부하 분산 장치는 수신 컨트롤러를 향하게 될 새 공용 IP를 사용해 구성됩니다. 이러한 방식으로 부하 분산 장치는 인터넷 트래픽을 수신으로 라우팅합니다.

외부 데이터 저장소. 마이크로 서비스는 일반적으로 상태 비저장이며 Azure SQL Database 또는 Azure Cosmos DB 같은 외부 데이터 저장소에 상태를 씁니다.

Microsoft Entra ID. AKS는 Microsoft Entra ID를 사용하여 Azure 부하 분산 장치와 같은 다른 Azure 리소스를 만들고 관리합니다. 클라이언트 애플리케이션의 사용자 인증에도 Microsoft Entra ID를 사용하는 것이 좋습니다.

Azure Container Registry. Container Registry를 사용하여 클러스터에 배포되는 프라이빗 Docker 이미지를 저장합니다. AKS는 Microsoft Entra ID를 사용하여 Container Registry로 인증할 수 있습니다. AKS에는 Azure Container Registry가 필요하지 않습니다. Docker 허브 같은 다른 컨테이너 레지스트리를 사용할 수 있습니다. 컨테이너 레지스트리가 워크로드에 대한 SLA(서비스 수준 약정)와 일치하거나 초과하는지 확인하기만 하면 됩니다.

Azure Pipelines. Azure Pipelines는 Azure DevOps Services의 일부이며 자동화된 빌드, 테스트 및 배포를 실행합니다. Jenkins 같은 타사 CI/CD 솔루션도 사용할 수 있습니다.

Helm. Helm은 Kubernetes용 패키지 관리자로써 Kubernetes 개체를 게시, 배포, 버전 관리 및 업데이트 가능한 단일 단위로 번들링하고 일반화하는 방법을 제공합니다.

Azure Monitor Azure Monitor는 Azure 서비스에 대한 메트릭 및 로그, 애플리케이션 원격 분석, 플랫폼 메트릭을 수집하고 저장합니다. 이 데이터를 사용하여 애플리케이션을 모니터링하고, 경고 및 대시보드를 설정하며, 오류의 근본 원인 분석을 수행합니다. Azure Monitor는 AKS와 통합되어 컨트롤러, 노드, 컨테이너의 메트릭을 수집합니다.

고려 사항

디자인

AKS에서 실행되는 다른 워크로드에 적용되는 여러 권장 모범 사례가 있지만, 이 참조 아키텍처는 마이크로 서비스 아키텍처에 집중되어 있습니다.

마이크로 서비스

마이크로 서비스는 느슨하게 결합되며, 독립적으로 배포 가능한 코드 단위입니다. 마이크로 서비스는 일반적으로 잘 정의된 API를 통해 통신하며, 특정 형태의 서비스 검색을 통해 검색할 수 있습니다. Pod가 이동하는 경우에도 서비스에 항상 연결할 수 있어야 합니다. Kubernetes Service 개체는 Kubernetes에서 마이크로 서비스를 모델링하는 자연스러운 방법입니다.

API 게이트웨이

API 게이트웨이는 일반적인 마이크로 서비스 설계 패턴입니다. API 게이트웨이는 외부 클라이언트와 마이크로 서비스 사이에 위치합니다. 역방향 프록시로 작동하면서 클라이언트에서 마이크로 서비스로 요청을 라우팅합니다. 또한 인증, SSL 종료 및 속도 제한과 같은 다양한 교차 작업을 수행할 수도 있습니다. 자세한 내용은 다음을 참조하세요.

• 마이크로서비스의 API 게이트웨이 사용
• 게이트웨이 기술 선택

Kubernetes에서 API 게이트웨이의 기능은 주로 수신 컨트롤러에서 처리됩니다. 고려 사항은 수신 섹션에 설명되어 있습니다.

데이터 스토리지

마이크로 서비스 아키텍처에서는 서비스가 데이터 스토리지 솔루션을 공유하면 안 됩니다. 각 서비스는 자체 데이터 세트를 관리하여 서비스 사이에 숨겨진 종속성을 방지해야 합니다. 데이터 격리는 여러 서비스가 동일한 기본 데이터 스키마를 공유할 때 발생할 수 있는 서비스 간의 의도치 않은 결합을 방지하는 데 도움이 됩니다. 또한 서비스에서 자체 데이터 저장소를 관리하는 경우 특정 요구 사항에 적합한 데이터 저장소를 사용할 수 있습니다.

자세한 내용은 마이크로 서비스 설계: 데이터 고려 사항을 참조하세요.

로컬 클러스터 스토리지에 영구 데이터를 저장하지 마세요. 이렇게 하면 데이터가 노드에 연결됩니다. 그 대신 Azure SQL Database나 Azure Cosmos DB 같은 외부 서비스를 사용합니다. 또 다른 옵션은 Azure Disks 또는 Azure Files를 사용하여 솔루션에 영구 데이터 볼륨을 탑재하는 것입니다.

자세한 내용은 AKS(Azure Kubernetes Service)에서 애플리케이션에 대한 스토리지 옵션을 참조하세요.

서비스 개체

Kubernetes Service 개체는 서비스 검색 기능에 대한 마이크로 서비스 요구 사항과 일치하는 기능 집합을 제공합니다.

• IP 주소입니다. 서비스 개체는 Pod 그룹(ReplicaSet)에 대한 고정 내부 IP 주소를 제공합니다. Pod가 만들어지거나 이동되면 이 내부 IP 주소에서 항상 서비스에 연결할 수 있습니다.

• 부하 분산 - 서비스의 IP 주소로 전송된 트래픽은 Pod에 부하 분산됩니다.

• 서비스 검색. 서비스는 Kubernetes DNS 서비스를 통해 내부 DNS 항목에 할당됩니다. 즉, API 게이트웨이가 DNS 이름을 사용하여 백 엔드 서비스를 호출할 수 있습니다. 서비스 간 통신에도 동일한 메커니즘을 사용할 수 있습니다. DNS 항목은 네임스페이스를 기준으로 구성되므로 네임스페이스가 제한된 컨텍스트에 해당하는 경우 서비스의 DNS 이름이 자연스럽게 애플리케이션 도메인에 매핑됩니다.

다음 다이어그램은 서비스와 Pod 간의 개념적 관계를 보여 줍니다. 엔드포인트 IP 주소 및 포트에 대한 실제 매핑은 Kubernetes 네트워크 프록시인 kube-proxy를 통해 수행됩니다.

수신

Kubernetes에서 수신 컨트롤러는 API 게이트웨이 패턴을 구현할 수 있습니다. 이 경우 수신 및 수신 컨트롤러는 함께 작동하여 다음과 같은 기능을 제공합니다.

• 클라이언트 요청을 적절한 백 엔드 서비스로 라우팅합니다. 라우팅은 클라이언트용 단일 엔드포인트를 제공하고 서비스에서 클라이언트를 분리하는 데 도움을 줍니다.

• 여러 요청을 단일 요청으로 집계하여 클라이언트와 백 엔드 사이의 전송량을 줄입니다.

• 백 엔드 서비스에서 SSL 종료, 인증, IP 제한 또는 클라이언트 속도 제한(제한) 등의 기능을 오프로드합니다.

수신은 프록시 서버에 대한 구성 설정을 추상화합니다. 또한 수신의 기본 구현을 제공하는 수신 컨트롤러도 필요합니다. Nginx, HAProxy, Traefik 및 Azure Application Gateway용 수신 컨트롤러가 있습니다.

수신 리소스는 다양한 기술로 처리할 수 있습니다. 함께 작동하려면 클러스터 내에서 수신 컨트롤러로 배포해야 합니다. 에지 라우터 또는 역방향 프록시로 작동합니다. 역방향 프록시 서버는 잠재적인 병목 상태 또는 단일 실패 지점이므로 고가용성을 위해 항상 두 개 이상의 복제본을 배포해야 합니다.

프록시 서버를 구성할 때 복잡한 파일이 필요한 경우가 많으며, 전문가가 아닌 경우 튜닝하기 어려울 수 있습니다. 따라서 수신 컨트롤러가 좋은 추상화 기능을 제공합니다. 또한 수신 컨트롤러는 Kubernetes API에 액세스할 수도 있으므로 라우팅 및 부하 분산에 대한 합리적인 의사 결정을 내릴 수 있습니다. 예를 들어 Nginx 수신 컨트롤러는 kube-proxy 네트워크 프록시를 우회합니다.

한편, 설정을 완전하게 제어해야 하는 경우 이 추상화를 우회하고 프록시 서버를 수동으로 구성하면 됩니다. 자세한 내용은 Kubernetes에 Nginx 또는 HAProxy 배포를 참조하세요.

Azure의 부하 분산 서비스에 대한 자세한 내용은 Azure의 부하 분산 옵션 개요를 참조하세요.

TLS/SSL 암호화

일반적인 구현에서 수신 컨트롤러는 SSL 종료에 사용됩니다. 따라서 수신 컨트롤러 배포의 일부로 TLS 인증서를 만들어야 합니다. 개발/테스트 목적으로 자체 서명된 인증서만 사용합니다. 자세한 내용은 AKS(Azure Kubernetes Service)에 HTTPS 수신 컨트롤러를 만들고 고유한 TLS 인증서 사용을 참조하세요.

프로덕션 워크로드의 경우 신뢰할 수 있는 CA(인증 기관)에서 서명된 인증서를 받아야 합니다. Let's Encrypt 인증서를 생성하고 구성하는 방법에 대한 자세한 내용은 AKS(Azure Kubernetes Service)에서 고정 공용 IP 주소를 사용하여 수신 컨트롤러 만들기를 참조하세요.

조직의 정책에 따라 인증서를 회전해야 할 수도 있습니다. 자세한 내용은 AKS(Azure Kubernetes Service)에서 인증서 교체를 참조하세요.

네임스페이스

네임스페이스를 사용하여 클러스터 내에서 서비스 구성합니다. Kubernetes 클러스터의 모든 개체는 네임스페이스에 속합니다. 기본적으로 새 개체를 만들면 해당 개체는 default 네임스페이스로 이동합니다. 하지만 클러스터의 리소스를 구성하는 데 도움이 되도록 보다 구체적인 이름의 네임스페이스를 만드는 것이 좋습니다.

첫째, 네임스페이스는 이름 충돌을 방지하는 데 도움이 됩니다. 여러 팀이 동일한 클러스터에 수백 개의 마이크로 서비스를 배포하고 모든 마이크로 서비스가 동일한 네임스페이스로 이동하면 관리가 어렵습니다. 또한 네임스페이스를 통해 다음과 같은 일을 할 수 있습니다.

• 네임스페이스에 할당된 Pod의 전체 세트가 해당 네임스페이스의 리소스 할당량을 초과할 수 없도록 네임스페이스에 리소스 제약 조건을 적용합니다.

• 네임스페이스 수준에서 RBAC 및 보안 정책을 비롯한 정책을 적용합니다.

마이크로 서비스 아키텍처의 경우 마이크로 서비스를 제한된 컨텍스트로 구성하고 각각의 제한된 컨텍스트에 대한 네임스페이스를 만드는 방안을 고려합니다. 예를 들어 제한된 컨텍스트 "주문 이행"과 관련된 모든 마이크로 서비스가 동일한 네임스페이스로 이동할 수 있습니다. 또는 개발 팀마다 네임스페이스를 만듭니다.

각 개발 팀의 자체 별도 네임스페이스에 유틸리티 서비스를 배치합니다. 예를 들어 클러스터 모니터링용 Elasticsearch 또는 Prometheus를 배포하거나 Helm용 Tiller를 배포할 수 있습니다.

상태 프로브

Kubernetes는 Pod에서 공개할 수 있는 두 가지 유형의 상태 프로브를 정의합니다.

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

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

프로브에 대해 생각할 때 Kubernetes에서 서비스가 작동하는 방식을 떠올리면 도움이 됩니다. 서비스에는 Pod 세트(0개 이상)와 일치하는 레이블 선택기가 있습니다. Kubernetes는 선택기와 일치하는 Pod에 트래픽을 부하 분산합니다. 성공적으로 시작되고 상태가 정상인 Pod만 트래픽을 수신합니다. 컨테이너가 충돌하면 Kubernetes는 Pod를 종료하고 대체 Pod를 예약합니다.

Pod가 성공적으로 시작되더라도 트래픽을 받을 준비가 완료되지 않은 경우가 가끔 있습니다. 컨테이너에서 실행 중인 애플리케이션이 메모리에 무언가를 로드하거나 구성 데이터를 읽는 초기화 작업을 예로 들 수 있습니다. Pod가 정상이지만 트래픽을 받을 준비가 완료되지 않았음을 나타내려면 준비 상태 프로브를 정의합니다.

활동성 프로브는 Pod가 여전히 실행 중이지만 정상 상태가 아니고 재활용해야 하는 상황을 처리합니다. 예를 들어 HTTP 요청을 처리하는 컨테이너가 어떤 이유로 중단되었다고 가정해 봅시다. 컨테이너는 충돌을 일으키지는 않지만 모든 요청 처리를 중단했습니다. HTTP 활동성 프로브를 정의하면 프로브가 응답을 중지할 경우 Kubernetes에 Pod를 다시 시작하라고 알립니다.

프로브를 설계할 때 몇 가지 사항을 고려해야 합니다.

• 코드의 시작 시간이 긴 경우 시작이 완료되기 전에 활동성 프로브가 실패를 보고할 위험이 있습니다. 이 프로브 실패를 방지하려면 프로브 시작을 지연시키는 initialDelaySeconds 설정을 사용하세요.

• Pod를 다시 시작하면 정상 상태로 복원되지 않는 한, 활동성 프로브는 도움이 되지 않습니다. 활동성 프로브를 사용하여 메모리 누수 또는 예기치 않은 교착 상태를 완화할 수 있지만, 즉시 다시 실패하는 Pod를 다시 시작해 봐야 아무 소용이 없습니다.

• 때때로 준비 상태 프로브는 종속 서비스를 확인하는 데 사용됩니다. 예를 들어 Pod가 데이터베이스에 종속된 경우 프로브가 데이터베이스 연결을 확인할 수 있습니다. 그러나 이 방법은 예기치 않은 문제를 일으킬 수 있습니다. 어떤 이유로 외부 서비스를 일시적으로 사용할 수 없게 될 수 있습니다. 그러면 서비스의 모든 Pod에 대해 준비 상태 프로브가 실패하고 모든 Pod가 부하 분산에서 제거되므로 연속 실패 업스트림이 발생합니다. 서비스가 일시적인 장애로부터 올바르게 복구될 수 있도록 서비스 내에서 재시도 처리를 구현하는 것이 더 좋은 방법입니다.

리소스 제약 조건

리소스 경합은 서비스의 가용성에 영향을 줄 수 있습니다. 단일 컨테이너가 클러스터 리소스(메모리 및 CPU)를 모두 사용할 수 없도록 컨테이너에 대한 리소스 제약 조건을 정의합니다. 스레드 또는 네트워크 연결 같은 컨테이너 이외 리소스는 격벽 패턴을 사용하여 리소스를 격리하는 방안을 고려합니다.

리소스 할당량을 사용하여 네임스페이스에 허용되는 총 리소스를 제한합니다. 이렇게 하면 프런트 엔드가 리소스의 백 엔드 서비스를 고갈시킬 수 없으며 그 반대도 마찬가지입니다.

보안

RBAC(역할 기반 액세스 제어)

Kubernetes와 Azure 둘 다 RBAC(역할 기반 액세스 제어)에 대한 메커니즘을 갖고 있습니다.

• Azure RBAC는 새 Azure 리소스를 만드는 기능을 포함하여 Azure의 리소스에 대한 액세스를 제어합니다. 사용자, 그룹 또는 서비스 주체에 권한을 할당할 수 있습니다. (서비스 주체는 애플리케이션에서 사용하는 보안 ID입니다.)

• Kubernetes RBAC는 Kubernetes API 권한을 제어합니다. 예를 들어 Pod 만들기 및 Pod 나열은 Kubernetes RBAC를 통해 사용자에게 권한을 부여(또는 거부)할 수 있는 작업입니다. 사용자에게 Kubernetes 권한을 할당하려면 역할 및 역할 바인딩을 만듭니다.

  • 역할은 네임스페이스 내에서 적용되는 권한 세트입니다. 권한은 리소스(Pod, 배포 등)에서 동사(가져오기, 업데이트, 만들기, 삭제)로 정의됩니다.

  • RoleBinding은 사용자 또는 그룹을 역할에 할당합니다.

  • 역할과 비슷하지만 모든 네임스페이스에서 전체 클러스터에 적용되는 ClusterRole 개체도 있습니다. 사용자 또는 그룹을 ClusterRole에 할당하려면 ClusterRoleBinding를 만듭니다.

AKS는 이러한 두 가지 RBAC 메커니즘을 통합합니다. AKS 클러스터를 만들 때 사용자 인증에 Microsoft Entra ID를 사용하도록 구성할 수 있습니다. 이를 설정하는 방법에 대한 자세한 내용은 Azure Kubernetes Service와 Microsoft Entra ID 통합을 참조 하세요.

구성되면 Kubernetes API에 액세스하려는 사용자(예: kubectl을 통해)는 Microsoft Entra 자격 증명을 사용하여 로그인해야 합니다.

기본적으로 Microsoft Entra 사용자는 클러스터에 액세스할 수 없습니다. 액세스 권한을 부여하기 위해 클러스터 관리자는 Microsoft Entra 사용자 또는 그룹을 참조하는 RoleBindings를 만듭니다. 사용자가 특정 작업에 대한 권한이 없는 경우 해당 작업이 실패합니다.

사용자가 기본적으로 액세스 권한이 없다면 클러스터 관리자는 어떻게 역할 바인딩을 만드는 권한을 갖게 되는 걸까요? AKS 클러스터에는 실제로 Kubernetes API 서버를 호출하기 위한 두 가지 유형의 자격 증명인 클러스터 사용자 및 클러스터 관리자가 있습니다. 클러스터 관리자 자격 증명은 클러스터에 대한 전체 액세스 권한을 부여합니다. Azure CLI 명령 az aks get-credentials --admin은 클러스터 관리자 자격 증명을 다운로드하여 kubeconfig 파일로 저장합니다. 클러스터 관리자는 이 kubeconfig 파일을 사용하여 역할 및 역할 바인딩을 만들 수 있습니다.

Kubernetes 클러스터 역할 및 RoleBinding 개체를 Kubernetes에서 기본적으로 관리하는 대신 Kubernetes 권한 부여에 Azure RBAC를 사용하는 것이 좋습니다. 이를 통해 Azure 리소스, AKS, Kubernetes 리소스에 대한 통합 관리와 액세스 제어가 가능합니다. 이러한 Azure RBAC 역할 할당은 보다 세분화된 액세스 제어를 위해 클러스터 내의 클러스터 또는 네임스페이스를 대상으로 할 수 있습니다. Azure RBAC는 제한된 기본 권한 집합을 지원하며, 역할과 RoleBindings를 관리하는 네이티브 Kubernetes 메커니즘과 결합하여 고급 또는 더 세분화된 액세스 패턴을 지원할 수 있습니다. 사용하도록 설정하면 Microsoft Entra 보안 주체는 Azure RBAC에서만 유효성을 검사하고 일반 Kubernetes 사용자 및 서비스 계정은 Kubernetes RBAC에서 단독으로 유효성을 검사합니다.

클러스터 관리자 자격 증명은 아주 강력하므로 Azure RBAC를 사용하여 액세스를 제한해야 합니다.

• "Azure Kubernetes 서비스 클러스터 관리자 역할"은 클러스터 관리자 자격 증명을 다운로드하는 권한을 갖고 있습니다. 클러스터 관리자에게만 이 역할을 할당해야 합니다.

• "Azure Kubernetes 서비스 클러스터 사용자 역할"은 클러스터 사용자 자격 증명을 다운로드하는 권한을 갖고 있습니다. 관리자가 아닌 사용자에게 이 역할을 할당할 수 있습니다. 이 역할은 클러스터 내부의 Kubernetes 리소스에 대한 특정 권한을 제공하지 않고, 사용자가 API 서버에 연결하는 것만 허용합니다.

RBAC 정책을 정의할 때(Kubernetes 및 Azure 둘 다) 조직의 역할에 대해 고민해야 합니다.

• AKS 클러스터를 생성 또는 삭제하고 관리자 자격 증명을 다운로드할 수 있는 사람은 누구입니까?
• 클러스터를 관리할 수 있는 사람은 누구입니까?
• 네임스페이스 내에서 리소스를 만들고 업데이트할 수 있는 사람은 누구입니까?

ClusterRoles 및 ClusterRoleBindings보다는 역할 및 RoleBindings를 사용하여 네임스페이스별로 Kubernetes RBAC 권한 범위를 지정하는 것이 좋습니다.

마지막으로 AKS 클러스터가 부하 분산 장치, 네트워킹, 스토리지 등의 Azure 리소스를 만들고 관리하려면 어떤 권한이 필요한지 결정해야 합니다. Azure API를 사용하여 인증하기 위해 클러스터는 Microsoft Entra 서비스 주체를 사용합니다. 클러스터를 만들 때 서비스 주체를 지정하지 않으면 자동으로 생성됩니다. 하지만 먼저 서비스 주체를 만든 후 최소한의 RBAC 권한을 할당하는 것이 보안상 좋은 방법입니다. 자세한 내용은 Azure Kubernetes Service를 사용하는 서비스 주체를 참조하세요.

비밀 관리 및 애플리케이션 자격 증명

애플리케이션 및 서비스가 Azure Storage 또는 SQL Database 같은 외부 서비스에 연결할 수 있는 자격 증명이 필요한 경우가 종종 있습니다. 문제는 이러한 자격 증명이 유출되지 않도록 안전하게 보호하는 것입니다.

Azure 리소스의 경우 관리 ID를 사용하는 옵션이 있습니다. 관리 ID의 개념은 애플리케이션 또는 서비스에 Microsoft Entra ID에 저장된 ID가 있고 이 ID를 사용하여 Azure 서비스로 인증한다는 것입니다. 애플리케이션 또는 서비스에는 Microsoft Entra ID로 만든 서비스 주체가 있으며 OAuth 2.0 토큰을 사용하여 인증합니다. 실행 중인 프로세스 코드는 사용할 토큰을 투명하게 가져올 수 있습니다. 이 방식을 사용하면 암호 또는 연결 문자열을 저장할 필요가 없습니다. Microsoft Entra 워크로드 ID(미리 보기)를 사용하여 개별 Pod에 Microsoft Entra ID를 할당하여 AKS에서 관리 ID를 사용할 수 있습니다.

현재 일부 Azure 서비스는 관리 ID를 사용한 인증을 지원하지 않습니다. 목록은 Microsoft Entra 인증을 지원하는 Azure 서비스를 참조하세요.

관리 ID를 사용하더라도 관리 ID를 지원하지 않는 Azure 서비스, 타사 서비스, API 키 등에 대한 일부 자격 증명 또는 기타 애플리케이션 비밀을 저장해야 합니다. 다음은 비밀을 안전하게 저장하기 위한 옵션입니다.

• Azure Key Vault. AKS에서는 Key Vault에서 하나 이상의 비밀을 볼륨으로 탑재할 수 있습니다. 볼륨은 Key Vault에서 비밀을 읽습니다. 그러면 Pod가 마치 정규 볼륨처럼 비밀을 읽을 수 있습니다. 자세한 내용은 AKS 클러스터에서 비밀 저장소 CSI 드라이버용 Azure Key Vault 공급자 사용을 참조하세요.

  Pod는 워크로드 ID를 사용하거나 사용자 또는 시스템이 할당한 관리 ID를 사용하여 자체 인증합니다. 자세한 고려 사항은 비밀 저장소 CSI 드라이버용 Azure Key Vault 공급자에 액세스하기 위한 ID 제공을 참조하세요.

• HashiCorp Vault. Kubernetes 애플리케이션은 Microsoft Entra 관리 ID를 사용하여 HashiCorp Vault로 인증할 수 있습니다. Microsoft Entra ID를 사용하는 HashiCorp Vault를 참조하세요. Vault 자체를 Kubernetes에 배포할 수는 있지만, 애플리케이션 클러스터에 준비된 별도의 전용 클러스터에서 실행하는 것이 좋습니다.

• Kubernetes 비밀. 또 다른 옵션은 간단하게 Kubernetes 비밀을 사용하는 것입니다. 이 옵션은 구성 방법이 가장 간단하지만 몇 가지 문제가 있습니다. 분산 키-값 저장소인 etcd에 비밀이 저장됩니다. AKS가 미사용 etcd를 암호화합니다. Microsoft에서 암호화 키를 관리합니다.

HashiCorp Vault 또는 Azure Key Vault 같은 시스템을 사용하면 다음과 같은 장점이 있습니다.

• 비밀을 중앙에서 제어할 수 있습니다.
• 모든 미사용 비밀이 암호화됩니다.
• 키를 중앙에서 관리합니다.
• 비밀 액세스를 제어할 수 있습니다.
• 감사

컨테이너 및 오케스트레이터 보안

다음은 Pod와 컨테이너의 보안을 위한 권장 사례입니다.

• 위협 모니터링:컨테이너용 Microsoft Defender(또는 타사 기능)를 사용하여 위협을 모니터링합니다. VM에서 컨테이너를 호스트하는 경우 서버용 Microsoft Defender 또는 타사 기능을 사용합니다. 또한 Azure Monitor의 컨테이너 모니터링 솔루션에서 Microsoft Sentinel 또는 기존 SIEM 솔루션으로 로그를 통합할 수 있습니다.

• 취약성 모니터링:클라우드용 Microsoft Defender 또는 Azure Marketplace를 통해 제공되는 타사 솔루션을 사용하여 이미지 및 실행 컨테이너에서 알려진 취약성을 지속적으로 모니터링합니다.

• Azure Container Registry의 기능인 ACR 작업을 사용하여 이미지 패칭을 자동화합니다. 컨테이너 이미지는 레이어에서 빌드됩니다. 기본 레이어에는 ASP.NET Core 또는 Node.js 같은 OS 이미지 및 애플리케이션 프레임워크 이미지가 포함됩니다. 기본 이미지는 일반적으로 업스트림에서 애플리케이션 개발자가 생성하고, 다른 프로젝트 관리자가 유지 관리합니다. 이러한 이미지가 업스트림에서 패치될 때 알려진 보안 취약성이 남아 있지 않도록 이미지를 업데이트, 테스트 및 재배포해야 합니다. ACR 작업은 이 프로세스를 자동화하는 데 도움이 될 수 있습니다.

• Azure Container Registry 또는 Docker Trusted Registry 같은 신뢰할 수 있는 프라이빗 레지스트리에 이미지를 저장합니다. Pod가 신뢰할 수 있는 레지스트리의 이미지만 끌어오도록 유효성 검사 허가 webhook를 사용합니다.

• 최소 권한 원칙 적용

  • 컨테이너를 권한 있는 모드로 실행하지 마세요. 권한 있는 모드는 호스트의 모든 디바이스에 컨테이너 액세스를 제공합니다.
  • 되도록이면 프로세스를 컨테이너 내부에서 루트로 실행하지 마세요. 컨테이너는 보안의 관점에서 완전한 격리를 제공하지 않으므로 컨테이너 프로세스를 권한 없는 사용자로 실행하는 것이 좋습니다.

DevOps

이 참조 아키텍처는 클라우드 리소스 및 해당 종속성을 프로비저닝하기 위한 Azure Resource Manager 템플릿을 제공합니다. [Azure Resource Manager 템플릿][arm-template]을 사용하면 Azure DevOps Services를 사용하여 다양한 환경을 몇 분 안에 프로비저닝할 수 있습니다(예: 프로덕션 시나리오 복제). 이렇게 하면 필요한 경우에만 비용을 절감하고 부하 테스트 환경을 프로비전할 수 있습니다.

ARM 템플릿을 구성하려면 워크로드 격리 기준을 따르는 것이 좋습니다. 워크로드는 일반적으로 임의의 기능 단위로 정의됩니다. 예를 들어 클러스터에 대한 별도의 템플릿과 종속 서비스에 대한 다른 템플릿을 가질 수 있습니다. 워크로드를 격리하면 모든 워크로드는 해당 DevOps 팀에 연결되고 팀에서 관리하기 때문에 DevOps에서 CI/CD(지속적인 통합 및 지속적인 업데이트)를 수행할 수 있습니다.

배포(CI/CD) 고려 사항

마이크로 서비스 아키텍처에 대한 강력한 CI/CD 프로세스의 목표는 다음과 같습니다.

• 각 팀은 다른 팀에 영향을 주거나 방해하지 않고 독립적으로 소유한 서비스를 빌드하여 배포할 수 있습니다.
• 새 버전의 서비스를 프로덕션 환경에 배포하기 전에 개발/테스트/QA 환경에 배포하여 유효성을 검사합니다. 각 단계에서 품질 게이트를 적용합니다.
• 새 버전의 서비스를 이전 버전과 함께 배포할 수 있습니다.
• 충분한 액세스 제어 정책을 적용합니다.
• 컨테이너화된 워크로드의 경우 프로덕션 환경에 배포된 컨테이너 이미지를 신뢰할 수 있습니다.

문제에 대해 자세히 알아보려면 마이크로 서비스 아키텍처에 대한 CI/CD를 참조하세요.

특정 권장 사항 및 모범 사례는 Kubernetes의 마이크로 서비스에 대한 CI/CD를 참조하세요.

비용 최적화

Azure 가격 계산기를 사용하여 비용을 예측합니다. 기타 고려 사항은 Microsoft Azure Well-Architected Framework의 비용 섹션에 설명되어 있습니다.

다음은 이 아키텍처에 사용되는 서비스에 대해 고려할 사항입니다.

AKS(Azure Kubernetes Service)

Kubernetes 클러스터의 배포, 관리 및 운영에서 AKS와 관련된 비용은 없습니다. Kubernetes 클러스터에서 사용하는 가상 머신 인스턴스, 스토리지 및 네트워킹 리소스에 해당하는 요금만 지급합니다.

필요한 리소스의 비용을 예측하려면 Container Services 계산기를 참조하세요.

Azure 부하 분산 장치

구성된 부하 분산 및 아웃바운드 규칙 수에 대해서만 요금이 청구됩니다. 인바운드 NAT 규칙은 무료입니다. 규칙을 구성하지 않으면 표준 Load Balancer에 대한 시간당 요금이 청구되지 않습니다.

자세한 내용은 Azure Load Balancer 가격 책정을 참조하세요.

Azure Pipelines

이 참조 아키텍처는 Azure Pipelines만 사용합니다. Azure는 Azure Pipeline을 개별 서비스로 제공합니다. CI/CD의 경우 매월 1,800분의 무료 Microsoft 호스팅 작업과 매월 제한 없는 1개의 자체 호스팅 작업이 허용되며, 추가 작업에는 요금이 부과됩니다. 자세한 내용은 Azure DevOps Services 가격 책정을 참조하세요.

Azure Monitor

Azure Monitor Log Analytics의 경우 데이터 수집과 보존에 대한 요금이 청구됩니다. 자세한 내용은 Azure Monitor 가격을 참조하세요.

시나리오 배포

이 아키텍처에 대한 참조 구현을 배포하려면 GitHub 리포지토리에 설명된 단계를 따르세요.

다음 단계

• AKS(Azure Kubernetes Service)를 사용하는 서비스 주체
• 컨테이너용 Microsoft Defender
• 서버용 Microsoft Defender
• Azure Monitor의 컨테이너 모니터링 솔루션
• Microsoft Sentinel 또는 기존 SIEM 솔루션.
• 클라우드용 Microsoft Defender 또는 Azure Marketplace를 통해 제공되는 타사 솔루션.
• ACR 작업

관련 참고 자료

• 고급 마이크로 서비스 예제를 진행하려면 고급 AKS(Azure Kubernetes Service) 마이크로 서비스 아키텍처를 참조하세요.
• 이 애플리케이션의 성능을 측정한 방법을 알아보려면 성능 튜닝 시나리오: 분산 비즈니스 트랜잭션을 참조하세요.
• 마이크로서비스 아키텍처를 위한 CI/CD
• Kubernetes에서 마이크로서비스에 대한 CI/CD