검색

9장. 네트워크 엣지의 원격 작업자 노드

download PDF

9.1. 네트워크 엣지에서 원격 작업자 노드 사용

네트워크 엣지에 있는 노드를 사용하여 OpenShift Container Platform 클러스터를 구성할 수 있습니다. 이 주제에서는 해당 노드를 원격 작업자 노드라고 합니다. 원격 작업자 노드가 있는 일반 클러스터에서는 온프레미스 마스터 및 작업자 노드를 클러스터에 연결된 다른 위치에 있는 작업자 노드와 결합합니다. 이 주제는 원격 작업자 노드 사용 모범 사례에 대한 지침을 제공하기 위한 것으로, 특정 구성 세부 정보는 포함하지 않습니다.

통신, 소매, 제조, 정부와 같이 다양한 업계에서 원격 작업자 노드에서 배포 패턴을 사용하는 다양한 사용 사례가 있습니다. 예를 들어 원격 작업자 노드를 Kubernetes 영역에 결합하여 프로젝트와 워크로드를 분리하고 격리할 수 있습니다.

그러나 원격 작업자 노드가 있으면 대기 시간이 길어지고 네트워크 연결이 간헐적으로 끊어지며 기타 문제가 발생할 수 있습니다. 원격 작업자 노드가 있는 클러스터의 문제점은 다음과 같습니다.

원격 작업자 노드가 있는 클러스터를 계획할 때 다음과 같은 제한 사항에 유의하십시오.

  • OpenShift Container Platform은 온프레미스 클러스터에서 사용하는 것과 다른 클라우드 공급자를 사용하는 원격 작업자 노드를 지원하지 않습니다.
  • 특정 Kubernetes 영역에서 다른 Kubernetes 영역으로 워크로드를 이동하는 경우 다른 영역에서 사용할 수 없는 특정 유형의 메모리 등 시스템 및 환경 문제로 인해 문제가 발생할 수 있습니다.
  • 프록시 및 방화벽은 이 문서의 범위를 벗어나는 추가 제한 사항을 제공할 수 있습니다. 방화벽 구성과 같은 제한 사항을 해결하는 방법은 관련 OpenShift Container Platform 설명서를 참조하십시오.
  • 컨트롤 플레인과 네트워크 엣지 노드 간에 L2/L3 수준 네트워크 연결을 구성하고 유지 관리해야 합니다.

9.1.1. 원격 작업자 노드 추가

클러스터에 원격 작업자 노드를 추가하려면 몇 가지 추가 고려 사항이 필요합니다.

  • 컨트롤 플레인과 모든 원격 작업자 노드 간에 트래픽을 라우팅하려면 경로 또는 기본 게이트웨이가 제 위치에 있는지 확인해야 합니다.
  • 컨트롤 플레인에 Ingress VIP를 배치해야 합니다.
  • 사용자 프로비저닝 인프라를 사용하여 원격 작업자 노드를 추가하는 것은 다른 작업자 노드를 추가하는 것과 동일합니다.
  • 설치 시 설치 시 설치 관리자 프로비저닝 클러스터에 원격 작업자 노드를 추가하려면 설치 전에 install-config.yaml 파일의 각 작업자 노드의 서브넷을 지정합니다. DHCP 서버에는 추가 설정이 필요하지 않습니다. 원격 작업자 노드는 로컬 프로비저닝 네트워크에 액세스할 수 없으므로 가상 미디어를 사용해야 합니다.
  • provisioning 네트워크와 함께 배포된 설치 관리자 프로비저닝 클러스터에 원격 작업자 노드를 추가하려면 install-config.yaml 파일에서 virtualMediaViaExternalNetwork 플래그가 true 로 설정되어 가상 미디어를 사용하여 노드를 추가해야 합니다. 원격 작업자 노드는 로컬 프로비저닝 네트워크에 액세스할 수 없습니다. PXE가 아닌 가상 미디어와 함께 배포해야 합니다. 또한 DHCP 서버의 각 원격 작업자 노드 및 컨트롤 플레인 노드의 각 서브넷을 지정합니다.

9.1.2. 원격 작업자 노드를 사용하여 네트워크 분리

모든 노드는 10초마다 OpenShift Container Platform 클러스터의 Kubernetes Controller Manager Operator(kube 컨트롤러)로 하트비트를 보냅니다. 클러스터에서 노드의 하트비트를 수신하지 않는 경우 OpenShift Container Platform은 여러 기본 메커니즘을 사용하여 응답합니다.

OpenShift Container Platform은 네트워크 파티션 및 기타 중단에 대해 탄력적으로 설계되었습니다. 소프트웨어 업그레이드로 인한 중단, 네트워크 분할, 라우팅 문제와 같이 비교적 일반적인 일부 중단을 완화할 수 있습니다. 완화 전략에는 원격 작업자 노드의 Pod가 올바른 양의 CPU 및 메모리 리소스를 요청하는지 확인, 적절한 복제 정책 구성, 영역 전체에서 중복성 사용, 워크로드에 Pod 중단 예산 사용이 포함됩니다.

구성된 기간이 지난 후 kube 컨트롤러와 노드의 연결이 끊어지면 컨트롤 플레인의 노드 컨트롤러에서 노드 상태를 Unhealthy로 업데이트하고 노드 Ready 조건을 Unknown으로 표시합니다. 스케줄러는 이에 대한 응답으로 해당 노드에 대한 Pod 예약을 중지합니다. 온프레미스 노드 컨트롤러는 NoExecute 효과가 있는 node.kubernetes.io/unreachable 테인트를 노드에 추가하고 노드의 Pod를 기본적으로 5분 후에 제거하도록 예약합니다.

Deployment 오브젝트 또는 StatefulSet 오브젝트와 같은 워크로드 컨트롤러에서 비정상 노드의 Pod로 트래픽을 전송하고 기타 노드에서 클러스터에 연결할 수 있는 경우 OpenShift Container Platform은 노드의 Pod 외부로 트래픽을 라우팅합니다. 클러스터에 연결할 수 없는 노드는 새 트래픽 라우팅을 통해 업데이트되지 않습니다. 결과적으로 해당 노드의 워크로드가 비정상 노드에 도달하기 위해 계속 시도할 수 있습니다.

다음과 같은 방법으로 연결 손실의 영향을 완화할 수 있습니다.

  • 데몬 세트를 사용하여 테인트를 허용하는 pod 생성
  • 노드가 중단되는 경우 자동으로 재시작하는 정적 Pod 사용
  • Kubernetes 영역을 사용하여 Pod 제거 제어
  • Pod 제거를 지연하거나 방지하도록 Pod 허용 오차 구성
  • 노드를 비정상으로 표시하는 시기를 제어하도록 kubelet 구성.

원격 작업자 노드가 있는 클러스터에서 이러한 오브젝트를 사용하는 방법에 대한 자세한 내용은 원격 작업자 노드 전략 정보를 참조하십시오.

9.1.3. 원격 작업자 노드의 정전

원격 작업자 노드가 정전되거나 강제 다시 시작되면 OpenShift Container Platform은 여러 기본 메커니즘을 사용하여 응답합니다.

구성된 기간이 지난 후 Kubernetes Controller Manager Operator(kube 컨트롤러)와 노드의 연결이 끊어지면 컨트롤 플레인에서 노드 상태를 Unhealthy로 업데이트하고 노드 Ready 조건을 Unknown으로 표시합니다. 스케줄러는 이에 대한 응답으로 해당 노드에 대한 Pod 예약을 중지합니다. 온프레미스 노드 컨트롤러는 NoExecute 효과가 있는 node.kubernetes.io/unreachable 테인트를 노드에 추가하고 노드의 Pod를 기본적으로 5분 후에 제거하도록 예약합니다.

노드가 전원을 복구하고 컨트롤 플레인에 다시 연결되면 노드에서 Pod를 재시작해야 합니다.

참고

재시작 즉시 Pod를 재시작하려면 정적 Pod를 사용하십시오.

노드를 재시작하면 kubelet도 재시작되고 노드에 예약된 Pod를 재시작하려고 합니다. 컨트롤 플레인에 대한 연결이 기본값인 5분보다 오래 걸리는 경우 컨트롤 플레인에서 노드 상태를 업데이트하고 node.kubernetes.io/unreachable 테인트를 제거할 수 없습니다. 노드에서 kubelet은 실행 중인 Pod를 모두 종료합니다. 이러한 조건이 해제되면 스케줄러는 해당 노드에 Pod를 예약할 수 있습니다.

다음을 통해 정전의 영향을 완화할 수 있습니다.

  • 데몬 세트를 사용하여 테인트를 허용하는 pod 생성
  • 노드와 함께 자동으로 재시작하는 정적 Pod 사용
  • Pod 제거를 지연하거나 방지하도록 Pod 허용 오차 구성
  • 노드 컨트롤러에서 노드를 비정상으로 표시하는 시기를 제어하도록 kubelet 구성.

원격 작업자 노드가 있는 클러스터에서 이러한 오브젝트를 사용하는 방법에 대한 자세한 내용은 원격 작업자 노드 전략 정보를 참조하십시오.

9.1.4. 대기 시간 급증 또는 원격 작업자로의 처리량 감소

클러스터 관리자가 플랫폼 확인을 위해 대기 시간 테스트를 수행한 경우 대기 시간이 긴 경우 안정성을 보장하기 위해 클러스터의 작동을 조정해야 할 수 있습니다. 클러스터 관리자는 파일에 기록된 하나의 매개 변수만 변경해야 합니다. 이 매개변수는 감독자 프로세스가 상태를 읽고 클러스터의 상태를 해석하는 방법에 영향을 미치는 매개변수 4개를 제어합니다. 하나의 매개변수만 변경하면 지원 가능한 방식으로 클러스터 튜닝이 제공됩니다.

Kubelet 프로세스는 클러스터 상태를 모니터링하기 위한 시작점을 제공합니다. Kubelet 은 OpenShift Container Platform 클러스터의 모든 노드에 대한 상태 값을 설정합니다. Kubernetes Controller Manager(kube 컨트롤러)는 기본적으로 10초마다 상태 값을 읽습니다. kube 컨트롤러에서 노드 상태 값을 읽을 수 없는 경우 구성된 기간이 지난 후 해당 노드와의 연결이 끊어집니다. 기본 동작은 다음과 같습니다.

  1. 컨트롤 플레인의 노드 컨트롤러는 노드 상태를 Unhealthy 로 업데이트하고 노드 Ready 조건 'Unknown'을 표시합니다.
  2. 스케줄러는 이에 대한 응답으로 해당 노드에 대한 Pod 예약을 중지합니다.
  3. Node Lifecycle Controller는 NoExecute 효과가 있는 node.kubernetes.io/unreachable 테인트를 노드에 추가하고 기본적으로 5분 후에 제거하도록 노드에 Pod를 예약합니다.

이 동작은 특히 네트워크 엣지에 노드가 있는 경우 네트워크가 대기 시간 문제가 발생하는 경우 문제가 발생할 수 있습니다. 경우에 따라 네트워크 대기 시간으로 인해 Kubernetes 컨트롤러 관리자에서 정상적인 노드에서 업데이트를 수신하지 못할 수 있습니다. Kubelet 은 노드가 정상이지만 노드에서 Pod를 제거합니다.

이 문제를 방지하려면 작업자 대기 시간 프로필을 사용하여 Kubelet 및 Kubernetes 컨트롤러 관리자가 작업을 수행하기 전에 상태 업데이트를 기다리는 빈도를 조정할 수 있습니다. 이러한 조정은 컨트롤 플레인과 작업자 노드 간의 네트워크 대기 시간이 최적이 아닌 경우 클러스터가 올바르게 실행되도록 하는 데 도움이 됩니다.

이러한 작업자 대기 시간 프로필에는 대기 시간을 높이기 위해 클러스터의 응답을 제어하기 위해 신중하게 조정된 값으로 미리 정의된 세 가지 매개변수 세트가 포함되어 있습니다. 실험적으로 최상의 값을 수동으로 찾을 필요가 없습니다.

클러스터를 설치할 때 또는 언제든지 클러스터 네트워크에서 대기 시간을 늘릴 때 작업자 대기 시간 프로필을 구성할 수 있습니다.

9.1.5. 원격 작업자 노드 전략

원격 작업자 노드를 사용하는 경우 애플리케이션을 실행하는 데 사용할 오브젝트를 고려하십시오.

네트워크 문제 또는 정전 시 원하는 동작을 기반으로 데몬 세트 또는 정적 Pod를 사용하는 것이 좋습니다. 또한 컨트롤 플레인에서 원격 작업자 노드에 연결할 수 없는 경우 Kubernetes 영역 및 허용 오차를 사용하여 Pod 제거를 제어하거나 방지할 수 있습니다.

데몬 세트
데몬 세트는 다음과 같은 이유로 원격 작업자 노드에서 Pod를 관리하는 가장 좋은 방법입니다.
  • 데몬 세트에는 일반적으로 일정 조정 동작이 필요하지 않습니다. 노드와 클러스터의 연결이 끊어지면 노드의 Pod가 계속 실행될 수 있습니다. OpenShift Container Platform에서는 데몬 세트 Pod의 상태를 변경하지 않고 Pod를 마지막으로 보고된 상태로 유지합니다. 예를 들어 데몬 세트 Pod가 Running 상태에 있는 경우 노드에서 통신을 중지하면 Pod가 계속 실행되고 OpenShift Container Platform에서 Pod가 실행 중인 것으로 간주합니다.
  • 기본적으로 데몬 세트 Pod는 tolerationSeconds 값이 없는 node.kubernetes.io/unreachablenode.kubernetes.io/not-ready 테인트에 대한 NoExecute 허용 오차로 생성됩니다. 이러한 기본값을 사용하면 컨트롤 플레인에서 노드에 연결할 수 없는 경우 데몬 세트 Pod가 제거되지 않습니다. 예를 들면 다음과 같습니다.

    데몬 세트 Pod에 기본적으로 허용 오차 추가

      tolerations:
        - key: node.kubernetes.io/not-ready
          operator: Exists
          effect: NoExecute
        - key: node.kubernetes.io/unreachable
          operator: Exists
          effect: NoExecute
        - key: node.kubernetes.io/disk-pressure
          operator: Exists
          effect: NoSchedule
        - key: node.kubernetes.io/memory-pressure
          operator: Exists
          effect: NoSchedule
        - key: node.kubernetes.io/pid-pressure
          operator: Exists
          effect: NoSchedule
        - key: node.kubernetes.io/unschedulable
          operator: Exists
          effect: NoSchedule

  • 데몬 세트에서는 라벨을 사용하여 일치하는 작업자 노드에서 워크로드를 실행할 수 있습니다.
  • OpenShift Container Platform 서비스 끝점을 사용하여 데몬 세트 Pod의 부하를 분산할 수 있습니다.
참고

OpenShift Container Platform에서 노드에 연결할 수 없는 경우 데몬 세트에서는 노드 재부팅 후 Pod를 예약하지 않습니다.

고정 Pod
노드가 재부팅될 때(예: 정전 후) Pod를 재시작하려면 정적 Pod를 사용하는 것이 좋습니다. 노드의 Kubelet은 노드가 재시작되면 정적 Pod를 자동으로 재시작합니다.
참고

정적 Pod에서는 보안 및 구성 맵을 사용할 수 없습니다.

Kubernetes 영역
Kubernetes 영역은 속도를 늦추거나 경우에 따라 Pod 제거를 완전히 중지할 수 있습니다.

컨트롤 플레인에서 노드에 연결할 수 없는 경우 노드 컨트롤러는 기본적으로 node.kubernetes.io/unreachable 테인트를 적용하고 초당 0.1 노드의 속도로 Pod를 제거합니다. 그러나 Kubernetes 영역을 사용하는 클러스터에서는 Pod 제거 동작이 변경됩니다.

영역이 완전히 중단되고 해당 영역에 있는 모든 노드의 Ready 조건이 False 또는 Unknown인 경우 컨트롤 플레인에서 해당 영역의 노드에 node.kubernetes.io/unreachable 테인트를 적용하지 않습니다.

부분적으로 중단된 영역의 경우 노드의 55% 이상에 False 또는 Unknown 조건이 있으면 Pod 제거 비율이 초당 0.01 노드로 줄어듭니다. 노드가 50개 미만인 소규모 클러스터의 노드는 테인트되지 않습니다. 이러한 동작을 적용하려면 클러스터에 영역이 네 개 이상 있어야 합니다.

노드 사양에 topology.kubernetes.io/region 라벨을 적용하여 특정 영역에 노드를 할당합니다.

Kubernetes 영역의 노드 라벨 샘플

kind: Node
apiVersion: v1
metadata:
  labels:
    topology.kubernetes.io/region=east

KubeletConfig 오브젝트

Kubelet에서 각 노드의 상태를 확인하는 시간을 조정할 수 있습니다.

온프레미스 노드 컨트롤러에서 노드를 Unhealthy 또는 Unreachable 조건으로 표시하는 타이밍에 영향을 미치는 간격을 설정하려면 node-status-update-frequencynode-status-report-frequency 매개변수가 포함된 KubeletConfig 오브젝트를 생성합니다.

각 노드의 kubelet은 node-status-update-frequency 설정에서 정의하는 노드 상태를 확인하고 node-status-report-frequency 설정에 따라 클러스터에 상태를 보고합니다. 기본적으로 kubelet은 Pod 상태를 10초 간격으로 확인하고 상태를 1분 간격으로 보고합니다. 그러나 노드 상태가 변경되면 Kubelet에서 이러한 변경을 클러스터에 즉시 보고합니다. OpenShift Container Platform에서는 노드 리스 기능 게이트가 활성화된 경우(OpenShift Container Platform 클러스터의 기본 상태)에만 node-status-report-frequency 설정을 사용합니다. 노드 리스 기능 게이트가 비활성화된 경우 노드는 node-status-update-frequency 설정에 따라 해당 상태를 보고합니다.

kubelet 구성의 예

apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: disable-cpu-units
spec:
  machineConfigPoolSelector:
    matchLabels:
      machineconfiguration.openshift.io/role: worker 1
  kubeletConfig:
    node-status-update-frequency: 2
      - "10s"
    node-status-report-frequency: 3
      - "1m"

1
MachineConfig 오브젝트의 라벨을 사용하여 이 KubeletConfig 오브젝트가 적용되는 노드 유형을 지정합니다.
2
Kubelet에서 이 MachineConfig 오브젝트와 연결된 노드의 상태를 점검하는 빈도를 지정합니다. 기본값은 10s입니다. 이 기본값을 변경하면 node-status-report-frequency 값이 동일한 값으로 변경됩니다.
3
Kubelet에서 이 MachineConfig 오브젝트와 연결된 노드의 상태를 보고하는 빈도를 지정합니다. 기본값은 1m입니다.

node-status-update-frequency 매개변수는 node-monitor-grace-periodpod-eviction-timeout 매개변수와 함께 작동합니다.

  • node-monitor-grace-period 매개변수는 컨트롤러 관리자가 노드 하트비트를 수신하지 못하는 경우 MachineConfig 오브젝트와 연결된 노드가 Unhealthy로 표시된 후 OpenShift Container Platform에서 대기하는 시간을 지정합니다. 노드의 워크로드는 이 시간 이후 계속 실행됩니다. node-monitor-grace-period가 만료된 후 원격 작업자 노드가 클러스터에 다시 참여하면 Pod가 계속 실행됩니다. 해당 노드에 새 Pod를 예약할 수 있습니다. node-monitor-grace-period 간격은 40s입니다. node-status-update-frequency 값은 node-monitor-grace-period 값보다 작아야 합니다.
  • pod-eviction-timeout 매개변수는 Pod를 제거하도록 표시하기 위해 MachineConfig 오브젝트와 연결된 노드를 Unreachable로 표시한 후 OpenShift Container Platform에서 대기하는 시간을 지정합니다. 제거된 Pod는 다른 노드에 다시 예약됩니다. 노드 컨트롤러가 온프레미스에서 Pod를 제거했기 때문에 pod-eviction-timeout이 만료된 후 원격 작업자 노드가 클러스터에 다시 참여하면 원격 작업자 노드에서 실행 중인 Pod가 종료됩니다. 그런 다음 Pod를 해당 노드에 다시 예약할 수 있습니다. pod-eviction-timeout 기간은 5m0s입니다.
참고

node-monitor-grace-periodpod-eviction-timeout 매개변수 수정은 지원되지 않습니다.

허용 오차
온프레미스 노드 컨트롤러에서 NoExecute 효과가 있는 node.kubernetes.io/unreachable 테인트를 연결할 수 없는 노드에 추가하는 경우 Pod 허용 오차를 사용하여 영향을 완화할 수 있습니다.

NoExecute 효과가 있는 테인트는 다음과 같은 방식으로 노드에서 이미 실행되고 있는 Pod에 영향을 미칩니다.

  • 해당 테인트를 허용하지 않는 Pod가 제거를 위해 큐에 추가됩니다.
  • 허용 오차 사양에 tolerationSeconds 값을 지정하지 않은 상태로 테인트를 허용하는 Pod는 영구적으로 바인딩된 상태로 유지됩니다.
  • tolerationSeconds 값이 지정된 테인트를 허용하는 Pod는 지정된 시간 동안 바인딩된 상태로 유지됩니다. 시간이 지나면 Pod가 제거를 위해 큐에 추가됩니다.

node.kubernetes.io/unreachablenode.kubernetes.io/not-ready 테인트에 대해 NoExecute 효과를 사용하여 Pod 허용 오차를 구성하면 Pod 제거를 지연하거나 방지할 수 있습니다.

Pod 사양의 허용 오차 예

...
tolerations:
- key: "node.kubernetes.io/unreachable"
  operator: "Exists"
  effect: "NoExecute" 1
- key: "node.kubernetes.io/not-ready"
  operator: "Exists"
  effect: "NoExecute" 2
  tolerationSeconds: 600
...

1
tolerationSeconds 없이 NoExecute 효과를 사용하면 컨트롤 플레인에서 노드에 연결할 수 없는 경우 Pod를 영구적으로 유지할 수 있습니다.
2
tolerationSeconds: 600을 사용하는 NoExecute 효과를 사용하면 컨트롤 플레인에서 노드를 Unhealthy 로 표시하는 경우 Pod가 10 분 동안 유지됩니다.

OpenShift Container Platform에서는 pod-eviction-timeout 값이 경과하면 tolerationSeconds 값을 사용합니다.

기타 유형의 OpenShift Container Platform 오브젝트
복제본 세트, 배포, 복제 컨트롤러를 사용할 수 있습니다. 노드가 5분 동안 연결이 끊기면 스케줄러에서 해당 Pod를 다른 노드에 다시 예약할 수 있습니다. 관리자가 특정 수의 Pod가 실행되고 해당 Pod에 액세스하도록 보장할 수 있는 일부 워크로드의 경우(예: REST API) 다른 노드에 다시 예약하면 유용할 수 있습니다.
참고

원격 작업자 노드로 작업할 때 원격 작업자 노드가 특정 기능을 위해 예약되도록 의도된 경우 다른 노드에 Pod를 다시 예약하지 못할 수 있습니다.

상태 저장 세트는 중단 발생 시 재시작되지 않습니다. 컨트롤 플레인에서 Pod가 종료되었음을 인식할 때까지 Pod는 terminating 상태로 유지됩니다.

네트워크 분리의 경우 OpenShift Container Platform에서는 동일한 유형의 영구 스토리지에 액세스할 수 없는 노드에 예약하지 않도록 영구 볼륨이 필요한 Pod를 다른 영역에 마이그레이션할 수 없습니다.

추가 리소스

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.