본 한국어 번역은 사용자 편의를 위해 제공되는 기계 번역입니다. 영어 버전과 한국어 버전이 서로 어긋나는 경우에는 언제나 영어 버전이 우선합니다.

Trident 사용하여 상태 저장 애플리케이션의 장애 조치 자동화

10/31/2025 기여자

Trident의 강제 분리 기능을 사용하면 Kubernetes 클러스터에서 비정상적인 노드의 볼륨을 자동으로 분리하여 데이터 손상을 방지하고 애플리케이션 가용성을 보장할 수 있습니다. 이 기능은 노드가 응답하지 않거나 유지 관리를 위해 오프라인으로 전환되는 시나리오에서 특히 유용합니다.

강제 분리에 대한 세부 정보

강제 분리가 가능합니다. ontap-san , ontap-san-economy , ontap-nas , 그리고 ontap-nas-economy 오직. 강제 분리를 활성화하기 전에 Kubernetes 클러스터에서 비정상적 노드 종료(NGNS)를 활성화해야 합니다. NGNS는 Kubernetes 1.28 이상에서 기본적으로 활성화되어 있습니다. 자세한 내용은 다음을 참조하세요. "Kubernetes: 노드 정상 종료 아님" .

또는 ontap-nas-economy 드라이버를 사용할 경우 ontap-nas, Trident이 관리형 엑스포트 정책을 사용하여 적용된 태그로 인해 Kubernetes 노드에서 액세스를 제한할 수 있도록 백엔드 구성에서 매개 변수를 로 true 설정해야 autoExportPolicy 합니다.

Trident는 Kubernetes ngns를 사용하기 때문에 허용할 수 없는 모든 워크로드의 일정이 재조정될 때까지 비정상 노드에서 테인트를 제거하지 마십시오 out-of-service. 무모하게 타트를 적용하거나 제거하면 백엔드 데이터 보호가 위태롭게 될 수 있습니다.

Kubernetes 클러스터 관리자가 노드에 태그를 enableForceDetach 적용하고 node.kubernetes.io/out-of-service=nodeshutdown:NoExecute 로 설정하면 true Trident이 노드 상태와 다음을 확인합니다.

해당 노드에 마운트된 볼륨에 대한 백엔드 I/O 액세스를 중지합니다.

Trident 노드 개체를 로 dirty 표시합니다(새 발행물에 안전하지 않음).

Trident 컨트롤러는 Trident 노드 포드에 의해 노드가 다시 검증될 때까지(로 표시된 후) 새로운 게시 볼륨 요청을 거부합니다 dirty. Trident가 노드를 확인할 수 있을 때까지(새 발행물에 안전함) 마운트된 PVC로 예약된 모든 작업 부하(클러스터 노드가 정상 및 준비 상태임 이후에도)는 수락되지 clean 않습니다.

노드 상태가 복원되고 정점이 제거되면 Trident는 다음을 수행합니다.

노드에서 오래된 게시된 경로를 식별하고 제거합니다.
노드가 상태(서비스 중단 시간이 제거되고 노드가 상태)이고 모든 오래되고 Ready 게시된 경로가 정리된 경우 cleanable, Trident는 노드를 로 재전송하고 게시된 새로운 볼륨을 노드에 허용합니다. clean

자동 장애 조치에 대한 세부 정보

통합을 통해 강제 분리 프로세스를 자동화할 수 있습니다."노드 상태 점검(NHC) 운영자" . 노드 장애가 발생하면 NHC는 Trident 노드 복구(TNR)를 트리거하고 Trident의 네임스페이스에 장애가 발생한 노드를 정의하는 TridentNodeRemediation CR을 생성하여 자동으로 강제 분리합니다. TNR은 노드 장애가 발생한 경우에만 생성되며, 노드가 다시 온라인 상태가 되거나 노드가 삭제되면 NHC에서 제거됩니다.

실패한 노드 포드 제거 프로세스

자동 장애 조치는 실패한 노드에서 제거할 작업 부하를 선택합니다. TNR이 생성되면 TNR 컨트롤러는 노드를 더티로 표시하여 새로운 볼륨 게시를 방지하고 강제 분리가 지원되는 포드와 해당 볼륨 첨부 파일을 제거하기 시작합니다.

강제 분리가 지원하는 모든 볼륨/PVC는 자동 장애 조치가 지원됩니다.

NAS 및 자동 내보내기 정책을 사용하는 NAS 경제 볼륨(SMB는 아직 지원되지 않음).
SAN 및 SAN 경제 볼륨.

참조하다강제 분리에 대한 세부 정보 .

기본 동작:

강제 분리가 지원하는 볼륨을 사용하는 Pod는 실패한 노드에서 제거됩니다. 쿠버네티스는 이를 정상적인 노드로 다시 예약합니다.
Trident 볼륨이 아닌 볼륨을 포함하여 강제 분리가 지원되지 않는 볼륨을 사용하는 Pod는 실패한 노드에서 제거되지 않습니다.
상태 비저장 포드(PVC 아님)는 포드 주석이 없는 한 실패한 노드에서 제거되지 않습니다. trident.netapp.io/podRemediationPolicy: delete 설정되었습니다.

포드 제거 동작 재정의:

Pod 제거 동작은 Pod 주석을 사용하여 사용자 정의할 수 있습니다. trident.netapp.io/podRemediationPolicy[retain, delete] . 이러한 주석은 장애 조치가 발생할 때 검사되어 사용됩니다. 페일오버 후 주석이 사라지는 것을 방지하려면 Kubernetes 배포/복제 세트 포드 사양에 주석을 적용합니다.

retain- 자동 장애 조치 중에는 실패한 노드에서 Pod가 제거되지 않습니다.
delete- 자동 장애 조치 중에 실패한 노드에서 Pod가 제거됩니다.

이러한 주석은 모든 포드에 적용될 수 있습니다.

강제 분리를 지원하는 볼륨의 경우 실패한 노드에서만 I/O 작업이 차단됩니다.
강제 분리를 지원하지 않는 볼륨의 경우 데이터 손상 및 다중 연결 문제가 발생할 위험이 있습니다.

트라이던트노드복구 CR

TridentNodeRemediation(TNR) CR은 실패한 노드를 정의합니다. TNR의 이름은 실패한 노드의 이름입니다.

TNR 예시:

apiVersion: trident.netapp.io/v1
kind: TridentNodeRemediation
metadata:
  name: <K8s-node-name>
spec: {}

TNR 상태: 다음 명령을 사용하여 TNR 상태를 확인하세요.
kubectl get tnr <name> -n <trident-namespace>

TNR은 다음 상태 중 하나에 속할 수 있습니다.

수정:
- 해당 노드에 마운트된 강제 분리가 지원하는 볼륨에 대한 백엔드 I/O 액세스를 중단합니다.
- Trident 노드 객체가 더티(새로운 게시물에 안전하지 않음)로 표시되었습니다.
- 노드에서 포드 및 볼륨 첨부 파일 제거
노드 복구 보류:
- 컨트롤러는 노드가 다시 온라인 상태가 될 때까지 기다리고 있습니다.
- 노드가 온라인 상태가 되면 publish-enforcement를 통해 노드가 정리되고 새로운 볼륨 출판에 적합한 상태가 됩니다.
노드가 K8s에서 삭제되면 TNR 컨트롤러는 TNR을 제거하고 조정을 중단합니다.
성공:
- 모든 수정 및 노드 복구 단계가 성공적으로 완료되었습니다. 노드가 정리되어 새로운 권의 출판에 적합합니다.
실패한:
- 복구할 수 없는 오류입니다. 오류 이유는 CR의 status.message 필드에 설정됩니다.

자동 장애 조치 활성화

필수 조건:

자동 장애 조치를 활성화하기 전에 강제 분리가 활성화되어 있는지 확인하세요. 자세한 내용은 다음을 참조하세요.강제 분리에 대한 세부 정보 .
Kubernetes 클러스터에 노드 상태 점검(NHC)을 설치합니다.
- "operator-sdk 설치".
- 클러스터에 Operator Lifecycle Manager(OLM)가 아직 설치되지 않았다면 설치하세요. operator-sdk olm install .
- 노드 상태 점검 운영자 설치: kubectl create -f https://operatorhub.io/install/node-healthcheck-operator.yaml .

또한 지정된 대로 노드 실패를 감지하기 위해 대체 방법을 사용할 수도 있습니다.[Integrating Custom Node Health Check Solutions] 아래 섹션을 참조하세요.

보다"노드 상태 점검 운영자" 자세한 내용은.

단계

클러스터의 워커 노드를 모니터링하기 위해 Trident 네임스페이스에 NodeHealthCheck(NHC) CR을 만듭니다. 예:

apiVersion: remediation.medik8s.io/v1alpha1
kind: NodeHealthCheck
metadata:
  name: <CR name>
spec:
  selector:
    matchExpressions:
      - key: node-role.kubernetes.io/control-plane
        operator: DoesNotExist
      - key: node-role.kubernetes.io/master
        operator: DoesNotExist
  remediationTemplate:
    apiVersion: trident.netapp.io/v1
    kind: TridentNodeRemediationTemplate
    namespace: <Trident installation namespace>
    name: trident-node-remediation-template
  minHealthy: 0 # Trigger force-detach upon one or more node failures
  unhealthyConditions:
    - type: Ready
      status: "False"
      duration: 0s
    - type: Ready
      status: Unknown
      duration: 0s

노드 상태 점검 CR을 적용합니다. trident 네임스페이스.

kubectl apply -f <nhc-cr-file>.yaml -n <trident-namespace>

위 CR은 노드 조건 '준비: 거짓' 및 '알 수 없음'에 대해 K8s 워커 노드를 감시하도록 구성되어 있습니다. 자동 장애 조치는 노드가 준비: 거짓 또는 준비: 알 수 없음 상태로 전환되면 실행됩니다.

그만큼 unhealthyConditions CR에서는 0초의 유예 기간을 사용합니다. 이렇게 하면 K8s가 노드 조건 Ready: false를 설정하는 즉시 자동 장애 조치가 트리거됩니다. 이 조건은 K8s가 노드에서 하트비트를 잃은 후에 설정됩니다. K8s는 마지막 하트비트 이후 Ready: false로 설정되기 전에 기본적으로 40초간 기다립니다. 이 유예 기간은 K8s 배포 옵션에서 사용자 정의할 수 있습니다.

추가 구성 옵션은 다음을 참조하세요."Node-Healthcheck-Operator 문서" .

추가 설정 정보

Trident 강제 분리가 활성화된 상태로 설치하면 NHC와의 통합을 용이하게 하기 위해 Trident 네임스페이스에 두 개의 추가 리소스인 TridentNodeRemediationTemplate(TNRT)과 ClusterRole이 자동으로 생성됩니다.

TridentNodeRemediationTemplate(TNRT):

TNRT는 NHC 컨트롤러를 위한 템플릿 역할을 하며, NHC 컨트롤러는 필요에 따라 TNRT를 사용하여 TNR 리소스를 생성합니다.

apiVersion: trident.netapp.io/v1
kind: TridentNodeRemediationTemplate
metadata:
  name: trident-node-remediation-template
  namespace: trident
spec:
  template:
    spec: {}

클러스터 역할:

강제 분리가 활성화된 경우 설치 중에 클러스터 역할도 추가됩니다. 이를 통해 NHC는 Trident 네임스페이스의 TNR에 대한 권한을 얻습니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    rbac.ext-remediation/aggregate-to-ext-remediation: "true"
  name: tridentnoderemediation-access
rules:
- apiGroups:
  - trident.netapp.io
  resources:
  - tridentnoderemediationtemplates
  - tridentnoderemediations
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
  - delete

K8s 클러스터 업그레이드 및 유지 관리

장애 조치를 방지하려면 노드가 다운되거나 재부팅될 것으로 예상되는 K8s 유지 관리 또는 업그레이드 중에 자동 장애 조치를 일시 중지합니다. 위에 설명된 NHC CR을 일시 중지하려면 CR을 패치하면 됩니다.

kubectl patch NodeHealthCheck <cr-name> --patch '{"spec":{"pauseRequests":["<description-for-reason-of-pause>"]}}' --type=merge

이렇게 하면 자동 장애 조치가 일시 중지됩니다. 자동 장애 조치를 다시 활성화하려면 유지 관리가 완료된 후 사양에서 pauseRequests를 제거하세요.

제한 사항

강제 분리가 지원되는 볼륨의 경우 실패한 노드에서만 I/O 작업이 방지됩니다. 강제 분리를 지원하는 볼륨/PVC를 사용하는 포드만 자동으로 제거됩니다.
자동 장애 조치 및 강제 분리 기능은 트라이던트 컨트롤러 포드 내부에서 실행됩니다. 트라이던트 컨트롤러를 호스팅하는 노드에 장애가 발생하면 K8s가 포드를 정상적인 노드로 옮길 때까지 자동 장애 조치가 지연됩니다.

사용자 정의 노드 상태 점검 솔루션 통합

Node Healthcheck Operator를 대체 노드 장애 감지 도구로 교체하여 자동 장애 조치를 트리거할 수 있습니다. 자동 장애 조치 메커니즘과의 호환성을 보장하려면 사용자 지정 솔루션이 다음을 수행해야 합니다.

노드 장애가 감지되면 장애가 발생한 노드의 이름을 TNR CR 이름으로 사용하여 TNR을 생성합니다.
노드가 복구되고 TNR이 성공 상태가 되면 TNR을 삭제합니다.