AKS(Azure Kubernetes Service) 클러스터에 대한 기본 아키텍처

Azure Kubernetes Service (AKS) 클러스터를 배포하기 위한 권장 기본 인프라의 참조 아키텍처에 대해 알아보세요. 디자인 원칙을 사용하며 Azure Well-Architected Framework의 AKS 아키텍처 모범 사례를 기반으로 합니다. 이 문서는 이 범용 인프라를 배포할 때 네트워킹, 보안 및 ID 팀과 같은 여러 개별 학제 간 그룹을 안내하는 데 도움이 됩니다.

이 아키텍처는 워크로드에 초점을 맞추지 않습니다. AKS 클러스터 자체에 집중합니다. 이 정보는 대부분의 AKS 클러스터에 권장되는 최소 기준입니다. 다중 지역 성장을 지원하고, 클러스터 내 트래픽을 보호하는 네트워크 토폴로지인 가시성을 제공하는 Azure 서비스와 통합됩니다.

대상 아키텍처는 비즈니스 요구 사항의 영향을 받아서, 애플리케이션 컨텍스트마다 다를 수 있습니다. 아키텍처를 사전 프로덕션 및 프로덕션 스테이지의 시작점으로 생각해보세요.

Kubernetes는 Azure 및 Microsoft 기술 이상으로 확장되는 강력한 에코시스템입니다. AKS 클러스터를 배포할 때 클러스터를 설계하고 운영하는 방법에 대한 다양한 결정을 내릴 책임이 있습니다. AKS 클러스터를 실행하려면 Microsoft를 비롯한 다양한 공급업체의 폐쇄 소스 구성 요소가 혼합됩니다. Kubernetes 에코시스템의 오픈 소스 구성 요소 및 환경이 자주 변경되므로 정기적으로 결정을 다시 검토해야 할 수 있습니다. Kubernetes를 채택하면 워크로드에 기능이 필요하고 워크로드 팀이 지속적으로 투자할 준비가 되었다는 사실을 인정하게 됩니다.

GitHub: AKS 기준 참조 구현에서 이 아키텍처의 구현을 사용할 수 있습니다. 이를 대체 시작점으로 사용하고 필요에 따라 참조 아키텍처를 구성합니다.

네트워킹 구성

네트워크 토폴로지
IP 주소 계획
수신 리소스 배포

클러스터 컴퓨팅

기본 클러스터에 대한 컴퓨팅
컨테이너 이미지 참조
정책 관리

ID 관리

클러스터용 Microsoft Entra ID 통합
워크로드에 대한 Microsoft Entra ID 통합

데이터 흐름 보안

데이터 흐름 보안
비밀 관리 추가

비즈니스 연속성

확장성
클러스터 및 노드 가용성
가용성 및 다중 지역 지원

작업

클러스터 및 워크로드 CI/CD 파이프라인
클러스터 상태 및 메트릭
비용 관리 및 보고

네트워크 토폴로지

이 아키텍처는 허브-및 스포크 네트워크 토폴로지를 사용합니다. 가상 네트워크 피어링을 통해 연결된 별도의 가상 네트워크에 허브와 스포크를 배포합니다. 이 토폴로지에는 몇 가지 이점이 있습니다. 이 토폴로지를 사용하여 다음을 수행합니다:

• 분리된 관리 활성화. 거버넌스를 적용하여 최소 권한 원칙을 준수할 수 있습니다. 또한, 업무 분리를 통해 Azure 랜딩 존의 개념을 지원합니다.

• 퍼블릭 인터넷에 대한 Azure 리소스의 직접적인 노출을 최소화합니다.

• 지역 허브 및 스포크 토폴로지 제공 허브 및 스포크 네트워크 토폴로지는 나중에 확장하여 워크로드 격리를 제공할 수 있습니다.

• 웹 애플리케이션 방화벽 서비스를 사용하여 모든 웹 애플리케이션에 대한 HTTP 트래픽 흐름을 검사할 수 있습니다.

• 여러 구독에 걸쳐 있는 워크로드에 대한 지원을 제공합니다.

• 아키텍처를 확장 가능하게 만들어주세요. 새 기능 또는 워크로드를 수용하기 위해, 네트워크 토폴로지의 재설계 대신 새 스포크를 추가할 수 있습니다.

• 네트워크 간에 방화벽 및 도메인 이름 시스템 (DNS) 영역과 같은 리소스 공유를 지원합니다.

• Azure 엔터프라이즈 규모 랜딩 존에 정렬.

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

자세한 내용은 Azure의 허브 스포크 네트워크 토폴로지를 참조하세요.

AKS 기준 참조 아키텍처의 Windows 컨테이너에 포함된 네트워크 디자인 변경 내용에 대한 자세한 내용은 AKS의 Windows 컨테이너를 참조하세요.

허브 가상 네트워크

허브 가상 네트워크는 연결 및 가시성의 중심점입니다. 이 아키텍처에서 허브에는 다음이 포함됩니다.

• 조직 전체의 방화벽 정책을 강제하기 위해 중앙 IT 팀에서 정의한 글로벌 방화벽 정책이 적용된 Azure Firewall.
• 가상 머신 (VMs)에 대한 원격 액세스를 위한 Azure Bastion.
• VPN 연결을 위한 게이트웨이 서브넷입니다.
• 네트워크 가시성을 위한 Azure Monitor.

네트워크 내에서 아키텍처에는 세 개의 서브넷이 있습니다.

Azure Firewall을 호스트하는 서브넷

Azure Firewall은 관리된 병화벽 서비스입니다. Azure Firewall 인스턴스는 아웃바운드 네트워크 트래픽을 보호합니다. 이 보안 계층이 없으면, 트래픽은 중요한 워크로드 데이터를 유출할 수 있는 악의적인 타사 서비스와 통신할 수 있습니다. Azure Firewall Manager를 사용하여 여러 Azure Firewall 인스턴스를 중앙에서 배포 및 구성하고 이 허브 가상 네트워크의 네트워크 아키텍처 유형에 대한 Azure Firewall 정책을 관리할 수 있습니다.

게이트웨이를 호스트하는 서브넷

이 서브넷은 VPN 게이트웨이 또는 Azure ExpressRoute 게이트웨이의 자리 표시자입니다. 게이트웨이는 온-프레미스 네트워크와 가상 네트워크의 라우터를 연결합니다.

Azure Bastion을 호스트하는 서브넷

이 서브넷은 Azure Bastion의 자리 표시자입니다. Azure Bastion을 사용하여 리소스를 인터넷에 노출하지 않고도 Azure 리소스에 안전하게 액세스할 수 있습니다. 이 서브넷은 관리 및 운영 전용입니다.

스포크 가상 네트워크

스포크 가상 네트워크에는 AKS 클러스터와 기타 관련 리소스가 포함됩니다. 스포크에는 다음 서브넷이 있습니다.

Azure Application Gateway를 호스트하는 서브넷

Application Gateway는 계층 7에서 작동하는 웹 트래픽 부하 분산 장치입니다. 참조 구현은 Azure Web Application Firewall을 사용하도록 설정하는 Application Gateway v2 SKU를 사용합니다. Web Application Firewall은 봇을 포함한 일반적인 웹 트래픽 공격으로부터 들어오는 트래픽을 보호합니다. 인스턴스에는 사용자 요청을 수신하는 공용 프런트-엔드 IP 구성이 있습니다. 기본적으로 Application Gateway에는 전용 서브넷이 필요합니다.

수신 리소스를 호스트하는 서브넷

Traefik은 트래픽을 라우팅하고 분산하기 위해, Kubernetes 수신 리소스를 수행하는 수신 컨트롤러입니다. Azure 내부 부하 분산 장치가 이 서브넷에 있습니다. 자세한 내용은 AKS에서 내부 Load Balancer 사용을 참조하세요.

클러스터 노드를 호스트하는 서브넷

AKS는 개별 노드 그룹인 두 개의 노드 풀을 유지 관리합니다. 시스템 노드 풀은 핵심 클러스터 서비스를 실행하는 Pod를 호스트합니다. 사용자 노드 풀은 작업 부하와 수신 컨트롤러를 실행하여 워크로드에 대한 인바운드 통신을 사용합니다.

Azure Private Link 엔드포인트를 호스트하는 서브넷

Azure Private Link 연결은 Azure Container Registry 및 Azure Key Vault에 대한 Private Link 연결을 만들어, 사용자는 스포크 가상 네트워크 안에서 프라이빗 엔드포인트방식으로 이러한 서비스에 액세스할 수 있습니다. 프라이빗 엔드포인트에는 전용 서브넷이 필요하지 않습니다. 허브 가상 네트워크에 프라이빗 엔드포인트를 배치할 수도 있습니다. 기준 구현에서는,엔드포인트가 스포크 가상 네트워크 안의 전용 서브넷에 배포됩니다. 이 방법은 피어된 네트워크 연결을 통과하는 트래픽을 줄입니다. 클러스터에 속한 리소스를 동일한 가상 네트워크에 유지합니다. 네트워크 보안 그룹을 사용하여 서브넷 수준에서 세분화된 보안 규칙을 적용할 수도 있습니다.

자세한 내용은 Private Link 배포 옵션을 참조하세요.

IP 주소 계획

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

이 참조 아키텍처는 각각 IP 주소 공간이 필요한 여러 네트워킹 방법을 사용합니다.

• 클러스터 노드, 프라이빗 엔드포인트 및 Application Gateway와 같은 리소스에 사용되는 Azure 가상 네트워크입니다.
• 클러스터는 별도의 주소 공간에서 Azure 가상 네트워크에 IP 주소를 Pod에 할당하는 Azure CNI 오버레이를 사용합니다.

가상 네트워크 IP 주소 공간

Azure 가상 네트워크의 주소 공간은 모든 서브넷을 보유할 수 있을 만큼 커야 합니다. 트래픽을 수신할 모든 엔터티를 고려하세요. Kubernetes는 서브넷 주소 공간의 해당 엔터티에 IP주소를 할당합니다. Azure 가상 네트워크의 IP 주소를 계획할 때 이러한 점을 고려합니다.

• 업그레이드: AKS는 정기적으로 노드를 업데이트하여 기본 VMs에서 보안 기능 및 기타 시스템 패치가 최신 상태로 유지되도록 합니다. 업그레이드 프로세스 중에 AKS는 Pod를 일시적으로 호스트하는 노드를 만들고, 업그레이드 노드는 통제되고 드레이닝됩니다. 해당 임시 노드에는 클러스터 서브넷의 IP 주소가 할당됩니다. 이러한 임시 노드 IP 주소에 충분한 주소 공간이 있는지 확인합니다.

  이 아키텍처에서 Pod는 롤링 업데이트 중을 포함하여 Azure CNI 오버레이 Pod 주소 공간 내에서 할당된 IP 주소입니다. 이 방법은 다른 Kubernetes 네트워킹 방법에 비해 Azure 가상 네트워크에서 사용되는 전체 IP 주소 수를 줄입니다.

• 확장성: 모든 시스템 및 사용자 노드의 노드 수와 최대 스케일링 성능 제한을 고려합니다. 400%까지 스케일 아웃하는 경우를 가정해 보겠습니다. 스케일 아웃되는 노드 전부에 대해 4배의 주소 수가 필요합니다.

  이 아키텍처는 Azure CNI 오버레이를 사용하므로 Pod의 확장성은 가상 네트워크의 주소 공간에 영향을 주지 않습니다.

• Private Link 주소: Private Link를 통해 다른 Azure 서비스와 통신하는 데 필요한 주소를 고려합니다. 이 아키텍처에는 Container Registry 및 Key Vault에 대한 링크에 두 개의 주소가 할당됩니다.

• 예약된 IP 주소: Azure는 용도에 대해 특정 주소 를 예약합니다 이 주소는 할당할 수 없습니다.

앞의 목록은 완전하지 않습니다. 사용 가능한 IP 주소 수에 영향을 주는 다른 리소스가 디자인에 있는 경우, 해당 주소를 수용합니다.

이 아키텍처는 단일 워크로드용으로 디자인되었습니다. 프로덕션 AKS 클러스터에서 항상 시스템 노드 풀을 사용자 노드 풀과 분리합니다. 클러스터에서 여러 워크로드를 실행하는 경우 사용자 노드 풀을 서로 격리할 수 있습니다. 그렇게 하면, 크기가 작은 서브넷이 더 많아집니다. 또한 수신 리소스는 더 복잡할 수 있으므로 추가 IP 주소가 필요한 여러 수신 컨트롤러가 필요할 수 있습니다.

Pod IP 주소 공간

Azure CNI 오버레이는 가상 네트워크에서 사용하는 주소 공간과는 별개인 전용 주소 공간을 사용하여 Pod에 IP 주소를 할당합니다. 가상 네트워크 또는 피어된 가상 네트워크와 겹치지 않는 IP 주소 공간을 사용합니다. 그러나 여러 AKS 클러스터를 만드는 경우 각 클러스터에서 동일한 Pod 주소 공간을 안전하게 사용할 수 있습니다.

각 노드에는 해당 Pod에 대한 /24 주소 공간이 할당되므로 클러스터의 노드 수에 필요한 만큼 /24 블록을 허용하도록 Pod 주소 공간이 충분히 큰지 확인해야 합니다. 업그레이드 또는 스케일 아웃 작업 중에 만든 임시 노드를 포함해야 합니다. 예를 들어 CIDR 범위에 /16 주소 공간을 사용하는 경우 클러스터는 최대 약 250개의 노드로 확장될 수 있습니다.

각 노드는 최대 250개의 Pod를 지원하며, 이 제한에는 업그레이드 중에 일시적으로 생성된 모든 Pod가 포함됩니다.

자세한 내용은, Azure CNI 오버레이에 대한 IP 주소 계획에 대한 지침을 참조 하세요.

기타 IP 주소 공간 고려 사항

이 아키텍처에 대한 전체 네트워킹 고려 사항은 AKS 기준 네트워크 토폴로지를 참조하세요. AKS 클러스터의 IP 주소 계획과 관련된 자세한 내용은 클러스터에 대한 IP 주소 지정 계획을 참조하세요.

AKS 기준 참조 아키텍처의 Windows 컨테이너에 포함된 IP 주소 계획 고려 사항에 대한 자세한 내용은 AKS의 Windows 컨테이너를 참조하세요.

추가 항목 및 미리 보기 기능

Kubernetes와 AKS는 온-프레미스 환경에 대한 소프트웨어보다 빠른 릴리스 주기를 통해 지속적으로 진화합니다. 이 기준 아키텍처는 선택된 AKS 미리 보기 기능과 AKS 추가 항목에 따라 달라집니다. 두 가지의 차이점은 다음과 같습니다:

• AKS 팀은 많은 미리 보기 기능이 일반 공급 (GA) 단계로 이동하기 전에 몇 달 동안만 해당 상태로 유지되기 때문에 미리 보기 기능이 배송되고 개선 되었다고 설명합니다.

• AKS 추가 기능 및 확장은 지원되는 추가 기능을 제공합니다. AKS는 설치, 구성, 수명 주기를 관리합니다.

이 기준 아키텍처에는 모든 미리 보기 기능 또는 추가 기능이 포함되지 않습니다. 대신 범용 클러스터에 중요한 값을 추가하는 항목만 포함합니다. 이러한 기능이 미리 보기에서 나오면, 기준 아키텍처가 그에 따라 수정됩니다. 사전 프로덕션 클러스터에서 평가할 수 있는 몇 가지 다른 미리 보기 기능 또는 AKS 추가 기능이 있습니다. 이러한 기능은 보안, 관리 효율성 또는 기타 요구 사항을 향상시킬 수 있습니다. 타사 추가 항목을 사용하면, 클러스터의 Kubernetes 버전을 업그레이드한 후 사용 가능한 버전 추적 및 업데이트 설치를 포함하여 설치하고 유지 관리해야 합니다.

컨테이너 이미지 참조

클러스터에는 워크로드 외에도 수신 컨트롤러와 같은 여러 다른 이미지가 포함될 수 있습니다. 이러한 이미지 중 일부는 퍼블릭 레지스트리에 상주할 수 있습니다. 이미지를 클러스터로 끌어올 때 이러한 점을 고려하세요.

• 클러스터는 인증하여 이미지를 끌어오세요.

• 공용 이미지를 사용하는 경우 서비스 수준 목표 (SLO)에 맞는 Container Registry로 공용 이미지를 가져옵니다. 그렇지 않으면, 이미지에 예기치 않은 가용성 문제가 발생할 수 있습니다. 필요할 때 이미지를 사용할 수 없는 경우 작동 문제가 발생할 수 있습니다. 공용 레지스트리 대신 Azure Container Registry와 같은 개인 컨테이너 레지스트리를 사용할 경우의 몇 가지 이점은 다음과 같습니다.

  • 이미지에 대한 무단 액세스를 차단할 수 있습니다.
  • 공용 종속성을 가지고 있지 않습니다.
  • 이미지 끌어오기 로그에 액세스하여 활동을 모니터링하고, 연결 문제를 심사할 수 있습니다.
  • 통합된 컨테이너 검사 및 이미지 규정 준수를 활용할 수 있습니다.

• 권한 있는 레지스트리에서 이미지를 끌어옵니다. Azure Policy를 통해 이 제한을 적용할 수 있습니다. 이 참조 구현에서 클러스터는 배포하는 Container Registry 인스턴스에서만 이미지를 가져옵니다.

기본 클러스터에 대한 컴퓨팅 구성

AKS에서 각 노드 풀은 가상 머신 확장 집합에 매핑됩니다. 노드는 각 노드 풀의 VM입니다. 비용을 최소화하기 위해 시스템 노드 풀에 더 작은 VM 크기를 사용하는 것이 좋습니다. 이 참조 구현은 세 개의 DS2_v2 노드가 있는 시스템 노드 풀을 배포합니다. 이 크기는 시스템 Pod의 예상 부하를 충족하기에 충분합니다. 운영 체제 디스크는 512 GB입니다.

사용자 노드 풀에 대한 몇 가지 고려 사항은 다음과 같습니다.

• 노드에 설정된 최대 Pod 수를 압축하려면 더 큰 노드 크기를 선택합니다. 대용량 노드는 모니터링 및 로깅과 같이 모든 노드에서 실행되는 서비스의 공간을 최소화합니다.

• 특정 워크로드 요구 사항이 있는 경우 적절한 VM 유형을 선택합니다. 예를 들어 일부 워크로드의 경우 메모리 최적화 제품이나 다른 워크로드의 경우 GPU 가속 제품이 필요할 수 있습니다. 자세한 내용은 Azure의 가상 머신 크기를 참조하세요.

• 두 개 이상의 노드를 배포합니다. 이렇게 하면 워크로드는 두 개의 복제본이 있는 고가용성 패턴을 갖게 됩니다. AKS를 사용하면 클러스터를 다시 만들지 않고 노드 수를 변경할 수 있습니다.

• 설계 팀에서 확정한 요구 사항을 토대로 실제 워크로드에 적합한 노드 크기를 계획하세요. 비즈니스 요구 사항에 따라 이 아키텍처는 프로덕션 워크로드에 대한 DS4_v2 를 사용합니다. 비용을 낮추려면, 최소 권장 사항인 DS3_v2로 크기를 줄일 수 있습니다.

• 클러스터의 용량을 계획할 때 워크로드가 각 노드의 최대 80%를 사용한다고 가정하세요. 나머지 20%는 AKS 서비스에 예약됩니다.

• 용량 계획에 따라 노드당 최대 Pod를 설정합니다. 용량 기준을 설정하려는 경우, 값은 30으로 시작합니다. 워크로드, 노드 크기 및 IP 제약 조건의 요구 사항에 따라 해당 값을 조정합니다.

운영 체제 선택

대부분의 AKS 클러스터는 해당 노드 풀에 대한 운영 체제로 Linux를 사용합니다. 이 참조 구현에서는 Azure용으로 조정된 가볍고 강화된 Linux 배포인 Azure Linux를 사용합니다. 원하는 경우 또는 Azure Linux에서 충족할 수 없는 요구 사항이 있는 경우 Ubuntu와 같은 다른 Linux 배포를 사용하도록 선택할 수 있습니다.

AKS는 Windows Server 운영 체제를 실행하는 노드 풀도 지원합니다. Windows를 실행하는 클러스터의 일부 측면에는 특별한 요구 사항이 있습니다. Windows 노드 풀 아키텍처에 대한 자세한 내용은 AKS에서 Windows 컨테이너 실행을 참조하세요.

기술이 혼합된 워크로드가 있는 경우 다른 노드 풀에서 다른 운영 체제를 사용할 수 있습니다. 그러나 워크로드에 다른 운영 체제가 필요하지 않은 경우 모든 워크로드의 노드 풀에 단일 운영 체제를 사용하는 것이 좋습니다.

클러스터용 Microsoft Entra ID 통합

클러스터에 대한 액세스를 보호하는 것은 매우 중요합니다. 보안 선택을 할 때 클러스터의 관점에서 생각해 보세요:

• 인사이드 아웃 액세스. 네트워킹 인프라, Azure Container Registry 및 Azure Key Vault와 같은 Azure 구성 요소에 대한 AKS 액세스를 고려하세요. 클러스터에 액세스할 수 있는 리소스에만 권한을 부여하세요.
• 아웃사이드 인 액세스. Kubernetes 클러스터에 대한 ID 액세스를 제공하세요. Kubernetes API 서버 및 Azure Resource Manager에 액세스할 수 있는 외부 엔터티에만 권한을 부여합니다.

Azure에 대한 AKS 액세스

Microsoft Entra ID를 통해 AKS에서 Azure로의 액세스를 관리하는 방법에는 서비스 주체 또는 Azure 리소스에 대한 관리 ID라는 두 가지 방법이 있습니다.

Azure에 대한 AKS 액세스를 관리하는 두 가지 방법 중에서 관리 ID를 권장합니다. 서비스 주체를 사용하면 수동 또는 프로그래밍 방식으로 비밀을 관리하고 회전해야 합니다. 그러나 관리 ID를 사용하면 Microsoft Entra ID가 인증 및 비밀의 시기 적절한 회전을 관리하고 수행합니다.

관리 ID를 사용하도록 설정하여 클러스터가 Microsoft Entra ID를 통해 외부 Azure 리소스와 상호 작용할 수 있도록 권장합니다. Microsoft Entra ID 통합을 바로 사용하지 않더라도 나중에 통합할 수 있습니다.

기본적으로 클러스터에서 사용하는 기본 ID는 클러스터 ID와 kubelet ID 두 가지입니다. AKS 컨트롤 플레인 구성 요소는 클러스터 ID 를 사용하여 수신 부하 분산 장치 및 AKS 관리 공용 IP를 포함한 클러스터 리소스를 관리합니다. kubelet ID는 Container Registry를 사용하여 인증합니다. 일부 추가 항목은 관리 ID로 인증을 지원합니다.

클러스터가 컨테이너 레지스트리에서 이미지를 가져와야 하는 경우 관리 ID를 사용해야 합니다. 이 작업을 수행하려면 클러스터가 레지스트리의 자격 증명을 가져와야 합니다. 관리 ID를 사용하지 않는 경우 해당 정보를 Kubernetes 비밀 개체 형식으로 저장하고 비밀을 검색하는 데 사용할 imagePullSecrets 수 있습니다. 이러한 접근 방식은 보안 복잡성 때문에 권장하지 않습니다. 비밀에 대한 사전 지식이 필요할 뿐만 아니라 DevOps 파이프라인 안에서 해당 비밀을 저장해야 합니다. 이 접근 방식을 권장하지 않는 또 다른 이유는 보안 암호의 교체를 관리하는 운영 오버헤드입니다. 대신 클러스터의 kubelet 관리 ID에 대한 AcrPull 액세스 권한을 레지스트리에 부여하세요. 이 방법은 문제를 해결합니다.

이 아키텍처에서 클러스터는 Microsoft Entra ID로 보호된 Azure 리소스에 액세스하고, 관리 ID를 지원하는 작업을 수행합니다. 클러스터가 수행하려는 작업에 따라 Azure 역할 기반 액세스 제어 (Azure RBAC) 및 권한을 클러스터의 관리 ID에 할당합니다. 클러스터는 Microsoft Entra ID에 대해 자체 인증을 한 다음 할당된 역할에 따라 액세스를 허용하거나 거부합니다. 다음은 Azure 기본 제공 역할이 클러스터에 할당된 참조 구현의 일부 예입니다.

• 네트워크 참가자 역할. 스포크 가상 네트워크를 제어하는 클러스터의 기능을 관리하세요. 이 역할 할당을 사용하면, AKS 클러스터 시스템 할당 ID가 내부 수신 컨트롤러 서비스에 대한 전용 서브넷과 함께 작동할 수 있습니다.

• 메트릭 게시자 역할 모니터링. Azure Monitor에 메트릭을 보내는 클러스터의 기능을 관리하세요.

• AcrPull 역할. 지정된 Azure Container Registry 인스턴스에서 이미지를 끌어오는 클러스터의 기능을 관리합니다.

클러스터 액세스

Microsoft Entra 통합은 외부 액세스에 대한 보안도 간소화합니다. 예를 들어, kubectl을 사용해 보는 것을 고려해보세요. 초기 단계로, az aks get-credentials 명령을 실행하여 클러스터의 자격 증명을 가져올 수 있습니다. Microsoft Entra ID는 클러스터 자격 증명을 가져올 수 있는 Azure 역할에 대해 사용자의 ID를 인증합니다. 자세한 내용은 사용 가능한 클러스터 역할 권한을 참조하세요.

AKS는 두 가지 방법으로 Microsoft Entra ID를 사용하여 Kubernetes 액세스를 지원합니다. 첫째 방법은 네이티브 Kubernetes RBAC 시스템과 통합된 ID 공급자로서 Microsoft Entra ID를 사용합니다. 다른 방법은 네이티브 Azure RBAC를 사용하여 클러스터 액세스를 제어합니다. 다음 섹션에서는 두 가지 접근 방식을 자세히 다룹니다.

Kubernetes RBAC를 Microsoft Entra ID와 연결

Kubernetes는 다음을 통해 RBAC를 지원합니다.

• 클러스터 전체 권한에 대해 Role 또는 ClusterRole 개체를 사용하여 정의한 사용 권한 집합.

• 작업 수행 권한이 있는 사용자 및 그룹을 할당하는 바인딩. RoleBinding 또는 ClusterRoleBinding 개체로 바인딩을 정의합니다.

Kubernetes에는 클러스터 관리자, 수정, 보기 등과 같은 몇 가지 기본 제공 역할이 있습니다. 이러한 역할을 Microsoft Entra 사용자 및 그룹에 바인딩하여 엔터프라이즈 디렉터리를 사용해 액세스를 관리합니다. 자세한 내용은 Microsoft Entra 통합으로 Kubernetes RBAC 사용을 참조하세요.

클러스터 및 네임스페이스 액세스에 대한 Microsoft Entra 그룹을 Microsoft Entra 액세스 검토에 포함해야 합니다.

Kubernetes 권한 부여에 Azure RBAC 사용

Kubernetes 네이티브 RBAC를 사용하는 대신, ClusterRoleBindings 및 RoleBindings 통합 Microsoft Entra 인증으로 권한 부여를 위해 Azure RBAC 및 Azure 역할 할당을 사용하는 것이 좋습니다. 이 방법은 클러스터에 대한 권한 부여 검사를 적용합니다. 이러한 역할을 관리 그룹, 구독 또는 리소스 그룹 범위까지도 할당할 수 있습니다. 그런 다음 범위 내의 모든 클러스터는 Kubernetes 클러스터의 개체에 액세스할 수 있는 권한이 있는 사용자와 관련하여 일관된 역할 할당 집합을 상속합니다.

자세한 내용은, Kubernetes 권한 부여를 위한 Azure RBAC를 참조하세요.

로컬 계정

AKS는 네이티브 Kubernetes 사용자 인증을 지원합니다. 이 방법을 사용하여 클러스터에 대한 사용자 액세스 권한을 제공하지 않는 것이 좋습니다. 이 방식은 인증서 기반이며 기본 ID 공급자 외부에서 수행되므로 중앙 집중식 사용자 액세스 제어 및 거버넌스를 어렵게 만듭니다. 항상 Microsoft Entra ID를 사용하여 클러스터에 대한 액세스를 관리하고 로컬 계정 액세스를 명시적으로 사용하지 않도록 클러스터를 구성합니다.

이 참조 구현에서는, 시스템이 클러스터를 배포할 때 로컬 클러스터 계정을 통한 액세스가 명시적으로 비활성화됩니다.

워크로드에 대한 Microsoft Entra ID 통합

전체 클러스터에 대해 Azure 시스템 할당 관리 ID를 보유하는 것과 유사하게 Pod 수준에서 관리 ID를 할당할 수 있습니다. 워크로드 ID를 사용하면 호스트된 워크로드가 Microsoft Entra ID를 통해 리소스에 액세스할 수 있습니다. 예를 들어 워크로드는 Azure Storage에 파일을 저장합니다. 이러한 파일에 액세스해야 하는 경우, Pod는 Azure 관리 ID로서 리소스에 대해 자체적으로 인증합니다.

이 참조 구현에서 Pod에 대한 관리 ID는 AKS의 Microsoft Entra 워크로드 ID는 Pod에 대한 관리 ID를 제공합니다. 이 방식은 Kubernetes와 기본 제공 기능을 통합하여 외부 ID 공급자와 페더레이션합니다. Microsoft Entra 워크로드 ID 페더레이션에 대한 자세한 내용은 워크로드 ID 페더레이션을 참조하세요.

네트워킹 모델 선택

AKS는 kubenet, CNI 및 Azure CNI 오버레이를 등 여러 네트워킹 모델을 지원합니다. CNI 모델은 고급 모델이며 성능이 높습니다. Pod 간에 통신할 때 CNI의 성능은 가상 네트워크에서 VM의 성능과 유사합니다. CNI는 또한 Azure 네트워크 정책을 사용할 수 있으므로 더 나은 보안 제어를 제공합니다. CNI 기반 네트워킹 모델을 사용하는 것이 좋습니다.

비 오버레이 모델에서, 모든 Pod는 서브넷 주소 공간에서 IP 주소를 가져옵니다. 동일한 네트워크(또는 피어링된 리소스) 내의 리소스는 해당 IP 주소를 통해 직접 Pod에 액세스할 수 있습니다. 네트워크 주소 변환 (NAT)는 해당 트래픽을 라우팅하는 데 필요하지 않습니다.

이 참조 구현에서는 노드에 대한 노드 풀 서브넷의 IP 주소만 할당하고 Pod IP에 대해 고도로 최적화된 오버레이 계층을 사용하는 Azure CNI 오버레이를 사용합니다. Azure CNI 오버레이는 다른 많은 방법보다 적은 수의 가상 네트워크 IP 주소를 사용하므로 IP 주소 제한 배포에 사용하는 것이 좋습니다.

모델에 대한 자세한 내용은 사용할 컨테이너 네트워킹 인터페이스 네트워크 모델 선택 및 kubenet와 을 Azure 컨테이너 네트워킹 인터페이스 네트워크 모델과 비교를 참조하세요.

수신 리소스 배포

Kubernetes 수신 리소스는 들어오는 트래픽을 라우팅 및 분배하여 클러스터에 분산합니다. 수신 리소스에는 두 파트가 있습니다.

• AKS에서 관리하는 내부 부하 분산 장치입니다. 부하 분산 장치는 개인 고정 IP 주소를 통해 수신 컨트롤러를 노출합니다. 인바운드 흐름을 수신하는 단일 연락 지점 역할을 합니다.

  이 아키텍처는 Azure Load Balancer를 사용합니다. Load Balancer는 수신 리소스 전용 서브넷의 클러스터 외부에 배치됩니다. Azure Application Gateway로부터 트래픽을 수신하며 해당 통신은 전송 계층 보안 (TLS)를 통해 제공됩니다. 인바운드 트래픽에 대한 TLS 암호화에 대한 더 자세한 내용은 수신 트래픽 흐름을 참조하세요.

• 수신 컨트롤러. 이 예에서는 Traefik을 사용합니다. 이는 클러스터의 사용자 노드 풀에서 실행되며, 내부 부하 분산 장치에서 트래픽을 수신하고, TLS를 종료하여 HTTP를 통해 워크로드 Pod에 전달합니다.

수신 컨트롤러는 클러스터의 중요 구성 요소입니다. 이 구성 요소를 구성할 때 다음 사항들을 고려합니다.

• 수신 컨트롤러를 디자인 결정의 일부로 특정 작업 범위로 제한합니다. 예를 들어 컨트롤러가 특정 워크로드를 실행하는 Pod와만 상호 작용하도록 허용할 수 있습니다.

• 동일한 노드에 복제본 배치를 피하여 부하를 분산하고 노드가 다운되는 경우 비즈니스 연속성 보장에 도움을 줍니다. 이 용도에 podAntiAffinity를 사용합니다.

• nodeSelectors를 사용하여 사용자 노드 풀에서만 Pod를 예약하도록 제한합니다. 이 설정은 워크로드 및 시스템 Pod를 분리합니다.

• 특정 엔터티가 수신 컨트롤러에 트래픽을 보내도록 하는 포트 및 프로토콜을 엽니다. 이 아키텍처에서, Traefik는 Azure Application Gateway에서만 트래픽을 수신합니다.

• 지정된 간격으로 Pod의 상태를 모니터링하는 readinessProbe 및 livenessProbe 설정을 구성하세요. 수신 컨트롤러는 Pod 상태를 나타내는 신호를 보내야 합니다.

• 특정 리소스에 대한 수신 컨트롤러의 액세스 및 특정 작업을 수행하는 기능을 제한하는 것이 좋습니다. 제한은 Kubernetes RBAC 권한을 통해 구현할 수 있습니다. 예를 들어, 이 아키텍처에서는 Kubernetes ClusterRole 개체의 규칙을 사용하여 서비스 및 엔드포인트를 감시, 가져오기 및 나열할 수 있는 권한이 Traefik에 부여되었습니다.

기준 참조 아키텍처에서 AKS의 Windows 컨테이너에 대한 수신 디자인에 대한 자세한 내용은 AKS의 Windows 컨테이너를 참조하세요.

라우터 설정

수신 컨트롤러는 경로를 사용하여 트래픽을 보낼 위치를 결정합니다. 경로는 트래픽이 수신되는 원본 포트 및 대상 포트와 프로토콜에 대한 정보를 지정합니다.

이 아키텍처의 예제는 다음과 같습니다.

Traefik는 Kubernetes 공급자를 사용하여 경로를 구성합니다. annotations, tls 및 entrypoints옵션은 경로가 HTTPS를 통해 제공될 것임을 나타냅니다. middlewares 옵션은 Azure Application Gateway 서브넷의 트래픽만 허용되도록 지정합니다. 클라이언트가 수락하는 경우 응답은 gzip 인코딩을 사용합니다. Traefik는 TLS 종료, 커뮤니케이션을 수행하므로 백 엔드 서비스와의 통신은 HTTP를 통해 수행됩니다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: aspnetapp-ingress
  namespace: a0008
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.class: traefik-internal
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.tls: "true"
    traefik.ingress.kubernetes.io/router.tls.options: default
    traefik.ingress.kubernetes.io/router.middlewares: app-gateway-snet@file, gzip-compress@file
spec:
  tls:
  - hosts:
      - bu0001a0008-00.aks-ingress.contoso.com
  rules:
  - host: bu0001a0008-00.aks-ingress.contoso.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: aspnetapp-service
            port:
              number: 80

네트워크 흐름 보안

이 아키텍처에서 네트워크 흐름에는 다음이 포함됩니다.

• 클라이언트에서 클러스터에서 실행되는 워크로드로의 수신 트래픽

• 클러스터의 Pod 또는 노드부터 외부 서비스까지의 송신 트래픽.

• Pod간의 Pod-Pod 트래픽. 이 트래픽에는 수신 컨트롤러와 워크로드 간의 통신이 포함됩니다. 워크로드가 클러스터에 배포된 여러 애플리케이션으로 구성된 경우 해당 애플리케이션 간 통신도 이 범주에 속합니다.

• 클라이언트와 Kubernetes API 서버 사이의 트래픽 관리.

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

이 아키텍처에는 모든 유형의 트래픽을 보호하는 여러 계층의 보안이 있습니다.

수신 트래픽 흐름

아키텍처는 클라이언트의 TLS 암호화 요청만 허용합니다. TLS v1.2는 제한된 암호화 집합으로 허용되는 최소 버전입니다. 서버 이름 표시 (SNI) 엄격한 일치가 활성화되었습니다. 엔드투엔드 TLS는 다음 다이어그램에 보듯이 두 개의 서로 다른 TLS 인증서를 사용하여 Application Gateway를 통해 설정됩니다.

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

1. 클라이언트는 도메인 이름에 HTTPS 요청을 보냅니다: bicycle.contoso.com. 해당 이름은 DNS A 레코드를 통해 Application Gateway의 공용 IP 주소에 연결됩니다. 이 트래픽은 클라이언트 브라우저와 게이트웨이 간의 트래픽을 검사하거나 변경할 수 없게 하기 위해 암호화됩니다.

2. Application Gateway에는 통합 웹 애플리케이션 방화벽이 있으며 bicycle.contoso.com 에 대한 TLS 핸드셰이크를 협상하여 보안 암호만 허용합니다. Application Gateway는 TLS 종료 지점으로, Application Gateway의 웹 애플리케이션 방화벽이 일반 텍스트 응답을 검사해야 하기 때문에 중요합니다. Key Vault는 TLS 인증서를 저장합니다. 클러스터는 Application Gateway와 통합된 사용자 할당 관리 ID를 사용하여 액세스합니다. 자세한 내용은 Key Vault 인증서를 사용한 TLS 종료를 참조하세요.

   Application Gateway는 웹 애플리케이션 방화벽 검사 규칙을 처리하고 트래픽을 구성된 백 엔드로 전달하는 라우팅 규칙을 실행합니다.

3. 트래픽이 Application Gateway에서 백 엔드로 이동하고, 내부 부하 분산 장치로 전달되면서 *.aks-ingress.contoso.com 에 대한 와일드카드인 다른 TLS 인증서로 다시 암호화됩니다. 이렇게 다시 암호화하면 안전하지 않은 트래픽이 클러스터 서브넷으로 전달되지 않도록 보장합니다.

4. 수신 컨트롤러는 부하 분산 장치를 통해 암호화된 트래픽을 수신합니다. 컨트롤러는 *.aks-ingress.contoso.com 에 대한 또 다른 TLS 종료 지점이며 HTTP를 통해 워크로드 Pod에 트래픽을 전달합니다. 인증서는 Key Vault에 저장되고 Container Storage Interface (CSI) 드라이버를 사용하여 클러스터에 탑재됩니다. 자세한 내용은 비밀 관리 추가를 참조하세요.

워크로드 Pod를 통해 모든 홉에서 엔드투엔드 TLS 트래픽을 구현할 수 있습니다. Pod-Pod 트래픽 보안을 결정할 때는 성능, 대기 시간 및 운영 효과를 측정해야 합니다. 적절한 제어 평면 RBAC 및 성숙한 소프트웨어 개발 수명 주기 사례를 사용하는 대부분의 단일 테넌트 클러스터의 경우 TLS가 수신 컨트롤러까지 암호화하고 Web Application Firewall로 보호하는 것으로 충분합니다. 이 방법은 네트워크 성능 저하로 인해 워크로드 관리 및 오버헤드의 오버헤드를 최소화합니다. 워크로드 및 규정 준수 요구 사항은 TLS 종료를 수행하는 위치를 결정합니다.

송신 트래픽 흐름

이 아키텍처에서는 클러스터의 모든 송신 트래픽이 Azure Firewall을 통해 통신하는 것이 좋습니다. 또는 사용자 고유의 유사한 네트워크 가상 어플라이언스도 사용할 수 있습니다. 네트워크 트래픽 검사를 제공하지 않으므로 Azure NAT Gateway 또는 HTTP 프록시와 같은 다른 송신 옵션을 사용하지 않는 것이 좋습니다. 제로 트러스트 제어 및 트래픽 검사 기능의 경우 클러스터의 모든 송신 트래픽이 Firewall을 통해 이동합니다. 사용자 정의 경로 (UDRs)을 사용하여 이 구성을 구현할 수 있습니다. 경로의 다음 홉은 Azure Firewall의 개인 IP 주소에 해당합니다. Azure Firewall은 송신 트래픽을 차단할지 허용할지를 결정합니다. 이 결정은 Azure Firewall에서 정의한 특정 규칙 또는 기본 제공 위협 인텔리전스 규칙에 따라 결정됩니다.

Azure Firewall 사용에 대한 대안으로 AKS의 HTTP 프록시 기능을 활용합니다. 클러스터에서 나가는 모든 트래픽은 HTTP 프록시의 IP 주소로 이동하여 트래픽을 전달하거나 삭제합니다.

어느 방식이던지, AKS에 필요한 송신 네트워크 트래픽 규칙 을 검토합니다.

클러스터가 다른 Azure 리소스와 통신이 필요한 경우, 제로 트러스트 컨트롤에 예외가 발생할 수 있습니다. 예를 들어, 클러스터는 컨테이너 레지스트리에서 업데이트된 이미지 또는 Key Vault 비밀을 가져와야 할 수 있습니다. 이러한 시나리오에서는 Private Link를 사용하는 것이 좋습니다. 특정 서브넷이 서비스에 직접 도달하여 클러스터와 서비스 간의 트래픽이 인터넷을 통해 이동하지 않는 이점이 있습니다. Private Link의 경우 퍼블릭 엔드포인트를 통해 대상 서비스를 사용하는 대신 추가 구성이 필요하다는 것이 단점입니다. 또한, 모든 Azure 서비스 또는 제품이 Private Link를 지원하지는 않습니다. 이러한 경우, 서비스에 액세스하려면 서브넷에서 가상 네트워크 서비스 엔드포인트 활성화를 고려해 보세요.

Private Link 또는 서비스 엔드포인트가 옵션이 아닌 경우, 퍼블릭 엔드포인트를 통해 다른 서비스에 연결하고 Azure Firewall 규칙 및 대상 서비스에 기본 제공되는 방화벽을 통해 액세스를 제어할 수 있습니다. 이 트래픽은 방화벽의 고정 IP 주소를 통과하기에, 해당 주소를 서비스의 IP 허용 목록에 추가할 수 있습니다. Azure Firewall에 추가 규칙을 두어 특정 서브넷의 트래픽만 허용하게 해야 한다는 것이 한 가지 단점입니다. Azure Firewall을 사용하여 송신 트래픽에 대한 여러 IP 주소를 계획할 때 해당 주소를 고려합니다. 그렇지 않으면 포트 소모에 도달할 수 있습니다. 여러 IP 주소 계획에 대한 자세한 내용은 여러 IP 주소가 있는 Azure Firewall 만들기를 참조 하세요.

AKS 기준 참조 아키텍처의 Windows 컨테이너에서 Windows 관련 송신 고려 사항에 대한 자세한 내용은 AKS의 Windows 컨테이너를 참조하세요.

Pod-Pod 트래픽

기본적으로 Pod는 클러스터의 모든 다른 Pod에서 트래픽을 허용할 수 있습니다. Kubernetes NetworkPolicy로 Pod 간의 네트워크 트래픽을 제한합니다. 정책은 신중하게 적용하세요, 그렇지 않으면 중요한 네트워크 흐름이 차단되는 상황이 발생할 수 있습니다. 수신 컨트롤러와 워크로드 간의 트래픽과 같이 필요에 따라 오직 특정 통신 경로만 허용합니다. 자세한 내용은 네트워크 정책을 참조하세요.

나중에 추가할 수 없으므로 클러스터가 프로비전될 때 네트워크 정책을 활성화하세요. NetworkPolicy을 구현하는 기술은 몇 가지 선택지가 있습니다. Azure 컨테이너 네트워킹 인터페이스 (CNI)가 필요한 Azure 네트워크 정책을 권장합니다. 자세한 내용은, 다음 Note를 참조하세요. 다른 옵션으로는 잘 알려진 오픈 소스 옵션인 Calico 네트워크 정책을 들 수 있습니다. 클러스터 전체 네트워크 정책을 관리해야 하는 경우 Calico가 좋습니다. Calico는 표준 Azure 지원이 적용되지 않습니다.

자세한 내용은 Azure 네트워크 정책 엔진 간의 차이점을 참조하세요.

관리 트래픽

클러스터 실행의 일부인 Kubernetes API 서버는, 리소스 만들기 또는 클러스터 스케일링 요청과 같이 클러스터에서 관리 작업을 수행하려는 리소스에서 트래픽을 수신합니다. 이러한 리소스의 예로는 DevOps 파이프라인의 빌드 에이전트 풀, Azure Bastion 서브넷 내의 Azure Bastion 인스턴스 및 노드 풀 자체가 있습니다. 모든 IP 주소에서 이 관리 트래픽을 수락하는 대신 AKS 인증 IP 범위 기능을 사용하여 권한 있는 IP 범위에서 API 서버로 오는 트래픽만 허용합니다.

자세한 내용은, API 서버 인증 IP 범위 정의를 참조하세요.

다른 제어 계층을 위해, 추가 복잡성의 비용으로 프라이빗 AKS 클러스터를 프로비저닝할 수 있습니다. 프라이빗 클러스터로, API 서버와 노드 풀 사이의 네트워크 트래픽이 인터넷에 절대 노출되지 않고 개인 네트워크에만 유지되도록 할 수 있습니다. 자세한 내용은, AKS 프라이빗 클러스터를 참조하세요.

비밀 관리 추가

Key Vault와 같은 관리형 키 저장소에 비밀을 저장합니다. 이점은 관리형 키 저장소가 비밀 회전을 처리한다는 것입니다. 강력한 암호화 및 액세스 감사 로그를 제공합니다. 또한 핵심 비밀을 배포 파이프라인에서 유지합니다. 이 아키텍처에서, Key Vault 방화벽이 활성화 및 구성되고, Private Link는 Azure 리소스에서 비밀 및 인증서에 액세스할 경우에 사용됩니다.

Key Vault는 다른 Azure 서비스와 잘 통합됩니다. 이러한 서비스의 기본 제공 기능을 사용하여 비밀에 액세스합니다. Application Gateway가 수신 흐름에 대한 TLS 인증서에 액세스하는 방법에 대한 더 많은 정보는 수신 트래픽 흐름 섹션을 참조하세요.

Key Vault에 대한 Azure RBAC 권한 모델을 사용하면 워크로드 ID를 Key Vault 비밀 사용자 또는 Key Vault 읽기 권한자 역할 할당에 배분하여 비밀에 액세스할 수 있습니다. 자세한 내용은, RBAC로 액세스 키 Vault를 참조하세요.

클러스터 비밀에 액세스하기

Pod가 특정 저장소에서 비밀에 액세스하도록 허용하려면 워크로드 ID를 사용해야 합니다. 검색 프로세스를 용이하게 하려면, 비밀 저장소 CSI 드라이버를 사용하세요. Pod에 비밀이 필요한 경우, 드라이버는 지정된 저장소와 연결하고, 볼륨에서 비밀을 검색하고, 클러스터에 해당 볼륨을 탑재합니다. 그런 다음 Pod는 볼륨 파일 시스템에서 비밀을 가져올 수 있습니다.

CSI 드라이버에는 다양한 관리 저장소를 지원하는 많은 공급자가 있습니다. 이 구현에서는 비밀 저장소 CSI 드라이버와 함께 Key Vault를 사용합니다. 추가 기능은 Key Vault에서 TLS 인증서를 검색하고 수신 컨트롤러를 실행하는 Pod에 드라이버를 로드합니다. 이 작업은 Pod를 만드는 동안 수행되며, 볼륨은 퍼블릭 키와 프라이빗 키를 모두 저장합니다.

워크로드 스토리지

이 아키텍처의 워크로드는 상태 비저장입니다. 상태를 저장해야 하는 경우, 클러스터 외부에 유지하는 것을 권장합니다. 워크로드 상태에 대한 참고 자료는 이 문서의 범위를 벗어납니다.

자세한 내용은 AKS의 애플리케이션에 대한 스토리지 옵션을 참조하세요.

정책 관리

AKS 클러스터를 관리하는 효과적인 방법은 정책으로 거버넌스를 적용하는 것입니다. 쿠버네티스는 Open Policy Agent (OPA) Gatekeeper를 통해 정책을 구현합니다. AKS의 경우, Azure Policy를 통해 정책을 제공합니다. 각 정책은 해당 범위의 모든 클러스터에 적용합니다. OPA Gatekeeper는 클러스터에서 정책 시행을 처리하고 모든 정책 검사를 기록합니다. 정책 변경 내용은 클러스터에 바로 반영되지 않으므로, 약간의 지연을 예상하세요.

AKS 클러스터를 관리하려면 Azure Policy를 사용하여 다음을 수행할 수 있습니다.

• 리소스 그룹 또는 구독에서 AKS 클러스터의 배포를 방지하거나 제한합니다. 조직에 대한 표준을 적용합니다. 예를 들어, 명명 규칙을 따르거나 태그를 지정할 수 있습니다.
• Kubernetes용 Azure Policy를 통해 AKS 클러스터를 보호합니다.

정책을 설정할 때 워크로드의 요구 사항에 따라 정책을 적용합니다. 다음 항목을 고려합니다.

• 이니셔티브라고 하는 정책 컬렉션 설정 또는 개별 정책 선택 중 무엇을 원하시나요? Azure Policy는 기본 및 제한이라는 두 가지 기본 제공 이니셔티브를 제공합니다. 각 이니셔티브는 AKS 클러스터에 적용되는 기본 제공 정책의 컬렉션입니다. 이니셔티브를 및 를 선택하고 클러스터와 상호 작용하는 클러스터 및 Container Registry, Application Gateway 혹은 Key Vault 등의 리소스에 대한 다른 정책을 선택하는 것이 좋습니다. 조직의 요구 사항에 따라 정책을 선택합니다.

• 작업을 감사하거나 거부하고 싶은가요? 감사 모드에서는, 작업이 허용되지만 비규격으로 플래그가 지정됩니다. 정기적인 주기로 비규격 상태를 확인하고 필요한 조치를 취하는 프로세스가 있어야 합니다. 거부 모드에서는 정책이 위반되므로 작업이 차단됩니다. 워크로드가 작동하기에는 지나치게 제한적일 수 있으므로 이 모드를 선택할 때는 주의해야 합니다.

• 워크로드에 설계상 규정을 준수하지 않아야 하는 영역이 있나요? Azure Policy는 정책 적용으로부터 제외되는 Kubernetes 네임스페이스를 지정하는 기능이 있습니다. 감사 모드에서도 정책을 계속 적용하여 해당 인스턴스를 인식하는 것을 권장합니다.

• 기본 제공 정책에서 다루지 않는 요구 사항이 있습니까? 사용자 지정 OPA Gatekeeper 정책을 적용하는 사용자 지정 Azure Policy 정의를 만들 수 있습니다. 사용자 지정 정책을 클러스터에 직접 적용하지 마세요. 자세한 내용은, 사용자 지정 정책 정의 만들기 및 할당을 참조하세요.

• 조직 전체 요구 사항이 있나요? 있는 경우 관리 그룹 수준에서 해당 정책을 추가합니다. 조직에 일반 정책이 있더라도 클러스터에서 자체 워크로드별 정책을 할당해야 합니다.

• Azure 정책을 특정 범위에 할당합니까? 프로덕션 정책이 사전 프로덕션 환경에 대해서도 유효성 검사가 되도록 해야 합니다. 그렇지 않으면 프로덕션 환경에 배포할 때, 사전 프로덕션에서 고려되지 않은 예기치 않은 추가 제한이 발생할 수 있습니다.

이 참조 구현은 AKS 클러스터를 만들 때 Azure Policy를 사용하도록 설정합니다. 제한 이니셔티브는 비준수에 대한 가시성을 얻기 위해 감사 모드로 할당됩니다.

구현은 기본 제공 이니셔티브에 포함되지 않은 추가 정책을 설정합니다. 이러한 정책은 거부 모드로 설정됩니다. 예를 들어, 배포된 Container Registry 인스턴스에서만 이미지를 끌어오도록 하는 정책이 있습니다. 고유의 사용자 지정 이니셔티브를 만드는 것이 좋습니다. 워크로드에 적용 가능한 정책을 단일 할당으로 결합합니다.

클러스터 내에서 Azure Policy 기능이 작동하는 방식을 관찰하려면 gatekeeper-system네임스페이스의 모든 Pod에 대한 Pod 로그azure-policy 와 azure-policy-webhook네임스페이스의 Podkube-system에 대한 로그에 액세스할 수 있습니다.

Windows 관련 Azure Policy 고려 사항에 대한 자세한 내용은 AKS 정책 관리 문서의 Windows 컨테이너를 참조하세요.

노드 및 Pod 스케일링 성능

수요가 증가하면, Kubernetes는 수평 Pod 자동 스케일링을 통해 기존 노드에 더 많은 Pod를 추가하여 스케일 아웃할 수 있습니다. Kubernetes가 추가 Pod를 더 이상 예약할 수 없는 경우, AKS 클러스터 자동 스케일링을 통해 노드 수를 늘려야 합니다. 전체 스케일링 솔루션에는 Pod 복제본과 클러스터의 노드 수를 모두 스케일링하는 방법이 있어야 합니다.

자동 스케일링 또는 수동 스케일링의 두 가지 방법이 있습니다.

자동 크기 조정 및 수동 접근 방식 모두 CPU 사용량 또는 사용자 지정 메트릭에 대한 경고를 모니터링하고 설정해야 합니다. Pod 스케일링의 경우, 애플리케이션 운영자는 Kubernetes API를 통해 ReplicaSet를 조정하여 Pod 복제본 수를 늘리거나 줄일 수 있습니다. 클러스터 스케일링을 위한 한 가지 방법은, Kubernetes 스케줄러가 실패할 때 알림을 받는 것입니다. 또 다른 방법은 시간 경과하면서 보류 중인 Pod를 감시하는 것입니다. Azure CLI 또는 Azure 포털을 통해 노드 수를 조정할 수 있습니다.

이러한 수동 메커니즘 중 일부가 자동 스케일러에 기본으로 탑재되기 때문에 자동 스케일링을 권장합니다.

일반적인 접근 방식은, 최소 개수의 Pod 및 노드를 사용하는 성능 테스트부터 시작합니다. 이러한 값을 사용하여 기준 기대치를 설정합니다. 그런 다음, 성능 메트릭과 수동 스케일링의 조합을 사용하여 병목 상태를 찾고 스케일링에 대한 애플리케이션의 응답을 파악합니다. 마지막으로 이 데이터를 사용하여 자동 스케일링에 대한 매개 변수를 설정합니다. AKS를 사용하는 성능 튜닝 시나리오에 대한 자세한 내용은, 성능 튜닝 시나리오: 분산 비즈니스 트랜잭션을 참조하세요.

Horizontal Pod Autoscaler

HPA(Horizontal Pod Autoscaler)는 Pod 수를 스케일링하는 Kubernetes 리소스입니다.

HPA 리소스에서 최소 및 최대 복제본 수를 설정하는 것을 권장합니다. 이 값은 자동 스케일링 범위를 제한합니다.

HPA는 CPU 사용률, 메모리 사용량, 및 사용자 지정 메트릭을 기준으로 스케일링할 수 있습니다. CPU 사용률만 기본으로 제공됩니다. 정의는 HorizontalPodAutoscaler 메트릭의 대상 값을 지정합니다. 예를 들어 사양은 대상 CPU 사용량을 설정합니다. Pod가 실행되는 동안, HPA 컨트롤러는 Kubernetes 메트릭 API를 사용하여 각 Pod의 CPU 사용률을 확인합니다. 해당 값을 대상 사용률과 비교하여 비율을 계산합니다. 그런 다음 비율을 사용하여 Pod가 초과 할당되었는지 또는 과소 할당되었는지를 결정합니다. Kubernetes 스케줄러를 사용하여 노드에 새 Pod를 할당하거나 노드에서 Pod를 제거합니다.

스케일링 작업이 완료되기 전에 HPA가 확인하는 경합 상태가 있을 수 있습니다. 그 결과 비율 계산이 잘못될 수 있습니다. 자세한 정보는 조정 이벤트의 휴지를 참조하세요.

워크로드가 이벤트 기반인 경우 인기 있는 오픈 소스 옵션은 Kubernetes 기반의 이벤트 구동 자동 크기 조정 (KEDA)입니다. 워크로드가 CPU 또는 메모리 바인딩이 아니고 메시지 큐와 같은 이벤트 원본에 의해 구동되는 경우 KEDA를 고려해보세요. KEDA는 많은 이벤트 원본 또는 스케일러를 지원합니다. KEDA가 KEDA 스케일러에서 확장할 수 있는 이벤트 원본 목록을 사용합니다. 이 목록에는 Azure Monitor 메트릭을 기반으로 KEDA 워크로드의 크기를 조정하는 편리한 방법인 Azure Monitor 스케일러가 포함되어 있습니다.

클러스터 자동 크기 조정기

클러스터 자동 스케일러는 노드 풀의 노드 수를 스케일링하는 AKS 추가 항목 구성 요소입니다. 클러스터 프로비전 중에 추가합니다. 각 사용자 노드 풀에 대해 별도의 클러스터 자동 스케일러가 필요합니다.

Kubernetes 스케줄러는 클러스터 자동 스케일러를 트리거합니다. 리소스 제약 조건으로 인해 Kubernetes 스케줄러가 Pod를 예약하지 못하면 자동 스케일러는 노드 풀에 새 노드를 자동으로 프로비전합니다. 반대로 클러스터 자동 스케일러는 노드의 사용되지 않는 용량을 확인합니다. 노드가 예상 용량으로 실행되지 않는 경우 Pod는 다른 노드로 이동되고 사용되지 않는 노드는 제거됩니다.

자동 스케일러를 활성화하면 최대 및 최소 노드 수를 설정합니다. 권장 값은 워크로드의 성능 기대치, 늘리려는 클러스터의 양 및 비용 영향에 따라 달라집니다. 최소 수는 해당 노드 풀에 대한 예약된 용량입니다. 이 참조 구현에서는, 워크로드의 간단한 특성으로 인해 최소값이 2로 설정됩니다.

시스템 노드 풀의 경우, 권장되는 최소값은 3입니다.

이 기준 참조 아키텍처에 포함된 Windows 관련 크기 조정 고려 사항에 대한 자세한 내용은 AKS 문서의 Windows 컨테이너를 참조하세요.

비즈니스 연속성 결정

비즈니스 연속성을 유지하려면 인프라 및 애플리케이션에 대한 SLO를 정의하세요. 자세한 내용은 안정성 목표를 정의하기 위한 권장 사항을 참조하세요. 온라인 서비스에 대한 최신 SLA 문서에서 AKS에 대한 서비스 수준 계약 (SLA) 조건을 검토하세요.

클러스터 노드

워크로드에 대한 최소 가용성 수준을 충족하려면, 노드 풀에 여러 노드가 필요합니다. 한 노드가 실패하면, 동일한 클러스터의 노드 풀에 있는 다른 노드 및 클러스터가 애플리케이션을 계속 실행할 수 있습니다. 안정성을 위해 시스템 노드 풀에 3개의 노드를 권장합니다. 사용자 노드 풀의 경우, 두 개 이하의 노드로 시작합니다. 더 높은 가용성이 필요한 경우 더 많은 노드를 프로비전합니다.

애플리케이션을 사용자 노드 풀이라고 하는 별도의 노드 풀에 배치하여 시스템 서비스에서 격리합니다. 이렇게 하면 Kubernetes 서비스는 전용 노드에서 실행되며 다른 워크로드와 경쟁하지 않습니다. 태그, 레이블 및 taint를 사용하여 워크로드를 예약할 노드 풀을 식별하는 것을 권장합니다. 시스템 노드 풀이 CriticalAddonsOnly taint로CriticalAddonsOnly오염되었는지 확인합니다.

제때에 업데이트 등 클러스터의 정기적인 유지 관리는 안정성에 매우 중요합니다. 또한 프로브를 통해 Pod의 상태를 모니터링하는 것을 권장합니다.

Pod 가용성

Pod 리소스 요구 사항 지정: 배포에 Pod 리소스 요구 사항을 지정하는 것을 권장합니다. 그러면 스케줄러가 Pod를 적절하게 예약할 수 있습니다. Pod를 예약할 수 없는 경우 안정성이 크게 감소합니다.

Pod 중단 예산 설정: 이 설정은 업데이트 또는 업그레이드 이벤트 중에 중단할 수 있는 배포의 복제본 수를 결정합니다. 자세한 내용은 Pod 중단 예산을 참조하세요.

하드웨어 오류와 같은 중단을 처리하도록 배포에 여러 복제본을 구성합니다. 업데이트 및 업그레이드와 같은 계획된 이벤트의 경우, 중단 예산은 예상된 애플리케이션 부하를 처리하는 데 필요한 Pod 복제본 수가 있는지 확인할 수 있습니다.

워크로드 네임스페이스에 대한 리소스 할당량 설정: 네임스페이스의 리소스 할당량을 사용하면 배포에서 Pod 요청 및 제한이 올바르게 설정되도록 할 수 있습니다. 자세한 내용은 리소스 할당량 적용을 참조하세요.

Pod 요청 및 제한 설정: 요청 및 제한을 설정하면 Kubernetes에서 CPU 및 메모리 리소스를 Pod에 효율적으로 할당할 수 있으며 노드에서 컨테이너 밀도를 높일 수 있습니다. 요청 및 제한은 하드웨어 사용량 향상으로 인해 비용을 줄이면서 안정성을 높일 수도 있습니다.

워크로드 한도를 추정하려면 기준을 테스트하고 설정하세요. 요청 및 제한에 대해 동일한 값으로 시작합니다. 그런 다음, 클러스터에서 불안정을 일으킬 수 있는 임계값을 설정할 때까지 해당 값을 점진적으로 튜닝합니다.

배포 매니페스트에서 요청 및 제한을 지정할 수 있습니다. 자세한 내용은 Pod 요청 및 한도 설정을 참조하세요.

가용성 영역 및 다중 지역 지원

일부 유형의 중단으로부터 보호하려면 지역에서 지원하는 경우 가용성 영역을 사용합니다. 그러면 컨트롤 플레인 구성 요소와 노드 풀의 노드가 모두 영역에 걸쳐 분산될 수 있습니다. 전체 영역을 사용할 수 없는 경우에도 지역 내의 다른 영역에 있는 노드는 계속 사용할 수 있습니다. 각 노드 풀은 노드 인스턴스 및 스케일링 성능을 관리하는 별도의 가상 머신 확장 집합에 매핑됩니다. AKS 서비스는 확장 집합 작업 및 구성을 관리합니다. 여러 영역을 사용하도록 설정할 때 고려해야 할 몇 가지 사항은 다음과 같습니다.

• 전체 인프라: 가용성 영역을 지원하는 지역을 선택합니다. 자세한 내용은 제한 사항을 참조하세요. 가동 시간 SLA를 사용하려면 표준 또는 프리미엄 계층을 선택해야 합니다. 가용성 영역을 사용하면 작동 시간 SLA가 더 커집니다.

• 클러스터: 노드 풀을 만들 때만 가용성 영역을 설정할 수 있습니다. 이들은 추후에 변경할 수 없습니다. 예상되는 분산이 가능하도록 노드 크기가 모든 영역에서 지원되어야 합니다. 기본 가상 머신 확장 집합은 영역 전체에서 동일한 하드웨어 구성을 제공합니다.

  다중 영역 지원은 노드 풀뿐 아니라, 컨트롤 플레인에도 적용됩니다. AKS 컨트롤 플레인은 노드 풀처럼 요청된 영역에 걸쳐 있습니다. 클러스터에서 영역 지원을 사용하지 않는 경우, 컨트롤 플레인 구성 요소가 가용성 영역에 분산되는 것이 보장되지 않습니다.

• 종속 리소스: 전체 영역 혜택을 위해 모든 서비스 종속성도 영역을 지원해야 합니다. 종속 서비스가 영역을 지원하지 않는 경우, 영역 오류로 인해 해당 서비스가 실패할 수 있습니다.

  예를 들어, 관리 디스크는 프로비전이 완료된 영역에서 사용할 수 있습니다. 오류가 발생할 경우, 노드는 다른 영역으로 이동할 수 있지만 관리 디스크는 노드와 함께 해당 영역으로 이동하지 않습니다.

이 아키텍처의 편의성을 고려하여, AKS는 가용성 영역 1, 2 및 3에 걸친 노드 풀이 포함된 단일 지역에 배포됩니다. Azure Firewall 및 Application Gateway와 등의 인프라의 다른 리소스도 다중 영역 지원을 사용하여 동일한 지역에 배포됩니다. 지역에서 복제는 Container Registry에 사용할 수 있습니다.

다중 영역

가용성 영역을 사용하도록 설정하면 전체 지역이 실패할 가능성이 낮은 이벤트에서는 적용 범위가 충분하지 않습니다. 더 높은 가용성을 얻으려면 여러 지역에서 여러 AKS 클러스터를 실행해야 합니다.

• 쌍을 이루는 지역을 사용할 수 있는 경우 선호합니다. 쌍을 이루는 지역을 사용할 경우의 이점은 플랫폼 업데이트 동안의 안정성입니다. Azure에서 한 번에 쌍의 한 지역만 업데이트되도록 합니다. 일부 지역에는 쌍이 없습니다. 지역이 페어링되지 않은 경우에도 사용할 다른 지역을 선택하여 다중 지역 솔루션을 배포할 수 있습니다. 지역 오류로부터 복구를 오케스트레이션하도록 구성하는 지속적인 통합 및 지속적인 업데이트 (CI/CD) 파이프라인을 사용하는 것이 좋습니다. Flux와 같은 특정 DevOps 도구를 사용하면 더 간편하게 여러 지역에 배포할 수 있습니다.

• Azure 리소스가 지역 복제를 지원하는 경우, 중복 서비스가 보조 지역을 가지는 위치를 제공합니다. 예를 들어 Container Registry에 지역에서 복제를 사용하도록 설정하면 선택한 Azure 지역에 이미지가 자동으로 복제됩니다. 또한 주 지역에서 중단이 발생하는 경우에도 이미지에 계속 액세스할 수 있습니다.

• 요구 사항에 따라 영역 또는 지역에 트래픽을 분산할 수 있는 트래픽 라우터를 선택합니다. 이 아키텍처는 영역 간에 비 웹 트래픽을 분산할 수 있으므로 Load Balancer를 배포합니다. 지역 간에 트래픽을 분산해야 하는 경우, Azure Front Door를 고려해보세요. 기타 다른 선택 사항은, 부하 분산 장치 선택을 참조하세요.

재해 복구

주 지역에서 오류가 발생하는 경우 다른 지역에 새 인스턴스를 빠르게 만들 수 있습니다. 몇 가지 권장 사항입니다.

• 다중 영역 사용하기. 주 지역에 쌍을 이루는 지역이 있는 경우 해당 쌍을 사용합니다. 그렇지 않은 경우 데이터 상주 및 대기 시간 요구 사항에 따라 지역을 선택합니다.

• 효율적으로 복제할 수 있는 비정상 워크로드를 사용합니다. 권장하지 않지만 클러스터에 상태를 저장해야 하는 경우, 다른 지역에서 데이터를 자주 백업해야 합니다.

• 다른 지역에 복제와 같은 복구 전략을 DevOps 파이프라인의 일부로 통합하여 SLO를 충족하세요.

• 재해 복구를 지원하는 기능으로 각 Azure 서비스를 프로비전하세요. 예를 들어, 이 아키텍처에서는 지역에서 복제를 위해 Container Registry가 활성화됩니다. 지역이 실패한 경우에도, 복제된 지역에서 이미지를 끌어올 수 있습니다.

• AKS 클러스터 및 필요한 기타 구성 요소를 포함하여 인프라를 코드로 배포합니다. 다른 지역에 배포해야 하는 경우 스크립트 또는 템플릿을 다시 사용하여 동일한 인스턴스를 만들 수 있습니다.

클러스터 백업

많은 아키텍처의 경우 새 클러스터를 프로비전하고 Git 작업 기반 클러스터 부트스트래핑을 통해 운영 상태로 되돌리고 애플리케이션 배포를 수행할 수 있습니다. 그러나 부트스트래핑 프로세스 내에서 캡처할 수 없는 구성 맵, 작업 및 비밀과 같은 중요한 리소스 상태가 있는 경우 복구 전략을 고려합니다. Kubernetes에서 상태 비스테이스 워크로드를 실행하는 것이 좋습니다. 아키텍처에 디스크 기반 상태가 포함된 경우 해당 콘텐츠에 대한 복구 전략도 고려해야 합니다.

클러스터 백업이 복구 전략의 일부여야 하는 경우 클러스터 내에서 비즈니스 요구 사항과 일치하는 솔루션을 설치해야 합니다. 이 에이전트는 Azure 디스크 기반 영구 볼륨 스냅샷을 선택하고 조정하는 대상으로 클러스터 리소스 상태를 푸시합니다.

VMware Velero 는 직접 설치하고 관리할 수 있는 일반적인 Kubernetes 백업 솔루션의 예입니다. 또는 AKS 백업 확장으로 관리되는 Velero 구현을 제공할 수 있습니다. AKS 백업 확장은 Azure Backup에서 자격 증명 모음 구성으로 외부화된 일정 및 백업 범위를 사용하여 Kubernetes 리소스와 영구 볼륨을 모두 백업할 수 있습니다.

참조 구현은 백업을 구현하지 않습니다. 여기에는 관리, 모니터링, 구매 및 보안을 위한 추가 Azure 리소스가 포함됩니다. 이러한 리소스에는 Azure Storage 계정, Azure Backup 자격 증명 모음 및 구성 및 신뢰할 수 있는 액세스 기능이 포함될 수 있습니다. 대신 상태 비지정 워크로드를 실행하려는 의도와 결합된 Git 작업은 복구 솔루션입니다.

정의된 복구 지점 목표 및 복구 시간 목표를 포함하여 비즈니스 목표를 충족하는 백업 솔루션을 선택하고 유효성을 검사합니다. 팀 Runbook에서 복구 프로세스를 정의하고 모든 중요 비즈니스용 워크로드에 대해 연습합니다.

Kubernetes API 서버 SLA

AKS를 무료 서비스로 사용할 수 있지만, 해당 계층은 재정적으로 지원되는 SLA를 제공하지 않습니다. SLA를 가져오려면 표준 계층을 선택해야 합니다. 모든 프로덕션 클러스터는 표준 계층을 사용하는 것이 좋습니다. 사전 프로덕션 클러스터에 대해 무료 계층을 예약하고 중요 업무용 워크로드 에 대해서만 프리미엄 계층을 예약합니다 . Azure 가용성 영역을 사용하는 경우 Kubernetes API 서버 SLA가 더 높습니다. 노드 풀 및 기타 리소스는 자체 SLAs로 처리됩니다. 각 서비스에 대한 특정 SLA에 대한 자세한 내용은 온라인 서비스 SLA를 참조하세요.

절충

영역 및 특히 지역에 걸쳐 아키텍처를 배포할 때 비용 대 가용성의 상충 관계가 있습니다. Container Registry의 지역에서 복제와 같은 일부 복제 기능은 더 비싼 프리미엄 SKU에서 제공됩니다. 다중 지역 배포의 경우 트래픽이 지역 간에 이동할 때 대역폭 요금이 적용되므로 비용도 증가합니다.

또한 영역 또는 지역 사이의 노드 통신에 추가 네트워크 대기 시간도 예상됩니다. 이러한 아키텍처 결정이 워크로드에 미치는 효과를 측정합니다.

시뮬레이션 및 강제 장애 조치(failover)로 테스트

시뮬레이션된 중단으로 강제 장애 조치 테스트를 통해 솔루션의 안정성을 테스트합니다. 시뮬레이션에는 노드 중지, 영역 실패를 시뮬레이션하기 위해 특정 영역의 모든 AKS 리소스 중단 또는 외부 종속성 실패 호출이 포함될 수 있습니다. Azure Chaos Studio로 Azure와 클러스터에서 다양한 유형의 중단을 시뮬레이션할 수도 있습니다.

자세한 내용은 Chaos Studio를 참조하세요.

로그 및 메트릭 모니터링 및 수집

Azure Monitor 컨테이너 인사이트는 이벤트를 실시간으로 볼 수 있어서 컨테이너 워크로드의 성능을 모니터링하는 데 권장되는 도구입니다. 실행 중인 Pod에서 컨테이너 로그를 캡처하고 집계하여 볼 수 있습니다. 메모리 및 CPU 사용률에 대한 메트릭 API에서 정보도 수집하여 실행 중인 리소스 및 워크로드의 상태를 모니터링합니다. 컨테이너 인사이트를 Pod를 스케일링할 때 성능을 모니터링하는 데도 사용할 수 있습니다. 여기에는 수집된 데이터의 모니터링, 분석 및 시각화에 중요한 원격 분석이 포함됩니다. 컨테이너 인사이트는 추세를 식별하고 중요한 문제에 대한 사전 알림을 받도록 경고를 구성할 수 있습니다.

ContainerLogV2 로그 스키마 간소화된 접근 방식으로 Kubernetes Pod에서 컨테이너 로그를 캡처하도록 설계되었습니다. 로그 항목은 Azure Log Analytics 작업 영역의 ContainerLogV2 테이블에 통합됩니다.

Pod에서 호스트되는 대부분의 워크로드는 Prometheus 메트릭을 내보냅니다. 컨테이너 인사이트는 Prometheus와 통합할 수 있습니다. 노드 및 Kubernetes에서 수집된 애플리케이션 및 워크로드 메트릭을 볼 수 있습니다.

일부 비 Microsoft 솔루션은 Datadog, Grafana 또는 New Relic과 같은 Kubernetes와 통합됩니다. 따라서 조직에서 이미 이러한 솔루션을 사용하는 경우 이러한 솔루션을 활용할 수 있습니다.

AKS를 사용하여 Azure는 핵심 Kubernetes 서비스 중 일부를 관리합니다. Azure는 AKS 컨트롤 플레인 구성 요소에 대한 로그를 리소스 로그로 구현합니다. 대부분의 클러스터에서 다음 옵션을 사용하도록 설정하는 것이 좋습니다. 이 옵션은 클러스터 문제를 해결하는 데 도움이 될 수 있으며 로그 밀도가 상대적으로 낮습니다.

• ClusterAutoscaler: 로깅을 사용하여 크기 조정 작업에 대한 가시성을 얻습니다. 자세한 내용은 클러스터 자동 스케일러 로그 및 상태 검색을 참조하세요.
• KubeControllerManager: Kubernetes와 Azure 컨트롤 플레인 간의 상호 작용에 대한 가시성 확보
• kube-audit-admin: 클러스터를 수정하는 활동에 대한 가시성을 확보. kube-audit 및 kube-audit-admin 모두를 활성화할 필요는 없습니다. kube-audit 는 수정되지 않은 (읽기) 작업도 포함하는 상위 집합 kube-audit-admin 입니다.
• guard: Microsoft Entra ID 및 Azure RBAC 감사를 캡처합니다.

초기 클러스터 또는 워크로드 수명 주기 개발 중에 KubeScheduler 혹은 KubeScheduler , 등의 다른 로그 범주를 사용하도록 설정하는 것이 유용할 수 있습니다. 추가된 클러스터 자동 크기 조정, Pod 배치 및 예약 및 유사한 데이터는 클러스터 또는 워크로드 작업 문제를 해결하는 데 도움이 될 수 있습니다. 문제 해결 요구 사항이 끝난 후에도 확장된 문제 해결 로그를 항상 켜짐 상태로 유지하면, Azure Monitor에 수집하고 저장하는 데 불필요한 비용이 발생할 수 있습니다.

Azure Monitor에는 시작할 기존 로그 쿼리 집합이 포함되어 있으며 이를 기본으로 사용하여 사용자 고유의 쿼리를 빌드할 수도 있습니다. 라이브러리가 증가함에 따라 하나 이상의 쿼리 팩으로 로그 쿼리를 저장하고 다시 사용할 수 있습니다. 쿼리의 사용자 지정 라이브러리는 AKS 클러스터의 상태 및 성능에 더 많은 가시성을 제공합니다. SLO 달성을 지원합니다.

AKS 모니터링 모범 사례에 대한 자세한 내용은 Azure Monitor로 AKS 모니터링 하기를 참조하세요.

Windows 관련 모니터링 고려 사항에 대한 자세한 내용은 AKS의 Windows 컨테이너를 참조하세요.

네트워크 메트릭

기본 클러스터 수준 네트워킹 메트릭은 네이티브 플랫폼 및 Prometheus 메트릭을 통해 사용할 수 있습니다. 또한 AKS 네트워크 관찰성을 사용하여 Prometheus 메트릭을 사용하여 노드 수준에서 네트워크 메트릭을 노출할 수 있습니다. 대부분의 클러스터에는 추가 네트워크 문제 해결 기능을 제공하고 노드 수준에서 예기치 않은 네트워크 사용량 또는 문제를 감지하기 위한 네트워크 관찰 기능이 포함되어야 합니다.

참조 구현은 일부 네트워크 관련 메트릭도 수집하는 Azure Monitor 컨테이너 인사이트를 사용합니다. 참조 구현은 Azure Monitor 컨테이너 인사이트에서 메트릭 수집을 사용하지 않도록 설정하고 대신 관리되는 Prometheus와 함께 Azure Monitor 작업 영역을 사용하여 네트워크 관찰성 메트릭을 수집합니다.

전송 제어 프로토콜 (TCP) 또는 사용자 데이터그램 프로토콜 (UDP) 패킷 손실, 대기 시간 또는 DNS 압력에 매우 중요한 워크로드의 경우 Pod 수준 네트워크 메트릭이 중요합니다. AKS에서는 고급 네트워크 관찰 기능으로 해당 수준의 세부 정보를 찾을 수 있습니다. 대부분의 워크로드에는 이러한 깊이의 네트워크 가시성이 필요하지 않습니다. Pod가 패킷 수준까지 민감도를 낮추어 고도로 최적화된 네트워크를 요구하지 않는 한 고급 네트워크 관찰성을 사용하도록 설정해서는 안 됩니다.

로깅에 대한 비용 최적화

참조 구현은 기본 계획을 시작점으로 사용하도록 ContainerLogV2 테이블을 구성합니다. 컨테이너용 Microsoft Defender 및 참조 구현을 위해 만든 경고는 이 테이블을 쿼리하지 않으므로 기본 계획은 수집 비용을 절감하므로 비용 효율적일 수 있습니다.

로그 볼륨 및 쿼리 요구 사항이 진화함에 따라 요구 사항에 가장 비용 효율적인 테이블 계획을 선택합니다. 쿼리가 테이블 데이터를 자주 검색하는 읽기 집약적인 솔루션이 되면 기본 분석 계획이 더 적합할 수 있습니다. 분석 계획은 쿼리 요금이 제거되어 쿼리 작업이 수집 비용보다 큰 시나리오에 최적화됩니다. 사용 패턴을 모니터링하고 필요에 따라 테이블 계획을 조정하면 모니터링 솔루션의 비용과 기능 간에 균형을 맞출 수 있습니다.

자세한 내용은 Log Analytics 작업 영역데이터 사용량을 기반으로 테이블 계획 선택을 참조하세요.

자동 복구 사용

활동성 및 준비 상태 프로브를 설정하여 Pod 상태를 모니터링하세요. Kubernetes가 응답하지 않는 Pod를 감지하면, Pod를 다시 시작합니다. 활동성 프로브는 Pod가 정상 상태인지 결정합니다. Kubernetes가 응답하지 않는 Pod를 감지하면, Pod를 다시 시작합니다. 준비 상태 프로브는 Pod가 요청 및 트래픽을 수신할 준비가 되었는지 확인합니다.

AKS 클러스터에 대한 일상적인 업데이트

Kubernetes 클러스터에 대한 2일차 작업의 일부는 일상적인 플랫폼 및 운영 체제 업데이트를 수행하는 것입니다. 모든 AKS 클러스터에서 처리할 세 가지 업데이트 계층이 있습니다.

• Kubernetes API 변경 및 사용 중단과 함께 제공되는 Kubernetes 버전(예: Kubernetes 1.30.3~ 1.30.7 또는 Kubernetes 1.30.7 ~ 1.31.1)입니다. 이 계층의 버전 변경은 전체 클러스터에 영향을 미칩니다.
• 운영 체제 업데이트와 AKS 구성 요소 업데이트를 결합하는 각 노드의 가상 하드 디스크 (VHD) 이미지입니다. 이러한 업데이트는 클러스터의 Kubernetes 버전에 대해 테스트됩니다. 이 계층의 버전 변경 내용은 노드 풀 수준에서 적용되며 Kubernetes 버전에는 영향을 주지 않습니다.
• Windows 업데이트 등의 운영 체제의 자체 네이티브 업데이트 프로세스 또는 apt. 운영 체제 공급업체는 이러한 업데이트를 직접 제공하며 클러스터의 Kubernetes 버전에 대해 테스트되지 않습니다. 이 계층의 버전 변경 내용은 단일 노드에 영향을 미치며 Kubernetes 버전에는 영향을 주지 않습니다.

이러한 각 계층은 독립적으로 제어됩니다. 워크로드의 클러스터에 대해 각 계층을 처리하는 방법을 결정합니다. 각 AKS 클러스터, 해당 노드 풀 또는 해당 노드가 업데이트되는 빈도( 주기)를 선택합니다. 또한 업데이트를 적용할 일 또는 시간을 선택합니다( 유지 관리 기간). 업데이트를 수동으로 설치할지 아니면 자동으로 설치할지 여부를 선택합니다. 클러스터에서 실행되는 워크로드와 마찬가지로 안전한 배포 사례가 필요하므로 클러스터에 대한 업데이트도 마찬가지입니다.

패치 및 업그레이드에 대한 포괄적인 관점은 AKS 2일차 작업 가이드의AKS 패치 및 업그레이드 지침을 참조하세요. 이 아키텍처와 관련된 기준 권장 사항에 대해 다음 정보를 사용합니다.

변경이 불가능한 인프라

변경할 수 없는 인프라로 AKS 클러스터를 작동하는 워크로드는 클러스터를 자동으로 또는 수동으로 업데이트하지 않습니다. 노드 이미지 업그레이드를 none로 설정하고 클러스터 자동 업그레이드를 none 로 설정합니다. 이 구성에서는 모든 계층의 모든 업그레이드를 전적으로 담당합니다. 원하는 업데이트를 사용할 수 있게 되면 사전 프로덕션 환경에서 업데이트를 테스트하고 새 클러스터에서 해당 호환성을 평가해야 합니다. 그런 다음 업데이트된 AKS 버전 및 노드 풀 VHD를 포함하는 프로덕션 복제본 스탬프를 배포합니다. 새 프로덕션 클러스터가 준비되면 이전 클러스터가 드레이닝되고 결국 서비스 해제됩니다.

새 인프라를 정기적으로 배포하는 변경할 수 없는 인프라는 프로덕션 클러스터에 현재 위치 업그레이드 전략이 적용되지 않아야 하는 유일한 상황입니다. 다른 모든 클러스터에는 현재 위치 업그레이드 전략이 있어야 합니다.

현재 위치 업그레이드

AKS 클러스터를 변경할 수 없는 인프라로 작동하지 않는 워크로드는 세 계층을 모두 해결하기 위해 실행 중인 클러스터를 정기적으로 업데이트해야 합니다. 업데이트 프로세스를 워크로드 요구 사항에 맞춥니다. 일상적인 업데이트 프로세스를 디자인하기 위한 시작점으로 다음 권장 사항을 사용합니다.

• 클러스터에서 업그레이드를 제어할 수 있도록 AKS의 계획된 유지 관리 기능을 예약합니다. 이 기능을 사용하면 기본적으로 위험한 작업인 업데이트를 제어된 시간에 수행하여 예기치 않은 실패의 영향을 줄일 수 있습니다.
• 롤링 업그레이드 중에 애플리케이션이 안정적으로 유지되도록 Pod 중단 예산을 구성합니다. 그러나 예산이 너무 공격적이어서 노드 업그레이드가 발생하지 않도록 구성하지 마세요. 대부분의 업그레이드에는 각 노드에 대한 코돈 및 드레이닝 프로세스가 필요하기 때문입니다.
• Azure 리소스 할당량 및 리소스 가용성을 확인합니다. 현재 위치 업그레이드는 이전 노드를 제거하기 전에 서지 노드라고 하는 새 노드 인스턴스를 배포합니다. 즉, Azure 할당량 및 IP 주소 공간을 새 노드에 사용할 수 있어야 합니다. 33%의 서지 값 은 대부분의 워크로드에 적합한 시작점입니다.
• 클러스터에 추가한 서비스 메시 또는 보안 에이전트와 같은 도구와의 호환성을 테스트합니다. 그리고 수신 컨트롤러, 서비스 메시 및 워크로드 Pod와 같은 워크로드 구성 요소를 테스트합니다. 사전 프로덕션 환경에서 테스트를 수행합니다.

노드에 대한 현재 위치 업그레이드

노드 OS 이미지 업그레이드에 NodeImage 자동 업그레이드 채널을 사용합니다. 이 채널은 노드 수준 업데이트를 사용하여 각 노드에서 VHD를 업데이트하도록 클러스터를 구성합니다. Microsoft는 AKS 버전에 대한 업데이트를 테스트합니다. Windows 노드의 경우 업데이트는 한 달에 한 번 정도 수행됩니다. Linux 노드의 경우 이러한 업데이트는 일주일에 한 번 정도 수행됩니다.

• 업그레이드는 AKS 또는 Kubernetes 버전을 변경하지 않으므로 Kubernetes API 호환성은 중요하지 않습니다.
• NodeImage 을 업그레이드 채널로 사용하는 경우, 계획된 유지 관리 기간을 준수하며, 일주일에 한 번 이상 설정해야 합니다. 적시에 애플리케이션을 보장하는 데 사용하는 노드 이미지 운영 체제에 관계없이 설정합니다.
• 이러한 업데이트에는 운영 체제 수준 보안, 호환성 및 기능 업데이트, 운영 체제 구성 설정 및 AKS 구성 요소 업데이트가 포함됩니다.
• 이미지 릴리스 및 포함된 구성 요소 버전 번호는 AKS 릴리스 추적기를 사용하여 추적됩니다.

클러스터에 대한 보안 요구 사항에 더 적극적인 패치 주기가 요구되고 클러스터가 잠재적인 중단을 허용할 수 있는 경우 SecurityPatch 업그레이드 채널을 대신 사용합니다. Microsoft는 이러한 업데이트도 테스트합니다. 업데이트는 Microsoft에서 다음 예약된 노드 이미지 업그레이드 전에 릴리스할 만큼 중요한 것으로 간주하는 보안 업그레이드가 있는 경우에만 게시됩니다. SecurityPatch채널NodeImage 을 사용할 때 채널이 받은 업데이트도 받게 됩니다. SecurityPatch 채널 옵션은 유지 관리 기간을 계속 유지 관리하므로 이러한 예기치 않은 보안 업데이트를 지원하기 위해 유지 관리 기간에 더 빈번한 간격(예: 매일 또는 격일)이 있는지 확인합니다.

현재 위치 업그레이드를 수행하는 대부분의 클러스터는 None 및 Unmanaged 노드 이미지 업그레이드 채널 옵션을 피해야 합니다.

클러스터에 대한 현재 위치 업데이트

Kubernetes는 빠르게 진화하는 플랫폼이며, 정기적인 업데이트는 중요한 보안 수정 및 새로운 기능을 제공합니다. Kubernetes 업데이트를 최신 상태로 유지하는 것이 중요합니다. 두 가지 최신 버전 또는 N-2 내에 있어야 합니다. 새 버전이 자주 릴리스되기 때문에, Kubernetes의 최신 버전으로 업그레이드하는 것이 중요합니다.

대부분의 클러스터는 충분한 주의와 엄격함으로 현재 위치 AKS 버전 업데이트를 수행할 수 있어야 합니다. 충분한 사전 프로덕션 테스트, 할당량 유효성 검사 및 Pod 중단 예산 구성을 통해 현재 위치 AKS 버전 업그레이드를 수행할 위험이 대부분 완화될 수 있습니다. 그러나 모든 현재 위치 업그레이드로 인해 예기치 않은 동작이 발생할 수 있습니다. 현재 위치 업그레이드가 워크로드에 너무 위험하다고 판단되는 경우 나머지 권장 사항을 따르는 대신 AKS 클러스터 접근 방식의 청록색 배포를 사용하는 것을 권장합니다.

Kubernetes 클러스터를 처음 배포할 때는 클러스터 자동 업그레이드 기능을 사용하지 않는 것을 권장합니다. 수동 접근 방식을 사용하면 업데이트가 프로덕션 환경에 적중하기 전에 사전 프로덕션 환경에서 새 AKS 클러스터 버전을 테스트할 시간을 제공합니다. 또한 이 방법은 가장 높은 수준의 예측 가능성 및 제어를 달성합니다. 그러나 Kubernetes 플랫폼에 대한 새 업데이트를 모니터링하고 릴리스할 때 새 버전을 신속하게 채택하는 것에 대해 부지런히 해야 합니다. 장기적인 지원 접근 방식보다 '최신 상태 유지' 사고방식을 채택하는 것이 좋습니다.

Azure Event Grid에 대한 AKS 시스템 토픽을 사용하여 클러스터에 새 AKS 버전을 사용할 수 있는 경우 알림을 받을 수 있습니다. 참조 구현은 이 Event Grid 시스템 토픽을 배포하여, 이벤트 스트림 알림 솔루션에서 Microsoft.ContainerService.NewKubernetesVersionAvailable 이벤트를 구독할 수 있도록 합니다. 특정 호환성 문제, 동작 변경 또는 기능 사용 중단에 대한 AKS 릴리스 정보를 검토합니다.

결국 Kubernetes 릴리스, AKS 릴리스, 클러스터, 클러스터 수준 구성 요소 및 워크로드를 통해 신뢰 지점에 도달하여 자동 업그레이드 기능을 탐색할 수 있습니다. 프로덕션 시스템의 경우 그 이상으로 patch이동하는 경우는 드뭅니다. 또한 AKS 버전을 자동으로 업그레이드할 때 클러스터에 대한 코드 (laC) AKS 버전 설정으로 인프라를 확인하여 동기화되지 않도록 합니다. 자동 업그레이드 작업을 지원하도록 계획된 유지 관리 기간을 구성합니다.

보안 모니터링

활성 위협 및 잠재적인 보안 위험 모두에 대한 컨테이너 인프라 모니터링. 다음은 관련 리소스입니다.

• 컨테이너용 Microsoft Defender 로 컨테이너 이미지에 대한 클라우드용 Defender 권장 사항을 식별하고 수정합니다.
• 컨테이너용 Defender는 정기적으로 컨테이너 이미지를 검사하여 취약성을 검색합니다.
• 컨테이너용 Defender는 의심스러운 활동에 대한 실시간 보안 경고도 생성합니다.
• AKS의 애플리케이션 및 클러스터에 대한 보안 개념은 컨테이너 보안이 전체 엔드투엔드 파이프라인을 빌드에서 AKS에서 실행되는 애플리케이션 워크로드로 보호하는 방법에 대한 정보를 자세히 설명합니다.

클러스터 및 워크로드 작업

클러스터 및 워크로드 작업 (DevOps) 고려 사항은 운영 우수성 디자인 원칙의 핵심 요소를 참조 하세요 .

클러스터 부트스트랩

프로비저닝을 수행한 후에는 작업 클러스터가 있지만 워크로드를 배포하기 전에 몇 가지 필수 단계가 있을 수 있습니다. 클러스터를 준비하는 프로세스를 부트스트래핑이라고 합니다. 부트스트래핑은 필수 구성 요소 이미지를 클러스터 노드에 배포하고, 네임스페이스를 만들고, 조직의 사용 사례 요구 사항을 충족하는 다른 작업을 수행하는 것으로 구성됩니다.

프로비저닝된 클러스터와 적절하게 구성된 클러스터 간의 격차를 줄이기 위해 클러스터 운영자는 고유한 부트스트래핑 프로세스가 어떤 모습인지 고려해야 합니다. 관련 자산을 미리 준비해야 합니다. 예를 들어 애플리케이션 워크로드를 배포하기 전에 각 노드에서 Kured를 실행하는 것이 중요한 경우 클러스터 운영자는 클러스터를 프로비저닝하기 전에 대상 Kured 이미지가 포함된 Container Registry 인스턴스가 이미 존재 하는지 확인해야 합니다.

부트스트래핑 프로세스는 다음 메서드 중 하나를 사용해서 구성할 수 있습니다.

• GitOps Flux v2 클러스터 확장
• Pipelines
• Flux 또는 Argo CD를 사용한 자체 구성(예:

AKS용 GitOps Flux v2 클러스터 확장을 사용할 때의 주요 이점 중 하나는, 프로비전된 클러스터와 부트스트랩된 클러스터 사이에 차이가 없다는 것입니다. 향후 견고한 관리 기반으로 환경을 설정하고 해당 부트스트래핑을 리소스 템플릿으로 포함하여, IaC 전략에 맞출 수 있도록 지원합니다.

마지막으로 확장을 사용할 때 kubectl은 부트스트래핑 프로세스의 어떤 부분에도 필요하지 않습니다. 긴급 중단 수정 상황에 대한 kubectl 기반 액세스를 예약할 수 있습니다. Azure 리소스 정의에 대한 템플릿과 GitOps 확장을 통한 매니페스트 부트스트랩 사이에 kubectl을 사용할 필요 없이 모든 정상 구성 작업이 수행될 수 있습니다.

워크로드 책임 격리

각 부분을 개별적으로 관리하기 위해 워크로드를 팀과 리소스 유형별로 나눕니다.

기본 구성 요소가 포함된 기본 워크로드로 시작하여 이를 기반으로 빌드합니다. 초기 작업은 네트워킹을 구성합니다. 해당 네트워크 내에서 허브 및 스포크와 서브넷에 대해서도 가상 네트워크를 프로비전합니다. 예를 들어, 스포크에는 시스템 및 사용자 노드 풀과 수신 리소스에 대한 별도의 서브넷이 있습니다. 허브에서 Azure Firewall에 대한 서브넷을 배포하세요.

또 다른 작업은 기본 워크로드를 Microsoft Entra ID와 통합하는 것입니다.

IaC 사용하기

가능한 경우 명령적 접근 방식보다 idempotent 선언적 메서드를 선택합니다. 구성 옵션을 지정하는 명령 시퀀스를 작성하는 대신 리소스 및 해당 속성을 설명하는 선언적 구문을 사용합니다. Bicep, Azure 리소스 매니저 템플릿 (ARM 템플릿) 또는 Terraform을 사용할수 있습니다.

관리 정책마다 리소스를 프로비전해야 합니다. 예를 들어, 올바른 VM 크기를 선택할 때 애플리케이션의 요구 사항에 맞게 비용 제약 조건, 가용성 영역 옵션 내로 유지합니다. Azure Policy를 사용하여 이러한 결정에 조직의 정책을 적용할 수도 있습니다.

명령 시퀀스를 작성해야 하는 경우 Azure CLI를 사용합니다. 이러한 명령은 다양한 Azure 서비스를 포함하며, 스크립팅을 통해 자동화할 수 있습니다. Windows 및 Linux 지원 Azure CLI. 또 다른 플랫폼 간 옵션은 Azure PowerShell입니다. 선택은 선호하는 기술 집합에 따라 다릅니다.

소스 제어 시스템에 스크립트 및 템플릿 파일을 저장하고, 버전을 지정합니다.

워크로드 CI/CD

워크플로 및 배포를 위한 파이프라인에는 애플리케이션을 지속적으로 빌드하고, 배포할 수 있는 기능이 있어야 합니다. 업데이트 안전하고 신속하게 배포하고, 문제가 있는 경우 롤백해야 합니다.

배포 전략에는 안정적이고 자동화된 지속적인 업데이트 전달 파이프라인이 포함되어야 합니다. 워크로드 컨테이너 이미지에 대한 변경 내용은 클러스터에 자동으로 배포합니다.

이 아키텍처에서는, 워크플로 및 배포를 관리하기 위해 GitHub Actions를 선택했습니다. 기타 인기 있는 옵션으로는 Azure DevOps 및 Jenkins가 있습니다.

클러스터 CI/CD

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

kubectl과 같은 명령적 접근 방식을 사용하는 대신 클러스터 및 리포지토리 변경 내용을 자동으로 동기화하는 도구를 사용합니다. 프로덕션에 배포하기 전에, 새 버전의 릴리스 및 해당 버전의 유효성 검사와 같은 워크플로를 관리하려면 GitOps 흐름을 사용하는 것이 좋습니다.

CI/CD 흐름의 필수적인 부분은 새롭게 프로비전된 클러스터의 부트스트래핑입니다. GitOps 접근 방식이 유용한 이유는 운영자가 IaC 전략의 일부로 부트스트래핑 프로세스를 선언적으로 정의하고 클러스터에 자동으로 반영된 구성을 볼 수 있도록 허용하기 때문입니다.

GitOps를 사용하는 경우, 에이전트가 클러스터에 배포되어 클러스터의 상태가 프라이빗 Git 리포지토리에 저장된 구성과 통합되도록 합니다. 이러한 에이전트 중 하나는 Flux이며, 클러스터에서 하나 이상의 연산자를 사용하여 Kubernetes 내에서 배포를 트리거합니다. Flux는 다음 작업을 수행합니다.

• 구성된 모든 리포지토리를 모니터링합니다.
• 새로운 구성 변경 내용을 검색합니다.
• 배포를 트리거합니다.
• 해당 변경 내용에 따라 원하는 실행 구성을 업데이트합니다.

해당 변경 내용이 배포되는 방식을 제어하는 정책도 설정할 수 있습니다.

다음은 GitOps 및 Flux를 사용하여 클러스터 구성을 자동화하는 방법을 보여 주는 예제입니다:

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

1. 개발자는 Git 리포지토리에 저장된 구성 YAML 파일과 같은 소스 코드에 변경 내용을 커밋합니다. 그러면 변경 내용이 Git 서버로 푸시됩니다.

2. Flux는 워크로드와 더불어 Pod에서 실행됩니다. Flux에는 Git 리포지토리에 대한 읽기 전용 액세스 권한이 있어서, Flux가 개발자의 요청 시에만 변경 내용을 적용하도록 합니다.

3. Flux는 구성의 변경 내용을 인식하고 kubectl 명령으로 해당 변경 내용을 적용합니다.

4. 개발자는 kubectl을 통해 Kubernetes API에 직접 액세스하지 않습니다.

여러 개발자가 변경 내용을 프로덕션에 적용하기 전에 끌어오기 요청을 통해 변경 내용을 승인할 수 있도록 Git 서버에 분기 정책을 적용할 수 있습니다.

GitOps와 Flux는 직접 구성할 수 있지만 AKS에는 Flux v2 클러스터 확장을 포함하는 GitOps를 사용하는 것이 좋습니다.

워크로드 및 클러스터 배포 전략

모든 변경 내용 아키텍처 구성 요소, 워크로드, 클러스터 구성을 하나 이상의 사전 프로덕션 AKS 클러스터에 배포합니다. 이렇게 하면 변경 내용이 시뮬레이션되고 프로덕션에 배포되기 전에 문제를 식별할 수 있습니다.

다음 단계로 넘어가기 전에 각 단계에서 테스트 및 유효성 검사를 실행합니다. 이를 통해 고도로 제어된 방식으로 프로덕션 환경에 업데이트를 푸시하고 예기치 않은 배포 문제로 인한 중단을 최소화할 수 있습니다. 이 배포는 동일한 GitHub Actions 파이프라인 또는 Flux 연산자로 프로덕션과 유사한 패턴을 따라야 합니다.

파란색-녹색 배포, A/B 테스트 및 카나리아 릴리스등의 고급 배포 기술에는 추가 프로세스가 요구되고 도구 사용이 필요할 수 있습니다. Flagger는 고급 배포 시나리오 해결을 지원하는 인기있는 오픈 소스 솔루션입니다.

원가 관리

먼저 AKS용 Well-Architected Framework에 설명된 비용 최적화 설계 검사 목록 및 권장 사항 목록을 검토합니다. Azure 가격 계산기로 아키텍처에 사용되는 서비스 비용을 예측합니다. 다른 모범 사례는 비용 최적화를 참조 하세요.

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

Windows 관련 비용 관리 고려 사항에 대한 자세한 내용은 AKS의 Windows 컨테이너를 참조하세요.

프로비전

• 비용이 어디에서 오는지 이해합니다. Kubernetes 클러스터 자체의 배포, 관리, 운영에서 AKS와 관련된 최소한의 비용은 없습니다. 비용에 영향을 미치는 것은 클러스터에서 사용하는 VM 인스턴스, 스토리지, 로그 데이터, 네트워킹 리소스입니다. 시스템 노드 풀에는 더 저렴한 VM을 선택하는 것이 좋습니다. DS2_v2 시리즈는 시스템 노드 풀의 일반적인 VM 유형입니다.

• 개발/테스트와 프로덕션 환경에 대해 동일한 구성을 해서는 안 됩니다. 프로덕션 워크로드에는 고가용성을 위한 추가 요구 사항이 있으며 일반적으로 비용이 더 많이 듭니다. 이 구성은 개발/테스트 환경에서 필요하지 않습니다.

• 프로덕션 워크로드용 작동 시간 SLA 추가하기. 그러나 가용성을 보장이 필요 없는 개발/테스트 또는 실험적 워크로드용으로 설계된 클러스터에는 비용 절감이 가능합니다. 예를 들어, SLO로 충분합니다. 또한 워크로드에서 지원하는 경우 스폿 VMs을 실행하는 전용 스폿 노드 풀을 사용하는 것이 좋습니다.

  AKS 워크로드 아키텍처의 일부로서 Azure SQL Database 또는 Azure App Service를 포함하는 비프로덕션 워크로드의 경우 Azure 개발/테스트 구독을 사용하여 서비스 할인을 받을 자격이 있는지 평가합니다.

• 스케일링 요구 사항을 충족하기 위해 과도한 크기의 클러스터로 시작하는 대신 최소 노드 수로 클러스터를 프로비전하고, 클러스터 자동 스케일러가 모니터링하여 크기 조정 결정을 내릴 수 있도록 합니다.

• Kubernetes가 더 높은 밀도의 노드 리소스를 할당할 수 있도록, Pod 요청 및 제한을 설정하여 하드웨어가 용량에 활용되도록 합니다.

• 클러스터에서 진단을 사용하도록 설정하면 비용이 증가할 수 있습니다.

• 워크로드가 장기간 있어야 할 경우, 1년 또는 3년간 Azure 예약 가상 머신 인스턴스를 약정하여 노드 비용을 줄일 수 있습니다. 자세한 내용은, Azure 예약 가상 머신 인스턴스로 비용 절감을 참조하세요.

• 노드 풀을 만들 때 태그를 사용합니다. 태그는 발생한 비용을 추적하기 위해 사용자 지정 보고서를 만들 때 도움이 됩니다. 태그를 사용하여 총 비용을 추적하고 비용을 특정 리소스 또는 팀에 매핑할 수 있습니다. 또한 클러스터가 팀 간에 공유되는 경우 소비자당 차지백 보고서를 작성하여 공유 클라우드 서비스에 대해 측정된 비용을 식별할 수 있습니다. 자세한 내용은 노드 풀에 대한 taint, 레이블 또는 태그 지정.

• 워크로드가 다중 지역이고 지역 간에 데이터를 복제하는 경우 추가 대역폭 비용을 예상합니다. 자세한 내용은 대역폭 가격 책정을 참조하세요.

• 조직에서 식별한 비용 제약 조건 내로 유지되도록 예산을 만듭니다. Microsoft Cost Management를 통해 예산을 만들 수 있습니다. 특정 임계값을 초과할 때 알림을 받는 경고를 만들 수도 있습니다. 자세한 내용은 템플릿을 사용하여 예산 만들기를 참조하세요.

Monitor

전체 클러스터와 컴퓨팅, 스토리지, 대역폭, 로그 및 방화벽 비용을 모니터링할 수 있습니다. Azure는 비용을 모니터링하고 분석하는 옵션을 제공합니다.

• Azure Advisor

• Microsoft Cost Management

이상적으로는 실시간으로 또는 적어도 정기적인 주기로 비용을 모니터링하는 것이 좋습니다. 그런 다음 비용이 이미 계산된 월말 이전에 조치를 취할 수 있습니다. 또한, 시간 경과에 따른 월별 추세를 모니터링하여 예산 내로 유지합니다.

데이터에 기반한 결정을 내리려면, 가장 많은 비용이 발생하는 리소스를 세부적으로 파악합니다. 또한, 각 리소스의 사용량을 계산하는 데 사용되는 미터를 잘 이해합니다. 예를 들어, 메트릭을 분석하여, 플랫폼이 과도한 크기인지 판단할 수 있습니다. Azure Monitor 메트릭에서 사용량 미터를 확인할 수 있습니다.

최적화

Azure Advisor에서 제공하는 권장 사항에 따라 조치를 합니다. 최적화는 다른 방법으로도 수행할 수 있습니다.

• 클러스터 자동 스케일러를 사용하여 노드 풀에서 과소 사용된 노드를 감자하고 제거할 수 있습니다.

  Important

  비용에 영향을 미치기 위해 노드 풀의 최소 및 최대 노드 설정과 같은 클러스터 자동 크기 조정기 설정을 적극적으로 변경하면 비생산적인 결과가 발생할 수 있습니다. 예를 들어 10분으로 설정되고 최소 및 최대 노드 설정이 워크로드 특성에 따라 5분마다 수정되는 경우 scale-down-unneeded-time 노드 수는 줄어들지 않습니다. 클러스터 자동 크기 조정기 설정이 새로 고쳐지므로 각 노드에 대한 불필요한 시간 계산이 다시 설정되기 때문입니다.

• 워크로드에서 지원하는 경우 해당 노드 풀에 대해 더 낮은 SKU를 선택합니다.

• 애플리케이션에 버스트 스케일링이 필요하지 않은 경우 시간이 지남에 따라 성능 메트릭을 분석하여 클러스터 크기를 적절하게 조정하는 것이 좋습니다.

• 워크로드가 이를 지원하는 경우, 실행이 예상되지 않을 때 사용자 노드 풀을 0 노드로 스케일링합니다. 또한 클러스터에서 실행되도록 예약된 워크로드가 없는 경우 AKS 시작/중지 기능으로 시스템 노드 풀 및 AKS 컨트롤 플레인을 포함한 모든 컴퓨팅을 종료하는 것이 좋습니다.

기타 비용 관련 정보는 AKS 가격 책정을 참조하세요.

다음 단계

• 고급 AKS 마이크로 서비스 아키텍처
• 다중 지역 클러스터에 대한 AKS 기준
• PCI-DSS 3.2.1용 AKS 규제 클러스터
• AKS 기준 참조 아키텍처의 Windows 컨테이너

관련 참고 자료

• GitHub의 AKS 로드맵
• Kubernetes 소개
• Kubernetes에서 애플리케이션 개발 및 배포
• AKS의 Well-Architected Framework 검토
• AKS 랜딩 존 가속기
• AKS 2일차 작업 가이드
• AKS의 마이크로서비스 아키텍처
• Azure Firewall을 사용하여 AKS 클러스터 보호
• AKS에 대한 Git 작업
• AKS를 사용한 데이터 스트리밍