6.3. 노드 관리
OpenShift Container Platform에서는 KubeletConfig CR(사용자 정의 리소스)을 사용하여 노드의 구성을 관리합니다. KubeletConfig 오브젝트의 인스턴스를 생성하면 관리형 머신 구성이 생성되어 노드의 설정을 덮어씁니다.
구성을 변경하기 위해 원격 머신에 로그인하는 것은 지원되지 않습니다.
6.3.1. 노드 수정
클러스터 또는 머신 풀을 구성하려면 CRD(사용자 정의 리소스 정의) 또는 kubeletConfig 오브젝트를 생성해야 합니다. OpenShift Container Platform에서는 CRD를 통해 도입된 변경 사항을 확인하는 데 Machine Config Controller를 사용하여 클러스터에 변경 사항을 적용합니다.
kubeletConfig 오브젝트의 필드는 업스트림 Kubernetes에서 kubelet에 직접 전달되므로 해당 필드의 검증은 kubelet 자체에서 직접 처리합니다. 이러한 필드의 유효한 값은 관련 Kubernetes 설명서를 참조하십시오. kubeletConfig 오브젝트의 잘못된 값은 클러스터 노드를 사용할 수 없게 될 수 있습니다.
프로세스
구성하려는 노드 유형의 정적 CRD인 머신 구성 풀과 연결된 라벨을 가져옵니다. 다음 중 하나를 실행합니다.
원하는 머신 구성 풀의 현재 라벨을 확인합니다.
예를 들면 다음과 같습니다.
$ oc get machineconfigpool --show-labels
출력 예
NAME CONFIG UPDATED UPDATING DEGRADED LABELS master rendered-master-e05b81f5ca4db1d249a1bf32f9ec24fd True False False operator.machineconfiguration.openshift.io/required-for-upgrade= worker rendered-worker-f50e78e1bc06d8e82327763145bfcf62 True False False
원하는 머신 구성 풀에 사용자 정의 라벨을 추가합니다.
예를 들면 다음과 같습니다.
$ oc label machineconfigpool worker custom-kubelet=enabled
구성 변경에 대한
kubeletconfigCR(사용자 정의 리소스)을 생성합니다.예를 들면 다음과 같습니다.
custom-config CR 구성 샘플
apiVersion: machineconfiguration.openshift.io/v1 kind: KubeletConfig metadata: name: custom-config 1 spec: machineConfigPoolSelector: matchLabels: custom-kubelet: enabled 2 kubeletConfig: 3 podsPerCore: 10 maxPods: 250 systemReserved: cpu: 2000m memory: 1Gi #...
CR 오브젝트를 생성합니다.
$ oc create -f <file-name>
예를 들면 다음과 같습니다.
$ oc create -f master-kube-config.yaml
대부분의 Kubelet 구성 옵션은 사용자가 설정할 수 있습니다. 다음 옵션은 덮어쓸 수 없습니다.
- CgroupDriver
- ClusterDNS
- ClusterDomain
- StaticPodPath
단일 노드에 50개 이상의 이미지가 포함된 경우 노드 간에 Pod 예약이 분산될 수 있습니다. 노드의 이미지 목록이 기본적으로 50개로 단축되기 때문입니다. KubeletConfig 오브젝트를 편집하고 nodeStatusMaxImages 값을 -1 로 설정하여 이미지 제한을 비활성화할 수 있습니다.
6.3.2. 컨트롤 플레인 노드를 예약 가능으로 구성
컨트롤 플레인 노드를 예약할 수 있도록 구성할 수 있습니다. 즉, 새 Pod를 마스터 노드에 배치할 수 있습니다. 기본적으로 컨트롤 플레인 노드는 예약할 수 없습니다.
마스터는 예약 가능으로 설정할 수 있지만 작업자 노드는 유지해야 합니다.
베어 메탈 클러스터에 작업자 노드 없이 OpenShift Container Platform을 배포할 수 있습니다. 이 경우 컨트롤 플레인 노드는 기본적으로 예약 가능으로 표시됩니다.
mastersSchedulable 필드를 구성하여 컨트롤 플레인 노드를 예약할 수 있도록 허용하거나 허용하지 않을 수 있습니다.
기본 예약 불가에서 예약 가능으로 컨트롤 플레인 노드를 구성하면 추가 서브스크립션이 필요합니다. 그 이유는 컨트롤 플레인 노드가 작업자 노드가 되기 때문입니다.
프로세스
schedulers.config.openshift.io리소스를 편집합니다.$ oc edit schedulers.config.openshift.io cluster
mastersSchedulable필드를 구성합니다.apiVersion: config.openshift.io/v1 kind: Scheduler metadata: creationTimestamp: "2019-09-10T03:04:05Z" generation: 1 name: cluster resourceVersion: "433" selfLink: /apis/config.openshift.io/v1/schedulers/cluster uid: a636d30a-d377-11e9-88d4-0a60097bee62 spec: mastersSchedulable: false 1 status: {} #...- 1
- 컨트롤 플레인 노드를 예약할 수 있도록 하려면
true로 설정하거나 컨트롤 플레인 노드를 예약할 수 없도록 하려면false로 설정합니다.
- 파일을 저장하여 변경 사항을 적용합니다.
6.3.3. SELinux 부울 설정
OpenShift Container Platform을 사용하면 RHCOS(Red Hat Enterprise Linux CoreOS) 노드에서 SELinux 부울을 활성화 및 비활성화할 수 있습니다. 다음 절차에서는 MCO(Machine Config Operator)를 사용하여 노드에서 SELinux 부울을 수정하는 방법을 설명합니다. 이 절차에서는 container_manage_cgroup 을 예제 부울로 사용합니다. 필요한 부울 값으로 이 값을 수정할 수 있습니다.
사전 요구 사항
- OpenShift CLI(oc)가 설치되어 있습니다.
프로세스
다음 예에 표시된
MachineConfig오브젝트를 사용하여 새 YAML 파일을 만듭니다.apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: 99-worker-setsebool spec: config: ignition: version: 3.2.0 systemd: units: - contents: | [Unit] Description=Set SELinux booleans Before=kubelet.service [Service] Type=oneshot ExecStart=/sbin/setsebool container_manage_cgroup=on RemainAfterExit=true [Install] WantedBy=multi-user.target graphical.target enabled: true name: setsebool.service #...다음 명령을 실행하여 새
MachineConfig오브젝트를 만듭니다.$ oc create -f 99-worker-setsebool.yaml
MachineConfig 오브젝트에 변경 사항을 적용하면 변경 사항이 적용된 후 영향을 받는 모든 노드가 정상적으로 재부팅됩니다.
6.3.4. 노드에 커널 인수 추가
특별한 경우에는 클러스터 노드 세트에 커널 인수를 추가해야 할 수 있습니다. 이 작업을 수행할 때 주의해야 하며 먼저 설정된 인수의 영향을 명확하게 이해하고 있어야합니다.
커널 인수를 잘못 사용하면 시스템이 부팅되지 않을 수 있습니다.
설정할 수 있는 커널 인수의 예는 다음과 같습니다.
-
nosmt: 커널에서 대칭 멀티 스레딩 (SMT)을 비활성화합니다. 멀티 스레딩은 각 CPU마다 여러 개의 논리 스레드를 허용합니다. 멀티 테넌트 환경에서
nosmt를 사용하여 잠재적인 크로스 스레드 공격 위험을 줄일 수 있습니다. SMT를 비활성화하는 것은 기본적으로 성능보다는 보안을 중요시하여 선택하는 것과 같습니다. - systemd.unified_cgroup_hierarchy: Linux 제어 그룹 버전 2 (cgroup v2)를 활성화합니다. cgroup v2는 다음 버전의 커널 제어 그룹 이며 여러 개선 사항을 제공합니다.
enforcing=0: SELinux(Security Enhanced Linux)를 허용 모드에서 실행하도록 구성합니다. 허용 모드에서는 SELinux가 개체에 레이블을 지정하고 로그에 액세스 거부 항목을 내보내는 등 로드된 보안 정책을 적용하는 것처럼 동작하지만 실제로는 어떤 작업도 거부하지 않습니다. 프로덕션 시스템에는 지원되지 않지만 허용 모드는 디버깅에 유용할 수 있습니다.
주의프로덕션에서 RHCOS에서 SELinux를 비활성화하는 것은 지원되지 않습니다. 노드에서 SELinux를 비활성화한 후에는 프로덕션 클러스터에서 다시 프로비저닝해야 합니다.
커널 인수 목록 및 설명은 Kernel.org 커널 매개변수에서 참조하십시오.
다음 프로세스에서는 다음을 식별하는 MachineConfig를 만듭니다.
- 커널 인수를 추가하려는 머신 세트입니다. 이 경우 작업자 역할을 갖는 머신입니다.
- 기존 커널 인수 끝에 추가되는 커널 인수입니다.
- 머신 구성 목록에서 변경 사항이 적용되는 위치를 나타내는 라벨입니다.
사전 요구 사항
- OpenShift Container Platform 클러스터에 대한 관리자 권한을 보유하고 있어야 합니다.
프로세스
OpenShift Container Platform 클러스터의 기존
MachineConfig오브젝트를 나열하고 머신 구성에 라벨을 지정하는 방법을 결정합니다.$ oc get MachineConfig
출력 예
NAME GENERATEDBYCONTROLLER IGNITIONVERSION AGE 00-master 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 00-worker 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-master-container-runtime 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-master-kubelet 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-worker-container-runtime 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-worker-kubelet 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 99-master-generated-registries 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 99-master-ssh 3.2.0 40m 99-worker-generated-registries 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 99-worker-ssh 3.2.0 40m rendered-master-23e785de7587df95a4b517e0647e5ab7 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m rendered-worker-5d596d9293ca3ea80c896a1191735bb1 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m
커널 인수를 식별하는
MachineConfig파일을 만듭니다 (예:05-worker-kernelarg-selinuxpermissive.yaml).apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker1 name: 05-worker-kernelarg-selinuxpermissive2 spec: kernelArguments: - enforcing=03새 머신 구성을 생성합니다.
$ oc create -f 05-worker-kernelarg-selinuxpermissive.yaml
머신 구성에서 새 구성이 추가되었는지 확인합니다.
$ oc get MachineConfig
출력 예
NAME GENERATEDBYCONTROLLER IGNITIONVERSION AGE 00-master 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 00-worker 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-master-container-runtime 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-master-kubelet 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-worker-container-runtime 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 01-worker-kubelet 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 05-worker-kernelarg-selinuxpermissive 3.2.0 105s 99-master-generated-registries 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 99-master-ssh 3.2.0 40m 99-worker-generated-registries 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m 99-worker-ssh 3.2.0 40m rendered-master-23e785de7587df95a4b517e0647e5ab7 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m rendered-worker-5d596d9293ca3ea80c896a1191735bb1 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m
노드를 확인합니다.
$ oc get nodes
출력 예
NAME STATUS ROLES AGE VERSION ip-10-0-136-161.ec2.internal Ready worker 28m v1.27.3 ip-10-0-136-243.ec2.internal Ready master 34m v1.27.3 ip-10-0-141-105.ec2.internal Ready,SchedulingDisabled worker 28m v1.27.3 ip-10-0-142-249.ec2.internal Ready master 34m v1.27.3 ip-10-0-153-11.ec2.internal Ready worker 28m v1.27.3 ip-10-0-153-150.ec2.internal Ready master 34m v1.27.3
변경 사항이 적용되어 있기 때문에 각 작업자 노드의 예약이 비활성화되어 있음을 알 수 있습니다.
작업자 노드 중 하나로 이동하여 커널 명령 행 인수 (호스트의
/proc/cmdline에 있음)를 나열하여 커널 인수가 작동하는지 확인합니다.$ oc debug node/ip-10-0-141-105.ec2.internal
출력 예
Starting pod/ip-10-0-141-105ec2internal-debug ... To use host binaries, run `chroot /host` sh-4.2# cat /host/proc/cmdline BOOT_IMAGE=/ostree/rhcos-... console=tty0 console=ttyS0,115200n8 rootflags=defaults,prjquota rw root=UUID=fd0... ostree=/ostree/boot.0/rhcos/16... coreos.oem.id=qemu coreos.oem.id=ec2 ignition.platform.id=ec2 enforcing=0 sh-4.2# exit
enforcing=0인수가 다른 커널 인수에 추가된 것을 확인할 수 있습니다.
6.3.5. 노드에서 스왑 메모리 사용 활성화
노드에서 스왑 메모리 사용을 활성화하는 것은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
노드별로 OpenShift Container Platform 워크로드에 대한 스왑 메모리 사용을 활성화할 수 있습니다.
스왑 메모리를 활성화하면 워크로드 성능 및 리소스 부족 처리에 부정적인 영향을 미칠 수 있습니다. 컨트롤 플레인 노드에서 스왑 메모리를 활성화하지 마십시오.
스왑 메모리를 활성화하려면 kubeletconfig CR(사용자 정의 리소스)을 생성하여 swapbehavior 매개변수를 설정합니다. 제한되거나 무제한 스왑 메모리를 설정할 수 있습니다.
제한:
LimitedSwap값을 사용하여 스왑 메모리 워크로드가 사용할 수 있는 양을 제한합니다. OpenShift Container Platform에서 관리하지 않는 노드의 모든 워크로드는 여전히 스왑 메모리를 사용할 수 있습니다.LimitedSwap동작은 Linux 제어 그룹 버전 1 (cgroups v1) 또는 버전 2 (cgroup v 2):에서 노드가 실행 중인지에 따라 다릅니다.- cgroup v1: OpenShift Container Platform 워크로드는 설정된 경우 Pod의 메모리 제한까지 메모리와 스왑의 조합을 사용할 수 있습니다.
- cgroup v2: OpenShift Container Platform 워크로드는 스왑 메모리를 사용할 수 없습니다.
-
무제한:
UnlimitedSwap값을 사용하여 워크로드가 시스템 제한까지 요청한 만큼 스왑 메모리를 사용할 수 있습니다.
kubelet은 이 구성없이 스왑 메모리가 없으면 시작되지 않으므로 노드에서 스왑 메모리를 활성화하기 전에 OpenShift Container Platform에서 스왑 메모리를 활성화해야 합니다. 노드에 스왑 메모리가 없는 경우 OpenShift Container Platform에서 스왑 메모리를 활성화하면 적용되지 않습니다.
사전 요구 사항
- 버전 4.10 이상을 사용하는 실행 중인 OpenShift Container Platform 클러스터가 있어야 합니다.
- 관리 권한이 있는 사용자로 클러스터에 로그인했습니다.
클러스터에서
TechPreviewNoUpgrade기능 세트를 활성화했습니다( 노드클러스터 작업 기능 게이트를 사용한 기능 활성화참조). 참고TechPreviewNoUpgrade기능 세트를 활성화하면 취소할 수 없으며 마이너 버전 업데이트가 허용되지 않습니다. 이러한 기능 세트는 프로덕션 클러스터에서는 권장되지 않습니다.-
노드에서 cgroup v2가 활성화된 경우
swapaccount=1커널 인수를 설정하여 노드에서 스왑 계정을 활성화해야 합니다.
프로세스
스왑 메모리를 허용하려는 머신 구성 풀에 사용자 지정 레이블을 적용합니다.
$ oc label machineconfigpool worker kubelet-swap=enabled
CR(사용자 정의 리소스)을 생성하여 스왑 설정을 활성화하고 구성합니다.
apiVersion: machineconfiguration.openshift.io/v1 kind: KubeletConfig metadata: name: swap-config spec: machineConfigPoolSelector: matchLabels: kubelet-swap: enabled kubeletConfig: failSwapOn: false 1 memorySwap: swapBehavior: LimitedSwap 2 #...- 시스템에서 스왑 메모리를 활성화합니다.
6.3.6. 하나의 RHOSP 호스트에서 다른 RHOSP 호스트로 컨트롤 플레인 노드를 수동으로 마이그레이션
클러스터에서 컨트롤 플레인 머신 세트가 활성화되지 않은 경우 컨트롤 플레인 노드를 RHOSP(Red Hat OpenStack Platform) 노드에서 다른 노드로 이동하는 스크립트를 실행할 수 있습니다.
사용자 프로비저닝 인프라에서 실행되는 클러스터에서 컨트롤 플레인 머신 세트가 활성화되지 않습니다.
컨트롤 플레인 머신 세트에 대한 자세한 내용은 "컨트롤 플레인 머신 세트가 있는 컨트롤 플레인 시스템 관리"를 참조하십시오.
사전 요구 사항
-
환경 변수
OS_CLOUD는clouds.yaml -
환경 변수
KUBECONFIG는 관리 OpenShift Container Platform 인증 정보가 포함된 구성을 나타냅니다.
프로세스
- 명령줄에서 다음 스크립트를 실행합니다.
#!/usr/bin/env bash
set -Eeuo pipefail
if [ $# -lt 1 ]; then
echo "Usage: '$0 node_name'"
exit 64
fi
# Check for admin OpenStack credentials
openstack server list --all-projects >/dev/null || { >&2 echo "The script needs OpenStack admin credentials. Exiting"; exit 77; }
# Check for admin OpenShift credentials
oc adm top node >/dev/null || { >&2 echo "The script needs OpenShift admin credentials. Exiting"; exit 77; }
set -x
declare -r node_name="$1"
declare server_id
server_id="$(openstack server list --all-projects -f value -c ID -c Name | grep "$node_name" | cut -d' ' -f1)"
readonly server_id
# Drain the node
oc adm cordon "$node_name"
oc adm drain "$node_name" --delete-emptydir-data --ignore-daemonsets --force
# Power off the server
oc debug "node/${node_name}" -- chroot /host shutdown -h 1
# Verify the server is shut off
until openstack server show "$server_id" -f value -c status | grep -q 'SHUTOFF'; do sleep 5; done
# Migrate the node
openstack server migrate --wait "$server_id"
# Resize the VM
openstack server resize confirm "$server_id"
# Wait for the resize confirm to finish
until openstack server show "$server_id" -f value -c status | grep -q 'SHUTOFF'; do sleep 5; done
# Restart the VM
openstack server start "$server_id"
# Wait for the node to show up as Ready:
until oc get node "$node_name" | grep -q "^${node_name}[[:space:]]\+Ready"; do sleep 5; done
# Uncordon the node
oc adm uncordon "$node_name"
# Wait for cluster operators to stabilize
until oc get co -o go-template='statuses: {{ range .items }}{{ range .status.conditions }}{{ if eq .type "Degraded" }}{{ if ne .status "False" }}DEGRADED{{ end }}{{ else if eq .type "Progressing"}}{{ if ne .status "False" }}PROGRESSING{{ end }}{{ else if eq .type "Available"}}{{ if ne .status "True" }}NOTAVAILABLE{{ end }}{{ end }}{{ end }}{{ end }}' | grep -qv '\(DEGRADED\|PROGRESSING\|NOTAVAILABLE\)'; do sleep 5; done스크립트가 완료되면 컨트롤 플레인 시스템이 새 RHOSP 노드로 마이그레이션됩니다.
추가 리소스
- 컨트롤 플레인 머신 세트에 대한 자세한 내용은 컨트롤 플레인 머신 세트를 사용하여 컨트롤 플레인 시스템 관리를 참조하십시오.
