OpenShift를 사용한 고가용성 권장사항


이 문서에서는 Compute Engine에서 Red Hat OpenShift Container Platform 워크로드로 고가용성 (HA)을 달성하기 위한 권장사항을 설명합니다. 이 문서에서는 오류가 발생할 때 워크로드의 가용성을 유지하는 데 도움이 되는 애플리케이션 수준 전략에 중점을 둡니다. 이러한 전략을 사용하면 단일 장애점을 제거하고 자동 페일오버 및 복구 메커니즘을 구현할 수 있습니다.

이 문서는 플랫폼 및 애플리케이션 아키텍트를 대상으로 하며 OpenShift 배포에 대한 경험이 있다고 가정합니다. OpenShift 배포 방법에 관한 자세한 내용은 Red Hat 문서를 참고하세요.

여러 영역에 배포 분산

Google Cloud 리전 내 여러 영역에 걸쳐 OpenShift를 배포하는 것이 좋습니다. 이 접근 방식을 사용하면 한 영역에서 중단이 발생하더라도 클러스터의 제어 영역 노드가 배포가 확장된 다른 영역에서 계속 작동할 수 있습니다. 여러 영역에 OpenShift를 배포하려면 install-config.yaml 파일에서 동일한 리전의 Google Cloud 영역 목록을 지정합니다.

노드가 배포되는 위치를 세분화하여 제어하려면 VM이 동일한 영역의 여러 장애 도메인에 분산되도록 하는 VM 배치 정책을 정의하는 것이 좋습니다. 클러스터 노드에 분산 배치 정책을 적용하면 위치별 중단의 영향을 동시에 받는 노드 수를 줄일 수 있습니다. 기존 클러스터의 분산 정책을 만드는 방법에 관한 자세한 내용은 분산 배치 정책을 만들어 VM에 적용을 참고하세요.

마찬가지로 여러 포드가 동일한 노드에 예약되지 않도록 하려면 포드 안티어피니티 규칙을 사용하는 것이 좋습니다. 이러한 규칙은 애플리케이션 복제본을 여러 영역에 분산합니다. 다음 예는 pod 제외 조정 규칙을 구현하는 방법을 보여줍니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: my-app-namespace
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      # Pod Anti-Affinity: Prefer to schedule new pods on nodes in different zones.
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: my-app
            topologyKey: topology.kubernetes.io/zone
      containers:
      - name: my-app-container
        image: quay.io/myorg/my-app:latest
        ports:
        - containerPort: 8080

웹 프런트엔드 또는 REST API와 같은 스테이트리스 서비스의 경우 각 서비스 또는 경로에 대해 여러 개의 포드 복제본을 실행하는 것이 좋습니다. 이 접근 방식을 사용하면 트래픽이 사용 가능한 영역의 포드로 자동으로 라우팅됩니다.

리소스 오버커밋을 방지하기 위해 선제적으로 부하 관리

리소스 오버커밋을 방지하려면 애플리케이션의 부하를 사전에 관리하는 것이 좋습니다. 오버커밋하면 부하가 발생할 때 서비스 성능이 저하될 수 있습니다. 리소스 요청 한도를 설정하여 오버커밋을 방지할 수 있습니다. 자세한 내용은 포드의 리소스 관리를 참고하세요. 또한 수평형 포드 자동 확장 처리를 사용하여 CPU, 메모리 또는 커스텀 측정항목을 기준으로 복제본을 자동으로 확장하거나 축소할 수 있습니다.

다음 부하 분산 서비스도 사용하는 것이 좋습니다.

  • OpenShift 인그레스 운영자 인그레스 운영자는 HAProxy 기반 인그레스 컨트롤러를 배포하여 포드로의 라우팅을 처리합니다. 특히 인그레스 컨트롤러에 전역 액세스를 구성하는 것이 좋습니다. 이렇게 하면 부하 분산기와 동일한 VPC 네트워크 및 리전의 모든 리전에 있는 클라이언트가 클러스터에서 실행 중인 워크로드에 도달할 수 있습니다. 또한 인그레스 컨트롤러 상태 확인을 구현하여 pod의 상태를 모니터링하고 실패한 pod를 다시 시작하는 것이 좋습니다.
  • Google Cloud 부하 분산 부하 분산은Google Cloud 영역에 트래픽을 분산합니다. 애플리케이션의 요구사항을 충족하는 부하 분산기를 선택합니다.

포드 중단 예산 정의

중단 예산을 정의하여 유지보수 이벤트나 업데이트와 같은 중단 중에 애플리케이션에서 사용할 수 있어야 하는 최소한의 포드 수를 지정하는 것이 좋습니다. 다음 예는 서비스 중단 예산을 정의하는 방법을 보여줍니다.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
  namespace: my-app-namespace
spec:
  # Define how many pods need to remain available during a disruption.
  # At least one of "minAvailable" or "maxUnavailable" must be specified.
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

자세한 내용은 애플리케이션에 중단 예산 지정을 참조하세요.

HA 및 데이터 복제를 지원하는 스토리지 사용

컨테이너 외부에 영구 데이터 저장소가 필요한 스테이트풀 워크로드의 경우 다음 권장사항을 따르는 것이 좋습니다.

디스크 권장사항

디스크 스토리지가 필요한 경우 다음 중 하나를 사용하세요.

스토리지 옵션을 선택한 후 클러스터에 해당 드라이버를 설치합니다.

마지막으로 디스크의 StorageClass를 설정합니다.

다음 예는 StorageClass를 설정하는 방법을 보여줍니다.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: regionalpd-balanced
provisioner: PROVISIONER
parameters:
  type: DISK-TYPE
  replication-type: REPLICATION-TYPE
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete
allowVolumeExpansion: true
allowedTopologies:
  - matchLabelExpressions:
      - key: topology.kubernetes.io/zone
        values:
          - europe-west1-b
          - europe-west1-a

데이터베이스 권장사항

데이터베이스가 필요한 경우 다음 중 하나를 사용하세요.

  • 완전 관리형 데이터베이스: Cloud SQL 또는 PostgreSQL용 AlloyDB를 사용하여 대신 데이터베이스 HA를 관리하는 것이 좋습니다. Cloud SQL을 사용하는 경우 Cloud SQL 프록시 연산자를 사용하여 애플리케이션과 데이터베이스 간의 연결 관리를 간소화할 수 있습니다.
  • 자체 관리형 데이터베이스: HA를 지원하는 데이터베이스를 사용하고 HA를 사용 설정하기 위해 해당 연산자를 배포하는 것이 좋습니다. 자세한 내용은 Kubernetes용 Redis Enterprise, MariaDB Operator, CloudNative PostgreSQL Operator와 같은 데이터베이스 운영자와 관련된 문서를 참고하세요.

데이터베이스 운영자를 설치한 후 여러 인스턴스가 있는 클러스터를 구성합니다. 다음 예는 다음 속성이 있는 클러스터의 구성을 보여줍니다.

  • 고가용성을 위해 인스턴스 3개로 my-postgres-cluster라는 PostgreSQL 클러스터가 생성됩니다.
  • 클러스터는 영역 전반에서 내구성 있는 복제 스토리지에 regionalpd-balanced 스토리지 클래스를 사용합니다.
  • mydatabase라는 데이터베이스가 사용자 myuser로 초기화되며, 사용자 인증 정보는 my-database-secret라는 Kubernetes 보안 비밀에 저장됩니다.
  • 보안 강화를 위해 슈퍼 사용자 액세스가 사용 중지됩니다.
  • 클러스터에 모니터링이 사용 설정되어 있습니다.
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: my-postgres-cluster
  namespace: postgres-namespace
spec:
  instances: 3
  storage:
    size: 10Gi
    storageClass: regionalpd-balanced
  bootstrap:
    initdb:
      database: mydatabase
      owner: myuser
      secret:
        name: my-database-secret
  enableSuperuserAccess: false
  monitoring:
    enabled: true
---
apiVersion: 1
kind: Secret
metadata:
  name: my-database-secret
  namespace: postgres-namespace
type: Opaque
data:
  username: bXl1c2Vy # Base64-encoded value of "myuser"
  password: c2VjdXJlcGFzc3dvcmQ= # Base64-encoded value of "securepassword"

애플리케이션 상태 외부화

세션 상태 또는 캐싱을 공유 메모리 저장소(예: Redis) 또는 HA 모드로 실행되도록 구성된 영구 데이터 스토어 (예: Postgres, MySQL)로 이동하는 것이 좋습니다.

권장사항 요약

요약하자면 OpenShift에서 고가용성을 달성하려면 다음 권장사항을 구현하세요.

  • 여러 영역에 배포 분산
  • 리소스 오버커밋을 방지하기 위해 선제적으로 부하 관리
  • 포드 중단 예산 정의
  • HA 데이터 복제 기능 사용
  • 애플리케이션 상태 외부화

다음 단계