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

Azure Active Directory
Container Registry
Kubernetes Service
Load Balancer
Monitor
Pipelines

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

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

AKS 참조 아키텍처

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

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

구성 요소

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

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

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

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

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

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

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

를 Azure Container Registry. Container Registry를 사용하여 클러스터에 배포되는 프라이빗 Docker 이미지를 저장합니다. AKS는 Azure AD ID를 사용하여 Container Registry를 인증할 수 있습니다. AKS는 Azure Container Registry가 필요 없습니다. Docker 허브 같은 다른 컨테이너 레지스트리를 사용할 수 있습니다.

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

투구. 투구는 게시, 배포, 버전 관리 및 업데이트할 수 있는 단일 단위로 Kubernetes 개체를 번들 하 고 일반화 하는 방법인 Kubernetes 용 패키지 관리자입니다.

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

디자인 고려 사항

이 참조 아키텍처는 마이크로 서비스 아키텍처에 중점을 두지만, 많은 권장 사례가 AKS에서 실행 되는 다른 워크 로드에 적용 됩니다.

마이크로 서비스

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

API 게이트웨이

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

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

데이터 스토리지

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

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

데이터를 노드에 연결 하므로 영구 데이터를 로컬 클러스터 저장소에 저장 하지 마세요. 대신 Azure SQL Database 또는 Cosmos DB와 같은 외부 서비스를 사용 합니다. 또 다른 옵션은 Azure 디스크 또는 Azure Files 사용하여 솔루션에 영구 데이터 볼륨을 탑재하는 것입니다.

자세한 내용은 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를 통해 수행됩니다.

서비스 및 Pod

수신

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

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

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

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

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

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

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

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

AKS의 경우 Application Gateway 수신 컨트롤러를 사용 하 여 Azure 애플리케이션 게이트웨이를 사용할 수도 있습니다. Application Gateway는 AKS 가상 네트워크의 서브넷에 배포 되므로이 옵션을 사용 하려면 AKS 클러스터를 구성할 때 Cni 네트워킹 을 사용 하도록 설정 해야 합니다. Azure 애플리케이션 Gateway는 계층 7 라우팅 및 SSL 종료를 수행할 수 있습니다. 또한 WAF (웹 응용 프로그램 방화벽)를 기본적으로 지원 합니다.

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

TLS/SSL 암호화

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

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

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

네임스페이스

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

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

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

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

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

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

상태 프로브

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

  • 준비 프로브: pod가 요청을 받을 준비가 되었는지 여부를 Kubernetes에 알립니다.

  • 선거의 probe: 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 클러스터를 만들 때 사용자 인증에 Azure AD를 사용하도록 구성할 수 있습니다. 이렇게 설정하는 방법에 대한 자세한 내용은 Azure Kubernetes Service와 Azure Active Directory 통합을 참조하세요.

이 구성을 마치면 Kubernetes API에 액세스하려는 사용자는(예: kubectl를 통해) Azure AD 자격 증명을 사용하여 로그인해야 합니다.

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

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

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

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

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

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

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

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

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

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

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

Azure 리소스의 경우 관리 ID를 사용하는 옵션이 있습니다. 애플리케이션 또는 서비스가 Azure AD에 ID를 저장하고, 이 ID를 사용하여 Azure 서비스를 인증한다는 것이 관리 ID의 개념입니다. 애플리케이션 또는 서비스는 생성한 서비스 주체를 Azure AD에 저장하고, OAuth 2.0 토큰을 사용하여 인증합니다. 실행 프로세스는 localhost 주소를 호출하여 토큰을 가져옵니다. 이 방식을 사용하면 암호 또는 연결 문자열을 저장할 필요가 없습니다. aad-pod-identity 프로젝트를 사용하여 개별 Pod에 ID를 할당하면 AKS에서 관리 ID를 사용할 수 있습니다.

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

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

  • Azure Key Vault. AKS에서는 Key Vault에서 하나 이상의 비밀을 볼륨으로 탑재할 수 있습니다. 볼륨은 Key Vault에서 비밀을 읽습니다. 그러면 Pod가 마치 정규 볼륨처럼 비밀을 읽을 수 있습니다. 자세한 내용은 GitHub의 secrets-store-csi-driver-provider-azure 프로젝트를 참조하세요.

    Pod는 위에서 설명한 Pod ID를 사용하거나 클라이언트 비밀과 함께 Azure AD 서비스 주체를 사용하여 자신을 인증합니다. 이 경우 클라이언트 비밀이 필요 없으므로 Pod ID를 사용하는 것이 좋습니다.

  • HashiCorp Vault. Kubernetes 애플리케이션은 Azure AD 관리 ID를 사용하여 HashiCorp Vault를 인증할 수 있습니다. HashiCorp Vault에서 말하는 Azure Active Directory를 참조하세요. Kubernetes에 자격 증명 모음 자체를 배포하고 애플리케이션 클러스터와 별도의 전용 클러스터에서 실행하는 것이 좋습니다.

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

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

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

컨테이너 및 Orchestrator 보안

다음은 Pod 및 컨테이너를 보호하기 위한 권장 사례입니다.

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

  • 취약성 모니터링 - Azure Marketplace 통해 사용할 수 있는 Azure Security Center 또는 타사 솔루션을 사용하여 이미지 및 실행 중인 컨테이너에서 알려진 취약성을 지속적으로 모니터링합니다.

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

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

  • 최소 권한 적용 원칙

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

DevOps 고려 사항

이 참조 아키텍처는 클라우드 리소스 및 해당 의존성을 프로비전하기 위한 [Azure Resource Manager 템플릿][arm-template]을 제공합니다. [Azure Resource Manager 템플릿] [arm-템플릿]을 사용 하면 프로덕션 시나리오를 복제 하는 등의 방법으로 [Azure DevOps Services] [az-devops]를 사용 하 여 몇 분 내에 다른 환경을 프로 비전 할 수 있습니다. 이를 통해 비용을 절감 하 고 필요한 경우에만 부하 테스트 환경을 프로 비전 할 수 있습니다.

워크 로드 격리 조건을 따라 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)

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

필요한 리소스의 비용을 예측 하려면 컨테이너 서비스 계산기를 참조 하세요.

Azure 부하 분산 장치

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

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

Azure Pipelines

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

Azure Monitor

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

솔루션 배포

이 아키텍처에 대한 참조 구현을 배포하려면 GitHub 리포지토의단계를 수행합니다.

다음 단계