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 설치를 완료하기 위해 필요한 경우 이 절차를 사용하여 커널 매개 변수를 추가하는 것이 좋습니다.

프로세스

  1. 클러스터에 대한 Kubernetes 매니페스트를 생성합니다.

    $ ./openshift-install create manifests --dir=<installation_directory>
  2. 커널 매개 변수를 작업자 또는 마스터 노드에 추가할지 여부를 결정합니다.
  3. 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

    커널 매개 변수를 작업자 노드에 추가하는 경우 masterworker로 변경할 수 있습니다. 마스터 및 작업자 노드 모두에 추가할 별도의 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 시스템에서 이를 수행하려면 다음 프로세스를 따르십시오.

프로세스

  1. RHEL 8 시스템을 가져온 후 등록하고 구독하십시오.

    # subscription-manager register
    Username: yourname
    Password: ***************
    # subscription-manager attach --auto
  2. 소프트웨어 및 컨테이너를 빌드하는 데 필요한 소프트웨어를 설치하십시오.

    # yum install podman make git -y
  3. kmod-via-containers 리포지토리를 복제합니다.

    $ mkdir kmods; cd kmods
    $ git clone https://github.com/kmods-via-containers/kmods-via-containers
  4. RHEL 8 빌드 호스트에 KVC 프레임 워크 인스턴스를 설치하여 모듈을 테스트합니다. kmods-via-container systemd 서비스가 추가되어 로드됩니다.

    $ cd kmods-via-containers/
    $ sudo make install
    $ sudo systemctl daemon-reload
  5. 커널 모듈의 소스 코드를 가져옵니다. 소스 코드는 제어할 수 없지만 다른 사람이 제공하는 타사 모듈을 빌드하는 데 사용될 수 있습니다. 다음과 같이 시스템에 복제할 수있는 kvc-simple-kmod 예제에 표시된 내용과 유사한 내용이 필요합니다.

    $ cd ..
    $ git clone https://github.com/kmods-via-containers/kvc-simple-kmod
  6. 다음과 같이 설정 파일 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"
  7. 커널 모듈의 kmods-via-containers @ .service 인스턴스 (이 예제에서는 simple-kmod)를 만들고 이를 활성화합니다.

    $ sudo make install
    $ sudo kmods-via-containers build simple-kmod $(uname -r)
  8. 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...
  9. 커널 모듈이 로드되었는지 확인하려면 lsmod 명령을 사용하여 모듈을 나열하십시오.

    $ lsmod | grep simple_
    simple_procfs_kmod     16384  0
    simple_kmod            16384  0
  10. 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가 부팅시 시작되도록합니다.

  1. RHEL 8 시스템을 가져온 후 등록합니다.

    # subscription-manager register
    Username: yourname
    Password: ***************
    # subscription-manager attach --auto
  2. 소프트웨어를 빌드하는 데 필요한 소프트웨어를 설치합니다.

    # yum install podman make git -y
  3. 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 키가 필요하지 않습니다.

  4. 다음과 같은 기본 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.yamlworker 노드에 커널 모듈을 배포하도록 설정되어 있습니다. 마스터 노드에 배포하려면 역할을 worker에서 master로 변경하십시오. 이 두 가지 작업을 수행하려면 여러유형의 배포에 서로 다른 파일 이름을 사용하여 전체 프로세스를 반복할 수 있습니다.

  1. 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
  2. 모듈 소프트웨어를 가져옵니다. 이 예에서는 kvc-simple-kmod가 사용됩니다.
  3. 이전에 복제된 리포지토리를 사용하여 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/
  4. filetranspiler라는 툴 및 종속 소프트웨어를 가져옵니다.

    $ cd ..
    $ sudo yum install -y python3
    git clone https://github.com/ashcrow/filetranspiler.git
  5. 최종 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
  6. 클러스터가 아직 작동하지 않은 경우 매니페스트 파일을 생성하고 해당 파일을 openshift 디렉토리에 추가합니다. 클러스터가 이미 실행중인 경우 다음과 같이 파일을 적용합니다.

    $ oc create -f 99-simple-kmod.yaml

    노드는 kmods-via-containers@simple-kmod.service 서비스를 시작하고 커널 모듈이 로드됩니다.

  7. 커널 모듈이 로드되었는지 확인하려면 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 모드 디스크 암호화를 활성화합니다.

프로세스

  1. 각 노드의 BIOS에서 TPM v2 암호화를 활성화해야하는지 확인하십시오. 이는 대부분의 Dell 시스템에서 필요합니다. 컴퓨터 설명서를 확인하십시오.
  2. 클러스터에 대한 Kubernetes 매니페스트를 생성합니다.

    $ ./openshift-install create manifests --dir=<installation_directory>
  3. 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
  4. YAML 파일의 백업 사본을 만듭니다. 클러스터를 만들 때 파일이 삭제되므로 백업을 수행해야합니다.
  5. 나머지 OpenShift Container Platform 배포를 계속합니다.

3.2.3.2. Tang 디스크 암호화 활성화

다음 프로세스를 사용하여 OpenShift Container Platform 배포 중에 Tang 모드 디스크 암호화를 활성화합니다.

프로세스

  1. 암호화 설정을 구성하고 openshift-install을 실행하여 함께 작업할 클러스터 및 oc를 설치하기 위해 Red Hat Enterprise Linux 서버에 액세스합니다.
  2. 기존 Tang 서버를 설정하거나 액세스합니다. 자세한 내용은 Network-bound disk encryption에서 참조하십시오. Tang에 표시하는 방법에 대한 자세한 내용은 Securing Automated Decryption New Cryptography and Techniques에서 참조하십시오.
  3. 클러스터에 대해 RHCOS 설치를 수행할 때 네트워크를 설정하기 위해 커널 인수를 추가합니다. 이 단계를 생략하면 두 번째 부팅이 실패합니다. 예를 들어 DHCP 네트워킹을 설정하려면 ip=dhcp를 지정하거나 커널 명령 줄에 매개 변수를 추가할 때 정적 네트워크를 설정합니다.
  4. 지문을 생성합니다. 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...
  5. Base64로 인코딩된 파일을 만들고 값을 새로 생성된 Tang 서버 (url) URL 및 지문 (thp)으로 바꿉니다.

    $ (cat <<EOM
    {
     "url": "https://tang.example.com",
     "thp": "PLjNyRdGw03zlRoGjQYMahSZGu9"
    }
    EOM
    ) | base64 -w0
    
    ewogInVybCI6ICJodHRwczovL3RhbmcuZXhhbXBsZS5jb20iLAogInRocCI6ICJaUk1leTFjR3cwN3psVExHYlhuUWFoUzBHdTAiCn0K
  6. 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
  7. 나머지 OpenShift Container Platform 배포를 계속합니다.

3.2.4. chrony 타임 서비스 설정

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

프로세스

  1. 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
  2. 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
  3. 설정 파일의 백업 사본을 만듭니다.
  4. 클러스터가 아직 시작하지 않은 경우 매니페스트 파일을 생성하고 해당 파일을 openshift 디렉토리에 추가한 후 계속 클러스터를 작성합니다.
  5. 클러스터가 이미 실행중인 경우 다음과 같이 파일을 적용합니다.

     $ oc apply -f ./masters-chrony-configuration.yaml

3.2.5. 추가 리소스

FIPS 지원에 대한 자세한 내용은 FIPS 암호화 지원을 참조하십시오.