3.2. 노드의 사용자 정의
OpenShift Container Platform 노드를 직접 변경하는 것은 권장되지 않지만 필요에 따라 낮은 수준의 보안, 네트워킹 또는 성능 기능을 구현해야하는 경우가 있습니다. OpenShift Container Platform 노드를 직접 변경하려면 다음을 수행하십시오.
-
Openshift-install
중 클러스터를 시작하기 위해 매니페스트 파일에 포함된 MachineConfig를 생성합니다. - Machine Config Operator를 통해 OpenShift Container Platform 노드에 전달되는 MachineConfig를 생성합니다.
다음 섹션에서는 이러한 방식으로 노드에서 설정할 수 있는 기능에 대해 설명합니다.
3.2.1. day-1 커널 매개 변수 추가
day-2 활동으로 커널 매개 변수를 수정하는 것이 바람직하지만 초기 클러스터 설치 중에 모든 마스터 또는 작업자 노드에 커널 매개 변수를 추가할 수 있습니다. 시스템이 처음으로 부팅되기 전에 적용되도록 클러스터 설치 중에 커널 매개 변수를 추가해야하는 이유는 다음과 같습니다.
- SELinux와 같은 기능을 비활성화하여 이 기능이 시스템에 영향을 미치지 않도록할 필요가 있는 경우
- 시스템을 시작하기 전에 몇 가지 낮은 수준의 네트워크 설정을 수행해야하는 경우
마스터 노드 또는 작업자 노드에 커널 매개 변수를 추가하기 위해 MachineConfig 객체를 생성하고 해당 객체를 클러스터 설정 중에 Ignition에서 사용하는 매니페스트 파일 세트에 삽입할 수 있습니다.
부팅시 RHEL 8 커널에 전달할 수 있는 매개 변수 목록은 Kernel.org 커널 매개 변수를 참조하십시오. 초기 OpenShift Container Platform 설치를 완료하기 위해 필요한 경우 이 절차를 사용하여 커널 매개 변수를 추가하는 것이 좋습니다.
프로세스
클러스터에 대한 Kubernetes 매니페스트를 생성합니다.
$ ./openshift-install create manifests --dir=<installation_directory>
- 커널 매개 변수를 작업자 또는 마스터 노드에 추가할지 여부를 결정합니다.
openshift
디렉토리에서 파일 (예:99-openshift-machineconfig-master-kargs.yaml
)을 작성하여 커널 설정을 추가할 MachineConfig 객체를 정의합니다. 다음 예제에서는loglevel=7
커널 매개 변수를 마스터 노드에 추가합니다.$ cat << EOF > 99-openshift-machineconfig-master-kargs.yaml apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: master name: 99-openshift-machineconfig-master-kargs spec: kernelArguments: - 'loglevel=7' EOF
커널 매개 변수를 작업자 노드에 추가하는 경우
master
를worker
로 변경할 수 있습니다. 마스터 및 작업자 노드 모두에 추가할 별도의 YAML 파일을 생성합니다.
이제 계속해서 클러스터를 만들 수 있습니다.
3.2.2. 노드에 커널 모듈 추가
대부분의 일반적인 하드웨어의 경우 컴퓨터가 시작되면 Linux 커널에 이러한 하드웨어를 사용하는 데 필요한 장치 드라이버 모듈이 포함됩니다. 그러나 일부 하드웨어의 경우 해당 모듈은 Linux에서 제공되지 않습니다. 따라서 각 호스트 컴퓨터에 대해 이러한 모듈을 제공하는 방법을 찾아야합니다. 이 단계에서는 OpenShift Container Platform 클러스터 노드에 대해 이를 수행하는 방법을 설명합니다.
이 프로세스에 따라 커널 모듈을 처음 배포할 때 현재 커널에서 모듈을 사용할 수 있게 됩니다. 새 커널이 설치되면 kmods-via-containers 소프트웨어가 다시 빌드되고 모듈이 배포되어 새 커널과 호환되는 버전의 모듈을 사용할 수 있습니다.
이 기능이 각 노드에서 모듈을 최신 상태로 유지하는 방법은 다음과 같습니다.
- 새 커널이 설치되었는지 감지하기 위해 부팅시 시작되는 각 노드에 systemd 서비스를 추가합니다.
- 새로운 커널이 감지되면 서비스는 모듈을 다시 빌드하여 커널에 설치합니다.
이 단계에 필요한 소프트웨어에 대한 자세한 내용은 kmods-via-containers github 사이트를 참조하십시오.
다음의 몇 가지 중요 사항에 유의하십시오.
- 이 단계는 기술 프리뷰입니다.
-
소프트웨어 툴과 샘플은 공식 RPM 형식으로 제공되지 않으며 현재 이 절차에 명시된 비공식
github.com
사이트에서만 구할 수 있습니다. - 이 절차를 통해 추가할 수 있는 타사 커널 모듈은 Red Hat에서 지원하지 않습니다.
-
이 절차에서는 커널 모듈을 빌드하는 데 필요한 소프트웨어가 RHEL 8 컨테이너에 배포됩니다. 노드가 새 커널을 가져 오면 각 노드에서 모듈이 자동으로 다시 빌드됩니다. 따라서 각 노드는 모듈을 다시 빌드하는 데 필요한 커널 및 관련 패키지가 포함된
yum
저장소에 액세스해야합니다. 해당 컨텐츠는 유효한 RHEL 서브스크립션을 통해 효과적으로 사용할 수 있습니다.
3.2.2.1. 커널 모듈 컨테이너 빌드 및 테스트
커널 모듈을 OpenShift Container Platform 클러스터에 배포하기 전에 별도의 RHEL 시스템에서 프로세스를 테스트할 수 있습니다. 커널 모듈의 소스 코드, KVC 프레임 워크 및 kmod-via-containers 소프트웨어를 수집합니다. 다음으로 모듈을 빌드하고 테스트합니다. RHEL 8 시스템에서 이를 수행하려면 다음 프로세스를 따르십시오.
프로세스
RHEL 8 시스템을 가져온 후 등록하고 구독하십시오.
# subscription-manager register Username: yourname Password: *************** # subscription-manager attach --auto
소프트웨어 및 컨테이너를 빌드하는 데 필요한 소프트웨어를 설치하십시오.
# yum install podman make git -y
kmod-via-containers 리포지토리를 복제합니다.
$ mkdir kmods; cd kmods $ git clone https://github.com/kmods-via-containers/kmods-via-containers
RHEL 8 빌드 호스트에 KVC 프레임 워크 인스턴스를 설치하여 모듈을 테스트합니다. kmods-via-container systemd 서비스가 추가되어 로드됩니다.
$ cd kmods-via-containers/ $ sudo make install $ sudo systemctl daemon-reload
커널 모듈의 소스 코드를 가져옵니다. 소스 코드는 제어할 수 없지만 다른 사람이 제공하는 타사 모듈을 빌드하는 데 사용될 수 있습니다. 다음과 같이 시스템에 복제할 수있는
kvc-simple-kmod
예제에 표시된 내용과 유사한 내용이 필요합니다.$ cd .. $ git clone https://github.com/kmods-via-containers/kvc-simple-kmod
다음과 같이 설정 파일
simple-kmod.conf
을 편집하고 Dockerfile의 이름을Dockerfile.rhel
로 변경합니다.$ cd kvc-simple-kmod $ cat simple-kmod.conf KMOD_CONTAINER_BUILD_CONTEXT="https://github.com/kmods-via-containers/kvc-simple-kmod.git" KMOD_CONTAINER_BUILD_FILE=Dockerfile.rhel KMOD_SOFTWARE_VERSION=dd1a7d4 KMOD_NAMES="simple-kmod simple-procfs-kmod"
커널 모듈의
kmods-via-containers @ .service
인스턴스 (이 예제에서는simple-kmod)
를 만들고 이를 활성화합니다.$ sudo make install $ sudo kmods-via-containers build simple-kmod $(uname -r)
systemd 서비스를 활성화하고 시작한 다음 상태를 확인하십시오.
$ sudo systemctl enable kmods-via-containers@simple-kmod.service $ sudo systemctl start kmods-via-containers@simple-kmod.service $ sudo systemctl status kmods-via-containers@simple-kmod.service ● kmods-via-containers@simple-kmod.service - Kmods Via Containers - simple-kmod Loaded: loaded (/etc/systemd/system/kmods-via-containers@.service; enabled; vendor preset: disabled) Active: active (exited) since Sun 2020-01-12 23:49:49 EST; 5s ago...
커널 모듈이 로드되었는지 확인하려면
lsmod
명령을 사용하여 모듈을 나열하십시오.$ lsmod | grep simple_ simple_procfs_kmod 16384 0 simple_kmod 16384 0
simple-kmod 예제에는 작동 여부를 테스트하는 몇 가지 다른 방법이 있습니다.
dmesg
를 사용하여 커널 링 버퍼에 "Hello world"메시지를 찾으십시오.$ dmesg | grep 'Hello world' [ 6420.761332] Hello world from simple_kmod.
/proc
에서simple-procfs-kmod
의 값을 확인합니다.$ sudo cat /proc/simple-procfs-kmod simple-procfs-kmod number = 0
spkut 명령을 실행하여 모듈에 대한 자세한 정보를 가져옵니다.
$ sudo spkut 44 KVC: wrapper simple-kmod for 4.18.0-147.3.1.el8_1.x86_64 Running userspace wrapper using the kernel module container... + podman run -i --rm --privileged simple-kmod-dd1a7d4:4.18.0-147.3.1.el8_1.x86_64 spkut 44 simple-procfs-kmod number = 0 simple-procfs-kmod number = 44
시스템이 부팅될 때 이 서비스는 새 커널이 실행 중인지를 확인합니다. 새 커널이 있으면 서비스는 새 버전의 커널 모듈을 빌드한 다음 로드합니다. 모듈이 이미 구축 된 경우 이를 로드합니다.
3.2.2.2. OpenShift Container Platform에 커널 모듈 프로비저닝
OpenShift Container Platform 클러스터를 처음 부팅할 때 커널 모듈을 활성화할 필요가 있는지 여부에 따라 다음 두 가지 방법 중 하나로 커널 모듈을 배포하도록 설정할 수 있습니다.
-
클러스터 설치시 커널 모듈 프로비저닝 (day-1): MachineConfig를 통해 컨텐츠를 작성하고 매니페스트 파일 세트와 함께
openshift-install
에 제공할 수 있습니다. - Machine Config Operator를 통해 커널 모듈 프로비저닝 (day-2): 커널 모듈을 추가하기 위해 클러스터가 가동 될 때까지 대기할 경우 MCO (Machine Config Operator)를 통해 커널 모듈 소프트웨어를 배포할 수 있습니다.
두 경우 모두 새 커널이 감지되면 각 노드에서 커널 소프트웨어 패키지 및 관련 소프트웨어 패키지를 가져올 수 있어야 합니다. 해당 컨텐츠를 가져올 수 있도록 각 노드를 설정할 수있는 몇 가지 방법이 있습니다.
- 각 노드에 RHEL 인타이틀먼트를 제공합니다.
-
/ etc / pki / entitlement
디렉토리에서 기존 RHEL 호스트의 RHEL 인타이틀먼트를 취득하고 Ignition 설정을 빌드할 때 제공하는 다른 파일과 동일한 위치에 복사합니다. -
Dockerfile에서 커널 및 기타 패키지가 포함된
yum
저장소에 대한 포인터를 추가합니다. 여기에는 새로 설치된 커널과 일치해야하므로 새 커널 패키지가 포함되어 있어야합니다.
3.2.2.2.1. MachineConfig를 통한 커널 모듈 프로비저닝
MachineConfig로 커널 모듈 소프트웨어를 패키지하면 설치시 또는 Machine Config Operator를 통해 해당 소프트웨어를 작업자 또는 마스터 노드에 전달할 수 있습니다.
먼저 사용하려는 기본 Ignition 설정을 만듭니다 설치시 Ignition 설정에는 클러스터에서 core
사용자의 authorized_keys
파일에 추가할 ssh 공개 키가 포함됩니다. 나중에 MCO를 통해 MachineConfig를 추가하는 경우 ssh 공개키가 필요하지 않습니다. 두 가지 유형 모두 샘플 simple-kmod 서비스는 kmds-via-containers@simple-kmod.service
가 필요한 systemd 장치 파일을 만듭니다.
systemd 장치는 업스트림 버그에 대한 해결 방법이며 kmods-via-containers@simple-kmod.service
가 부팅시 시작되도록합니다.
RHEL 8 시스템을 가져온 후 등록합니다.
# subscription-manager register Username: yourname Password: *************** # subscription-manager attach --auto
소프트웨어를 빌드하는 데 필요한 소프트웨어를 설치합니다.
# yum install podman make git -y
systemd 장치 파일을 만들 Ignition 설정 파일을 만듭니다.
$ mkdir kmods; cd kmods $ cat <<EOF > ./baseconfig.ign { "ignition": { "version": "2.2.0" }, "passwd": { "users": [ { "name": "core", "groups": ["sudo"], "sshAuthorizedKeys": [ "ssh-rsa AAAA" ] } ] }, "systemd": { "units": [{ "name": "require-kvc-simple-kmod.service", "enabled": true, "contents": "[Unit]\nRequires=kmods-via-containers@simple-kmod.service\n[Service]\nType=oneshot\nExecStart=/usr/bin/true\n\n[Install]\nWantedBy=multi-user.target" }] } } EOF
참고openshift-install
중에 파일을 사용하려면 공개 SSH 키를baseconfig.ign
파일에 추가해야합니다. MCO를 통해 MachineConfig를 생성하는 경우 공개 SSH 키가 필요하지 않습니다.- 다음과 같은 기본 MCO YAML 스니펫을 만듭니다.
$ cat <<EOF > mc-base.yaml apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker name: 10-kvc-simple-kmod spec: config: EOF
+
mc-base.yaml
은 worker
노드에 커널 모듈을 배포하도록 설정되어 있습니다. 마스터 노드에 배포하려면 역할을 worker
에서 master
로 변경하십시오. 이 두 가지 작업을 수행하려면 여러유형의 배포에 서로 다른 파일 이름을 사용하여 전체 프로세스를 반복할 수 있습니다.
kmods-via-containers
소프트웨어를 가져옵니다:$ git clone https://github.com/kmods-via-containers/kmods-via-containers $ git clone https://github.com/kmods-via-containers/kvc-simple-kmod
-
모듈 소프트웨어를 가져옵니다. 이 예에서는
kvc-simple-kmod
가 사용됩니다. 이전에 복제된 리포지토리를 사용하여 fakeroot 디렉토리를 만들고 Ignition을 통해 전달할 파일을 이 디렉토리에 배치합니다.
$ FAKEROOT=$(mktemp -d) $ cd kmods-via-containers $ make install DESTDIR=${FAKEROOT}/usr/local CONFDIR=${FAKEROOT}/etc/ $ cd ../kvc-simple-kmod $ make install DESTDIR=${FAKEROOT}/usr/local CONFDIR=${FAKEROOT}/etc/
filetranspiler
라는 툴 및 종속 소프트웨어를 가져옵니다.$ cd .. $ sudo yum install -y python3 git clone https://github.com/ashcrow/filetranspiler.git
최종 MachineConfig YAML (
mc.yaml
)을 생성하고 이를 전달하려는 파일과 함께 기본 Ignition 설정, 기본 MachineConfig 및 fakeroot 디렉토리를 포함합니다.$ ./filetranspiler/filetranspile -i ./baseconfig.ign \ -f ${FAKEROOT} --format=yaml --dereference-symlinks \ | sed 's/^/ /' | (cat mc-base.yaml -) > 99-simple-kmod.yaml
클러스터가 아직 작동하지 않은 경우 매니페스트 파일을 생성하고 해당 파일을
openshift
디렉토리에 추가합니다. 클러스터가 이미 실행중인 경우 다음과 같이 파일을 적용합니다.$ oc create -f 99-simple-kmod.yaml
노드는
kmods-via-containers@simple-kmod.service
서비스를 시작하고 커널 모듈이 로드됩니다.커널 모듈이 로드되었는지 확인하려면
oc debug node / <openshift-node>
를 사용 후chroot / host를
사용하여 노드에 로그인할 수 있습니다. 모듈을 나열하려면lsmod
명령을 사용합니다.$ lsmod | grep simple_ simple_procfs_kmod 16384 0 simple_kmod 16384 0
3.2.3. 설치시 디스크 암호화
OpenShift Container Platform을 설치할 때 모든 마스터 및 작업자 노드에서 디스크 암호화를 활성화할 수 있습니다. 이는 다음과 같은 기능을 제공합니다:
- 설치 프로그램 프로비저닝 인프라 및 사용자 프로비저닝 인프라 배포에서 사용 가능
- RHCOS (Red Hat Enterprise Linux CoreOS) 시스템에서만 지원됨
- 매니페스트 설치 단계에서 디스크 암호화를 설정하여 첫 번째 부팅부터 디스크에 기록된 모든 데이터를 암호화함
-
루트 파일 시스템의 데이터만 암호화함 (
/
에서/ dev / mapper / coreos-luks-root
) - 사용자 개입없이 암호 제공 가능
- AES-256-CBC 암호화 사용
- 클러스터가 FIPS를 지원하도록 활성화해야 함
다음의 두 가지 암호화 모드가 지원됩니다.
- TPM v2: 기본 모드입니다. TPM v2는 암호를 보안 암호화 프로세서에 저장합니다. TPM v2 디스크 암호화를 구현하려면 아래 설명에 따라 Ignition 설정 파일을 만듭니다.
- Tang : Tang을 사용하여 클러스터를 암호화하려면 Tang 서버를 사용해야합니다. Clevis는 클라이언트 측에서 암호 해독을 구현합니다. Tang 암호화 모드는 베어 메탈 설치에만 지원됩니다.
클러스터 노드에 디스크 암호화를 사용하려면 다음 두 프로세스 중 하나를 수행하십시오.
3.2.3.1. TPM v2 디스크 암호화 활성화
다음 프로세스를 사용하여 OpenShift Container Platform 배포 중에 TPM v2 모드 디스크 암호화를 활성화합니다.
프로세스
- 각 노드의 BIOS에서 TPM v2 암호화를 활성화해야하는지 확인하십시오. 이는 대부분의 Dell 시스템에서 필요합니다. 컴퓨터 설명서를 확인하십시오.
클러스터에 대한 Kubernetes 매니페스트를 생성합니다.
$ ./openshift-install create manifests --dir=<installation_directory>
openshift
디렉토리에서 마스터 및/또는 작업자 파일을 작성하여 해당 노드의 디스크를 암호화하십시오. 이 두 파일의 예는 다음과 같습니다.$ cat << EOF > ./99-openshift-worker-tpmv2-encryption.yaml apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: name: worker-tpm labels: machineconfiguration.openshift.io/role: worker spec: config: ignition: version: 2.2.0 storage: files: - contents: source: data:text/plain;base64,e30K filesystem: root mode: 420 path: /etc/clevis.json EOF
$ cat << EOF > ./99-openshift-master-tpmv2-encryption.yaml apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: name: master-tpm labels: machineconfiguration.openshift.io/role: master spec: config: ignition: version: 2.2.0 storage: files: - contents: source: data:text/plain;base64,e30K filesystem: root mode: 420 path: /etc/clevis.json EOF
- YAML 파일의 백업 사본을 만듭니다. 클러스터를 만들 때 파일이 삭제되므로 백업을 수행해야합니다.
- 나머지 OpenShift Container Platform 배포를 계속합니다.
3.2.3.2. Tang 디스크 암호화 활성화
다음 프로세스를 사용하여 OpenShift Container Platform 배포 중에 Tang 모드 디스크 암호화를 활성화합니다.
프로세스
-
암호화 설정을 구성하고
openshift-install
을 실행하여 함께 작업할 클러스터 및oc
를 설치하기 위해 Red Hat Enterprise Linux 서버에 액세스합니다. - 기존 Tang 서버를 설정하거나 액세스합니다. 자세한 내용은 Network-bound disk encryption에서 참조하십시오. Tang에 표시하는 방법에 대한 자세한 내용은 Securing Automated Decryption New Cryptography and Techniques에서 참조하십시오.
-
클러스터에 대해 RHCOS 설치를 수행할 때 네트워크를 설정하기 위해 커널 인수를 추가합니다. 이 단계를 생략하면 두 번째 부팅이 실패합니다. 예를 들어 DHCP 네트워킹을 설정하려면
ip=dhcp
를 지정하거나 커널 명령 줄에 매개 변수를 추가할 때 정적 네트워크를 설정합니다. 지문을 생성합니다. clevis 패키지를 설치하십시오 (아직 설치되지 않은 경우). Tang 서버에서 지문을 생성합니다.
url
값을 Tang 서버 URL로 바꾸십시오.$ sudo yum install clevis -y $ echo nifty random wordwords \ | clevis-encrypt-tang \ '{"url":"https://tang.example.org"}' The advertisement contains the following signing keys: PLjNyRdGw03zlRoGjQYMahSZGu9 Do you wish to trust these keys? [ynYN] y eyJhbmc3SlRyMXpPenc3ajhEQ01tZVJiTi1oM...
Base64로 인코딩된 파일을 만들고 값을 새로 생성된 Tang 서버 (
url
) URL 및 지문 (thp
)으로 바꿉니다.$ (cat <<EOM { "url": "https://tang.example.com", "thp": "PLjNyRdGw03zlRoGjQYMahSZGu9" } EOM ) | base64 -w0 ewogInVybCI6ICJodHRwczovL3RhbmcuZXhhbXBsZS5jb20iLAogInRocCI6ICJaUk1leTFjR3cwN3psVExHYlhuUWFoUzBHdTAiCn0K
TPM2 예제의 "source"를 작업자 및/또는 마스터 노드의 다음 예제 중 하나 또는 둘 다에 대한 Base64 인코딩 파일로 바꿉니다.
$ cat << EOF > ./99-openshift-worker-tang-encryption.yaml apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: name: worker-tang labels: machineconfiguration.openshift.io/role: worker spec: config: ignition: version: 2.2.0 storage: files: - contents: source: data:text/plain;base64,e30K source: data:text/plain;base64,ewogInVybCI6ICJodHRwczovL3RhbmcuZXhhbXBsZS5jb20iLAogInRocCI6ICJaUk1leTFjR3cwN3psVExHYlhuUWFoUzBHdTAiCn0K filesystem: root mode: 420 path: /etc/clevis.json EOF
$ cat << EOF > ./99-openshift-master-encryption.yaml apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: name: master-tang labels: machineconfiguration.openshift.io/role: master spec: config: ignition: version: 2.2.0 storage: files: - contents: source: data:text/plain;base64,e30K source: data:text/plain;base64,ewogInVybCI6ICJodHRwczovL3RhbmcuZXhhbXBsZS5jb20iLAogInRocCI6ICJaUk1leTFjR3cwN3psVExHYlhuUWFoUzBHdTAiCn0K filesystem: root mode: 420 path: /etc/clevis.json EOF
- 나머지 OpenShift Container Platform 배포를 계속합니다.
3.2.4. chrony 타임 서비스 설정
chrony.conf
파일의 내용을 수정하고 해당 내용을 MachineConfig로 노드에 전달하여 chrony 타임 서비스 (chronyd)에서 사용하는 시간 서버 및 관련 구성을 설정할 수 있습니다.
프로세스
chrony.conf
파일의 내용을 작성하고 base64로 인코딩하십시오. 예를 들면 다음과 같습니다.$ cat << EOF | base64 server clock.redhat.com iburst driftfile /var/lib/chrony/drift makestep 1.0 3 rtcsync logdir /var/log/chrony EOF ICAgIHNlcnZlciBjbG9jay5yZWRoYXQuY29tIGlidXJzdAogICAgZHJpZnRmaWxlIC92YXIvbGli L2Nocm9ueS9kcmlmdAogICAgbWFrZXN0ZXAgMS4wIDMKICAgIHJ0Y3N5bmMKICAgIGxvZ2RpciAv dmFyL2xvZy9jaHJvbnkK
base64 문자열을 작성한 문자열로 바꾸어 MachineConfig 파일을 만듭니다. 이 예제에서는 파일을
master
노드에 추가합니다. 이를worker
로 변경하거나worker
역할의 추가 MachineConfig을 만들 수 있습니다.$ cat << EOF > ./99-masters-chrony-configuration.yaml apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: master name: masters-chrony-configuration spec: config: ignition: config: {} security: tls: {} timeouts: {} version: 2.2.0 networkd: {} passwd: {} storage: files: - contents: source: data:text/plain;charset=utf-8;base64,c2VydmVyIGNsb2NrLnJlZGhhdC5jb20gaWJ1cnN0CmRyaWZ0ZmlsZSAvdmFyL2xpYi9jaHJvbnkvZHJpZnQKbWFrZXN0ZXAgMS4wIDMKcnRjc3luYwpsb2dkaXIgL3Zhci9sb2cvY2hyb255Cg== verification: {} filesystem: root mode: 420 path: /etc/chrony.conf osImageURL: "" EOF
- 설정 파일의 백업 사본을 만듭니다.
-
클러스터가 아직 시작하지 않은 경우 매니페스트 파일을 생성하고 해당 파일을
openshift
디렉토리에 추가한 후 계속 클러스터를 작성합니다. 클러스터가 이미 실행중인 경우 다음과 같이 파일을 적용합니다.
$ oc apply -f ./masters-chrony-configuration.yaml
3.2.5. 추가 리소스
FIPS 지원에 대한 자세한 내용은 FIPS 암호화 지원을 참조하십시오.