6.9. 노드 재부팅 이해
플랫폼에서 실행 중인 애플리케이션을 중단하지 않고 노드를 재부팅하려면 먼저 Pod를 비워야 합니다. 라우팅 계층에서 가용성이 높은 Pod의 경우 다른 작업을 수행할 필요가 없습니다. 스토리지(일반적으로 데이터베이스)가 필요한 기타 Pod의 경우 특정 Pod가 일시적으로 오프라인으로 전환된 상태에서도 계속 작동하는지 확인하는 것이 중요합니다. 상태 저장 Pod에 대한 복원력을 구현하는 방법은 애플리케이션마다 다르지만 어떠한 경우에도 노드 유사성 방지를 사용하여 Pod가 사용 가능한 노드에 적절히 분배되도록 스케줄러를 구성하는 것이 중요합니다.
또 다른 문제는 라우터 또는 레지스트리와 같은 중요한 인프라를 실행하는 노드를 처리하는 방법입니다. 동일한 노드 비우기 프로세스가 적용되지만 특정 엣지 케이스를 이해하는 것이 중요합니다.
6.9.1. 중요한 인프라를 실행하는 노드 재부팅 정보
라우터 Pod, 레지스트리 Pod, 모니터링 Pod와 같은 중요한 OpenShift Container Platform 인프라 구성 요소를 호스팅하는 노드를 재부팅할 때는 이러한 구성 요소를 실행하는 데 사용 가능한 노드가 세 개 이상 있는지 확인하십시오.
다음 시나리오에서는 두 개의 노드만 사용할 수 있을 때 OpenShift Container Platform에서 실행되는 애플리케이션에서 서비스 중단이 발생하는 방식을 보여줍니다.
- 노드 A가 예약 불가로 표시되고 모든 Pod가 비어 있습니다.
- 이제 해당 노드에서 실행 중인 레지스트리 Pod가 노드 B에 다시 배포됩니다. 그러면 노드 B는 두 레지스트리 Pod를 모두 실행합니다.
- 이제 노드 B가 예약 불가로 표시되고 비어 있습니다.
- 노드 B에 Pod 끝점 두 개를 노출하는 서비스에서는 해당 끝점이 노드 A에 다시 배포될 때까지 잠시 모든 끝점이 손실됩니다.
인프라 구성 요소로 노드 세 개를 사용하는 경우 이 프로세스에서는 서비스가 중단되지 않습니다. 그러나 Pod 예약으로 인해 비워진 후 다시 제공된 마지막 노드에는 레지스트리 Pod가 없습니다. 기타 노드 중 하나에는 레지스트리 Pod가 두 개 있습니다. 마지막 노드에 세 번째 레지스트리 Pod를 예약하려면 Pod 유사성 방지를 사용하여 스케줄러에서 동일한 노드에 두 레지스트리 Pod를 배치하지 않도록 합니다.
추가 정보
- Pod 유사성 방지에 대한 자세한 내용은 유사성 및 유사성 방지 규칙을 사용하여 다른 Pod와 관련된 Pod 배치 를 참조하십시오.
6.9.2. Pod 유사성 방지를 사용하여 노드 재부팅
Pod 유사성 방지는 노드 유사성 방지와 약간 다릅니다. Pod를 배포할 다른 적절한 위치가 없는 경우 노드 유사성 방지를 위반할 수 있습니다. Pod 유사성 방지를 필수 또는 기본으로 설정할 수 있습니다.
이 규칙에서는 두 개의 인프라 노드만 사용할 수 있는 경우 한 개를 재부팅하면 컨테이너 이미지 레지스트리 Pod가 다른 노드에서 실행되지 않습니다. oc get pods는 적절한 노드가 제공될 때까지 Pod를 준비되지 않은 것으로 보고합니다. 노드를 사용할 수 있고 모든 Pod가 준비 상태가 되면 다음 노드를 재시작할 수 있습니다.
프로세스
Pod 유사성 방지를 사용하여 노드를 재부팅하려면 다음을 수행합니다.
노드 사양을 편집하여 Pod 유사성 방지를 구성합니다.
apiVersion: v1 kind: Pod metadata: name: with-pod-antiaffinity spec: affinity: podAntiAffinity: 1 preferredDuringSchedulingIgnoredDuringExecution: 2 - weight: 100 3 podAffinityTerm: labelSelector: matchExpressions: - key: registry 4 operator: In 5 values: - default topologyKey: kubernetes.io/hostname #...이 예제에서는 컨테이너 이미지 레지스트리 Pod에
registry=default라벨이 있다고 가정합니다. Pod 유사성 방지에서는 모든 Kubernetes 일치 표현식을 사용할 수 있습니다.-
예약 정책 파일에서
MatchInterPodAffinity스케줄러 서술자를 활성화합니다. - 노드를 정상적으로 다시 시작합니다.
6.9.3. 라우터를 실행하는 노드를 재부팅하는 방법 이해
대부분의 경우 OpenShift Container Platform 라우터를 실행하는 Pod에서는 호스트 포트를 노출합니다.
PodFitsPorts 스케줄러 서술자를 사용하면 동일한 포트를 사용하는 라우터 Pod가 동일한 노드에서 실행되지 않고 Pod 유사성 방지를 구현할 수 있습니다. 라우터에서 고가용성을 위해 IP 장애 조치를 사용하는 경우 추가로 필요한 조치는 없습니다.
고가용성을 위해 AWS Elastic Load Balancing과 같은 외부 서비스를 사용하는 라우터 Pod의 경우 해당 서비스에서 라우터 Pod 재시작에 대응해야 합니다.
드물지만 라우터 Pod에 호스트 포트가 구성되어 있지 않은 경우가 있습니다. 이러한 경우 인프라 노드에 권장되는 재시작 프로세스를 따라야 합니다.
6.9.4. 노드를 정상적으로 재부팅
노드를 재부팅하기 전에 노드의 데이터 손실을 방지하기 위해 etcd 데이터를 백업하는 것이 좋습니다.
사용자가 클러스터를 관리하기 위해 kubeconfig 파일에 인증서를 두지 않고 oc login 명령을 수행해야 하는 단일 노드 OpenShift 클러스터의 경우, 노드를 차단하고 드레이닝한 후 oc adm 명령을 사용할 수 없습니다. 이는 cordon으로 인해 openshift-oauth-apiserver Pod가 실행되지 않기 때문입니다. 다음 절차에 표시된 대로 SSH를 사용하여 노드에 액세스할 수 있습니다.
단일 노드 OpenShift 클러스터에서는 차단 및 드레이닝 시 Pod를 다시 예약할 수 없습니다. 그러나 이렇게 하면 Pod, 특히 워크로드 Pod를 통해 관련 리소스를 적절하게 중지하고 릴리스할 수 있습니다.
절차
노드를 정상적으로 다시 시작하려면 다음을 수행합니다.
노드를 예약 불가능으로 표시합니다.
$ oc adm cordon <node1>
실행 중인 모든 Pod를 제거하도록 노드를 드레이닝합니다.
$ oc adm drain <node1> --ignore-daemonsets --delete-emptydir-data --force
사용자 정의 PDB(Pod 중단 예산)와 연결된 Pod를 제거할 수 없는 오류가 표시될 수 있습니다.
오류 예
error when evicting pods/"rails-postgresql-example-1-72v2w" -n "rails" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
이 경우 drain 명령을 다시 실행하여 PDB 검사를 바이패스하는
disable-eviction플래그를 추가합니다.$ oc adm drain <node1> --ignore-daemonsets --delete-emptydir-data --force --disable-eviction
디버그 모드에서 노드에 액세스합니다.
$ oc debug node/<node1>
루트 디렉토리를
/host로 변경합니다.$ chroot /host
노드를 재시작합니다.
$ systemctl reboot
잠시 후 노드는
NotReady상태가 됩니다.참고일부 단일 노드 OpenShift 클러스터에서는
openshift-oauth-apiserver포드가 실행되지 않기 때문에 차단 및 노드 드레이닝 후oc명령을 사용할 수 없습니다. SSH를 사용하여 노드에 연결하고 재부팅을 수행할 수 있습니다.$ ssh core@<master-node>.<cluster_name>.<base_domain>
$ sudo systemctl reboot
재부팅이 완료되면 다음 명령을 실행하여 노드를 예약 가능으로 표시합니다.
$ oc adm uncordon <node1>
참고일부 단일 노드 OpenShift 클러스터에서는
openshift-oauth-apiserver포드가 실행되지 않기 때문에 차단 및 노드 드레이닝 후oc명령을 사용할 수 없습니다. SSH를 사용하여 노드에 연결하고 uncordon할 수 있습니다.$ ssh core@<target_node>
$ sudo oc adm uncordon <node> --kubeconfig /etc/kubernetes/static-pod-resources/kube-apiserver-certs/secrets/node-kubeconfigs/localhost.kubeconfig
노드가 준비되었는지 확인합니다.
$ oc get node <node1>
출력 예
NAME STATUS ROLES AGE VERSION <node1> Ready worker 6d22h v1.18.3+b0068a8
추가 정보
etcd 데이터 백업에 대한 자세한 내용은 etcd 데이터 백업을 참조하십시오.
