검색

3.2. MachineConfig 개체를 사용하여 노드 구성

download PDF

이 섹션의 작업을 통해 MachineConfig 객체를 생성하여 OpenShift Container Platform 노드에서 실행되는 파일, systemd 단위 파일 및 기타 운영 체제 기능을 변경할 수 있습니다. 머신 구성 사용에 대한 자세한 내용은 SSH 인증 키 업데이트, 이미지 서명 확인,SCTP 활성화, OpenShift Container Platform 용 iSCSI 개시자 이름 구성과 관련된 내용을 참조하십시오.

OpenShift Container Platform은 Ignition 사양 버전 3.2을 지원합니다. 앞으로 생성하는 모든 새로운 머신 구성은 Ignition 사양 버전 3.2를 기반으로 해야합니다. OpenShift Container Platform 클러스터를 업그레이드하는 경우 기존 Ignition 사양 버전 2.x 머신 구성은 사양 버전 3.2로 자동 변환됩니다.

작은 정보

OpenShift Container Platform 노드에 다른 구성 파일을 추가하는 방법의 경우 다음 " chrony 타임 서비스 구성" 절차를 모델로 사용하십시오.

3.2.1. chrony 타임 서비스 설정

chrony.conf 파일의 내용을 수정하고 해당 내용을 머신 구성으로 노드에 전달하여 chrony 타임 서비스 (chronyd)에서 사용하는 시간 서버 및 관련 구성을 설정할 수 있습니다.

프로세스

  1. chrony.conf 파일의 내용을 포함하여 Butane config를 만듭니다. 예를 들어 작업자 노드에 chrony를 구성하려면 99-worker-chrony.bu 파일을 만듭니다.

    참고

    Butane에 대한 자세한 내용은 “Butane 을 사용하여 머신 구성 생성”을 참조하십시오.

    variant: openshift
    version: 4.9.0
    metadata:
      name: 99-worker-chrony 1
      labels:
        machineconfiguration.openshift.io/role: worker 2
    storage:
      files:
      - path: /etc/chrony.conf
        mode: 0644 3
        overwrite: true
        contents:
          inline: |
            pool 0.rhel.pool.ntp.org iburst 4
            driftfile /var/lib/chrony/drift
            makestep 1.0 3
            rtcsync
            logdir /var/log/chrony
    1 2
    컨트롤 플레인 노드에서 두 위치에 있는 masterworker로 대체합니다.
    3
    시스템 구성 파일에서 mode 필드의 8진수 값 모드를 지정합니다. 파일을 만들고 변경 사항을 적용하면 모드가 10진수 값으로 변환됩니다. oc get mc <mc-name> -o yaml 명령을 사용하여 YAML 파일을 확인할 수 있습니다.
    4
    DHCP 서버에서 제공하는 것과 같은 유효한 시간 소스를 지정합니다. 다른 방법으로 1.rhel.pool.ntp.org, 2.rhel.pool.ntp.org 또는 3.rhel.pool.ntp.org의 NTP 서버 중 하나를 지정할 수 있습니다.
  2. Butane을 사용하여 노드에 전달할 구성이 포함된 MachineConfig 파일 99-worker-chrony.yaml을 생성합니다.

    $ butane 99-worker-chrony.bu -o 99-worker-chrony.yaml
  3. 다음 두 가지 방법 중 하나로 설정을 적용하십시오.

    • 클러스터가 아직 실행되지 않은 경우 매니페스트 파일을 생성한 후 <installation_directory>/openshift 디렉터리에 MachineConfig 개체 파일을 추가한 다음 클러스터를 계속 작성합니다.
    • 클러스터가 이미 실행중인 경우 다음과 같은 파일을 적용합니다.

      $ oc apply -f ./99-worker-chrony.yaml

3.2.2. chrony 타임 서비스 비활성화

MachineConfig CR(사용자 정의 리소스)을 사용하여 특정 역할이 있는 노드의 chrony 타임 서비스 (chronyd)를 비활성화할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

  1. 지정된 노드 역할에 대해 chronyd를 비활성화하는 MachineConfig CR을 만듭니다.

    1. 다음 YAML을 disable-chronyd.yaml 파일에 저장합니다.

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        labels:
          machineconfiguration.openshift.io/role: <node_role> 1
        name: disable-chronyd
      spec:
        config:
          ignition:
            version: 3.2.0
          systemd:
            units:
              - contents: |
                  [Unit]
                  Description=NTP client/server
                  Documentation=man:chronyd(8) man:chrony.conf(5)
                  After=ntpdate.service sntp.service ntpd.service
                  Conflicts=ntpd.service systemd-timesyncd.service
                  ConditionCapability=CAP_SYS_TIME
                  [Service]
                  Type=forking
                  PIDFile=/run/chrony/chronyd.pid
                  EnvironmentFile=-/etc/sysconfig/chronyd
                  ExecStart=/usr/sbin/chronyd $OPTIONS
                  ExecStartPost=/usr/libexec/chrony-helper update-daemon
                  PrivateTmp=yes
                  ProtectHome=yes
                  ProtectSystem=full
                  [Install]
                  WantedBy=multi-user.target
                enabled: false
                name: "chronyd.service"
      1
      chronyd를 비활성화하려는 노드 역할(예: master)입니다.
    2. 다음 명령을 실행하여 MachineConfig CR을 생성합니다.

      $ oc create -f disable-chronyd.yaml

3.2.3. 노드에 커널 인수 추가

특별한 경우에는 클러스터 노드 세트에 커널 인수를 추가해야 할 수 있습니다. 이 작업을 수행할 때 주의해야 하며 먼저 설정된 인수의 영향을 명확하게 이해하고 있어야합니다.

주의

커널 인수를 잘못 사용하면 시스템이 부팅되지 않을 수 있습니다.

설정할 수 있는 커널 인수의 예는 다음과 같습니다.

  • enforcing=0: SELinux(Security Enhanced Linux)를 허용 모드에서 실행하도록 구성합니다. 허용 모드에서는 SELinux가 개체에 레이블을 지정하고 로그에 액세스 거부 항목을 내보내는 등 로드된 보안 정책을 적용하는 것처럼 동작하지만 실제로는 어떤 작업도 거부하지 않습니다. 프로덕션 시스템에는 지원되지 않지만 허용 모드는 디버깅에 유용할 수 있습니다.
  • nosmt: 커널에서 대칭 멀티 스레딩 (SMT)을 비활성화합니다. 멀티 스레딩은 각 CPU마다 여러 개의 논리 스레드를 허용합니다. 멀티 테넌트 환경에서 nosmt를 사용하여 잠재적인 크로스 스레드 공격 위험을 줄일 수 있습니다. SMT를 비활성화하는 것은 기본적으로 성능보다는 보안을 중요시하여 선택하는 것과 같습니다.

커널 인수 목록 및 설명은 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:
      config:
        ignition:
          version: 3.2.0
      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.22.1
    ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.22.1
    ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.22.1
    ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.22.1
    ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.22.1
    ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.22.1

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

  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 인수가 다른 커널 인수에 추가된 것을 확인할 수 있습니다.

3.2.4. RHCOS에서 커널 인수로 다중 경로 활성화

RHCOS(Red Hat Enterprise Linux CoreOS)는 기본 디스크에서 다중 경로를 지원하므로 하드웨어 장애에 대한 탄력성이 강화된 호스트 가용성을 높일 수 있습니다. 설치 후 지원은 머신 구성을 통해 다중 경로를 활성화하여 사용할 수 있습니다.

중요

설치 중에 다중 경로를 활성화하는 것은 OpenShift Container Platform 4.8 이상에서 프로비저닝된 노드에 권장됩니다. I/O에서 최적화된 경로로 인해 I/O 시스템 오류가 발생하는 설정에서 설치 시 멀티패스를 활성화해야 합니다. 설치 시 다중 경로를 활성화하는 방법에 대한 자세한 내용은 베어 메탈에 설치 문서의 "RHCOS에서 커널 인수를 사용하여 다중 경로 활성화"를 참조하십시오.

중요

IBM Z 및 LinuxONE에서는 설치 중에 클러스터를 구성하는 경우에만 다중 경로를 활성화할 수 있습니다. 자세한 내용은 IBM Z 및 LinuxONE에 z/VM으로 클러스터 설치의 "RHCOS 설치 및 OpenShift Container Platform 부트스트랩 프로세스 시작"을 참조하십시오.

사전 요구 사항

  • OpenShift Container Platform 클러스터 (버전 4.7 이상)가 실행되고 있어야 합니다.
  • 관리 권한이 있는 사용자로 클러스터에 로그인했습니다.
  • 멀티패스에 디스크가 활성화되었는지 확인했습니다. 멀티패스는 HBA 어댑터를 통해 SAN에 연결된 호스트에서만 지원됩니다.

절차

  1. 컨트롤 플레인 노드에서 다중 경로 설치 후 활성화하려면 다음을 수행합니다.

    • 다음과 같이 클러스터에 master 레이블를 추가하도록 지시하고 다중 경로 커널 인수를 식별하는 99-master-kargs-mpath.yaml과 같은 머신 구성 파일을 만듭니다.

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        labels:
          machineconfiguration.openshift.io/role: "master"
        name: 99-master-kargs-mpath
      spec:
        kernelArguments:
          - 'rd.multipath=default'
          - 'root=/dev/disk/by-label/dm-mpath-root'
  2. 작업자 노드에서 다중 경로 설치 후 활성화하려면 다음을 수행합니다.

    • 다음과 같은 99-worker-kargs-mpath.yaml 과 같은 머신 구성 파일을 생성하여 클러스터에 worker 레이블을 추가하고 다중 경로 커널 인수를 식별합니다.

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        labels:
          machineconfiguration.openshift.io/role: "worker"
        name: 99-worker-kargs-mpath
      spec:
        kernelArguments:
          - 'rd.multipath=default'
          - 'root=/dev/disk/by-label/dm-mpath-root'
  3. 이전에 작성한 마스터 또는 작업자 YAML 파일을 사용하여 새 머신 구성을 생성합니다.

    $ oc create -f ./99-worker-kargs-mpath.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
    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-kargs-mpath                              52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             105s
    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.22.1
    ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.22.1
    ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.22.1
    ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.22.1
    ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.22.1
    ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.22.1

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

  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
    ...
    rd.multipath=default root=/dev/disk/by-label/dm-mpath-root
    ...
    
    sh-4.2# exit

    추가된 커널 인수가 표시되어야 합니다.

추가 리소스

3.2.5. 노드에 실시간 커널 추가

일부 OpenShift Container Platform 워크로드에는 높은 수준의 결정이 필요합니다. Linux는 실시간 운영 체제가 아니지만 Linux 실시간 커널에는 운영 체제에 실시간 기능을 제공하는 선점 형 스케줄러가 포함되어 있습니다.

OpenShift Container Platform 워크로드에 이러한 실시간 기능이 필요한 경우 머신을 Linux 실시간 커널로 전환할 수 있습니다. OpenShift Container Platform, 4.9의 경우 MachineConfig 오브젝트를 사용하여 이러한 전환을 수행할 수 있습니다. 머신 구성 kernelType 설정을 realtime으로 변경하는 것처럼 간단하지만 변경을 수행하기 전에 몇 가지 고려해야 할 사항이 있습니다.

  • 현재 실시간 커널은 작업자 노드에서만 지원되며 RAN (Radio Access Network) 사용만 지원됩니다.
  • 다음 단계는 Red Hat Enterprise Linux for Real Time 8에서 인증 된 시스템을 사용하는 베어 메탈 설치에 완전히 지원됩니다.
  • OpenShift Container Platform에서 실시간 지원은 특정 서브스크립션으로 제한됩니다.
  • 다음 단계는 Google Cloud Platform에서의 사용도 지원됩니다.

전제 조건

  • 실행중인 OpenShift Container Platform 클러스터 (버전 4.4 이상)가 있어야합니다.
  • 관리 권한이 있는 사용자로 클러스터에 로그인합니다.

절차

  1. 실시간 커널의 머신 구성을 만듭니다. realtime 커널 유형의 MachineConfig 개체가 포함된 YAML 파일 (예: 99-worker-realtime.yaml)을 만듭니다. 다음 예에서는 모든 작업자 노드에 대해 실시간 커널을 사용하도록 클러스터에 지시합니다.

    $ cat << EOF > 99-worker-realtime.yaml
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: "worker"
      name: 99-worker-realtime
    spec:
      kernelType: realtime
    EOF
  2. 머신 구성을 클러스터에 추가합니다. 다음을 입력하여 머신 구성을 클러스터에 추가합니다.

    $ oc create -f 99-worker-realtime.yaml
  3. 실시간 커널을 확인합니다 : 영향을 받는 각 노드가 재부팅되면 클러스터에 로그인하고 다음 명령을 실행하여 실시간 커널이 구성된 노드 세트의 일반 커널을 대체하고 있는지 확인합니다.

    $ oc get nodes

    출력 예

    NAME                                        STATUS  ROLES    AGE   VERSION
    ip-10-0-143-147.us-east-2.compute.internal  Ready   worker   103m  v1.22.1
    ip-10-0-146-92.us-east-2.compute.internal   Ready   worker   101m  v1.22.1
    ip-10-0-169-2.us-east-2.compute.internal    Ready   worker   102m  v1.22.1

    $ oc debug node/ip-10-0-143-147.us-east-2.compute.internal

    출력 예

    Starting pod/ip-10-0-143-147us-east-2computeinternal-debug ...
    To use host binaries, run `chroot /host`
    
    sh-4.4# uname -a
    Linux <worker_node> 4.18.0-147.3.1.rt24.96.el8_1.x86_64 #1 SMP PREEMPT RT
            Wed Nov 27 18:29:55 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

    커널 이름에는 rt 및 "PREEMPT RT"라는 텍스트가 포함되어 이것이 실시간 커널임을 나타냅니다.

  4. 일반 커널로 돌아가려면 MachineConfig 객체를 삭제합니다.

    $ oc delete -f 99-worker-realtime.yaml

3.2.6. journald 설정 구성

OpenShift Container Platform 노드에서 journald 서비스 설정을 구성해야하는 경우 적절한 구성 파일을 수정하고 해당 파일을 머신 구성으로 적절한 노드 풀에 전달하여 이를 수행할 수 있습니다.

이 프로세스에서는 /etc/systemd/journald.conf 파일에서 journald 속도 제한 설정을 수정하고 이를 작업자 노드에 적용하는 방법을 설명합니다. 해당 파일을 사용하는 방법에 대한 정보는 journald.conf man 페이지를 참조하십시오.

사전 요구 사항

  • 실행 중인 OpenShift Container Platform 클러스터가 있어야 합니다.
  • 관리 권한이 있는 사용자로 클러스터에 로그인합니다.

절차

  1. 필요한 설정과 함께 /etc/systemd/journald.conf 파일을 포함하는 Butane 구성 파일 40-worker-custom-journald.bu를 만듭니다.

    참고

    Butane에 대한 자세한 내용은 “Butane 을 사용하여 머신 구성 생성”을 참조하십시오.

    variant: openshift
    version: 4.9.0
    metadata:
      name: 40-worker-custom-journald
      labels:
        machineconfiguration.openshift.io/role: worker
    storage:
      files:
      - path: /etc/systemd/journald.conf
        mode: 0644
        overwrite: true
        contents:
          inline: |
            # Disable rate limiting
            RateLimitInterval=1s
            RateLimitBurst=10000
            Storage=volatile
            Compress=no
            MaxRetentionSec=30s
  2. Butane을 사용하여 작업자 노드로 전달할 구성이 포함된 MachineConfig 개체 파일 40-worker-custom-journald.yaml을 생성합니다.

    $ butane 40-worker-custom-journald.bu -o 40-worker-custom-journald.yaml
  3. 머신 구성을 풀에 적용합니다.

    $ oc apply -f 40-worker-custom-journald.yaml
  4. 새 머신 구성이 적용되고 노드가 저하된 상태에 있는지 확인합니다. 이 작업을 수행하는 데 몇 분 정도 걸릴 수 있습니다. 각 노드에 새 머신 구성이 성공적으로 적용되어 작업자 풀에 진행중인 업데이트가 표시됩니다.

    $ oc get machineconfigpool
    NAME   CONFIG             UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
    master rendered-master-35 True    False    False    3            3                 3                   0                    34m
    worker rendered-worker-d8 False   True     False    3            1                 1                   0                    34m
  5. 변경 사항이 적용되었는지 확인하려면 작업자 노드에 로그인합니다.

    $ oc get node | grep worker
    ip-10-0-0-1.us-east-2.compute.internal   Ready    worker   39m   v0.0.0-master+$Format:%h$
    $ oc debug node/ip-10-0-0-1.us-east-2.compute.internal
    Starting pod/ip-10-0-141-142us-east-2computeinternal-debug ...
    ...
    sh-4.2# chroot /host
    sh-4.4# cat /etc/systemd/journald.conf
    # Disable rate limiting
    RateLimitInterval=1s
    RateLimitBurst=10000
    Storage=volatile
    Compress=no
    MaxRetentionSec=30s
    sh-4.4# exit

3.2.7. RHCOS에 확장 기능 추가

RHCOS는 모든 플랫폼에서 OpenShift Container Platform 클러스터에 공통적인 기능 세트를 제공하도록 설계된 최소한의 컨테이너 지향 RHEL 운영 체제입니다. RHCOS 시스템에 소프트웨어 패키지를 추가하는 것은 일반적으로 권장되지 않지만 MCO는 RHCOS 노드에 최소한의 기능 세트를 추가하는 데 사용할 수있는 extensions 기능을 제공합니다.

현재 다음 확장 기능을 사용할 수 있습니다.

  • usbguard: usbguard 확장 기능을 추가하면 간섭적인 USB 장치의 공격으로부터 RHCOS 시스템을 보호합니다. 자세한 내용은 USBGuard를 참조하십시오.

다음 프로세서에서는 머신 구성을 사용하여 RHCOS 노드에 하나 이상의 확장 기능을 추가하는 방법을 설명합니다.

사전 요구 사항

  • 실행중인 OpenShift Container Platform 클러스터 (버전 4.6 이상)가 있어야합니다.
  • 관리 권한이 있는 사용자로 클러스터에 로그인합니다.

절차

  1. 확장 기능을 위한 머신 구성을 만듭니다. MachineConfig extensions 개체를 포함하는 YAML 파일 (예 : 80-extensions.yaml)을 만듭니다. 이 예에서는 클러스터에 usbguard 확장 기능을 추가하도록 지시합니다.

    $ cat << EOF > 80-extensions.yaml
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 80-worker-extensions
    spec:
      config:
        ignition:
          version: 3.2.0
      extensions:
        - usbguard
    EOF
  2. 머신 구성을 클러스터에 추가합니다. 다음을 입력하여 머신 구성을 클러스터에 추가합니다.

    $ oc create -f 80-extensions.yaml

    이렇게하면 모든 작업자 노드에 usbguard의 rpm 패키지가 설치됩니다.

  3. 확장 기능이 적용되었는지 확인합니다.

    $ oc get machineconfig 80-worker-extensions

    출력 예

    NAME                 GENERATEDBYCONTROLLER IGNITIONVERSION AGE
    80-worker-extensions                       3.2.0           57s

  4. 새 머신 구성이 적용되고 노드가 저하된 상태에 있는지 확인합니다. 이 작업을 수행하는 데 몇 분 정도 걸릴 수 있습니다. 각 머신에 새 머신 구성이 성공적으로 적용되면 작업자 풀에 진행중인 업데이트가 표시됩니다.

    $ oc get machineconfigpool

    출력 예

    NAME   CONFIG             UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
    master rendered-master-35 True    False    False    3            3                 3                   0                    34m
    worker rendered-worker-d8 False   True     False    3            1                 1                   0                    34m

  5. 확장 기능을 확인합니다. 확장 기능이 적용되었는지 확인하려면 다음을 실행하십시오.

    $ oc get node | grep worker

    출력 예

    NAME                                        STATUS  ROLES    AGE   VERSION
    ip-10-0-169-2.us-east-2.compute.internal    Ready   worker   102m  v1.22.1

    $ oc debug node/ip-10-0-169-2.us-east-2.compute.internal

    출력 예

    ...
    To use host binaries, run `chroot /host`
    sh-4.4# chroot /host
    sh-4.4# rpm -q usbguard
    usbguard-0.7.4-4.el8.x86_64.rpm

3.2.8. 머신 구성 매니페스트에서 사용자 정의 펌웨어 Blob 로드

/usr/lib 에서 펌웨어 Blob의 기본 위치는 읽기 전용이므로 검색 경로를 업데이트하여 사용자 지정 펌웨어 Blob을 찾을 수 있습니다. 이를 통해 RHCOS에서 Blob을 관리하지 않는 경우 머신 구성 매니페스트에 로컬 펌웨어 Blob을 로드할 수 있습니다.

절차

  1. 검색 경로를 업데이트하여 로컬 스토리지에 루트 소유 및 쓰기 가능하도록 Butane 구성 파일 98-worker-firmware-blob.bu 를 생성합니다. 다음 예제에서는 로컬 워크스테이션의 사용자 지정 Blob 파일을 /var/lib/firmware 아래의 노드에 배치합니다.

    참고

    Butane에 대한 자세한 내용은 “Butane 을 사용하여 머신 구성 생성”을 참조하십시오.

    사용자 정의 펌웨어 Blob의 Butane 구성 파일

    variant: openshift
    version: 4.9.0
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 98-worker-firmware-blob
    storage:
      files:
      - path: /var/lib/firmware/<package_name> 1
        contents:
          local: <package_name> 2
        mode: 0644 3
    openshift:
      kernel_arguments:
        - 'firmware_class.path=/var/lib/firmware' 4

    1
    펌웨어 패키지가 복사되는 노드에서 경로를 설정합니다.
    2
    Butane을 실행하는 시스템의 로컬 파일 디렉터리에서 읽은 내용이 포함된 파일을 지정합니다. 로컬 파일의 경로는 다음 단계에서 Butane과 함께 -- files-dir 옵션을 사용하여 지정해야 하는 files-dir 디렉터리를 기준으로 합니다.
    3
    RHCOS 노드에서 파일에 대한 권한을 설정합니다. 0644 권한을 설정하는 것이 좋습니다.
    4
    firmware_class.path 매개 변수는 로컬 워크스테이션에서 노드의 루트 파일 시스템으로 복사된 사용자 지정 펌웨어 Blob을 찾을 위치에 대한 커널 검색 경로를 사용자 지정합니다. 이 예에서는 /var/lib/firmware 를 사용자 지정 경로로 사용합니다.
  2. Butane을 실행하여 로컬 워크스테이션 98-worker-firmware-blob.yaml 에서 펌웨어 Blob의 사본을 사용하는 MachineConfig 오브젝트 파일을 생성합니다. 펌웨어 Blob에는 노드로 전달할 구성이 포함되어 있습니다. 다음 예제에서는 --files-dir 옵션을 사용하여 로컬 파일 또는 파일이 있는 워크스테이션의 디렉터리를 지정합니다.

    $ butane 98-worker-firmware-blob.bu -o 98-worker-firmware-blob.yaml --files-dir <directory_including_package_name>
  3. 다음 두 가지 방법 중 하나로 노드에 구성을 적용합니다.

    • 클러스터가 아직 실행되지 않은 경우 매니페스트 파일을 생성한 후 <installation_directory>/openshift 디렉터리에 MachineConfig 개체 파일을 추가한 다음 클러스터를 계속 작성합니다.
    • 클러스터가 이미 실행중인 경우 다음과 같은 파일을 적용합니다.

      $ oc apply -f 98-worker-firmware-blob.yaml

      머신 구성을 완료하기 위해 MachineConfig 오브젝트 YAML 파일이 생성됩니다.

  4. 향후 MachineConfig 오브젝트를 업데이트해야 하는 경우 Butane 구성을 저장합니다.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.