지원콘솔개발자평가판 시작연락처

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 오브젝트에서 잘못된 값은 클러스터 노드를 사용할 수 없게 만들 수 있습니다.

절차

  1. 구성하려는 노드 유형의 정적 CRD인 머신 구성 풀과 연결된 라벨을 가져옵니다. 다음 중 하나를 실행합니다.

    1. 원하는 머신 구성 풀의 현재 라벨을 확인합니다.

      예를 들면 다음과 같습니다. 

      $  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

    2. 원하는 머신 구성 풀에 사용자 정의 라벨을 추가합니다.

      예를 들면 다음과 같습니다. 

      $ oc label machineconfigpool worker custom-kubelet=enabled

  2. 구성 변경에 대한 kubeletconfig CR(사용자 정의 리소스)을 생성합니다.

    예를 들면 다음과 같습니다.

    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
#...

    1
    CR에 이름을 지정합니다.
    2
    구성 변경 사항을 적용하려면 라벨을 지정합니다. 이 라벨은 머신 구성 풀에 추가한 라벨입니다.
    3
    변경할 새 값을 지정합니다.

  3. 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 필드를 구성하여 컨트롤 플레인 노드를 허용하거나 허용하지 않을 수 있습니다.

중요

기본 예약 불가에서 예약 가능으로 컨트롤 플레인 노드를 구성하면 추가 서브스크립션이 필요합니다. 그 이유는 컨트롤 플레인 노드가 작업자 노드가 되기 때문입니다.

절차

  1. schedulers.config.openshift.io 리소스를 편집합니다. 

    $ oc edit schedulers.config.openshift.io cluster

  2. 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 로 설정합니다.
  3. 파일을 저장하여 변경 사항을 적용합니다.

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)가 설치되어 있습니다.

절차

  1. 다음 예제에 표시된 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
#...

  2. 다음 명령을 실행하여 새 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 클러스터에 대한 관리자 권한을 보유하고 있어야 합니다.

절차

  1. 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

  2. 커널 인수를 식별하는 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
    1
    새 커널 인수를 작업자 노드에만 적용합니다.
    2
    머신 구성(05) 중 적합한 위치와 어떤 기능 (SELinux 허용 모드를 구성하기 위해 커널 매개변수 추가)을 하는지 식별하기 위해 이름이 지정됩니다.
    3
    정확한 커널 인수를 enforcing=0으로 식별합니다.

  3. 새 머신 구성을 생성합니다. 

    $ oc create -f 05-worker-kernelarg-selinuxpermissive.yaml

  4. 머신 구성에서 새 구성이 추가되었는지 확인합니다. 

    $ 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

  5. 노드를 확인합니다. 

    $ oc get nodes

    출력 예

    NAME                           STATUS                     ROLES    AGE   VERSION
ip-10-0-136-161.ec2.internal   Ready                      worker   28m   v1.26.0
ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.26.0
ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.26.0
ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.26.0
ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.26.0
ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.26.0

    변경 사항이 적용되어 있기 때문에 각 작업자 노드의 예약이 비활성화되어 있음을 알 수 있습니다.

  6. 작업자 노드 중 하나로 이동하여 커널 명령 행 인수 (호스트의 /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 커널 인수를 설정하여 노드에서 스왑 계정을 활성화해야 합니다.

절차

  1. 스왑 메모리를 허용하려는 머신 구성 풀에 사용자 정의 라벨을 적용합니다. 

    $ oc label machineconfigpool worker kubelet-swap=enabled

  2. 사용자 정의 리소스(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
#...
    1
    연결된 노드에서 스왑 메모리 사용을 활성화하려면 false 로 설정합니다. 스왑 메모리 사용을 비활성화하려면 true 로 설정합니다.
    2
    스왑 메모리 동작을 지정합니다. 지정하지 않는 경우 기본값은 LimitedSwap 입니다.
  3. 시스템에서 스왑 메모리를 활성화합니다.

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 노드로 마이그레이션됩니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.