5.4. 노드 호스트 관련 권장 사례
OpenShift Container Platform 노드 구성 파일에는 중요한 옵션이 포함되어 있습니다. 예를 들어 두 개의 매개변수 podsPerCore
및 maxPods
는 하나의 노드에 대해 예약할 수 있는 최대 Pod 수를 제어합니다.
옵션을 둘 다 사용하는 경우 한 노드의 Pod 수는 두 값 중 작은 값으로 제한됩니다. 이 값을 초과하면 다음과 같은 결과가 발생할 수 있습니다.
- CPU 사용률 증가
- Pod 예약 속도 저하
- 노드의 메모리 크기에 따라 메모리 부족 시나리오 발생
- IP 주소 모두 소진
- 리소스 초과 커밋으로 인한 사용자 애플리케이션 성능 저하
Kubernetes의 경우 단일 컨테이너를 보유한 하나의 Pod에서 실제로 두 개의 컨테이너가 사용됩니다. 두 번째 컨테이너는 실제 컨테이너 시작 전 네트워킹 설정에 사용됩니다. 따라서 10개의 Pod를 실행하는 시스템에서는 실제로 20개의 컨테이너가 실행됩니다.
클라우드 공급자의 디스크 IOPS 제한이 CRI-O 및 kubelet에 영향을 미칠 수 있습니다. 노드에서 다수의 I/O 집약적 Pod가 실행되고 있는 경우 오버로드될 수 있습니다. 노드에서 디스크 I/O를 모니터링하고 워크로드에 대해 처리량이 충분한 볼륨을 사용하는 것이 좋습니다.
podsPerCore
는 노드의 프로세서 코어 수에 따라 노드가 실행할 수 있는 Pod 수를 설정합니다. 예를 들어 프로세서 코어가 4개인 노드에서 podsPerCore
가 10
으로 설정된 경우 노드에 허용되는 최대 Pod 수는 40
이 됩니다.
kubeletConfig: podsPerCore: 10
podsPerCore
를 0
으로 설정하면 이 제한이 비활성화됩니다. 기본값은 0
입니다. podsPerCore
는 maxPods
를 초과할 수 없습니다.
maxPods
는 노드의 속성에 관계없이 노드가 실행할 수 있는 Pod 수를 고정된 값으로 설정합니다.
kubeletConfig: maxPods: 250
5.4.1. KubeletConfig CRD를 생성하여 kubelet 매개변수 편집
kubelet 구성은 현재 Ignition 구성으로 직렬화되어 있으므로 직접 편집할 수 있습니다. 하지만 MCC(Machine Config Controller)에 새 kubelet-config-controller
도 추가되어 있습니다. 이를 통해 KubeletConfig
CR(사용자 정의 리소스)을 사용하여 kubelet 매개변수를 편집할 수 있습니다.
kubeletConfig
오브젝트의 필드가 Kubernetes 업스트림에서 kubelet으로 직접 전달되므로 kubelet은 해당 값을 직접 검증합니다. kubeletConfig
오브젝트의 값이 유효하지 않으면 클러스터 노드를 사용할 수 없게 될 수 있습니다. 유효한 값은 Kubernetes 설명서를 참조하십시오.
다음 지침 사항을 고려하십시오.
-
해당 풀에 필요한 모든 구성 변경 사항을 사용하여 각 머신 구성 풀에 대해 하나의
KubeletConfig
CR을 생성합니다. 모든 풀에 동일한 콘텐츠를 적용하는 경우 모든 풀에 대해 하나의KubeletConfig
CR만 필요합니다. -
기존
KubeletConfig
CR을 편집하여 각 변경 사항에 대한 CR을 생성하는 대신 기존 설정을 수정하거나 새 설정을 추가합니다. 변경 사항을 되돌릴 수 있도록 다른 머신 구성 풀을 수정하거나 임시로 변경하려는 변경 사항만 수정하기 위해 CR을 생성하는 것이 좋습니다. -
필요에 따라 클러스터당 10개로 제한되는 여러
KubeletConfig
CR을 생성합니다. 첫 번째KubeletConfig
CR의 경우 MCO(Machine Config Operator)는kubelet
에 추가된 머신 구성을 생성합니다. 이후 각 CR을 통해 컨트롤러는 숫자 접미사가 있는 다른kubelet
머신 구성을 생성합니다. 예를 들어,-2
접미사가 있는kubelet
머신 구성이 있는 경우 다음kubelet
머신 구성에-3
이 추가됩니다.
머신 구성을 삭제하려면 제한을 초과하지 않도록 해당 구성을 역순으로 삭제합니다. 예를 들어 kubelet-2
머신 구성을 삭제하기 전에 kubelet-3
머신 구성을 삭제합니다.
kubelet-9
접미사가 있는 머신 구성이 있고 다른 KubeletConfig
CR을 생성하는 경우 kubelet
머신 구성이 10개 미만인 경우에도 새 머신 구성이 생성되지 않습니다.
KubeletConfig
CR 예
$ oc get kubeletconfig
NAME AGE set-max-pods 15m
KubeletConfig
머신 구성 표시 예
$ oc get mc | grep kubelet
... 99-worker-generated-kubelet-1 b5c5119de007945b6fe6fb215db3b8e2ceb12511 3.2.0 26m ...
다음 프로세스는 작업자 노드의 각 노드에 대한 최대 Pod 수를 구성하는 방법을 보여줍니다.
사전 요구 사항
구성하려는 노드 유형의 정적
MachineConfigPool
CR와 연관된 라벨을 가져옵니다. 다음 중 하나를 실행합니다.Machine config pool을 표시합니다.
$ oc describe machineconfigpool <name>
예를 들면 다음과 같습니다.
$ oc describe machineconfigpool worker
출력 예
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool metadata: creationTimestamp: 2019-02-08T14:52:39Z generation: 1 labels: custom-kubelet: set-max-pods 1
- 1
- 라벨이 추가되면
labels
아래에 표시됩니다.
라벨이 없으면 키/값 쌍을 추가합니다.
$ oc label machineconfigpool worker custom-kubelet=set-max-pods
절차
이 명령은 선택할 수 있는 사용 가능한 머신 구성 오브젝트를 표시합니다.
$ oc get machineconfig
기본적으로 두 개의 kubelet 관련 구성은
01-master-kubelet
및01-worker-kubelet
입니다.노드당 최대 Pod의 현재 값을 확인하려면 다음을 실행합니다.
$ oc describe node <node_name>
예를 들면 다음과 같습니다.
$ oc describe node ci-ln-5grqprb-f76d1-ncnqq-worker-a-mdv94
Allocatable
스탠자에서value: pods: <value>
를 찾습니다.출력 예
Allocatable: attachable-volumes-aws-ebs: 25 cpu: 3500m hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 15341844Ki pods: 250
작업자 노드에서 노드당 최대 Pod 수를 설정하려면 kubelet 구성이 포함된 사용자 정의 리소스 파일을 생성합니다.
apiVersion: machineconfiguration.openshift.io/v1 kind: KubeletConfig metadata: name: set-max-pods spec: machineConfigPoolSelector: matchLabels: custom-kubelet: set-max-pods 1 kubeletConfig: maxPods: 500 2
참고kubelet이 API 서버와 통신하는 속도는 QPS(초당 쿼리) 및 버스트 값에 따라 달라집니다. 노드마다 실행되는 Pod 수가 제한된 경우 기본 값인
50
(kubeAPIQPS
인 경우) 및100
(kubeAPIBurst
인 경우)이면 충분합니다. 노드에 CPU 및 메모리 리소스가 충분한 경우 kubelet QPS 및 버스트 속도를 업데이트하는 것이 좋습니다.apiVersion: machineconfiguration.openshift.io/v1 kind: KubeletConfig metadata: name: set-max-pods spec: machineConfigPoolSelector: matchLabels: custom-kubelet: set-max-pods kubeletConfig: maxPods: <pod_count> kubeAPIBurst: <burst_rate> kubeAPIQPS: <QPS>
라벨을 사용하여 작업자의 머신 구성 풀을 업데이트합니다.
$ oc label machineconfigpool worker custom-kubelet=large-pods
KubeletConfig
오브젝트를 생성합니다.$ oc create -f change-maxPods-cr.yaml
KubeletConfig
오브젝트가 생성되었는지 확인합니다.$ oc get kubeletconfig
출력 예
NAME AGE set-max-pods 15m
클러스터의 작업자 노드 수에 따라 작업자 노드가 하나씩 재부팅될 때까지 기다립니다. 작업자 노드가 3개인 클러스터의 경우 약 10~15분이 걸릴 수 있습니다.
변경 사항이 노드에 적용되었는지 확인합니다.
작업자 노드에서
maxPods
값이 변경되었는지 확인합니다.$ oc describe node <node_name>
Allocatable
스탠자를 찾습니다.... Allocatable: attachable-volumes-gce-pd: 127 cpu: 3500m ephemeral-storage: 123201474766 hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 14225400Ki pods: 500 1 ...
- 1
- 이 예에서
pods
매개변수는KubeletConfig
오브젝트에 설정한 값을 보고해야 합니다.
KubeletConfig
오브젝트에서 변경 사항을 확인합니다.$ oc get kubeletconfigs set-max-pods -o yaml
상태가 표시되어야 합니다. "true"
및type:Success
:spec: kubeletConfig: maxPods: 500 machineConfigPoolSelector: matchLabels: custom-kubelet: set-max-pods status: conditions: - lastTransitionTime: "2021-06-30T17:04:07Z" message: Success status: "True" type: Success
5.4.3. 컨트롤 플레인 노드 크기 조정
컨트롤 플레인 노드 리소스 요구사항은 클러스터의 노드 수에 따라 달라집니다. 다음 컨트롤 플레인 노드 크기 권장 사항은 컨트롤 플레인 밀도 중심 테스트 결과를 기반으로 합니다. 컨트롤 플레인 테스트에서는 노드 수에 따라 각 네임스페이스의 클러스터에서 다음 오브젝트를 생성합니다.
- 12개의 이미지 스트림
- 3개의 빌드 구성
- 6개의 빌드
- 각각 두 개의 시크릿을 마운트하는 2개의 Pod 복제본이 있는 배포 1개
- 2개의 배포에 1개의 Pod 복제본이 2개의 시크릿을 마운트함
- 이전 배포를 가리키는 서비스 3개
- 이전 배포를 가리키는 경로 3개
- 10개의 시크릿, 이 중 2 개는 이전 배포에 의해 마운트됨
- 10개의 구성 맵, 이 중 두 개는 이전 배포에 의해 마운트됨
작업자 노드 수 | 클러스터 로드(네임스페이스) | CPU 코어 수 | 메모리(GB) |
---|---|---|---|
25 | 500 | 4 | 16 |
100 | 1000 | 8 | 32 |
250 | 4000 | 16 | 96 |
3개의 마스터 또는 컨트롤 플레인 노드가 있는 대규모 및 고밀도 클러스터에서는 노드 중 하나가 중지되거나, 재부팅 또는 실패할 때 CPU 및 메모리 사용량이 증가합니다. 비용 절감을 위해 클러스터를 종료한 후 클러스터를 재시작하는 의도적인 경우 외에도 전원, 네트워크 또는 기본 인프라와 관련된 예기치 않은 문제로 인해 오류가 발생할 수 있습니다. 나머지 두 컨트롤 플레인 노드는 고가용성이 되기 위해 부하를 처리하여 리소스 사용량을 늘려야 합니다. 이는 마스터가 직렬로 연결, 드레이닝, 재부팅되어 운영 체제 업데이트를 적용하고 컨트롤 플레인 Operator 업데이트를 적용하기 때문에 업그레이드 중에도 이 문제가 발생할 수 있습니다. 단계적 오류를 방지하려면 컨트롤 플레인 노드의 전체 CPU 및 메모리 리소스 사용량을 리소스 사용량 급증을 처리하기 위해 사용 가능한 모든 용량의 60%로 유지합니다. 리소스 부족으로 인한 다운타임을 방지하기 위해 컨트롤 플레인 노드에서 CPU 및 메모리를 늘립니다.
노드 크기 조정은 클러스터의 노드 수와 개체 수에 따라 달라집니다. 또한 클러스터에서 개체가 현재 생성되는지에 따라 달라집니다. 개체 생성 중에 컨트롤 플레인은 개체가 running
단계에 있을 때보다 리소스 사용량 측면에서 더 활성화됩니다.
OLM(Operator Lifecycle Manager)은 컨트롤 플레인 노드에서 실행되며, 메모리 공간은 OLM이 클러스터에서 관리해야 하는 네임스페이스 및 사용자 설치된 operator 수에 따라 다릅니다. OOM이 종료되지 않도록 컨트를 플레인 노드의 크기를 적절하게 조정해야 합니다. 다음 데이터 지점은 클러스터 최대값 테스트 결과를 기반으로 합니다.
네임스페이스 수 | 유휴 상태의 OLM 메모리(GB) | 5명의 사용자 operator가 설치된 OLM 메모리(GB) |
---|---|---|
500 | 0.823 | 1.7 |
1000 | 1.2 | 2.5 |
1500 | 1.7 | 3.2 |
2000 | 2 | 4.4 |
3000 | 2.7 | 5.6 |
4000 | 3.8 | 7.6 |
5000 | 4.2 | 9.02 |
6000 | 5.8 | 11.3 |
7000 | 6.6 | 12.9 |
8000 | 6.9 | 14.8 |
9000 | 8 | 17.7 |
10,000 | 9.9 | 21.6 |
설치 관리자 프로비저닝 인프라 설치 방법을 사용하는 경우 실행 중인 OpenShift Container Platform 4.8 클러스터에서 컨트롤 플레인 노드 크기를 변경할 수 없습니다. 대신 총 노드 수를 추정하고 설치하는 동안 권장되는 컨트롤 플레인 노드 크기를 사용해야 합니다.
권장 사항은 OpenShift SDN이 있는 OpenShift Container Platform 클러스터에서 네트워크 플러그인으로 캡처된 데이터 포인트를 기반으로 합니다.
OpenShift Container Platform 3.11 및 이전 버전과 비교하면, OpenShift Container Platform 4.8에서는 기본적으로 CPU 코어의 절반(500밀리코어)이 시스템에 의해 예약되어 있습니다. 이러한 점을 고려하여 크기가 결정됩니다.
5.4.4. CPU 관리자 설정
절차
선택 사항: 노드에 레이블을 지정합니다.
# oc label node perf-node.example.com cpumanager=true
CPU 관리자를 활성화해야 하는 노드의
MachineConfigPool
을 편집합니다. 이 예에서는 모든 작업자의 CPU 관리자가 활성화됩니다.# oc edit machineconfigpool worker
작업자 머신 구성 풀에 레이블을 추가합니다.
metadata: creationTimestamp: 2020-xx-xxx generation: 3 labels: custom-kubelet: cpumanager-enabled
KubeletConfig
,cpumanager-kubeletconfig.yaml
, CR(사용자 정의 리소스)을 생성합니다. 이전 단계에서 생성한 레이블을 참조하여 올바른 노드가 새 kubelet 구성으로 업데이트되도록 합니다.machineConfigPoolSelector
섹션을 참조하십시오.apiVersion: machineconfiguration.openshift.io/v1 kind: KubeletConfig metadata: name: cpumanager-enabled spec: machineConfigPoolSelector: matchLabels: custom-kubelet: cpumanager-enabled kubeletConfig: cpuManagerPolicy: static 1 cpuManagerReconcilePeriod: 5s 2
동적 kubelet 구성을 생성합니다.
# oc create -f cpumanager-kubeletconfig.yaml
그러면 kubelet 구성에 CPU 관리자 기능이 추가되고 필요한 경우 MCO(Machine Config Operator)가 노드를 재부팅합니다. CPU 관리자를 활성화하는 데는 재부팅이 필요하지 않습니다.
병합된 kubelet 구성을 확인합니다.
# oc get machineconfig 99-worker-XXXXXX-XXXXX-XXXX-XXXXX-kubelet -o json | grep ownerReference -A7
출력 예
"ownerReferences": [ { "apiVersion": "machineconfiguration.openshift.io/v1", "kind": "KubeletConfig", "name": "cpumanager-enabled", "uid": "7ed5616d-6b72-11e9-aae1-021e1ce18878" } ]
작업자에서 업데이트된
kubelet.conf
를 확인합니다.# oc debug node/perf-node.example.com sh-4.2# cat /host/etc/kubernetes/kubelet.conf | grep cpuManager
출력 예
cpuManagerPolicy: static 1 cpuManagerReconcilePeriod: 5s 2
코어를 하나 이상 요청하는 Pod를 생성합니다. 제한 및 요청 둘 다 해당 CPU 값이 정수로 설정되어야 합니다. 해당 숫자는 이 Pod 전용으로 사용할 코어 수입니다.
# cat cpumanager-pod.yaml
출력 예
apiVersion: v1 kind: Pod metadata: generateName: cpumanager- spec: containers: - name: cpumanager image: gcr.io/google_containers/pause-amd64:3.0 resources: requests: cpu: 1 memory: "1G" limits: cpu: 1 memory: "1G" nodeSelector: cpumanager: "true"
Pod를 생성합니다.
# oc create -f cpumanager-pod.yaml
레이블 지정한 노드에 Pod가 예약되어 있는지 검증합니다.
# oc describe pod cpumanager
출력 예
Name: cpumanager-6cqz7 Namespace: default Priority: 0 PriorityClassName: <none> Node: perf-node.example.com/xxx.xx.xx.xxx ... Limits: cpu: 1 memory: 1G Requests: cpu: 1 memory: 1G ... QoS Class: Guaranteed Node-Selectors: cpumanager=true
cgroups
가 올바르게 설정되었는지 검증합니다.pause
프로세스의 PID(프로세스 ID)를 가져옵니다.# ├─init.scope │ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 17 └─kubepods.slice ├─kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice │ ├─crio-b5437308f1a574c542bdf08563b865c0345c8f8c0b0a655612c.scope │ └─32706 /pause
QoS(Quality of Service) 계층
Guaranteed
의 Pod는kubepods.slice
에 있습니다. 다른 QoS 계층의 Pod는kubepods
의 하위cgroups
에 있습니다.# cd /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice/crio-b5437308f1ad1a7db0574c542bdf08563b865c0345c86e9585f8c0b0a655612c.scope # for i in `ls cpuset.cpus tasks` ; do echo -n "$i "; cat $i ; done
출력 예
cpuset.cpus 1 tasks 32706
작업에 허용되는 CPU 목록을 확인합니다.
# grep ^Cpus_allowed_list /proc/32706/status
출력 예
Cpus_allowed_list: 1
Guaranteed
Pod용으로 할당된 코어에서는 시스템의 다른 Pod(이 경우burstable
QoS 계층의 Pod)를 실행할 수 없는지 검증합니다.# cat /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podc494a073_6b77_11e9_98c0_06bba5c387ea.slice/crio-c56982f57b75a2420947f0afc6cafe7534c5734efc34157525fa9abbf99e3849.scope/cpuset.cpus 0 # oc describe node perf-node.example.com
출력 예
... Capacity: attachable-volumes-aws-ebs: 39 cpu: 2 ephemeral-storage: 124768236Ki hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 8162900Ki pods: 250 Allocatable: attachable-volumes-aws-ebs: 39 cpu: 1500m ephemeral-storage: 124768236Ki hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 7548500Ki pods: 250 ------- ---- ------------ ---------- --------------- ------------- --- default cpumanager-6cqz7 1 (66%) 1 (66%) 1G (12%) 1G (12%) 29m Allocated resources: (Total limits may be over 100 percent, i.e., overcommitted.) Resource Requests Limits -------- -------- ------ cpu 1440m (96%) 1 (66%)
이 VM에는 두 개의 CPU 코어가 있습니다.
system-reserved
설정은 500밀리코어로 설정되었습니다. 즉,Node Allocatable
양이 되는 노드의 전체 용량에서 한 코어의 절반이 감산되었습니다.Allocatable CPU
는 1500 밀리코어임을 확인할 수 있습니다. 즉, Pod마다 하나의 전체 코어를 사용하므로 CPU 관리자 Pod 중 하나를 실행할 수 있습니다. 전체 코어는 1000밀리코어에 해당합니다. 두 번째 Pod를 예약하려고 하면 시스템에서 해당 Pod를 수락하지만 Pod가 예약되지 않습니다.NAME READY STATUS RESTARTS AGE cpumanager-6cqz7 1/1 Running 0 33m cpumanager-7qc2t 0/1 Pending 0 11s