클라우드 네이티브 시나리오의 고가용성 아키텍처 모범 사례

[위안추앙 컨퍼런스 미리보기] 1024 프로그래머의 날(이틀 전), 오픈소스 중국 사무실에서 만나 AI에 대해 이야기하자! >>>

저자: Liu Jiaxu(별명: Jiaxu), Alibaba Cloud 컨테이너 서비스 기술 전문가

소개

클라우드 네이티브 기술의 급속한 발전과 엔터프라이즈 IT 분야의 심층적인 적용으로 인해 클라우드 네이티브 시나리오의 고가용성 아키텍처는 엔터프라이즈 서비스의 가용성, 안정성 및 보안을 위해 점점 더 중요해지고 있습니다. 합리적인 아키텍처 설계와 클라우드 플랫폼 기술 지원을 통해 클라우드 네이티브 고가용성 아키텍처는 고가용성, 탄력적인 확장성, 운영 및 유지 관리 단순화, 안정성 및 보안 향상 등의 이점을 제공하여 기업에 보다 안정적이고 효율적인 서비스를 제공할 수 있습니다. 운영 환경.

쿠버네티스는 클라우드 네이티브의 핵심 기술 중 하나로 인프라 자동화, 탄력적 확장성, 마이크로서비스 아키텍처, 자동화된 운영 및 유지 관리 등 컨테이너 오케스트레이션 및 관리 기능을 제공하므로 쿠버네티스의 애플리케이션 고가용성 아키텍처는 클라우드 네이티브이며 고가용성입니다. 기초. 이 기사에서는 ACK(Kubernetes)용 Alibaba Cloud Container Service를 예로 들어 ACK 기반 애플리케이션의 고가용성 아키텍처 및 거버넌스에 대한 모범 사례를 소개합니다.

애플리케이션 고가용성 아키텍처 설계

클라우드 네이티브 애플리케이션의 고가용성 아키텍처 설계는 애플리케이션의 고가용성 개발, 배포 및 거버넌스를 위한 중요한 전제 조건으로, 다음 측면에서 고려할 수 있습니다.

1. 클러스터 설계: 클러스터 제어 평면과 데이터 평면의 구성 요소와 노드는 다중 노드 및 다중 복사본 고가용성을 사용하여 배포되어 K8s 클러스터의 고가용성을 보장합니다. ACK를 예로 들면 제어 평면과 데이터 평면을 포괄하는 클러스터 고가용성 기능을 제공합니다. 제어 플레인에서 ACK Pro 관리 버전 클러스터의 제어 플레인 구성 요소는 여러 복사본을 사용하여 가용성 영역에 배포되고 제어 플레인의 로드 압력에 따라 자동으로 탄력적입니다. ACK 독점 버전은 3개 또는 5개의 마스터로 구성될 수 있습니다. 노드. 데이터 측면에서 ACK는 사용자가 가용성 영역 및 ECS 배포 세트 전반에 걸쳐 노드를 배포하고 추가하도록 선택할 수 있는 기능을 지원합니다.

2. 컨테이너 설계: 애플리케이션은 클러스터에 여러 개의 복사본으로 배포되고, 애플리케이션의 고가용성을 달성하기 위해 배포, Statefulset, OpenKruise CRD 기반으로 애플리케이션 복사본을 관리하며, 애플리케이션이 동적 부하 변화에 대처할 수 있도록 자동 탄력적 정책을 구성합니다. . 다중 복사본 Pod 시나리오에서는 기본 역할과 보조 역할에 복사본이 있는지 여부에 따라 기본 및 보조 고가용성과 다중 활성 고가용성으로 나눌 수 있습니다.

3. 리소스 스케줄링: K8s 스케줄러를 사용하여 애플리케이션 로드 밸런싱 및 장애 조치를 달성합니다. 라벨과 선택기를 사용하여 애플리케이션의 배포 노드 범위를 지정하고 선호도, 반선호도 및 토폴로지 예약 제약 조건 규칙을 사용하여 노드, 가용성 영역, 배포 세트, 토폴로지 도메인 등별로 Pod를 구현하는 애플리케이션의 예약 전략을 제어합니다. 다양한 카테고리 고가용성.

4. 스토리지 설계: 데이터 손실을 방지하기 위해 스토리지를 마운트하기 위한 K8s 영구 볼륨 등 애플리케이션 데이터를 저장하기 위해 영구 스토리지를 사용합니다. 상태 저장 애플리케이션의 경우 StatefulSet을 사용하여 상태 저장 애플리케이션의 복제본 및 스토리지 볼륨을 관리합니다.

5. 오류 복구: K8s의 자동 복구 메커니즘을 사용하여 애플리케이션 오류를 처리합니다. 상태 확인 및 자동 다시 시작을 사용하여 애플리케이션 상태를 모니터링하고 애플리케이션 오류가 발생할 경우 애플리케이션을 자동으로 다시 시작하거나 마이그레이션할 수 있습니다.

6. 네트워크 설계: K8s의 서비스 검색 및 로드 밸런싱 기능을 사용하여 애플리케이션 네트워크 액세스를 구현하고 서비스 및 Ingress를 사용하여 애플리케이션 서비스를 노출합니다.

7. 모니터링 및 경보: K8s 모니터링 및 경보 시스템(예: Prometheus, Thanos, AlertManager 등)을 사용하여 애플리케이션의 실행 상태를 모니터링하고 적시에 오류를 발견하고 처리합니다.

8. 전체 링크 고가용성 설계: 전체 링크 고가용성은 클라우드 네이티브 애플리케이션 시스템 및 서비스에 포함된 모든 구성 요소, 모듈, 서비스, 네트워크 및 기타 링크의 고가용성을 의미합니다. 풀링크 고가용성은 전체 시스템의 아키텍처 설계, 구성 요소 선택 및 구성, 서비스 배포 및 운영 및 유지 관리까지 포괄적인 고려와 구현이 필요한 종합적인 고려 사항입니다. 동시에 특정 비즈니스 요구 사항과 기술 요구 사항에 따라 적절한 타협과 절충이 이루어져야 합니다.

즉, K8s 애플리케이션을 위한 고가용성 아키텍처를 설계하려면 안정적이고 안정적인 애플리케이션 고가용성 아키텍처 및 기능을 달성하기 위해 클러스터, 컨테이너, 리소스 스케줄링, 스토리지, 장애 복구, 네트워크 및 모니터링 알람과 같은 요소를 포괄적으로 고려해야 합니다. 위의 원칙을 참고하여 기존 시스템의 고가용성 전환도 구현할 수 있습니다.

다음에서는 위의 설계 원칙을 바탕으로 Kubernetes가 제공하는 다양한 고가용성 기술과 ACK를 기반으로 한 관련 제품 구현을 소개합니다.

K8의 고가용성 기술 및 ACK에서의 적용

Kubernetes는 클러스터와 애플리케이션의 고가용성을 보장하기 위해 다양한 고가용성 기술과 메커니즘을 제공합니다. 토폴로지 배포 제약 조건, PodAntiAffinity, 컨테이너 상태 확인 및 자동 다시 시작, 스토리지 중복성 및 지속성, 서비스 검색 및 로드 밸런싱 등이 포함됩니다. 이러한 기술과 메커니즘은 가용성이 높은 Kubernetes 클러스터와 애플리케이션을 구축하고 안정적이고 신뢰할 수 있는 서비스를 제공하는 데 도움이 될 수 있습니다. 이에 대해서는 아래에서 소개하겠습니다.

3.1 제어 평면/데이터 평면은 여러 가용성 영역에서 가용성이 높습니다.

클러스터링은 컨트롤 플레인과 데이터 플레인 노드/구성 요소를 서로 다른 가용 영역에 배포하여 고가용성을 달성하는 중요한 고가용성 아키텍처 설계 방법입니다. 가용 영역은 지리적 영역 내에서 클라우드 공급자가 제공하는 논리적으로 독립된 데이터 센터입니다. 여러 가용 영역에 노드를 배포하면 하나의 가용 영역이 실패하거나 사용할 수 없게 되더라도 클러스터가 계속해서 서비스를 제공할 수 있습니다.

다음은 Kubernetes에서 가용영역 기반 컨트롤 플레인/데이터 플레인 노드의 고가용성 구성을 구현하는 데 사용할 수 있는 가용영역 기반 K8s 클러스터 노드의 고가용성 설계의 핵심 사항입니다.

여러 가용 영역 옵션

단일 실패 지점의 위험을 줄이려면 클러스터에 대해 클라우드 공급업체에서 지원하는 여러 가용성 영역을 선택하세요.
제어 영역 노드/구성요소 배포

다양한 가용성 영역에 제어 플레인 노드 및 구성 요소(예: etcd, kube-apiserver, kube-controller-manager, kube-scheduler)를 배포하고 클라우드 공급업체의 로드 밸런서 또는 DNS 확인을 사용하여 트래픽을 백엔드에 분산합니다. 여러 etcd 노드를 사용하여 고가용성 etcd 클러스터를 구성하고 이를 다양한 가용성 영역에 배포합니다. 이렇게 하면 etcd 노드 중 하나가 실패하더라도 클러스터가 계속 작동할 수 있습니다.
데이터 평면 노드 배포

여러 가용성 영역에 데이터 플레인 노드를 분산하여 Pod가 다양한 가용성 영역에 예약되어 교차 가용성 영역 고가용성을 달성할 수 있도록 합니다.
모니터링 및 자동 복구 클러스터 상태를 모니터링하도록 모니터링 시스템을 구성하고 노드 또는 가용 영역 장애 발생 시 자동 장애 조치 및 복구를 위한 자동 복구 메커니즘을 설정합니다.

여러 가용성 영역에 제어 평면 노드/구성 요소 및 데이터 평면 노드를 배포하면 Kubernetes 클러스터의 가용성 및 내결함성이 향상되어 단일 가용성 영역 또는 노드에 장애가 발생하더라도 클러스터가 계속 서비스를 제공할 수 있습니다.

ACK는 제어 평면과 데이터 평면을 포괄하는 클러스터 고가용성 기능을 제공합니다. ACK 컨테이너 서비스는 Kubernetes on Kubernetes 아키텍처를 사용하여 etcd, API 서버, 스케줄러 등을 포함한 사용자 Kubernetes 클러스터 제어 플레인 구성 요소를 호스팅합니다. 각 제어 플레인 구성 요소의 여러 인스턴스는 고가용성 아키텍처를 사용하여 배포 및 관리됩니다. ACK Pro 클러스터가 있는 지역의 가용 영역 수가 3개 이상인 경우 ACK Pro 관리형 클러스터 제어 평면의 SLA는 99.95%이고, ACK Pro 클러스터가 있는 지역의 가용 영역 수가 3개 이상인 경우 위치가 2 이하인 경우 ACK Pro 관리형 클러스터 제어 플레인의 SLA는 99.50%입니다.

ACK 컨테이너 서비스는 호스팅 구성 요소의 고가용성, 보안, 탄력적인 확장 및 축소를 담당합니다. ACK Pro 클러스터는 관리되는 구성 요소에 대한 완전한 관찰 기능을 제공하여 사용자가 클러스터 상태를 모니터링하고 경고하도록 돕습니다.

다음은 가용성 영역별 고가용성 조각화를 제어하는 일반적인 기술과 ACK 시나리오에서의 사용 방법을 소개하며, 데이터 평면의 고가용성 시나리오에서 널리 사용됩니다.

3.1.1 토폴로지 확산 제약

Topology Spread Constraints는 Kubernetes 클러스터에서 Pod 배포를 관리하는 기능입니다. 이는 Pod가 다양한 노드와 가용성 영역에 균등하게 분산되어 애플리케이션 고가용성과 안정성을 향상시킵니다. 이 기술은 배포, StatefulSet, DaemonSet 및 Job/CronJob 워크로드에 적용됩니다.

토폴로지 배포 제약 조건을 사용하면 다음 구성을 설정하여 Pod 배포를 제어할 수 있습니다.

최대 왜곡

각 토폴로지 도메인에서 Pod의 최대 편차 값을 지정합니다. 토폴로지 도메인은 노드, 가용성 영역 또는 기타 사용자 정의 토폴로지 도메인일 수 있습니다. 최대 편차 값은 클러스터의 두 토폴로지 도메인에 있는 Pod 간의 최대 차이를 나타내는 정수입니다. 예를 들어 MaxSkew가 2로 설정된 경우 두 토폴로지 도메인의 Pod 수 차이가 2를 초과할 수 없습니다.
토폴로지키

토폴로지 도메인의 레이블이나 주석을 식별하는 데 사용되는 키를 지정합니다. 노드 레이블(예: node.kubernetes.io/zone)이나 사용자 정의 레이블 또는 주석을 사용할 수 있습니다.
불만족스러울 때

토폴로지 분포 제약 조건을 충족할 수 없을 때 수행할 작업을 지정합니다. 선택할 수 있는 작업은 DoNotSchedule(Pod를 예약하지 않음), ScheduleAnyway(Pod를 강제로 예약) 및 RequireDuringSchedulingIgnoredDuringExecution(토폴로지 배포 제약 조건이 필요하지만 적용하지는 않음)입니다.

이러한 구성을 사용하면 원하는 토폴로지 배포에 따라 클러스터에 포드가 배포되도록 토폴로지 배포 제약 조건이 포함된 정책을 생성할 수 있습니다. 이는 안정성과 가용성을 높이기 위해 다양한 가용 영역이나 노드에 로드를 균등하게 분산해야 하는 애플리케이션에 유용합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-run-per-zone
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app-run-per-zone
  template:
    metadata:
      labels:
        app: app-run-per-zone
    spec:
      containers:
        - name: app-container
          image: app-image
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: "topology.kubernetes.io/zone"
          whenUnsatisfiable: DoNotSchedule

위의 예에서는 maxSkew가 1로 설정되고 topologyKey가 "topology.kubernetes.io/zone"으로 설정되고 whenUnsatisfiable이 DoNotSchedule로 설정된 토폴로지 배포 제약 조건이 생성됩니다. 이는 노드의 레이블 "topology.kubernetes.io/zone"(클라우드 벤더의 가용 영역에 해당)으로 정의된 토폴로지 도메인과 토폴로지 간 Pod 수의 최대 차이에 따라 Pod가 가용 영역별로 강제로 분산됨을 의미합니다. 도메인은 1입니다. 이러한 방식으로 Workload Pod를 가용 영역에 따라 최대한 분산하고 예약할 수 있습니다.

ACK K8s 클러스터 제어 평면은 기본적으로 다중 가용 영역 고가용성 아키텍처를 채택하고 있으며, 또한 데이터 평면에 다중 가용 영역 아키텍처를 구현해야 합니다. ACK 클러스터의 데이터 평면은 노드 풀과 가상 노드로 구성됩니다. 각 노드 풀은 ECS 인스턴스의 그룹으로, 사용자는 노드 풀을 통해 노드를 관리, 확장, 축소하고 일상적인 운영 및 유지 관리를 수행할 수 있습니다. 가상 노드는 탄력적 컨테이너 인스턴스 ECI를 통해 서버리스 컨테이너 실행 환경을 제공할 수 있습니다.

각 노드 풀 뒤에는 노드의 수동 확장 및 자동 확장을 지원하는 탄력적 확장 그룹(ESS)이 있습니다. ACK 노드 풀은 서로 다른 물리적 서버의 동일한 배포 세트에서 ECS 인스턴스를 분산 및 배포할 수 있는 배포 세트를 지원하므로 하나의 물리적 시스템 오류로 인해 여러 ECS 인스턴스의 가동 중지 시간을 방지할 수 있습니다. ACK는 다중 AZ 노드 풀도 지원합니다. 생성 및 작동 중에 서로 다른 AZ에 걸쳐 있는 여러 vSwitch를 노드 풀에 대해 선택할 수 있습니다. 그리고 ECS 인스턴스가 확장 그룹에서 지정한(즉, 여러 VPC 스위치 지정) 여러 가용 영역에 고르게 분산될 수 있도록 균형 잡힌 배포 전략을 선택합니다. 인벤토리 부족이나 기타 이유로 인해 가용성 영역의 균형이 맞지 않는 경우 균형 조정 작업을 수행하여 리소스의 가용성 영역 배포 균형을 맞출 수 있습니다.

K8s 스케줄링의 토폴로지 확산 제약(Topology Spread Constraints)과 결합된 노드, 배포 세트 및 AZ와 같은 다양한 오류 도메인의 메타 정보를 기반으로 다양한 수준의 오류 도메인 격리 기능을 달성할 수 있습니다. 먼저, ACK 노드 풀의 모든 노드는 "kubernetes.io/hostname", "topology.kubernetes.io/zone", "topology.kubernetes.io/region" 등과 같은 토폴로지 관련 레이블을 자동으로 추가합니다. 개발자는 토폴로지 배포 제약 조건을 사용하여 다양한 오류 도메인 간의 Pod 배포를 제어하여 기본 인프라 오류에 대한 내성을 향상시킬 수 있습니다.

3.1.2 토폴로지 분포 제약 조건과 NodeAffinity/NodeSelector의 관계

토폴로지 배포 제약 조건과 NodeAffinity/NodeSelector 간의 관계는 노드 어피니티와 노드 선택기가 주로 특정 노드 범위에 대한 포드의 일정을 제어하는 데 사용되는 반면, 토폴로지 배포 제약 조건은 다양한 토폴로지 도메인 간의 포드 배포를 제어하는 데 더 중점을 둡니다. . 이러한 메커니즘을 결합하여 포드의 예약 및 배포를 보다 세밀하게 제어할 수 있습니다.

NodeAffinity 및 NodeSelector는 토폴로지 분포 제약 조건과 함께 사용할 수 있습니다. 먼저 NodeAffinity 및 NodeSelector를 사용하여 특정 조건을 충족하는 노드를 선택한 다음 토폴로지 배포 제약 조건을 사용하여 이러한 노드의 Pod 배포가 예상되는 토폴로지 배포 요구 사항을 충족하는지 확인할 수 있습니다.

자세한 내용은 [1]을 참조하세요 .

Node Affinity와 Node Selector를 위상적 분포 제약 조건과 함께 혼합하여 사용하는 방법은 [2] 를 참조하세요 .

3.1.3 위상적 분포 제약의 단점

토폴로지 분포 제약 조건에는 몇 가지 제한 사항과 단점이 있으며 이에 유의해야 합니다.

가용 영역 수에 대한 제한: 가용 영역 수가 매우 제한되어 있거나 사용 가능한 가용 영역이 하나만 있는 경우 토폴로지 배포 제약 조건을 사용해도 이점을 얻지 못할 수 있습니다. 이 경우 진정한 가용성 영역 결함 격리 및 고가용성을 달성할 수 없습니다.
포드가 삭제되면 제약조건이 계속 충족된다는 보장이 없습니다. 예를 들어 배포를 축소하면 포드가 고르지 않게 배포될 수 있습니다.
스케줄러는 클러스터의 모든 영역이나 기타 토폴로지 도메인에 대한 사전 지식이 없습니다. 이는 클러스터의 기존 노드를 기반으로 결정됩니다. 이로 인해 노드 풀(또는 노드 그룹)이 0개의 노드로 줄어들고 사용자가 클러스터가 확장될 수 있을 것으로 기대하는 경우 자동 크기 조정 클러스터에서 문제가 발생할 수 있습니다. 이 시점에서는 이러한 토폴로지 도메인이 최소한 고려되지 않습니다. 그 안에 노드가 있습니다.

자세한 내용은 [3]을 참조하세요 .

3.1.4 동시적이고 신속한 탄력적 확장을 달성하기 위한 다중 가용성 영역

ACK 노드 Auto-scaling 구성요소는 사전 스케줄링을 통해 특정 스케일링 그룹에 서비스를 배포할 수 있는지 여부를 확인한 후 지정된 스케일링 그룹에 인스턴스 수를 확장하라는 요청을 보내고 최종적으로 ESS 스케일링 그룹이 인스턴스를 생성합니다. . 그러나 확장 그룹에서 여러 가용 영역 vSwtich를 구성하는 이 모델 기능은 다음과 같은 문제를 야기합니다.

클러스터 리소스가 부족하여 다중 AZ 비즈니스 Pod를 예약할 수 없는 경우 노드 자동 조정 서비스가 조정 그룹 확장을 트리거하지만 가용 영역과 확장해야 하는 인스턴스 간의 관계를 전달할 수 없습니다. ESS 탄력적 확장 그룹이므로 지속적으로 팝업될 수 있습니다. 특정 지역의 여러 인스턴스가 동시에 여러 vSwtich에 팝업되는 대신 여러 가용 영역에서 동시 확장 요구를 충족할 수 없습니다.

다중 가용성 영역 밸런싱은 데이터 유형에 대한 고가용성 시나리오의 일반적인 배포 방법입니다. 비즈니스 압박이 증가하는 경우 다중 가용 영역 균형 잡힌 예약 전략을 적용하면 클러스터의 예약 수준을 충족하기 위해 여러 가용 영역의 인스턴스를 자동으로 확장할 수 있습니다.

여러 가용성 영역에서 노드를 동시에 확장하는 문제를 해결하기 위해 컨테이너 서비스 ACK는 소량의 리소스 중복성을 사용하여 여러 가용성 영역의 탄력적 확장 문제를 방향성 확장 문제로 변환하는 ack-autoscaling-placeholder 구성 요소를 도입합니다. 동시 노드 풀 수.

구체적인 원칙은 다음과 같습니다.

먼저, 각 가용성 영역에 대한 노드 풀을 생성하고 각 노드 풀에 가용성 영역 레이블을 지정합니다.
가용성 영역 레이블 nodeSelector를 구성하여 ack-autoscaling-placeholder를 사용하여 각 가용성 영역에 대한 자리 표시자 Pod를 만듭니다. 기본 자리 표시자 Pod는 상대적으로 가중치가 낮은 PriorityClass를 가지며 애플리케이션 Pod는 자리 표시자 Pod보다 우선순위가 높습니다.
이러한 방식으로 비즈니스는 Pod Pending을 적용한 후 각 Availability Zone의 Pod를 선점하게 됩니다. 반친화성은 가용 영역에 대한 nodeSelector가 되어 확장 영역을 발행하는 노드의 요청을 쉽게 처리할 수 있습니다.

아래 그림의 두 가용 영역은 여러 가용 영역의 동시 확장을 충족하기 위해 기존 아키텍처를 사용하는 방법을 소개하기 위한 예입니다.

자세한 내용은 [4]를 참고하세요 .

3.1.5 가용영역 용량 손상 후 자동 복구

다중 영역 고가용성 클러스터에 AZ 장애가 발생하면 애플리케이션 용량이 손상되는 경우가 많습니다. K8s는 애플리케이션 복사본 수 또는 HPA(수평형 포드 확장) 구성에 따라 자동으로 용량을 확장합니다. 이를 위해서는 클러스터 리소스를 자동으로 확장하기 위해 클러스터를 Cluster AutoScaler 또는 가상 노드로 구성해야 합니다. Cluster AutoScaler를 사용하면 초과 할당을 통해 리소스를 예약할 수 있습니다. 이를 통해 컨테이너 애플리케이션을 빠르게 시작하고 기본 확장이 느리거나 실패하여 발생하는 비즈니스 중단을 방지할 수 있습니다. 자세한 내용은 [5]를 참고하세요 .

3.2 노드별 Pod 반친화성 적용(PodAntiAffinity)

Pod Anti-Affinity는 Pod를 예약할 때 Pod가 동일한 노드에 예약되지 않도록 하는 데 사용되는 Kubernetes의 예약 전략입니다. 이는 애플리케이션의 고가용성 및 결함 격리 기능을 향상시키기 위해 Pod 노드를 분산하는 데 사용될 수 있습니다.

포드 반선호도 정책을 사용하면 다음 방법을 구성하여 포드의 노드 분산을 제어할 수 있습니다.

1.예약 중 필수, 실행 중 무시됨

이는 예약 시간에 Pod 간의 반선호도 관계가 충족되도록 요구하는 강제 정책입니다. 이는 Kubernetes 스케줄러가 Pod를 예약할 때 동일한 노드에 예약되지 않도록 최선을 다한다는 의미입니다. 그러나 예약 후 노드 리소스가 부족하거나 다른 이유로 인해 동일한 노드에서 이러한 Pod를 실행해야 하는 경우 Kubernetes는 이 반선호도 정책을 무시합니다.

2.예약 중 선호 실행 중 무시됨

이는 Pod 간의 반선호도 관계 유지를 권장하는 기본 전략이지만 필수 사항은 아닙니다. 스케줄러에 여러 선택 사항이 있는 경우 동일한 노드에서 이러한 포드를 예약하지 않으려고 합니다. 그러나 다른 실행 가능한 옵션을 사용할 수 없는 경우 스케줄러는 동일한 노드에서 이러한 포드를 계속 예약할 수 있습니다.

포드 반선호도 정책을 사용하면 클러스터 내 포드 배포를 제어하고 동일한 노드에서 포드 예약을 방지하여 노드 분산을 달성할 수 있습니다. 이는 가용성과 결함 격리를 개선하기 위해 여러 노드에서 Pod를 실행해야 하는 애플리케이션에 유용합니다.

다음은 Pod 반친화성의 예입니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-run-per-node
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app-run-per-node
  template:
    metadata:
      labels:
        app: app-run-per-node
    spec:
      containers:
        - name: app-container
          image: app-image
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: app
                    operator: In
                    values:
                      - app-run-per-node
              topologyKey: "kubernetes.io/hostname"

위의 예시에서는 포드에 대해 반선호도 설정이 설정되어 있으므로 스케줄러는 예약할 때 이러한 포드가 동일한 노드에 예약되지 않도록 해야 합니다. 토폴로지 키는 "kubernetes.io/hostname"으로 설정되어 스케줄러가 여러 노드 간에 분산될 수 있습니다.

포드 반친화성과 노드 어피니티(노드 어피니티)는 다른 개념입니다. 노드 어피니티는 포드가 특정 라벨이 있는 노드에 예약되는 것을 선호하도록 지정하는 데 사용되는 반면, 포드 반친화성은 포드가 동일한 노드에 예약되지 않도록 하는 데 사용됩니다. 이 두 가지 스케줄링 전략을 결합하면 보다 유연하고 내결함성이 있는 스케줄링 및 노드 배포가 가능해집니다.

TopologySpreadConstraints를 기반으로 노드별 포드의 고가용성 스케줄링 효과를 달성하는 것도 가능합니다. topologyKey를 지정하면 "kubernetes.io/hostname"은 각 노드가 노드 간 편향 비교를 달성하기 위한 토폴로지 도메인이 되는 것과 같습니다. 다음은 위상 분포 제약 조건의 예입니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app-container
          image: my-app-image
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: "kubernetes.io/hostname"
          whenUnsatisfiable: DoNotSchedule

위의 예에서는 maxSkew가 1로 설정되고 topologyKey가 "kubernetes.io/hostname"으로 설정되고 whenUnsatisfiable이 DoNotSchedule로 설정된 토폴로지 배포 제약 조건이 생성됩니다. 이는 고가용성을 위해 포드를 노드별로 분산시키기 위해 각 노드에서 1개의 포드만 실행할 수 있음을 의미합니다.

3.3 애플리케이션 다중 복사본 고가용성

Kubernetes에서는 배포, Statefulset 및 OpenKruise와 같은 CRD 고급 리소스와 같은 다양한 워크로드를 기반으로 애플리케이션의 다중 복사본 고가용성을 달성할 수 있습니다. 배포를 예로 들면, 배포 리소스는 Pod 복사본 수를 정의하는 데 사용되는 컨트롤러로, 지정된 수의 복사본이 항상 실행되도록 하고 복사본이 실패할 경우 자동으로 새 복사본을 생성하는 역할을 담당합니다.

3.3.1 애플리케이션 다중 활동 및 고가용성

애플리케이션의 다중 활동 및 고가용성은 애플리케이션의 여러 복사본이 트래픽을 수신하고 독립적으로 서비스를 처리할 수 있음을 의미합니다. 복사본 수는 HPA를 통해 구성할 수 있으며 로드 압력에 의해 트리거되는 자동 탄력성을 사용하여 동적 트래픽에 적응할 수 있습니다. API 서버 및 Nginx Ingress 컨트롤러. 이러한 형태의 고가용성 설계에서는 데이터 일관성 및 여러 복사본의 성능과 같은 문제를 고려해야 합니다.

3.3.2 애플리케이션 활성 및 백업 고가용성

애플리케이션의 기본 및 백업 고가용성은 애플리케이션의 여러 복사본에 기본 복사본과 백업 복사본이 있음을 의미합니다. 가장 일반적인 것은 하나의 마스터와 하나의 백업이며, 하나의 마스터와 여러 개의 슬레이브와 같이 더 복잡한 형태도 있습니다. Master는 Lock Grabing 및 기타 방법에 따라 선택되며 Controller 형태로 적용 가능한 Component입니다. 예를 들어 Etcd, KubeControllerManager 및 KubeScheduler는 모두 활성 및 백업 모드의 고가용성 애플리케이션입니다.

사용자는 자신의 비즈니스 형태와 시나리오에 따라 멀티 액티브 또는 액티브-스탠바이를 사용하도록 컨트롤러를 설계할 수 있습니다.

3.3.3 PDB는 애플리케이션 고가용성을 향상시킵니다.

애플리케이션 가용성을 더욱 향상시키기 위해 Kubernetes에서 PDB(Pod Disruption Budget) 구성을 사용할 수도 있습니다. PDB를 사용하면 사용자는 사용 가능한 최소 복제본 수를 정의할 수 있습니다. 노드 유지 관리 또는 장애가 발생하면 Kubernetes는 최소한 지정된 수의 복제본이 계속 실행되도록 합니다. PDB는 너무 많은 복제본이 동시에 종료되는 것을 방지할 수 있습니다. 이는 MessageQueue 제품과 같이 여러 라이브 복제본이 트래픽을 처리하는 시나리오에 특히 적합하여 서비스 중단을 방지합니다.

PDB를 사용하려면 배포 또는 StatefulSet의 구성에 PDB 리소스를 추가하고 사용 가능한 최소 복제본 수를 지정합니다. 예를 들어 다음은 PDB를 사용한 배포 구성의 예입니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-with-pdb
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app-with-pdb
  template:
    metadata:
      labels:
        app: app-with-pdb
    spec:
      containers:
        - name: app-container
          image: app-container-image
          ports:
            - containerPort: 80
  ---
  apiVersion: policy/v1beta1
  kind: PodDisruptionBudget
  metadata:
    name: pdb-for-app
  spec:
    minAvailable: 2
    selector:
      matchLabels:
        app: app-with-pdb

위의 예에서 배포 구성은 3개의 복제본을 정의하고 PDB 구성은 최소 2개의 복제본을 사용 가능한 상태로 유지하도록 지정합니다. 즉, 노드 유지 관리 또는 장애 중에도 Kubernetes는 최소 2개의 복제본이 항상 실행되도록 보장하여 Kubernetes 클러스터의 애플리케이션 가용성을 향상하고 서비스 중단 가능성을 줄입니다.

3.4 상태 감지 및 자가 치유

Kubernetes에서는 다양한 유형의 프로브를 구성하여 컨테이너의 상태와 가용성을 모니터링하고 관리할 수 있습니다. 다음은 Kubernetes에서 일반적으로 사용되는 프로브 구성 및 전략입니다.

활동성 프로브 활동성 프로브는 컨테이너가 여전히 정상적으로 실행되고 있는지 여부를 모니터링하는 데 사용됩니다. 활동성 프로브가 실패하면(200이 아닌 상태 코드를 반환) Kubernetes는 컨테이너를 다시 시작합니다. 생존 프로브를 구성하면 문제가 발생할 때 컨테이너가 자동으로 다시 시작될 수 있습니다. 활동성 프로브는 HTTP 요청, TCP 소켓 또는 명령 실행을 사용하여 감지할 수 있습니다.
준비 프로브 준비 프로브는 컨테이너가 트래픽을 수신할 준비가 되었는지 여부를 모니터링하는 데 사용됩니다. Kubernetes는 준비 프로브가 성공한 경우(200 상태 코드 반환)에만 트래픽을 컨테이너로 전달합니다. 준비 상태 프로브를 구성하면 컨테이너가 완전히 시작되고 요청을 받을 준비가 된 경우에만 서비스의 로드 밸런서에 컨테이너가 추가되도록 할 수 있습니다.
시작 프로브 시작 프로브는 컨테이너가 시작되는지 여부를 모니터링하는 데 사용됩니다. 활성 프로브 및 준비 프로브와 달리 시작 프로브는 컨테이너 시작 중에 실행되며 프로브가 성공한 후에만 컨테이너가 준비된 것으로 표시됩니다. 프로브 시작이 실패하면 Kubernetes는 컨테이너를 실패로 표시하고 컨테이너를 다시 시작합니다.
다시 시작 정책 다시 시작 정책은 컨테이너가 종료될 때 수행되어야 하는 작업을 정의합니다. Kubernetes는 다음 세 가지 다시 시작 전략을 지원합니다.

- 항상: Kubernetes는 종료 방법에 관계없이 컨테이너를 자동으로 다시 시작합니다.
- OnFailure: Kubernetes는 컨테이너가 0이 아닌 상태로 종료되는 경우에만 컨테이너를 자동으로 다시 시작합니다.
- 안 함: Kubernetes는 종료 방법에 관계없이 컨테이너를 자동으로 다시 시작하지 않습니다.

이는 포드 또는 배포 구성에서 해당 프로브 및 다시 시작 정책을 추가하여 구성할 수 있습니다. 예를 들면 다음과 같습니다.

apiVersion: v1
kind: Pod
metadata:
  name: app-with-probe
spec:
  containers:
    - name: app-container
      image: app-image
      livenessProbe:
        httpGet:
          path: /health
          port: 80
        initialDelaySeconds: 10
        periodSeconds: 5
      readinessProbe:
        tcpSocket:
          port: 8080
        initialDelaySeconds: 15
        periodSeconds: 10
      startupProbe:
        exec:
          command:
            - cat
            - /tmp/ready
        initialDelaySeconds: 20
        periodSeconds: 15
      restartPolicy: Always

위의 예에서 활동성 프로브(HTTP GET 요청을 통해 /health 경로가 있는 포트 80 감지), 준비 프로브(TCP 소켓을 통해 포트 8080 감지) 및 시작 프로브(cat /tmp/ready 명령 사용) 컨테이너가 시작되었는지 여부를 감지하기 위해) 그리고 다시 시작 정책은 Always입니다. 실제 필요에 따라 컨테이너의 특성과 상태 점검 요구 사항을 기반으로 적절한 구성이 가능합니다.

3.5 애플리케이션과 데이터 분리

Kubernetes에서는 PV(영구 볼륨) 및 PVC(영구 볼륨 클레임)를 사용하여 애플리케이션과 데이터 분리를 달성하거나 적절한 백엔드 데이터베이스 서비스 스토리지를 선택할 수 있습니다.

PV 및 PVC는 애플리케이션이 기본 스토리지 기술과 독립적으로 사용할 수 있는 추상화 계층을 제공합니다. 영구 볼륨은 클러스터의 스토리지 리소스이며 포드 및 노드와 독립적입니다. 영구 볼륨 신청은 스토리지 리소스를 애플리케이션의 포드에 바인딩하는 데 사용되는 영구 볼륨에 대한 요청입니다.

올바른 영구 볼륨 신청 및 영구 볼륨을 선택하려면 고려해야 할 몇 가지 요소가 있습니다.

저장 유형

애플리케이션의 요구 사항에 따라 적절한 스토리지 유형을 선택하세요. Kubernetes는 로컬 스토리지, 네트워크 스토리지(예: NFS, iSCSI 등), 클라우드 공급자의 영구 스토리지(예: Alibaba Cloud OSS 등), 외부 스토리지 플러그인(예: Ceph 등)을 포함한 다양한 스토리지 유형을 지원합니다. , GlusterFS 등). 애플리케이션의 읽기 및 쓰기 성능, 데이터 보호, 가용성 요구 사항에 따라 적절한 스토리지 유형을 선택하세요.
저장

애플리케이션의 스토리지 요구 사항에 따라 적절한 스토리지 용량을 선택하세요. 영구 볼륨을 생성할 때 스토리지 용량의 크기 범위를 지정할 수 있습니다. 영구 볼륨 신청을 생성할 때 필요한 스토리지 용량을 지정할 수 있습니다. 데이터 저장소 요구 사항을 충족할 만큼 충분한 저장소 공간을 애플리케이션에 제공해야 합니다.
액세스 모드

애플리케이션의 액세스 모드에 따라 적절한 액세스 모드를 선택하십시오. Kubernetes는 일관된 읽기 및 쓰기(ReadWriteOnce), 여러 번 읽고 쓰기(ReadWriteMany), 읽기 전용(ReadOnlyMany)을 포함한 여러 액세스 모드를 지원합니다. 애플리케이션의 다중 노드 액세스 요구 사항에 따라 적절한 액세스 모드를 선택하세요.

RDS와 같은 적절한 백엔드 데이터 서비스를 선택할 때 다음 요소를 고려해야 합니다.

데이터베이스 유형 및 기능

애플리케이션의 요구 사항에 따라 적절한 데이터베이스 유형을 선택하세요. 관계형 데이터베이스(예: MySQL, PostgreSQL), NoSQL 데이터베이스(예: MongoDB, Cassandra) 등과 같은 다양한 데이터베이스 유형은 다양한 기능과 적응성을 제공합니다. 애플리케이션의 데이터 모델 및 쿼리 요구 사항에 따라 적절한 데이터베이스 유형을 선택하십시오.
성능 및 확장성

애플리케이션의 성능 요구 사항에 따라 백엔드 데이터 서비스를 선택하세요. 데이터베이스의 성능 지표(처리량, 대기 시간 등)와 확장 능력을 고려하세요.
가용성 및 안정성

백엔드 데이터 서비스를 선택할 때 가용성과 안정성을 고려하세요. 클라우드 제공업체의 관리형 데이터베이스 서비스는 일반적으로 고가용성과 자동화된 백업 기능을 제공합니다. 애플리케이션의 가용성 및 데이터 보호 요구 사항을 충족하는 백엔드 데이터 서비스를 선택하십시오.

3.6 로드 밸런싱 고가용성 구성

기존의 로드 밸런싱 CLB는 동일한 지역에서 기계실 간 재해 복구를 달성하기 위해 대부분의 지역에 여러 가용성 영역을 배포했습니다. 서비스 주석을 사용하여 SLB/CLB의 활성 및 백업 가용 영역을 지정할 수 있습니다. 활성 및 백업 가용 영역은 노드 풀의 ECS 가용 영역과 일치해야 가용 영역 간 데이터 전달을 줄이고 네트워크 액세스를 향상시킬 수 있습니다. 성능.

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-master-zoneid: "cn-hangzhou-a"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-slave-zoneid: "cn-hangzhou-b"
  name: nginx
  namespace: default
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx
  type: LoadBalancer

가용성 영역 간 네트워크 트래픽을 줄이고 네트워크 성능을 향상시키기 위해. Kubernetes 1.23에 도입된 토폴로지 인식 힌트를 사용하여 토폴로지 인식 최근접 라우팅 기능을 구현할 수 있습니다.

3.7 클라우드 디스크 고가용성 구성

현재 Alibaba Cloud 클라우드 디스크는 단일 가용 영역에서만 생성 및 탑재할 수 있습니다. 클라우드 디스크를 다중 가용 영역 클러스터의 영구 애플리케이션용 데이터 스토리지로 사용하려면 토폴로지 인식 클라우드 디스크 스토리지 유형 alicloud-를 선택해야 합니다. ACK에서 제공하는 디스크 토폴로지 [6] 이 스토리지 클래스의 볼륨 바인딩 모드는 기본적으로 WaitForFirstConsumer로 설정되며 해당 가용성 영역에서 PertantVolumeClaim이 생성될 때까지 지연된 바인딩을 지원합니다. 다중 가용 영역 토폴로지 인식을 지정하여 스토리지 볼륨을 생성하는 보다 세분화된 ESSD 클라우드 디스크 스토리지 클래스를 생성할 수 있습니다. 스토리지 선언 및 지속성 애플리케이션은 다음과 같습니다. 자세한 내용은 문서 [7]을 참조 하세요 .

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: alicloud-disk-topology-essd
provisioner: diskplugin.csi.alibabacloud.com
parameters:
  type: cloud_essd
  fstype: ext4
  diskTags: "a:b,b:c"
  zoneId: “cn-hangzhou-a,cn-hangzhou-b,cn-hangzhou-c” #指定可用区范围来生成云盘
  encrypted: "false"
  performanceLevel: PL1 #指定性能类型
  volumeExpandAutoSnapshot: "forced" #指定扩容编配的自动备份开关，该设置仅在type为"cloud_essd"时生效。
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Retain
allowVolumeExpansion: true
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: topology-disk-pvc
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 100Gi
  storageClassName: alicloud-disk-topology-essd
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: "mysql"
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - image: mysql:5.6
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: "mysql"
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: topology-disk-pvc

3.8 가상 노드 고가용성 구성

가상 노드는 Kubernetes 애플리케이션이 탄력적인 컨테이너 인스턴스 ECI에 배포되도록 지원하여 노드 운영 및 유지 관리의 필요성을 없애고 필요에 따라 이를 생성하여 예약된 리소스의 낭비를 줄입니다. 갑작스러운 트래픽에 대응하기 위해 사업을 급속히 수평적으로 확장하거나, 작업 처리를 위해 대량의 인스턴스를 론칭할 때, 가용 영역에 해당 사양의 인스턴스 재고가 부족하거나, 지정된 스위치 IP가 소진되는 등의 상황이 발생할 수 있습니다. ECI 인스턴스 생성 실패. . ACK Serverless의 다중 가용 영역 기능을 사용하면 ECI 인스턴스 생성 성공률을 높일 수 있습니다.

ECI 프로필을 통해 여러 AZ에 vSwitch를 구성하여 여러 AZ 애플리케이션에 가상 노드를 배포할 수 있습니다.

ECI는 압력 분산 효과를 달성하기 위해 포드 생성 요청을 모든 vSwitch에 분산합니다.
Pod 생성 요청에서 vSwitch에 인벤토리가 없는 상황이 발생하면 자동으로 다음 vSwitch로 전환하여 계속해서 생성을 시도합니다.

실제 필요에 따라 kube-system/eci-profile configmap에서 vswitch 필드를 수정하면 수정 사항이 즉시 적용됩니다.

kubectl -n kube-system edit cm eci-profile

apiVersion: v1
data:
  kube-proxy: "true"
  privatezone: "true"
  quota-cpu: "192000"
  quota-memory: 640Ti
  quota-pods: "4000"
  regionId: cn-hangzhou
  resourcegroup: ""
  securitygroupId: sg-xxx
  vpcId: vpc-xxx
  vswitchIds: vsw-xxx,vsw-yyy,vsw-zzz
kind: ConfigMap

관련 내용은 [8] 에서 확인할 수 있다 .

3.9 모니터링 알람 구성

K8s 자체가 드러내는 지표와 kube-state-metrics 등의 구성 요소를 통해 Pod, Node 등 리소스의 고가용성과 사용 가능한 Zone의 분포를 효과적으로 모니터링할 수 있으며, 이는 문제를 빠르게 발견하고 찾아내는 데 큰 의미가 있습니다. 생산 환경에서는 K8s 버전 및 구성 요소 버전 업그레이드에 따라 모니터링 및 경보 시스템이 지속적으로 구축되고 반복적으로 업데이트되므로 새로운 지표에 지속적으로 주의를 기울이고 비즈니스 시나리오에 따라 모니터링 및 경보 시스템에 도입하는 것이 좋습니다. 다음은 참고용으로 리소스 고가용성에 대한 두 가지 경보 구성을 나열합니다.

3.9.1 애플리케이션 로드 복사 불가 알람 모니터링

K8s의 kube-state-metrics는 애플리케이션 로드 배포/Statefulset/Daemonset의 사용할 수 없는 복사본 수, 총 복사본 수 등을 집계하고 분석할 수 있으며, 이러한 유형의 지표를 기반으로 애플리케이션에 사용할 수 없는 복사본이 있는지 여부를 확인할 수 있습니다. 전체 복사본 수 중 사용할 수 없는 복사본의 비율 부분적으로 또는 완전히 영향을 받은 서비스에 대한 모니터링 및 경고를 실현합니다.

배포를 예로 들면 AlertManager/Thanos Ruler의 알람 예시는 다음과 같습니다.

# kube-system或者monitoring中的Deployment存在不可用副本，持续1m，则触发告警，告警serverity配置为L1
- alert: SystemPodReplicasUnavailable
  expr: kube_deployment_status_replicas_unavailable{namespace=~"kube-system|monitoring",deployment!~"ack-stub|kubernetes-kdm"} > 0
  labels:
    severity: L1
  annotations:
    summary: "namespace={{$labels.namespace}}, deployment={{$labels.deployment}}: Deployment存在不可用Replica"
  for: 1m
# kube-system或者monitoring中的Deployment副本总数>0，且全部副本不可用，持续1m，则触发告警，告警serverity配置为L1
- alert: SystemAllPodReplicasUnavailable
  expr: kube_deployment_status_replicas_unavailable{namespace=~"kube-system|monitoring"} == kube_deployment_status_replicas{namespace=~"kube-system|monitoring"} and kube_deployment_status_replicas{namespace=~"kube-system|monitoring"} > 0
  labels:
    severity: L1
  annotations:
    summary: "namespace={{$labels.namespace}}, deployment={{$labels.deployment}}: Deployment全部Replicas不可用"
  for: 1m

3.9.2 클러스터 가용 영역에서 비정상 노드의 비율에 대한 경보 모니터링

K8s의 kube-controller-manager 구성 요소는 비정상 노드 수, 정상 노드 비율, 가용 영역의 총 노드 수를 계산하고 관련 경보를 구성할 수 있습니다.

# HELP node_collector_unhealthy_nodes_in_zone [ALPHA] Gauge measuring number of not Ready Nodes per zones.
# TYPE node_collector_unhealthy_nodes_in_zone gauge
node_collector_unhealthy_nodes_in_zone{zone="cn-shanghai::cn-shanghai-e"} 0
node_collector_unhealthy_nodes_in_zone{zone="cn-shanghai::cn-shanghai-g"} 0
node_collector_unhealthy_nodes_in_zone{zone="cn-shanghai::cn-shanghai-l"} 0
node_collector_unhealthy_nodes_in_zone{zone="cn-shanghai::cn-shanghai-m"} 0
node_collector_unhealthy_nodes_in_zone{zone="cn-shanghai::cn-shanghai-n"} 0
# HELP node_collector_zone_health [ALPHA] Gauge measuring percentage of healthy nodes per zone.
# TYPE node_collector_zone_health gauge
node_collector_zone_health{zone="cn-shanghai::cn-shanghai-e"} 100
node_collector_zone_health{zone="cn-shanghai::cn-shanghai-g"} 100
node_collector_zone_health{zone="cn-shanghai::cn-shanghai-l"} 100
node_collector_zone_health{zone="cn-shanghai::cn-shanghai-m"} 100
node_collector_zone_health{zone="cn-shanghai::cn-shanghai-n"} 100
# HELP node_collector_zone_size [ALPHA] Gauge measuring number of registered Nodes per zones.
# TYPE node_collector_zone_size gauge
node_collector_zone_size{zone="cn-shanghai::cn-shanghai-e"} 21
node_collector_zone_size{zone="cn-shanghai::cn-shanghai-g"} 21
node_collector_zone_size{zone="cn-shanghai::cn-shanghai-l"} 21
node_collector_zone_size{zone="cn-shanghai::cn-shanghai-m"} 21
node_collector_zone_size{zone="cn-shanghai::cn-shanghai-n"} 21

AlertManager/Thanos Ruler의 알람 예시는 다음과 같습니다.

# node_collector_zone_health <= 80 如果可用区内健康节点比例小于80%，就触发告警。
- alert: HealthyNodePercentagePerZoneLessThan80
  expr: node_collector_zone_health <= 80
  labels:
    severity: L1
  annotations:
    summary: "zone={{$labels.zone}}: 可用区内健康节点与节点总数百分比 <= 80%"
  for: 5m

애플리케이션을 위한 단일/다중 클러스터 고가용성 아키텍처

위 3장에서 소개한 고가용성 기술과 Alibaba Cloud의 제품 역량이 제공하는 제품 역량을 기반으로 단일 클러스터 내의 고가용성 아키텍처를 완벽하게 실현할 수 있습니다. 멀티 클러스터 고가용성 아키텍처는 단일 클러스터 고가용성 아키텍처를 더욱 업그레이드한 고가용성 아키텍처로, 클러스터/지역 전반에 걸쳐 고가용성 서비스 기능을 제공합니다.

다중 지역, 다중 클러스터 배포 및 통합된 애플리케이션 아키텍처를 통해 지역 간 네트워크 전송 지연, 비용 및 실패율 문제를 극복하는 동시에 고가용성을 보장할 수 있습니다. 이를 통해 사용자에게 더 나은 사용자 경험을 제공하는 동시에 비즈니스 안정성과 신뢰성을 보장할 수 있습니다.

4.1 단일 지역, 다중 가용 영역 고가용성 클러스터

위의 3장에서 소개한 고가용성 기술과 Alibaba Cloud 제품이 제공하는 기능을 기반으로 단일 클러스터 차원 내에서 고가용성 아키텍처를 실현할 수 있는데, 이에 대해서는 여기서 다시 설명하지 않습니다.

4.2 단일 지역 다중 클러스터 고가용성 + 다중 지역 다중 클러스터 고가용성

첫째, 각 ACK 클러스터는 다중 가용 영역 고가용성 아키텍처를 채택하고 비즈니스 애플리케이션은 다중 가용 영역 배포 모드를 채택하여 SLB를 통해 외부 서비스를 제공합니다.

다중 지역 배포와 다중 AZ 배포는 본질적으로 유사하지만 지역 간 네트워크 전송 지연, 비용 및 실패율의 차이로 인해 서로 다른 배포 및 애플리케이션 아키텍처를 적용해야 합니다. 플랫폼 계층의 경우 지역 간 Kubernetes 클러스터를 구현하는 것이 권장되지 않으며 대신 다중 지역 다중 클러스터 접근 방식을 채택하고 이를 통합된 애플리케이션 아키텍처와 결합하여 다중 지역 고가용성 아키텍처를 달성하는 것이 좋습니다. . 여러 개의 독립적인 Kubernetes 클러스터를 서로 다른 지역에 배포하고 각 클러스터는 자체 노드와 애플리케이션을 관리합니다. 각 지역의 클러스터는 독립적이며 자체 마스터 노드와 작업자 노드를 갖습니다. 이를 통해 지역 간 네트워크 지연 및 실패율을 줄이고 애플리케이션 가용성과 성능을 향상시킬 수 있습니다.

동시에, 통합된 애플리케이션 아키텍처를 채택하여 애플리케이션을 독립된 단위로 분할하고, 각 단위는 여러 지역의 클러스터에 복사본을 배포합니다. 로드 밸런싱 및 DNS 해석 기술을 통해 사용자 요청을 가장 가까운 위치로 라우팅하고, 트래픽을 가장 가까운 지역으로 분산시키며, 네트워크 지연 시간을 단축하고, 고가용성 및 재해 복구 기능을 제공할 수 있습니다.

지역 간 ACK 클러스터에 네트워크 상호 연결이 필요한 경우 CEN(클라우드 엔터프라이즈 네트워크)을 통해 다중 지역 VPC 간의 상호 연결을 달성할 수 있습니다. 지역 간 비즈니스 트래픽 스케줄링은 글로벌 트래픽 관리 GTM 및 클라우드 분석 서비스를 통해 구현됩니다.

관측 가능성, 보안 정책, 클러스터 간 애플리케이션 통합 제공 등 여러 지역의 여러 클러스터에 대한 통합 관리를 수행하려는 경우. 이를 달성하기 위해 ACK One을 사용할 수 있습니다. 분산 클라우드 컨테이너 플랫폼 ACK One(Distributed Cloud Container Platform for Kubernetes)은 Alibaba Cloud가 하이브리드 클라우드, 멀티 클러스터, 분산 컴퓨팅, 재해 복구 및 기타 시나리오를 위해 출시한 엔터프라이즈급 클라우드 네이티브 플랫폼입니다. ACK One은 모든 지역, 모든 인프라에서 사용자의 Kubernetes 클러스터를 연결하고 관리할 수 있으며 컴퓨팅, 네트워크, 스토리지, 보안, 모니터링, 로그, 작업, 애플리케이션, 트래픽 등을 지원하는 일관된 관리 및 커뮤니티 호환 API를 제공합니다. 통합된 운영 및 유지 관리 관리 및 제어. ACK One에 대해 더 알고 싶으시다면 딩톡 검색 그룹번호: 35688562 로 편하게 가입해주세요 .

ACK One은 2개소, 3개 센터에서 응용시스템 재해복구 솔루션을 구축하고 있으며, 관련 내용은 [9]를 참고하시기 바랍니다.

링크 요약

클라우드 네이티브 시나리오의 고가용성 아키텍처와 애플리케이션 설계는 엔터프라이즈 서비스의 가용성, 안정성, 보안에 매우 중요하며 애플리케이션 가용성과 사용자 경험을 효과적으로 개선하고 결함 격리와 내결함성을 제공할 수 있습니다. 이 기사에서는 클라우드 네이티브 애플리케이션을 위한 고가용성 아키텍처 설계의 핵심 원칙, K8s 고가용성 기술, ACK 시나리오에서의 사용 및 구현, 단일 클러스터 및 다중 클러스터 고가용성 아키텍처의 사용을 소개합니다. 관련 요구 사항이 있는 기업에 참조 및 도움을 제공하기 위해 ACK는 고객에게 안전하고 안정적이며 성능이 뛰어나고 비용이 최적화되고 지속적으로 업그레이드되는 클라우드 기반 제품 및 서비스를 계속 제공할 것입니다!

이 글은 Alibaba Cloud Container Service의 대표인 Yi Li가 ACK 고가용성 아키텍처 분석에 대해 훌륭하게 공유한 글입니다. 진심으로 감사드립니다!

[2] https://kubernetes.io/blog/2020/05/introducing-podtopologyspread/

[3] https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/#known-limitations

[4] https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/configure-auto-scaling-for-cross-zone-deployment

[5] https://help.aliyun.com/document_detail/184995.html

[6] https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/dynamically-provision-a-disk-volume-by-using-the-cli-1 #섹션-dh5-bd8-x0q

[7] https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/use-dynamically-provisioned-disk-volumes

[8] https://help.aliyun.com/zh/ack/serverless-kubernetes/user-guide/create-ecis-across-zones

[9] https://developer.aliyun.com/article/913027