Azure Kubernetes Service에 대한 작업 관리 고려 사항

  • 아티클

Kubernetes는 인상적인 에코시스템으로 빠르게 발전하는 비교적 새로운 기술입니다. 따라서 관리 및 보호하기가 어려울 수 있습니다.

AKS에 대한 작업 기준

관리 및 모니터링을 염두에 두고 AKS(Azure Kubernetes Service) 솔루션을 올바르게 설계하여 운영 우수성과 고객 성공을 위해 노력할 수 있습니다.

디자인 고려 사항

다음 사항을 고려합니다.

  • AKS 제한에 유의하세요. 여러 AKS 인스턴스를 사용하여 이러한 제한을 초과하여 확장할 수 있습니다.
  • 클러스터 내에서 워크로드를 논리적으로 격리하는 방법 및 별도의 클러스터에서 워크로드를 물리적으로 격리하는 방법을 알고 있어야 합니다.
  • 워크로드별 리소스 사용을 제어하는 방법을 알고 있어야 합니다.
  • Kubernetes가 워크로드의 상태를 이해하는 데 도움이 되는 방법을 알고 있어야 합니다.
  • 다양한 가상 머신 크기 및 하나 또는 다른 가상 머신 사용의 영향에 유의하세요. VM이 클수록 더 많은 부하를 처리할 수 있습니다. 계획된 유지 관리 및 계획되지 않은 유지 관리에 사용할 수 없는 경우 더 작은 VM을 다른 VM으로 쉽게 바꿀 수 있습니다. 또한 확장 집합의 노드 풀 및 VM에 유의하여 동일한 클러스터에서 서로 다른 크기의 가상 머신을 허용합니다. AKS는 리소스의 더 작은 비율을 예약하여 워크로드에 더 많은 리소스를 사용할 수 있도록 하기 때문에 더 큰 VM이 더 적합합니다.
  • AKS를 모니터링하고 로그하는 방법을 알고 있어야 합니다. Kubernetes는 다양한 구성 요소로 구성되며 모니터링 및 로깅은 상태, 추세 및 잠재적 문제에 대한 인사이트를 제공해야 합니다.
  • 모니터링 및 로깅을 기반으로 Kubernetes 또는 위에서 실행되는 애플리케이션에서 생성된 많은 이벤트가 있을 수 있습니다. 경고는 기록 목적의 로그 항목과 즉각적인 조치가 필요한 로그 항목을 구분하는 데 도움이 될 수 있습니다.
  • 수행해야 하는 업데이트 및 업그레이드에 유의하세요. Kubernetes 수준에는 주 버전, 부 버전 및 패치 버전이 있습니다. 고객은 이러한 업데이트를 적용하여 업스트림 Kubernetes의 정책에 따라 지원되는 상태를 유지해야 합니다. 작업자 호스트 수준에서 OS 커널 패치에는 고객이 수행해야 하는 재부팅이 필요할 수 있으며 새 OS 버전으로 업그레이드할 수 있습니다. 클러스터를 수동으로 업그레이드하는 것 외에도 클러스터에서 자동 업그레이드 채널을 설정할 수 있습니다.
  • 클러스터의 리소스 제한 사항 및 개별 워크로드에 유의하세요.
  • Horizontal Pod Autoscaler 및 Cluster Autoscaler의 차이점에 유의하세요.
  • 네트워크 정책 및 Azure 정책 플러그 인을 사용하여 Pod 간의 트래픽 보안을 고려합니다.
  • AKS에서 실행되는 애플리케이션 및 서비스의 문제를 해결하려면 컨트롤 플레인 구성 요소에서 생성된 로그를 확인해야 할 수 있습니다. 로깅은 기본적으로 사용하도록 설정되지 않으므로 AKS에 대한 리소스 로그를 사용하도록 설정할 수 있습니다.

권장 사항

  • 다음 AKS 제한을 이해합니다.

  • 네임스페이스 수준에서 논리적 격리를 사용하여 애플리케이션, 팀, 환경 및 사업부를 구분합니다. 다중 테넌트 및 클러스터 격리. 또한 노드 풀은 노드 사양이 다른 노드에서 도움이 될 수 있으며 Kubernetes와 같은 유지 관리는 여러 노드 풀을 업그레이드합니다.

  • 네임스페이스 수준에서 리소스 할당량을 계획하고 적용합니다. Pod가 리소스 요청 및 제한을 정의하지 않는 경우 정책 등을 사용하여 배포를 거부합니다. 일부 kube-system Pod에는 요청 및 제한이 없으므로 kube-system Pod에는 적용되지 않습니다. 리소스 사용량을 모니터링하고 필요에 따라 할당량을 조정합니다. 기본 스케줄러 기능

  • Pod에 상태 프로브를 추가합니다. Pod에 livenessProbe, readinessProbe 및 startupProbeAKS 상태 프로브가 포함되어 있는지 확인합니다.

  • 여러 컨테이너 인스턴스를 포함할 수 있을 만큼 큰 VM 크기를 사용하면 밀도가 증가하지만 클러스터가 실패한 노드의 워크로드를 처리할 수 없을 정도로 크지는 않은 이점을 얻을 수 있습니다.

  • 모니터링 솔루션을 사용합니다. Azure Monitor 컨테이너 인사이트는 기본적으로 설정되며 많은 인사이트에 쉽게 액세스할 수 있습니다. 더 자세히 연습하고 싶거나 Prometheus를 사용한 경험이 있는 경우 Prometheus 통합을 사용할 수 있습니다. AKS에서 모니터링 애플리케이션을 실행하려는 경우에도 Azure Monitor를 사용하여 해당 애플리케이션을 모니터링해야 합니다.

  • Azure Monitor 컨테이너 인사이트 메트릭 경고를 사용하여 직접 작업이 필요한 경우 알림을 제공합니다.

  • 자동 노드 풀 크기 조정 기능을 Horizontal Pod Autoscaler와 함께 사용하여 애플리케이션 요구 사항을 충족하고 사용량이 가장 많은 시간의 부하를 완화합니다.

  • Azure Advisor를 사용하여 비용, 보안, 안정성, 운영 우수성 및 성능에 대한 모범 사례 권장 사항을 가져옵니다. 또한 클라우드용 Microsoft Defender 사용하여 이미지 취약성과 같은 위협을 방지하고 검색합니다.

  • Azure Arc 지원 Kubernetes를 사용하여 Azure Policy, 클라우드용 Defender, GitOps 등을 사용하여 Azure에서 AKS Kubernetes가 아닌 클러스터를 관리합니다.

  • Pod 요청 및 제한을 사용하여 AKS 클러스터 내에서 컴퓨팅 리소스를 관리합니다. Pod 요청 및 제한은 Kubernetes 스케줄러에 Pod에 할당할 컴퓨팅 리소스를 알려줍니다.

AKS를 보호하고 복구하기 위한 비즈니스 연속성/재해 복구

조직은 특정 요구 사항을 충족하기 위해 적절한 AKS(Azure Kubernetes Service) 플랫폼 수준 기능을 설계해야 합니다. 이러한 애플리케이션 서비스에는 RTO(복구 시간 목표) 및 RPO(복구 지점 목표)와 관련된 요구 사항이 있습니다. AKS 재해 복구를 위해 해결해야 할 여러 가지 고려 사항이 있습니다. 첫 번째 단계는 인프라 및 애플리케이션에 대한 SLA(서비스 수준 계약)를 정의하는 것입니다. AKS(Azure Kubernetes Service)를 위한 SLA에 대해 알아봅니다. 월별 가동 시간 계산에 대한 정보는 SLA 세부 정보 섹션을 참조하세요.

디자인 고려 사항

다음 사항을 고려합니다.

  • AKS 클러스터는 애플리케이션에 대한 최소 가용성 수준을 제공하기 위해 노드 풀의 여러 노드를 사용해야 합니다.

  • Pod 요청 및 제한을 설정합니다. 이러한 제한을 설정하면 Kubernetes에서 다음을 수행할 수 있습니다.

    • Pod에 CPU 및 메모리 리소스를 효율적으로 제공합니다.
    • 노드에서 컨테이너 밀도가 높아집니다.

    또한 제한을 통해 하드웨어를 더 잘 사용하기 때문에 비용을 줄이면서 안정성이 향상될 수 있습니다.

  • 가용성 영역 또는 가용성 집합에 대한 AKS 적합성:

    • 가용성 영역을 지원하는 지역을 선택합니다.
    • 가용성 영역은 노드 풀이 만들어질 때만 설정할 수 있으며 나중에 변경할 수 없습니다. 다중 영역 지원은 노드 풀에만 적용됩니다.
    • 전체 영역 혜택을 위해 모든 서비스 종속성도 영역을 지원해야 합니다. 종속 서비스가 영역을 지원하지 않는 경우 영역 오류로 인해 해당 서비스가 실패할 수 있습니다.
    • 서로 다른 쌍을 이루는 지역에서 여러 AKS 클러스터를 실행하여 가용성 영역 달성할 수 있는 것 이상의 고가용성을 제공합니다. Azure 리소스가 지역 중복성을 지원하는 경우 중복 서비스에 보조 지역이 있는 위치를 제공합니다.

  • AKS의 재해 복구에 대한 지침을 알고 있어야 합니다. 그런 다음, Azure Dev Spaces에 사용하는 AKS 클러스터에 적용되는지 여부를 고려합니다.

  • 애플리케이션 및 데이터에 대한 일관된 백업을 만듭니다.

    • 비 상태 저장 서비스를 효율적으로 복제할 수 있습니다.
    • 클러스터에 상태를 저장해야 하는 경우 쌍을 이루는 지역에서 데이터를 자주 백업합니다. 한 가지 고려 사항은 클러스터에 상태를 제대로 저장하는 것이 복잡할 수 있다는 것입니다.

  • 클러스터 업데이트 및 유지 관리.

    • 항상 클러스터를 최신 상태로 유지합니다.
    • 릴리스 및 사용 중단 프로세스에 유의하세요.
    • 업데이트 및 유지 관리를 계획합니다.

  • 장애 조치(failover)가 발생하는 경우의 네트워크 연결.

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

  • 계획되거나 계획되지 않은 장애 조치(failover).

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

  • 서비스 수준 목표에 도달하기 위해 엔지니어링 DevOps 기능을 유지 관리합니다.

  • Kubernetes API 서버 엔드포인트에 대해 재정적으로 지원되는 SLA가 필요한지 여부를 결정합니다.

디자인 권장 사항

다음은 디자인에 관한 모범 사례입니다.

  • 시스템 노드 풀에 3개의 노드를 사용합니다. 사용자 노드 풀의 경우 두 개 이하의 노드로 시작합니다. 더 높은 가용성이 필요한 경우 더 많은 노드를 설정합니다.

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

  • 클러스터의 정기적인 유지 관리(예: 적시에 업데이트)는 안정성에 매우 중요합니다. AKS의 Kubernetes 버전에 대한 지원 창을 염두에 두고 업데이트를 계획합니다. 또한 프로브를 통해 Pod의 상태를 모니터링하는 것이 좋습니다.

  • 가능하면 컨테이너 내부에서 서비스 상태를 제거합니다. 대신, 다중 지역 복제를 지원하는 Azure PaaS(platform as a service)를 사용합니다.

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

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

  • 애플리케이션이 데이터에 Azure Storage를 사용할 수도 있습니다. 애플리케이션이 서로 다른 지역의 여러 AKS 클러스터에 분산되어 있으므로 스토리지를 동기화된 상태로 유지해야 합니다. 스토리지를 복제하는 두 가지 일반적인 방법은 다음과 같습니다.

    • 인프라 기반 비동기 복제
    • 애플리케이션 기반 비동기 복제

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

    기본 제공 기능은 서비스 아키텍처의 오류 및 중단을 처리하는 복잡한 작업에 대한 솔루션을 제공합니다. 이러한 구성은 디자인 및 배포 자동화를 간소화하는 데 도움이 됩니다. 조직에서 SLA, RTO 및 RPO에 대한 표준을 정의한 경우 Kubernetes 및 Azure에 기본 제공 서비스를 사용하여 비즈니스 목표를 달성할 수 있습니다.

  • Pod 중단 예산을 설정합니다. 이 설정은 업데이트 또는 업그레이드 이벤트 중에 중단할 수 있는 배포의 복제본 수를 확인합니다.

  • 서비스 네임스페이스에 리소스 할당량을 적용합니다. 네임스페이스의 리소스 할당량은 Pod 요청 및 한도가 배포에서 올바르게 설정되도록 합니다.

    • 클러스터 수준에서 리소스 할당량을 설정하면 적절한 요청 및 제한이 없는 파트너 서비스를 배포할 때 문제가 발생할 수 있습니다.

  • Azure Container Registry에 컨테이너 이미지를 저장하고 레지스트리를 각 AKS 지역에 지역 복제합니다.

  • 작동 시간 SLA를 사용하여 프로덕션 워크로드를 호스트하는 모든 클러스터에 대해 재정적으로 지원되는 더 높은 SLA를 사용하도록 설정합니다. 작동 시간 SLA는 가용성 영역을 사용하는 클러스터에 Kubernetes API 서버 엔드포인트의 99.95% 가용성을 보장하고, 가용성 영역을 사용하지 않는 클러스터에는 99.9%의 가용성을 보장합니다. 노드, 노드 풀 및 기타 리소스는 해당 SLA에서 다룹니다. AKS는 컨트롤 플레인 구성 요소에 대해 SLO(서비스 수준 목표)가 99.5%인 무료 계층을 제공합니다. 작동 시간 SLA를 사용하지 않는 클러스터는 프로덕션 워크로드에 사용하면 안 됩니다.

  • Azure ExpressRoute 연결을 위해 여러 지역 및 피어링 위치를 사용합니다.

    중복 하이브리드 네트워크 아키텍처는 중단이 Azure 지역 또는 피어링 공급자 위치에 영향을 주는 경우 중단 없는 프레미스 간 연결을 보장하는 데 도움이 될 수 있습니다.

  • 글로벌 가상 네트워크 피어링을 사용하여 지역 상호 연결. 클러스터가 서로 통신해야 하는 경우 가상 네트워크 피어링을 통해 두 가상 네트워크를 서로 연결할 수 있습니다. 이 기술은 가상 네트워크를 서로 상호 연결하여 여러 지리적 지역에서도 Microsoft의 백본 네트워크에서 높은 대역폭을 제공합니다.

  • Azure Front Door는 분할된 TCP 기반 애니캐스트 프로토콜을 사용하여 최종 사용자가 가장 가까운 Front Door POP(Point of Presence)에 즉시 연결하도록 합니다. Azure Front Door의 추가 기능에는 다음이 포함됩니다.

    • TLS 종료
    • 사용자 지정 도메인
    • 웹 애플리케이션 방화벽
    • URL 재작성
    • 세션 선호도

    애플리케이션 트래픽 요구 사항을 검토하여 어떤 솔루션이 가장 적합한지 알아보세요.