다음을 통해 공유

Azure Red Hat OpenShift에 대한 운영 기준 지침

  • 아티클

Azure Red Hat OpenShift는 확장성이 뛰어난 완전 관리형 OpenShift 클러스터를 주문형으로 제공합니다. 관리 및 모니터링을 염두에 두고 솔루션을 올바르게 설계하면 운영 우수성과 고객 성공을 위해 노력할 수 있습니다.

디자인 고려 사항

다음 사항을 고려합니다.

  • Azure Red Hat OpenShift 책임 매트릭스를 검토하여 클러스터에 대한 책임이 Microsoft, Red Hat 및 고객 간에 공유되는 방식을 이해합니다.
  • Azure 가상 머신 제한 및지원되는 지역에 유의하세요. 리소스를 배포하는 데 사용할 수 있는 용량이 있는지 확인합니다.
  • 클러스터 내에서 워크로드를 논리적으로 격리하는 방법 및 별도의 클러스터에서 워크로드를 물리적으로 격리하는 방법을 알고 있어야 합니다.
  • Kubernetes가 워크로드의 상태를 이해하는 데 도움이 되는 방법을 알고 있어야 합니다.
  • 다양한 가상 머신 크기와 하나 또는 다른 가상 머신을 사용하는 효과에 유의하세요.
  • Azure Red Hat OpenShift를 모니터링하고 기록하여 리소스의 상태에 대한 인사이트를 얻고 잠재적인 문제를 예측하는 방법을 알고 있어야 합니다. 클러스터와 위에서 실행되는 애플리케이션 모두 많은 이벤트를 생성할 수 있습니다. 경고를 사용하여 기록 목적으로 로그 항목과 즉각적인 조치가 필요한 항목을 구분할 수 있습니다.
  • 중요한 시스템 업데이트 및 업그레이드에 유의하세요. 중요한 패치 업데이트는 Azure Red Hat OpenShift SRE(사이트 안정성 엔지니어)에 의해 클러스터에 자동으로 적용됩니다. 패치 업데이트를 미리 설치하려는 고객은 무료로 설치할 수 있습니다.
  • 클러스터 및 개별 워크로드의 리소스 제한 사항에 유의하세요.
  • 가로 Pod 자동 크기 조정기와 클러스터 자동 크기 조정의 차이점에 유의하세요.
  • 지원 수 명 주기 를 검토하고 버전 지원 정책을 이해합니다. Azure Red Hat OpenShift는 Red Hat OpenShift Container Platform의 현재 및 이전에 일반적으로 사용 가능한 부 릴리스 만 지원합니다. 지원 요청을 사용하려면 클러스터가 지원되는 버전 내에 있어야 합니다.
  • 클러스터 구성 요구 사항을 검토하여 클러스터 지원 가능성을 유지합니다.
  • 네트워크 정책을 사용하여 클러스터 내에서 트래픽을 보호하려면 네임스페이스 간 네트워킹을 검토합니다.

디자인 권장 사항

  • Azure Red Hat OpenShift에는 풍부한 운영자 에코시스템이 있으며 효율성과 정확도로 운영 활동을 수행하고 자동화하는 데 사용해야 합니다.
  • Pod에 상태 프로브를 추가하여 애플리케이션 상태를 모니터링합니다. Pod에 livenessProbe 및 readinessProbe가 포함되어 있는지 확인합니다. 시작 프로브를 사용하여 애플리케이션이 시작된 지점을 확인합니다.
  • 여러 컨테이너 인스턴스를 포함할 수 있을 만큼 큰 가상 머신 크기를 사용하면 밀도가 증가하지만 클러스터가 실패한 노드의 워크로드를 처리할 수 없을 정도로 크지 않은 이점을 얻을 수 있습니다.
  • 일반적으로 보안 정책, 리소스 제한 또는 구성 요구 사항을 적용하는 데 사용되는 허용 플러그 인을 사용하여 클러스터 함수를 규제합니다.
  • Pod 요청 및 제한을 사용하여 클러스터 내에서 컴퓨팅 리소스를 관리합니다. Pod 요청 및 제한은 컴퓨팅 리소스를 Pod에 할당하는 Kubernetes 스케줄러에 알릴 수 있습니다. 제한 범위를 사용하여 프로젝트의 리소스 소비 를 제한합니다.
  • CPU 및 메모리 요청 값을 최적화하고 수직 Pod 자동 크기 조정기를 사용하여 클러스터 리소스의 효율성을 최대화합니다.
  • OpenShift 웹 콘솔에는 노드 수준의 모든 메트릭이 포함됩니다. 기본 빌드된 Prometheus 또는 Container Insights 통합을 사용하여 모니터링 프로세스를 설정합니다.
    • Prometheus는 Azure Red Hat OpenShift 4.x 클러스터에 대해 미리 설치되고 구성됩니다.
    • 클러스터를 Azure Arc 지원 Kubernetes에 온보딩하여 Container Insights를 사용하도록 설정할 수 있습니다.
    • OpenShift 로깅 은 로그 집계, 스토리지 및 시각화 구성 요소를 배포합니다.
  • OpenShift Container Platform에서 제공하는 Pipelines/GitOps와 같은 DevOps 사례 및 CI/CD 솔루션을 통해 애플리케이션 배달 프로세스를 자동화합니다.
  • 클러스터에 리소스가 부족하여 더 많은 배포를 지원할 때 머신 크기를 조정하도록 ClusterAutoScaler 및 MachineAutoScaler를 정의합니다.
  • 컴퓨터 상태 검사를 배포하여 컴퓨터 풀에서 손상된 컴퓨터를 자동으로 복구합니다.
  • 수평 Pod 자동 크기 조정기를 사용하여 수요를 충족하도록 Pod 크기를 조정합니다.
  • 경고 시스템을 사용하여 직접 작업이 필요한 경우 알림 제공: Container Insights 메트릭 경고 또는 기본 제공 경고 UI.

비즈니스 연속성 및 재해 복구(BCDR)

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

BCDR에 대한 디자인 고려 사항

다음 사항을 고려합니다.

  • Azure Red Hat OpenShift 클러스터는 여러 컴퓨터 집합을 사용하여 애플리케이션에 대한 최소 가용성 수준을 제공해야 합니다.
  • Pod 요청 및 제한을 설정합니다. 이러한 제한을 설정하면 Kubernetes에서 다음을 수행할 수 있습니다.
    • CPU 및 메모리 리소스를 Pod에 효율적으로 할당합니다.
    • 노드에서 컨테이너 밀도가 높아집니다.
    • 하드웨어를 더 잘 사용하기 때문에 비용 절감으로 안정성을 높입니다.
  • 고가용성을 위해 사용 가능한 모든 영역에 노드를 분산합니다.
    • 가용성 영역을 지원하는 지역을 선택합니다.
    • 전체 영역 혜택을 위해 모든 서비스 종속성도 영역을 지원해야 합니다. 종속 서비스가 영역을 지원하지 않는 경우 영역 오류로 인해 해당 서비스가 실패할 수 있습니다. 영역을 통해 워크로드를 분산할 때 사용되는 디스크 유형을 검토합니다.
    • 가용성 영역 달성할 수 있는 것 이상의 고가용성을 위해 서로 다른 쌍을 이루는 지역에서 여러 클러스터를 실행합니다. Azure 리소스가 지역 중복성을 지원하는 경우 중복 서비스에 보조 지역이 있는 위치를 제공합니다.
  • 애플리케이션 및 데이터에 대한 일관된 백업을 만듭니다.
    • 비 상태 저장 서비스를 효율적으로 복제할 수 있습니다.
    • 클러스터에 상태를 저장해야 하는 경우 쌍을 이루는 지역에서 데이터를 자주 백업합니다.
  • 클러스터를 업그레이드하고 유지 관리합니다.
  • 장애 조치(failover)가 발생하는 경우 네트워크 연결:
    • 지역 간에 트래픽을 분산해야 하는 경우 Azure Front Door를 사용하는 것이 좋습니다.
  • 계획 및 계획되지 않은 장애 조치(failover)의 경우:
    • 각 Azure 서비스를 설정할 때 재해 복구를 지원하는 기능을 선택합니다. 예를 들어 Azure Container Registry 선택한 경우 지역 복제에 사용하도록 설정합니다. 지역이 다운된 경우에도 복제된 지역에서 이미지를 끌어올 수 있습니다.
  • DevOps 엔지니어링 기능을 유지 관리하여 서비스 수준 목표에 도달합니다.

BCDR에 대한 디자인 권장 사항

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

  • Azure Red Hat OpenShift 클러스터는 3개의 컨트롤 플레인 노드와 3개 이상의 작업자 노드로 프로비전됩니다. 노드가 영역에 분산되도록 가용성 영역 지원하는 지역에 클러스터가 생성되었는지 확인합니다.
  • 고가용성을 위해 이러한 노드를 다른 가용성 영역 배포합니다. 각 가용성 영역에 대해 서로 다른 컴퓨터 집합이 필요하므로 3개 이상의 컴퓨터 집합을 만듭니다.
  • 컨트롤 플레인 노드에서 추가 워크로드를 실행하지 마세요. 컨트롤 플레인 노드에서 예약할 수 있지만 전체 클러스터에 영향을 줄 수 있는 추가 리소스 사용량 및 안정성 문제가 발생합니다.
  • 인프라 구성 요소를 저장할 인프라 머신 집합을 만듭니다. 이러한 컴퓨터에 특정 Kubernetes 레이블을 적용한 다음 해당 컴퓨터에서만 실행되도록 인프라 구성 요소를 업데이트합니다.
  • 가능하면 컨테이너 내부에서 서비스 상태를 제거합니다. 대신, 다중 지역 복제를 지원하는 Azure PaaS(platform as a service)를 사용합니다.
  • 배포는 Pod 리소스 요구 사항을 지정해야 합니다. 그러면 스케줄러가 Pod를 적절하게 예약할 수 있습니다. Pod가 예약되지 않은 경우 안정성이 크게 감소합니다.
  • 하드웨어 오류와 같은 중단을 처리하도록 배포에서 여러 복제본을 설정합니다. 업데이트 및 업그레이드와 같은 계획된 이벤트의 경우 중단 예산은 예상된 애플리케이션 부하를 처리하는 데 필요한 Pod 복제본 수가 있는지 확인할 수 있습니다.
  • Pod 토폴로지 제약 조건을 사용하여 클러스터 전체의 노드에서 Pod를 자동으로 예약합니다.
  • 애플리케이션은 데이터에 스토리지를 사용할 수 있으며 필요한 경우 지역 간 가용성을 보장해야 합니다.
    • 붙지 Azure Files 스토리지 클래스와 함께 RWX 스토리지 사용.
    • 스토리지 프로비저닝에 CSI 드라이버 사용.
  • 애플리케이션 백업을 만들고 복원 계획:
  • Pod 리소스 제한을 예측합니다. 기준을 테스트하고 설정합니다. 요청 및 제한에 대해 동일한 값으로 시작합니다. 그런 다음, 클러스터에서 불안정을 일으킬 수 있는 임계값을 설정할 때까지 해당 값을 점진적으로 조정합니다. 배포 매니페스트에서 Pod 제한을 지정할 수 있습니다. 수직 Pod 자동 크기 조정기는 CPU 및 메모리 요청 값을 최적화하고 클러스터 리소스의 효율성을 최대화할 수 있습니다.
    • 기본 제공 기능은 서비스 아키텍처의 오류 및 중단을 처리할 수 있습니다. 이러한 구성은 디자인 및 배포 자동화를 간소화하는 데 도움이 됩니다. organization SLA, RTO 및 RPO에 대한 표준을 정의하는 경우 Kubernetes 및 Azure에 기본 제공되는 서비스를 사용하여 비즈니스 목표를 달성할 수 있습니다.
  • 새 애플리케이션 릴리스를 배포하려면 파란색/녹색 또는 카나리아 전략을 고려합니다.
  • Pod 우선 순위/Pod 중단 예산을 설정하여 클러스터가 유지 관리 작업을 위해 중단하도록 허용되는 Pod 복제본 수를 제한하여 가용성을 보장합니다.
  • 서비스 네임스페이스에 리소스 할당량을 적용합니다. 네임스페이스의 리소스 할당량은 Pod 요청 및 제한이 배포에 올바르게 설정되도록 합니다.
    • 클러스터 수준에서 리소스 할당량을 설정하면 적절한 요청 및 제한이 없는 파트너 서비스를 배포할 때 문제가 발생할 수 있습니다.
  • 컨테이너 이미지를 Azure Container Registry 저장하고 레지스트리를 각 지역에 지역 복제합니다.
  • Azure ExpressRoute 연결을 위해 여러 지역 및 피어링 위치를 사용합니다. 중복 하이브리드 네트워크 아키텍처는 중단이 Azure 지역 또는 피어링 공급자 위치에 영향을 주는 경우 중단 없는 프레미스 간 연결을 보장하는 데 도움이 될 수 있습니다.
  • 글로벌 가상 네트워크 피어링을 사용하여 지역 상호 연결. 클러스터가 서로 통신해야 하는 경우 가상 네트워크 피어링을 통해 두 가상 네트워크를 서로 연결할 수 있습니다. 이 기술은 서로 가상 네트워크를 상호 연결하여 여러 지리적 지역에서도 Microsoft의 백본 네트워크에서 높은 대역폭을 제공합니다.
  • 분할 TCP 기반 애니캐스트 프로토콜인 Azure Front Door를 사용하여 최종 사용자를 가장 가까운 Front Door POP(현재 상태 지점)에 즉시 연결합니다. Azure Front Door의 추가 기능은 다음과 같습니다.
    • TLS 종료
    • 사용자 지정 도메인
    • 웹 애플리케이션 방화벽
    • URL 재작성
    • 세션 선호도

다음 단계

Azure 랜딩 존 의 플랫폼 자동화 및 DevOps에 대한 디자인 고려 사항 및 권장 사항에 대해 알아봅니다.