3장. 정책 및 서비스 정의

Pod는 설계상 짧은 기간 동안 존재해야 합니다. 애플리케이션 Pod의 여러 인스턴스가 실행되는 경우 개별 Pod 또는 컨테이너의 문제를 방지할 수 있도록 서비스를 적절하게 스케일링합니다. OpenShift 노드 스케줄러는 복원력을 추가로 개선하기 위해 이러한 워크로드가 다른 작업자 노드에 분산되어 있는지도 확인할 수 있습니다.

가능한 Pod 오류를 처리할 때 스토리지가 애플리케이션에 연결된 방식을 이해하는 것도 중요합니다. 단일 포드에 연결된 단일 영구 볼륨은 포드 확장의 모든 이점을 활용할 수 없지만 복제된 데이터베이스, 데이터베이스 서비스 또는 공유 스토리지는 가능합니다.

계획된 유지 관리 기간(예: 업그레이드) 동안 애플리케이션의 중단을 방지하려면 Pod 중단 예산을 정의하는 것이 중요합니다. 이는 Kubernetes API의 일부이며 다른 오브젝트 유형과 같은 oc 명령으로 관리할 수 있습니다. 유지 관리를 위해 노드를 드레이닝하는 것과 같이 작업 중에 Pod에 대한 보안 제약 조건을 지정할 수 있습니다.

작업자 노드는 애플리케이션 pod가 포함된 가상 머신입니다. 기본적으로 ROSA 클러스터에는 단일 가용성 영역 클러스터에 대해 최소 두 개의 작업자 노드가 있습니다. 작업자 노드 오류가 발생하는 경우 기존 노드와 관련된 문제가 해결되거나 노드가 교체될 때까지 충분한 용량이 있는 한 작업자 노드가 작동되도록 Pod가 재배치됩니다. 더 많은 작업자 노드는 단일 노드 중단을 방지할 수 있으며 노드 장애가 발생할 경우 Pod를 다시 예약하기 위한 적절한 클러스터 용량을 보장합니다.

단일 AZ ROSA 클러스터에는 프라이빗 서브넷에서 동일한 가용 영역(AZ)에 3개 이상의 컨트롤 플레인과 두 개의 인프라 노드가 있습니다.

다중 AZ ROSA 클러스터에는 선택한 클러스터 유형에 따라 단일 영역 또는 여러 영역에서 고가용성을 위해 사전 구성된 컨트롤 플레인 노드와 세 개의 인프라 노드가 있습니다. 컨트롤 플레인 및 인프라 노드는 작업자 노드와 동일한 복원력을 가지며 Red Hat에서 완전히 관리할 수 있는 추가 이점이 있습니다.

완전한 컨트롤 플레인 중단이 발생하면 OpenShift API가 작동하지 않으며 기존 작업자 노드 Pod는 영향을 받지 않습니다. 그러나 Pod 또는 노드 중단이 동시에 발생하는 경우 새 Pod 또는 노드를 추가하거나 예약하기 전에 컨트롤 플레인을 복구해야 합니다.

인프라 노드에서 실행되는 모든 서비스는 Red Hat에서 고가용성으로 구성하고 인프라 노드에 분산합니다. 완전한 인프라 중단이 발생하는 경우 이러한 노드가 복구될 때까지 이러한 서비스를 사용할 수 없습니다.

AWS의 영역 오류는 단일 가용성 영역과 관련된 작업자 노드, 블록 또는 공유 스토리지, 로드 밸런서와 같은 모든 가상 구성 요소에 영향을 미칩니다. 영역 장애로부터 보호하기 위해 ROSA는 여러 가용성 영역 클러스터라는 세 가지 가용성 영역에 분산된 클러스터에 대한 옵션을 제공합니다. 기존 상태 비저장 워크로드는 충분한 용량이 있는 경우 중단 시 영향을 받지 않는 영역에 재배포됩니다.

상태 저장 애플리케이션을 배포한 경우 스토리지는 중요한 구성 요소이며 고가용성을 고려할 때 고려해야 합니다. 단일 블록 스토리지 PV는 Pod 수준에서도 중단을 방지할 수 없습니다. 스토리지의 가용성을 유지하는 가장 좋은 방법은 복제된 스토리지 솔루션, 중단의 영향을 받지 않는 공유 스토리지 또는 클러스터와 무관한 데이터베이스 서비스를 사용하는 것입니다.