Azure Kubernetes Service에 대 한 엔터프라이즈 규모의 비즈니스 연속성 및 재해 복구Enterprise-scale business continuity and disaster recovery for Azure Kubernetes Service

조직에서는 특정 요구 사항을 충족 하기 위해 적절 한 AKS (Azure Kubernetes Service) 플랫폼 수준 기능을 디자인 해야 합니다.Your organization needs to design suitable Azure Kubernetes Service (AKS) platform-level capabilities to meet its specific requirements. 이러한 응용 프로그램 서비스에는 RTO (복구 시간 목표) 및 RPO (복구 지점 목표)와 관련 된 요구 사항이 있습니다.These application services have requirements related to recovery time objective (RTO) and recovery point objective (RPO). AKS 재해 복구를 위해 여러 가지 사항을 고려해 야 합니다.There are multiple considerations to address for AKS disaster recovery. 첫 번째 단계는 인프라 및 응용 프로그램에 대 한 SLA (서비스 수준 계약)를 정의 하는 것입니다.Your first step is to define a service-level agreement (SLA) for your infrastructure and application. AKS (Azure Kubernetes Service)에 대 한 SLA에 대해 알아봅니다.Learn about the SLA for Azure Kubernetes Service (AKS). 월간 작동 시간 계산에 대 한 자세한 내용은 SLA 세부 정보 섹션을 참조 하세요.See the SLA details section for information about monthly uptime calculations.

설계 고려 사항Design considerations

다음 사항을 고려합니다.Consider the following factors:

  • AKS 클러스터는 응용 프로그램에 대 한 최소 수준의 가용성을 제공 하기 위해 노드 풀에서 여러 노드를 사용 해야 합니다.The AKS cluster should use multiple nodes in a node pool to provide the minimum level of availability for your application.

  • Pod 요청 및 제한을설정 합니다.Set pod requests and limits. 이러한 제한을 설정 하면 Kubernetes를 사용할 수 있습니다.Setting these limits lets Kubernetes:

    • Pod에 CPU 및 메모리 리소스를 효율적으로 제공 합니다.Efficiently give CPU and memory resources to the pods.

    • 노드에 컨테이너 밀도가 더 높습니다.Have higher container density on a node.

    또한 하드웨어를 보다 효율적으로 사용 하 여 비용을 절감할 수 있습니다.Limits can also increase reliability with reduced costs because of better use of hardware.

  • 가용성 영역 또는 가용성 집합에 대 한 AKS 적합성.AKS suitability for Availability Zones or availability sets.

    • 가용성 영역을 지원하는 지역을 선택합니다.Choose a region that supports Availability Zones.

    • 가용성 영역 노드 풀을 만든 경우에만 설정할 수 있으며 나중에 변경할 수 없습니다.Availability Zones can only be set when the node pool is created and can't be changed later. Multizone support는 노드 풀에만 적용 됩니다.Multizone support only applies to node pools.

    • 영역을 완벽 하 게 활용 하려면 모든 서비스 종속성이 영역도 지원 해야 합니다.For complete zonal benefit, all service dependencies must also support zones. 종속 서비스가 영역을 지원 하지 않는 경우 영역 오류가 발생 하 여 해당 서비스가 실패할 수 있습니다.If a dependent service doesn't support zones, it's possible that a zone failure could cause that service to fail.

    • 가용성 영역 달성할 수 있는 것 보다 높은 가용성을 위해 여러 쌍을 이루는 지역에서 여러 AKS 클러스터를 실행 합니다.For higher availability beyond what Availability Zones can achieve, run multiple AKS clusters in different paired regions. Azure 리소스에서 지역 중복을 지 원하는 경우 중복 서비스의 보조 지역을 지정 하는 위치를 제공 합니다.If an Azure resource supports geo-redundancy, provide the location where the redundant service will have its secondary region.

  • AKS에서 재해 복구에 대 한 지침 을 알고 있어야 합니다.You should be aware of guidelines for disaster recovery in AKS. 그런 다음 Azure Dev Spaces에 사용 하는 AKS 클러스터에 적용 되는지 여부를 고려 합니다.Then consider whether they apply to the AKS clusters that you use for Azure Dev Spaces.

  • 응용 프로그램 및 데이터에 대 한 백업을 지속적으로 만듭니다.Consistently create backups for applications and data.

    • 상태 저장 서비스가 아닌 서비스를 효율적으로 복제할 수 있습니다.A non-stateful service can be replicated efficiently.

    • 클러스터에 상태를 저장 해야 하는 경우 (권장 되지 않음) 쌍을 이루는 지역에서 자주 데이터를 백업 해야 합니다.If you need to store state in the cluster (not recommended), make sure you back up the data frequently in the paired region.

  • 클러스터 업데이트 및 유지 관리.Cluster update and maintenance.

    • 항상 클러스터를 최신 상태로 유지 합니다.Always keep your cluster up to date.

    • 릴리스 및 사용 중단 프로세스에 대해 알고 있어야 합니다.Be aware of the release and deprecation process.

    • 업데이트 및 유지 관리를 미리 계획 합니다.Plan your updates and maintenance in advance.

  • 장애 조치 (failover)가 발생 하는 경우 네트워크 연결.Network connectivity if a failover occurs.

    • 요구 사항에 따라 영역 또는 지역 간에 트래픽을 분산할 수 있는 트래픽 라우터를 선택 합니다.Choose a traffic router that can distribute traffic across zones or regions, depending on your requirement. 이 아키텍처는 여러 영역에 웹이 아닌 트래픽을 배포할 수 있으므로 Azure Load Balancer 을 배포 합니다.This architecture deploys Azure Load Balancer because it can distribute non-web traffic across zones.

    • 영역 간에 트래픽을 분산 해야 하는 경우 Azure Front 도어를 사용 하는 것이 좋습니다.If you need to distribute traffic across regions, consider using Azure Front Door.

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

    • 각 Azure 서비스를 설정할 때 재해 복구를 지 원하는 기능을 선택 합니다.When setting up each Azure service, choose features that support disaster recovery. 예를 들어이 아키텍처에서는 지역에서 복제에 대 한 Azure Container Registry 를 사용 하도록 설정 합니다.For example, in this architecture, enable Azure Container Registry for geo-replication. 지역이 중단 되는 경우에도 복제 된 지역에서 이미지를 끌어올 수 있습니다.If a region goes down, you can still pull images from the replicated region.
  • 서비스 수준 목표에 도달 하기 위한 엔지니어링 DevOps 기능을 유지 관리 합니다.Maintain engineering DevOps capabilities to reach service level goals.

  • Kubernetes API 서버 끝점에 대 한 재정적 지원 SLA 가 필요한 지 여부를 확인 합니다.Determine whether you need a financially backed SLA for your Kubernetes API server endpoint.

디자인 권장 사항Design recommendations

디자인에 대 한 모범 사례는 다음과 같습니다.The following are best practices for your design:

  • 시스템 노드 풀에 세 개의 노드를 사용 합니다.Use three nodes for the system node pool. 사용자 노드 풀의 경우 두 개 미만의 노드를 사용 하 여 시작 합니다.For the user node pool, start with no less than two nodes. 더 높은 가용성이 필요한 경우 더 많은 노드를 설정 합니다.If you need higher availability, set up more nodes.

  • 응용 프로그램을 별도의 노드 풀에 배치 하 여 시스템 서비스에서 격리 합니다.Isolate your application from the system services by placing it in a separate node pool. 이러한 방식으로 Kubernetes services는 전용 노드에서 실행 되 고 다른 서비스와 경쟁할 수 없습니다.This way, Kubernetes services run on dedicated nodes and don't compete with other services. 태그, 레이블 및 taints 를 사용 하 여 작업을 예약할 노드 풀을 식별 합니다.Use tags, labels, and taints to identify the node pool to schedule your workload.

  • 적시에 업데이트를 수행 하는 것과 같은 클러스터의 일반 보존는 안정성을 위해 중요 합니다.Regular upkeep of your cluster like making timely updates is crucial for reliability. AKS에서 지원 되는 Kubernetes 버전의 지원 되는 창에 유의 하 고 업데이트를 미리 계획 합니다.Be mindful of supported window of Kubernetes versions on AKS and plan your updates in advance. 또한 프로브를 통해 pod 상태를 모니터링 하는 것이 좋습니다.Also, monitoring the health of the pods through probes is recommended.

  • 가능 하면 컨테이너 내부에서 서비스 상태를 제거합니다.Whenever possible, remove service state from inside containers. 대신, 다중 지역 복제를 지 원하는 Azure PaaS (platform as a service)를 사용 합니다.Instead, use an Azure platform as a service (PaaS) that supports multiregion replication.

  • Pod 리소스를 확인 합니다.Ensure pod resources. 배포에서 pod 리소스 요구 사항을 지정 하는 것이 좋습니다.It's highly recommended that deployments specify pod resource requirements. 그런 다음 스케줄러에서 pod를 적절 하 게 예약할 수 있습니다.The scheduler can then appropriately schedule the pod. Pod가 예약 되지 않은 경우 안정성이 크게 depreciates.Reliability depreciates significantly when pods aren't scheduled.

  • 하드웨어 오류와 같은 중단을 처리 하도록 배포에 여러 복제본을 설정 합니다.Set up multiple replicas in the deployment to handle disruptions like hardware failures. 업데이트 및 업그레이드와 같은 계획 된 이벤트의 경우 중단 예산으로 인해 필요한 응용 프로그램 부하를 처리 하기 위해 필요한 pod 복제본 수가 있는지 확인할 수 있습니다.For planned events like updates and upgrades, a disruption budget can ensure the required number of pod replicas exist to handle expected application load.

  • 응용 프로그램은 데이터에 대 한 Azure Storage 를 사용할 수 있습니다.Your applications might use Azure Storage for their data. 응용 프로그램은 서로 다른 지역의 여러 AKS 클러스터에 걸쳐 분산 되므로 저장소를 동기화 된 상태로 유지 해야 합니다.Because your applications are spread across multiple AKS clusters in different regions, you need to keep the storage synced. 저장소를 복제 하는 두 가지 일반적인 방법은 다음과 같습니다.Here are two common ways to replicate storage:

    • 인프라 기반 비동기 복제Infrastructure-based asynchronous replication

    • 애플리케이션 기반 비동기 복제Application-based asynchronous replication

  • Pod 한도를 예상 합니다.Estimate pod limits. 기준을 테스트 하 고 설정 합니다.Test and establish a baseline. 요청 및 제한에 대해 동일한 값으로 시작 합니다.Start with equal values for requests and limits. 그런 다음 클러스터에서 불안정 해질 수 있는 임계값을 설정할 때까지 이러한 값을 점차적으로 조정 합니다.Then, gradually tune those values until you've established a threshold that can cause instability in the cluster. Pod 제한은 배포 매니페스트에 지정할 수 있습니다.Pod limits can be specified in your deployment manifests.

    기본 제공 기능은 오류 처리 및 서비스 아키텍처 중단의 복잡 한 작업에 대 한 솔루션을 제공 합니다.The built-in features provide a solution to the complex task of handling failures and disruptions in service architecture. 이러한 구성은 디자인 및 배포 자동화를 간소화 하는 데 도움이 됩니다.These configurations help to simplify both design and deployment automation. 조직에서 SLA, RTO 및 RPO에 대 한 표준을 정의한 경우 Kubernetes 및 Azure에 기본 제공 서비스를 사용 하 여 비즈니스 목표를 달성할 수 있습니다.When an organization has defined a standard for the SLA, RTO, and RPO, it can use built-in services to Kubernetes and Azure to achieve its business goals.

  • Pod 중단 예산을설정 합니다.Set pod disruption budgets. 이 설정은 배포에서 업데이트 또는 업그레이드 이벤트 중에 수행할 수 있는 복제본 수를 확인 합니다.This setting checks how many replicas in a deployment you can take down during an update or upgrade event.

  • 서비스 네임 스페이스에 리소스 할당량을 적용 합니다.Enforce resource quotas on the service namespaces. 네임 스페이스의 리소스 할당량은 배포에 pod 요청 및 제한이 적절히 설정 되었는지 확인 합니다.The resource quota on a namespace will ensure pod requests and limits are properly set on a deployment.

    • 클러스터 수준에서 리소스 할당량을 설정 하면 적절 한 요청 및 제한이 없는 파트너 서비스를 배포할 때 문제가 발생할 수 있습니다.Setting resources quotas at the cluster level can cause problems when deploying partner services that don't have proper requests and limits.
  • 최신 버전의 kube-advisor 오픈 소스 도구 를 정기적으로 실행 하 여 클러스터의 문제를 검색 합니다.Regularly run the latest version of the kube-advisor open-source tool to detect issues in your cluster.

  • 컨테이너 이미지를 Azure Container Registry 에 저장 하 고 각 AKS 지역에 레지스트리를 지역 복제 합니다.Store your container images in Azure Container Registry and geo-replicate the registry to each AKS region.

  • AKS는 무료 서비스로 사용할 수 있지만이 계층은 재정적 지원 SLA를 제공 하지 않습니다.AKS can be used as a free service, but that tier doesn't offer a financially backed SLA. 이러한 SLA를 얻으려면 구입 하는 제품에 작동 시간 SLA를 추가 해야 합니다.To get that SLA, you have to add an uptime SLA to what you buy. 모든 프로덕션 클러스터에서이 옵션을 사용 하는 것이 좋습니다.We recommend all production clusters use this option. 프리 프로덕션 클러스터에 대해이 옵션을 사용 하지 않고 클러스터를 예약 합니다.Reserve clusters without this option for pre-production clusters. 가용성 영역와 함께 사용 하는 경우 Kubernetes API 서버 SLA가 99.95%로 증가 합니다.When combined with Availability Zones, the Kubernetes API server SLA is increased to 99.95%. 노드 풀 및 기타 리소스는 자체 SLA에 따라 적용 됩니다.Your node pools, and other resources are covered under their own SLA.

  • Express 경로 연결에는 여러 지역 및 피어 링 위치를 사용 합니다.Use multiple regions and peering locations for ExpressRoute connectivity.

    Azure 지역 또는 피어 링 공급자 위치에 영향을 주는 중단이 발생 하는 경우 중복 하이브리드 네트워크 아키텍처를 통해 크로스-프레미스 간 연결을 원활 하 게 수행할 수 있습니다.If an outage affecting an Azure region or peering provider location occurs, a redundant hybrid network architecture can help ensure uninterrupted cross-premises connectivity.

  • 전역 가상 네트워크 피어 링을 사용 하 여 영역을 상호 연결 합니다.Interconnect regions with global virtual network peering. 클러스터가 서로 통신 해야 하는 경우 가상 네트워크 피어 링을 통해 두 가상 네트워크를 서로 연결할 수 있습니다.If the clusters need to talk to each other, connecting both virtual networks to each other can be achieved through virtual network peering. 이 기술은 서로 다른 지리적 지역에도 불구 하 고 Microsoft의 백본 네트워크에서 높은 대역폭을 제공 하 여 가상 네트워크를 서로 상호 연결할 수 있습니다.This technology interconnects virtual networks to each other providing high bandwidth across Microsoft's backbone network, even across different geographic regions.

  • Azure 전면 도어는 분할 TCP 기반 애니캐스트 프로토콜을 사용 하 여 최종 사용자가 가장 가까운 앞면 도어 지점에 즉시 연결 되도록 합니다.Using split TCP-based anycast protocol, Azure Front Door ensures that your end users promptly connect to the nearest Front Door point of presence. Azure Front 도어의 다른 기능은 다음과 같습니다.Other features of Azure Front Door include:

    • TLS 종료TLS termination

    • 사용자 지정 도메인Custom domain

    • 웹 애플리케이션 방화벽Web Application Firewall

    • URL 다시 쓰기URL rewrite

    • 세션 선호도Session affinity

    응용 프로그램 트래픽의 필요성을 검토 하 여 가장 적합 한 솔루션을 알아보세요.Review the needs of your application traffic to learn which solution is the most suitable.