다음을 통해 공유

AKS(Azure Kubernetes Service)에 대한 Azure Well-Architected Framework 관점

  • 아티클

AKS(Azure Kubernetes Service)는 컨테이너화된 애플리케이션을 배포하고 관리하는 데 사용할 수 있는 관리되는 Kubernetes 서비스입니다. 다른 관리되는 서비스와 마찬가지로 AKS는 작업 오버헤드의 상당 부분을 Azure로 오프로드하면서 워크로드에 고가용성, 확장성 및 이식성 기능을 제공합니다.

이 문서에서는 아키텍트로서 컴퓨트 의사 결정 트리를 검토하고 워크로드에 대한 컴퓨트 옵션으로 AKS를 선택했다고 가정합니다. 이 문서의 지침에서는 Azure Well-Architected Framework 핵심 요소원칙에 매핑되는 아키텍처 권장 사항을 제공합니다.

중요하다

이 가이드를 사용하는 방법

각 섹션에는 기술 범위로 지역화된 디자인 전략과 함께 관심 있는 아키텍처 영역을 제공하는 디자인 검사 목록 있습니다.

또한 이러한 전략을 구체화하는 데 도움이 될 수 있는 기술 기능에 대한 권장 사항도 포함되어 있습니다. 권장 사항은 AKS 및 해당 종속성에 사용할 수 있는 모든 구성의 전체 목록을 나타내지 않습니다. 대신 디자인 관점에 매핑된 주요 권장 사항을 나열합니다. 권장 사항을 사용하여 개념 증명을 빌드하거나 기존 환경을 최적화합니다.

주요 권장 사항을 보여 주는 기본 아키텍처: AKS 기준 아키텍처.

기술 범위

이 검토는 다음 Azure 리소스에 대한 상호 연결된 결정에 중점을 둡니다.

  • AKS

AKS에 대한 Well-Architected Framework 핵심 요소의 모범 사례를 논의할 때는 클러스터 워크로드 구분하는 것이 중요합니다. 클러스터 모범 사례는 클러스터 관리자와 해당 리소스 공급자 간의 공동 책임이며 워크로드 모범 사례는 개발자의 도메인입니다. 이 문서에는 이러한 각 역할에 대한 고려 사항 및 권장 사항이 있습니다.

메모

다음은 디자인 검사 목록 및 각 선택이 클러스터 아키텍처, 워크로드 아키텍처 또는 둘 다에 적용할 수 있는지 여부를 나타내는 권장 사항의 목록을 포함합니다.

신뢰성

안정성 핵심 요소의 목적은 충분한 복원력과 오류로부터 빠르게 복구할 수 있는 기능을지속적인 기능을 제공하는 것입니다.

안정성 디자인 원칙은 개별 구성 요소, 시스템 흐름 및 시스템 전체에 적용되는 고급 디자인 전략을 제공할 있습니다.

디자인 검사 목록

안정성 대한디자인 검토 검사 목록을 기반으로 디자인 전략을 시작합니다. AKS의 기능 및 종속성을 염두에 두고 비즈니스 요구 사항과 관련성을 확인합니다. 필요에 따라 더 많은 접근 방식을 포함하도록 전략을 확장합니다.

  • (클러스터) 복원력을 향상시키기 위해 중복성을 빌드합니다. 단일 지역에 배포할 때 가용성을 높이기 위한 복원력 전략의 일환으로 AKS 클러스터에 대한 가용성 영역을 사용합니다. 많은 Azure 지역에서 가용성 영역을 제공합니다. 영역은 대기 시간이 짧은 연결을 가질 수 있을 만큼 가깝지만 로컬 중단이 둘 이상의 영역에 영향을 줄 가능성을 줄이기에 충분합니다.

    중요한 워크로드의 경우 여러 Azure 지역에 여러 클러스터를 배포합니다. AKS 클러스터를 지리적으로 분산하면 복원력을 높이고 지역 오류의 영향을 최소화할 수 있습니다. 다중 지역 전략은 가용성을 최대화하고 비즈니스 연속성을 제공하는 데 도움이 됩니다. 인터넷에 노출된 워크로드는 Azure Front Door 또는 Azure Traffic Manager 를 사용하여 AKS 클러스터 간에 트래픽을 전역적으로 라우팅해야 합니다. 자세한 내용은 멀티리전 전략을 참조하세요.

    IP 주소 공간을 계획하여 클러스터가 다중 클러스터 토폴로지에서 장애 조치(failover) 트래픽의 크기를 안정적으로 조정하고 처리할 수 있도록 합니다.

  • (클러스터 및 워크로드) 클러스터 및 워크로드의 안정성 및 전반적인 상태 지표를 모니터링합니다. 로그 및 메트릭을 수집하여 워크로드 상태를 모니터링하고, 성능 및 안정성 추세를 식별하고, 문제를 해결합니다. AKS 솔루션에 대한 안정성 및 상태 모니터링 솔루션을 설계하는 데 도움이 되도록 Azure Monitor 사용하여 Kubernetes를 모니터링하는 모범 사례 및 워크로드에 대한 Well-Architected 상태 모델링 가이드를 검토합니다.

    워크로드가 수평 크기 조정을 지원하고 애플리케이션 준비 상태 및 상태를 보고하도록 빌드되었는지 확인합니다.

  • (클러스터 및 워크로드) 사용자 노델 풀에서 애플리케이션 Pod를 호스트합니다. 애플리케이션 워크로드에서 시스템 Pod를 격리하면 AKS 필수 서비스가 리소스 요구 또는 사용자 노드 풀을 실행하는 워크로드로 인한 잠재적 문제의 영향을 받지 않도록 할 수 있습니다.

    워크로드가 사용자 노드 풀에서 실행되는지 확인하고 적절한 크기의 SKU를 선택합니다. 최소한 사용자 노드 풀에 대한 노드 2개와 시스템 노드 풀의 노드 3개를 포함합니다.

  • (클러스터 및 워크로드) AKS 작동 시간 SLA(서비스 수준 계약)를 가용성 및 복구 대상으로 고려합니다. 클러스터 및 워크로드에 대한 안정성 및 복구 대상을 정의하려면 안정성 대상을 정의하기 위한권장 사항의 지침을 따릅니다. 그런 다음 해당 대상을 충족하는 디자인을 작성합니다.

  • (클러스터 및 워크로드) Azure Backup을 사용하여 AKS 클러스터 서비스를 보호하고, 복구 지점을 백업 볼트에 저장하여 재해 시나리오에서 복원을 수행합니다. AKS 클러스터에서 실행되는 컨테이너화된 애플리케이션 및 데이터를 백업하고 복원하려면 보호를 구성하기 위한 AKS 백업 개요의 지침을 따르세요.

권장 사항

추천 장점
(클러스터 및 워크로드) 노드 선택기 및 선호도를 사용하여 Pod 예약을 제어합니다.

AKS에서 Kubernetes 스케줄러는 노드의 하드웨어별로 워크로드를 논리적으로 격리할 수 있습니다. 달리, 일치하는 노드 선택기가 없는 Pod도 레이블이 지정된 노드에 예약될 수 있지만, 일치하는 노드 선택기를 정의한 Pod가 우선적으로 예약됩니다.		 노드 선호도는 더 많은 유연성을 제공하므로 Pod를 노드와 일치시킬 수 없는 경우 발생하는 작업을 정의할 수 있습니다.
(클러스터) 네트워크 요구 사항 및 클러스터 크기 조정에 따라 적절한 네트워크 플러그 인을 선택합니다.

네트워크 플러그 인마다 다양한 수준의 기능을 제공합니다. Azure CNI(Azure Container Networking Interface)는 Windows 기반 노드 풀, 일부 네트워킹 요구 사항 및 Kubernetes 네트워크 정책과 같은 특정 시나리오에 필요합니다.

자세한 내용은 Kubenet과 Azure CNI참조하세요.		 올바른 네트워크 플러그 인은 더 나은 호환성 및 성능을 보장하는 데 도움이 될 수 있습니다.
(클러스터 및 워크로드) 프로덕션 등급 클러스터에 AKS 가동 시간 SLA 사용합니다. 워크로드는 AKS 클러스터에 대한 Kubernetes API 서버 엔드포인트의 고가용성 보장으로 인해 더 높은 가용성 대상을 지원할 수 있습니다.
(클러스터) 가용성 영역 사용하여 물리적으로 분리된 데이터 센터에 AKS 에이전트 노드를 배포하여 Azure 지역 내에서 복원력을 최대화합니다.

공동성 요구 사항이 있는 경우 일반 가상 머신 확장 집합 기반 AKS 배포를 단일 영역에 사용하거나 근접 배치 그룹을 사용하여 노드 간 대기 시간을 최소화합니다.		 여러 영역에 노드 풀을 분산하면 다른 영역이 중단되더라도 한 노드 풀의 노드는 계속 실행됩니다.
(클러스터 및 워크로드) 애플리케이션 배포 매니페스트에서 Pod 리소스 요청 및 제한을 정의합니다. Azure Policy를 사용하여 이러한 제한을 적용합니다. Kubernetes 클러스터에서 리소스 소모를 방지하기 위해 컨테이너 CPU 및 메모리 리소스 제한이 필요합니다.
(클러스터 및 워크로드) 시스템 노드 풀을 애플리케이션 워크로드에서 격리된 상태로 유지합니다.

시스템 노드 풀에는 2개 이상의 vCPU 및 4GB 메모리의 VM(가상 머신) SKU가 필요합니다. 4개 이상의 vCPU를 사용하는 것이 좋습니다. 자세한 내용은 시스템 및 사용자 노드 풀참조하세요.		 시스템 노드 풀은 클러스터의 제어 평면에 필수적인 중요한 시스템 Pod를 호스트합니다. 애플리케이션 워크로드에서 이러한 시스템 Pod를 격리하면 필수 서비스가 리소스 요구 또는 워크로드로 인한 잠재적 문제의 영향을 받지 않도록 할 수 있습니다.
(클러스터 및 워크로드) 특정 요구 사항에 따라 전용 노드 풀에 애플리케이션을 분리합니다. 관리 오버헤드를 줄이기 위해 많은 수의 노드 풀을 방지합니다. 애플리케이션은 동일한 구성을 공유할 수 있으며 GPU 사용 VM, CPU 또는 메모리 최적화 VM 또는 0으로 확장할 수 있는 기능이 필요합니다. 특정 애플리케이션에 노드 풀을 헌납하면 리소스를 과도하게 프로비전하거나 활용하지 않고 각 애플리케이션이 필요한 리소스를 가져오도록 할 수 있습니다.
(클러스터) 여러 개의 동시 아웃바운드 연결을 만드는 워크로드를 실행하는 클러스터에 NAT 게이트웨이 사용합니다. Azure NAT Gateway는 대규모로 안정적인 송신 트래픽을 지원하며 높은 동시 아웃바운드 트래픽에 Azure Load Balancer 제한을 적용하여 안정성 문제를 방지할 수 있습니다.
(클러스터 및 워크로드) Azure Backup을 사용하여 AKS 클러스터를 보호하고 재해 발생 시 대체 지역으로 복원합니다. Azure Backup은 클러스터 상태 및 애플리케이션 데이터에 대해 실행되는 컨테이너화된 애플리케이션 및 데이터의 백업 및 복원 작업을 지원합니다.

지역 재해 시나리오에서 백업을 사용하고백업을 복구할 수 있습니다.		 AKS(Azure Kubernetes Service)를 사용한 Azure Backup은 완전히 관리되고 확장 가능하며 안전하며 비용 효율적인 솔루션을 제공합니다. 백업 인프라를 설정하고 유지 관리하는 복잡성 없이 워크로드의 안정성을 향상시킵니다.

보안

보안 핵심 요소의 목적은 워크로드에 기밀성, 무결성 및 가용성 보증을 제공하는 것입니다.

보안 디자인 원칙은 AKS의 기술 설계에 접근 방법을 적용함으로써 이러한 목표를 달성하기 위한 고수준의 설계 전략을 제공합니다.

디자인 검사 목록

보안 대한 디자인 검토 검사 목록을 기반으로 디자인 전략을 시작하고 취약성 및 컨트롤을 식별하여 보안 상태를 개선합니다. AKS 보안 개념 숙지하고 CIS Kubernetes 벤치마크기반으로 보안 강화 권장 사항을 평가합니다. 필요에 따라 더 많은 접근 방식을 포함하도록 전략을 확장합니다.

  • (클러스터) ID 및 액세스 관리대한 Microsoft Entra ID와 통합합니다. Microsoft Entra ID를 사용하여 클러스터에 대한 ID 관리를 중앙 집중화합니다. 사용자 계정 또는 그룹 상태의 변경 내용은 AKS 클러스터에 액세스할 때 자동으로 업데이트됩니다. ID를 기본 보안 경계설정합니다. Kubernetes 클러스터의 개발자 및 애플리케이션 소유자는 다양한 리소스에 액세스해야 합니다.

    Kubernetes 역할 기반 액세스 제어(RBAC)를 Microsoft Entra ID와 함께 사용하여 최소 권한 액세스을(를) 구현합니다. 관리자 권한 할당을 최소화하여 구성 및 비밀을 보호합니다.

  • (클러스터) 보안 모니터링 및 보안 정보 및 이벤트 관리 도구와 통합합니다. Microsoft Sentinel 컨테이너용 Microsoft Defender를 사용하여 클러스터 및 해당 클러스터에서 실행되는 워크로드의 위협을 감지하고 신속하게 대응합니다. Microsoft Sentinel AKS 커넥터를 사용하도록 설정하여 AKS 진단 로그를 Microsoft Sentinel로 스트리밍합니다.

  • (클러스터 및 워크로드) 세분화 및 네트워크 컨트롤을 구현합니다. 데이터 반출을 방지하려면 권한 있고 안전한 트래픽만 허용하고 보안 위반의 폭발 반경을 포함해야 합니다.

    프라이빗 AKS 클러스터를 사용하여 API 서버에 대한 클러스터 관리 트래픽이 프라이빗 네트워크에 유지되도록 하는 것이 좋습니다. 또는 공용 클러스터에 API 서버 허용 목록을 사용합니다.

  • (워크로드) WAF(웹 애플리케이션 방화벽)를 사용하여 들어오는 트래픽에서 잠재적인 공격을 검색합니다. WAF는 애플리케이션에 도달하기 전에 악의적인 트래픽을 차단하는 데 도움이 되도록 실시간으로 위협을 감지하고 완화할 수 있습니다. SQL 삽입, 사이트 간 스크립팅 및 기타 Open Web Application Security Project 취약성과 같은 일반적인 웹 기반 공격으로부터 강력한 보호를 제공합니다. 부하 분산 장치 중 일부는 Azure Application Gateway 또는 Azure Front Door와 같이 통합 WAF가 있습니다.

  • (워크로드) 강화된 워크로드의 소프트웨어 공급망을 유지 관리합니다. 컨테이너 인식 검사로 지속적인 통합 및 지속적인 업데이트 파이프라인이 강화되었는지 확인합니다.

  • (클러스터 및 워크로드) 특수 보안 워크로드에 대한 추가 보호를 구현합니다. 클러스터에서 중요한 워크로드를 실행해야 하는 경우 프라이빗 클러스터를 배포해야 할 수 있습니다. 다음은 몇 가지 예입니다.

권장 사항

추천 장점
(클러스터) 클러스터에서 관리 ID 사용합니다. 서비스 원칙 관리 및 회전과 관련된 오버헤드를 방지할 수 있습니다.
(워크로드) Microsoft Entra 워크로드 ID 를 사용하여 AKS에서 워크로드를 통해 Azure Key Vault 및 Microsoft Graph와 같은 Microsoft Entra로 보호되는 리소스에 액세스합니다. AKS 워크로드 ID를 사용하여 코드에서 직접 자격 증명을 관리할 필요 없이 Microsoft Entra ID RBAC를 사용하여 Azure 리소스에 대한 액세스를 보호합니다.
클러스터) Microsoft Entra ID를 사용하여 AKS 에서 Azure Container Registry에 인증합니다. AKS는 Microsoft Entra ID를 사용하여 imagePullSecrets 비밀을 사용하지 않고 Container Registry로 인증할 수 있습니다.
(클러스터) 워크로드 요구 사항에 더 높은 수준의 세분화가 필요한 경우 프라이빗 AKS 클러스터 사용하여 API 서버로 네트워크 트래픽을 보호합니다. 기본적으로 노드 풀과 API 서버 간의 네트워크 트래픽은 Microsoft 백본 네트워크를 이동합니다. 프라이빗 클러스터를 사용하면 API 서버에 대한 네트워크 트래픽이 프라이빗 네트워크에만 유지되도록 할 수 있습니다.
(클러스터) 공용 AKS 클러스터의 경우 API 서버 권한이 부여된 IP 주소 범위를 사용합니다. 배포 빌드 에이전트, 작업 관리 및 노드 풀의 송신 지점(예: Azure Firewall)의 공용 IP 주소와 같은 원본을 포함합니다. 공용 클러스터를 사용하는 경우 클러스터의 API 서버에 도달할 수 있는 트래픽을 제한하여 AKS 클러스터의 공격 노출 영역을 크게 줄일 수 있습니다.
(클러스터) Microsoft Entra ID RBAC를 사용하여 API 서버를 보호합니다.

로컬 계정 사용하지 않도록 설정하여 Microsoft Entra ID 기반 ID를 사용하여 모든 클러스터 액세스를 적용합니다.		 Kubernetes API 서버에 대한 액세스 보안은 클러스터를 보호하기 위해 수행할 수 있는 가장 중요한 작업 중 하나입니다. Kubernetes RBAC를 Microsoft Entra ID와 통합하여 API 서버에 대한 액세스를 제어합니다.
(클러스터) Azure 네트워크 정책 또는 Calico을(를) 사용하십시오. 정책을 사용하면 클러스터의 Pod 간에 네트워크 트래픽을 보호하고 제어할 수 있습니다. Calico는 정책 순서 및 우선 순위, 거부 규칙 및 보다 유연한 일치 규칙을 포함하여 다양한 기능을 제공합니다.
(클러스터) Azure Policy사용하여 클러스터 및 Pod를 보호합니다. Azure Policy는 중앙 집중식으로 일관된 방식으로 클러스터에 대규모 적용 및 보호 기능을 적용하는 데 도움이 될 수 있습니다. 또한 Pod에 부여된 함수를 제어하고 회사 정책에 대해 실행 중인 함수가 있는지 여부를 감지할 수 있습니다.
(클러스터) 리소스에 대한 컨테이너 액세스를 보호합니다. 컨테이너가 수행할 수 있는 작업에 대한 액세스를 제한합니다. 최소 개수의 권한을 제공하고 루트 사용 또는 권한 상승을 방지합니다.

Linux 기반 컨테이너의 경우 기본 제공 Linux 보안 기능 사용하여 리소스에 대한보안 컨테이너 액세스를 참조하세요.		 권한을 제한하고 루트 또는 권한 있는 에스컬레이션을 사용하지 않도록 하여 보안 위반 위험을 줄일 수 있습니다. 컨테이너가 손상되더라도 잠재적 손상이 최소화되도록 할 수 있습니다.
(클러스터) 클러스터의 아웃바운드 트래픽이 Azure Firewall 또는 HTTP 프록시같은 네트워크 보안 지점을 통과하도록 하여 클러스터 송신 트래픽을 제어합니다. Azure Firewall 또는 HTTP 프록시를 통해 아웃바운드 트래픽을 라우팅하여 무단 액세스 및 데이터 반출을 방지하는 보안 정책을 적용할 수 있습니다. 또한 이 방법은 보안 정책 관리를 간소화하고 전체 AKS 클러스터에서 일관된 규칙을 보다 쉽게 적용할 수 있도록 합니다.
(클러스터) 오픈 소스 Microsoft Entra 워크로드 ID 및 비밀 저장소 CSI 드라이버를 Key Vault와 함께 사용합니다. 이러한 기능은 강력한 암호화를 사용하여 Key Vault에서 비밀, 인증서 및 연결 문자열을 보호하고 회전하는 데 도움이 됩니다. 액세스 감사 로그를 제공하고 핵심 비밀을 배포 파이프라인에서 유지합니다.
(클러스터) 컨테이너용 Microsoft Defender 사용합니다. 컨테이너용 Microsoft Defender를 사용하면 클러스터, 컨테이너 및 해당 애플리케이션의 보안을 모니터링하고 유지 관리할 수 있습니다.

비용 최적화

비용 최적화는 지출 패턴을 감지하고, 중요한 영역에 대한 투자의 우선 순위를 지정하고, 비즈니스 요구 사항을 충족하면서 조직의 예산을 충족하도록 다른 영역에서 최적화하는 데 중점을 둡니다.

비용 최적화 디자인 원칙은 AKS 및 해당 환경과 관련된 기술 설계에서 필요에 따라 이러한 목표를 달성하고 절충하기 위한 높은 수준의 디자인 전략을 제공할 있습니다.

디자인 검사 목록

디자인 검토 체크리스트에 기반하여, 투자에 대한 비용 최적화을 위한 디자인 전략을 시작합니다. 워크로드가 워크로드에 할당된 예산에 맞게 조정되도록 디자인을 미세 조정합니다. 디자인은 적절한 Azure 기능을 사용하고, 투자를 모니터링하고, 시간이 지남에 따라 최적화할 기회를 찾아야 합니다.

  • (클러스터) 비용 모델에 AKS 대한 가격 책정 계층을 포함합니다. 비용을 예측하려면 Azure 가격 계산기 사용하고 계산기에서 다양한 구성 및 지불 계획을 테스트합니다.

  • (클러스터) 워크로드에 가장 적합한 요금을 가져옵니다. 워크로드 실행 비용에 직접적인 영향을 주므로 각 노드 풀에 적절한 VM SKU를 사용합니다. 적절한 사용률 없이 고성능 VM을 선택하면 지출 낭비가 발생할 수 있습니다. 덜 강력한 VM을 선택하면 성능 문제가 발생하고 가동 중지 시간이 증가할 수 있습니다.

    용량을 적절하게 계획했고 워크로드가 예측 가능하고 장기간 존재할 경우 Azure Reservations 또는 절감 계획 등록하여 리소스 비용을 절감합니다.

    Azure Spot Virtual Machines 선택하여 상당한 할인과 함께 사용하지 않는 Azure 용량을 사용합니다. 이러한 할인은 종량제 가격의 최대 90%까지 도달할 수 있습니다. Azure에 용량이 다시 필요한 경우 Azure 인프라는 스폿 노드를 제거합니다.

    AKS 온-프레미스 또는 에지를 실행하는 경우 Azure 하이브리드 혜택 사용하여 이러한 시나리오에서 컨테이너화된 애플리케이션을 실행할 때 비용을 절감할 수도 있습니다.

  • (클러스터 및 워크로드) 워크로드 구성 요소 비용을 최적화합니다. 워크로드에 가장 비용 효율적인 지역을 선택합니다. 비용, 대기 시간 및 규정 준수 요구 사항을 평가하여 워크로드를 비용 효율적으로 실행하고 고객에게 영향을 주지 않거나 추가 네트워킹 요금을 부과하지 않도록 합니다. Azure에서 워크로드를 배포하는 지역은 비용에 큰 영향을 줄 수 있습니다. 여러 요인으로 인해 리소스 비용은 Azure의 각 지역에 따라 달라집니다.

    새 노드에서 해당 이미지를 다운로드해야 하므로 비용을 절감할 수 있도록 작고 최적화된 이미지를 유지 관리합니다. 애플리케이션이 시작될 때 사용자 요청 실패 또는 시간 제한이 초과 프로비전으로 이어질 수 있습니다. 오류 및 시간 제한을 방지하기 위해 컨테이너를 가능한 한 빨리 시작할 수 있는 방식으로 이미지를 빌드합니다.

    Azure Monitor Kubernetes를 모니터링하기 위한 모범 사례의 비용 최적화 권장 사항을 검토하여 워크로드에 가장 적합한 모니터링 전략을 결정합니다. CPU, 메모리, 스토리지 및 네트워크부터 성능 메트릭을 분석하여 클러스터, 노드 및 네임스페이스별로 비용 최적화 기회를 식별합니다.

  • (클러스터 및 워크로드) 워크로드 크기 조정 비용을 최적화합니다. 모든 워크로드 요구 사항을 충족하면서 크기 조정 비용을 줄이기 위해 대체 수직 및 수평 크기 조정 구성을 고려합니다. 자동 크기 조정기를 사용하여 워크로드가 덜 활성화된 경우 규모를 확장합니다.

  • (클러스터 및 워크로드) 비용 데이터를 수집하고 분석합니다. 비용 최적화를 사용하도록 설정하는 기초는 비용 절감 클러스터의 확산입니다. 재무, 운영 및 엔지니어링 팀 간의 협업을 포함하는 비용 효율성 사고 방식을 개발하여 비용 절감 목표를 조정하고 클라우드 비용에 투명성을 제공합니다.

권장 사항

추천 장점
(클러스터 및 워크로드) AKS SKU 선택 및 관리형 디스크 크기를 워크로드 요구 사항에 맞춥니다. 선택 항목을 워크로드 요구와 일치하면 불필요한 리소스에 대한 비용을 지불하지 않도록 할 수 있습니다.
(클러스터) AKS 노드 풀적합한 VM 인스턴스 유형을 선택합니다.

올바른 VM 인스턴스 유형을 확인하려면 워크로드 특성, 리소스 요구 사항 및 가용성 요구 사항을 고려합니다.		 올바른 VM 인스턴스 유형을 선택하는 것은 AKS에서 애플리케이션을 실행하는 데 드는 비용에 직접적인 영향을 주므로 매우 중요합니다. 적절한 사용률 없이 고성능 인스턴스를 선택하면 지출 낭비가 발생할 수 있습니다. 덜 강력한 인스턴스를 선택하면 성능 문제가 발생하며 가동 중지 시간이 증가할 수 있습니다.
(클러스터) 더 효율적인 Azure Resource Manager 아키텍처에 따라 VM을 선택합니다. AKS는 Arm64 노드 풀을 만들고 클러스터 내에서 Intel 및 Resource Manager 아키텍처 노드를 혼합하여 만드는 지원합니다. Arm64 아키텍처는 낮은 전력 사용률과 효율적인 컴퓨팅 성능으로 인해 더 나은 가격 대 성능 비율을 제공합니다. 이러한 기능은 더 낮은 비용으로 더 나은 성능을 가져올 수 있습니다.
(클러스터) 클러스터 자동 크기 조정기 사용하도록 설정하여 과도한 리소스 용량에 대한 응답으로 에이전트 노드 수를 자동으로 줄입니다. AKS 클러스터의 노드 수를 자동으로 축소하면 수요가 낮을 때 효율적인 클러스터를 실행하고 수요가 증가할 때 확장할 수 있습니다.
(클러스터) 노드 자동 프로비전 사용하도록 설정하여 VM SKU 선택을 자동화합니다. 노드 자동 프로비전은 SKU 선택 프로세스를 간소화하고 보류 중인 Pod 리소스 요구 사항에 따라 워크로드를 가장 효율적이고 비용 효율적인 방식으로 실행하기 위한 최적의 VM 구성을 결정합니다.
(워크로드) HorizontalPodAutoscaler 사용하여 CPU 사용률 또는 기타 메트릭에 따라 배포의 Pod 수를 조정합니다. 수요가 낮을 때 Pod 수를 자동으로 축소하고 수요가 증가할 때 스케일 아웃하면 워크로드의 더 비용 효율적인 운영이 가능합니다.
(워크로드) VerticalPodAutoscaler(미리 보기)를 사용하여 Pod의 크기를 적절히 조정하고, 기록된 사용량에 따라 요청 및 제한을 동적으로 설정합니다. VerticalPodAutoscaler는 각 워크로드에 대한 컨테이너에 대한 리소스 요청 및 제한을 설정하여 다른 Pod에 대한 CPU 및 메모리를 확보하고 AKS 클러스터의 효과적인 사용률을 보장합니다.
(클러스터) AKS 비용 분석 추가 기능을 구성합니다. 비용 분석 클러스터 확장을 사용하면 클러스터 또는 네임스페이스의 다양한 Kubernetes 리소스와 연결된 비용에 대한 세분화된 인사이트를 얻을 수 있습니다.

운영 우수성

운영 우수성은 주로 개발 사례, 관찰 가능성 및 릴리스 관리대한 절차에 중점을 둡니다.

운영 우수성 디자인 원칙은 워크로드의 운영 요구 사항에 대한 이러한 목표를 달성하기 위한 높은 수준의 디자인 전략을 제공할 있습니다.

디자인 검사 목록

가시성, 테스트 및 배포를 위한 프로세스를 정의하기 위한 운영 우수성 대한 디자인 검토 검사 목록을 기반으로 디자인 전략을 시작합니다. AKS 모범 사례 및 Day-2 작업 가이드 참조하여 이해하고 구현할 주요 고려 사항에 대해 알아봅니다.

  • (클러스터) IaC(Infrastructure as code) 배포 방법을 구현합니다. Bicep, Terraform 또는 유사한 도구를 사용하여 선언적 템플릿 기반 배포 방법을 사용합니다. 모든 배포가 반복 가능하고 추적 가능하며 소스 코드 리포지토리에 저장되어 있는지 확인합니다. 자세한 내용은 AKS 제품 설명서의 빠른 시작 참조하세요.

  • (클러스터 및 워크로드) 인프라 및 워크로드 배포를 자동화합니다. 표준 소프트웨어 솔루션을 사용하여 클러스터 및 워크로드의 배포를 관리, 통합 및 자동화합니다. 배포 파이프라인을 소스 제어 시스템과 통합하고 자동화된 테스트를 통합합니다.

    클러스터가 필수적인 클러스터 전반의 구성 및 배포로 초기 설정되도록 자동화된 프로세스를 구축합니다. 이 프로세스는 일반적으로 GitOps를 사용하여 수행됩니다.

    소프트웨어 개발 수명 주기 내에서 워크로드에 대해 반복 가능하고 자동화된 배포 프로세스를 사용합니다.

  • (클러스터 및 워크로드) 포괄적인 모니터링 전략을 구현합니다. 로그 및 메트릭을 수집하여 워크로드의 상태를 모니터링하고, 성능 및 안정성 추세를 식별하고, 문제를 해결합니다. Azure Monitor 사용하여 Kubernetes를 모니터링하기 위한 모범 사례와 모니터링 시스템 디자인 및 만들기 위한 Well-Architected 권장 사항을 검토하여 워크로드에 가장 적합한 모니터링 전략을 결정합니다.

    진단 설정을 사용하도록 설정하여 컨트롤 플레인 또는 코어 API 서버 상호 작용이 기록되도록 합니다.

    워크로드는 수집할 수 있는 원격 분석을 내보내도록 설계되어야 하며, 여기에는 활동성 및 준비 상태도 포함되어야 합니다.

  • (클러스터 및 워크로드) 프로덕션 전략에서 테스트를 구현합니다. 프로덕션의 테스트는 실제 배포를 사용하여 프로덕션 환경에서 애플리케이션의 동작 및 성능을 확인하고 측정합니다. Kubernetes를 대상으로 하는 비정상 상황 엔지니어링 사례를 사용하여 애플리케이션 또는 플랫폼 안정성 문제를 식별합니다.

    Azure Chaos Studio는 오류를 시뮬레이션하고 재해 복구 상황을 유도하는 데 도움이 될 수 있습니다.

  • (클러스터 및 워크로드) 워크로드 거버넌스를 적용합니다. Azure Policy는 조직 표준을 일관되게 준수하고, 정책 적용을 자동화하며, 클러스터 리소스에 대한 중앙 집중식 가시성 및 제어를 제공합니다.

    AKS에 사용 가능한 기본 제공 정책에 대해 자세히 알아보려면 Azure 정책 섹션을 검토하세요.

  • (클러스터 및 워크로드) 중요 업무용 워크로드에 스탬프 수준, 파란색-녹색 배포 사용합니다. 스탬프 수준, 파란색-녹색 배포 접근 방식은 변경 내용을 릴리스하는 데 대한 신뢰를 높이고 Azure 플랫폼, 리소스 공급자 및 IaC 모듈과 같은 다운스트림 종속성과 호환성을 확인할 수 있으므로 가동 중지 시간 업그레이드를 사용하지 않을 수 있습니다.

    Kubernetes 및 수신 컨트롤러는 릴리스 엔지니어링 프로세스에 포함할 수 있는 많은 고급 배포 패턴을 지원합니다. 파란색-녹색 배포 또는 카나리아 릴리스와 같은 패턴을 고려합니다.

  • (클러스터 및 워크로드) 워크로드를 보다 지속 가능하게 만듭니다. 워크로드를 보다 지속 가능하고 클라우드 효율적인 만들려면 비용 최적화, 탄소 배출을 줄이고 에너지 소비 최적화하는노력을 결합해야 합니다. 애플리케이션 비용을 최적화하는 것은 워크로드를 보다 지속 가능하게 만드는 초기 단계입니다.

    지속 가능하고 효율적인 AKS 워크로드를 빌드하는 방법을 알아보려면 AKS 지속 가능한 소프트웨어 엔지니어링 원칙을 참조하세요.

권장 사항

추천 장점
(클러스터) AKS Azure 정책을 사용하여 클러스터 및 Pod 구성 표준을 운영합니다. AKS에 대한 Azure 정책은 중앙 집중식으로 일관된 방식으로 클러스터에 대규모 적용 및 보호 기능을 적용하는 데 도움이 될 수 있습니다. 정책을 사용하여 Pod에 부여된 권한을 정의하고 회사 정책을 준수하는지 확인합니다.
(워크로드) Kubernetes Event Driven Autoscaler (KEDA)을 사용합니다. KEDA를 사용하면 처리 중인 이벤트 수와 같은 이벤트에 따라 애플리케이션의 크기를 조정할 수 있습니다. 50개 이상의 KEDA 스칼라로 구성된 풍부한 카탈로그 중에서 선택할 수 있습니다.

성능 효율성

성능 효율성은 용량을 관리하여 부하 증가하는 경우에도 사용자 환경을 유지 관리합니다. 이 전략에는 리소스 크기 조정, 잠재적인 병목 현상 식별 및 최적화, 최고 성능 최적화가 포함됩니다.

성능 효율성 디자인 원칙은 예상 사용량에 따른 용량 목표를 달성하기 위한 고수준의 설계 전략을 제공합니다.

디자인 검사 목록

AKS의 주요 성과 지표를 기반으로 기준을 정의하기 위한 성능 효율성 대한 디자인 검토 검사 목록을 기반으로 디자인 전략을 시작합니다.

  • (클러스터 및 워크로드) 용량 계획을 수행합니다. SKU, 자동 크기 조정 설정, IP 주소 지정 및 장애 조치(failover) 고려 사항을 포함하는 자세한 용량 계획 연습을 수행하고 반복합니다.

    용량 계획을 공식화한 후 클러스터의 리소스 사용률을 지속적으로 관찰하여 계획을 자주 업데이트합니다.

  • (클러스터) 크기 조정 전략을 정의합니다. 과용 또는 낭비 없이 워크로드 요구를 충족하도록 리소스가 효율적으로 조정되도록 크기 조정을 구성합니다. 클러스터 자동 크기 조정 및 HorizontalPodAutoscaler와 같은 AKS 기능을 사용하여 작업에 대한 부담을 줄이면 워크로드 요구 사항을 동적으로 충족할 수 있습니다. 컨테이너에서 효율적으로 작동하고 배포하도록 워크로드를 최적화합니다.

    크기 조정 및 분할 가이드를 검토하여 크기 조정 구성의 다양한 측면을 이해합니다.

  • (클러스터 및 워크로드) 성능 테스트를 수행합니다. Pod 및 클러스터 자동 크기 조정기를 모두 실행하는 지속적인 부하 테스트 작업을 수행합니다. 성능 목표 및 설정된 기준과 결과를 비교합니다.

  • (클러스터 및 워크로드) 워크로드 및 흐름의 크기를 독립적으로 조정합니다. 독립 크기 조정을 허용하도록 워크로드와 흐름을 서로 다른 노드 풀로 분리합니다. 흐름 사용하여 워크로드 디자인 최적화 지침을 따라 흐름을 식별하고 우선 순위를 지정합니다.

권장 사항

추천 장점
(클러스터) 클러스터 자동 크기 조정기 사용하여 워크로드 요구에 따라 에이전트 노드 수를 자동으로 조정합니다.

HorizontalPodAutoscaler 사용하여 CPU 사용률 또는 기타 메트릭에 따라 배포의 Pod 수를 조정합니다.		 AKS 클러스터의 노드 수와 Pod 수를 자동으로 확장하거나 축소할 수 있으므로 효율적이고 비용 효율적인 클러스터를 실행할 수 있습니다.
(클러스터 및 워크로드) 워크로드를 서로 다른 노드 풀로 분리하고, 사용자 노드 풀 의 크기를 조정하는 것을으로 고려합니다. 항상 실행 중인 노드가 필요한 시스템 노드 풀과 달리 사용자 노드 풀을 사용하면 규모를 확장하거나 축소할 수 있습니다.
(워크로드) AKS 고급 스케줄러 기능 사용하여 필요한 워크로드에 대한 리소스의 고급 분산을 구현합니다. AKS 클러스터를 관리할 때 팀과 워크로드를 격리해야 하는 경우가 많습니다. Kubernetes 스케줄러가 제공하는 고급 기능을 사용하면 특정 노드에서 예약할 수 있는 파드를 제어할 수 있습니다. 또한 다중 포드 애플리케이션을 클러스터 전체에 적절하게 배포할 수 있는 방법을 제어할 수 있습니다.
(워크로드) KEDA 사용하여 워크로드와 관련된 신호를 기반으로 의미 있는 자동 크기 조정 규칙 집합을 빌드합니다. 모든 크기 조정 결정은 CPU 또는 메모리 메트릭에서 파생될 수 없습니다. 크기 조정 고려 사항은 더 복잡하거나 외부 데이터 요소에서 발생하는 경우가 많습니다. KEDA를 사용하면 큐의 메시지 수 또는 토픽 지연 기간과 같은 이벤트에 따라 애플리케이션의 크기를 조정할 수 있습니다.

Azure 정책

Azure는 일반적인 Azure 정책 및 Kubernetes용 Azure Policy 추가 기능 및 클러스터 내에서 Azure 리소스에 적용되는 AKS와 관련된 광범위한 기본 제공 정책 집합을 제공합니다. 대부분의 Azure 리소스 정책은 감사/거부 배포 변형에 제공됩니다. 기본 제공 Azure Policy 정의 외에도 AKS 리소스와 Kubernetes용 Azure Policy 추가 기능에 대한 사용자 지정 정책을 만들 수 있습니다.

이 문서의 권장 사항 중 일부는 Azure Policy를 통해 감사할 수 있습니다. 예를 들어 다음 클러스터 정책을 확인할 수 있습니다.

  • 클러스터에는 Pod 사양에 대해 구성된 준비 상태 또는 활동성 상태 프로브가 있습니다.
  • 클라우드 기반 정책용 Microsoft Defender.
  • 인증 모드 및 구성 정책(예: Microsoft Entra ID, RBAC 및 로컬 인증 사용 안 함).
  • 프라이빗 클러스터를 포함한 API 서버 네트워크 액세스 정책
  • GitOps 구성 정책.
  • 진단 설정 정책.
  • AKS 버전 제한.
  • 명령 호출을 방지합니다.

다음 클러스터 및 워크로드 정책을 확인할 수도 있습니다.

  • Linux 기반 워크로드를 위한 Kubernetes 클러스터의 Pod 보안 이니셔티브.
  • AppArmor, sysctl, 보안 캡, SELinux, seccomp, 권한 있는 컨테이너 및 자동 탑재 클러스터 API 자격 증명과 같은 Pod 및 컨테이너 기능 정책을 포함합니다.
  • 탑재, 볼륨 드라이버 및 파일 시스템 정책
  • 호스트 네트워크, 포트, 허용되는 외부 IP, HTTP 및 내부 부하 분산 장치와 같은 Pod 및 컨테이너 네트워킹 정책
  • 네임스페이스 배포 제한.
  • CPU 및 메모리 리소스 제한.

포괄적인 거버넌스를 위해 Kubernetes 대한 Azure Policy 기본 제공 정의 및 컴퓨팅 계층의 보안에 영향을 줄 수 있는 기타 정책을 검토합니다.

Azure Advisor 권장 사항

Azure Advisor는 모범 사례를 따라 Azure 배포를 최적화하는 데 도움이 되는 개인 설정된 클라우드 컨설턴트입니다. AKS의 안정성, 보안, 비용 효율성, 성능 및 운영 우수성을 개선하는 데 도움이 되는 몇 가지 권장 사항은 다음과 같습니다.

관련 콘텐츠

다음 문서를 이 문서에서 강조 표시된 권장 사항을 보여 주는 리소스로 간주합니다.

다음 제품 설명서를 사용하여 구현 전문 지식을 구축합니다.

  • AKS 제품 설명서