3.2. MachineConfig 개체를 사용하여 노드 구성
이 섹션의 작업을 통해 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)에서 사용하는 시간 서버 및 관련 구성을 설정할 수 있습니다.
프로세스
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
- 컨트롤 플레인 노드에서 두 위치에 있는
master를worker로 대체합니다. - 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 서버 중 하나를 지정할 수 있습니다.
Butane을 사용하여 노드에 전달할 구성이 포함된
MachineConfig파일99-worker-chrony.yaml을 생성합니다.$ butane 99-worker-chrony.bu -o 99-worker-chrony.yaml
다음 두 가지 방법 중 하나로 설정을 적용하십시오.
-
클러스터가 아직 실행되지 않은 경우 매니페스트 파일을 생성한 후
<installation_directory>/openshift디렉터리에MachineConfig개체 파일을 추가한 다음 클러스터를 계속 작성합니다. 클러스터가 이미 실행중인 경우 다음과 같은 파일을 적용합니다.
$ oc apply -f ./99-worker-chrony.yaml
-
클러스터가 아직 실행되지 않은 경우 매니페스트 파일을 생성한 후
추가 리소스
3.2.2. chrony 타임 서비스 비활성화
MachineConfig CR(사용자 정의 리소스)을 사용하여 특정 역할이 있는 노드의 chrony 타임 서비스 (chronyd)를 비활성화할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. -
cluster-admin권한이 있는 사용자로 로그인합니다.
절차
지정된 노드 역할에 대해
chronyd를 비활성화하는MachineConfigCR을 만듭니다.다음 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)입니다.
다음 명령을 실행하여
MachineConfigCR을 생성합니다.$ 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 클러스터에 대한 관리자 권한을 보유하고 있어야 합니다.
프로세스
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: config: ignition: version: 3.2.0 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.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
변경 사항이 적용되어 있기 때문에 각 작업자 노드의 예약이 비활성화되어 있음을 알 수 있습니다.
작업자 노드 중 하나로 이동하여 커널 명령 행 인수 (호스트의
/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에 연결된 호스트에서만 지원됩니다.
절차
컨트롤 플레인 노드에서 다중 경로 설치 후 활성화하려면 다음을 수행합니다.
다음과 같이 클러스터에
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'
작업자 노드에서 다중 경로 설치 후 활성화하려면 다음을 수행합니다.
다음과 같은
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'
이전에 작성한 마스터 또는 작업자 YAML 파일을 사용하여 새 머신 구성을 생성합니다.
$ oc create -f ./99-worker-kargs-mpath.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 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
노드를 확인합니다.
$ 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
변경 사항이 적용되어 있기 때문에 각 작업자 노드의 예약이 비활성화되어 있음을 알 수 있습니다.
작업자 노드 중 하나로 이동하여 커널 명령 행 인수 (호스트의
/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
추가된 커널 인수가 표시되어야 합니다.
추가 리소스
- 설치 시간 동안 다중 경로를 활성화하는 방법에 대한 자세한 내용은 RHCOS에서 커널 인수를 사용하여 다중 경로 활성화를 참조하십시오.
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 이상)가 있어야합니다.
- 관리 권한이 있는 사용자로 클러스터에 로그인합니다.
절차
실시간 커널의 머신 구성을 만듭니다.
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머신 구성을 클러스터에 추가합니다. 다음을 입력하여 머신 구성을 클러스터에 추가합니다.
$ oc create -f 99-worker-realtime.yaml
실시간 커널을 확인합니다 : 영향을 받는 각 노드가 재부팅되면 클러스터에 로그인하고 다음 명령을 실행하여 실시간 커널이 구성된 노드 세트의 일반 커널을 대체하고 있는지 확인합니다.
$ 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"라는 텍스트가 포함되어 이것이 실시간 커널임을 나타냅니다.일반 커널로 돌아가려면
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 클러스터가 있어야 합니다.
- 관리 권한이 있는 사용자로 클러스터에 로그인합니다.
절차
필요한 설정과 함께
/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=30sButane을 사용하여 작업자 노드로 전달할 구성이 포함된
MachineConfig개체 파일40-worker-custom-journald.yaml을 생성합니다.$ butane 40-worker-custom-journald.bu -o 40-worker-custom-journald.yaml
머신 구성을 풀에 적용합니다.
$ oc apply -f 40-worker-custom-journald.yaml
새 머신 구성이 적용되고 노드가 저하된 상태에 있는지 확인합니다. 이 작업을 수행하는 데 몇 분 정도 걸릴 수 있습니다. 각 노드에 새 머신 구성이 성공적으로 적용되어 작업자 풀에 진행중인 업데이트가 표시됩니다.
$ 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
변경 사항이 적용되었는지 확인하려면 작업자 노드에 로그인합니다.
$ 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 이상)가 있어야합니다.
- 관리 권한이 있는 사용자로 클러스터에 로그인합니다.
절차
확장 기능을 위한 머신 구성을 만듭니다.
MachineConfigextensions개체를 포함하는 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머신 구성을 클러스터에 추가합니다. 다음을 입력하여 머신 구성을 클러스터에 추가합니다.
$ oc create -f 80-extensions.yaml
이렇게하면 모든 작업자 노드에
usbguard의 rpm 패키지가 설치됩니다.확장 기능이 적용되었는지 확인합니다.
$ oc get machineconfig 80-worker-extensions
출력 예
NAME GENERATEDBYCONTROLLER IGNITIONVERSION AGE 80-worker-extensions 3.2.0 57s
새 머신 구성이 적용되고 노드가 저하된 상태에 있는지 확인합니다. 이 작업을 수행하는 데 몇 분 정도 걸릴 수 있습니다. 각 머신에 새 머신 구성이 성공적으로 적용되면 작업자 풀에 진행중인 업데이트가 표시됩니다.
$ 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
확장 기능을 확인합니다. 확장 기능이 적용되었는지 확인하려면 다음을 실행하십시오.
$ 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을 로드할 수 있습니다.
절차
검색 경로를 업데이트하여 로컬 스토리지에 루트 소유 및 쓰기 가능하도록 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를 사용자 지정 경로로 사용합니다.
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>
다음 두 가지 방법 중 하나로 노드에 구성을 적용합니다.
-
클러스터가 아직 실행되지 않은 경우 매니페스트 파일을 생성한 후
<installation_directory>/openshift디렉터리에MachineConfig개체 파일을 추가한 다음 클러스터를 계속 작성합니다. 클러스터가 이미 실행중인 경우 다음과 같은 파일을 적용합니다.
$ oc apply -f 98-worker-firmware-blob.yaml
머신 구성을 완료하기 위해
MachineConfig오브젝트 YAML 파일이 생성됩니다.
-
클러스터가 아직 실행되지 않은 경우 매니페스트 파일을 생성한 후
-
향후
MachineConfig오브젝트를 업데이트해야 하는 경우 Butane 구성을 저장합니다.
추가 리소스
