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

Azure Active Directory
Application Gateway
Bastion
Container Registry
방화벽
Key Vault
Kubernetes Service
Load Balancer
Monitor
정책
Private Link
Azure 역할 기반 액세스 제어

이 참조 아키텍처에서는 AKS(Azure Kubernetes Service) 클러스터를 배포하는 기준 인프라를 빌드합니다. 이 문서에는 조직의 비즈니스 요구 사항에 따라 클러스터의 네트워킹, 보안, ID, 관리 및 모니터링에 대한 권장 사항이 포함되어 있습니다.

GitHub 로고  AKS(Azure Kubernetes Service) 보안 기준 참조 구현 GitHub 이 아키텍처의 구현을사용할 수 있습니다. 이를 시작점으로 사용하고 필요에 따라 구성할 수 있습니다.

참고

이 참조 아키텍처에는 Kubernetes 및 해당 개념에 대한 지식이 필요합니다. 리프레셔가 필요한 경우 리소스에 대한 관련 문서 섹션을 참조하세요.

네트워크 토폴로지

이 아키텍처는 허브-스포크 네트워크 토폴로지입니다. 허브 및 스포크 는 피어링을통해 연결된 별도의 가상 네트워크에 배포됩니다. 이 토폴로지의 몇 가지 장점은 다음과 같습니다.

  • 분리된 관리. 이를 통해 거버넌스를 적용하고 방사형 반경을 제어할 수 있습니다. 또한 업무 분리를 통해 랜딩 존 개념을 지원합니다.

  • 공용 인터넷에 대한 Azure 리소스의 직접 노출을 최소화합니다.

  • 조직은 종종 지역 허브-스포크 토폴로지로 운영합니다. 허브-스포크 네트워크 토폴로지도 나중에 확장할 수 있으며 워크로드 격리를 제공할 수 있습니다.

  • 모든 웹 애플리케이션에는 HTTP 트래픽 흐름을 제어하는 데 도움이 되는 WAF(웹 애플리케이션 방화벽) 서비스가 필요합니다.

  • 여러 구독에 걸쳐 있는 워크로드에 대한 자연스러운 선택입니다.

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

  • 방화벽 및 DNS와 같은 특정 리소스는 네트워크 간에 공유할 수 있습니다.

허프 스포크 네트워크 토폴로지

허브

허브 가상 네트워크는 연결 및 관찰성의 중심점입니다. 네트워크 내에서 세 개의 서브넷이 배포됩니다.

호스트 Azure Firewall 서브넷

Azure Firewall 방화벽 서비스입니다. 방화벽 인스턴스는 아웃바운드 네트워크 트래픽을 보호합니다. 이 보안 계층이 없으면 흐름이 중요한 회사 데이터를 반출할 수 있는 악의적인 타사 서비스와 통신할 수 있습니다.

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

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

호스트 Azure Bastion 서브넷

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

이야기

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

호스트 Azure Application Gateway 서브넷

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

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

트래픽을 라우팅하고 분산하기 위해 Traefik는 Kubernetes 수신 리소스를 처리할 수신 컨트롤러입니다. Azure 내부 부하 분산은 이 서브넷에 있습니다.

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

AKS는 두 개의 개별 노드 그룹(또는 노드 풀)을 유지 관리합니다. 시스템 노드 풀은 핵심 클러스터 서비스를 실행하는 Pod를 호스트합니다. 사용자 노드 풀은 Contoso 워크로드 및 수신 컨트롤러를 실행하여 워크로드에 대한 인바운드 통신을 용이하게 합니다. 워크로드는 간단한 ASP.NET 애플리케이션입니다.

자세한 내용은 Azure의 허브-스포크 네트워크 토폴로지입니다.

IP 주소 계획

AKS 클러스터의 네트워크 토폴로지

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

  • 업그레이드

    AKS는 노드를 정기적으로 업데이트하여 기본 가상 머신이 보안 기능 및 기타 시스템 패치를 최신 상태로 유지하고 있는지 확인합니다. 업그레이드 프로세스 중에 AKS는 Pod를 일시적으로 호스트하는 노드를 만드는 반면 업그레이드 노드는 중단되고 드레인됩니다. 해당 임시 노드에는 클러스터 서브넷의 IP 주소가 할당됩니다.

    Pod의 경우 전략에 따라 추가 주소가 필요할 수 있습니다. 롤링 업데이트의 경우 실제 Pod가 업데이트되는 동안 워크로드를 실행하는 임시 Pod에 대한 주소가 필요합니다. 바꾸기 전략을 사용하면 Pod가 제거되고 새 Pod가 만들어집니다. 따라서 이전 Pod와 연결된 주소가 다시 사용됩니다.

  • 확장성

    모든 시스템 및 사용자 노드의 노드 수와 최대 확장성 제한을 고려합니다. 400% 규모 확장하려는 경우를 가정해 보겠습니다. 확장된 모든 노드에 대한 주소 수의 4배가 필요합니다.

    이 아키텍처에서는 각 Pod에 직접 연락할 수 있습니다. 따라서 각 Pod에는 개별 주소가 필요합니다. Pod 확장성은 주소 계산에 영향을 미칩니다. 이러한 결정은 증가하려는 Pod 수에 대한 선택에 따라 달라집니다.

  • Azure Private Link 주소

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

  • 특정 주소는 Azure에서 사용 하도록 예약 되어 있습니다. 할당할 수 없습니다.

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

이 아키텍처는 단일 작업을 위해 설계 되었습니다. 여러 워크 로드의 경우 사용자 노드 풀을 서로 격리 하 고 시스템 노드 풀에서 격리 하는 것이 좋습니다. 이 옵션을 선택 하면 크기가 더 작은 서브넷이 더 많이 발생할 수 있습니다. 또한 수신 리소스는 더 복잡할 수 있습니다. 추가 주소를 필요로 하는 수신 컨트롤러가 여러 개 필요할 수 있습니다.

이 아키텍처에 대 한 전체 고려 사항은 AKS 기본 설정 네트워크 토폴로지를 참조 하세요.

AKS 클러스터에 대 한 IP를 계획 하는 방법에 대 한 자세한 내용은 클러스터에 대 한 ip 주소 지정 계획을 참조 하세요.

컨테이너 이미지 참조

워크 로드 외에도 클러스터는 수신 컨트롤러와 같은 여러 다른 이미지를 포함할 수 있습니다. 이러한 이미지 중 일부는 공용 레지스트리에 있을 수 있습니다. 클러스터로 끌어올 때 이러한 사항을 고려 합니다.

  • 클러스터는 이미지를 가져오도록 인증 됩니다.

  • 공용 이미지를 사용 하는 경우 SLO에 맞는 컨테이너 레지스트리로 가져오는 것이 좋습니다. 그렇지 않으면 예기치 않은 가용성 문제가 이미지에 적용 될 수 있습니다. 이러한 문제로 인해 필요할 때 이미지를 사용할 수 없는 경우 작동 문제가 발생할 수 있습니다. 공용 레지스트리 대신 컨테이너 레지스트리를 사용할 경우의 몇 가지 이점은 다음과 같습니다.

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

    ACR (Azure Container Registry) 옵션입니다.

  • 권한 있는 레지스트리에서 이미지를 가져옵니다. Azure Policy를 통해이 제한을 적용할 수 있습니다. 이 참조 구현에서 클러스터는 아키텍처의 일부로 배포 된 ACR 에서만 이미지를 가져옵니다.

기본 클러스터에 대 한 계산 구성

AKS에서 각 노드 풀은 가상 머신 확장 집합에 매핑됩니다. 노드는 각 노드 풀의 Vm입니다. 비용을 최소화 하려면 시스템 노드 풀에 더 작은 VM 크기를 사용 하는 것이 좋습니다. 이 참조 구현은 3 개의 DS2_v2 노드를 사용 하 여 시스템 노드 풀을 배포 합니다. 이 크기는 시스템 pod의 예상 부하를 충족 하기에 충분 합니다. OS 디스크는 512 GB입니다.

사용자 노드 풀의 경우 다음과 같은 몇 가지 사항을 고려해 야 합니다.

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

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

  • 워크 로드에 대 한 실제 노드 크기는 디자인 팀에서 결정 하는 요구 사항에 따라 달라 집니다. 비즈니스 요구 사항에 따라 프로덕션 워크 로드에 대 한 DS4_v2를 선택 했습니다. 비용을 절감 하려면 최소 권장 사항인 DS3_v2 크기를 삭제할 수 있습니다.

  • 클러스터에 대 한 용량을 계획할 때 워크 로드에서 각 노드의 최대 80%까지 소비할 수 있다고 가정 합니다. 나머지 20%는 AKS 서비스용으로 예약 되어 있습니다.

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

클러스터에 대 한 Azure Active Directory 통합

클러스터에 대 한 액세스를 보호 하는 것은 매우 중요 합니다. 보안 옵션을 선택 하는 경우 클러스터의 관점을 고려 합니다.

  • 내부 액세스. 네트워킹 인프라, Azure Container Registry, Azure Key Vault 등의 Azure 구성 요소에 대 한 액세스를 AKS. 클러스터에서 액세스할 수 있는 리소스에만 권한을 부여 합니다.
  • 외부 액세스. Kubernetes 클러스터에 id 액세스를 제공 합니다. Kubernetes API 서버 및 Azure Resource Manager에 대 한 액세스를 허용 하는 외부 엔터티만 권한을 부여 합니다.

Azure에 대 한 AKS 액세스

azure AD (Azure Active Directory)를 통해 azure 액세스를 관리 하는 두 가지 방법이 있습니다. 서비스 사용자 또는 azure 리소스에 대 한 관리 되는 id 입니다.

두 가지 방법 중에서 관리 id를 권장 합니다. 서비스 사용자는 수동으로 또는 프로그래밍 방식으로 암호를 관리 하 고 회전 해야 합니다. Azure AD는 관리 되는 id를 사용 하 여 사용자에 대 한 암호를 적시에 관리 하 고 인증 합니다.

클러스터가 Azure AD를 통해 외부 Azure 리소스와 상호 작용할 수 있도록 관리 id를 사용 하도록 설정 하는 것이 좋습니다. 클러스터를 만드는 동안에만이 설정을 사용 하도록 설정할 수 있습니다. Azure AD를 즉시 사용 하지 않더라도 나중에 통합할 수 있습니다.

내부 외부 사례에 대 한 예로, 클러스터가 컨테이너 레지스트리에서 이미지를 가져와야 하는 경우 관리 id 사용을 검토해 보겠습니다. 이 작업을 수행 하려면 클러스터가 레지스트리의 자격 증명을 가져와야 합니다. 한 가지 방법은 해당 정보를 Kubernetes 암호 개체의 형태로 저장 하 고를 사용 하 여 암호를 검색 하는 것입니다 imagePullSecrets . 보안 복잡성 때문에이 방법을 사용 하지 않는 것이 좋습니다. 비밀에 대 한 사전 지식이 필요 하 고 DevOps 파이프라인을 통해 해당 비밀도 공개 해야 합니다. 또 다른 이유는 비밀의 회전을 관리 하는 작업 오버 헤드입니다. 대신, acrPull 클러스터의 관리 되는 id에 대 한 액세스 권한을 레지스트리에 부여 합니다. 이 방법은 이러한 문제를 해결 합니다.

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

  • 네트워크 참가자. 클러스터의 스포크 가상 네트워크 제어 기능입니다. 이 역할 할당을 통해 AKS 클러스터 시스템 할당 id는 내부 수신 컨트롤러 서비스에 대 한 전용 서브넷을 사용할 수 있습니다.
  • 모니터링 메트릭 Publisher. Azure Monitor에 메트릭을 전송 하는 클러스터의 기능입니다.
  • Acrpull. 지정 된 Azure Container registry에서 이미지를 가져오는 클러스터의 기능입니다.

클러스터 액세스

또한 Azure AD 통합은 외부 액세스에 대 한 보안을 간소화 합니다. 사용자가 kubectl를 사용 하려고 한다고 가정 합니다. 초기 단계로는 az aks get-credentials 명령을 보내 클러스터의 자격 증명을 가져옵니다. Azure AD는 클러스터 자격 증명을 가져올 수 있는 Azure 역할에 대해 사용자의 id를 인증 합니다. 자세한 내용은 사용 가능한 클러스터 역할 권한을 참조 하세요.

AKS는 두 가지 방법으로 Azure Active Directory를 사용 하 여 Kubernetes에 액세스할 수 있습니다. 첫 번째는 Azure Active Directory를 기본 Kubernetes RBAC 시스템과 통합 된 id 공급자로 사용 하는 것입니다. 다른 한 가지는 네이티브 Azure RBAC를 사용 하 여 클러스터 액세스를 제어 하는 것입니다. 두 가지 모두 아래에 자세히 설명 되어 있습니다.

Azure Active Directory에 Kubernetes RBAC 연결

Kubernetes는 다음을 통해 RBAC (역할 기반 액세스 제어)를 지원 합니다.

  • 사용 권한 집합입니다. Role ClusterRole 클러스터 전체 사용 권한에 대해 또는 개체에 의해 정의 됩니다.

  • 작업을 수행할 수 있는 사용자 및 그룹을 할당 하는 바인딩입니다. 또는 개체에 의해 정의 RoleBinding CluserRoleBinding 됩니다.

Kubernetes에는 클러스터 관리자, 편집, 보기 등의 몇 가지 기본 제공 역할이 있습니다. 엔터프라이즈 디렉터리를 사용 하 여 액세스를 관리할 수 있도록 Azure Active Directory 사용자 및 그룹에 해당 역할을 바인딩합니다. 자세한 내용은 AZURE AD 통합과 함께 KUBERNETES RBAC 사용을 참조 하세요.

클러스터 및 네임 스페이스 액세스에 사용 되는 Azure AD 그룹이 AZURE ad 액세스 검토에 포함 되어 있어야 합니다.

Kubernetes 권한 부여에 Azure RBAC 사용

통합 AAD 인증을 사용 하는 Kubernetes RBAC를 사용 하는 대신 Azure RBAC 및 역할 할당을 사용 하 여 클러스터 액세스를 적용 하는 것이 또 다른 옵션입니다. Azure RBAC를 사용 하는 경우 기본 Kubernetes RBAC 역할 및 역할 바인딩을 구성할 필요가 없다는 이점도 있습니다.

자세한 내용은 Azure 역할을 참조하세요.

로컬 계정

AKS는 기본 Kubernetes 사용자 인증을 지원 합니다. 이 방법을 사용 하는 클러스터에 대 한 사용자 액세스 액세스는 제안 되지 않습니다. 인증서 기반 이며 기본 id 공급자 외부에서 수행 됩니다. 중앙 집중식 사용자 액세스 제어 및 관리 작업을 어렵게 만듭니다. 항상 Azure Active Directory를 통해 클러스터에 대 한 액세스를 관리 하 고 로컬 계정 액세스를 명시적으로 사용 하지 않도록 클러스터를 구성 합니다.

이 참조 구현에서는 클러스터가 배포 될 때 로컬 클러스터 계정을 통한 액세스를 명시적으로 사용 하지 않도록 설정 합니다.

워크 로드에 대 한 Azure Active Directory 통합

전체 클러스터에 대해 Azure 관리 Id를 보유 하는 것과 마찬가지로 pod 수준에서 관리 되는 id를 할당할 수 있습니다. Pod 관리 id를 사용 하면 호스팅된 작업에서 Azure Active Directory 통해 리소스에 액세스할 수 있습니다. 예를 들어 작업은 Azure Storage 파일을 저장 합니다. 이러한 파일에 액세스 해야 하는 경우 pod는 리소스에 대해 자신을 인증 합니다.

이 참조 구현에서 관리 되는 pod id는 aad-pod id를 통해 쉽게 확인할 수 있습니다.

수신 리소스 배포

Kubernetes 수신 리소스는 들어오는 트래픽을 라우팅 하 고 클러스터로 배포 합니다. 수신 리소스에는 두 가지 부분이 있습니다.

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

    이 아키텍처에서는 Azure Load Balancer 사용 됩니다. 수신 리소스 전용 서브넷의 클러스터 외부에 배치 됩니다. Azure 애플리케이션 게이트웨이에서 트래픽을 수신 하 고 TLS를 통해 통신 하는 것입니다. 인바운드 트래픽에 대 한 TLS 암호화에 대 한 자세한 내용은 트래픽 흐름 수신을 참조 하세요.

  • 수신 컨트롤러. Traefik을 선택 했습니다. 클러스터의 사용자 노드 풀에서 실행 됩니다. 내부 부하 분산 장치에서 트래픽을 수신 하 고, TLS를 종료 하 고, HTTP를 통해 워크 로드 pod 전달 합니다.

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

  • 디자인 결정의 일환으로 수신 컨트롤러의 작동을 허용 하는 범위를 선택 합니다. 예를 들어 컨트롤러가 특정 워크 로드를 실행 하는 pod 상호 작용 하도록 허용할 수 있습니다.

  • 동일한 노드에 복제본을 배치 하 여 부하를 분산 하 고 노드가 종료 될 때 비즈니스 연속성을 보장 하지 않도록 합니다. podAntiAffinity이 목적을 위해를 사용 합니다.

  • Pod를 사용 하 여 사용자 노드 풀에만 예약 되도록 제한 nodeSelectors 합니다. 이 설정은 작업 및 시스템 pod를 격리 합니다.

  • 특정 엔터티가 수신 컨트롤러로 트래픽을 전송할 수 있도록 허용 하는 포트 및 프로토콜을 엽니다. 이 아키텍처에서 Traefik는 Azure 애플리케이션 게이트웨이의 트래픽만 수신 합니다.

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

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

참고

적절 한 수신 컨트롤러에 대 한 선택은 워크 로드의 요구 사항, 운영자의 기술 집합 및 기술 옵션의 지원 가능성에 따라 결정 됩니다. 가장 중요 한 것은 SLO의 기대를 충족 하는 기능입니다.

Traefik는 Kubernetes 클러스터에 대 한 인기 있는 오픈 소스 옵션이 며이 아키텍처에서 설명 목적으로 선택 됩니다. Azure 서비스와 타사 제품 통합을 보여 줍니다. 예를 들어 Traefik를 Azure AD Pod 관리 Id 및 Azure Key Vault와 통합 하는 방법을 구현 하는 방법을 보여 줍니다.

또 다른 선택은 Azure 애플리케이션 게이트웨이 수신 컨트롤러 및 AKS와 잘 통합 된 것입니다. 수신 컨트롤러의 기능 외에 다른 이점도 제공 합니다. 예를 들어 Application Gateway는 클러스터의 가상 네트워크 진입점을 용이 하 게 합니다. 클러스터를 시작 하는 트래픽을 관찰할 수 있습니다. WAF를 필요로 하는 응용 프로그램이 있는 경우 WAF와 통합 되었기 때문에 Application Gateway를 선택 하는 것이 좋습니다. 또한 TLS 종료를 수행할 수 있는 기회를 제공 합니다.

라우터 설정

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

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

Traefik는 Kubernetes 공급자를 사용 하 여 경로를 구성 합니다. annotations, tls 및는 HTTPS를 entrypoints 통해 경로가 제공 됨을 표시 합니다. 는 middlewares Azure 애플리케이션 게이트웨이 서브넷의 트래픽만 허용 하도록 지정 합니다. 클라이언트에서 수락 하는 경우 응답에 gzip 인코딩이 사용 됩니다. Traefik는 TLS 종료를 수행 하므로 백 엔드 서비스와의 통신은 HTTP를 통해 수행 됩니다.

apiVersion:networking.k8s.io/v1beta1
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: /
        backend:
          serviceName: aspnetapp-service
          servicePort: http

네트워크 흐름 보안

이 컨텍스트에서 네트워크 흐름은 다음과 같이 분류 될 수 있습니다.

  • 수신 트래픽 클라이언트에서 클러스터에서 실행 중인 작업으로

  • 트래픽 Egress. 클러스터의 pod 또는 노드에서 외부 서비스로

  • Pod 간 트래픽 입니다. Pod 간의 통신. 이 트래픽은 수신 컨트롤러와 워크 로드 간의 통신을 포함 합니다. 또한 워크 로드가 클러스터에 배포 된 여러 응용 프로그램으로 구성 된 경우 해당 응용 프로그램 간의 통신은이 범주에 속합니다.

  • 관리 트래픽 클라이언트와 Kubernetes API 서버 간에 이동 하는 트래픽

클러스터 트래픽 흐름

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

수신 트래픽 흐름

아키텍처는 클라이언트의 TLS 암호화 요청만 허용 합니다. TLS v 1.2는 제한 된 암호 집합에서 허용 되는 최소 버전입니다. SNI (서버 이름 표시) strict를 사용 합니다. 이 이미지에 표시 된 것 처럼 두 가지 다른 TLS 인증서를 사용 하 여 Application Gateway를 통해 종단 간 TLS를 설정 합니다.

TLS 종료

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

  2. Application Gateway에는 통합 된 WAF (웹 응용 프로그램 방화벽)가 있으며 보안 암호화만 허용 하 여 bicycle.contoso.com에 대 한 TLS 핸드셰이크를 협상 합니다. Application Gateway은 WAF 검사 규칙을 처리 하 고 구성 된 백 엔드로 트래픽을 전달 하는 라우팅 규칙을 실행 하는 데 필요 하므로 TLS 종료 지점입니다. TLS 인증서는 Azure Key Vault에 저장 됩니다. Application Gateway와 통합 된 사용자 할당 관리 id를 사용 하 여 액세스할 수 있습니다. 해당 기능에 대 한 자세한 내용은 Key Vault 인증서를 사용 하는 TLS 종료를 참조 하십시오.

  3. 트래픽이 Application Gateway에서 백 엔드로 이동 하 고 * 내부 부하 분산 장치에 전달 되는 다른 TLS 인증서 (aks-ingress.contoso.com의 와일드 카드)를 사용 하 여 트래픽을 다시 암호화 합니다. 이렇게 다시 암호화하면 안전하지 않은 트래픽이 클러스터 서브넷으로 흐르지 않습니다.

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

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

Egress 트래픽 흐름

제로 트러스트 제어 및 트래픽을 검사하는 기능의 경우 클러스터의 모든 송신 트래픽은 Azure Firewall 통해 이동합니다. UDR(사용자 정의 경로)을 사용하여 해당 선택을 구현할 수 있습니다. 경로의 다음 홉은 Azure Firewall 개인 IP 주소입니다. 여기서 Azure Firewall 송신 트래픽을 차단할지 아니면 허용할지를 결정합니다. 이 결정은 Azure Firewall 정의된 특정 규칙 또는 기본 제공 위협 인텔리전스 규칙에 따라 결정됩니다.

참고

UDR을 사용하여 Azure Firewall 통해 수신 트래픽 및 송신에 대한 공용 지점으로 공용 부하 분산기를 사용하는 경우 비대칭 라우팅 상황이표시될 수 있습니다. 이 아키텍처는 Application Gateway 뒤의 전용 수신 서브넷에서 내부 부하 분산을 사용합니다. 이 디자인 선택은 보안을 향상시킬 뿐만 아니라 비대칭 라우팅 문제를 제거합니다. 또는 Application Gateway 전후에 Azure Firewall 통해 수신 트래픽을 라우팅할 수 있습니다. 대부분의 상황에서는 이 접근 방식이 필요하지 않거나 권장되지 않습니다. 비대칭 라우팅에 대한 자세한 내용은 Azure 표준 Load Balancer Azure Firewall 통합을참조하세요.

제로 트러스트 컨트롤의 예외는 클러스터가 다른 Azure 리소스와 통신해야 하는 경우입니다. 예를 들어 클러스터는 컨테이너 레지스트리에서 업데이트된 이미지를 끌어와야 합니다. Azure Private Link 사용하는것이 좋습니다. 장점은 특정 서브넷이 서비스에 직접 도달한다는 것입니다. 또한 클러스터와 서비스 간의 트래픽은 공용 인터넷에 노출되지 않습니다. 단점은 Private Link 공용 엔드포인트를 통해 대상 서비스를 사용하는 대신 추가 구성이 필요하다는 것입니다. 또한 모든 Azure 서비스 또는 S SKU가 Private Link 지원하지는 않습니다. 이러한 경우 서브넷의 서비스 엔드포인트에서 서비스에 액세스할 수 있도록 설정하는 것이 좋습니다.

Private Link 또는 서비스 엔드포인트가 옵션이 아닌 경우 해당 퍼블릭 엔드포인트를 통해 다른 서비스에 도달하고 Azure Firewall 규칙 및 대상 서비스에 기본 제공된 방화벽을 통해 액세스를 제어할 수 있습니다. 이 트래픽은 방화벽의 고정 IP 주소를 통과하므로 해당 주소를 서비스의 IP 허용 목록에 추가할 수 있습니다. 한 가지 단점은 Azure Firewall 특정 서브넷의 트래픽만 허용되도록 하는 추가 규칙이 있어야 한다는 것입니다.

Pod-Pod 트래픽

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

나중에 추가할 수 없으므로 클러스터가 프로비전될 때 네트워크 정책을 사용하도록 설정합니다. 를 구현하는 기술에는 몇 가지 선택 항목이 NetworkPolicy 있습니다. CNI(Azure Container Networking Interface)가 필요한 Azure 네트워크 정책을 권장합니다. 아래 참고를 참조하세요. 다른 옵션으로는 잘 알려진 오픈 소스 옵션인 Calico 네트워크 정책이 있습니다. 클러스터 전체 네트워크 정책을 관리해야 하는 경우 Calico를 고려합니다. Calico는 표준 Azure 지원에서 다루지 않습니다.

자세한 내용은 Azure 네트워크 정책과 Calico 정책 간의 차이점 및 해당 기능을 참조하세요.

참고

AKS는 CNI(kubenet 및 Azure Container Networking Interface) 네트워킹 모델을 지원합니다. CNI는 두 모델 중 더 고급이며 Azure 네트워크 정책을 사용하도록 설정하는 데 필요합니다. 이 모델에서 모든 Pod는 서브넷 주소 공간에서 IP 주소를 가져옵니다. 동일한 네트워크(또는 피어된 리소스) 내의 리소스는 IP 주소를 통해 직접 Pod에 액세스할 수 있습니다. NAT는 해당 트래픽을 라우팅하는 데 필요하지 않습니다.따라서 CNI는 추가 네트워크 오버레이가 없으므로 수행됩니다. 또한 Azure 네트워크 정책을 사용할 수 있으므로 더 나은 보안 제어를 제공합니다. 일반적으로 CNI를 권장합니다. CNI는 팀이 제어하는 리소스와 팀별로 세분화된 제어를 제공합니다. 또한 CNI는 kubenet보다 크기가 더 큰 Pod를 허용합니다. 그렇지 않으면 클러스터를 다시 배포해야 합니다. 모델에 대한 자세한 내용은 네트워크 모델 비교를 참조하세요.

관리 트래픽

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

자세한 내용은 API 서버 권한 있는 IP 범위 정의를 참조하세요.

비밀 관리 추가

Azure Key Vault 같은 관리되는 키 저장소에 비밀을 저장합니다. 이점은 관리형 저장소가 비밀 회전을 처리하고, 강력한 암호화를 제공하고, 액세스 감사 로그를 제공하고, 핵심 비밀을 배포 파이프라인에서 유지한다는 것입니다.

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

클러스터 비밀 액세스

Pod가 특정 저장소의 비밀에 액세스할 수 있도록 Pod 관리 ID를 사용해야 합니다.

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

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

워크로드 스토리지

이 아키텍처에 사용되는 워크로드는 상태 비지정 상태입니다. 상태를 저장해야 하는 경우 클러스터 외부에 유지하는 것이 좋습니다. 워크로드 상태에 대한 지침은 이 문서의 범위를 벗어났습니다.

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

정책 관리

AKS 클러스터를 관리하는 효과적인 방법은 정책을 통해 거버넌스를 적용하는 것입니다. Kubernetes는 OPA Gatekeeper를 통해 정책을 구현합니다. AKS의 경우 정책은 Azure Policy 통해 전달됩니다. 각 정책은 해당 범위의 모든 클러스터에 적용됩니다. Azure Policy 적용은 궁극적으로 클러스터의 OPA Gatekeeper에 의해 처리되고 모든 정책 검사가 기록됩니다. 정책 변경 내용은 클러스터에 즉시 반영되지 않습니다. 약간의 지연이 예상됩니다.

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

  • 정책 모음(이니셔티브라고 함)을 설정하거나 개별 정책을 선택하려고 합니까? Azure Policy 기본 및 제한이라는 두 가지 기본 제공 이니셔티브를 제공합니다. 각 이니셔티브는 AKS 클러스터에 적용할 수 있는 기본 제공 정책 모음입니다. 이니셔티브를 선택하고 조직의 요구 사항에 따라 클러스터와 상호 작용하는 클러스터 및 리소스(ACR, Application Gateway, Key Vault 및 기타)에 대한 추가 정책을 선택하고 선택하는 것이 좋습니다.

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

  • 워크로드에 의도적으로 규정을 준수하지 않아야 하는 영역이 있나요? Azure Policy 정책 적용에서 제외되는 Kubernetes 네임스페이스를 지정하는 기능이 있습니다. 이러한 인스턴스를 인식할 수 있도록 감사 모드에서 정책을 적용하는 것이 좋습니다.

  • 기본 제공 정책에서 다루지 않는 요구 사항이 있나요? 이러한 드문 경우에서 사용자 지정 OPA Gatekeeper 정책을 적용하는 사용자 지정 Azure Policy 정의를 만듭니다. 클러스터에 정책을 직접 적용하지 마십시오.

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

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

이 참조 구현에서는 AKS 클러스터가 생성될 때 Azure Policy 사용하도록 설정되며 감사 모드에서 제한적인 이니셔티브를 할당하여 비준수에 대한 가시성을 확보합니다.

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

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

노드 및 Pod 확장성

수요가 증가함에 따라 Kubernetes는 HPA(Horizontal Pod Autoscaling)를 통해 기존 노드에 더 많은 Pod를 추가하여 확장할 수 있습니다. 추가 Pod를 더 이상 예약할 수 없는 경우 AKS 클러스터 자동 조정을 통해 노드 수를 늘려야 합니다. 전체 크기 조정 솔루션에는 클러스터의 Pod 복제본과 노드 수를 모두 확장하는 방법이 있어야 합니다.

자동 크기 조정 또는 수동 크기 조정의 두 가지 방법이 있습니다.

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

자동 크기 조정은 이러한 수동 메커니즘 중 일부가 자동 크기 조정기에 기본 제공되기 때문에 이 방법입니다.

일반적인 접근 방식은 최소 개수의 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(경합 상태)가 확인될 수 있습니다. 결과는 잘못된 비율 계산일 수 있습니다. 자세한 내용은 이벤트 크기 조정의 쿨다운을 참조하세요.

워크로드가 이벤트 구동인 경우 인기 있는 오픈 소스 옵션은 KEDA입니다. 워크로드가 CPU 또는 메모리 바인딩이 아닌 메시지 큐와 같은 이벤트 원본에 의해 구동되는 경우 KEDA를 고려합니다. KEDA는 많은 이벤트 원본(또는 스칼라)을 지원합니다. Azure Monitor scaler를 포함하여 지원되는 KEDA 스칼라 목록은 여기에서 찾을 수 있습니다. Azure Monitor 메트릭에 따라 KEDA 워크로드의 크기를 조정하는 편리한 방법입니다.

클러스터 자동 스케일러

클러스터 자동 크기 조정기는 노드 풀의 노드 수를 조정하는 AKS 추가 기능 구성 요소입니다. 클러스터 프로비전 중에 추가해야 합니다. 각 사용자 노드 풀에 대해 별도의 클러스터 자동 크기 조정기 가 필요합니다.

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

자동 크기 조정기 사용 시 최대 및 최소 노드 수를 설정합니다. 권장 값은 워크로드의 성능 기대치, 클러스터를 증가시킬 정도 및 비용에 미치는 영향에 따라 달라집니다. 최소 수는 해당 노드 풀에 예약된 용량입니다. 이 참조 구현에서는 워크로드의 단순한 특성 때문에 최소값이 2로 설정됩니다.

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

비즈니스 연속성 결정

비즈니스 연속성을 유지하려면 인프라 및 애플리케이션에 대한 Service Level Agreement(서비스 수준 약정) 정의합니다. 월별 작동 시간 계산에 대한 자세한 내용은 AKS(Azure Kubernetes Service SLA)를참조하세요.

클러스터 노드

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

별도의 노드 풀에 배치하여 시스템 서비스에서 애플리케이션을 격리합니다. 이러한 방식으로 Kubernetes 서비스는 전용 노드에서 실행되며 워크로드와 경쟁하지 않습니다. 워크로드를 예약할 노드 풀을 식별하려면 태그, 레이블 및 테인을 사용하는 것이 좋습니다.

적시에 업데이트와 같은 클러스터를 정기적으로 유지하는 것은 안정성에 매우 중요합니다. 또한 프로브를 통해 Pod의 상태를 모니터링하는 것이 좋습니다.

Pod 가용성

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

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

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

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

참고

클러스터 수준에서 리소스 할당량을 설정하면 적절한 요청 및 제한이 없는 타사 워크로드를 배포할 때 문제가 발생할 수 있습니다.

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

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

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

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

SLA에 더 높은 작동 시간이 필요한 경우 영역의 손실로부터 보호합니다. 지역에서 지원하는 경우 가용성 영역을 사용할 수 있습니다. 그런 다음 컨트롤 플레인 구성 요소와 노드 풀의 노드를 모두 영역에 분산할 수 있습니다. 전체 영역을 사용할 수 없는 경우 지역 내의 다른 영역에 있는 노드를 계속 사용할 수 있습니다. 각 노드 풀은 노드 인스턴스 및 확장성을 관리하는 별도의 가상 머신 확장 집합에 매핑됩니다. 확장 집합 작업 및 구성은 AKS 서비스에서 관리됩니다. 다중 영역 사용 시 몇 가지 고려 사항은 다음과 같습니다.

  • 전체 인프라. 가용성 영역을 지원하는 지역을 선택합니다. 자세한 내용은 제한 사항 및 지역 가용성을 참조하세요. 작동 시간 SLA를 구입하려면 해당 옵션을 지원하는 지역을 선택합니다. 가용성 영역을 사용하는 경우 작동 시간 SLA가 더 큽니다.

  • 클러스터. 가용성 영역은 노드 풀이 만들어질 때만 설정할 수 있으며 나중에 변경할 수 없습니다. 예상되는 배포가 가능할 수 있도록 모든 영역에서 노드 크기를 지원해야 합니다. 기본 가상 머신 확장 집합은 영역 간에 동일한 하드웨어 구성을 제공합니다.

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

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

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

간단히 하기 위해 이 아키텍처에서 AKS는 가용성 영역 1, 2 및 3에 걸쳐 있는 노드 풀이 있는 단일 지역에 배포됩니다. Azure Firewall 및 Application Gateway 같은 인프라의 다른 리소스도 다중 영역 지원을 사용하여 동일한 지역에 배포됩니다. 지역 복제는 Azure Container Registry 사용할 수 있습니다.

다중 영역

전체 지역이 중단되는 경우 가용성 영역을 사용하도록 설정하는 것만으로는 충분하지 않습니다. 가용성을 높이려면 다른 지역에서 여러 AKS 클러스터를 실행합니다.

  • 쌍을 이루는 지역을 사용합니다. 쌍을 이루는 지역을 사용하여 지역 오류로부터 복구하도록 구성된 CI/CD 파이프라인을 사용하는 것이 좋습니다. 쌍을 이루는 지역을 사용하는 이점은 업데이트 중에 안정성입니다. Azure는 쌍의 한 지역만 한 번에 업데이트되도록 합니다. flux와 같은 특정 DevOps 도구를 사용하면 다중 지역 배포를 더 쉽게 만들 수 있습니다.

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

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

재해 복구

주 지역에서 오류가 발생할 경우 다른 지역에 새 인스턴스를 신속하게 만들 수 있어야 합니다. 몇 가지 권장 사항입니다.

  • 쌍을 이루는 지역을 사용합니다.

  • 비 상태 저장 워크로드를 효율적으로 복제할 수 있습니다. 클러스터에 상태를 저장해야 하는 경우(권장하지 않음) 쌍을 이루는 지역에서 데이터를 자주 백업해야 합니다.

  • SLO(서비스 수준 목표)를 충족하기 위해 DevOps 파이프라인의 일부로 다른 지역에 복제하는 것과 같은 복구 전략을 통합합니다.

  • 각 Azure 서비스를 프로비전할 때 재해 복구를 지원하는 기능을 선택합니다. 예를 들어 이 아키텍처에서는 지역 복제에 Azure Container Registry 사용하도록 설정됩니다. 지역이 다운된 경우에도 복제된 지역에서 이미지를 끌어올 수 있습니다.

Kubernetes API 서버 작동 시간 SLA

AKS는 무료 서비스로 사용할 수 있지만, 해당 계층은 재무적으로 백업되는 SLA를 제공하지 않습니다. 해당 SLA를 얻으려면 구매에 작동 시간 SLA를 추가하도록 선택해야 합니다. 모든 프로덕션 클러스터에서 이 옵션을 사용하는 것이 좋습니다. 사전 프로덕션 클러스터에 대해 이 옵션 없이 클러스터를 예약합니다. Azure 가용성 영역 결합하면 Kubernetes API 서버 SLA가 99.95%로 증가합니다. 노드 풀 및 기타 리소스는 자체 SLA에 따라 적용됩니다.

거래

영역 및 특히 지역에 아키텍처를 배포하기 위한 비용 대 가용성 절충이 있습니다. Azure Container Registry 지역에서 복제와 같은 일부 복제 기능은 프리미엄 SUS에서 사용할 수 있으며, 이는 비용이 더 많이 듭니다. 트래픽이 영역 및 지역 간에 이동할 때 적용되는 대역폭 요금 때문에 비용도 증가합니다.

또한 영역 또는 지역 간의 노드 통신에서 추가 네트워크 대기 시간을 예상합니다. 이 아키텍처 결정이 워크로드에 미치는 영향을 측정합니다.

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

노드 중단, 특정 영역의 모든 AKS 리소스 중단, 영역 오류 시뮬레이션 또는 외부 종속성 중단과 같은 시뮬레이트된 중단으로 강제 장애 조치(failover) 테스트를 통해 안정성을 보장합니다.

메트릭 모니터링 및 수집

컨테이너용 Azure Monitor 기능은 실시간으로 이벤트를 볼 수 있으므로 모니터링 및 로깅에 권장되는 도구입니다. 실행 중인 Pod에서 컨테이너 로그를 캡처하고 보기 위해 집계합니다. 또한 메모리 및 CPU 사용률에 대한 정보를 메트릭 API에서 수집하여 실행 중인 리소스 및 워크로드의 상태를 모니터링합니다. Pod 크기 조정으로 성능을 모니터링하는 데 사용할 수 있습니다. 또 다른 장점은 Azure Portal 사용하여 차트와 대시보드를 쉽게 구성할 수 있다는 것입니다. Automation Runbook, Azure Functions 등을 트리거하는 경고를 만드는 기능이 있습니다.

Pod에서 호스트되는 대부분의 워크로드는 Prometheus 메트릭을 내포합니다. Azure Monitor Prometheus 메트릭을 스크래핑하고 시각화할 수 있습니다.

Kubernetes와 통합된 몇 가지 타사 유틸리티가 있습니다. 조직에서 이미 사용하고 있는 경우 Grafana 또는 Datadog와 같은 로그 및 메트릭 플랫폼을 활용합니다.

AKS를 통해 Azure는 일부 핵심 Kubernetes 서비스를 관리합니다. 이러한 서비스의 로그는 고객 지원의 요청당 사용하도록 설정해야 합니다. 그러나 클러스터 문제를 해결하는 데 도움이 될 수 있는 로그 원본을 사용하도록 설정하는 것이 좋습니다.

자동 복구 사용

활동성 및 준비 상태 프로브를설정하여 Pod의 상태를 모니터링합니다. 응답하지 않는 Pod가 검색되면 Kubernetes는 Pod를 다시 시작합니다. 활동성 프로브는 Pod가 정상인지 여부를 결정합니다. 응답하지 않으면 Kubernetes가 Pod를 다시 시작합니다. 준비 상태 프로브는 Pod가 요청/트래픽을 받을 준비가 되었는지 여부를 결정합니다.

참고

AKS는 노드 자동 복구 를 사용하여 인프라 노드의 기본 제공 자체 복구를제공합니다.

보안 업데이트

지원되는 N-2버전 을 사용하여 Kubernetes 버전을 최신 상태로 유지합니다. 새 버전이 자주 릴리스되기 때문에 Kubernetes의 최신 버전으로 업그레이드하는 것이 중요합니다.

자세한 내용은 Kubernetes의 최신 버전으로 정기적으로 업데이트AKS(Azure Kubernetes Service) 클러스터 업그레이드를 참조하세요.

클러스터에 대한 새 AKS 버전 가용성과 같이 클러스터에서 발생하는 이벤트의 알림은 Azure Event Grid AKS 시스템 항목을통해 달성할 수 있습니다. 참조 구현은 이벤트 스트림 알림 솔루션에서 이벤트를 구독할 수 있도록 이 Event Grid 시스템 토픽을 Microsoft.ContainerService.NewKubernetesVersionAvailable 배포합니다.

주간 업데이트

AKS는 최신 OS 및 런타임 업데이트가 있는 새 노드 이미지를 제공합니다. 이러한 새 이미지는 자동으로 적용되지 않습니다. 이미지를 업데이트해야 하는 빈도를 결정해야 합니다. 노드 풀의 기본 이미지를 매주 업그레이드하는 프로세스가 있는 것이 좋습니다. 자세한 내용은 AKS(Azure Kubernetes Service) 노드 이미지 AKS 릴리스 정보 업그레이드를 참조하세요.

일일 업데이트

이미지 업그레이드 사이에 AKS 노드는 OS 및 런타임 패치를 개별적으로 다운로드하여 설치합니다. 설치 시 노드 VM을 다시 부팅해야 할 수 있습니다. AKS는 보류 중인 업데이트로 인해 노드를 다시 부팅하지 않습니다. 다시 부팅이 필요한 적용된 업데이트에 대한 노드를 모니터링하고 제어된 방식으로 해당 노드의 다시 부팅을 수행하는 프로세스가 있어야 합니다. 오픈 소스 옵션은 선택(Kubernetes 재부팅 디먼)입니다.

노드 이미지를 최신 주간 릴리스와 동기화된 상태로 유지하면 이러한 간헐적인 다시 부팅 요청을 최소화하면서 향상된 보안 태세를 유지합니다. 노드 이미지 업그레이드에만 의존하면 AKS 호환성 및 주간 보안 패치가 보장됩니다. 반면, 매일 업데이트를 적용하면 보안 문제가 더 빠르게 해결될 수 있지만 AKS에서 반드시 테스트되지는 않았습니다. 가능한 경우 노드 이미지 업그레이드를 주 주 보안 패치 전략으로 사용합니다.

보안 모니터링

컨테이너 인프라에서 활성 위협 및 잠재적인 보안 위험을 모두 모니터링합니다.

클러스터 및 워크로드 작업(DevOps)

다음은 몇 가지 고려 사항입니다. 자세한 내용은 Operational Excellence 핵심을 참조하세요.

워크로드 책임 격리

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

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

또 다른 부분은 기본 워크로드를 Azure Active Directory 통합하는 것입니다.

IaC(Infrastructure as Code) 사용

가능한 경우 명령적 접근 방식보다 멱등원 선언적 메서드를 선택합니다. 구성 옵션을 지정하는 명령 시퀀스를 작성하는 대신 리소스 및 해당 속성을 설명하는 선언적 구문을 사용합니다. 한 가지 옵션은 ARM(Azure Resource Manager) 템플릿이며 다른 옵션은 Terraform입니다.

관리 정책에 따라 리소스를 프로비전하는지 확인합니다. 예를 들어 적절한 VM 크기를 선택할 때 애플리케이션의 요구 사항에 맞게 비용 제약 조건, 가용성 영역 옵션 내에 유지합니다.

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

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

워크로드 CI/CD

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

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

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

클러스터 CI/CD

워크로드 CI/CD

kubectl과 같은 명령적 접근 방식을 사용하는 대신 클러스터 및 리포지토리 변경 내용을 자동으로 동기화하는 도구를 사용합니다. 프로덕션에 배포하기 전에 새 버전의 릴리스 및 해당 버전의 유효성 검사와 같은 워크플로를 관리하려면 GitOps 흐름을 고려합니다. 에이전트는 클러스터의 상태가 프라이빗 Git 리포지션에 저장된 구성과 조정되도록 클러스터에 배포됩니다. Kubernetes 및 AKS는 해당 환경을 기본적으로 지원하지 않습니다. flux옵션을 권장합니다. 클러스터에서 하나 이상의 연산자를 사용하여 Kubernetes 내에서 배포를 트리거합니다. flux는 다음 작업을 수행합니다.

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

이러한 변경 내용을 배포하는 방법을 제어하는 정책을 설정할 수도 있습니다.

GitOps 및 Flux를 사용하여 클러스터 구성을 자동화하는 방법을 보여 주는 참조 구현의 예제는 다음과 같습니다.

GitOps Flow

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

  2. flux는 워크로드와 함께 의 Pod에서 실행됩니다. flux는 git 리포지토리에 대한 읽기 전용 액세스 권한을 가지며, flux가 개발자의 요청에 따라 변경 내용만 적용하도록 합니다.

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

  4. 개발자는 kubectl을 통해 Kubernetes API에 직접 액세스할 수 없습니다. git 서버에 분기 정책이 있어야 합니다. 이렇게 하면 여러 개발자가 변경이 프로덕션에 적용되기 전에 승인할 수 있습니다.

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

하나 이상의 사전 프로덕션 AKS 클러스터에 변경(아키텍처 구성 요소, 워크로드, 클러스터 구성)을 배포합니다. 이렇게 하면 프로덕션에 배포하기 전에 변경으로 문제가 발생할 수 있음을 시뮬레이션합니다.

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

파란색-녹색 배포,A/B 테스트 및 카나리아 릴리스와같은 고급 배포 기술에는 추가 프로세스 및 잠재적으로 도구가 필요합니다. Flagger는 고급 배포 시나리오를 해결하는 데 도움이 되는 인기 있는 오픈 소스 솔루션입니다.

비용 관리

Azure 가격 계산기를 사용하여 아키텍처에 사용되는 서비스에 대한 비용을 예측합니다. 다른 모범 사례는 Microsoft Azure Well-Architected Framework의 비용 최적화 섹션에 설명되어 있습니다.

프로비전

  • Kubernetes 클러스터의 배포, 관리 및 운영에는 AKS와 관련된 비용이 없습니다. 주요 비용 드라이버는 클러스터에서 사용하는 가상 머신 인스턴스, 스토리지 및 네트워킹 리소스입니다. 시스템 노드 풀에 더 저렴한 VM을 선택하는 것이 좋습니다. 권장되는 SKU는 DS2_v2.

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

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

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

  • 크기 조정 요구 사항을 충족하기 위해 너무 많은 클러스터로 시작하는 대신 최소 노드 수로 클러스터를 프로비전하고 클러스터 자동 크기 조정기에서 모니터링 및 크기 조정 결정을 내릴 수 있도록 합니다.

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

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

  • 워크로드가 장기간 존재할 것으로 예상되는 경우 1년 또는 3년 예약 가상 머신 인스턴스를 커밋하여 노드 비용을 줄일 수 있습니다. 자세한 내용은 예약된 VM을 참조하세요.

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

  • 지역의 가용성 영역 내에서의 데이터 전송은 무료가 아닙니다. 워크로드가 다중 지역이거나 청구 영역 간에 전송이 있는 경우 추가 대역폭 비용을 예상합니다. 자세한 내용은 청구 영역 및 지역 간 트래픽을 참조하세요.

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

모니터

컴퓨팅 비용과 함께 전체 클러스터의 비용을 모니터링하기 위해 스토리지, 대역폭, 방화벽 및 로그에 대한 비용 정보도 수집합니다. Azure는 비용을 모니터링하고 분석할 수 있는 다양한 대시보드를 제공합니다.

비용이 이미 계산된 월말 이전에 작업을 수행하려면 실시간으로 또는 적어도 정기적으로 비용을 모니터링하는 것이 가장 좋습니다. 또한 시간별 월별 추세를 모니터링하여 예산을 유지합니다.

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

최적화

에서 제공하는 권장 사항에 따라 Azure Advisor. 최적화하는 다른 방법은 다음과 같습니다.

  • 클러스터 자동 크기 조정기를 사용하도록 설정하여 노드 풀에서 사용량이 부족한 노드를 검색하고 제거합니다.

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

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

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

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

다음 단계

Kubernetes에서 리프레셔가 필요한 경우 Kubernetes 소개 및 Microsoft Learn Kubernetes 학습 경로에 애플리케이션 개발 및 배포를 완료합니다.