2장. 정책 및 서비스 정의

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

Pod 실패 가능성이 있는 경우 애플리케이션에 스토리지가 연결된 방법을 이해하는 것도 중요합니다. 단일 Pod에 연결된 단일 영구 볼륨은 Pod 스케일링의 전체 이점을 활용할 수 없지만 복제된 데이터베이스, 데이터베이스 서비스 또는 공유 스토리지에서는 사용할 수 있습니다.

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

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

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

다중 AZ ROSA 클러스터에는 세 개의 컨트롤 플레인 노드와 고가용성을 위해 사전 구성된 인프라 노드가 있으며 각 AZ에 하나씩 있습니다. 컨트롤 플레인 및 인프라 노드는 작업자 노드와 동일한 복원력을 가지며 Red Hat에서 완전히 관리하는 이점이 추가되었습니다.

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

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

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

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