Azure Well-Architected Framework 검토 - AKS(Azure Kubernetes Service)

  • 아티클

이 문서에서는 AKS(Azure Kubernetes Service)에 대한 아키텍처 모범 사례를 제공합니다. 이 지침은 아키텍처 우수성의 5가지 핵심 요소에 기반합니다.

  • 안정성
  • 보안
  • 비용 최적화
  • 운영 우수성
  • 성능 효율성

시스템 디자인 원칙을 이해하고, Azure Kubernetes Service 대한 실무 지식을 가지고 있으며, 해당 기능에 정통한 것으로 가정합니다. 자세한 내용은 Azure Container Service를 참조하세요.

사전 요구 사항

Well-Architected 프레임워크 핵심 요소 이해는 고품질의 안정적이고 효율적인 클라우드 아키텍처를 생성하는 데 도움이 될 수 있습니다. Azure Well-Architected Framework 검토 평가를 사용하여 워크로드를 검토하는 것이 좋습니다.

컨텍스트의 경우 디자인에서 이러한 고려 사항을 반영하는 참조 아키텍처를 검토하는 것이 좋습니다. AZURE KUBERNETES SERVICE AKS(Azure Kubernetes Service) 클러스터 및 마이크로 서비스 아키텍처에 대한 기준 아키텍처부터 시작하는 것이 좋습니다. 또한 AKS(확장 가능한 Azure Kubernetes Service) 클러스터에 대한 랜딩 존 구독을 준비하는 아키텍처 접근 방식 및 참조 구현을 제공하는 AKS 랜딩 존 가속기를 검토합니다.

안정성

클라우드에서도 오류가 발생한다는 것을 인정합니다. 목표는 모든 장애를 막는 것이 아니라 단일 장애 구성 요소의 영향을 최소화하는 것입니다. 다음 정보를 사용하여 실패한 인스턴스를 최소화합니다.

Azure Kubernetes Service 안정성에 대해 논의할 때 클러스터 안정성과 워크로드 안정성을 구분하는 것이 중요합니다. 클러스터 안정성은 클러스터 관리자와 해당 리소스 공급자 간의 공동 책임이며 워크로드 안정성은 개발자의 도메인입니다. Azure Kubernetes Service 이러한 두 역할에 대한 고려 사항 및 권장 사항이 있습니다.

아래 의 디자인 검사 목록 및 권장 사항 목록에서 각 선택이 클러스터 아키텍처, 워크로드 아키텍처 또는 둘 다에 적용 가능한지 여부를 나타내기 위해 호출이 수행됩니다.

디자인 검사 목록

  • 클러스터 아키텍처: 중요한 워크로드의 경우 AKS 클러스터 에 대한 가용성 영역을 사용합니다.
  • 클러스터 아키텍처: 다중 클러스터 토폴로지에서 장애 조치(failover) 트래픽 처리를 포함하여 클러스터의 크기를 안정적으로 조정할 수 있도록 IP 주소 공간을 계획합니다.
  • 클러스터 아키텍처:컨테이너 인사이트를 사용하도록 설정하여 클러스터를 모니터링하고 안정성에 영향을 미치는 이벤트에 대한 경고를 구성합니다.
  • 워크로드 아키텍처: 수평 크기 조정을 지원하고 애플리케이션 준비 상태 및 상태를 보고하도록 워크로드가 빌드되었는지 확인합니다.
  • 클러스터 및 워크로드 아키텍처: 워크로드가 사용자 노드 풀에서 실행되고 있는지 확인하고 올바른 크기 SKU를 선택했습니다. 최소한 사용자 노드 풀에 대한 노드 2개와 시스템 노드 풀의 노드 3개를 포함합니다.
  • 클러스터 아키텍처: AKS 작동 시간 SLA를 사용하여 프로덕션 워크로드에 대한 가용성 목표를 충족합니다.

AKS 구성 권장 사항

안정성을 위해 AKS 구성을 최적화하려면 다음 권장 사항 표를 살펴보세요.

권장 이점
클러스터 및 워크로드 아키텍처: 노드 선택기 및 선호도를 사용하여 Pod 예약을 제어합니다. Kubernetes 스케줄러가 노드의 하드웨어를 기준으로 워크로드를 논리적으로 격리하도록 허용합니다. 허용과 달리 일치하는 노드 선택기가 없는 Pod는 레이블이 지정된 노드에서 예약할 수 있습니다. 이를 통해 노드에서 사용되지 않는 리소스를 사용할 수 있지만 일치하는 노드 선택기를 정의하는 Pod에 우선 순위를 부여합니다. 더 많은 유연성을 제공하는 노드 선호도를 사용하면 Pod를 노드와 매칭할 수 없을 경우 발생하는 상황을 정의할 수 있습니다.
클러스터 아키텍처: 네트워크 요구 사항 및 클러스터 크기 조정에 따라 네트워크 플러그 인을 적절하게 선택해야 합니다. Azure CNI는 특정 시나리오(예: Windows 기반 노드 풀, 특정 네트워킹 요구 사항 및 Kubernetes 네트워크 정책)에 필요합니다. 자세한 내용은 Kubenet과 Azure CNI 를 참조하세요.
클러스터 및 워크로드 아키텍처: 프로덕션 등급 클러스터에 AKS 작동 시간 SLA 를 사용합니다. AKS 작동 시간 SLA는 다음을 보장합니다.
- Azure 가용성 영역을 사용하는 AKS 클러스터에 대한 Kubernetes API 서버 엔드포인트의 99.95% 가용성 또는
- Azure 가용성 영역을 사용하지 않는 AKS 클러스터에 대한 99.9% 가용성.
클러스터 및 워크로드 아키텍처:컨테이너 인사이트를 사용하여 클러스터 모니터링을 구성합니다. 컨테이너 인사이트는 메트릭 API를 통해 Kubernetes에서 사용할 수 있는 컨트롤러, 노드 및 컨테이너의 상태 및 성능을 모니터링하는 데 도움이 됩니다. Prometheus와 통합하면 애플리케이션 및 워크로드 메트릭을 수집할 수 있습니다.
클러스터 아키텍처:가용성 영역을 사용하여 물리적으로 분리된 데이터 센터에 AKS 에이전트 노드를 배포하여 Azure 지역 내에서 복원력을 최대화합니다. 여러 영역에 노드 풀을 분산하면 한 노드 풀의 노드는 다른 영역이 중단된 경우에도 계속 실행됩니다. 공동성 요구 사항이 있는 경우 단일 영역에 대한 일반 VMSS 기반 AKS 배포 또는 근접 배치 그룹을 사용하여 노드 간 대기 시간을 최소화할 수 있습니다.
클러스터 아키텍처: 가용성을 최대화하고 비즈니스 연속성을 제공하기 위해 여러 Azure 지역에 배포된 AKS 클러스터를 배포하여 다중 리전 전략을 채택합니다. 인터넷 연결 워크로드는 Azure Front Door 또는 Azure Traffic Manager 를 활용하여 AKS 클러스터 간에 트래픽을 전역적으로 라우팅해야 합니다.
클러스터 및 워크로드 아키텍처: 애플리케이션 배포 매니페스트에서 Pod 리소스 요청 및 제한을 정의하고 Azure Policy 적용합니다. Kubernetes 클러스터의 리소스 소모를 방지하려면 컨테이너 CPU 및 메모리 리소스 제한이 필요합니다.
클러스터 및 워크로드 아키텍처: 시스템 노드 풀을 애플리케이션 워크로드와 격리된 상태로 유지합니다. 시스템 노드 풀에는 2개 이상의 vCPU 및 4GB 메모리의 VM SKU가 필요하지만 4개 이상의 vCPU를 사용하는 것이 좋습니다. 자세한 요구 사항은 시스템 및 사용자 노드 풀을 참조하세요.
클러스터 및 워크로드 아키텍처: 특정 요구 사항에 따라 애플리케이션을 전용 노드 풀로 구분합니다. 애플리케이션은 동일한 구성을 공유할 수 있으며 GPU 지원 VM, CPU 또는 메모리 최적화 VM 또는 0으로 스케일링할 수 있는 기능이 필요할 수 있습니다. 추가 관리 오버헤드를 줄이기 위해 많은 수의 노드 풀을 방지합니다.
클러스터 아키텍처: 여러 개의 동시 아웃바운드 연결을 만드는 워크로드를 실행하는 클러스터에 NAT 게이트웨이를 사용합니다. 동시 아웃바운드 트래픽이 많은 Azure Load Balancer 제한 사항과 관련된 안정성 문제를 방지하기 위해 NAT 게이트웨이 대신 안정적인 송신 트래픽을 대규모로 지원합니다.

자세한 제안은 안정성 핵심 요소의 원칙을 참조하세요.

Azure Policy

Azure Kubernetes Service 일반적인 Azure Policy와 같은 Azure 리소스와 클러스터 내에서 Kubernetes에 대한 Azure Policy 추가 기능을 사용하는 다양한 기본 제공 Azure 정책을 제공합니다. 다양한 정책이 있으며 이 핵심 요소와 관련된 주요 정책은 여기에 요약되어 있습니다. 자세한 내용은 Kubernetes에 대한 기본 제공 정책 정의를 참조하세요.

클러스터 및 워크로드 아키텍처

  • 클러스터에는 Pod 사양에 대해 구성된 준비 상태 또는 활동성 상태 프로브 가 있습니다.

기본 제공 Azure Policy 정의 외에도 AKS 리소스와 Kubernetes용 Azure Policy 추가 기능에 대해 사용자 지정 정책을 만들 수 있습니다. 이렇게 하면 클러스터 및 워크로드 아키텍처에서 적용하려는 안정성 제약 조건을 추가할 수 있습니다.

보안

보안은 아키텍처에서 가장 중요한 요소입니다. AKS가 애플리케이션 워크로드의 보안을 강화하는 방법을 알아보려면 보안 디자인 원칙을 검토하는 것이 좋습니다. Azure Kubernetes Service 클러스터가 PCI-DSS 3.2.1(Payment Card Industry Data Security Standard)의 규정 요구 사항을 충족하는 중요한 워크로드를 실행하도록 설계되어야 하는 경우 PCI-DSS 3.2.1에 대한 AKS 규제 클러스터를 검토합니다.

AKS를 사용하는 DoD IL5(영향 수준 5) 지원 및 요구 사항에 대해 알아보려면 Azure Government IL5 격리 요구 사항을 검토하세요.

Azure Kubernetes Service 보안을 논의할 때 클러스터 보안과 워크로드 보안을 구분하는 것이 중요합니다. 클러스터 보안은 클러스터 관리자와 해당 리소스 공급자 간의 공동 책임이며 워크로드 보안은 개발자의 도메인입니다. Azure Kubernetes Service 이러한 두 역할에 대한 고려 사항 및 권장 사항이 있습니다.

아래 의 디자인 검사 목록 및 권장 사항 목록에서 각 선택이 클러스터 아키텍처, 워크로드 아키텍처 또는 둘 다에 적용 가능한지 여부를 나타내기 위해 호출이 수행됩니다.

디자인 검사 목록

  • 클러스터 아키텍처:관리 ID를 사용하여 서비스 원칙을 관리하고 회전하지 않도록 합니다.
  • 클러스터 아키텍처:최소 권한 액세스를 위해 Microsoft Entra ID Kubernetes RBAC(역할 기반 액세스 제어)를 사용하고 구성 및 비밀 액세스를 보호하기 위한 관리자 권한 부여를 최소화합니다.
  • 클러스터 아키텍처:Azure Sentinel을 사용하는 컨테이너에 Microsoft Defender 사용하여 클러스터 및 해당 컨테이너에서 실행되는 워크로드의 위협을 감지하고 신속하게 대응합니다.
  • 클러스터 아키텍처: 프라이빗 AKS 클러스터를 배포하여 API 서버에 대한 클러스터 관리 트래픽이 프라이빗 네트워크에 유지되도록 합니다. 또는 프라이빗이 아닌 클러스터에 API 서버 허용 목록을 사용합니다.
  • 워크로드 아키텍처: Web Application Firewall 사용하여 HTTP(S) 트래픽을 보호합니다.
  • 워크로드 아키텍처: 컨테이너 인식 검사로 CI/CID 파이프라인이 강화되었는지 확인합니다.

권장 사항

보안을 위해 AKS 구성을 최적화하려면 다음 권장 사항 표를 살펴봅니다.

권장 이점
클러스터 아키텍처: Microsoft Entra 통합을 사용합니다. Microsoft Entra ID 사용하면 ID 관리 구성 요소가 중앙 집중화됩니다. 사용자 계정 또는 그룹 상태의 변경 내용은 AKS 클러스터에 액세스할 때 자동으로 업데이트됩니다. Kubernetes 클러스터의 개발자 및 애플리케이션 소유자는 다양한 다른 리소스에 액세스해야 합니다.
클러스터 아키텍처: Azure Container Registry Microsoft Entra ID 인증합니다. AKS 및 Microsoft Entra ID 비밀을 사용하지 imagePullSecrets 않고 Azure Container Registry 인증할 수 있습니다. 자세한 내용은 Azure Kubernetes Service Azure Container Registry 인증을 참조하세요.
클러스터 아키텍처:프라이빗 AKS 클러스터를 사용하여 API 서버에 대한 네트워크 트래픽을 보호합니다. 기본적으로 노드 풀과 API 서버 간의 네트워크 트래픽은 Microsoft 백본 네트워크를 이동합니다. 프라이빗 클러스터를 사용하여 API 서버에 대한 네트워크 트래픽이 프라이빗 네트워크에만 유지되도록 할 수 있습니다.
클러스터 아키텍처: 프라이빗이 아닌 AKS 클러스터의 경우 API 서버 권한 있는 IP 범위를 사용합니다. 공용 클러스터를 사용하는 경우 권한 있는 IP 범위 기능을 사용하여 클러스터 API 서버에 연결할 수 있는 트래픽을 계속 제한할 수 있습니다. 배포 빌드 에이전트, 운영 관리 및 노드 풀의 송신 지점(예: Azure Firewall)의 공용 IP와 같은 원본을 포함합니다.
클러스터 아키텍처: Microsoft Entra RBAC를 사용하여 API 서버를 보호합니다. Kubernetes API 서버에 대한 액세스 보호는 클러스터를 보호하기 위해 수행할 수 있는 가장 중요한 작업 중 하나입니다. Kubernetes RBAC(역할 기반 액세스 제어)를 Microsoft Entra ID 통합하여 API 서버에 대한 액세스를 제어합니다. 로컬 계정을 사용하지 않도록 설정하여 Microsoft Entra ID 기반 ID를 사용하여 모든 클러스터 액세스를 적용합니다.
클러스터 아키텍처:Azure 네트워크 정책 또는 Calico를 사용합니다. 클러스터의 Pod 간에 네트워크 트래픽을 보호하고 제어합니다.
클러스터 아키텍처:Azure Policy 사용하여 클러스터 및 Pod를 보호합니다. Azure Policy 중앙 집중식으로 일관된 방식으로 클러스터에 대규모 적용 및 보호 기능을 적용하는 데 도움이 될 수 있습니다. 또한 어떤 기능이 Pod에 제공되는지, 어떤 것이 회사 정책과 충돌하는지 제어할 수 있습니다.
클러스터 아키텍처: 리소스에 대한 컨테이너 액세스를 보호합니다. 컨테이너가 수행할 수 있는 작업에 대한 액세스를 제한합니다. 최소 개수의 권한을 제공하고 루트 사용 또는 권한 상승을 방지합니다.
워크로드 아키텍처: Web Application Firewall 사용하여 HTTP(S) 트래픽을 보호합니다. 들어오는 트래픽에서 잠재적인 공격을 검색하려면 Azure Application Gateway 또는 Azure Front Door에서 WAF(Azure Web Application Firewall)와 같은 웹 애플리케이션 방화벽을 사용합니다.
클러스터 아키텍처: 클러스터 송신 트래픽을 제어합니다. 클러스터의 아웃바운드 트래픽이 Azure Firewall 또는 HTTP 프록시와 같은 네트워크 보안 지점을 통과하는지 확인합니다.
클러스터 아키텍처: Azure Key Vault 오픈 소스 Microsoft Entra 워크로드 ID 및 비밀 저장소 CSI 드라이버를 사용합니다. 강력한 암호화를 사용하여 Azure Key Vault 비밀, 인증서 및 연결 문자열을 보호하고 회전합니다. 액세스 감사 로그를 제공하고 핵심 비밀을 배포 파이프라인에서 유지합니다.
클러스터 아키텍처:컨테이너에 Microsoft Defender 사용합니다. 클러스터, 컨테이너 및 해당 애플리케이션의 보안을 모니터링하고 유지 관리합니다.

더 많은 제안 사항은 보안 핵심 요소의 원칙을 참조하세요.

Azure Advisor는 Azure Kubernetes 서비스를 보장하고 개선하는 데 도움이 됩니다. RBAC가 구성되지 않은 클러스터, Microsoft Defender 구성 누락, API 서버에 대한 무제한 네트워크 액세스와 같이 아래 정책 섹션에 나열된 항목의 하위 집합에 대한 권장 사항을 제공합니다. 마찬가지로 일부 Pod 보안 이니셔티브 항목에 대한 워크로드 권장 사항을 만듭니다. 권장 사항을 검토합니다.

정책 정의

Azure Policy 표준 정책 정의와 같은 Azure 리소스와 AKS 모두에 적용되고 클러스터 내에서 Kubernetes에 대한 Azure Policy 추가 기능을 사용하는 다양한 기본 제공 정책 정의를 제공합니다. 대부분의 Azure 리소스 정책은 Audit/Deny뿐만 아니라 Deploy If Not Exists 변형에도 제공됩니다.

다양한 정책이 있으며 이 핵심 요소와 관련된 주요 정책은 여기에 요약되어 있습니다. 자세한 내용은 Kubernetes에 대한 기본 제공 정책 정의를 참조하세요.

클러스터 아키텍처

  • 클라우드 기반 정책에 대한 Microsoft Defender
  • 인증 모드 및 구성 정책(Microsoft Entra ID, RBAC, 로컬 인증 사용 안 함)
  • 프라이빗 클러스터를 포함한 API Server 네트워크 액세스 정책

클러스터 및 워크로드 아키텍처

  • Kubernetes 클러스터 Pod 보안 이니셔티브 Linux 기반 워크로드
  • AppArmor, sysctl, security caps, SELinux, seccomp, privileged containers, automount cluster API 자격 증명과 같은 Pod 및 컨테이너 기능 정책 포함
  • 탑재, 볼륨 드라이버 및 파일 시스템 정책
  • 호스트 네트워크, 포트, 허용되는 외부 IP, HTTP 및 내부 부하 분산 장치와 같은 Pod/컨테이너 네트워킹 정책

Azure Kubernetes Service 배포는 Helm 차트 및 컨테이너 이미지에도 Azure Container Registry 사용합니다. Azure Container Registry 또한 보안 AKS 아키텍처를 보완하는 클라우드용 네트워크 제한, 액세스 제어 및 Microsoft Defender 걸쳐 있는 다양한 Azure 정책을 지원합니다.

기본 제공 정책 외에도 AKS 리소스와 Kubernetes용 Azure Policy 추가 기능에 대해 사용자 지정 정책을 만들 수 있습니다. 이렇게 하면 클러스터 및 워크로드 아키텍처에서 적용하려는 추가 보안 제약 조건을 추가할 수 있습니다.

자세한 제안은 AKS 보안 개념을 참조하고 CIS Kubernetes 벤치마크를 기반으로 보안 강화 권장 사항을 평가합니다.

비용 최적화

비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 개선하기 위해 다양한 구성 옵션과 권장 모범 사례를 이해하는 것입니다. 이 문서의 지침을 따르기 전에 다음 리소스를 검토하는 것이 좋습니다.

Azure Kubernetes Service 비용 최적화에 대해 논의할 때 클러스터 리소스 비용과워크로드 리소스 비용을 구분하는 것이 중요합니다. 클러스터 리소스는 클러스터 관리자와 해당 리소스 공급자 간의 공동 책임이며 워크로드 리소스는 개발자의 도메인입니다. Azure Kubernetes Service 이러한 두 역할에 대한 고려 사항 및 권장 사항이 있습니다.

디자인 검사 목록 및 권장 사항 목록에서 각 선택이 클러스터 아키텍처, 워크로드 아키텍처 또는 둘 다에 적용 가능한지 여부를 나타내기 위해 호출이 수행됩니다.

클러스터 비용 최적화를 위해 Azure 가격 계산기로 이동하여 사용 가능한 제품에서 Azure Kubernetes Service 선택합니다. 계산기에서 다양한 구성 및 결제 계획을 테스트할 수 있습니다.

디자인 검사 목록

  • 클러스터 아키텍처: 장기 용량이 필요한 노드 풀 및 예약 인스턴스당 적절한 VM SKU를 사용합니다.
  • 클러스터 및 워크로드 아키텍처: 적절한 관리 디스크 계층 및 크기를 사용합니다.
  • 클러스터 아키텍처: CPU, 메모리, 스토리지 및 네트워크부터 성능 메트릭을 검토하여 클러스터, 노드 및 네임스페이스별로 비용 최적화 기회를 식별합니다.
  • 클러스터 및 워크로드 아키텍처: 워크로드가 덜 활성화된 경우 자동 크기 조정기를 사용하여 스케일 인합니다.

권장 사항

비용을 위해 AKS 구성을 최적화하려면 다음 권장 사항 표를 살펴보세요.

권장 이점
클러스터 및 워크로드 아키텍처: SKU 선택 및 관리 디스크 크기를 워크로드 요구 사항에 맞춥니다. 선택 항목을 워크로드 요구와 일치하면 불필요한 리소스에 대한 비용을 지불하지 않습니다.
클러스터 아키텍처: 올바른 가상 머신 instance 유형을 선택합니다. 올바른 가상 머신 instance 유형을 선택하는 것은 AKS에서 애플리케이션을 실행하는 비용에 직접적인 영향을 주기 때문에 중요합니다. 적절한 사용률 없이 고성능 instance 선택하면 지출이 낭비되는 반면 강력한 instance 선택하면 성능 문제 및 가동 중지 시간이 증가할 수 있습니다. 올바른 가상 머신 instance 유형을 확인하려면 워크로드 특성, 리소스 요구 사항 및 가용성 요구 사항을 고려합니다.
클러스터 아키텍처:Arm 아키텍처에 따라 가상 머신을 선택합니다. AKS는 클러스터 내에서 ARM64 Ubuntu 에이전트 노드뿐만 아니라 더 낮은 비용으로 더 나은 성능을 가져올 수 있는 혼합 Intel 및 ARM 아키텍처 노드를 만드는 것을 지원합니다.
클러스터 아키텍처:Azure Spot Virtual Machines 선택합니다. 스폿 VM을 사용하면 상당한 할인을 통해 사용하지 않는 Azure 용량을 활용할 수 있습니다(종량제 가격에 비해 최대 90%). Azure에 용량이 다시 필요한 경우 Azure 인프라는 스폿 노드를 제거합니다.
클러스터 아키텍처: 적절한 지역을 선택합니다. 여러 요인으로 인해 리소스 비용은 Azure의 지역마다 다릅니다. 비용, 대기 시간 및 규정 준수 요구 사항을 평가하여 워크로드를 비용 효율적으로 실행하고 최종 사용자에게 영향을 주지 않거나 추가 네트워킹 요금을 만들지 않도록 합니다.
워크로드 아키텍처: 작고 최적화된 이미지를 유지 관리합니다. 이미지를 간소화하면 새 노드에서 이러한 이미지를 다운로드해야 하므로 비용을 절감할 수 있습니다. 애플리케이션이 시작되는 동안 사용자 요청 오류 또는 시간 제한을 방지할 수 있도록 가능한 한 빨리 컨테이너를 시작할 수 있는 방식으로 이미지를 빌드하여 잠재적으로 과잉 프로비전으로 이어질 수 있습니다.
클러스터 아키텍처:클러스터 자동 크기 조정기를 사용하도록 설정하여 과도한 리소스 용량에 대한 응답으로 에이전트 노드 수를 자동으로 줄입니다. AKS 클러스터의 노드 수를 자동으로 축소하면 수요가 낮을 때 효율적인 클러스터를 실행하고 수요가 반환되면 스케일 업할 수 있습니다.
클러스터 아키텍처:노드 자동 프로비전을 사용하도록 설정하여 VM SKU 선택을 자동화합니다. 노드 자동 프로비전은 SKU 선택 프로세스를 간소화하고 보류 중인 Pod 리소스 요구 사항에 따라 가장 효율적이고 비용 효율적인 방식으로 워크로드를 실행하는 최적의 VM 구성을 결정합니다.
워크로드 아키텍처:Horizontal Pod 자동 크기 조정기를 사용합니다. 클러스터 스케일 인 작업을 지원하는 CPU 사용률 또는 기타 선택 메트릭에 따라 배포의 Pod 수를 조정합니다.
워크로드 아키텍처:세로 Pod 자동 크기 조정기 (미리 보기)를 사용합니다. Pod의 권한을 부여하고 기록 사용에 따라 요청 및 제한을 동적으로 설정합니다.
워크로드 아키텍처:Kubernetes KEDA(이벤트 기반 자동 크기 조정 )를 사용합니다. 처리 중인 이벤트 수에 따라 크기를 조정합니다. 50개 이상의 KEDA 스칼라로 구성된 풍부한 카탈로그 중에서 선택합니다.
클러스터 및 워크로드 아키텍처: 클라우드 사용량의 소유권을 높이기 위해 클라우드 재무 분야 및 문화 관행을 채택합니다. 비용 최적화를 사용하도록 설정하는 기초는 비용 절감 클러스터의 확산입니다. 금융 운영 방법(FinOps)은 조직에서 클라우드 비용을 줄이는 데 종종 사용됩니다. 재무, 운영 및 엔지니어링 팀 간의 협업을 통해 비용 절감 목표를 조정하고 클라우드 비용에 투명성을 가져오는 관행입니다.
클러스터 아키텍처:Azure Reservations 또는 Azure 저축 플랜에 등록합니다. 용량을 적절하게 계획한 경우 워크로드가 예측 가능하고 장시간 존재하므로 Azure Reservation 또는 절약 플랜 에 등록하여 리소스 비용을 추가로 절감할 수 있습니다.
클러스터 아키텍처:컨테이너 인사이트를 사용하여 클러스터 모니터링을 구성합니다. 컨테이너 인사이트는 클러스터 유휴 및 할당되지 않은 리소스에 대한 실행 가능한 인사이트를 제공하는 데 도움이 됩니다. 또한 컨테이너 인사이트는 Prometheus 메트릭 수집을 지원하고 Azure Managed Grafana와 통합되어 애플리케이션 및 인프라에 대한 전체적인 보기를 가져옵니다.
클러스터 아키텍처:AKS 비용 분석 추가 기능을 구성합니다. 비용 분석 클러스터 확장을 사용하면 클러스터 또는 네임스페이스의 다양한 Kubernetes 리소스와 연결된 비용에 대한 세분화된 인사이트를 얻을 수 있습니다.

자세한 제안은 비용 최적화 핵심 요소의 원칙 및 Azure Kubernetes Service 비용 최적화를 참조하세요.

정책 정의

비용 최적화와 관련된 기본 제공 정책은 없지만 AKS 리소스와 Kubernetes용 Azure Policy 추가 기능에 대해 사용자 지정 정책을 만들 수 있습니다. 이렇게 하면 클러스터 및 워크로드 아키텍처에서 적용하려는 추가 비용 최적화 제약 조건을 추가할 수 있습니다.

클라우드 효율성

워크로드를 보다 지속 가능하고 클라우드 효율적으로 만들려면 비용 최적화, 탄소 배출 감소 및 에너지 소비 최적화와 관련된 노력을 결합해야 합니다. 애플리케이션 비용을 최적화하는 것은 워크로드를 보다 지속 가능하게 만드는 초기 단계입니다.

AKS(Azure Kubernetes Service 지속 가능한 소프트웨어 엔지니어링 원칙)에서 지속 가능하고 효율적인 AKS 워크로드를 빌드하는 방법을 알아봅니다.

운영 우수성

모니터링 및 진단은 매우 중요한 요소입니다. 성능 통계를 측정할 수 있을 뿐만 아니라 메트릭을 사용하여 문제를 신속하게 해결하고 수정할 수 있습니다. 운영 우수성 디자인 원칙 및2일차 운영 가이드를 검토하는 것이 좋습니다.

Azure Kubernetes Service 운영 우수성에 대해 논의할 때 클러스터 운영 우수성과 워크로드 운영 우수성을 구분하는 것이 중요합니다. 클러스터 작업은 클러스터 관리자와 해당 리소스 공급자 간의 공동 책임이며 워크로드 작업은 개발자의 도메인입니다. Azure Kubernetes Service 이러한 두 역할에 대한 고려 사항 및 권장 사항이 있습니다.

아래 의 디자인 검사 목록 및 권장 사항 목록에서 각 선택이 클러스터 아키텍처, 워크로드 아키텍처 또는 둘 다에 적용 가능한지 여부를 나타내기 위해 호출이 수행됩니다.

디자인 검사 목록

  • 클러스터 아키텍처: Bicep, Terraform 등을 사용하여 템플릿 기반 배포를 사용합니다. 모든 배포가 반복 가능하고 추적 가능하며 소스 코드 리포지토리에 저장되어 있는지 확인합니다.
  • 클러스터 아키텍처: 자동화된 프로세스를 빌드하여 클러스터가 필요한 클러스터 전체 구성 및 배포로 부트스트랩되도록 합니다. GitOps를 사용하여 수행하는 경우가 많습니다.
  • 워크로드 아키텍처: 소프트웨어 개발 수명 주기 내에서 워크로드에 대해 반복 가능하고 자동화된 배포 프로세스를 사용합니다.
  • 클러스터 아키텍처: 진단 설정을 사용하도록 설정하여 컨트롤 플레인 또는 핵심 API 서버 상호 작용이 기록되도록 합니다.
  • 클러스터 및 워크로드 아키텍처:컨테이너 인사이트를 사용하도록 설정하여 메트릭, 로그 및 진단 수집하여 클러스터에서 실행되는 클러스터 및 워크로드의 가용성과 성능을 모니터링합니다.
  • 워크로드 아키텍처: 워크로드는 수집할 수 있는 원격 분석을 내보내도록 설계되어야 하며, 여기에는 생계형 및 준비 상태도 포함되어야 합니다.
  • 클러스터 및 워크로드 아키텍처: Kubernetes를 대상으로 하는 비정상 상황 엔지니어링 사례를 사용하여 애플리케이션 또는 플랫폼 안정성 문제를 식별합니다.
  • 워크로드 아키텍처: 컨테이너에서 효율적으로 작동하고 배포하도록 워크로드를 최적화합니다.
  • 클러스터 및 워크로드 아키텍처: Azure Policy 사용하여 클러스터 및 워크로드 거버넌스를 적용합니다.

권장 사항

다음 권장 사항 표를 탐색하여 작업에 AKS 구성을 최적화합니다.

권장 이점
클러스터 및 워크로드 아키텍처:AKS 모범 사례 설명서를 검토합니다. AKS에서 애플리케이션을 성공적으로 빌드하고 실행하려면 이해하고 구현해야 하는 주요 고려 사항이 있습니다. 이러한 영역에는 다중 테넌트/스케줄러 기능, 클러스터와 함께 Pod 보안 또는 비즈니스 연속성 및 재해 복구가 포함됩니다.
클러스터 및 워크로드 아키텍처:Azure Chaos Studio를 검토합니다. Azure Chaos Studio는 오류를 시뮬레이션하고 재해 복구 상황을 트리거하는 데 도움이 될 수 있습니다.
클러스터 및 워크로드 아키텍처:컨테이너 인사이트를 사용하여 클러스터 모니터링을 구성합니다. 컨테이너 인사이트는 메트릭 API 및 컨테이너 로그를 통해 Kubernetes에서 사용할 수 있는 컨트롤러, 노드 및 컨테이너에서 메모리 및 프로세서 메트릭을 수집하여 컨테이너의 성능을 모니터링하는 데 도움이 됩니다.
워크로드 아키텍처: Azure Monitor를 사용하여 애플리케이션 성능을 모니터링합니다. AKS 클러스터에서 실행되는 애플리케이션의 코드 기반 모니터링을 위해 Application Insights 를 구성합니다.
워크로드 아키텍처: Container Insights를 사용하여 Prometheus 메트릭 스크래핑을 구성합니다. Azure Monitor의 일부인 컨테이너 인사이트는 Prometheus 메트릭을 수집하는 원활한 온보딩 환경을 제공합니다. 자세한 내용은 Prometheus 메트릭 스크래핑 구성을 참조하세요 .
클러스터 아키텍처: 가용성을 최대화하고 비즈니스 연속성을 제공하기 위해 여러 Azure 지역에 배포된 AKS 클러스터를 배포하여 다중 리전 전략을 채택합니다. 인터넷 연결 워크로드는 Azure Front Door 또는 Azure Traffic Manager 를 활용하여 AKS 클러스터 간에 트래픽을 전역적으로 라우팅해야 합니다.
클러스터 아키텍처:Azure Policy 사용하여 클러스터 및 Pod 구성 표준을 운영합니다. Azure Policy 중앙 집중식으로 일관된 방식으로 클러스터에 대규모 적용 및 보호 기능을 적용하는 데 도움이 될 수 있습니다. 또한 어떤 기능이 Pod에 제공되는지, 어떤 것이 회사 정책과 충돌하는지 제어할 수 있습니다.
워크로드 아키텍처: 릴리스 엔지니어링 프로세스에서 플랫폼 기능을 사용합니다. Kubernetes 및 수신 컨트롤러는 릴리스 엔지니어링 프로세스에 포함하기 위해 많은 고급 배포 패턴을 지원합니다. 파란색-녹색 배포 또는 카나리아 릴리스와 같은 패턴을 고려합니다.
클러스터 및 워크로드 아키텍처: 중요 업무용 워크로드의 경우 스탬프 수준 파란색/녹색 배포를 사용합니다. 배포 및 테스트를 포함하여 중요 업무용 디자인 영역을 자동화합니다.

더 많은 제안은 운영 우수성 핵심 요소의 원칙을 참조하세요.

또한 Azure Advisor는 지원되지 않는 AKS 버전 및 구성되지 않은 진단 설정과 같은 아래 정책 섹션에 나열된 항목의 하위 집합에 대한 권장 사항을 제공합니다. 마찬가지로 기본 네임스페이스 사용에 대한 워크로드 권장 사항을 만듭니다.

정책 정의

Azure Policy 표준 정책 정의와 같은 Azure 리소스와 AKS 모두에 적용되고 클러스터 내에서 Kubernetes에 대한 Azure Policy 추가 기능을 사용하는 다양한 기본 제공 정책 정의를 제공합니다. 대부분의 Azure 리소스 정책은 Audit/Deny뿐만 아니라 Deploy If Not Exists 변형에도 제공됩니다.

다양한 정책이 있으며 이 핵심 요소와 관련된 주요 정책은 여기에 요약되어 있습니다. 자세한 내용은 Kubernetes에 대한 기본 제공 정책 정의를 참조하세요.

클러스터 아키텍처

  • Kubernetes에 대한 추가 기능 Azure Policy
  • GitOps 구성 정책
  • 진단 설정 정책
  • AKS 버전 제한
  • 명령 호출 방지

클러스터 및 워크로드 아키텍처

  • 네임스페이스 배포 제한 사항

기본 제공 정책 외에도 AKS 리소스와 Kubernetes용 Azure Policy 추가 기능에 대해 사용자 지정 정책을 만들 수 있습니다. 이렇게 하면 클러스터 및 워크로드 아키텍처에서 적용하려는 추가 보안 제약 조건을 추가할 수 있습니다.

성능 효율성

성능 효율성은 사용자가 배치된 요구 사항을 효율적인 방식으로 충족하기 위해 워크로드의 크기를 조정할 수 있는 기능입니다. 성능 효율성 원칙을 검토하는 것이 좋습니다.

Azure Kubernetes Service 성능에 대해 논의할 때 클러스터 성능과 워크로드 성능을 구분하는 것이 중요합니다. 클러스터 성능은 클러스터 관리자와 해당 리소스 공급자 간의 공동 책임이며 워크로드 성능은 개발자의 도메인입니다. Azure Kubernetes Service 이러한 두 역할에 대한 고려 사항 및 권장 사항이 있습니다.

아래 의 디자인 검사 목록 및 권장 사항 목록에서 각 선택이 클러스터 아키텍처, 워크로드 아키텍처 또는 둘 다에 적용 가능한지 여부를 나타내기 위해 호출이 수행됩니다.

디자인 검사 목록

Azure Kubernetes Service 디자인 선택을 할 때 성능 효율성 원칙을 검토합니다.

  • 클러스터 및 워크로드 아키텍처: SKU, 자동 크기 조정 설정, IP 주소 지정 및 장애 조치(failover) 고려 사항을 포함하는 자세한 용량 계획 연습을 수행하고 반복합니다.
  • 클러스터 아키텍처:클러스터 자동 크기 조정기를 사용하도록 설정하여 응답 워크로드 요구에서 에이전트 노드 수를 자동으로 조정합니다.
  • 클러스터 아키텍처:Horizontal Pod 자동 크기 조정기를 사용하여 CPU 사용률 또는 기타 선택 메트릭에 따라 배포의 Pod 수를 조정합니다.
  • 클러스터 및 워크로드 아키텍처: Pod 및 클러스터 자동 크기 조정기를 모두 실행하는 지속적인 부하 테스트 작업을 수행합니다.
  • 클러스터 및 워크로드 아키텍처: 워크로드를 서로 다른 노드 풀로 분리하여 독립적인 스케일링을 허용합니다.

권장 사항

성능을 위해 Azure Kubernetes Service 구성을 최적화하려면 다음 권장 사항 표를 살펴보세요.

권장 이점
클러스터 및 워크로드 아키텍처: 자세한 용량 계획을 개발하고 지속적으로 검토하고 수정합니다. 용량 계획을 공식화한 후 클러스터의 리소스 사용률을 지속적으로 관찰하여 자주 업데이트해야 합니다.
클러스터 아키텍처:클러스터 자동 크기 조정기가 리소스 제약 조건에 대한 응답으로 에이전트 노드 수를 자동으로 조정하도록 설정합니다. AKS 클러스터에서 노드 수를 자동으로 스케일 업하거나 스케일 다운하는 이 기능을 통해 효율적이고 비용 효율적인 클러스터를 실행할 수 있습니다.
클러스터 및 워크로드 아키텍처: 워크로드를 다른 노드 풀로 분리하고 사용자 노드 풀 의 크기를 조정하는 것이 좋습니다. 항상 실행 중인 노드가 필요한 시스템 노드 풀과 달리 사용자 노드 풀을 사용하면 스케일 업 또는 다운할 수 있습니다.
워크로드 아키텍처: AKS 고급 스케줄러 기능을 사용합니다. 필요한 워크로드에 대한 리소스의 분산을 제어하는 데 도움이 됩니다.
워크로드 아키텍처: 의미 있는 워크로드 크기 조정 메트릭을 사용합니다. CPU 또는 메모리 메트릭에서 모든 크기 조정 결정을 파생할 수 있는 것은 아닙니다. 크기 조정 고려 사항은 더 복잡하거나 외부 데이터 요소에서 발생하는 경우가 많습니다. KEDA를 사용하여 워크로드와 관련된 신호를 기반으로 의미 있는 자동 크기 조정 규칙 집합을 빌드합니다.

자세한 제안은 성능 효율성 핵심 요소의 원칙을 참조하세요.

정책 정의

Azure Policy 표준 정책 정의와 같이 Azure 리소스와 AKS에 모두 적용되고 클러스터 내에서 Kubernetes에 대한 Azure Policy 추가 기능을 사용하는 다양한 기본 제공 정책 정의를 제공합니다. 대부분의 Azure 리소스 정책은 Audit/Deny뿐만 아니라 Deploy If Not Exists 변형에도 제공됩니다.

다양한 정책이 있으며 이 핵심 요소와 관련된 주요 정책은 여기에 요약되어 있습니다. 자세한 내용은 Kubernetes에 대한 기본 제공 정책 정의를 참조하세요.

클러스터 및 워크로드 아키텍처

  • CPU 및 메모리 리소스 제한

기본 제공 정책 외에도 AKS 리소스와 Kubernetes용 Azure Policy 추가 기능에 대한 사용자 지정 정책을 만들 수 있습니다. 이렇게 하면 클러스터 및 워크로드 아키텍처에서 적용하려는 추가 보안 제약 조건을 추가할 수 있습니다.

추가 리소스

Azure 아키텍처 센터 지침

클라우드 채택 프레임워크 지침

다음 단계