2.10. 노드 재부팅
플랫폼에서 실행 중인 애플리케이션을 중단하지 않고 노드를 재부팅하려면 먼저 포드를 비우는 것이 중요합니다. 라우팅 계층에서 가용성이 높은 Pod의 경우 다른 작업을 수행할 필요가 없습니다. 스토리지(일반적으로 데이터베이스)가 필요한 기타 Pod의 경우 특정 Pod가 일시적으로 오프라인으로 전환된 상태에서도 계속 작동하는지 확인하는 것이 중요합니다. 상태 저장 Pod에 대한 복원력을 구현하는 것은 애플리케이션마다 다르지만, 모든 경우에 노드 유사성 방지를 사용하도록 스케줄러를 구성하여 Pod가 사용 가능한 노드에 적절하게 분배되도록 하는 것이 중요합니다.
또 다른 문제는 라우터 또는 레지스트리와 같은 중요한 인프라를 실행하는 노드를 처리하는 방법입니다. 동일한 노드 비우기 프로세스가 적용되지만 특정 엣지 케이스를 이해하는 것이 중요합니다.
2.10.1. 인프라 노드
인프라 노드는 OpenShift Container Platform 환경의 일부를 실행하도록 레이블이 지정된 노드입니다. 현재 노드 재부팅을 관리하는 가장 쉬운 방법은 인프라를 실행하는 데 사용 가능한 노드가 3개 이상 있는지 확인하는 것입니다. 아래 시나리오는 두 개의 노드만 사용할 수 있을 때 OpenShift Container Platform에서 실행되는 애플리케이션의 서비스 중단으로 이어질 수 있는 일반적인 실수를 보여줍니다.
- 노드 A가 예약 불가로 표시되고 모든 Pod가 비어 있습니다.
- 이제 해당 노드에서 실행 중인 레지스트리 포드가 B 노드에 재배포됩니다. 즉, 노드 B는 이제 두 레지스트리 포드를 모두 실행합니다.
- 이제 노드 B가 예약 불가로 표시되고 비어 있습니다.
- 노드 B에 두 포드 끝점을 노출하는 서비스는 잠시 동안 노드 A에 재배포될 때까지 모든 엔드포인트가 손실됩니다.
세 개의 인프라 노드를 사용하는 동일한 프로세스로 인해 서비스가 중단되지 않습니다. 그러나 Pod 예약으로 인해 비워진 후 되돌린 마지막 노드가 0개의 레지스트리를 실행 중인 상태로 남아 있습니다. 다른 두 노드는 각각 두 개의 레지스트리와 하나의 레지스트리를 실행합니다. 최상의 솔루션은 Pod 유사성 방지를 사용하는 것입니다. 이는 현재 테스트할 수 있지만 프로덕션 워크로드에서 아직 지원되지 않는 알파 기능입니다.
