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

머신 구성

OpenShift Container Platform 4.16

OpenShift Container Platform에서 기본 운영 체제 및 컨테이너 런타임의 구성 및 업데이트 관리 및 적용

Red Hat OpenShift Documentation Team

초록

이 문서에서는 MachineConfig, KubeletConfig, ContainerRuntimeConfig 오브젝트를 사용하여 systemd, CRI-O, Kubelet, 커널 및 기타 시스템 기능에 대한 변경 사항을 관리하는 방법을 설명합니다. 또한 이미지 계층 지정을 사용하면 클러스터 작업자 노드의 기본 이미지에 추가 이미지를 계층화하여 기본 노드 운영 체제를 쉽게 사용자 지정할 수 있습니다.

1장. 머신 구성 개요

OpenShift Container Platform 노드에서 실행되는 운영 체제를 변경해야하는 경우가 있습니다. 여기에는 네트워크 시간 서비스 설정 변경, 커널 인수 추가 또는 특정 방식으로 저널 설정이 포함됩니다.

몇 가지 특수 기능 외에도 OpenShift Container Platform 노드에서 운영 체제 대부분의 변경 사항은 Machine Config Operator가 관리하는 MachineConfig 객체를 생성하여 수행할 수 있습니다. 예를 들어 MCO(Machine Config Operator) 및 머신 구성을 사용하여 systemd, CRI-O 및 kubelet, 커널, 네트워크 관리자 및 기타 시스템 기능에 대한 업데이트를 관리할 수 있습니다.

이 섹션의 작업은 Machine Config Operator의 기능을 사용하여 OpenShift Container Platform 노드에서 운영 체제 기능을 구성하는 방법을 설명합니다.

중요

NetworkManager는 새 네트워크 구성을 키 파일 형식으로 /etc/NetworkManager/system-connections/ 에 저장합니다.

이전에는 NetworkManager에서 새 네트워크 구성을 /etc/sysconfig/network-scripts/ 에 ifcfg 형식으로 저장했습니다. RHEL 9.0부터 RHEL은 새로운 네트워크 구성을 키 파일 형식으로 /etc/NetworkManager/system-connections/ 에 저장합니다. 이전 형식의 /etc/sysconfig/network-scripts/ 에 저장된 연결 구성은 중단되지 않습니다. 기존 프로필의 수정 사항은 이전 파일을 계속 업데이트합니다.

1.1. 머신 구성 Operator 정보

OpenShift Container Platform 4.16은 운영 체제와 클러스터 관리를 모두 통합합니다. 클러스터는 클러스터 노드에서 RHCOS(Red Hat Enterprise Linux CoreOS)에 대한 업데이트를 포함하여 자체 업데이트를 관리하므로 OpenShift Container Platform은 노드 업그레이드 오케스트레이션을 단순화하는 독단적인 라이프사이클 관리 환경을 제공합니다.

OpenShift Container Platform은 3개의 데몬 세트와 컨트롤러를 사용하여 노드 관리를 단순화합니다. 이러한 데몬 세트는 표준 Kubernetes 스타일 구성을 사용하여 호스트에 대한 운영 체제 업데이트 및 구성 변경을 오케스트레이션합니다. 다음이 포함됩니다.

  • 컨트롤 플레인에서 머신 업그레이드를 조정하는 machine-config-controller. 모든 클러스터 노드를 모니터링하고 구성 업데이트를 오케스트레이션합니다.
  • 클러스터의 각 노드에서 실행되며 머신 구성에 정의된 구성으로 MachineConfigController의 지시에 따라 머신을 업데이트하는 machine-config-daemon 데몬 세트. 노드가 변경사항을 감지하면 포드를 비우고 업데이트를 적용한 다음 재부팅합니다. 이러한 변경사항은 지정된 머신 구성 및 제어 kubelet 구성을 적용하는 Ignition 구성 파일의 형태로 제공됩니다. 업데이트 자체는 컨테이너로 제공됩니다. 이 프로세스는 OpenShift Container Platform 및 RHCOS 업데이트를 성공적으로 관리하는 데 핵심입니다.
  • 클러스터에 참여할 때 컨트롤 플레인 노드에 Ignition 구성 파일을 제공하는 machine-config-server 데몬 세트.

머신 구성은 Ignition 구성의 서브 세트입니다. machine-config-daemon은 OSTree 업데이트를 수행해야 하는지 아니면 일련의 systemd kubelet 파일 변경, 구성 변경 또는 운영 체제나 OpenShift Container Platform 구성의 기타 변경 사항을 적용해야 하는지 확인하기 위해 머신 구성을 읽습니다.

노드 관리 작업을 수행할 때 KubeletConfig 사용자 정의 리소스(CR)를 생성하거나 수정합니다.

중요

머신 구성을 변경하면 MCO(Machine Config Operator)가 변경 사항을 적용하기 위해 해당 노드를 자동으로 재부팅합니다.

노드 중단 정책을 사용하여 일부 머신 구성 변경으로 인한 중단을 완화할 수 있습니다. 머신 구성을 변경한 후 노드 재시작 동작 이해 를 참조하십시오.

또는 시스템 구성을 변경한 후 노드가 자동으로 재부팅되지 않도록 할 수 있습니다. 해당 머신 구성 풀에서 spec.paused 필드를 true 로 설정하여 autoreboot 프로세스를 일시 중지합니다. 일시 정지되면 spec.paused 필드를 false로 설정하고 노드가 새 구성으로 재부팅될 때까지 머신 구성 변경 사항이 적용되지 않습니다.

다음 수정 사항에서는 노드 재부팅이 트리거되지 않습니다.

  • MCO가 다음 변경 사항을 감지하면 노드를 드레이닝하거나 재부팅하지 않고 업데이트를 적용합니다.

    • 머신 구성의 spec.config.passwd.users.sshAuthorizedKeys 매개변수에서 SSH 키 변경
    • openshift-config 네임 스페이스에서 글로벌 풀 시크릿 또는 풀 시크릿 관련 변경 사항
    • Kubernetes API Server Operator의 /etc/kubernetes/kubelet-ca.crt 인증 기관(CA) 자동 교체

  • MCO가 ImageDigestMirrorSet,ImageTagMirrorSet 또는 ImageContentSourcePolicy 개체 추가 또는 편집과 같은 /etc/containers/registries.conf 파일의 변경을 감지하면 해당 노드를 드레이닝하고 변경 사항을 적용하고 노드를 분리합니다. 다음 변경에는 노드 드레이닝이 발생하지 않습니다.

    • 각 미러에 대해 설정된 pull-from-mirror = "digest-only" 매개변수를 사용하여 레지스트리를 추가합니다.
    • 레지스트리에 설정된 pull-from-mirror = "digest-only" 매개변수를 사용하여 미러를 추가합니다.
    • unqualified-search-registries 목록에 항목이 추가되었습니다.

노드의 구성이 현재 적용된 머신 구성에서 지정하는 것과 완전히 일치하지 않는 경우가 있을 수 있습니다. 이 상태를 구성 드리프트 라고 합니다. MCO(Machine Config Daemon)는 노드에서 구성 드리프트를 정기적으로 확인합니다. MCD가 구성 드리프트를 감지하면 관리자가 노드 구성을 수정할 때까지 MCO는 노드가 degraded 상태로 표시됩니다. 성능이 저하된 노드는 온라인 상태이고 작동하지만 업데이트할 수 없습니다.

1.2. Machine Config 개요

MCO (Machine Config Operator)는 systemd, CRI-O 및 Kubelet, 커널, 네트워크 관리자 및 기타 시스템 기능에 대한 업데이트를 관리합니다. 또한 호스트에 구성 파일을 쓸 수 있는 MachineConfig CRD를 제공합니다( machine-config-operator참조). OpenShift Container Platform 클러스터에 대한 고급 시스템 수준을 변경하려면 MCO의 기능과 다른 구성 요소와 상호 작용 방식을 이해하는 것이 중요합니다. MCO, 머신 구성 및 사용 방법에 대해 알아야 할 몇 가지 사항은 다음과 같습니다.

  • 머신 구성은 사전순으로 해당 이름의 사전순으로 처리됩니다. 렌더링 컨트롤러는 목록의 첫 번째 머신 구성을 기반으로 사용하고 나머지를 기본 머신 구성에 추가합니다.
  • 머신 구성은 OpenShift Container Platform 노드 풀을 나타내는 각 시스템의 운영 체제에서 파일 또는 서비스를 특정하게 변경할 수 있습니다.

  • MCO는 시스템 풀의 운영 체제에 변경 사항을 적용합니다. 모든 OpenShift Container Platform 클러스터는 작업자 및 컨트롤 플레인 노드 풀로 시작합니다. 역할 레이블을 추가하여 사용자 지정 노드 풀을 구성할 수 있습니다. 예를 들어 애플리케이션에 필요한 특정 하드웨어 기능을 포함하는 작업자 노드의 사용자 정의 풀을 설정할 수 있습니다. 그러나 이 섹션의 예에서는 기본 풀 유형의 변경에 중점을 둡니다.

    중요

    노드는 master 또는 worker와 같이 유형을 나타내기 위해 여러 레이블을 적용할 수 있지만 단일 머신 구성 풀의 멤버일 수 있습니다.

  • 머신 구성을 변경한 후 MCO는 topology.kubernetes.io/zone 레이블을 기반으로 영역별로 영향을 받는 노드를 알파벳순으로 업데이트합니다. 영역에 둘 이상의 노드가 있으면 가장 오래된 노드가 먼저 업데이트됩니다. 베어 메탈 배포에서와 같이 영역을 사용하지 않는 노드의 경우 노드가 사용 기간으로 업그레이드되며 가장 오래된 노드가 먼저 업데이트됩니다. MCO는 머신 구성 풀의 maxUnavailable 필드에 지정된 노드 수를 한 번에 업데이트합니다.
  • OpenShift Container Platform을 디스크에 설치하기 전에 일부 머신 구성을 완료해야 합니다. 대부분의 경우 이 작업은 설치 후 머신 구성으로 실행되지 않고 OpenShift Container Platform 설치 프로그램 프로세스에 직접 삽입되는 머신 구성을 생성하여 수행할 수 있습니다. 다른 경우에는 노드별 개별 IP 주소 설정 또는 고급 디스크 파티셔닝과 같은 작업을 수행하기 위해 OpenShift Container Platform 설치 프로그램 시작 시 커널 인수를 전달하는 베어 메탈 설치를 수행해야 할 수 있습니다.
  • MCO는 머신 구성에 설정된 항목을 관리합니다. MCO가 충돌하는 파일을 관리하도록 명시적으로 지시하지 않는 한 MCO는 시스템에 대한 수동 변경 사항을 덮어 쓰지 않습니다. 즉, MCO는 사용자가 요청한 특정 업데이트 만 수행하고 전체 노드에 대한 제어를 요구하지 않습니다.
  • 노드를 수동으로 변경하지 않는 것이 좋습니다. 노드를 종료하고 새 노드를 시작해야하는 경우 이러한 직접적인 변경 사항이 손실됩니다.
  • MCO는 /etc 및 /var 디렉토리에있는 파일에 쓰는 경우에만 지원됩니다. 하지만 이러한 영역 중 하나에 심볼릭 링크를 사용하여 쓰기 가능해진 일부 디렉토리에 대한 심볼릭 링크도 있습니다. /opt 및 /usr/local 디렉토리는 예제입니다.
  • Ignition은 MachineConfigs에서 사용되는 구성 형식입니다. 자세한 내용은 Ignition Configuration Specification v3.2.0을 참조하십시오.
  • Ignition 구성 설정은 OpenShift Container Platform 설치시 직접 제공될 수 있고 MCO가 Ignition 구성을 제공하는 것과 동일한 방식으로 포맷할 수 있지만 MCO는 원래 Ignition 구성이 무엇인지 확인할 방법이 없습니다. 따라서 Ignition 구성 설정을 배포하기 전에 이를 머신 구성에 래핑해야 합니다.
  • MCO에서 관리하는 파일이 MCO 외부에서 변경되면 MCD (Machine Config Daemon)가 노드를 degraded로 설정합니다. 이는 문제가 되는 파일을 덮어 쓰지 않으며 성능이 degraded 상태에서 계속 작동합니다.
  • 머신 구성을 사용하는 주요 이유는 OpenShift Container Platform 클러스터의 풀에 새 노드를 추가할 때 적용되기 때문입니다. machine-api-operator는 새 머신을 프로비저닝하고 MCO가 이를 구성합니다.

MCO는 Ignition을 구성 형식으로 사용합니다. OpenShift Container Platform 4.6은 Ignition 구성 사양 버전 2에서 버전 3으로 이동했습니다.

1.2.1. 머신 구성에서 변경 가능한 구성

MCO가 변경할 수 있는 구성 요소의 종류는 다음과 같습니다.

  • config: Ignition 구성 개체 (Ignition 구성 사양 참조)를 생성하여 다음을 포함하여 OpenShift Container Platform 시스템에서 파일, systemd 서비스 및 기타 기능을 변경할 수 있습니다.

    • Configuration files: /var 또는 /etc 디렉토리에 파일을 만들거나 덮어 씁니다.
    • systemd units: systemd 서비스의 상태를 생성 및 설정하거나 추가 설정을 기존 systemd 서비스에 추가합니다.

    • users and groups: 설치 후 passwd 섹션에서 SSH 키를 변경합니다.

      중요
      • 머신 구성을 사용하여 SSH 키 변경은 core 사용자만 지원됩니다.
      • 머신 구성을 사용하여 새 사용자를 추가하는 것은 지원되지 않습니다.
  • kernelArguments: OpenShift Container Platform 노드가 시작될 때 커널 명령 줄에 인수를 추가합니다.
  • kernelType: 선택 옵션으로 표준 커널 대신 사용할 비표준 커널을 확인합니다. RT 커널 (RAN 용)을 사용하려면 realtime을 사용합니다. 이는 일부 플랫폼에서만 지원됩니다. 64k-pages 매개변수를 사용하여 64k 페이지 크기 커널을 활성화합니다. 이 설정은 64비트 ARM 아키텍처가 있는 머신에만 독점적입니다.

  • fips: FIPS 모드를 활성화합니다. FIPS는 설치 후 절차가 아닌 설치 시간 설정에서 설정해야 합니다.

    중요

    클러스터의 FIPS 모드를 활성화하려면 FIPS 모드에서 작동하도록 구성된 RHEL(Red Hat Enterprise Linux) 컴퓨터에서 설치 프로그램을 실행해야 합니다. RHEL에서 FIPS 모드 구성에 대한 자세한 내용은 FIPS 모드에서 시스템 설치를 참조하십시오.

    FIPS 모드에서 부팅된 RHEL(Red Hat Enterprise Linux CoreOS) 또는 RHCOS(Red Hat Enterprise Linux CoreOS)를 실행하는 경우 OpenShift Container Platform 코어 구성 요소는 x86_64, ppc64le 및 s390x 아키텍처에서만 FIPS 140-2/140-3 Validation에 대해 NIST에 제출된 RHEL 암호화 라이브러리를 사용합니다.

  • extensions: 사전 패키지화된 소프트웨어를 추가하여 RHCOS 기능을 확장합니다. 이 기능의 경우 사용 가능한 확장에는 usbguard 및 커널 모듈이 포함됩니다.
  • 사용자 지정 리소스 (ContainerRuntime 및 Kubelet용): 머신 구성 외부에서 MCO는 CRI-O 컨테이너 런타임 설정 (ContainerRuntime CR) 및 Kubelet 서비스 (Kubelet CR)를 변경하기 위해 두 가지 특정 사용자 지정 리소스를 관리합니다.

MCO는 OpenShift Container Platform 노드에서 운영 체제 구성 요소를 변경할 수 있는 유일한 Operator가 아닙니다. 다른 Operator도 운영 체제 수준의 기능을 변경할 수 있습니다. 한 가지 예로 Node Tuning Operator를 사용하여 Tuned 데몬 프로필을 통해 노드 수준 조정을 수행할 수있습니다.

설치 후 수행할 수 있는 MCO 구성 작업은 다음 절차에 포함됩니다. OpenShift Container Platform 설치 중 또는 설치 전에 수행해야 하는 시스템 설정 작업은 RHCOS 베어 메탈 설치에 대한 설명을 참조하십시오. 기본적으로 MCO를 사용하여 변경한 많은 변경 사항을 재부팅해야 합니다.

다음 수정 사항에서는 노드 재부팅이 트리거되지 않습니다.

  • MCO가 다음 변경 사항을 감지하면 노드를 드레이닝하거나 재부팅하지 않고 업데이트를 적용합니다.

    • 머신 구성의 spec.config.passwd.users.sshAuthorizedKeys 매개변수에서 SSH 키 변경
    • openshift-config 네임 스페이스에서 글로벌 풀 시크릿 또는 풀 시크릿 관련 변경 사항
    • Kubernetes API Server Operator의 /etc/kubernetes/kubelet-ca.crt 인증 기관(CA) 자동 교체

  • MCO가 ImageDigestMirrorSet,ImageTagMirrorSet 또는 ImageContentSourcePolicy 개체 추가 또는 편집과 같은 /etc/containers/registries.conf 파일의 변경을 감지하면 해당 노드를 드레이닝하고 변경 사항을 적용하고 노드를 분리합니다. 다음 변경에는 노드 드레이닝이 발생하지 않습니다.

    • 각 미러에 대해 설정된 pull-from-mirror = "digest-only" 매개변수를 사용하여 레지스트리를 추가합니다.
    • 레지스트리에 설정된 pull-from-mirror = "digest-only" 매개변수를 사용하여 미러를 추가합니다.
    • unqualified-search-registries 목록에 항목이 추가되었습니다.

다른 경우에는 MCO가 노드 중단 정책을 사용하여 변경 시 워크로드에 대한 중단을 완화할 수 있습니다. 자세한 내용은 머신 구성 변경 후 노드 재시작 동작 이해 를 참조하십시오.

노드의 구성이 현재 적용된 머신 구성에서 지정하는 것과 완전히 일치하지 않는 경우가 있을 수 있습니다. 이 상태를 구성 드리프트 라고 합니다. MCO(Machine Config Daemon)는 노드에서 구성 드리프트를 정기적으로 확인합니다. MCD가 구성 드리프트를 감지하면 관리자가 노드 구성을 수정할 때까지 MCO는 노드가 degraded 상태로 표시됩니다. 성능이 저하된 노드는 온라인 상태이고 작동하지만 업데이트할 수 없습니다. 구성 드리프트에 대한 자세한 내용은 구성 드리프트 감지 이해 를 참조하십시오.

1.3. Machine Config Operator 노드 드레이닝 동작 이해

머신 구성을 사용하여 새 구성 파일 추가, systemd 장치 또는 커널 인수 수정, SSH 키 업데이트와 같은 시스템 기능을 변경하는 경우 MCO(Machine Config Operator)는 이러한 변경 사항을 적용하고 각 노드가 원하는 구성 상태에 있는지 확인합니다.

변경 후 MCO는 새로 렌더링된 머신 구성을 생성합니다. 대부분의 경우 새로 렌더링된 머신 구성을 적용할 때 Operator는 영향을 받는 모든 노드에 업데이트된 구성이 있을 때까지 영향을 받는 각 노드에서 다음 단계를 수행합니다.

  1. Cordon. MCO는 추가 워크로드에 대해 노드를 예약할 수 없음으로 표시합니다.
  2. drain. MCO는 노드에서 실행 중인 모든 워크로드를 종료하여 워크로드를 다른 노드에 다시 예약합니다.
  3. 적용. MCO는 필요에 따라 새 구성을 노드에 씁니다.
  4. 재부팅. MCO가 노드를 다시 시작합니다.
  5. 차단 해제. MCO는 노드를 워크로드에 대해 예약 가능으로 표시합니다.

이 프로세스 전반에 걸쳐 MCO는 머신 구성 풀에 설정된 MaxUnavailable 값을 기반으로 필요한 Pod 수를 유지 관리합니다.

MCO가 마스터 노드에서 Pod를 드레이닝하는 경우 다음 조건을 기록하십시오.

  • 단일 노드 OpenShift 클러스터에서 MCO는 드레이닝 작업을 건너뜁니다.
  • MCO는 etcd와 같은 서비스로의 간섭을 방지하기 위해 정적 pod를 드레이닝하지 않습니다.
참고

경우에 따라 노드가 드레이닝되지 않습니다. 자세한 내용은 "Machine Config Operator 정보"를 참조하십시오.

노드 중단 정책을 사용하거나 컨트롤 플레인 재부팅을 비활성화하여 주기를 드레이닝 및 재부팅하여 발생하는 중단을 완화하는 방법이 있습니다. 자세한 내용은 "머신 구성 변경 후 노드 재시작 동작 이해" 및 "Machine Config Operator가 자동으로 재부팅되지 않도록 비활성화"를 참조하십시오.

1.4. 구성 드리프트 탐지 이해

노드의 디스크상의 상태가 머신 구성에 구성된 것과 다른 상황이 있을 수 있습니다. 이를 구성 드리프트 라고 합니다. 예를 들어 클러스터 관리자는 파일, systemd 장치 파일 또는 머신 구성을 통해 구성한 파일 권한을 수동으로 수정할 수 있습니다. 이로 인해 구성 드리프트가 발생합니다. 구성 드리프트로 인해 머신 구성 풀의 노드 또는 머신 구성이 업데이트될 때 문제가 발생할 수 있습니다.

MCO(Machine Config Operator)는 MCP(Machine Config Daemon)를 사용하여 노드를 정기적으로 구성 드리프트를 확인합니다. 탐지된 경우 MCO는 노드와 MCP(Machine config pool)를 Degraded 로 설정하고 오류를 보고합니다. 성능이 저하된 노드는 온라인 상태이고 작동하지만 업데이트할 수 없습니다.

MCD는 다음 조건 각각에 대해 구성 드리프트 탐지를 수행합니다.

  • 노드가 부팅되는 경우
  • 머신 구성에 지정된 파일(Ignition 파일 및 systemd 드롭인 단위)이 머신 구성 외부에서 수정되는 경우

  • 새 머신 구성을 적용하기 전에

    참고

    노드에 새 머신 구성을 적용하면 MCD가 구성 드리프트 탐지를 일시적으로 종료합니다. 새 머신 구성이 노드의 머신 구성과 반드시 다르기 때문에 이 종료가 필요합니다. 새 머신 구성을 적용한 후 MCD는 새 머신 구성을 사용하여 구성 드리프트 탐지를 다시 시작합니다.

구성 드리프트 탐지를 수행할 때 MCD는 파일 콘텐츠 및 권한이 현재 적용된 머신 구성에 지정된 항목과 완전히 일치하는지 확인합니다. 일반적으로 MCD는 탐지가 트리거된 후 1초 이내에 구성 드리프트를 감지합니다.

MCD가 구성 드리프트를 감지하면 MCD는 다음 작업을 수행합니다.

  • 콘솔 로그에 오류를 발송합니다.
  • Kubernetes 이벤트 내보내기
  • 노드에서 추가 탐지를 중지합니다.
  • 노드와 MCP의 성능이 저하된상태로 설정

MCP를 나열하여 성능이 저하된 노드가 있는지 확인할 수 있습니다. 

$ oc get mcp worker
Copy to Clipboard

성능이 저하된 MCP가 있는 경우 DEGRADEDMACHINECOUNT 필드는 다음 출력과 유사하게 0이 아닙니다.

출력 예

NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
worker   rendered-worker-404caf3180818d8ac1f50c32f14b57c3   False     True       True       2              1                   1                     1                      5h51m
Copy to Clipboard

머신 구성 풀을 검사하여 구성 드리프트로 인해 문제가 발생하는지 확인할 수 있습니다. 

$ oc describe mcp worker
Copy to Clipboard

출력 예

 ...
    Last Transition Time:  2021-12-20T18:54:00Z
    Message:               Node ci-ln-j4h8nkb-72292-pxqxz-worker-a-fjks4 is reporting: "content mismatch for file \"/etc/mco-test-file\""
1 

    Reason:                1 nodes are reporting degraded status on sync
    Status:                True
    Type:                  NodeDegraded
2 

 ...
Copy to Clipboard

1
이 메시지는 머신 구성에서 추가한 노드의 /etc/mco-test-file 파일이 머신 구성 외부에서 변경되었음을 보여줍니다.
2
노드의 상태는 NodeDegraded 입니다.

또는 성능이 저하된 노드를 알고 있는 경우 해당 노드를 검사합니다. 

$ oc describe node/ci-ln-j4h8nkb-72292-pxqxz-worker-a-fjks4
Copy to Clipboard

출력 예

 ...

Annotations:        cloud.network.openshift.io/egress-ipconfig: [{"interface":"nic0","ifaddr":{"ipv4":"10.0.128.0/17"},"capacity":{"ip":10}}]
                    csi.volume.kubernetes.io/nodeid:
                      {"pd.csi.storage.gke.io":"projects/openshift-gce-devel-ci/zones/us-central1-a/instances/ci-ln-j4h8nkb-72292-pxqxz-worker-a-fjks4"}
                    machine.openshift.io/machine: openshift-machine-api/ci-ln-j4h8nkb-72292-pxqxz-worker-a-fjks4
                    machineconfiguration.openshift.io/controlPlaneTopology: HighlyAvailable
                    machineconfiguration.openshift.io/currentConfig: rendered-worker-67bd55d0b02b0f659aef33680693a9f9
                    machineconfiguration.openshift.io/desiredConfig: rendered-worker-67bd55d0b02b0f659aef33680693a9f9
                    machineconfiguration.openshift.io/reason: content mismatch for file "/etc/mco-test-file"
1 

                    machineconfiguration.openshift.io/state: Degraded
2 

 ...
Copy to Clipboard

1
노드와 나열된 머신 구성 간에 구성 드리프트가 감지되었음을 나타내는 오류 메시지입니다. 여기서 오류 메시지는 머신 구성에 의해 추가된 /etc/mco-test-file 의 내용이 머신 구성 외부에서 변경되었음을 나타냅니다.
2
노드의 상태는 Degraded 입니다.

다음 수정 사항 중 하나를 수행하여 구성 드리프트를 수정하고 노드를 Ready 상태로 되돌릴 수 있습니다.

  • 노드에 있는 파일의 내용 및 파일 권한이 머신 구성에 구성된 항목과 일치하는지 확인합니다. 파일 내용을 수동으로 다시 작성하거나 파일 권한을 변경할 수 있습니다.

  • 성능이 저하된 노드에서 force 파일을 생성합니다. 강제 파일을 사용하면 MCD가 일반적인 구성 드리프트 탐지를 무시하고 현재 머신 구성을 다시 적용합니다.

    참고

    노드에 강제 파일을 생성하면 해당 노드가 재부팅됩니다.

1.5. Machine config pool 상태 확인

MCO(Machine Config Operator), 해당 하위 구성 요소 및 관리하는 리소스의 상태를 보려면 다음 oc 명령을 사용합니다.

프로세스

  1. 각 MCP(머신 구성 풀)에 대해 클러스터에서 사용 가능한 MCO 관리 노드 수를 보려면 다음 명령을 실행합니다. 

    $ oc get machineconfigpool
    Copy to Clipboard

    출력 예

    NAME      CONFIG                    UPDATED  UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT  AGE
master    rendered-master-06c9c4…   True     False      False     3             3                  3                   0                     4h42m
worker    rendered-worker-f4b64…    False    True       False     3             2                  2                   0                     4h42m
    Copy to Clipboard

    다음과 같습니다.

    UPDATED
    True 상태는 MCO가 현재 머신 구성을 해당 MCP의 노드에 적용했음을 나타냅니다. 현재 머신 구성은 oc get mcp 출력의 STATUS 필드에 지정됩니다. False 상태는 MCP의 노드가 업데이트 중임을 나타냅니다.
    업데이트
    True 상태는 MCO가 MachineConfigPool 사용자 정의 리소스에 지정된 대로 해당 MCP의 노드 중 하나 이상에 원하는 머신 구성을 적용 중임을 나타냅니다. 원하는 머신 구성은 편집된 새로운 머신 구성입니다. 업데이트 중인 노드를 예약에 사용할 수 없을 수 있습니다. False 상태는 MCP의 모든 노드가 업데이트됨을 나타냅니다.
    DEGRADED
    True 상태는 MCO가 현재 또는 원하는 머신 구성을 해당 MCP의 노드 중 하나에 적용하지 못하거나 구성이 실패했음을 나타냅니다. 성능이 저하된 노드를 예약에 사용할 수 없을 수 있습니다. False 상태는 MCP의 모든 노드가 준비되었음을 나타냅니다.
    MACHINECOUNT
    해당 MCP의 총 머신 수를 나타냅니다.
    READYMACHINECOUNT
    예약 준비가 된 해당 MCP의 총 머신 수를 나타냅니다.
    UPDATEDMACHINECOUNT
    현재 머신 구성이 있는 해당 MCP의 총 머신 수를 나타냅니다.
    DEGRADEDMACHINECOUNT
    degraded 또는 unreconcilable으로 표시된 MCP의 총 머신 수를 나타냅니다.

    이전 출력에는 컨트롤 플레인(마스터) 노드와 3개의 작업자 노드가 있습니다. 컨트롤 플레인 MCP 및 관련 노드가 현재 머신 구성으로 업데이트됩니다. 작업자 MCP의 노드가 원하는 머신 구성으로 업데이트되고 있습니다. UPDATEDMACHINECOUNT 에 표시된 대로 작업자 MCP의 노드 중 두 개가 업데이트되고 하나는 계속 업데이트됩니다. DEGRADEDMACHINECOUNT 가 0 이고 DEGRADED 가 False 인 것처럼 문제가 없습니다.

    MCP의 노드가 업데이트되는 동안 CONFIG 에 나열된 머신 구성은 MCP가 업데이트되는 현재 머신 구성입니다. 업데이트가 완료되면 나열된 머신 구성은 MCP가 업데이트되는 원하는 머신 구성입니다.

    참고

    노드가 차단되는 경우 해당 노드는 READYMACHINECOUNT 에 포함되지 않지만 MACHINECOUNT 에 포함됩니다. 또한 MCP 상태는 UPDATING 으로 설정됩니다. 노드에 현재 머신 구성이 있으므로 UPDATEDMACHINECOUNT 합계로 계산됩니다.

    출력 예

    NAME      CONFIG                    UPDATED  UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT  AGE
master    rendered-master-06c9c4…   True     False      False     3             3                  3                   0                     4h42m
worker    rendered-worker-c1b41a…   False    True       False     3             2                  3                   0                     4h42m
    Copy to Clipboard

  2. MachineConfigPool 사용자 정의 리소스를 검사하여 MCP에서 노드의 상태를 확인하려면 다음 명령을 실행합니다. 

    $ oc describe mcp worker
    Copy to Clipboard

    출력 예

    ...
  Degraded Machine Count:     0
  Machine Count:              3
  Observed Generation:        2
  Ready Machine Count:        3
  Unavailable Machine Count:  0
  Updated Machine Count:      3
Events:                       <none>
    Copy to Clipboard

    참고

    노드가 차단되는 경우 노드가 Ready Machine 수 에 포함되지 않습니다. 이는 Unavailable Machine Count 에 포함되어 있습니다:

    출력 예

    ...
  Degraded Machine Count:     0
  Machine Count:              3
  Observed Generation:        2
  Ready Machine Count:        2
  Unavailable Machine Count:  1
  Updated Machine Count:      3
    Copy to Clipboard

  3. 각 기존 MachineConfig 오브젝트를 보려면 다음 명령을 실행합니다. 

    $ oc get machineconfigs
    Copy to Clipboard

    출력 예

    NAME                             GENERATEDBYCONTROLLER          IGNITIONVERSION  AGE
00-master                        2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
00-worker                        2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
01-master-container-runtime      2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
01-master-kubelet                2c9371fbb673b97a6fe8b1c52…     3.2.0            5h18m
...
rendered-master-dde...           2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
rendered-worker-fde...           2c9371fbb673b97a6fe8b1c52...   3.2.0            5h18m
    Copy to Clipboard

    rendered 로 나열된 MachineConfig 오브젝트는 변경하거나 삭제할 수 없습니다.

  4. 특정 머신 구성의 콘텐츠(이 경우 01-master-kubelet)를 보려면 다음 명령을 실행합니다. 

    $ oc describe machineconfigs 01-master-kubelet
    Copy to Clipboard

    명령의 출력에서는 이 MachineConfig 오브젝트에 구성 파일(cloud.conf 및 kubelet.conf)과 systemd 서비스(Kubernetes Kubelet)가 모두 포함되어 있음을 보여줍니다.

    출력 예

    Name:         01-master-kubelet
...
Spec:
  Config:
    Ignition:
      Version:  3.2.0
    Storage:
      Files:
        Contents:
          Source:   data:,
        Mode:       420
        Overwrite:  true
        Path:       /etc/kubernetes/cloud.conf
        Contents:
          Source:   data:,kind%3A%20KubeletConfiguration%0AapiVersion%3A%20kubelet.config.k8s.io%2Fv1beta1%0Aauthentication%3A%0A%20%20x509%3A%0A%20%20%20%20clientCAFile%3A%20%2Fetc%2Fkubernetes%2Fkubelet-ca.crt%0A%20%20anonymous...
        Mode:       420
        Overwrite:  true
        Path:       /etc/kubernetes/kubelet.conf
    Systemd:
      Units:
        Contents:  [Unit]
Description=Kubernetes Kubelet
Wants=rpc-statd.service network-online.target crio.service
After=network-online.target crio.service

ExecStart=/usr/bin/hyperkube \
    kubelet \
      --config=/etc/kubernetes/kubelet.conf \ ...
    Copy to Clipboard

적용한 머신 구성에서 문제가 발생하면 언제든지 해당 변경 사항을 취소할 수 있습니다. 예를 들어 oc create -f ./myconfig.yaml 을 실행하여 머신 구성을 적용한 경우 다음 명령을 실행하여 해당 머신 구성을 제거할 수 있습니다. 

$ oc delete -f ./myconfig.yaml
Copy to Clipboard

이것이 유일한 문제인 경우 영향을 받는 풀 노드는 성능이 저하되지 않은 상태로 돌아갑니다. 이로 인해 실제로 렌더링된 구성이 이전에 렌더링된 상태로 롤백됩니다.

자체 머신 구성을 클러스터에 추가하는 경우 위의 예에 표시된 명령을 사용하여 해당 상태 및 적용되는 풀의 관련 상태를 확인할 수 있습니다.

1.6. 머신 구성 노드 상태 확인

업데이트 중에 문제가 발생할 경우 개별 노드의 진행 상황을 모니터링하고 노드를 해결해야 할 수 있습니다.

클러스터에 대한 MCO(Machine Config Operator) 업데이트 상태를 보려면 다음 oc 명령을 사용합니다.

중요

향상된 MCO 상태 보고는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

프로세스

  1. 다음 명령을 실행하여 모든 머신 구성 풀의 모든 노드에 대한 업데이트 상태에 대한 요약 정보를 가져옵니다. 

    $ oc get machineconfignodes
    Copy to Clipboard

    출력 예

    NAME                          UPDATED   UPDATEPREPARED   UPDATEEXECUTED   UPDATEPOSTACTIONCOMPLETED   UPDATECOMPLETED   RESUMED
ip-10-0-12-194.ec2.internal   True      False             False              False                    False              False
ip-10-0-17-102.ec2.internal   False     True              False              False                    False              False
ip-10-0-2-232.ec2.internal    False     False             True               False                    False              False
ip-10-0-59-251.ec2.internal   False     False             False              True                     False              False
ip-10-0-59-56.ec2.internal    False     False             False              False                    True               True
ip-10-0-6-214.ec2.internal    False     False             Unknown            False                    False              False
    Copy to Clipboard

    다음과 같습니다.

    UPDATED
    True 상태는 MCO가 현재 머신 구성을 특정 노드에 적용했음을 나타냅니다. False 상태는 노드가 현재 업데이트 중임을 나타냅니다. 알 수 없는 상태는 작업이 처리 중임을 나타냅니다.
    UPDATEPREPARED
    False 상태는 MCO가 배포할 새 머신 구성을 조정하기 시작하지 않았음을 나타냅니다. True 상태는 MCO가 업데이트의 이 단계를 완료했음을 나타냅니다. 알 수 없는 상태는 작업이 처리 중임을 나타냅니다.
    UPDATEEXECUTED
    False 상태는 MCO가 노드 차단 및 드레이닝을 시작하지 않았음을 나타냅니다. 또한 디스크 상태 및 운영 체제가 업데이트를 시작하지 않았음을 나타냅니다. True 상태는 MCO가 업데이트의 이 단계를 완료했음을 나타냅니다. 알 수 없는 상태는 작업이 처리 중임을 나타냅니다.
    UPDATEPOSTACTIONCOMPLETED
    False 상태는 MCO가 노드를 재부팅하거나 데몬을 종료하지 않았음을 나타냅니다. True 상태는 MCO가 재부팅을 완료하고 노드 상태를 업데이트했음을 나타냅니다. 알 수 없는 상태는 이 단계의 업데이트 프로세스 중 오류가 발생했거나 MCO가 현재 업데이트를 적용하고 있음을 나타냅니다.
    업데이트COMPLETED
    False 상태는 MCO가 노드 분리 및 노드 상태 및 메트릭을 업데이트하지 않았음을 나타냅니다. True 상태는 MCO가 노드 상태 및 사용 가능한 메트릭 업데이트를 완료했음을 나타냅니다.
    RE RESUMED

    False 상태는 MCO가 구성 드리프트 모니터를 시작하지 않았음을 나타냅니다. True 상태는 노드가 다시 시작되었음을 나타냅니다. 알 수 없는 상태는 작업이 처리 중임을 나타냅니다.

    참고

    앞서 설명한 기본 단계 내에는 업데이트 진행 상황을 보다 자세히 확인하는 데 사용할 수 있는 2차 단계가 있을 수 있습니다. 이전 명령의 -o wide 옵션을 사용하여 업데이트의 보조 단계를 포함하는 자세한 정보를 얻을 수 있습니다. 이는 추가 UPDATECOMPATIBLE,UPDATEFILESANDOS,DRAINEDNODE,CORDONEDNODE,REBOOTNODE,RELOADEDCRIO 및 Cryostat ORDONED 열을 제공합니다. 이러한 보조 단계는 항상 발생하는 것은 아니며 적용하려는 업데이트 유형에 따라 달라집니다.

  2. 다음 명령을 실행하여 특정 머신 구성 풀에서 노드 업데이트 상태를 확인합니다. 

    $ oc get machineconfignodes $(oc get machineconfignodes -o json | jq -r '.items[]|select(.spec.pool.name=="<pool_name>")|.metadata.name')
    1
    Copy to Clipboard
    1
    풀 이름은 MachineConfigPool 개체 이름입니다.

    출력 예

    NAME                          UPDATED   UPDATEPREPARED   UPDATEEXECUTED   UPDATEPOSTACTIONCOMPLETE   UPDATECOMPLETE   RESUMED
ip-10-0-48-226.ec2.internal   True      False            False            False                      False            False
ip-10-0-5-241.ec2.internal    True      False            False            False                      False            False
ip-10-0-74-108.ec2.internal   True      False            False            False                      False            False
    Copy to Clipboard

  3. 다음 명령을 실행하여 개별 노드의 업데이트 상태를 확인합니다. 

    $ oc describe machineconfignode/<node_name>
    1
    Copy to Clipboard
    1
    노드 이름은 MachineConfigNode 개체 이름입니다.

    출력 예

    Name:         <node_name>
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  machineconfiguration.openshift.io/v1alpha1
Kind:         MachineConfigNode
Metadata:
  Creation Timestamp:  2023-10-17T13:08:58Z
  Generation:          1
  Resource Version:    49443
  UID:                 4bd758ab-2187-413c-ac42-882e61761b1d
Spec:
  Node Ref:
    Name:         <node_name>
  Pool:
    Name:         master
  ConfigVersion:
    Desired: rendered-worker-823ff8dc2b33bf444709ed7cd2b9855b
    1 
    
Status:
  Conditions:
    Last Transition Time:  2023-10-17T13:09:02Z
    Message:               Node has completed update to config rendered-master-cf99e619747ab19165f11e3546c71f1e
    Reason:                NodeUpgradeComplete
    Status:                True
    Type:                  Updated
    Last Transition Time:  2023-10-17T13:09:02Z
    Message:               This node has not yet entered the UpdatePreparing phase
    Reason:                NotYetOccured
    Status:                False
  Config Version:
    Current:            rendered-worker-823ff8dc2b33bf444709ed7cd2b9855b
    Desired:            rendered-worker-823ff8dc2b33bf444709ed7cd2b9855b
    2 
    
  Health:               Healthy
  Most Recent Error:
  Observed Generation:  3
    Copy to Clipboard

    1
    spec.configversion.desired 필드에 지정된 원하는 구성은 노드에서 새 구성이 감지되면 즉시 업데이트됩니다.
    2
    status.configversion.desired 필드에 지정된 원하는 구성은 MCP(Machine Config Daemon)에서 새 구성을 검증할 때만 업데이트됩니다. MCD는 업데이트의 현재 단계를 확인하여 검증을 수행합니다. 업데이트가 UPDATEPREPARED 단계를 성공적으로 통과하면 상태가 새 구성을 추가합니다.

1.7. Machine Config Operator 인증서 이해

Machine Config Operator 인증서는 RHCOS(Red Hat Enterprise Linux CoreOS) 노드와 Machine Config Server 간의 연결을 보호하는 데 사용됩니다. 자세한 내용은 Machine Config Operator 인증서를 참조하십시오.

1.7.1. 인증서 보기 및 상호 작용

다음 인증서는 MCP(Machine Config Controller)에 의해 클러스터에서 처리되며 ControllerConfig 리소스에서 찾을 수 있습니다.

  • /etc/kubernetes/kubelet-ca.crt
  • /etc/kubernetes/static-pod-resources/configmaps/cloud-config/ca-bundle.pem
  • /etc/pki/ca-trust/source/anchors/openshift-config-user-ca-bundle.crt

MCC는 이미지 레지스트리 인증서 및 관련 사용자 번들 인증서도 처리합니다.

인증서가 들어오는 번들과 서명 및 제목 데이터를 포함하여 나열된 인증서에 대한 정보를 가져올 수 있습니다.

프로세스

  • 다음 명령을 실행하여 자세한 인증서 정보를 가져옵니다. 

    $ oc get controllerconfig/machine-config-controller -o yaml | yq -y '.status.controllerCertificates'
    Copy to Clipboard

    출력 예

    "controllerCertificates": [
                   {
                       "bundleFile": "KubeAPIServerServingCAData",
                       "signer": "<signer_data1>",
                       "subject": "CN=openshift-kube-apiserver-operator_node-system-admin-signer@168909215"
                   },
                   {
                       "bundleFile": "RootCAData",
                       "signer": "<signer_data2>",
                       "subject": "CN=root-ca,OU=openshift"
                   }
                ]
    Copy to Clipboard

  • 다음 명령을 사용하여 머신 구성 풀 상태를 확인하여 ControllerConfig에 있는 더 간단한 버전의 정보를 가져옵니다. 

    $ oc get mcp master -o yaml | yq -y '.status.certExpirys'
    Copy to Clipboard

    출력 예

    status:
  certExpirys:
  - bundle: KubeAPIServerServingCAData
    subject: CN=admin-kubeconfig-signer,OU=openshift
  - bundle: KubeAPIServerServingCAData
    subject: CN=kube-csr-signer_@1689585558
  - bundle: KubeAPIServerServingCAData
    subject: CN=kubelet-signer,OU=openshift
  - bundle: KubeAPIServerServingCAData
    subject: CN=kube-apiserver-to-kubelet-signer,OU=openshift
  - bundle: KubeAPIServerServingCAData
    subject: CN=kube-control-plane-signer,OU=openshift
    Copy to Clipboard

    이 방법은 머신 구성 풀 정보를 이미 사용하는 OpenShift Container Platform 애플리케이션을 위한 것입니다.

  • /etc/docker/cert.d 디렉터리의 콘텐츠를 확인하여 노드에 있는 이미지 레지스트리 인증서를 확인합니다. 

    # ls /etc/docker/certs.d
    Copy to Clipboard

    출력 예

    image-registry.openshift-image-registry.svc.cluster.local:5000 image-registry.openshift-image-registry.svc:5000
    Copy to Clipboard

2장. 머신 구성 오브젝트를 사용하여 노드 구성

이 섹션의 작업을 통해 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로 자동 변환됩니다.

노드의 구성이 현재 적용된 머신 구성에서 지정하는 것과 완전히 일치하지 않는 경우가 있을 수 있습니다. 이 상태를 구성 드리프트 라고 합니다. MCO(Machine Config Daemon)는 노드에서 구성 드리프트를 정기적으로 확인합니다. MCD가 구성 드리프트를 감지하면 관리자가 노드 구성을 수정할 때까지 MCO는 노드가 degraded 상태로 표시됩니다. 성능이 저하된 노드는 온라인 상태이고 작동하지만 업데이트할 수 없습니다. 구성 드리프트에 대한 자세한 내용은 구성 드리프트 감지 이해 를 참조하십시오.

작은 정보

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

2.1. chrony 타임 서비스 설정

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

프로세스

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

    참고

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

    variant: openshift
version: 4.16.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
    Copy to Clipboard
    1 2
    컨트롤 플레인 노드에서 두 위치에 있는 master를 worker로 대체합니다.
    3
    시스템 구성 파일에서 mode 필드의 8진수 값 모드를 지정합니다. 파일을 만들고 변경 사항을 적용하면 mode가 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
    Copy to Clipboard

  3. 다음 두 가지 방법 중 하나로 설정을 적용하십시오.

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

    • 클러스터가 이미 실행중인 경우 다음과 같은 파일을 적용합니다. 

      $ oc apply -f ./99-worker-chrony.yaml
      Copy to Clipboard

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"
      Copy to Clipboard
      1
      chronyd를 비활성화하려는 노드 역할(예: master)입니다.

    2. 다음 명령을 실행하여 MachineConfig CR을 생성합니다. 

      $ oc create -f disable-chronyd.yaml
      Copy to Clipboard

2.3. 노드에 커널 인수 추가

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

주의

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

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

  • nosmt: 커널에서 대칭 멀티 스레딩 (SMT)을 비활성화합니다. 멀티 스레딩은 각 CPU마다 여러 개의 논리 스레드를 허용합니다. 멀티 테넌트 환경에서 nosmt를 사용하여 잠재적인 크로스 스레드 공격 위험을 줄일 수 있습니다. SMT를 비활성화하는 것은 기본적으로 성능보다는 보안을 중요시하여 선택하는 것과 같습니다.

  • systemd.unified_cgroup_hierarchy: Linux 제어 그룹 버전 2 (cgroup v2)를 활성화합니다. cgroup v2는 다음 버전의 커널 제어 그룹 이며 여러 개선 사항을 제공합니다.

    중요

    cgroup v1은 더 이상 사용되지 않는 기능입니다. 더 이상 사용되지 않는 기능은 여전히 OpenShift Container Platform에 포함되어 있으며 계속 지원됩니다. 그러나 이 기능은 향후 릴리스에서 제거될 예정이므로 새로운 배포에는 사용하지 않는 것이 좋습니다.

    OpenShift Container Platform에서 더 이상 사용되지 않거나 삭제된 주요 기능의 최신 목록은 OpenShift Container Platform 릴리스 노트에서 더 이상 사용되지 않고 삭제된 기능 섹션을 참조하십시오.

  • enforcing=0: SELinux(Security Enhanced Linux)를 허용 모드에서 실행하도록 구성합니다. 허용 모드에서는 SELinux가 개체에 레이블을 지정하고 로그에 액세스 거부 항목을 내보내는 등 로드된 보안 정책을 적용하는 것처럼 동작하지만 실제로는 어떤 작업도 거부하지 않습니다. 프로덕션 시스템에는 지원되지 않지만 허용 모드는 디버깅에 유용할 수 있습니다.

    주의

    프로덕션에서 RHCOS에서 SELinux를 비활성화하는 것은 지원되지 않습니다. 노드에서 SELinux를 비활성화한 후에는 프로덕션 클러스터에서 다시 프로비저닝해야 합니다.

커널 인수 목록 및 설명은 Kernel.org 커널 매개변수에서 참조하십시오.

다음 프로세스에서는 다음을 식별하는 MachineConfig를 만듭니다.

  • 커널 인수를 추가하려는 머신 세트입니다. 이 경우 작업자 역할을 갖는 머신입니다.
  • 기존 커널 인수 끝에 추가되는 커널 인수입니다.
  • 머신 구성 목록에서 변경 사항이 적용되는 위치를 나타내는 라벨입니다.

사전 요구 사항

  • OpenShift Container Platform 클러스터에 대한 관리자 권한을 보유하고 있어야 합니다.

프로세스

  1. OpenShift Container Platform 클러스터의 기존 MachineConfig 오브젝트를 나열하고 머신 구성에 라벨을 지정하는 방법을 결정합니다. 

    $ oc get MachineConfig
    Copy to Clipboard

    출력 예

    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
    Copy to Clipboard

  2. 커널 인수를 식별하는 MachineConfig 파일을 만듭니다 (예: 05-worker-kernelarg-selinuxpermissive.yaml). 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
    1 
    
  name: 05-worker-kernelarg-selinuxpermissive
    2 
    
spec:
  kernelArguments:
    - enforcing=0
    3
    Copy to Clipboard
    1
    새 커널 인수를 작업자 노드에만 적용합니다.
    2
    머신 구성(05) 중 적합한 위치와 어떤 기능 (SELinux 허용 모드를 구성하기 위해 커널 매개변수 추가)을 하는지 식별하기 위해 이름이 지정됩니다.
    3
    정확한 커널 인수를 enforcing=0으로 식별합니다.

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

    $ oc create -f 05-worker-kernelarg-selinuxpermissive.yaml
    Copy to Clipboard

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

    $ oc get MachineConfig
    Copy to Clipboard

    출력 예

    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
    Copy to Clipboard

  5. 노드를 확인합니다. 

    $ oc get nodes
    Copy to Clipboard

    출력 예

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

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

  6. 작업자 노드 중 하나로 이동하여 커널 명령 행 인수 (호스트의 /proc/cmdline 에 있음)를 나열하여 커널 인수가 작동하는지 확인합니다. 

    $ oc debug node/ip-10-0-141-105.ec2.internal
    Copy to Clipboard

    출력 예

    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
    Copy to Clipboard

    enforcing=0 인수가 다른 커널 인수에 추가된 것을 확인할 수 있습니다.

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

중요

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

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

중요

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

중요

다중 경로가 구성된 IBM Power®에서 "vSCSI" 스토리지가 있는 단일 VIOS 호스트에서 OpenShift Container Platform 4.16 클러스터를 설치 후 활동으로 구성하면 다중 경로가 활성화된 CoreOS 노드가 부팅되지 않습니다. 노드에서 하나의 경로만 사용할 수 있으므로 이 동작이 예상됩니다.

사전 요구 사항

  • 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'
      Copy to Clipboard

  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'
      Copy to Clipboard

  3. 이전에 작성한 마스터 또는 작업자 YAML 파일을 사용하여 새 머신 구성을 생성합니다. 

    $ oc create -f ./99-worker-kargs-mpath.yaml
    Copy to Clipboard

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

    $ oc get MachineConfig
    Copy to Clipboard

    출력 예

    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
    Copy to Clipboard

  5. 노드를 확인합니다. 

    $ oc get nodes
    Copy to Clipboard

    출력 예

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

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

  6. 작업자 노드 중 하나로 이동하여 커널 명령 행 인수 (호스트의 /proc/cmdline 에 있음)를 나열하여 커널 인수가 작동하는지 확인합니다. 

    $ oc debug node/ip-10-0-141-105.ec2.internal
    Copy to Clipboard

    출력 예

    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
    Copy to Clipboard

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

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

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

OpenShift Container Platform 워크로드에 이러한 실시간 기능이 필요한 경우 머신을 Linux 실시간 커널로 전환할 수 있습니다. OpenShift Container Platform, 4.16의 경우 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
    Copy to Clipboard

  2. 머신 구성을 클러스터에 추가합니다. 다음을 입력하여 머신 구성을 클러스터에 추가합니다. 

    $ oc create -f 99-worker-realtime.yaml
    Copy to Clipboard

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

    $ oc get nodes
    Copy to Clipboard

    출력 예

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

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

    출력 예

    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
    Copy to Clipboard

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

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

    $ oc delete -f 99-worker-realtime.yaml
    Copy to Clipboard

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.16.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
    Copy to Clipboard

  2. Butane을 사용하여 작업자 노드로 전달할 구성이 포함된 MachineConfig 개체 파일 40-worker-custom-journald.yaml을 생성합니다. 

    $ butane 40-worker-custom-journald.bu -o 40-worker-custom-journald.yaml
    Copy to Clipboard

  3. 머신 구성을 풀에 적용합니다. 

    $ oc apply -f 40-worker-custom-journald.yaml
    Copy to Clipboard

  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
    Copy to Clipboard

  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
    Copy to Clipboard

2.7. RHCOS에 확장 기능 추가

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

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

다음 프로세서에서는 머신 구성을 사용하여 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
    Copy to Clipboard

  2. 머신 구성을 클러스터에 추가합니다. 다음을 입력하여 머신 구성을 클러스터에 추가합니다. 

    $ oc create -f 80-extensions.yaml
    Copy to Clipboard

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

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

    $ oc get machineconfig 80-worker-extensions
    Copy to Clipboard

    출력 예

    NAME                 GENERATEDBYCONTROLLER IGNITIONVERSION AGE
80-worker-extensions                       3.2.0           57s
    Copy to Clipboard

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

    $ oc get machineconfigpool
    Copy to Clipboard

    출력 예

    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
    Copy to Clipboard

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

    $ oc get node | grep worker
    Copy to Clipboard

    출력 예

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

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

    출력 예

    ...
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
    Copy to Clipboard

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.16.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
    Copy to Clipboard

    1
    펌웨어 패키지가 복사되는 노드의 경로를 설정합니다.
    2
    Butane을 실행하는 시스템의 로컬 파일 디렉터리에서 읽어오는 콘텐츠가 포함된 파일을 지정합니다. 로컬 파일의 경로는 files-dir 디렉터리를 기준으로 하며, 다음 단계에서 Butane과 함께 --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>
    Copy to Clipboard

  3. 다음 두 가지 방법 중 하나로 노드에 구성을 적용합니다.

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

    • 클러스터가 이미 실행중인 경우 다음과 같은 파일을 적용합니다. 

      $ oc apply -f 98-worker-firmware-blob.yaml
      Copy to Clipboard

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

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

2.9. 노드 액세스의 코어 사용자 암호 변경

기본적으로 RHCOS(Red Hat Enterprise Linux CoreOS)는 클러스터의 노드에 core 라는 사용자를 생성합니다. 코어 사용자를 사용하여 클라우드 공급자 직렬 콘솔 또는 베어 메탈 베이스 보드 컨트롤러 관리자(BMC)를 통해 노드에 액세스할 수 있습니다. 예를 들어 노드가 다운된 경우 SSH 또는 oc debug node 명령을 사용하여 해당 노드에 액세스할 수 없습니다. 그러나 기본적으로 이 사용자에 대한 암호가 없으므로 로그인하지 않고 로그인할 수 없습니다.

머신 구성을 사용하여 core 사용자의 암호를 생성할 수 있습니다. MCO(Machine Config Operator)는 암호를 할당하고 암호를 /etc/shadow 파일에 삽입하여 core 사용자로 로그인할 수 있습니다. MCO는 암호 해시를 검사하지 않습니다. 따라서 MCO는 암호에 문제가 있는지 보고할 수 없습니다.

참고
  • 암호는 클라우드 공급자 직렬 콘솔 또는 BMC를 통해서만 작동합니다. SSH에서는 작동하지 않습니다.
  • /etc/shadow 파일 또는 암호를 설정하는 systemd 장치가 포함된 머신 구성이 있는 경우 암호 해시보다 우선합니다.

필요한 경우 암호를 생성하는 데 사용한 머신 구성을 편집하여 암호를 변경할 수 있습니다. 또한 머신 구성을 삭제하여 암호를 제거할 수 있습니다. 머신 구성을 삭제해도 사용자 계정이 제거되지는 않습니다.

프로세스

  1. 운영 체제에서 지원하는 툴을 사용하여 해시된 암호를 생성합니다. 예를 들어 다음 명령을 실행하여 mkpasswd 를 사용하여 해시된 암호를 만듭니다. 

    $ mkpasswd -m SHA-512 testpass
    Copy to Clipboard

    출력 예

    $ $6$CBZwA6s6AVFOtiZe$aUKDWpthhJEyR3nnhM02NM1sKCpHn9XN.NPrJNQ3HYewioaorpwL3mKGLxvW0AOb4pJxqoqP4nFX77y0p00.8.
    Copy to Clipboard

  2. 코어 사용자 이름과 해시된 암호가 포함된 머신 구성 파일을 생성합니다. 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: set-core-user-password
spec:
  config:
    ignition:
      version: 3.2.0
    passwd:
      users:
      - name: core
    1 
    
        passwordHash: <password>
    2
    Copy to Clipboard
    1
    이것이 핵심 이어야 합니다.
    2
    core 계정과 함께 사용할 해시된 암호입니다.

  3. 다음 명령을 실행하여 머신 구성을 생성합니다. 

    $ oc create -f <file-name>.yaml
    Copy to Clipboard

    노드가 재부팅되지 않으며 잠시 후에 사용할 수 있어야 합니다. 다음 예와 같이 oc get mcp 를 사용하여 머신 구성 풀이 업데이트되는지 확인할 수 있습니다. 

    NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master   rendered-master-d686a3ffc8fdec47280afec446fce8dd   True      False      False      3              3                   3                     0                      64m
worker   rendered-worker-4605605a5b1f9de1d061e9d350f251e5   False     True       False      3              0                   0                     0                      64m
    Copy to Clipboard

검증

  1. 노드가 UPDATED=True 상태로 돌아간 후 다음 명령을 실행하여 노드의 디버그 세션을 시작합니다. 

    $ oc debug node/<node_name>
    Copy to Clipboard

  2. 다음 명령을 실행하여 디버그 쉘 내에서 /host 를 root 디렉터리로 설정합니다. 

    sh-4.4# chroot /host
    Copy to Clipboard

  3. /etc/shadow 파일의 내용을 확인합니다.

    출력 예

    ...
core:$6$2sE/010goDuRSxxv$o18K52wor.wIwZp:19418:0:99999:7:::
...
    Copy to Clipboard

    해시된 암호는 core 사용자에게 할당됩니다.

3장. 노드 중단 정책을 사용하여 머신 구성 변경의 중단을 최소화

기본적으로 MachineConfig 오브젝트의 필드를 특정 변경할 때 MCO(Machine Config Operator)는 해당 머신 구성과 연결된 노드를 드레이닝하고 재부팅합니다. 그러나 워크로드에 거의 또는 전혀 중단하지 않아도 되는 일부 Ignition 구성 오브젝트에 대한 변경 사항을 정의하는 노드 중단 정책을 생성할 수 있습니다.

노드 중단 정책을 사용하면 클러스터 중단과 변경되지 않는 구성 변경 사항을 정의할 수 있습니다. 이를 통해 클러스터에서 소규모 머신 구성을 변경할 때 노드 다운타임을 줄일 수 있습니다. 정책을 구성하려면 openshift-machine-config-operator 네임스페이스에 있는 MachineConfiguration 오브젝트를 수정합니다. 다음 MachineConfiguration 오브젝트에서 노드 중단 정책 예제를 참조하십시오.

참고

노드 중단 정책에 관계없이 항상 재부팅이 필요한 머신 구성 변경 사항이 있습니다. 자세한 내용은 Machine Config Operator 정보를 참조하십시오.

노드 중단 정책을 생성한 후 MCO는 정책의 유효성을 검사하여 형식 지정 문제와 같은 파일에서 잠재적인 문제를 검색합니다. 그런 다음 MCO는 클러스터 기본값과 정책을 병합하고 머신 구성의 status.nodeDisruptionPolicyStatus 필드를 머신 구성을 나중에 변경할 때 수행할 작업과 채웁니다. 정책의 구성은 항상 클러스터 기본값을 덮어씁니다.

중요

MCO는 노드 중단 정책에서 변경 사항을 성공적으로 적용할 수 있는지 여부를 확인하지 않습니다. 따라서 노드 중단 정책의 정확성을 보장해야 합니다.

예를 들어 sudo 구성에 노드 드레이닝 및 재부팅이 필요하지 않도록 노드 중단 정책을 구성할 수 있습니다. 또는 sshd 에 대한 업데이트가 해당 하나의 서비스를 다시 로드한 상태에서만 적용되도록 클러스터를 구성할 수 있습니다.

중요

노드 중단 정책 기능은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

다음 Ignition 구성 오브젝트를 변경할 때 MCO의 동작을 제어할 수 있습니다.

  • 구성 파일: /var 또는 /etc 디렉토리의 파일에 추가하거나 업데이트합니다.
  • systemd units: systemd 서비스의 상태를 생성 및 설정하거나 기존 systemd 서비스를 수정합니다.
  • users and groups: 설치 후 passwd 섹션에서 SSH 키를 변경합니다.
  • ICSP,ITMS,IDMS 개체: ImageContentSourcePolicy (ICSP), ImageTagMirrorSet (ITMS) 및 ImageDigestMirrorSet (IDMS) 오브젝트에서 미러링 규칙을 제거할 수 있습니다.

이러한 변경을 수행할 때 노드 중단 정책에 따라 MCO가 변경 사항을 구현할 때 다음 작업 중 필요한 작업이 결정됩니다.

  • reboot: MCO가 노드를 비우고 재부팅합니다. 이는 기본 동작입니다.
  • none: MCO가 노드를 드레이닝하거나 재부팅하지 않습니다. MCO는 추가 작업 없이 변경 사항을 적용합니다.
  • drain: MCO가 워크로드 노드를 차단하고 드레이닝합니다. 새 구성으로 워크로드가 다시 시작됩니다.
  • Reload: 서비스의 경우 MCO는 서비스를 다시 시작하지 않고 지정된 서비스를 다시 로드합니다.
  • restart: 서비스의 경우 MCO가 지정된 서비스를 완전히 다시 시작합니다.
  • DaemonReload: MCO가 systemd 관리자 구성을 다시 로드합니다.
  • Special: 내부 MCO 전용 작업이며 사용자가 설정할 수 없습니다.
참고
  • Reboot 및 None 작업은 Reboot 및 None 작업이 다른 작업을 재정의하므로 다른 작업과 함께 사용할 수 없습니다.
  • 작업은 노드 중단 정책 목록에 설정된 순서대로 적용됩니다.
  • 노드에 대한 재부팅 또는 기타 중단이 필요한 다른 머신 구성 변경을 수행하는 경우 노드 중단 정책 작업을 다시 시작합니다.

3.1. 노드 중단 정책의 예

다음 예제 MachineConfiguration 오브젝트에는 노드 중단 정책이 포함되어 있습니다.

작은 정보

MachineConfiguration 오브젝트와 MachineConfig 오브젝트는 서로 다른 오브젝트입니다. MachineConfiguration 오브젝트는 MCO Operator의 구성 매개변수가 포함된 MCO 네임스페이스의 싱글톤 오브젝트입니다. MachineConfig 오브젝트는 머신 구성 풀에 적용되는 변경 사항을 정의합니다.

다음 예제 MachineConfiguration 오브젝트는 사용자 정의 정책을 보여줍니다. 기본 노드 중단 정책 값은 상태 스탠자에 표시됩니다.

기본 노드 중단 정책

apiVersion: operator.openshift.io/v1
kind: MachineConfiguration
  name: cluster
spec:
  logLevel: Normal
  managementState: Managed
  operatorLogLevel: Normal
status:
  nodeDisruptionPolicyStatus:
    clusterPolicies:
      files:
      - actions:
        - type: None
        path: /etc/mco/internal-registry-pull-secret.json
      - actions:
        - type: None
        path: /var/lib/kubelet/config.json
      - actions:
        - reload:
            serviceName: crio.service
          type: Reload
        path: /etc/machine-config-daemon/no-reboot/containers-gpg.pub
      - actions:
        - reload:
            serviceName: crio.service
          type: Reload
        path: /etc/containers/policy.json
      - actions:
        - type: Special
        path: /etc/containers/registries.conf
      sshkey:
        actions:
        - type: None
  readyReplicas: 0
Copy to Clipboard

다음 예에서 SSH 키를 변경하면 MCO는 클러스터 노드를 비우고 crio.service 를 다시 로드하고 systemd 구성을 다시 로드하고 crio-service 를 다시 시작합니다.

SSH 키 변경을 위한 노드 중단 정책의 예

apiVersion: operator.openshift.io/v1
kind: MachineConfiguration
metadata:
  name: cluster
  namespace: openshift-machine-config-operator
# ...
spec:
  nodeDisruptionPolicy:
    sshkey:
      actions:
      - type: Drain
      - reload:
          serviceName: crio.service
        type: Reload
      - type: DaemonReload
      - restart:
          serviceName: crio.service
        type: Restart
# ...
Copy to Clipboard

다음 예에서 /etc/chrony.conf 디렉터리의 파일을 변경하면 MCO가 클러스터 노드에서 chronyd.service 를 다시 로드합니다.

구성 파일 변경을 위한 노드 중단 정책의 예

apiVersion: operator.openshift.io/v1
kind: MachineConfiguration
metadata:
  name: cluster
  namespace: openshift-machine-config-operator
# ...
spec:
  nodeDisruptionPolicy:
    files:
    - actions:
      - reload:
          serviceName: chronyd.service
        type: Reload
      path: /etc/chrony.conf
Copy to Clipboard

다음 예에서 auditd.service systemd 장치를 변경하면 MCO는 클러스터 노드를 비우고 crio.service 를 다시 로드하고, systemd 관리자 구성을 다시 로드하고 crio.service 를 다시 시작합니다.

구성 파일 변경을 위한 노드 중단 정책의 예

apiVersion: operator.openshift.io/v1
kind: MachineConfiguration
metadata:
  name: cluster
  namespace: openshift-machine-config-operator
# ...
spec:
  nodeDisruptionPolicy:
    units:
      - name: auditd.service
        actions:
          - type: Drain
          - type: Reload
            reload:
              serviceName: crio.service
          - type: DaemonReload
          - type: Restart
            restart:
              serviceName: crio.service
Copy to Clipboard

다음 예에서 registries.conf 디렉터리의 파일을 변경하면 MCO가 노드를 드레이닝하거나 재부팅하지 않고 변경 사항을 추가 작업 없이 적용합니다.

구성 파일 변경을 위한 노드 중단 정책의 예

apiVersion: operator.openshift.io/v1
kind: MachineConfiguration
metadata:
  name: cluster
  namespace: openshift-machine-config-operator
# ...
spec:
  nodeDisruptionPolicy:
      - actions:
        - type: None
        path: /etc/containers/registries.conf
Copy to Clipboard

3.2. 머신 구성 변경 시 노드 재시작 동작 구성

노드 중단 정책을 생성하여 클러스터를 중단하고 변경되지 않는 머신 구성 변경을 정의할 수 있습니다.

노드가 /var 또는 /etc 디렉토리, systemd 장치, SSH 키 및 registries.conf 파일의 변경 사항에 응답하는 방법을 제어할 수 있습니다.

이러한 변경을 수행할 때 노드 중단 정책에 따라 MCO가 변경 사항을 구현할 때 다음 작업 중 필요한 작업이 결정됩니다.

  • reboot: MCO가 노드를 비우고 재부팅합니다. 이는 기본 동작입니다.
  • none: MCO가 노드를 드레이닝하거나 재부팅하지 않습니다. MCO는 추가 작업 없이 변경 사항을 적용합니다.
  • drain: MCO가 워크로드 노드를 차단하고 드레이닝합니다. 새 구성으로 워크로드가 다시 시작됩니다.
  • Reload: 서비스의 경우 MCO는 서비스를 다시 시작하지 않고 지정된 서비스를 다시 로드합니다.
  • restart: 서비스의 경우 MCO가 지정된 서비스를 완전히 다시 시작합니다.
  • DaemonReload: MCO가 systemd 관리자 구성을 다시 로드합니다.
  • Special: 내부 MCO 전용 작업이며 사용자가 설정할 수 없습니다.
참고
  • Reboot 및 None 작업은 Reboot 및 None 작업이 다른 작업을 재정의하므로 다른 작업과 함께 사용할 수 없습니다.
  • 작업은 노드 중단 정책 목록에 설정된 순서대로 적용됩니다.
  • 노드에 대한 재부팅 또는 기타 중단이 필요한 다른 머신 구성 변경을 수행하는 경우 노드 중단 정책 작업을 다시 시작합니다.

사전 요구 사항

  • 기능 게이트를 사용하여 설정된 TechPreviewNoUpgrade 기능을 활성화했습니다. 자세한 내용은 "기능 게이트를 사용하여 기능 활성화"를 참조하십시오.

    주의

    클러스터에 TechPreviewNoUpgrade 기능 세트를 활성화하면 마이너 버전 업데이트가 수행되지 않습니다. TechPreviewNoUpgrade 기능 세트를 비활성화할 수 없습니다. 프로덕션 클러스터에서 이 기능 세트를 활성화하지 마십시오.

프로세스

  1. machineconfigurations.operator.openshift.io 오브젝트를 편집하여 노드 중단 정책을 정의합니다. 

    $ oc edit MachineConfiguration cluster -n openshift-machine-config-operator
    Copy to Clipboard

  2. 다음과 유사한 노드 중단 정책을 추가합니다. 

    apiVersion: operator.openshift.io/v1
kind: MachineConfiguration
metadata:
  name: cluster
# ...
spec:
  nodeDisruptionPolicy:
    1 
    
    files:
    2 
    
    - actions:
    3 
    
      - reload:
    4 
    
          serviceName: chronyd.service
    5 
    
        type: Reload
      path: /etc/chrony.conf
    6 
    
    sshkey:
    7 
    
      actions:
      - type: Drain
      - reload:
          serviceName: crio.service
        type: Reload
      - type: DaemonReload
      - restart:
          serviceName: crio.service
        type: Restart
    units:
    8 
    
    - actions:
      - type: Drain
      - reload:
          serviceName: crio.service
        type: Reload
      - type: DaemonReload
      - restart:
          serviceName: crio.service
        type: Restart
      name: test.service
    Copy to Clipboard
    1
    노드 중단 정책을 지정합니다.
    2
    해당 경로의 변경에 수행할 머신 구성 파일 정의 및 조치 목록을 지정합니다. 이 목록은 최대 50개의 항목을 지원합니다.
    3
    지정된 파일의 변경 시 실행할 일련의 작업을 지정합니다. 작업은 이 목록에 설정된 순서대로 적용됩니다. 이 목록은 최대 10개의 항목을 지원합니다.
    4
    지정된 파일의 변경 시 나열된 서비스를 다시 로드하도록 지정합니다.
    5
    수행할 서비스의 전체 이름을 지정합니다.
    6
    머신 구성에서 관리하는 파일의 위치를 지정합니다. 정책의 작업은 경로 의 파일을 변경할 때 적용됩니다.
    7
    클러스터의 SSH 키 변경 시 수행할 서비스 이름 및 작업 목록을 지정합니다.
    8
    해당 단위를 변경할 systemd 장치 이름 및 동작 목록을 지정합니다.

검증

  • 생성한 MachineConfiguration 오브젝트 파일을 확인합니다. 

    $ oc get MachineConfiguration/cluster -o yaml
    Copy to Clipboard

    출력 예

    apiVersion: operator.openshift.io/v1
kind: MachineConfiguration
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: cluster
# ...
status:
  nodeDisruptionPolicyStatus:
    1 
    
    clusterPolicies:
      files:
# ...
      - actions:
        - reload:
            serviceName: chronyd.service
          type: Reload
        path: /etc/chrony.conf
      sshkey:
        actions:
        - type: Drain
        - reload:
            serviceName: crio.service
          type: Reload
        - type: DaemonReload
        - restart:
            serviceName: crio.service
          type: Restart
      units:
      - actions:
        - type: Drain
        - reload:
            serviceName: crio.service
          type: Reload
        - type: DaemonReload
        - restart:
            serviceName: crio.service
          type: Restart
        name: test.se
# ...
    Copy to Clipboard

    1
    현재 클러스터 검증 정책을 지정합니다.

4장. MCO 관련 사용자 지정 리소스 구성

MachineConfig 개체를 관리하는 것 외에도 MCO는KubeletConfig 및 ContainerRuntimeConfig의 두 가지 사용자 지정 리소스 (CR)를 관리합니다. 이러한 CR을 사용하면 kubelet 및 CRI-O 컨테이너 런타임 서비스가 작동하는 방식에 영향을 미치는 노드 수준 설정을 변경할 수 있습니다.

4.1. KubeletConfig CRD를 생성하여 kubelet 매개변수 편집

kubelet 구성은 현재 Ignition 구성으로 직렬화되어 있으므로 직접 편집할 수 있습니다. 하지만 MCC(Machine Config Controller)에 새 kubelet-config-controller도 추가되어 있습니다. 이를 통해 KubeletConfig CR(사용자 정의 리소스)을 사용하여 kubelet 매개변수를 편집할 수 있습니다.

참고

kubeletConfig 오브젝트의 필드가 Kubernetes 업스트림에서 kubelet으로 직접 전달되므로 kubelet은 해당 값을 직접 검증합니다. kubeletConfig 오브젝트의 값이 유효하지 않으면 클러스터 노드를 사용할 수 없게 될 수 있습니다. 유효한 값은 Kubernetes 설명서를 참조하십시오.

다음 지침 사항을 고려하십시오.

  • 기존 KubeletConfig CR을 편집하여 각 변경 사항에 대한 CR을 생성하는 대신 기존 설정을 수정하거나 새 설정을 추가합니다. 변경 사항을 되돌릴 수 있도록 다른 머신 구성 풀을 수정하거나 임시로 변경하려는 변경 사항만 수정하기 위해 CR을 생성하는 것이 좋습니다.
  • 해당 풀에 필요한 모든 구성 변경 사항을 사용하여 각 머신 구성 풀에 대해 하나의 KubeletConfig CR을 생성합니다.
  • 필요에 따라 클러스터당 10개로 제한되는 여러 KubeletConfig CR을 생성합니다. 첫 번째 KubeletConfig CR의 경우 MCO(Machine Config Operator)는 kubelet에 추가된 머신 구성을 생성합니다. 이후 각 CR을 통해 컨트롤러는 숫자 접미사가 있는 다른 kubelet 머신 구성을 생성합니다. 예를 들어, -2 접미사가 있는 kubelet 머신 구성이 있는 경우 다음 kubelet 머신 구성에 -3이 추가됩니다.
참고

사용자 정의 머신 구성 풀에 kubelet 또는 컨테이너 런타임 구성을 적용하는 경우 machineConfigSelector 의 사용자 지정 역할은 사용자 정의 머신 구성 풀의 이름과 일치해야 합니다.

예를 들어 다음 사용자 지정 머신 구성 풀의 이름은 infra 이므로 사용자 지정 역할도 infra 여야 합니다. 

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: infra
spec:
  machineConfigSelector:
    matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,infra]}
# ...
Copy to Clipboard

머신 구성을 삭제하려면 제한을 초과하지 않도록 해당 구성을 역순으로 삭제합니다. 예를 들어 kubelet-2 머신 구성을 삭제하기 전에 kubelet-3 머신 구성을 삭제합니다.

참고

kubelet-9 접미사가 있는 머신 구성이 있고 다른 KubeletConfig CR을 생성하는 경우 kubelet 머신 구성이 10개 미만인 경우에도 새 머신 구성이 생성되지 않습니다.

KubeletConfig CR 예

$ oc get kubeletconfig
Copy to Clipboard 

NAME                AGE
set-max-pods        15m
Copy to Clipboard

KubeletConfig 머신 구성 표시 예

$ oc get mc | grep kubelet
Copy to Clipboard 

...
99-worker-generated-kubelet-1                  b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             26m
...
Copy to Clipboard

다음 프로세스는 작업자 노드의 각 노드에 대한 최대 Pod 수를 구성하는 방법을 보여줍니다.

사전 요구 사항

  1. 구성하려는 노드 유형의 정적 MachineConfigPool CR와 연관된 라벨을 가져옵니다. 다음 중 하나를 실행합니다.

    1. Machine config pool을 표시합니다. 

      $ oc describe machineconfigpool <name>
      Copy to Clipboard

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

      $ oc describe machineconfigpool worker
      Copy to Clipboard

      출력 예

      apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  creationTimestamp: 2019-02-08T14:52:39Z
  generation: 1
  labels:
    custom-kubelet: set-max-pods
      1
      Copy to Clipboard

      1
      라벨이 추가되면 labels 아래에 표시됩니다.

    2. 라벨이 없으면 키/값 쌍을 추가합니다. 

      $ oc label machineconfigpool worker custom-kubelet=set-max-pods
      Copy to Clipboard

프로세스

  1. 이 명령은 선택할 수 있는 사용 가능한 머신 구성 오브젝트를 표시합니다. 

    $ oc get machineconfig
    Copy to Clipboard

    기본적으로 두 개의 kubelet 관련 구성은 01-master-kubelet 및 01-worker-kubelet입니다.

  2. 노드당 최대 Pod의 현재 값을 확인하려면 다음을 실행합니다. 

    $ oc describe node <node_name>
    Copy to Clipboard

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

    $ oc describe node ci-ln-5grqprb-f76d1-ncnqq-worker-a-mdv94
    Copy to Clipboard

    Allocatable 스탠자에서 value: pods: <value>를 찾습니다.

    출력 예

    Allocatable:
 attachable-volumes-aws-ebs:  25
 cpu:                         3500m
 hugepages-1Gi:               0
 hugepages-2Mi:               0
 memory:                      15341844Ki
 pods:                        250
    Copy to Clipboard

  3. 작업자 노드에서 노드당 최대 Pod 수를 설정하려면 kubelet 구성이 포함된 사용자 정의 리소스 파일을 생성합니다.

    중요

    특정 머신 구성 풀을 대상으로 하는 kubelet 구성도 종속 풀에 영향을 미칩니다. 예를 들어 작업자 노드가 포함된 풀에 대한 kubelet 구성을 생성하면 인프라 노드가 포함된 풀을 포함한 모든 하위 집합 풀에도 적용됩니다. 이를 방지하려면 작업자 노드만 포함하는 선택 표현식을 사용하여 새 머신 구성 풀을 생성하고 kubelet 구성이 이 새 풀을 대상으로 지정하도록 해야 합니다. 

    apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: set-max-pods
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: set-max-pods
    1 
    
  kubeletConfig:
    maxPods: 500
    2
    Copy to Clipboard
    1
    머신 구성 풀에서 레이블을 입력합니다.
    2
    kubelet 구성을 추가합니다. 이 예에서는 maxPods를 사용하여 노드당 최대 Pod를 설정합니다.
    참고

    kubelet이 API 서버와 통신하는 속도는 QPS(초당 쿼리) 및 버스트 값에 따라 달라집니다. 노드마다 실행되는 Pod 수가 제한된 경우 기본 값인 50(kubeAPIQPS인 경우) 및 100(kubeAPIBurst인 경우)이면 충분합니다. 노드에 CPU 및 메모리 리소스가 충분한 경우 kubelet QPS 및 버스트 속도를 업데이트하는 것이 좋습니다. 

    apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: set-max-pods
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: set-max-pods
  kubeletConfig:
    maxPods: <pod_count>
    kubeAPIBurst: <burst_rate>
    kubeAPIQPS: <QPS>
    Copy to Clipboard

    1. 라벨을 사용하여 작업자의 머신 구성 풀을 업데이트합니다. 

      $ oc label machineconfigpool worker custom-kubelet=set-max-pods
      Copy to Clipboard

    2. KubeletConfig 오브젝트를 생성합니다. 

      $ oc create -f change-maxPods-cr.yaml
      Copy to Clipboard

    3. KubeletConfig 오브젝트가 생성되었는지 확인합니다. 

      $ oc get kubeletconfig
      Copy to Clipboard

      출력 예

      NAME                AGE
set-max-pods        15m
      Copy to Clipboard

      클러스터의 작업자 노드 수에 따라 작업자 노드가 하나씩 재부팅될 때까지 기다립니다. 작업자 노드가 3개인 클러스터의 경우 약 10~15분이 걸릴 수 있습니다.

  4. 변경 사항이 노드에 적용되었는지 확인합니다.

    1. 작업자 노드에서 maxPods 값이 변경되었는지 확인합니다. 

      $ oc describe node <node_name>
      Copy to Clipboard

    2. Allocatable 스탠자를 찾습니다. 

       ...
Allocatable:
  attachable-volumes-gce-pd:  127
  cpu:                        3500m
  ephemeral-storage:          123201474766
  hugepages-1Gi:              0
  hugepages-2Mi:              0
  memory:                     14225400Ki
  pods:                       500
      1 
      
 ...
      Copy to Clipboard
      1
      이 예에서 pods 매개변수는 KubeletConfig 오브젝트에 설정한 값을 보고해야 합니다.

  5. KubeletConfig 오브젝트에서 변경 사항을 확인합니다. 

    $ oc get kubeletconfigs set-max-pods -o yaml
    Copy to Clipboard

    다음 예와 같이 True 및 type:Success 상태가 표시되어야 합니다. 

    spec:
  kubeletConfig:
    maxPods: 500
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: set-max-pods
status:
  conditions:
  - lastTransitionTime: "2021-06-30T17:04:07Z"
    message: Success
    status: "True"
    type: Success
    Copy to Clipboard

4.2. CRI-O 매개 변수를 편집하기 위한 ContainerRuntimeConfig CR 작성

특정 MCP(MCP)와 연결된 노드의 OpenShift Container Platform CRI-O 런타임과 관련된 설정을 변경할 수 있습니다. ContainerRuntimeConfig 사용자 지정 리소스(CR)를 사용하여 구성 값을 설정하고 MCP와 일치하도록 레이블을 추가합니다. 그런 다음 MCO는 업데이트된 값으로 연결된 노드에서 crio.conf 및 storage.conf 구성 파일을 다시 빌드합니다.

참고

ContainerRuntimeConfig CR을 사용하여 구현된 변경 사항을 되돌리려면 CR을 삭제해야 합니다. 머신 구성 풀에서 레이블을 제거해도 변경 사항은 복구되지 않습니다.

ContainerRuntimeConfig CR을 사용하여 다음 설정을 수정할 수 있습니다.

  • PIDs 제한: ContainerRuntimeConfig 에서 PIDs 제한을 더 이상 사용되지 않을 것으로 예상됩니다. PIDs 제한이 필요한 경우 KubeletConfig CR에서 podPidsLimit 필드를 대신 사용하는 것이 좋습니다. podPidsLimit 필드의 기본값은 4096 입니다.

    참고

    CRI-O 플래그는 컨테이너의 cgroup에 적용되지만 Kubelet 플래그는 Pod의 cgroup에 설정됩니다. 이에 따라 PID 제한을 조정하십시오.

  • Log level: logLevel 매개변수는 로그 메시지의 상세 수준인 CRI-O log_level 매개변수를 설정합니다. 기본값은 info (log_level = info)입니다. 기타 다른 옵션에는 fatal, panic, error, warn, debug, trace가 포함됩니다.
  • Overlay size: overlaySize 매개변수는 컨테이너 이미지의 최대 크기인 CRI-O Overlay 스토리지 드라이버 size 매개 변수를 설정합니다.
  • Maximum log size: ContainerRuntimeConfig 에서 최대 로그 크기를 설정하는 것은 더 이상 사용되지 않을 것으로 예상됩니다. 최대 로그 크기가 필요한 경우 KubeletConfig CR에서 containerLogMaxSize 필드를 대신 사용하는 것이 좋습니다.
  • container runtime: defaultRuntime 매개변수는 컨테이너 런타임을 runc 또는 crun 으로 설정합니다. 기본값은 runc 입니다.

각 머신 구성 풀에 대해 해당 풀에 필요한 모든 구성 변경 사항이 포함된 하나의 ContainerRuntimeConfig CR이 있어야 합니다. 모든 풀에 동일한 콘텐츠를 적용하는 경우 모든 풀에 대해 하나의 ContainerRuntimeConfig CR만 있으면 됩니다.

기존 ContainerRuntimeConfig CR을 편집하여 새 CR을 생성하는 대신 기존 설정을 편집하거나 새 설정을 추가할 수도 있습니다. 새 ContainerRuntimeConfig CR을 생성하여 다른 머신 구성 풀을 수정하거나 임시로 변경하려는 경우에만 변경 사항을 되돌릴 수 있도록 하는 것이 좋습니다.

필요에 따라 여러 ContainerRuntimeConfig CR을 생성할 수 있습니다 (클러스터당 10 개 제한). 첫 번째 ContainerRuntimeConfig CR의 경우 MCO는 containerruntime으로 추가된 머신 구성을 생성합니다. 이후 각 CR을 통해 컨트롤러는 숫자 접미사가 포함된 새 containerruntime 머신 구성을 생성합니다. 예를 들어, -2 접미사가 있는 containerruntime 머신 구성이 있는 경우 다음 containerruntime 머신 구성에 -3이 추가됩니다.

머신 구성을 삭제하려면 제한을 초과하지 않도록 해당 구성을 역순으로 삭제해야 합니다. 예를 들어 containerruntime-2 머신 구성을 삭제하기 전에 containerruntime-3 머신 구성을 삭제해야 합니다.

참고

containerruntime-9 접미사가 있는 머신 구성이 있는 경우, 다음 머신 구성에 ContainerRuntimeConfig CR이 추가되고, containerruntime 머신 구성이 10 개 미만이어도 제한을 초과하여 실패합니다.

여러 ContainerRuntimeConfig CR 표시 예

$ oc get ctrcfg
Copy to Clipboard

출력 예

NAME         AGE
ctr-overlay  15m
ctr-level    5m45s
Copy to Clipboard

여러 containerruntime 머신 구성의 예

$ oc get mc | grep container
Copy to Clipboard

출력 예

...
01-master-container-runtime                        b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             57m
...
01-worker-container-runtime                        b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             57m
...
99-worker-generated-containerruntime               b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             26m
99-worker-generated-containerruntime-1             b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             17m
99-worker-generated-containerruntime-2             b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             7m26s
...
Copy to Clipboard

다음 예제에서는 log_level 필드를 debug 로 설정하고 오버레이 크기를 8GB로 설정합니다.

ContainerRuntimeConfig CR 예

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: overlay-size
spec:
 machineConfigPoolSelector:
   matchLabels:
     pools.operator.machineconfiguration.openshift.io/worker: ''
1 

 containerRuntimeConfig:
   logLevel: debug
2 

   overlaySize: 8G
3 

   defaultRuntime: "crun"
4
Copy to Clipboard

1
머신 구성 풀 레이블을 지정합니다. 컨테이너 런타임 구성의 경우 역할이 연결된 머신 구성 풀의 이름과 일치해야 합니다.
2
선택 사항: 로그 메시지의 상세 수준을 설정합니다.
3
선택 사항: 컨테이너 이미지의 최대 크기를 지정합니다.
4
선택 사항: 새 컨테이너에 배포할 컨테이너 런타임을 지정합니다. 기본값은 runc 입니다.

프로세스

ContainerRuntimeConfig CR을 사용하여 CRI-O 설정을 변경합니다.

  1. ContainerRuntimeConfig CR의 YAML 파일을 생성합니다. 

    apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: overlay-size
spec:
 machineConfigPoolSelector:
   matchLabels:
     pools.operator.machineconfiguration.openshift.io/worker: ''
    1 
    
 containerRuntimeConfig:
    2 
    
   logLevel: debug
   overlaySize: 8G
    Copy to Clipboard
    1
    수정할 머신 구성 풀의 레이블을 지정합니다.
    2
    필요에 따라 매개변수를 설정합니다.

  2. ContainerRuntimeConfig CR을 생성합니다. 

    $ oc create -f <file_name>.yaml
    Copy to Clipboard

  3. CR이 생성되었는지 확인합니다. 

    $ oc get ContainerRuntimeConfig
    Copy to Clipboard

    출력 예

    NAME           AGE
overlay-size   3m19s
    Copy to Clipboard

  4. 새 containerruntime 머신 구성이 생성되었는지 확인합니다. 

    $ oc get machineconfigs | grep containerrun
    Copy to Clipboard

    출력 예

    99-worker-generated-containerruntime   2c9371fbb673b97a6fe8b1c52691999ed3a1bfc2  3.2.0  31s
    Copy to Clipboard

  5. 모두 준비 상태로 표시될 때까지 머신 구성 풀을 모니터링합니다. 

    $ oc get mcp worker
    Copy to Clipboard

    출력 예

    NAME    CONFIG               UPDATED  UPDATING  DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT  DEGRADEDMACHINECOUNT  AGE
worker  rendered-worker-169  False    True      False     3             1                  1                    0                     9h
    Copy to Clipboard

  6. 설정이 CRI-O에 적용되었는지 확인하려면 다음을 실행합니다.

    1. 머신 구성 풀의 노드에 oc debug 세션을 열고 chroot /host를 실행합니다. 

      $ oc debug node/<node_name>
      Copy to Clipboard 
      sh-4.4# chroot /host
      Copy to Clipboard

    2. crio.conf 파일의 변경 사항을 확인합니다. 

      sh-4.4# crio config | grep 'log_level'
      Copy to Clipboard

      출력 예

      log_level = "debug"
      Copy to Clipboard

    3. 'storage.conf' 파일의 변경 사항을 확인합니다. 

      sh-4.4# head -n 7 /etc/containers/storage.conf
      Copy to Clipboard

      출력 예

      [storage]
  driver = "overlay"
  runroot = "/var/run/containers/storage"
  graphroot = "/var/lib/containers/storage"
  [storage.options]
    additionalimagestores = []
    size = "8G"
      Copy to Clipboard

4.3. CRI-O를 사용하여 오버레이에 대한 기본 최대 컨테이너 루트 파티션 크기 설정

각 컨테이너의 루트 파티션에는 기본 호스트의 사용 가능한 디스크 공간이 모두 표시됩니다. 다음 지침에 따라 모든 컨테이너의 루트 디스크에 대한 최대 파티션 크기를 설정합니다.

최대 오버레이 크기 및 로그 수준과 같은 기타 CRI-O 옵션을 구성하려면 다음 ContainerRuntimeConfig CRD(사용자 정의 리소스 정의)를 생성할 수 있습니다. 

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: overlay-size
spec:
 machineConfigPoolSelector:
   matchLabels:
     custom-crio: overlay-size
 containerRuntimeConfig:
   logLevel: debug
   overlaySize: 8G
Copy to Clipboard

프로세스

  1. 구성 오브젝트를 생성합니다. 

    $ oc apply -f overlaysize.yml
    Copy to Clipboard

  2. 새 CRI-O 구성을 작업자 노드에 적용하려면 작업자 머신 구성 풀을 편집합니다. 

    $ oc edit machineconfigpool worker
    Copy to Clipboard

  3. ContainerRuntimeConfig CRD에서 설정한 matchLabels 이름을 기반으로 custom-crio 레이블을 추가합니다. 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  creationTimestamp: "2020-07-09T15:46:34Z"
  generation: 3
  labels:
    custom-crio: overlay-size
    machineconfiguration.openshift.io/mco-built-in: ""
    Copy to Clipboard

  4. 변경 사항을 저장한 다음 머신 구성을 확인합니다. 

    $ oc get machineconfigs
    Copy to Clipboard

    새로운 99-worker-generated-containerruntime 및 rendered-worker-xyz 오브젝트가 생성됩니다.

    출력 예

    99-worker-generated-containerruntime  4173030d89fbf4a7a0976d1665491a4d9a6e54f1   3.2.0             7m42s
rendered-worker-xyz                   4173030d89fbf4a7a0976d1665491a4d9a6e54f1   3.2.0             7m36s
    Copy to Clipboard

  5. 해당 오브젝트가 생성된 후 적용할 변경 사항이 있는지 머신 구성 풀을 모니터링합니다. 

    $ oc get mcp worker
    Copy to Clipboard

    작업자 노드는 UPDATING을 True로 표시하고 머신 수, 업데이트된 수 및 기타 세부 정보를 표시합니다.

    출력 예

    NAME   CONFIG              UPDATED   UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
worker rendered-worker-xyz False True False     3             2                   2                    0                      20h
    Copy to Clipboard

    완료 후 작업자 노드는 UPDATING에서 다시 False로 변환되고 UPDATEDMACHINECOUNT의 수는 MACHINECOUNT의 ​​수와 일치합니다.

    출력 예

    NAME   CONFIG              UPDATED   UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
worker   rendered-worker-xyz   True      False      False      3         3            3             0           20h
    Copy to Clipboard

    작업자 머신을 보면 새로운 8GB 최대 크기 구성이 모든 작업자에 적용되는 것을 확인할 수 있습니다.

    출력 예

    head -n 7 /etc/containers/storage.conf
[storage]
  driver = "overlay"
  runroot = "/var/run/containers/storage"
  graphroot = "/var/lib/containers/storage"
  [storage.options]
    additionalimagestores = []
    size = "8G"
    Copy to Clipboard

    컨테이너 내부를 보면 루트 파티션이 이제 8GB가 됩니다.

    출력 예

    ~ $ df -h
Filesystem                Size      Used Available Use% Mounted on
overlay                   8.0G      8.0K      8.0G   0% /
    Copy to Clipboard

5장. 업데이트된 부팅 이미지

MCO(Machine Config Operator)는 부팅 이미지를 사용하여 RHCOS(Red Hat Enterprise Linux CoreOS) 노드를 시작합니다. 기본적으로 OpenShift Container Platform은 부팅 이미지를 관리하지 않습니다.

즉 클러스터의 부팅 이미지가 클러스터와 함께 업데이트되지 않습니다. 예를 들어 클러스터가 원래 OpenShift Container Platform 4.12를 사용하여 생성된 경우 클러스터를 생성하는 데 사용하는 부팅 이미지는 클러스터가 이후 버전에 있더라도 동일한 4.12 버전입니다. 나중에 클러스터가 4.13 이상으로 업그레이드된 경우 새 노드는 동일한 4.12 이미지로 계속 확장됩니다.

이 프로세스에서는 다음과 같은 문제가 발생할 수 있습니다.

  • 노드를 시작하는 추가 시간
  • 인증서 만료 문제
  • 버전 skew 문제

이러한 문제를 방지하려면 클러스터를 업데이트할 때마다 부팅 이미지를 업데이트하도록 클러스터를 구성할 수 있습니다. MachineConfiguration 오브젝트를 수정하여 이 기능을 활성화할 수 있습니다. 현재 GCP(Google Cloud Platform) 클러스터에서만 부팅 이미지를 업데이트할 수 있으며 Cluster API에서 관리하는 클러스터에서는 지원되지 않습니다.

중요

부팅 이미지 업데이트 기능은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

클러스터에 사용된 현재 부팅 이미지를 보려면 머신 세트를 검사합니다.

부팅 이미지 참조가 있는 머신 세트 예

apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  name: ci-ln-hmy310k-72292-5f87z-worker-a
  namespace: openshift-machine-api
spec:
# ...
  template:
# ...
    spec:
# ...
      providerSpec:
# ...
        value:
          disks:
          - autoDelete: true
            boot: true
            image: projects/rhcos-cloud/global/images/rhcos-412-85-202203181601-0-gcp-x86-64
1 

# ...
Copy to Clipboard

1
이 부팅 이미지는 현재 클러스터 버전에 관계없이 원래 설치된 OpenShift Container Platform 버전 (이 예제 OpenShift Container Platform 4.12)과 동일합니다. 부팅 이미지가 머신 세트에 표시되는 방식은 providerSpec 필드의 구조가 플랫폼마다 다르기 때문에 플랫폼에 따라 다릅니다.

부팅 이미지를 업데이트하도록 클러스터를 구성하면 머신 세트에서 참조하는 부팅 이미지가 현재 클러스터 버전과 일치합니다.

5.1. 업데이트된 부팅 이미지 구성

기본적으로 OpenShift Container Platform은 부팅 이미지를 관리하지 않습니다. MachineConfiguration 오브젝트를 수정하여 클러스터를 업데이트할 때마다 부팅 이미지를 업데이트하도록 클러스터를 구성할 수 있습니다.

사전 요구 사항

  • 기능 게이트를 사용하여 설정된 TechPreviewNoUpgrade 기능을 활성화했습니다. 자세한 내용은 추가 리소스 섹션의 "기능 게이트를 사용하여 기능 활성화"를 참조하십시오.

프로세스

  1. 다음 명령을 실행하여 부팅 이미지 업데이트를 활성화하려면 cluster 라는 MachineConfiguration 오브젝트를 편집합니다. 

    $ oc edit MachineConfiguration cluster
    Copy to Clipboard

    1. 선택 사항: 모든 머신 세트의 부팅 이미지 업데이트 기능을 구성합니다. 

      apiVersion: operator.openshift.io/v1
kind: MachineConfiguration
metadata:
  name: cluster
  namespace: openshift-machine-config-operator
spec:
# ...
  managedBootImages:
      1 
      
    machineManagers:
    - resource: machinesets
      apiGroup: machine.openshift.io
      selection:
        mode: All
      2
      Copy to Clipboard
      1
      부팅 이미지 업데이트 기능을 활성화합니다.
      2
      클러스터의 모든 머신 세트가 업데이트되도록 지정합니다.

    2. 선택 사항: 특정 머신 세트의 부팅 이미지 업데이트 기능을 구성합니다. 

      apiVersion: operator.openshift.io/v1
kind: MachineConfiguration
metadata:
  name: cluster
  namespace: openshift-machine-config-operator
spec:
# ...
  managedBootImages:
      1 
      
    machineManagers:
    - resource: machinesets
      apiGroup: machine.openshift.io
      selection:
        mode: Partial
          partial:
            machineResourceSelector:
              matchLabels:
                update-boot-image: "true"
      2
      Copy to Clipboard
      1
      부팅 이미지 업데이트 기능을 활성화합니다.
      2
      이 레이블이 있는 모든 머신 세트를 업데이트할 수 있도록 지정합니다.
      작은 정보

      머신 세트에 적절한 라벨이 없는 경우 다음과 유사한 명령을 실행하여 키/값 쌍을 추가합니다. 

      $ oc label machineset.machine ci-ln-hmy310k-72292-5f87z-worker-a update-boot-image=true -n openshift-machine-api
      Copy to Clipboard

검증

  1. 다음 명령을 실행하여 부팅 이미지 버전을 가져옵니다. 

    $ oc get machinesets <machineset_name> -n openshift-machine-api -o yaml
    Copy to Clipboard

    부팅 이미지 참조가 있는 머신 세트 예

    apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
  labels:
    machine.openshift.io/cluster-api-cluster: ci-ln-77hmkpt-72292-d4pxp
    update-boot-image: "true"
  name: ci-ln-77hmkpt-72292-d4pxp-worker-a
  namespace: openshift-machine-api
spec:
# ...
  template:
# ...
    spec:
# ...
      providerSpec:
# ...
        value:
          disks:
          - autoDelete: true
            boot: true
            image: projects/rhcos-cloud/global/images/rhcos-416-92-202402201450-0-gcp-x86-64
    1 
    
# ...
    Copy to Clipboard

    1
    이 부팅 이미지는 현재 OpenShift Container Platform 버전과 동일합니다.

5.2. 업데이트된 부팅 이미지 비활성화

업데이트된 부팅 이미지 기능을 비활성화하려면 MachineConfiguration 오브젝트를 편집하여 managedBootImages 스탠자를 제거합니다.

일부 노드가 새 부팅 이미지 버전으로 생성된 후 이 기능을 비활성화하면 기존 노드는 현재 부팅 이미지를 유지합니다. 이 기능을 비활성화해도 노드 또는 머신 세트를 원래 설치된 부팅 이미지로 롤백하지 않습니다. 머신 세트에는 기능이 활성화되고 클러스터가 향후 새 OpenShift Container Platform 버전으로 업그레이드되면 다시 업데이트되지 않은 부팅 이미지 버전이 유지됩니다.

프로세스

  1. MachineConfiguration 오브젝트를 편집하여 업데이트된 부팅 이미지를 비활성화합니다. 

    $ oc edit MachineConfiguration cluster
    Copy to Clipboard

  2. managedBootImages 스탠자를 제거합니다. 

    apiVersion: operator.openshift.io/v1
kind: MachineConfiguration
metadata:
  name: cluster
  namespace: openshift-machine-config-operator
spec:
# ...
  managedBootImages:
    1 
    
    machineManagers:
    - resource: machinesets
      apiGroup: machine.openshift.io
      selection:
        mode: All
    Copy to Clipboard
    1
    업데이트된 부팅 이미지를 비활성화하려면 전체 스탠자를 제거합니다.

6장. 사용되지 않은 렌더링된 머신 구성 관리

MCO(Machine Config Operator)는 가비지 컬렉션 활동을 수행하지 않습니다. 즉, 렌더링된 모든 머신 구성이 클러스터에 남아 있습니다. 사용자 또는 컨트롤러가 새 머신 구성을 적용할 때마다 MCO는 영향을 받는 각 머신 구성 풀에 대해 새로 렌더링된 구성을 생성합니다. 시간이 지남에 따라 렌더링된 머신 구성이 많을 수 있으므로 머신 구성을 혼동할 수 있습니다. 렌더링된 머신 구성이 너무 많으면 etcd 관련 디스크 공간 문제 및 성능 문제가 발생할 수 있습니다.

oc adm prune renderedmachineconfigs 명령을 --confirm 플래그와 함께 사용하여 오래되고 사용되지 않는 렌더링된 머신 구성을 제거할 수 있습니다. 이 명령을 사용하면 사용되지 않은 렌더링되지 않은 머신 구성 또는 특정 머신 구성 풀에 있는 구성만 제거할 수 있습니다. 이전 구성을 확인하려는 경우 이전 머신 구성을 유지하기 위해 지정된 수의 사용되지 않는 렌더링된 머신 구성을 제거할 수도 있습니다.

--confirm 플래그 없이 oc adm prune renderedmachineconfigs 명령을 사용하여 렌더링된 머신 구성이 제거되었는지 확인할 수 있습니다.

list 하위 명령을 사용하여 클러스터 또는 특정 머신 구성 풀의 렌더링된 모든 머신 구성을 표시합니다.

참고

oc adm prune renderedmachineconfigs 명령은 사용되지 않는 렌더링된 머신 구성만 삭제합니다. 머신 구성 풀에서 렌더링된 머신 구성이 사용 중인 경우 렌더링된 머신 구성이 삭제되지 않습니다. 이 경우 명령 출력은 렌더링된 머신 구성이 삭제되지 않은 이유를 지정합니다.

6.1. 렌더링된 머신 구성 보기

oc adm prune renderedmachineconfigs 명령을 list 하위 명령과 함께 사용하여 렌더링된 머신 구성 목록을 볼 수 있습니다.

예를 들어 다음 절차의 명령은 작업자 머신 구성 풀에 대해 렌더링된 모든 머신 구성을 나열합니다.

프로세스

  • 선택 사항: 다음 명령을 사용하여 렌더링된 머신 구성을 나열합니다. 

    $ oc adm prune renderedmachineconfigs list --in-use=false --pool-name=worker
    Copy to Clipboard

    다음과 같습니다.

    list
    클러스터에 렌더링된 머신 구성 목록을 표시합니다.
    --in-use
    선택 사항: 사용된 머신 구성 또는 지정된 풀의 모든 머신 구성만 표시할지 여부를 지정합니다. true 인 경우 출력에 머신 구성 풀에서 사용 중인 렌더링된 머신 구성이 나열됩니다. false 인 경우 출력에 클러스터의 렌더링된 모든 머신 구성이 나열됩니다. 기본값은 false입니다.
    --pool-name
    선택 사항: 머신 구성을 표시할 머신 구성 풀을 지정합니다.

    출력 예

    worker
status: rendered-worker-ae115e2b5e6ae05e0e6e5d62c7d0dd81
spec: rendered-worker-ae115e2b5e6ae05e0e6e5d62c7d0dd81
    Copy to Clipboard

  • 다음 명령을 실행하여 렌더링된 머신 구성을 자동으로 제거할 수 있습니다. 명령 출력에서 현재 사용 중이므로 표시된 렌더링된 머신 구성은 제거되지 않습니다. 

    $ oc adm prune renderedmachineconfigs --pool-name=worker
    Copy to Clipboard

    이 명령은 시험 실행 모드에서 실행되며 머신 구성은 제거되지 않습니다.

    다음과 같습니다.

    --pool-name
    선택 사항: 지정된 머신 구성 풀에 머신 구성을 표시합니다.

    출력 예

    Dry run enabled - no modifications will be made. Add --confirm to remove rendered machine configs.
DRY RUN: Deleted rendered MachineConfig rendered-worker-23d7322831a57f02998e7e1600a0865f
DRY RUN: Deleted rendered MachineConfig rendered-worker-fc94397dc7c43808c7014683c208956e
DRY RUN: Skipping deletion of rendered MachineConfig rendered-worker-ad5a3cad36303c363cf458ab0524e7c0 as it's currently in use
    Copy to Clipboard

6.2. 렌더링되지 않은 사용되지 않은 머신 구성 제거

oc adm prune renderedmachineconfigs 명령을 --confirm 명령과 함께 사용하여 사용되지 않는 렌더링되지 않은 머신 구성을 제거할 수 있습니다. 렌더링된 머신 구성이 삭제되지 않은 경우 명령 출력은 삭제되지 않았음을 표시하고 삭제를 건너뛰는 이유를 나열합니다.

프로세스

  1. 선택 사항: 다음 명령을 실행하여 자동으로 제거할 수 있는 렌더링된 머신 구성을 나열합니다. 명령 출력에서 현재 사용 중이므로 표시된 렌더링된 머신 구성은 제거되지 않습니다. 

    $ oc adm prune renderedmachineconfigs --pool-name=worker
    Copy to Clipboard

    출력 예

    Dry run enabled - no modifications will be made. Add --confirm to remove rendered machine configs.
DRY RUN: Deleted rendered MachineConfig rendered-worker-23d7322831a57f02998e7e1600a0865f
DRY RUN: Deleted rendered MachineConfig rendered-worker-fc94397dc7c43808c7014683c208956e
DRY RUN: Skipping deletion of rendered MachineConfig rendered-worker-ad5a3cad36303c363cf458ab0524e7c0 as it's currently in use
    Copy to Clipboard

    다음과 같습니다.

    pool-name
    선택 사항: 머신 구성을 삭제할 머신 구성 풀을 지정합니다.

  2. 다음 명령을 실행하여 사용되지 않은 렌더링되지 않은 머신 구성을 제거합니다. 다음 절차의 명령은 작업자 머신 구성 풀에서 사용되지 않는 두 개의 오래된 렌더링 머신 구성을 삭제합니다. 

    $ oc adm prune renderedmachineconfigs --pool-name=worker --count=2 --confirm
    Copy to Clipboard

    다음과 같습니다.

    --count
    선택 사항: 가장 오래된 것부터 삭제하려는 사용되지 않은 머신 구성의 최대 수를 지정합니다.
    --confirm
    선택 사항: 가장 오래된 것부터 삭제하려는 사용되지 않은 머신 구성의 최대 수를 지정합니다.
    --pool-name
    선택 사항: 머신을 삭제할 머신 구성 풀을 지정합니다. 지정하지 않으면 모든 풀이 평가됩니다.

7장. RHCOS 이미지 계층화

RHCOS(Red Hat Enterprise Linux CoreOS) 이미지 계층 지정을 사용하면 기본 이미지에 추가 이미지를 계층화하여 기본 RHCOS 이미지의 기능을 쉽게 확장할 수 있습니다. 이 계층화는 기본 RHCOS 이미지를 수정하지 않습니다. 대신 모든 RHCOS 기능을 포함하는 사용자 정의 계층 이미지를 생성하고 클러스터의 특정 노드에 기능을 추가합니다.

7.1. RHCOS 이미지 계층화 정보

이미지 계층 지정을 사용하면 클러스터 작업자 노드에서 기본 노드 운영 체제를 사용자 지정할 수 있습니다. 이렇게 하면 노드 운영 체제 및 특수 소프트웨어와 같은 추가 사용자 지정을 포함하여 모든 항목을 최신 상태로 유지할 수 있습니다.

Containerfile을 사용하여 사용자 정의 계층 이미지를 생성하고 사용자 정의 오브젝트를 사용하여 노드에 적용합니다. 언제든지 사용자 정의 오브젝트를 삭제하여 사용자 정의 계층 이미지를 제거할 수 있습니다.

RHCOS 이미지 계층 지정을 사용하면 RPM을 기본 이미지에 설치할 수 있으며 사용자 정의 콘텐츠는 RHCOS와 함께 부팅됩니다. MCO(Machine Config Operator)는 이러한 사용자 정의 계층 이미지를 롤아웃하고 기본 RHCOS 이미지에 대해 수행하는 방식과 동일하게 사용자 지정 컨테이너를 모니터링할 수 있습니다. RHCOS 이미지 계층화를 통해 RHCOS 노드를 관리하는 방법에 있어 유연성이 향상됩니다.

중요

실시간 커널 및 확장 RPM을 사용자 지정 계층 콘텐츠로 설치하는 것은 권장되지 않습니다. 이러한 RPM은 머신 구성을 사용하여 설치된 RPM과 충돌할 수 있기 때문입니다. 충돌이 발생하면 머신 구성 RPM 설치를 시도할 때 MCO는 성능이 저하된 상태가 됩니다. 계속하기 전에 머신 구성에서 충돌하는 확장을 제거해야 합니다.

사용자 정의 계층 이미지를 클러스터에 적용하는 즉시 사용자 정의 계층 이미지 및 해당 노드의 소유권을 효과적으로 소유할 수 있습니다. Red Hat은 표준 노드에서 기본 RHCOS 이미지를 유지 관리 및 업데이트해야 하지만 사용자 정의 계층 이미지를 사용하는 노드에서 이미지를 유지 관리하고 업데이트해야 합니다. 사용자 정의 계층 이미지로 적용한 패키지 및 패키지에 발생할 수 있는 문제에 대한 책임이 있다고 가정합니다.

사용자 지정 계층 이미지를 노드에 배포하는 방법은 다음 두 가지가 있습니다.

클러스터 내 계층 지정

클러스터 내 계층 지정을 사용하면 Containerfile 및 기타 매개변수를 포함하는 MachineOSConfig 오브젝트를 생성합니다. 빌드는 클러스터에서 수행되며 결과 사용자 정의 계층 이미지는 리포지터리로 자동 푸시되고 MachineOSConfig 오브젝트에 지정한 머신 구성 풀에 적용됩니다. 전체 프로세스는 클러스터 내에서 완전히 수행됩니다.

중요

클러스터상의 이미지 계층 지정은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

클러스터 외부 계층 지정
클러스터 외부 계층 지정을 사용하면 적용하려는 OpenShift Container Platform 이미지와 RPM을 참조하는 Containerfile을 생성하고, 자체 환경에서 계층화된 이미지를 빌드하고, 이미지를 리포지토리로 내보냅니다. 그런 다음 클러스터에서 새 이미지를 가리키는 대상 노드 풀에 대한 MachineConfig 오브젝트를 만듭니다. Machine Config Operator는 연결된 머신 구성의 osImageURL 값에 의해 지정된 대로 기본 RHCOS 이미지를 재정의하고 새 이미지를 부팅합니다.
중요

두 방법 모두 나머지 클러스터에 설치된 동일한 기본 RHCOS 이미지를 사용합니다. oc adm release info --image-for rhel-coreos 명령을 사용하여 클러스터에 사용되는 기본 이미지를 가져옵니다.

7.2. Containerfiles의 예

RHCOS 이미지 계층 지정을 사용하면 다음 유형의 이미지를 사용하여 사용자 정의 계층 이미지를 생성할 수 있습니다.

  • OpenShift Container Platform Hotfixes. CEE(Customer Experience and Engagement)를 사용하여 RHCOS 이미지 위에 Hotfix 패키지를 확보하고 적용할 수 있습니다. 경우에 따라 공식 OpenShift Container Platform 릴리스에 포함되기 전에 버그 수정 또는 개선 사항을 원할 수 있습니다. RHCOS 이미지 계층 지정을 사용하면 공식적으로 릴리스되기 전에 핫픽스를 쉽게 추가하고 기본 RHCOS 이미지에 수정 사항이 통합되면 Hotfix를 제거할 수 있습니다.

    중요

    일부 핫픽스에는 Red Hat 지원 예외가 필요하며 OpenShift Container Platform 지원 범위 또는 라이프 사이클 정책의 일반 범위를 벗어납니다.

    Red Hat Hotfix 정책을 기반으로 핫픽스가 제공됩니다. 기본 이미지 위에 적용하고 프로덕션 환경 이외의 환경에서 새 사용자 지정 계층 이미지가 있는지 테스트합니다. 프로덕션에서 사용자 정의 계층 이미지를 안전하게 사용할 수 있다는 것이 만족되면 자체 일정에 따라 특정 노드 풀로 롤아웃할 수 있습니다. 어떠한 이유로든 사용자 정의 계층 이미지를 쉽게 롤백하고 기본 RHCOS를 사용하여 로 돌아갈 수 있습니다.

    핫픽스를 적용하는 클러스터의 컨테이너 파일 예

    # Using a 4.12.0 image
containerfileArch: noarch
content: |-
  FROM configs AS final
  #Install hotfix rpm
  RUN rpm-ostree override replace https://example.com/myrepo/haproxy-1.0.16-5.el8.src.rpm && \
      rpm-ostree cleanup -m && \
      ostree container commit
    Copy to Clipboard

    핫픽스를 적용하는 클러스터 외부 컨테이너 파일의 예

    # Using a 4.12.0 image
FROM quay.io/openshift-release-dev/ocp-release@sha256...
#Install hotfix rpm
RUN rpm-ostree override replace https://example.com/myrepo/haproxy-1.0.16-5.el8.src.rpm && \
    rpm-ostree cleanup -m && \
    ostree container commit
    Copy to Clipboard

  • RHEL 패키지. Red Hat 고객 포털(예: chrony, firewalld, iputils)에서 RHEL(Red Hat Enterprise Linux) 패키지를 다운로드할 수 있습니다.

    libreswan 유틸리티를 적용하는 클러스터 외부 컨테이너 파일의 예

    # Get RHCOS base image of target cluster `oc adm release info --image-for rhel-coreos`
# hadolint ignore=DL3006
FROM quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256...

# Install our config file
COPY my-host-to-host.conf /etc/ipsec.d/

# RHEL entitled host is needed here to access RHEL packages
# Install libreswan as extra RHEL package
RUN rpm-ostree install libreswan && \
    systemctl enable ipsec && \
    ostree container commit
    Copy to Clipboard

    libreswan에는 추가 RHEL 패키지가 필요하므로 권한이 있는 RHEL 호스트에 이미지를 빌드해야 합니다. RHEL 인타이틀먼트가 작동하려면 etc-pki-entitlement 보안을 openshift-machine-api 네임스페이스에 복사해야 합니다.

  • 타사 패키지. 다음 유형의 패키지와 같은 타사 조직에서 RPM을 다운로드하고 설치할 수 있습니다.

    • 성능을 개선하거나 기능을 추가하기 위해 엣지 드라이버 및 커널 개선 사항 유지.
    • 가능한 실제 중단을 조사하기 위한 포렌식 클라이언트 툴입니다.
    • 보안 에이전트.
    • 전체 클러스터에 대한 일관된 보기를 제공하는 인벤토리 에이전트입니다.
    • SSH 키 관리 패키지.

    EPEL의 타사 패키지를 적용하는 클러스터 내 Containerfile의 예

    FROM configs AS final

#Enable EPEL (more info at https://docs.fedoraproject.org/en-US/epel/ ) and install htop
RUN rpm-ostree install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm && \
    rpm-ostree install htop && \
    ostree container commit
    Copy to Clipboard

    EPEL의 타사 패키지를 적용하는 클러스터 외부 컨테이너 파일의 예

    # Get RHCOS base image of target cluster `oc adm release info --image-for rhel-coreos`
# hadolint ignore=DL3006
FROM quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256...

# Install our config file
COPY my-host-to-host.conf /etc/ipsec.d/

# RHEL entitled host is needed here to access RHEL packages
# Install libreswan as extra RHEL package
RUN rpm-ostree install libreswan && \
    systemctl enable ipsec && \
    ostree container commit
    Copy to Clipboard

    이 Containerfile은 RHEL 어류 프로그램을 설치합니다. 어류에는 추가 RHEL 패키지가 필요하므로 권한이 있는 RHEL 호스트에 이미지를 빌드해야 합니다. RHEL 인타이틀먼트가 작동하려면 etc-pki-entitlement 보안을 openshift-machine-api 네임스페이스에 복사해야 합니다.

    RHEL 종속 항목이 있는 타사 패키지를 적용하는 클러스터의 컨테이너 파일 예

    FROM configs AS final

# RHEL entitled host is needed here to access RHEL packages
# Install fish as third party package from EPEL
RUN rpm-ostree install https://dl.fedoraproject.org/pub/epel/9/Everything/x86_64/Packages/f/fish-3.3.1-3.el9.x86_64.rpm && \
    ostree container commit
    Copy to Clipboard

    RHEL 종속 항목이 있는 타사 패키지를 적용하는 클러스터 외부 Containerfile의 예

    # Get RHCOS base image of target cluster `oc adm release info --image-for rhel-coreos`
# hadolint ignore=DL3006
FROM quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256...

# Install our config file
COPY my-host-to-host.conf /etc/ipsec.d/

# RHEL entitled host is needed here to access RHEL packages
# Install libreswan as extra RHEL package
RUN rpm-ostree install libreswan && \
    systemctl enable ipsec && \
    ostree container commit
    Copy to Clipboard

머신 구성을 생성한 후 MCO(Machine Config Operator)에서 다음 단계를 수행합니다.

  1. 지정된 풀 또는 풀에 대해 새 머신 구성을 렌더링합니다.
  2. 풀 또는 풀의 노드에서 차단 및 드레이닝 작업을 수행합니다.
  3. 나머지 머신 구성 매개변수를 노드에 씁니다.
  4. 사용자 정의 계층 이미지를 노드에 적용합니다.
  5. 새 이미지를 사용하여 노드를 재부팅합니다.
중요

클러스터에 롤아웃하기 전에 프로덕션 환경 외부의 이미지를 테스트하는 것이 좋습니다.

7.3. 클러스터상의 계층화를 사용하여 사용자 정의 계층 이미지 적용

on-cluster 빌드 프로세스를 사용하여 클러스터에 사용자 정의 계층 이미지를 적용하려면 사전 요구 사항에 설명된 대로 Containerfile, 머신 구성 풀 참조, 리포지토리 내보내기 및 가져오기 보안을 포함하는 MachineOSConfig 사용자 정의 리소스를 만듭니다.

오브젝트를 생성할 때 MCO(Machine Config Operator)는 MachineOSBuild 오브젝트 및 machine-os-builder Pod를 생성합니다. 빌드 프로세스는 빌드가 완료된 후 정리되는 구성 맵과 같은 일시적인 오브젝트도 생성합니다.

빌드가 완료되면 MCO는 새 노드를 배포할 때 사용할 수 있도록 새 사용자 지정 계층 이미지를 리포지토리로 푸시합니다. MachineOSBuild 오브젝트 및 machine-os-builder Pod에서 새 사용자 정의 계층 이미지에 대한 다이제스트된 이미지 가져오기 사양을 확인할 수 있습니다.

이러한 새 오브젝트 또는 machine-os-builder Pod와 상호 작용할 필요가 없습니다. 그러나 필요한 경우 이러한 리소스를 모두 사용하여 문제를 해결할 수 있습니다.

사용자 정의 계층 이미지를 사용하려는 각 머신 구성 풀에 대해 별도의 MachineOSConfig CR이 필요합니다.

중요

클러스터상의 이미지 계층 지정은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

사전 요구 사항

  • 기능 게이트를 사용하여 설정된 TechPreviewNoUpgrade 기능을 활성화했습니다. 자세한 내용은 "기능 게이트를 사용하여 기능 활성화"를 참조하십시오.
  • MCO가 기본 운영 체제 이미지를 가져오는 데 필요한 openshift-machine-config-operator 네임스페이스에 풀 시크릿이 있습니다.
  • MCO가 새 사용자 지정 계층 이미지를 레지스트리로 내보내는 데 필요한 푸시 시크릿이 있습니다.
  • 노드에서 새 사용자 지정 계층화된 이미지를 레지스트리에서 가져와야 하는 풀 시크릿이 있습니다. 이미지를 리포지토리로 내보내는 데 사용한 것과 다른 시크릿이어야 합니다.
  • 컨테이너 파일을 구성하는 방법에 대해 잘 알고 있습니다. Containerfile을 생성하는 방법에 대한 지침은 이 문서의 범위를 벗어납니다.
  • 선택 사항: 사용자 정의 계층 이미지를 적용하려는 노드에 대해 별도의 머신 구성 풀이 있습니다.

프로세스

  1. machineOSconfig 오브젝트를 생성합니다.

    1. 다음과 유사한 YAML 파일을 생성합니다. 

      apiVersion: machineconfiguration.openshift.io/v1alpha1
kind: MachineOSConfig
metadata:
  name: layered
spec:
  machineConfigPool:
    name: <mcp_name>
      1 
      
  buildInputs:
    containerFile:
      2 
      
    - containerfileArch: noarch
      content: |-
        FROM configs AS final
        RUN rpm-ostree install cowsay && \
          ostree container commit
    imageBuilder:
      3 
      
      imageBuilderType: PodImageBuilder
    baseImagePullSecret:
      4 
      
      name: global-pull-secret-copy
    renderedImagePushspec: image-registry.openshift-image-registry.svc:5000/openshift/os-image:latest
      5 
      
    renderedImagePushSecret:
      6 
      
      name: builder-dockercfg-7lzwl
  buildOutputs:
      7 
      
    currentImagePullSecret:
      name: builder-dockercfg-7lzwl
      Copy to Clipboard
      1
      사용자 정의 계층 이미지를 배포하려는 노드와 연결된 머신 구성 풀의 이름을 지정합니다.
      2
      사용자 지정 계층 이미지를 구성할 Containerfile을 지정합니다.
      3
      사용할 이미지 빌더의 이름을 지정합니다. PodImageBuilder 여야 합니다.
      4
      MCO가 레지스트리에서 기본 운영 체제 이미지를 가져오는 데 필요한 풀 시크릿의 이름을 지정합니다.
      5
      새로 빌드된 사용자 정의 계층 이미지를 내보낼 이미지 레지스트리를 지정합니다. 이는 클러스터가 액세스할 수 있는 모든 레지스트리일 수 있습니다. 이 예에서는 내부 OpenShift Container Platform 레지스트리를 사용합니다.
      6
      MCO에서 새로 빌드된 사용자 지정 계층 이미지를 해당 레지스트리로 푸시해야 하는 내보내기 보안의 이름을 지정합니다.
      7
      노드에서 새로 빌드된 사용자 정의 계층 이미지를 가져와야 하는 이미지 레지스트리에 필요한 보안을 지정합니다. 이미지를 리포지토리에 내보내는 데 사용한 것과 다른 시크릿이어야 합니다.

    2. MachineOSConfig 오브젝트를 생성합니다. 

      $ oc create -f <file_name>.yaml
      Copy to Clipboard

  2. 필요한 경우 MachineOSBuild 오브젝트가 생성되어 READY 상태에 있는 경우 새 사용자 지정 계층 이미지를 사용하려는 노드의 노드 사양을 수정합니다.

    1. MachineOSBuild 오브젝트가 READY 인지 확인합니다. SUCCEEDED 값이 True 이면 빌드가 완료됩니다. 

      $ oc get machineosbuild
      Copy to Clipboard

      MachineOSBuild 오브젝트가 준비되었음을 보여주는 출력 예

      NAME                                                                PREPARED   BUILDING   SUCCEEDED   INTERRUPTED   FAILED
layered-rendered-layered-ad5a3cad36303c363cf458ab0524e7c0-builder   False      False      True        False         False
      Copy to Clipboard

    2. MachineOSConfig 오브젝트에 지정한 머신 구성 풀의 레이블을 추가하여 사용자 정의 계층 이미지를 배포하려는 노드를 편집합니다. 

      $ oc label node <node_name> 'node-role.kubernetes.io/<mcp_name>='
      Copy to Clipboard

      다음과 같습니다.

      node-role.kubernetes.io/<mcp_name>=
      사용자 정의 계층 이미지를 배포할 노드를 식별하는 노드 선택기를 지정합니다.

      변경 사항을 저장하면 MCO가 노드를 드레이닝, 차단 및 재부팅합니다. 재부팅 후 노드는 새 사용자 정의 계층 이미지를 사용합니다.

검증

  1. 다음 명령을 사용하여 새 포드가 실행 중인지 확인합니다. 

    $ oc get pods -n <machineosbuilds_namespace>
    Copy to Clipboard 
    NAME                                                              READY   STATUS    RESTARTS   AGE
build-rendered-layered-ad5a3cad36303c363cf458ab0524e7c0           2/2     Running   0          2m40s
    1 
    
# ...
machine-os-builder-6fb66cfb99-zcpvq                               1/1     Running   0          2m42s
    2
    Copy to Clipboard
    1
    사용자 정의 계층 이미지가 빌드 중인 빌드 Pod입니다.
    2
    이 Pod는 문제 해결에 사용할 수 있습니다.

  2. MachineOSConfig 오브젝트에 새 사용자 정의 계층 이미지에 대한 참조가 포함되어 있는지 확인합니다. 

    $ oc describe MachineOSConfig <object_name>
    Copy to Clipboard 
    apiVersion: machineconfiguration.openshift.io/v1alpha1
kind: MachineOSConfig
metadata:
  name: layered
spec:
  buildInputs:
    baseImagePullSecret:
      name: global-pull-secret-copy
    containerFile:
    - containerfileArch: noarch
      content: ""
    imageBuilder:
      imageBuilderType: PodImageBuilder
    renderedImagePushSecret:
      name: builder-dockercfg-ng82t-canonical
    renderedImagePushspec: image-registry.openshift-image-registry.svc:5000/openshift-machine-config-operator/os-image:latest
  buildOutputs:
    currentImagePullSecret:
      name: global-pull-secret-copy
  machineConfigPool:
    name: layered
status:
  currentImagePullspec: image-registry.openshift-image-registry.svc:5000/openshift-machine-config-operator/os-image@sha256:f636fa5b504e92e6faa22ecd71a60b089dab72200f3d130c68dfec07148d11cd
    1
    Copy to Clipboard
    1
    새 사용자 지정 계층 이미지에 대한 다이제스트된 이미지 가져오기 사양입니다.

  3. MachineOSBuild 오브젝트에 새 사용자 지정 계층 이미지에 대한 참조가 포함되어 있는지 확인합니다. 

    $ oc describe machineosbuild <object_name>
    Copy to Clipboard 
    apiVersion: machineconfiguration.openshift.io/v1alpha1
kind: MachineOSBuild
metadata:
  name: layered-rendered-layered-ad5a3cad36303c363cf458ab0524e7c0-builder
spec:
  desiredConfig:
    name: rendered-layered-ad5a3cad36303c363cf458ab0524e7c0
  machineOSConfig:
    name: layered
  renderedImagePushspec: image-registry.openshift-image-registry.svc:5000/openshift-machine-config-operator/os-image:latest
# ...
status:
  conditions:
    - lastTransitionTime: "2024-05-21T20:25:06Z"
      message: Build Ready
      reason: Ready
      status: "True"
      type: Succeeded
  finalImagePullspec: image-registry.openshift-image-registry.svc:5000/openshift-machine-config-operator/os-image@sha256:f636fa5b504e92e6faa22ecd71a60b089dab72200f3d130c68dfec07148d11cd
    1
    Copy to Clipboard
    1
    새 사용자 지정 계층 이미지에 대한 다이제스트된 이미지 가져오기 사양입니다.

  4. 적절한 노드에서 새 사용자 지정 계층 이미지를 사용하고 있는지 확인합니다.

    1. 컨트롤 플레인 노드의 root로 디버그 세션을 시작합니다. 

      $ oc debug node/<node_name>
      Copy to Clipboard

    2. 디버그 쉘 내에서 /host를 root 디렉터리로 설정합니다. 

      sh-4.4# chroot /host
      Copy to Clipboard

    3. rpm-ostree status 명령을 실행하여 사용자 정의 계층화된 이미지가 사용 중인지 확인합니다. 

      sh-5.1# rpm-ostree status
      Copy to Clipboard

      출력 예

      # ...
Deployments:
* ostree-unverified-registry:quay.io/openshift-release-dev/os-image@sha256:f636fa5b504e92e6faa22ecd71a60b089dab72200f3d130c68dfec07148d11cd
      1 
      
                   Digest: sha256:bcea2546295b2a55e0a9bf6dd4789433a9867e378661093b6fdee0031ed1e8a4
                  Version: 416.94.202405141654-0 (2024-05-14T16:58:43Z)
      Copy to Clipboard

      1
      새 사용자 지정 계층 이미지에 대한 다이제스트된 이미지 가져오기 사양입니다.

추가 리소스

7.4. 클러스터 외부 계층 지정을 사용하여 사용자 정의 계층 이미지 적용

특정 머신 구성 풀의 노드에서 RHCOS(Red Hat Enterprise Linux CoreOS) 이미지 계층을 쉽게 구성할 수 있습니다. MCO(Machine Config Operator)는 새 사용자 정의 계층 이미지로 노드를 재부팅하여 기본 RHCOS(Red Hat Enterprise Linux CoreOS) 이미지를 덮어씁니다.

클러스터에 사용자 정의 계층 이미지를 적용하려면 클러스터가 액세스할 수 있는 리포지토리에 사용자 정의 계층 이미지가 있어야 합니다. 그런 다음 사용자 지정 계층화된 이미지를 가리키는 MachineConfig 오브젝트를 만듭니다. 구성할 각 머신 구성 풀에 대해 별도의 MachineConfig 오브젝트가 필요합니다.

중요

사용자 정의 계층 이미지를 구성하면 OpenShift Container Platform에서 더 이상 사용자 정의 계층 이미지를 사용하는 노드를 자동으로 업데이트하지 않습니다. 필요에 따라 노드를 수동으로 업데이트해야 합니다. 사용자 정의 계층을 롤백하면 OpenShift Container Platform에서 노드를 자동으로 업데이트합니다. 사용자 지정 계층화된 이미지를 사용하는 노드 업데이트에 대한 중요한 정보는 다음 추가 리소스 섹션을 참조하십시오.

사전 요구 사항

  • 태그가 아닌 OpenShift Container Platform 이미지 다이제스트를 기반으로 하는 사용자 정의 계층 이미지를 생성해야 합니다.

    참고

    나머지 클러스터에 설치된 동일한 기본 RHCOS 이미지를 사용해야 합니다. oc adm release info --image-for rhel-coreos 명령을 사용하여 클러스터에서 사용 중인 기본 이미지를 가져옵니다.

    예를 들어 다음 Containerfile은 OpenShift Container Platform 4.16 이미지에서 사용자 정의 계층 이미지를 생성하고 CentOS 9 Stream의 커널 패키지를 덮어씁니다.

    사용자 정의 계층 이미지의 컨테이너 파일 예

    # Using a 4.16.0 image
FROM quay.io/openshift-release/ocp-release@sha256...
    1 
    
#Install hotfix rpm
RUN rpm-ostree override replace http://mirror.stream.centos.org/9-stream/BaseOS/x86_64/os/Packages/kernel-{,core-,modules-,modules-core-,modules-extra-}5.14.0-295.el9.x86_64.rpm && \
    2 
    
    rpm-ostree cleanup -m && \
    ostree container commit
    Copy to Clipboard

    1
    클러스터의 RHCOS 기본 이미지를 지정합니다.
    2
    커널 패키지를 대체합니다.
    참고

    Containerfile을 생성하는 방법에 대한 지침은 이 문서의 범위를 벗어납니다.

  • 사용자 정의 계층 이미지를 빌드하는 프로세스는 클러스터 외부에서 수행되므로 Podman 또는 Buildah와 함께 --authfile /path/to/pull-secret 옵션을 사용해야 합니다. 또는 이러한 툴에서 풀 시크릿을 자동으로 읽을 수 있도록 기본 파일 위치( ~/.docker/config.json,$XDG_RUNTIME_DIR/containers/auth.json,~/.docker/config.json 또는 ~/.dockercfg ) 중 하나에 추가할 수 있습니다. 자세한 내용은 containers-auth.json 도움말 페이지를 참조하십시오.
  • 사용자 정의 계층 이미지를 클러스터가 액세스할 수 있는 리포지토리로 푸시해야 합니다.

프로세스

  1. 머신 구성 파일을 생성합니다.

    1. 다음과 유사한 YAML 파일을 생성합니다. 

      apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
      1 
      
  name: os-layer-custom
spec:
  osImageURL: quay.io/my-registry/custom-image@sha256...
      2
      Copy to Clipboard
      1
      사용자 지정 계층 이미지를 적용할 머신 구성 풀을 지정합니다.
      2
      리포지토리의 사용자 지정 계층화된 이미지의 경로를 지정합니다.

    2. MachineConfig 오브젝트를 생성합니다. 

      $ oc create -f <file_name>.yaml
      Copy to Clipboard
      중요

      클러스터에 롤아웃하기 전에 프로덕션 환경 외부의 이미지를 테스트하는 것이 좋습니다.

검증

다음 점검 중 하나를 수행하여 사용자 정의 계층 이미지가 적용되었는지 확인할 수 있습니다.

  1. 작업자 머신 구성 풀이 새 머신 구성을 사용하여 롤아웃되었는지 확인합니다.

    1. 새 머신 구성이 생성되었는지 확인합니다. 

      $ oc get mc
      Copy to Clipboard

      샘플 출력

      NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
00-master                                          5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
00-worker                                          5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
01-master-container-runtime                        5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
01-master-kubelet                                  5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
01-worker-container-runtime                        5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
01-worker-kubelet                                  5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
99-master-generated-registries                     5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
99-master-ssh                                                                                 3.2.0             98m
99-worker-generated-registries                     5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
99-worker-ssh                                                                                 3.2.0             98m
os-layer-custom                                                                                                 10s
      1 
      
rendered-master-15961f1da260f7be141006404d17d39b   5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
rendered-worker-5aff604cb1381a4fe07feaf1595a797e   5bdb57489b720096ef912f738b46330a8f577803   3.2.0             95m
rendered-worker-5de4837625b1cbc237de6b22bc0bc873   5bdb57489b720096ef912f738b46330a8f577803   3.2.0             4s
      2
      Copy to Clipboard

      1
      새 머신 구성
      2
      새로 렌더링된 머신 구성

    2. 새 머신 구성의 osImageURL 값이 예상 이미지를 가리키는지 확인합니다. 

      $ oc describe mc rendered-master-4e8be63aef68b843b546827b6ebe0913
      Copy to Clipboard

      출력 예

      Name:         rendered-master-4e8be63aef68b843b546827b6ebe0913
Namespace:
Labels:       <none>
Annotations:  machineconfiguration.openshift.io/generated-by-controller-version: 8276d9c1f574481043d3661a1ace1f36cd8c3b62
              machineconfiguration.openshift.io/release-image-version: 4.16.0-ec.3
API Version:  machineconfiguration.openshift.io/v1
Kind:         MachineConfig
...
  Os Image URL: quay.io/my-registry/custom-image@sha256...
      Copy to Clipboard

    3. 연결된 머신 구성 풀이 새 머신 구성을 사용하여 업데이트되었는지 확인합니다. 

      $ oc get mcp
      Copy to Clipboard

      샘플 출력

      NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master   rendered-master-6faecdfa1b25c114a58cf178fbaa45e2   True      False      False      3              3                   3                     0                      39m
worker   rendered-worker-6b000dbc31aaee63c6a2d56d04cd4c1b   False     True       False      3              0                   0                     0                      39m
      1
      Copy to Clipboard

      1
      UPDATING 필드가 True 이면 머신 구성 풀이 새 머신 구성으로 업데이트됩니다. 필드가 False 가 되면 작업자 머신 구성 풀이 새 머신 구성에 롤아웃됩니다.

    4. 노드를 확인하여 노드의 스케줄링이 비활성화되어 있는지 확인합니다. 변경 사항이 적용 중임을 나타냅니다. 

      $ oc get nodes
      Copy to Clipboard

      출력 예

      NAME                                         STATUS                     ROLES                  AGE   VERSION
ip-10-0-148-79.us-west-1.compute.internal    Ready                      worker                 32m   v1.29.4
ip-10-0-155-125.us-west-1.compute.internal   Ready,SchedulingDisabled   worker                 35m   v1.29.4
ip-10-0-170-47.us-west-1.compute.internal    Ready                      control-plane,master   42m   v1.29.4
ip-10-0-174-77.us-west-1.compute.internal    Ready                      control-plane,master   42m   v1.29.4
ip-10-0-211-49.us-west-1.compute.internal    Ready                      control-plane,master   42m   v1.29.4
ip-10-0-218-151.us-west-1.compute.internal   Ready                      worker                 31m   v1.29.4
      Copy to Clipboard

  2. 노드가 Ready 상태가 되면 노드가 사용자 정의 계층화된 이미지를 사용하고 있는지 확인합니다.

    1. 노드에 대한 oc 디버그 세션을 엽니다. 예를 들면 다음과 같습니다. 

      $ oc debug node/ip-10-0-155-125.us-west-1.compute.internal
      Copy to Clipboard

    2. 디버그 쉘 내에서 /host를 root 디렉터리로 설정합니다. 

      sh-4.4# chroot /host
      Copy to Clipboard

    3. rpm-ostree status 명령을 실행하여 사용자 정의 계층화된 이미지가 사용 중인지 확인합니다. 

      sh-4.4# sudo rpm-ostree status
      Copy to Clipboard

      출력 예

      State: idle
Deployments:
* ostree-unverified-registry:quay.io/my-registry/...
                   Digest: sha256:...
      Copy to Clipboard

추가 리소스

RHCOS 사용자 정의 계층 이미지로 업데이트

7.5. RHCOS 사용자 정의 계층 이미지 제거

특정 머신 구성 풀의 노드에서 RHCOS(Red Hat Enterprise Linux CoreOS) 이미지 계층을 쉽게 되돌릴 수 있습니다. MCO(Machine Config Operator)는 클러스터 기본 RHCOS(Red Hat Enterprise Linux CoreOS) 이미지가 있는 노드를 재부팅하여 사용자 정의 계층 이미지를 덮어씁니다.

클러스터에서 RHCOS(Red Hat Enterprise Linux CoreOS) 사용자 정의 계층화된 이미지를 제거하려면 이미지를 적용한 머신 구성을 삭제해야 합니다.

프로세스

  1. 사용자 정의 계층 이미지를 적용한 머신 구성을 삭제합니다. 

    $ oc delete mc os-layer-custom
    Copy to Clipboard

    머신 구성을 삭제한 후 노드가 재부팅됩니다.

검증

다음 검사를 수행하여 사용자 정의 계층 이미지가 제거되었는지 확인할 수 있습니다.

  1. 이전 머신 구성을 사용하여 작업자 머신 구성 풀이 업데이트되었는지 확인합니다. 

    $ oc get mcp
    Copy to Clipboard

    샘플 출력

    NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master   rendered-master-6faecdfa1b25c114a58cf178fbaa45e2   True      False      False      3              3                   3                     0                      39m
worker   rendered-worker-6b000dbc31aaee63c6a2d56d04cd4c1b   False     True       False      3              0                   0                     0                      39m
    1
    Copy to Clipboard

    1
    UPDATING 필드가 True 이면 머신 구성 풀이 이전 머신 구성으로 업데이트됩니다. 필드가 False 가 되면 작업자 머신 구성 풀이 이전 머신 구성에 롤아웃됩니다.

  2. 노드를 확인하여 노드의 스케줄링이 비활성화되어 있는지 확인합니다. 변경 사항이 적용 중임을 나타냅니다. 

    $ oc get nodes
    Copy to Clipboard

    출력 예

    NAME                                         STATUS                     ROLES                  AGE   VERSION
ip-10-0-148-79.us-west-1.compute.internal    Ready                      worker                 32m   v1.29.4
ip-10-0-155-125.us-west-1.compute.internal   Ready,SchedulingDisabled   worker                 35m   v1.29.4
ip-10-0-170-47.us-west-1.compute.internal    Ready                      control-plane,master   42m   v1.29.4
ip-10-0-174-77.us-west-1.compute.internal    Ready                      control-plane,master   42m   v1.29.4
ip-10-0-211-49.us-west-1.compute.internal    Ready                      control-plane,master   42m   v1.29.4
ip-10-0-218-151.us-west-1.compute.internal   Ready                      worker                 31m   v1.29.4
    Copy to Clipboard

  3. 노드가 Ready 상태가 되면 노드가 기본 이미지를 사용하고 있는지 확인합니다.

    1. 노드에 대한 oc 디버그 세션을 엽니다. 예를 들면 다음과 같습니다. 

      $ oc debug node/ip-10-0-155-125.us-west-1.compute.internal
      Copy to Clipboard

    2. 디버그 쉘 내에서 /host를 root 디렉터리로 설정합니다. 

      sh-4.4# chroot /host
      Copy to Clipboard

    3. rpm-ostree status 명령을 실행하여 사용자 정의 계층화된 이미지가 사용 중인지 확인합니다. 

      sh-4.4# sudo rpm-ostree status
      Copy to Clipboard

      출력 예

      State: idle
Deployments:
* ostree-unverified-registry:podman pull quay.io/openshift-release-dev/ocp-release@sha256:e2044c3cfebe0ff3a99fc207ac5efe6e07878ad59fd4ad5e41f88cb016dacd73
                   Digest: sha256:e2044c3cfebe0ff3a99fc207ac5efe6e07878ad59fd4ad5e41f88cb016dacd73
      Copy to Clipboard

7.6. RHCOS 사용자 정의 계층 이미지로 업데이트

RHCOS(Red Hat Enterprise Linux CoreOS) 이미지 계층 지정을 구성하면 OpenShift Container Platform에서 사용자 정의 계층 이미지를 사용하는 노드 풀을 자동으로 업데이트하지 않습니다. 필요에 따라 노드를 수동으로 업데이트해야 합니다.

사용자 정의 계층 이미지를 사용하는 노드를 업데이트하려면 다음 일반 단계를 따르십시오.

  1. 클러스터는 사용자 정의 계층 이미지를 사용하는 노드를 제외하고 x.y.z+1 버전으로 자동으로 업그레이드합니다.
  2. 그런 다음 업데이트된 OpenShift Container Platform 이미지와 이전에 적용한 RPM을 참조하는 새 Containerfile을 생성할 수 있습니다.
  3. 업데이트된 사용자 정의 계층 이미지를 가리키는 새 머신 구성을 생성합니다.

사용자 정의 계층 이미지로 노드를 업데이트할 필요는 없습니다. 그러나 해당 노드가 현재 OpenShift Container Platform 버전보다 너무 멀리 떨어져 있으면 예기치 않은 결과가 발생할 수 있습니다.

8장. 머신 구성 데몬 메트릭 개요

머신 구성 데몬은 Machine Config Operator의 일부입니다. 클러스터의 모든 노드에서 실행됩니다. 머신 구성 데몬은 각 노드의 구성 변경 및 업데이트를 관리합니다.

8.1. 머신 구성 데몬 메트릭 이해

OpenShift Container Platform 4.3부터는 머신 구성 데몬에서 일련의 메트릭을 제공합니다. 이러한 메트릭은 Prometheus 클러스터 모니터링 스택을 사용하여 액세스할 수 있습니다.

다음 테이블에 이러한 메트릭 집합이 설명되어 있습니다. 일부 항목에는 특정 로그를 가져오는 명령이 포함되어 있습니다. Hpwever: oc adm must-gather 명령을 사용하여 가장 포괄적인 로그 세트를 사용할 수 있습니다.

참고

이름 및 설명 열에서 * 로 표시된 메트릭은 성능 문제가 발생할 수 있는 심각한 오류를 나타냅니다. 이러한 문제가 발생하면 업데이트 및 업그레이드가 진행되지 않을 수 있습니다.

표 8.1. MCO 메트릭
이름형식설명참고

mcd_host_os_and_version

[]string{"os", "version"}

MCD가 실행 중인 OS(예: RHCOS 또는 RHEL)를 표시합니다. RHCOS의 경우 버전이 제공됩니다.

 

mcd_drain_err*

 

드레이닝 실패 중 수신한 오류를 기록합니다. *

드레이닝에 성공하려면 여러 번 시도해야 할 수 있지만 터미널에서 드레이닝이 실패하면 업데이트가 진행되지 않습니다. drain_time 메트릭은 드레이닝에 걸린 시간을 표시하며 문제 해결에 도움이 될 수 있습니다.

추가 조사가 필요한 경우 다음을 실행하여 로그를 참조하십시오.

$ oc logs -f -n openshift-machine-config-operator machine-config-daemon-<hash> -c machine-config-daemon

mcd_pivot_err*

[]string{"err", "node", "pivot_target"}

피벗 중 로그 오류가 발생했습니다. *

피벗 오류로 인해 OS 업그레이드가 진행되지 않을 수 있습니다.

추가 조사를 수행하려면 다음 명령을 실행하여 machine-config-daemon 컨테이너의 로그를 확인합니다.

$ oc logs -f -n openshift-machine-config-operator machine-config-daemon-<hash> -c machine-config-daemon

mcd_state

[]string{"state", "reason"}

표시된 노드의 머신 구성 데몬 상태입니다. 가능한 상태는 "완료", "작업 중", "저하됨"입니다. "저하됨"의 경우 이유가 포함됩니다.

추가 조사가 필요한 경우 다음을 실행하여 로그를 참조하십시오.

$ oc logs -f -n openshift-machine-config-operator machine-config-daemon-<hash> -c machine-config-daemon

mcd_kubelet_state*

 

kubelet 상태 장애를 기록합니다. *

이 값은 비어 있고 실패 횟수가 0이어야 합니다. 실패 횟수가 2를 초과하면 임계값이 초과되었음을 나타내는 오류입니다. 이는 kubelet 상태에 문제가 있을 수 있음을 나타냅니다.

추가 조사를 수행하려면 다음 명령을 실행하여 노드에 액세스한 후 해당 로그를 모두 확인합니다.

$ oc debug node/<node> — chroot /host journalctl -u kubelet

mcd_reboot_err*

[]string{"message", "err", "node"}

실패한 재부팅 및 해당 오류를 기록합니다. *

이 값은 비어 있을 것으로 예상되며, 재부팅에 성공했음을 나타냅니다.

추가 조사가 필요한 경우 다음을 실행하여 로그를 참조하십시오.

$ oc logs -f -n openshift-machine-config-operator machine-config-daemon-<hash> -c machine-config-daemon

mcd_update_state

[]string{"config", "err"}

구성 업데이트의 성공 또는 실패와 해당 오류를 기록합니다.

예상 값은 rendered-master/rendered-worker-XXXX입니다. 업데이트에 실패하면 오류가 발생합니다.

추가 조사가 필요한 경우 다음을 실행하여 로그를 참조하십시오.

$ oc logs -f -n openshift-machine-config-operator machine-config-daemon-<hash> -c machine-config-daemon

Legal Notice

Copyright © 2024 Red Hat, Inc.

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2025 Red Hat, Inc.