7장. RHCOS(Red Hat Enterprise Linux CoreOS)
7.1. RHCOS 소개
RHCOS(Red Hat Enterprise Linux CoreOS)는 자동화된 원격 업그레이드 기능을 갖춘 RHEL(Red Hat Enterprise Linux)의 품질 표준을 제공하여 차세대 단일 목적 컨테이너 운영 체제 기술을 나타냅니다.
RHCOS는 모든 OpenShift Container Platform 머신에 대해 OpenShift Container Platform 4.9의 구성 요소로만 지원됩니다. RHCOS는 OpenShift Container Platform 컨트롤 플레인 머신 또는 마스터 머신에 지원되는 유일한 운영 체제입니다. RHCOS는 모든 클러스터 머신의 기본 운영 체제이지만 RHEL을 운영 체제로 사용하는 작업자 머신이라고도 하는 컴퓨팅 머신을 생성할 수 있습니다. OpenShift Container Platform 4.9에 RHCOS를 배포하는 일반적인 방법에는 두 가지가 있습니다.
- 설치 프로그램이 프로비저닝하는 인프라에 클러스터를 설치하면 설치 중에 RHCOS 이미지가 대상 플랫폼으로 다운로드됩니다. RHCOS 구성을 제어하는 적합한 Ignition 구성 파일도 다운로드하여 머신을 배포하는 데 사용됩니다.
- 관리하는 인프라에 클러스터를 설치하는 경우 설치 문서에 따라 RHCOS 이미지를 얻고, Ignition 구성 파일을 생성하며, Ignition 구성 파일을 사용하여 머신을 프로비저닝해야 합니다.
7.1.1. 주요 RHCOS 기능
다음 목록은 RHCOS 운영 체제의 주요 기능을 설명합니다.
- RHEL 기반: 기본 운영 체제는 주로 RHEL 구성 요소로 구성됩니다. RHEL을 지원하는 동일한 품질, 보안 및 제어 수단도 RHCOS를 지원합니다. 예를 들어, RHCOS 소프트웨어는 RPM 패키지에 있으며 각 RHCOS 시스템은 RHEL 커널과 systemd init 시스템에서 관리하는 일련의 서비스로 시작됩니다.
- 제어된 불변성: RHEL 구성 요소가 포함되어 있지만 RHCOS는 기본 RHEL 설치보다 더 엄격하게 관리되도록 설계되었습니다. OpenShift Container Platform 클러스터에서 원격으로 관리가 수행됩니다. RHCOS 머신을 설정할 때 몇 가지 시스템 설정만 수정할 수 있습니다. 이러한 제어된 불변성을 통해 OpenShift Container Platform이 클러스터에 최신 상태의 RHCOS 시스템을 저장할 수 있으므로, 항상 추가 머신을 생성하고 최신 RHCOS 구성에 따라 업데이트를 수행할 수 있습니다.
- CRI-O 컨테이너 런타임: RHCOS에는 Docker에 필요한 OCI 및 libcontainer 형식 컨테이너를 실행하는 기능이 포함되어 있지만 Docker 컨테이너 엔진 대신 CRI-O 컨테이너 엔진을 통합합니다. OpenShift Container Platform과 같은 Kubernetes 플랫폼에 필요한 기능에 중점을 두어 CRI-O는 다양한 Kubernetes 버전과의 특정 호환성을 제공할 수 있습니다. CRI-O에서는 더 큰 기능 세트를 제공하는 컨테이너 엔진으로 가능한 것보다 작은 설치 공간과 감소된 공격 면적을 제공합니다. 현재 CRI-O는 OpenShift Container Platform 클러스터 내에서만 사용할 수 있는 엔진입니다.
-
컨테이너 도구 세트: 컨테이너 빌드, 복사 및 관리와 같은 작업의 경우 RHCOS는 Docker CLI 도구를 호환 가능한 컨테이너 도구 세트로 대체합니다. podman CLI 도구에서는 컨테이너 및 컨테이너 이미지 실행, 시작, 중지, 나열 및 제거와 같은 많은 컨테이너 런타임 기능을 지원합니다. skopeo CLI 도구를 통해서는 이미지를 복사, 인증 및 서명할 수 있습니다.
crictlCLI 도구를 사용하여 CRI-O 컨테이너 엔진의 컨테이너 및 포드에 대해 작업할 수 있습니다. RHCOS에서 이러한 도구를 직접 사용하는 것은 좋지 않지만 디버깅 목적으로 사용할 수 있습니다. -
rpm-ostree upgrades: RHCOS에서
rpm-ostree시스템을 사용하여 트랜잭션 업그레이드를 제공합니다. 업데이트는 컨테이너 이미지를 통해 제공되며 OpenShift Container Platform 업데이트 프로세스의 일부입니다. 배포되면 컨테이너 이미지를 가져와서 추출하고 디스크에 쓴 다음, 부트 로더가 새 버전으로 부팅되도록 수정됩니다. 클러스터 용량에 미치는 영향을 최소화하기 위해 머신이 롤링 방식으로 업데이트되게 재부팅됩니다. bootupd 펌웨어 및 부트로더 업데이트 도구: 패키지 관리자 및
rpm-ostree와 같은 하이브리드 시스템은 펌웨어 또는 부트로더를 업데이트하지 않습니다.bootupd를 사용하는 RHCOS 사용자는 최신 아키텍처 (x86_64, ppc64le, aarch64 등)에서 실행되는 UEFI 및 레거시 BIOS 부팅 모드 펌웨어 및 부팅 업데이트를 관리하는 교차 배포 시스템 관련 OS 업데이트 툴에 액세스할 수 있습니다.bootupd설치 방법에 대한 자세한 내용은 bootupd를 사용하여 부트로더 업데이트 설명서를 참조하십시오.-
Machine Config Operator를 통해 업데이트: OpenShift Container Platform에서 Machine Config Operator는 운영 체제 업그레이드를 처리합니다.
yum업그레이드와 마찬가지로 개별 패키지를 업그레이드하는 대신rpm-ostree는 원자 단위로 OS 업그레이드를 제공합니다. 새 OS 배포는 업그레이드 중에 준비되며 다음에 다시 부팅할 때 적용됩니다. 업그레이드에 문제가 있으면 단일 롤백 및 재부팅을 통해 시스템을 이전 상태로 되돌립니다. OpenShift Container Platform의 RHCOS 업그레이드는 클러스터 업데이트 중에 수행됩니다.
RHCOS 시스템의 경우 rpm-ostree 파일 시스템의 레이아웃은 다음과 같은 특징이 있습니다.
-
/usr은 운영 체제 바이너리 및 라이브러리가 저장되는 위치이며 읽기 전용입니다. 이 변경은 지원하지 않습니다. -
/etc,/boot,/var은 시스템에 쓸 수 있지만 Machine Config Operator를 통해서만 변경될 수 있습니다. -
/var/lib/containers는 컨테이너 이미지를 저장하기 위한 그래프 스토리지 위치입니다.
7.1.2. RHCOS 구성 방법 선택
RHCOS는 최소한의 사용자 구성으로 OpenShift Container Platform 클러스터에 배포하도록 설계되었습니다. 가장 기본적인 형태로 다음과 같이 구성됩니다.
- AWS와 같은 프로비저닝된 인프라로 시작하거나 인프라를 직접 프로비저닝.
-
openshift-install을 실행할 때install-config.yaml파일에 자격 증명과 클러스터 이름과 같은 몇 가지 정보를 제공합니다.
그 이후 OpenShift Container Platform의 RHCOS 시스템은 OpenShift Container Platform 클러스터에서 완전히 관리되도록 설계되었으므로 RHCOS 머신을 직접 변경하는 것은 좋지 않습니다. 디버깅 목적으로 RHCOS 머신 클러스터에 대한 직접 액세스를 제한할 수 있지만 RHCOS 시스템을 직접 구성해서는 안 됩니다. 대신 OpenShift Container Platform 노드에서 기능을 추가하거나 변경해야 하는 경우 다음과 같은 방식으로 변경해 보십시오.
- Kubernetes 워크로드 개체 (DaemonSet 및 Deployment 등): 서비스 또는 기타 사용자 수준 기능을 클러스터에 추가해야 하는 경우 Kubernetes 워크로드 개체로 추가하는 것이 좋습니다. 특정 노드 구성 외부에서 이 기능을 유지하는 것이 후속 업그레이드에서 클러스터를 중단할 위험을 줄이는 가장 좋은 방법입니다.
- 2일 차 사용자 정의: 가능하면 클러스터 노드를 사용자 정의하지 않고 클러스터를 작동시키며 클러스터가 가동된 후 필요한 노드를 변경합니다. 이와 같이 변경하면 나중에 추적하기가 쉬워지고 업데이트를 중단할 가능성이 적어집니다. 이러한 사용자 정의 방법으로 머신 구성을 생성하거나 Operator 사용자 정의 리소스를 수정할 수 있습니다.
-
1일 차 사용자 정의: 클러스터가 처음 표시될 때 구현해야 하는 사용자 정의의 경우 최초 부팅 시 변경사항이 구현되도록 클러스터를 수정하는 방법이 있습니다. 1일 차 사용자 정의는
openshift-install중에 Ignition 구성 및 매니페스트 파일을 통해 수행하거나 사용자가 프로비저닝한 ISO 설치 중에 부트 옵션을 추가하여 수행할 수 있습니다.
1일 차에 수행할 수 있는 사용자 정의의 예는 다음과 같습니다.
- 커널 인수: 클러스터가 최초 부팅될 때 노드에서 특정 커널 기능 또는 조정이 필요한 경우.
- 디스크 암호화: 보안상 FIPS 지원과 같이 노드의 루트 파일 시스템을 암호화해야 하는 경우.
- 커널 모듈: 네트워크 카드 또는 비디오 카드와 같은 특정 하드웨어 장치에 Linux 커널에서 기본적으로 사용 가능한 모듈이 없는 경우.
- Chronyd: 시간 서버의 위치와 같은 특정 시계 설정을 노드에 제공하려는 경우.
이러한 작업을 수행하려면 MachineConfig 오브젝트와 같은 추가 오브젝트를 포함하도록 openshift-install 프로세스를 보강할 수 있습니다. 머신 구성을 생성하는 절차는 클러스터가 가동된 후 Machine Config Operator에 전달될 수 있습니다.
-
설치 프로그램에서 생성하는 Ignition 구성 파일에 24시간 후에 만료되는 인증서가 포함되어 있습니다. 이 인증서는 그 후에 갱신됩니다. 인증서를 갱신하기 전에 클러스터가 종료되고 24시간이 지난 후에 클러스터가 다시 시작되면 클러스터는 만료된 인증서를 자동으로 복구합니다. 예외적으로 kubelet 인증서를 복구하려면 대기 중인
node-bootstrapper인증서 서명 요청(CSR)을 수동으로 승인해야 합니다. 자세한 내용은 만료된 컨트롤 플레인 인증서에서 복구 문서를 참조하십시오. - 클러스터를 설치한 후 24시간에서 22시간까지의 인증서가 교체되기 때문에 생성된 후 12시간 이내에 Ignition 구성 파일을 사용하는 것이 좋습니다. 12시간 이내에 Ignition 구성 파일을 사용하면 설치 중에 인증서 업데이트가 실행되는 경우 설치 실패를 방지할 수 있습니다.
7.1.3. RHCOS 배포 방법 선택
OpenShift Container Platform용 RHCOS 설치 간의 차이점은 설치 프로그램이 프로비저닝한 인프라에 배포하는지 아니면 사용자가 프로비저닝한 인프라에 배포하는지에 따라 다릅니다.
- 설치 관리자 프로비저닝: 일부 클라우드 환경은 최소한의 구성으로 OpenShift Container Platform 클러스터를 시작할 수 있는 사전 구성된 인프라를 제공합니다. 이러한 유형의 설치에서는 클러스터가 최초 부팅될 때 준비되도록 각 노드에 콘텐츠를 배치하는 Ignition 구성을 제공할 수 있습니다.
- 사용자 프로비저닝: 자체 인프라를 프로비저닝하는 경우 RHCOS 노드에 컨텐츠를 추가하는 방법에 있어 유연성이 향상됩니다. 예를 들어, RHCOS ISO 설치 프로그램을 부팅하여 각 시스템을 설치할 때 커널 인수를 추가할 수 있습니다. 그러나 운영 체제 자체에서 구성이 필요한 대부분의 경우 Ignition 구성을 통해 해당 구성을 제공하는 것이 가장 좋습니다.
Ignition 기능은 RHCOS 시스템이 처음 설정된 경우에만 실행됩니다. 그런 다음 나중에 머신 구성을 사용하여 Ignition 구성을 제공할 수 있습니다.
7.1.4. Ignition 정보
Ignition은 RHCOS가 초기 구성 중에 디스크를 조작하는 데 사용하는 유틸리티입니다. 디스크 파티셔닝, 파티션 포맷, 파일 작성 및 사용자 구성을 포함한 일반적인 디스크 작업을 완료합니다. 최초 부팅 시 Ignition은 설치 미디어 또는 사용자가 지정한 위치에서 구성을 읽고 해당 구성을 머신에 적용합니다.
클러스터를 설치하든 클러스터에 머신을 추가하든 Ignition은 항상 OpenShift Container Platform 클러스터 머신의 초기 구성을 수행합니다. 실제 시스템 설정의 대부분은 각 머신 자체에서 수행됩니다. 머신마다 Ignition은 RHCOS 이미지를 가져와서 RHCOS 커널을 부팅합니다. 커널 명령줄의 옵션은 배포 유형과 Ignition 사용 초기 RAM 디스크(initramfs)의 위치를 식별합니다.
7.1.4.1. Ignition 작동 방식
Ignition을 사용하여 머신을 생성하려면 Ignition 구성 파일이 필요합니다. OpenShift Container Platform 설치 프로그램은 클러스터를 배포하는 데 필요한 Ignition 구성 파일을 생성합니다. 이러한 파일은 설치 프로그램에 직접 또는 install-config.yaml 파일을 통해 제공한 정보를 기반으로 합니다.
Ignition이 머신을 구성하는 방법은 cloud-init 또는 Linux Anaconda kickstart와 같은 도구가 시스템을 구성하는 방법과 유사하지만 몇 가지 중요한 차이점이 있습니다.
- Ignition은 설치하려는 시스템과 별도의 초기 RAM 디스크에서 실행됩니다. 따라서 Ignition은 디스크를 다시 파티셔닝하고 파일 시스템을 설정하며 머신의 영구 파일 시스템을 변경할 수 있습니다. 반대로 cloud-init는 시스템을 부팅할 때 시스템 init 시스템의 일부로 실행되므로 디스크 파티션과 같은 작업을 근본적으로 변경할 수 없습니다. cloud-init에서는 노드 부팅 프로세스 도중에 부팅 프로세스를 재구성하기가 어렵습니다.
- Ignition은 기존 시스템을 변경하지 않고 시스템을 초기화하기 위한 것입니다. 머신이 초기화되고 설치된 시스템에서 커널이 실행된 후 OpenShift Container Platform 클러스터의 Machine Config Operator가 향후 머신 구성을 모두 완료합니다.
- 정의된 작업 세트를 완료하는 대신 Ignition은 선언적 구성을 구현합니다. 새 머신이 시작되기 전에 모든 파티션, 파일, 서비스 및 기타 항목이 제 위치에 있는지 확인합니다. 그런 다음 새 머신이 지정된 구성을 충족시키는 데 필요한 파일을 디스크에 복사하는 등의 변경을 수행합니다.
- Ignition이 머신 구성을 마치면 커널은 계속 실행되지만 초기 RAM 디스크를 버리고 디스크의 설치된 시스템으로 전환합니다. 시스템을 재부팅하지 않아도 모든 새로운 시스템 서비스 및 기타 기능이 시작됩니다.
- Ignition은 모든 새 머신이 선언된 구성을 충족하는지 확인하므로 부분적으로 구성된 머신을 가질 수 없습니다. 머신 설정에 실패하면 초기화 프로세스가 완료되지 않고 Ignition이 새 머신을 시작하지 않습니다. 클러스터에 부분적으로 구성된 머신이 포함되어 있지 않습니다. Ignition을 완료할 수 없으면 머신이 클러스터에 추가되지 않습니다. 대신 새 머신을 추가해야 합니다. 그러면 구성 작업에 종속된 항목이 나중에 실패할 때까지 실패한 구성 작업의 결과를 알 수 없을 때 머신을 디버깅하기 어려운 상황이 방지됩니다.
- 머신 설정에 실패하게 만드는 Ignition 구성에 문제가 있는 경우, Ignition은 동일한 구성을 사용하여 다른 머신을 설정하려고 시도하지 않습니다. 예를 들어, 동일한 파일을 생성하려는 상위 및 하위 구성으로 구성된 Ignition 구성 때문에 실패할 수 있습니다. 이러한 경우 문제가 해결될 때까지 다른 머신을 설정하는 데 Ignition 구성이 다시 사용되지 않도록 방지할 수 있습니다.
- 여러 개의 Ignition 구성 파일이 있으면 해당 구성 세트를 통합합니다. Ignition은 선언적이므로 구성 간의 충돌 때문에 Ignition이 머신을 설정하지 못할 수 있습니다. 해당 파일의 정보 순서는 중요하지 않습니다. Ignition은 가장 적합한 방식으로 각 설정을 정렬하고 구현합니다. 예를 들어, 파일에 여러 수준의 디렉터리가 필요한 경우 다른 파일에 해당 경로를 따라 디렉터리가 필요한 경우 나중 파일이 먼저 생성됩니다. Ignition은 모든 파일, 디렉토리 및 링크를 수준별로 정렬하고 생성합니다.
- Ignition은 완전히 비어 있는 하드 디스크로 시작할 수 있기 때문에 cloud-init에서 수행할 수 없는 작업을 수행할 수 있습니다. PXE 부팅과 같은 기능을 사용하여 처음부터 베어 메탈에 시스템을 설정합니다. 베어 메탈의 경우 Ignition 구성이 부트 파티션에 삽입되어 Ignition 구성이 이를 찾아서 시스템을 올바르게 구성할 수 있습니다.
7.1.4.2. Ignition 순서
OpenShift Container Platform 클러스터에 있는 RHCOS 머신의 Ignition 프로세스에는 다음 단계가 포함됩니다.
- 머신이 Ignition 구성 파일을 가져옵니다. 컨트롤 플레인 머신은 부트스트랩 머신에서 Ignition 구성 파일을 가져오고 작업자 머신은 컨트롤 플레인 머신에서 Ignition 구성 파일을 가져옵니다.
- Ignition은 머신에 디스크 파티션, 파일 시스템, 디렉토리 및 링크를 생성합니다. RAID 어레이는 지원하지만 LVM 볼륨은 지원하지 않습니다.
-
Ignition은 initramfs의
/sysroot디렉터리에 영구 파일 시스템의 루트를 마운트하고 해당/sysroot디렉터리에서 작동을 시작합니다. - Ignition은 정의된 모든 파일 시스템을 구성하고 런타임 시 적절히 마운트되도록 설정합니다.
-
Ignition은
systemd임시 파일을 실행하여/var디렉터리에 필요한 파일을 채웁니다. - Ignition은 Ignition 구성 파일을 실행하여 사용자, systemd 장치 파일 및 기타 구성 파일을 설정합니다.
- Ignition에서는 initramfs에 마운트된 영구 시스템의 모든 구성 요소를 마운트 해제합니다.
- Ignition은 새 머신의 init 프로세스를 시작하여 시스템 부팅 중에 실행되는 머신에서 다른 모든 서비스가 시작됩니다.
이 프로세스가 끝나면 시스템에서 클러스터에 참여할 준비가 되었으며 재부팅할 필요가 없습니다.
