2.6. Pod 예약 결정에 Pod 우선순위 포함
클러스터에서 Pod 우선순위 및 선점을 활성화할 수 있습니다. Pod 우선순위는 다른 Pod와 관련된 Pod의 중요도를 나타내며 해당 우선 순위에 따라 Pod를 대기열에 넣습니다. Pod 선점을 사용하면 적절한 노드 Pod 우선순위에 사용 가능한 공간이 없는 경우 우선 순위가 낮은 Pod를 제거하거나 우선순위가 낮은 Pod를 예약할 수 있습니다. 노드의 예약 순서 및 리소스 부족 제거 순서에도 영향을 미칩니다.
우선순위 및 선점 기능을 사용하려면 Pod 사양의 우선순위 클래스를 참조하여 스케줄링에 해당 가중치를 적용합니다.
2.6.1. Pod 우선순위 이해
Pod 우선순위 및 선점 기능을 사용하면 스케줄러에서 보류 중인 Pod를 우선순위에 따라 정렬하고, 보류 중인 Pod는 예약 큐에서 우선순위가 더 낮은 다른 대기 중인 Pod보다 앞에 배치됩니다. 그 결과 예약 요구 사항이 충족되는 경우 우선순위가 높은 Pod가 우선순위가 낮은 Pod보다 더 빨리 예약될 수 있습니다. Pod를 예약할 수 없는 경우에는 스케줄러에서 우선순위가 낮은 다른 Pod를 계속 예약합니다.
2.6.1.1. Pod 우선순위 클래스
네임스페이스가 지정되지 않은 오브젝트로서 이름에서 우선순위 정수 값으로의 매핑을 정의하는 우선순위 클래스를 Pod에 할당할 수 있습니다. 값이 클수록 우선순위가 높습니다.
우선순위 클래스 오브젝트에는 1000000000(10억)보다 작거나 같은 32비트 정수 값을 사용할 수 있습니다. 선점 또는 제거해서는 안 되는 중요한 Pod의 경우 10억보다 크거나 같은 수를 예약합니다. 기본적으로 AWS의 Red Hat OpenShift Service에는 중요한 시스템 Pod에서 일정을 보장하기 위해 두 가지 우선순위 클래스가 예약되어 있습니다.
$ oc get priorityclasses
출력 예
NAME VALUE GLOBAL-DEFAULT AGE system-node-critical 2000001000 false 72m system-cluster-critical 2000000000 false 72m openshift-user-critical 1000000000 false 3d13h cluster-logging 1000000 false 29s
system-node-critical - 이 우선순위 클래스의 값은 2000001000이며 노드에서 제거해서는 안 되는 모든 Pod에 사용합니다. 이 우선순위 클래스가 있는 Pod의 예는
ovnkube-node등입니다. 대다수의 중요한 구성 요소에는 기본적으로system-node-critical우선순위 클래스가 포함됩니다. 예를 들면 다음과 같습니다.- master-api
- master-controller
- master-etcd
- OVN-kubernetes
- sync
system-cluster-critical - 이 우선순위 클래스의 값은 2000000000(10억)이며 클러스터에 중요한 Pod에 사용합니다. 이 우선순위 클래스가 있는 Pod는 특정 상황에서 노드에서 제거할 수 있습니다. 예를 들어
system-node-critical우선순위 클래스를 사용하여 구성한 Pod가 우선할 수 있습니다. 그러나 이 우선순위 클래스는 예약을 보장합니다. 이 우선순위 클래스를 사용할 수 있는 Pod의 예로는 fluentd, Descheduler와 같은 추가 기능 구성 요소 등이 있습니다. 대다수의 중요한 구성 요소에는 기본적으로system-cluster-critical우선순위 클래스가 포함됩니다. 예를 들면 다음과 같습니다.- fluentd
- metrics-server
- Descheduler
-
OpenShift-user-critical -
priorityClassName필드를 리소스 사용을 바인딩할 수 없고 예측 가능한 리소스 사용량 동작이 없는 중요한 Pod와 함께 사용할 수 있습니다.openshift-monitoring및openshift-user-workload-monitoring네임스페이스 아래의 Prometheus Pod는openshift-user-criticalpriorityClassName을 사용합니다. 모니터링 워크로드는 첫 번째priorityClass로시스템 중요를 사용하지만 모니터링에서 과도한 메모리를 사용하고 노드를 제거할 수 없는 경우 문제가 발생합니다. 결과적으로 모니터링은 중요한 노드 작동을 유지하기 위해 스케줄러의 유연성을 제공하기 위해 우선 순위가 떨어지고 많은 워크로드를 이동합니다. - cluster-logging - 이 우선순위는 Fluentd에서 Fluentd Pod가 다른 앱보다 먼저 노드에 예약되도록 하는 데 사용합니다.
2.6.1.2. Pod 우선순위 이름
우선순위 클래스가 한 개 이상 있으면 Pod 사양에서 우선순위 클래스 이름을 지정하는 Pod를 생성할 수 있습니다. 우선순위 승인 컨트롤러는 우선순위 클래스 이름 필드를 사용하여 정수 값으로 된 우선순위를 채웁니다. 이름이 지정된 우선순위 클래스가 없는 경우 Pod가 거부됩니다.
2.6.2. Pod 선점 이해
개발자가 Pod를 생성하면 Pod가 큐로 들어갑니다. 개발자가 Pod에 Pod 우선순위 또는 선점을 구성한 경우 스케줄러는 큐에서 Pod를 선택하고 해당 Pod를 노드에 예약하려고 합니다. 스케줄러가 노드에서 Pod의 지정된 요구 사항을 모두 충족하는 적절한 공간을 찾을 수 없는 경우 보류 중인 Pod에 대한 선점 논리가 트리거됩니다.
스케줄러가 노드에서 Pod를 하나 이상 선점하면 우선순위가 높은 Pod 사양의 nominatedNodeName 필드가 nodename 필드와 함께 노드의 이름으로 설정됩니다. 스케줄러는 nominatedNodeName 필드를 사용하여 Pod용으로 예약된 리소스를 계속 추적하고 클러스터의 선점에 대한 정보도 사용자에게 제공합니다.
스케줄러에서 우선순위가 낮은 Pod를 선점한 후에는 Pod의 정상 종료 기간을 따릅니다. 스케줄러에서 우선순위가 낮은 Pod가 종료되기를 기다리는 동안 다른 노드를 사용할 수 있게 되는 경우 스케줄러는 해당 노드에서 우선순위가 더 높은 Pod를 예약할 수 있습니다. 따라서 Pod 사양의 nominatedNodeName 필드 및 nodeName 필드가 다를 수 있습니다.
또한 스케줄러가 노드의 Pod를 선점하고 종료되기를 기다리고 있는 상태에서 보류 중인 Pod보다 우선순위가 높은 Pod를 예약해야 하는 경우, 스케줄러는 우선순위가 더 높은 Pod를 대신 예약할 수 있습니다. 이러한 경우 스케줄러는 보류 중인 Pod의 nominatedNodeName을 지워 해당 Pod를 다른 노드에 사용할 수 있도록 합니다.
선점을 수행해도 우선순위가 낮은 Pod가 노드에서 모두 제거되는 것은 아닙니다. 스케줄러는 우선순위가 낮은 Pod의 일부를 제거하여 보류 중인 Pod를 예약할 수 있습니다.
스케줄러는 노드에서 보류 중인 Pod를 예약할 수 있는 경우에만 해당 노드에서 Pod 선점을 고려합니다.
2.6.2.1. 선점되지 않은 우선 순위 클래스
선점 정책이 Never로 설정된 Pod는 예약 큐에서 우선순위가 낮은 Pod보다 앞에 배치되지만 다른 Pod는 선점할 수 없습니다. 예약 대기 중인 비 선점 Pod는 사용 가능한 리소스가 충분하고 해당 Pod를 예약할 수 있을 때까지 예약 큐에 남아 있습니다. 비 선점 Pod는 다른 Pod와 마찬가지로 스케줄러 백오프의 영향을 받습니다. 즉 스케줄러에서 이러한 Pod를 예약하지 못하면 더 낮은 빈도로 다시 예약을 시도하여 우선순위가 더 낮은 기타 Pod를 먼저 예약할 수 있습니다.
비 선점 Pod는 우선순위가 높은 다른 Pod에서 계속 선점할 수 있습니다.
2.6.2.2. Pod 선점 및 기타 스케줄러 설정
Pod 우선순위 및 선점 기능을 활성화하는 경우 다른 스케줄러 설정을 고려하십시오.
- Pod 우선순위 및 Pod 중단 예산
- Pod 중단 예산은 동시에 작동해야 하는 최소 복제본 수 또는 백분율을 지정합니다. Pod 중단 예산을 지정하면 최상의 노력 수준에서 Pod를 선점할 때 AWS의 Red Hat OpenShift Service가 해당 예산을 유지합니다. 스케줄러는 Pod 중단 예산을 위반하지 않고 Pod를 선점하려고 합니다. 이러한 Pod를 찾을 수 없는 경우 Pod 중단 예산 요구 사항과 관계없이 우선순위가 낮은 Pod를 선점할 수 있습니다.
- Pod 우선순위 및 Pod 유사성
- Pod 유사성을 위해서는 동일한 라벨이 있는 다른 Pod와 같은 노드에서 새 Pod를 예약해야 합니다.
노드에서 우선순위가 낮은 하나 이상의 Pod와 보류 중인 Pod에 Pod 간 유사성이 있는 경우 스케줄러는 선호도 요구 사항을 위반하지 않고 우선순위가 낮은 Pod를 선점할 수 없습니다. 이 경우 스케줄러는 보류 중인 Pod를 예약할 다른 노드를 찾습니다. 그러나 스케줄러에서 적절한 노드를 찾을 수 있다는 보장이 없고 보류 중인 Pod가 예약되지 않을 수 있습니다.
이러한 상황을 방지하려면 우선순위가 같은 Pod를 사용하여 Pod 유사성을 신중하게 구성합니다.
2.6.2.3. 선점된 Pod의 정상 종료
Pod를 선점할 때 스케줄러는 Pod의 정상 종료 기간이 만료될 때까지 대기하여 Pod가 작동을 완료하고 종료할 수 있도록 합니다. 기간이 지난 후에도 Pod가 종료되지 않으면 스케줄러에서 Pod를 종료합니다. 이러한 정상 종료 기간으로 인해 스케줄러에서 Pod를 선점하는 시점과 노드에서 보류 중인 Pod를 예약할 수 있는 시간 사이에 시차가 발생합니다.
이 간격을 최소화하려면 우선순위가 낮은 Pod의 정상 종료 기간을 짧게 구성하십시오.
2.6.3. 우선순위 및 선점 구성
Pod 사양에 priorityClassName 을 사용하여 우선순위 클래스 오브젝트를 생성하고 Pod를 우선순위에 연결하여 우선순위 및 선점을 적용합니다.
예약된 기존 Pod에 우선순위 클래스를 직접 추가할 수 없습니다.
프로세스
우선순위 및 선점을 사용하도록 클러스터를 구성하려면 다음을 수행합니다.
다음과 유사한 YAML 파일을 생성하여 우선순위 클래스의 이름을 포함하도록 Pod 사양을 정의합니다.
apiVersion: v1 kind: Pod metadata: name: nginx labels: env: test spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent priorityClassName: system-cluster-critical 1- 1
- 이 Pod에 사용할 우선순위 클래스를 지정합니다.
Pod를 생성합니다.
$ oc create -f <file-name>.yaml
Pod 구성 또는 Pod 템플릿에 우선순위 이름을 직접 추가할 수 있습니다.
