2.6. 연결이 끊긴 환경에서 IBM Z 및 IBM LinuxONE에 RHEL KVM을 사용하여 클러스터 설치

2.6.1. 사전 요구 사항
링크 복사

사용자 제공 인프라를 사용하여 IBM Z에 클러스터 설치 준비 작업을 완료했습니다.
OpenShift Container Platform 설치 및 업데이트 프로세스에 대한 세부 정보를 검토했습니다.
클러스터 설치 방법을 선택하고 사용자를 위해 준비하는 방법 에 대한 설명서를 읽어보세요.
연결이 끊긴 설치에 대한 이미지를 레지스트리에 미러링 하고 OpenShift Container Platform 버전에 대한 imageContentSources 데이터를 얻었습니다.
설치 프로세스를 시작하기 전에 기존 설치 파일을 이동하거나 제거해야 합니다. 이렇게 하면 설치 프로세스 중에 필요한 설치 파일이 생성되고 업데이트됩니다.
중요
설치 미디어에 액세스할 수있는 시스템에서 설치 프로세스를 수행해야 합니다.
클러스터에 대해 OpenShift Data Foundation이나 기타 지원되는 스토리지 프로토콜을 사용하여 영구 스토리지를 프로비저닝했습니다. 프라이빗 이미지 레지스트리를 배포하려면 ReadWriteMany 액세스 권한을 사용하여 영구 스토리지를 설정해야 합니다.
방화벽을 사용하는 경우 클러스터가 액세스해야 하는 사이트를 허용하도록 구성했습니다 .
참고
프록시를 구성하는 경우에도 해당 사이트 목록을 검토하십시오.
논리 파티션(LPAR)에 호스팅되고 RHEL 8.6 이상을 기반으로 하는 RHEL 커널 가상 머신(KVM) 시스템을 프로비저닝했습니다. Red Hat Enterprise Linux 8 및 9 수명 주기를 참조하세요.

2.6.2. 네트워크가 제한된 환경에서의 설치 정보
링크 복사

OpenShift Container Platform 4.19에서는 소프트웨어 구성 요소를 얻기 위해 인터넷에 활성 연결을 요구하지 않는 설치를 수행할 수 있습니다. 제한된 네트워크 설치는 클러스터를 설치하는 클라우드 플랫폼에 따라 설치 관리자 프로비저닝 인프라 또는 사용자 프로비저닝 인프라를 사용하여 완료할 수 있습니다.

클라우드 플랫폼에 제한된 네트워크 설치를 수행하는 방법을 선택해도 클라우드 API에 액세스는 가능해야 합니다. Amazon Web Service의 Route 53 DNS 및 IAM 서비스와 같은 일부 클라우드 기능에는 인터넷 액세스가 필요합니다. 네트워크에 따라 베어 메탈 하드웨어, Nutanix 또는 VMware vSphere에 설치하는 경우 인터넷 접속이 덜 필요할 수 있습니다.

제한된 네트워크 설치를 완료하려면 OpenShift 이미지 레지스트리의 내용을 미러링하고 설치 미디어를 포함하는 레지스트리를 만들어야 합니다. 인터넷과 폐쇄 네트워크에 모두 액세스하거나 제한 사항을 따르는 다른 방법을 통해 미러 호스트에 레지스트리를 생성할 수 있습니다.

중요

사용자 프로비저닝 설치의 구성이 복잡하므로 사용자 프로비저닝 인프라를 사용하여 제한된 네트워크 설치를 시도하기 전에 표준 사용자 프로비저닝 인프라 설치를 완료하는 것이 좋습니다. 이 테스트 설치를 완료하면 제한된 네트워크에 설치하는 동안 발생할 수 있는 문제를 보다 쉽게 파악 및 해결할 수 있습니다.

2.6.2.1. 추가 제한
링크 복사

제한된 네트워크의 클러스터에는 다음과 같은 추가 제한이 있습니다.

ClusterVersion 상태에 사용 가능한 업데이트를 검색할 수 없음 오류가 포함되어 있습니다.
기본적으로 필요한 이미지 스트림 태그에 액세스할 수 없기 때문에 개발자 카탈로그의 내용을 사용할 수 없습니다.

2.6.3. 사용자 프로비저닝 인프라 준비
링크 복사

사용자 프로비저닝 인프라에 OpenShift Container Platform을 설치하기 전에 기본 인프라를 준비해야 합니다.

이 섹션에서는 OpenShift Container Platform 설치를 준비하기 위해 클러스터 인프라를 설정하는 데 필요한 높은 수준의 단계에 대해 자세히 설명합니다. 여기에는 클러스터 노드에 대한 IP 네트워킹 및 네트워크 연결 구성, 방화벽을 통해 필요한 포트 활성화, 필수 DNS 및 로드 밸런싱 인프라를 설정하는 작업이 포함됩니다.

준비 후 클러스터 인프라는 사용자 프로비저닝 인프라가 있는 클러스터의 요구 사항 섹션에 설명된 요구 사항을 충족해야 합니다.

사전 요구 사항

OpenShift Container Platform 4.x 테스트된 통합 페이지를 검토했습니다.
사용자 프로비저닝 인프라가 있는 클러스터의 요구 사항 섹션에 자세히 설명된 인프라 요구 사항을 검토했습니다.

프로세스

DHCP를 사용하여 클러스터 노드에 IP 네트워킹 구성을 제공하는 경우 DHCP 서비스를 구성합니다.
1. 노드의 영구 IP 주소를 DHCP 서버 구성에 추가합니다. 구성에서 관련 네트워크 인터페이스의 MAC 주소를 각 노드의 의도한 IP 주소와 일치시킵니다.
2. DHCP를 사용하여 클러스터 시스템의 IP 주소 지정을 구성하는 경우 시스템은 DHCP를 통해 DNS 서버 정보도 가져옵니다. DHCP 서버 구성을 통해 클러스터 노드에서 사용하는 영구 DNS 서버 주소를 정의합니다.
  참고
  DHCP 서비스를 사용하지 않는 경우 RHCOS 설치 시 IP 네트워킹 구성과 DNS 서버의 주소를 노드에 제공해야 합니다. ISO 이미지에서 설치하는 경우 부팅 인수로 전달할 수 있습니다. 고정 IP 프로비저닝 및 고급 네트워킹 옵션에 대한 자세한 내용은 RHCOS 설치 및 OpenShift Container Platform 부트스트랩 프로세스 시작 섹션을 참조하십시오.
3. DHCP 서버 구성에 클러스터 노드의 호스트 이름을 정의합니다. 호스트 이름 고려 사항에 대한 자세한 내용은 DHCP를 통해 클러스터 노드 호스트 이름 설정 섹션을 참조하십시오.
  참고
  DHCP 서비스를 사용하지 않는 경우 클러스터 노드는 역방향 DNS 조회를 통해 호스트 이름을 가져옵니다.
Red Hat Enterprise Linux CoreOS(RHCOS)의 빠른 설치 또는 Red Hat Enterprise Linux CoreOS(RHCOS)의 전체 설치 중 하나를 선택하세요. 전체 설치의 경우 Ignition 파일을 제공하고 클러스터 노드에 이미지를 설치하기 위해 HTTP 또는 HTTPS 서버를 설정해야 합니다. 빠른 설치의 경우 HTTP 또는 HTTPS 서버가 필요하지 않지만 DHCP 서버가 필요합니다. "빠른 설치: Red Hat Enterprise Linux CoreOS(RHCOS) 머신 만들기" 및 "전체 설치: Red Hat Enterprise Linux CoreOS(RHCOS) 머신 만들기" 섹션을 참조하세요.
네트워크 인프라가 클러스터 구성 요소 간 필수 네트워크 연결을 제공하는지 확인합니다. 요구 사항에 대한 자세한 내용은 사용자 프로비저닝 인프라 섹션의 네트워킹 요구 사항 섹션을 참조하십시오.
OpenShift Container Platform 클러스터 구성 요소가 통신하는 데 필요한 포트를 활성화하도록 방화벽을 구성합니다. 필요한 포트에 대한 자세한 내용은 사용자 프로비저닝 인프라 섹션의 네트워킹 요구 사항 섹션을 참조하십시오.
중요
기본적으로 OpenShift Container Platform 클러스터에서는 포트 1936 에 액세스할 수 있습니다. 각 제어 평면 노드가 이 포트에 액세스해야 하기 때문입니다.
Ingress 로드 밸런서를 사용하여 이 포트를 노출하지 마세요. 그렇게 하면 Ingress 컨트롤러와 관련된 통계 및 측정 항목과 같은 민감한 정보가 노출될 수 있습니다.
클러스터에 필요한 DNS 인프라를 설정합니다.
1. Kubernetes API, 애플리케이션 와일드카드, 부트스트랩 시스템, 컨트롤 플레인 시스템 및 컴퓨팅 시스템의 DNS 이름 확인을 구성합니다.
2. Kubernetes API, 부트스트랩 시스템, 컨트롤 플레인 시스템 및 컴퓨팅 시스템에 대한 역방향 DNS 확인을 구성합니다.
  OpenShift Container Platform DNS 요구 사항에 대한 자세한 내용은 사용자 프로비저닝 DNS 요구 사항 섹션을 참조하십시오.
DNS 구성을 확인합니다.
1. 설치 노드에서 Kubernetes API의 레코드 이름, 와일드카드 경로 및 클러스터 노드에 대해 DNS 조회를 실행합니다. 응답의 IP 주소가 올바른 구성 요소에 해당하는지 확인합니다.
2. 설치 노드에서 로드 밸런서 및 클러스터 노드의 IP 주소에 대해 역방향 DNS 조회를 실행합니다. 응답의 레코드 이름이 올바른 구성 요소에 해당하는지 확인합니다.
  자세한 DNS 검증 단계는 사용자 프로비저닝 인프라에 대한 DNS 확인 섹션을 참조하십시오.
필요한 API 및 애플리케이션 수신 로드 밸런싱 인프라를 프로비저닝합니다. 요구 사항에 대한 자세한 내용은 사용자 프로비저닝 인프라에 대한 로드 밸런싱 요구 사항 섹션을 참조하십시오.

참고

일부 로드 밸런싱 솔루션에는 로드 밸런싱을 초기화하기 전에 클러스터 노드의 DNS 이름을 확인해야 합니다.

2.6.4. 수동으로 설치 구성 파일 만들기
링크 복사

클러스터를 설치하려면 설치 구성 파일을 수동으로 만들어야 합니다.

사전 요구 사항

설치 프로그램에서 사용할 SSH 공개 키가 로컬 컴퓨터에 있습니다. 디버깅 및 재해 복구를 위해 클러스터 노드에 대한 SSH 인증에 이 키를 사용할 수 있습니다.
OpenShift Container Platform 설치 프로그램과 클러스터의 풀 시크릿이 있습니다.

프로세스

필요한 설치 자산을 저장할 설치 디렉터리를 만듭니다.
```
mkdir <installation_directory>
```
```
$ mkdir <installation_directory>
```
Copy to Clipboard Toggle word wrap
중요
디렉터리를 만들어야 합니다. 부트스트랩 X.509 인증서와 같은 일부 설치 자산은 만료 간격이 짧으므로 설치 디렉터리를 재사용해서는 안 됩니다. 다른 클러스터 설치의 개별 파일을 재사용하려면 해당 파일을 사용자 디렉터리에 복사하면 됩니다. 그러나 설치 자산의 파일 이름은 릴리스간에 변경될 수 있습니다. 따라서 이전 OpenShift Container Platform 버전에서 설치 파일을 복사할 때는 주의하십시오.
제공된 샘플 install-config.yaml 파일 템플릿을 사용자 정의하고 <installation_directory> 에 파일을 저장합니다.
참고
이 설정 파일의 이름을 install-config.yaml로 지정해야 합니다.
install-config.yaml 파일을 백업해 두면 여러 클러스터를 설치하는 데 사용할 수 있습니다.
중요
다음 단계에서 설치 프로세스가 파일을 사용하므로 지금 install-config.yaml 파일을 백업하세요.

2.6.4.1. IBM Z용 샘플 install-config.yaml 파일
링크 복사

install-config.yaml 파일을 사용자 지정하여 OpenShift Container Platform 클러스터 플랫폼에 대한 자세한 정보를 지정하거나 필수 매개변수 값을 수정할 수 있습니다.

apiVersion: v1
baseDomain: example.com 
compute: 
- hyperthreading: Enabled 
  name: worker
  replicas: 0 
  architecture: s390x
controlPlane: 
  hyperthreading: Enabled 
  name: master
  replicas: 3 
  architecture: s390x
metadata:
  name: test 
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14 
    hostPrefix: 23 
  networkType: OVNKubernetes 
  serviceNetwork: 
  - 172.30.0.0/16
platform:
  none: {} 
fips: false 
pullSecret: '{"auths":{"<local_registry>": {"auth": "<credentials>","email": "you@example.com"}}}' 
sshKey: 'ssh-ed25519 AAAA...' 
additionalTrustBundle: | 
  -----BEGIN CERTIFICATE-----
  ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
  -----END CERTIFICATE-----
imageContentSources: 
- mirrors:
  - <local_repository>/ocp4/openshift4
  source: quay.io/openshift-release-dev/ocp-release
- mirrors:
  - <local_repository>/ocp4/openshift4
  source: quay.io/openshift-release-dev/ocp-v4.0-art-dev

apiVersion: v1
baseDomain: example.com

1


compute:

2


- hyperthreading: Enabled

3


  name: worker
  replicas: 0

4


  architecture: s390x
controlPlane:

5


  hyperthreading: Enabled

6


  name: master
  replicas: 3

7


  architecture: s390x
metadata:
  name: test

8


networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14

9


    hostPrefix: 23

10


  networkType: OVNKubernetes

11


  serviceNetwork:

12


  - 172.30.0.0/16
platform:
  none: {}

13


fips: false

14


pullSecret: '{"auths":{"<local_registry>": {"auth": "<credentials>","email": "you@example.com"}}}'

15


sshKey: 'ssh-ed25519 AAAA...'

16


additionalTrustBundle: |

17


  -----BEGIN CERTIFICATE-----
  ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
  -----END CERTIFICATE-----
imageContentSources:

18


- mirrors:
  - <local_repository>/ocp4/openshift4
  source: quay.io/openshift-release-dev/ocp-release
- mirrors:
  - <local_repository>/ocp4/openshift4
  source: quay.io/openshift-release-dev/ocp-v4.0-art-dev

Copy to Clipboard

Toggle word wrap

1

클러스터의 기본 도메인입니다. 모든 DNS 레코드는 이 기본 도메인의 하위 도메인이어야 하며 클러스터 이름을 포함해야 합니다.

2 5

controlPlane 섹션은 단일 매핑이지만 compute 섹션은 일련의 매핑입니다. 서로 다른 데이터 구조의 요구사항을 충족하도록 compute 섹션의 첫 번째 줄은 하이픈(-)으로 시작해야 하며 controlPlane 섹션의 첫 번째 줄은 하이픈으로 시작할 수 없습니다. 하나의 컨트롤 플레인 풀만 사용됩니다.

3 6

동시 멀티스레딩(SMT) 또는 hyperthreading 활성화/비활성화 여부를 지정합니다. 시스템 코어의 성능을 높이기 위해 기본적으로 SMT가 활성화됩니다. 매개변수 값을 Disabled로 설정하여 비활성화할 수 있습니다. SMT를 비활성화하는 경우 모든 클러스터 머신에서 이를 비활성화해야 합니다. 여기에는 컨트롤 플레인과 컴퓨팅 머신이 모두 포함됩니다.

참고

SMT(동시 멀티 스레딩)는 기본적으로 활성화되어 있습니다. OpenShift Container Platform 노드에서 SMT를 사용할 수 없는 경우 hyperthreading 매개변수가 적용되지 않습니다.

중요

OpenShift Container Platform 노드 또는 install-config.yaml 파일에서 hyperthreading을 비활성화하는 경우 용량 계획에서 머신 성능이 크게 저하될 수 있는 문제를 고려해야 합니다.

4

사용자 프로비저닝 인프라에 OpenShift Container Platform을 설치할 때 이 값을 0으로 설정해야 합니다. 설치 프로그램에서 제공하는 설치에서 매개 변수는 클러스터가 생성 및 관리하는 컴퓨팅 머신 수를 제어합니다. 사용자 프로비저닝 설치에서는 클러스터 설치를 완료하기 전에 컴퓨팅 시스템을 수동으로 배포해야 합니다.

참고

3-노드 클러스터를 설치하는 경우 RHCOS(Red Hat Enterprise Linux CoreOS) 시스템을 설치할 때 컴퓨팅 머신을 배포하지 마십시오.

7

클러스터에 추가하는 컨트롤 플레인 시스템의 수입니다. 클러스터에서 이 값을 클러스터의 etcd 끝점 수로 사용하므로 이 값은 배포하는 컨트롤 플레인 시스템의 수와 일치해야 합니다.

8

DNS 레코드에 지정한 클러스터 이름입니다.

9

Pod IP 주소가 할당되는 IP 주소 블록입니다. 이 블록은 기존 물리적 네트워크와 중복되지 않아야합니다. 이러한 IP 주소는 Pod 네트워크에 사용됩니다. 외부 네트워크에서 Pod에 액세스해야 하는 경우, 트래픽을 관리하도록 로드 밸런서와 라우터를 설정해야 합니다.

참고

클래스 E CIDR 범위는 향후 사용을 위해 예약되어 있습니다. 클래스 E CIDR 범위를 사용하려면 네트워크 환경이 클래스 E CIDR 범위 내의 IP 주소를 허용하는지 확인해야 합니다.

10

개별 노드 각각에 할당할 서브넷 접두사 길이입니다. 예를 들어 hostPrefix를 23으로 설정하면 지정된 cidr 이외 /23 서브넷이 각 노드에 할당되어 510(2^(32 - 23) - 2) Pod IP 주소가 허용됩니다. 외부 네트워크에서 노드에 액세스해야 하는 경우 트래픽을 관리하도록 로드 밸런서와 라우터를 구성합니다.

11

설치할 클러스터 네트워크 플러그인입니다. 기본값인 OVNKubernetes 만 지원됩니다.

12

서비스 IP 주소에 사용할 IP 주소 풀입니다. IP 주소 풀은 하나만 입력할 수 있습니다. 이 블록은 기존 물리적 네트워크와 중복되지 않아야합니다. 외부 네트워크에서 서비스에 액세스해야 하는 경우, 트래픽을 관리하도록 로드 밸런서와 라우터를 구성합니다.

13

플랫폼을 none으로 설정해야 합니다. IBM Z® 인프라에 대해 추가 플랫폼 구성 변수를 제공할 수 없습니다.

중요

플랫폼 유형이 none 으로 설치된 클러스터는 Machine API를 사용하여 컴퓨팅 머신을 관리하는 등의 일부 기능을 사용할 수 없습니다. 이러한 제한은 클러스터에 연결된 컴퓨팅 머신이 일반적으로 해당 기능을 지원하는 플랫폼에 설치된 경우에도 적용됩니다. 설치 후에는 이 매개변수를 변경할 수 없습니다.

14

FIPS 모드 활성화 또는 비활성화 여부입니다. 기본적으로 FIPS 모드는 비활성화됩니다. FIPS 모드가 활성화된 경우 OpenShift Container Platform이 실행되는 Red Hat Enterprise Linux CoreOS(RHCOS) 머신은 기본 Kubernetes 암호화 제품군을 우회하고 대신 RHCOS와 함께 제공되는 암호화 모듈을 사용합니다.

중요

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

FIPS 모드로 부팅된 Red Hat Enterprise Linux(RHEL) 또는 Red Hat Enterprise Linux CoreOS(RHCOS)를 실행할 때 OpenShift Container Platform 핵심 구성 요소는 x86_64, ppc64le 및 s390x 아키텍처에서만 FIPS 140-2/140-3 검증을 위해 NIST에 제출된 RHEL 암호화 라이브러리를 사용합니다.

15

<local_registry>는 미러 레지스트리가 해당 내용을 제공하는 데 사용하는 레지스트리 도메인 이름과 포트(선택사항)를 지정합니다. 예: registry.example.com 또는 registry.example.com:5000 <credentials>는 미러 레지스트리의 base64 인코딩 사용자 이름과 암호를 지정합니다.

16

Red Hat Enterprise Linux CoreOS(RHCOS)의 핵심 사용자를 위한 SSH 공개 키입니다.

참고

설치 디버깅 또는 재해 복구를 수행하려는 프로덕션 OpenShift Container Platform 클러스터의 경우 ssh-agent 프로세스가 사용하는 SSH 키를 지정합니다.

17

additionalTrustBundle 매개변수와 값을 추가합니다. 값은 미러 레지스트리에 사용한 인증서 파일의 내용이어야 합니다. 인증서 파일은 기존의 신뢰할 수 있는 인증 기관이거나 미러 레지스트리에 대해 생성한 자체 서명 인증서일 수 있습니다.

18

저장소를 미러링하는 데 사용한 명령의 출력에 따라 imageContentSources 섹션을 제공합니다.

중요

oc adm release mirror 명령을 사용할 때 imageContentSources 섹션의 출력을 사용하세요.
oc mirror 명령을 사용하는 경우, 명령을 실행한 결과로 생성되는 ImageContentSourcePolicy 파일의 repositoryDigestMirrors 섹션을 사용합니다.
ImageContentSourcePolicy 가 더 이상 사용되지 않습니다. 자세한 내용은 이미지 레지스트리 저장소 미러링 구성을 참조하세요.

2.6.4.2. 설치 중 클러스터 단위 프록시 구성
링크 복사

프로덕션 환경에서는 인터넷에 대한 직접 액세스를 거부하고 대신 HTTP 또는 HTTPS 프록시를 사용할 수 있습니다. install-config.yaml 파일에서 프록시 설정을 구성하여 프록시가 사용되도록 새 OpenShift Container Platform 클러스터를 구성할 수 있습니다.

사전 요구 사항

기존 install-config.yaml 파일이 있습니다.
클러스터에서 액세스해야 하는 사이트를 검토하고 프록시를 바이패스해야 하는지 확인했습니다. 기본적으로 호스팅 클라우드 공급자 API에 대한 호출을 포함하여 모든 클러스터 발신(Egress) 트래픽이 프록시됩니다. 필요한 경우 프록시를 바이패스하기 위해 Proxy 오브젝트의 spec.noProxy 필드에 사이트를 추가했습니다.
참고
Proxy 오브젝트의 status.noProxy 필드는 설치 구성에 있는 networking.machineNetwork[].cidr, networking.clusterNetwork[].cidr, networking.serviceNetwork[] 필드의 값으로 채워집니다.
Amazon Web Services(AWS), Google Cloud Platform(GCP), Microsoft Azure 및 Red Hat OpenStack Platform(RHOSP)에 설치하는 경우 프록시 개체 status.noProxy 필드도 인스턴스 메타데이터 엔드포인트( 169.254.169.254 )로 채워집니다.

프로세스

install-config.yaml 파일을 편집하고 프록시 설정을 추가합니다. 예를 들면 다음과 같습니다.
```
apiVersion: v1
baseDomain: my.domain.com
proxy:
  httpProxy: http://<username>:<pswd>@<ip>:<port> 
  httpsProxy: https://<username>:<pswd>@<ip>:<port> 
  noProxy: example.com 
additionalTrustBundle: | 
    -----BEGIN CERTIFICATE-----
    <MY_TRUSTED_CA_CERT>
    -----END CERTIFICATE-----
additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle> 
```
```
apiVersion: v1
baseDomain: my.domain.com
proxy:
  httpProxy: http://<username>:<pswd>@<ip>:<port> 
```
1
```
  httpsProxy: https://<username>:<pswd>@<ip>:<port> 
```
2
```
  noProxy: example.com 
```
3
```
additionalTrustBundle: | 
```
4
```
    -----BEGIN CERTIFICATE-----
    <MY_TRUSTED_CA_CERT>
    -----END CERTIFICATE-----
additionalTrustBundlePolicy: <policy_to_add_additionalTrustBundle> 
```
5
Copy to Clipboard Toggle word wrap
1
클러스터 외부에서 HTTP 연결을 구축하는 데 사용할 프록시 URL입니다. URL 스키마는 http여야 합니다.
2
클러스터 외부에서 HTTPS 연결을 구축하는 데 사용할 프록시 URL입니다.
3
대상 도메인 이름, IP 주소 또는 프록시에서 제외할 기타 네트워크 CIDR로 이루어진 쉼표로 구분된 목록입니다. 하위 도메인과 일치하려면 도메인 앞에 .을 입력합니다. 예를 들어, .y.com은 x.y.com과 일치하지만 y.com은 일치하지 않습니다. *를 사용하여 모든 대상에 대해 프록시를 바이패스합니다.
4
이 값을 제공하면 설치 프로그램에서 HTTPS 연결을 프록시하는 데 필요한 추가 CA 인증서가 하나 이상 포함된 openshift-config 네임스페이스에 user-ca-bundle이라는 이름으로 구성 맵을 생성합니다. 그런 다음 클러스터 네트워크 운영자는 이러한 내용을 Red Hat Enterprise Linux CoreOS(RHCOS) 신뢰 번들과 병합하는 신뢰할 수 있는 CA 번들 구성 맵을 만들고, 이 구성 맵은 프록시 개체의 신뢰할 수 있는 CA 필드에서 참조됩니다. 프록시의 ID 인증서를 RHCOS 트러스트 번들에 있는 기관에서 서명하지 않은 경우 additionalTrustBundle 필드가 있어야 합니다.
5
선택 사항: 신뢰할 수 있는 CA 필드의 user-ca-bundle 구성 맵을 참조하도록 프록시 개체의 구성을 결정하는 정책입니다. 허용되는 값은 Proxyonly 및 Always 입니다. http/https 프록시가 구성된 경우에만 Proxyonly를 사용하여 user-ca-bundle 구성 맵을 참조합니다. Always를 사용하여 user-ca-bundle 구성 맵을 항상 참조합니다. 기본값은 Proxyonly 입니다.
참고
설치 프로그램에서 프록시 adinessEndpoints 필드를 지원하지 않습니다.
참고
설치 프로그램이 시간 초과되면 설치 프로그램의 wait-for 명령을 사용하여 배포를 다시 시작한 다음 완료합니다. 예를 들면 다음과 같습니다.
$ ./openshift-install wait-for install-complete --log-level debug
Copy to Clipboard Toggle word wrap
파일을 저장해 놓고 OpenShift Container Platform을 설치할 때 참조하십시오.

제공되는 install-config.yaml 파일의 프록시 설정을 사용하는 cluster라는 이름의 클러스터 전체 프록시가 설치 프로그램에 의해 생성됩니다. 프록시 설정을 제공하지 않아도 cluster Proxy 오브젝트는 계속 생성되지만 spec은 nil이 됩니다.

참고

cluster라는 Proxy 오브젝트만 지원되며 추가 프록시는 생성할 수 없습니다.

2.6.4.3. 3개의 노드 클러스터 구성
링크 복사

필요한 경우 3개의 컨트롤 플레인 시스템으로 구성된 최소 3개의 노드 클러스터에 제로 컴퓨팅 머신을 배포할 수 있습니다. 이를 통해 클러스터 관리자와 개발자들이 테스트, 개발, 프로덕션에 사용할 수 있는 소형화되고 리소스 효율이 높은 클러스터를 제공합니다.

3-노드 OpenShift Container Platform 환경에서 세 개의 컨트롤 플레인 머신을 예약할 수 있습니다. 즉, 애플리케이션 워크로드가 해당 플랫폼에서 실행되도록 예약됩니다.

사전 요구 사항

기존 install-config.yaml 파일이 있습니다.

프로세스

install-config.yaml 파일에서 다음 compute 스탠자에 표시된 대로 컴퓨팅 복제본 수가 0으로 설정되어 있는지 확인합니다.
```
compute:
- name: worker
  platform: {}
  replicas: 0
```
```
compute:
- name: worker
  platform: {}
  replicas: 0
```
Copy to Clipboard Toggle word wrap
참고
배포 중인 컴퓨팅 머신 수에 관계없이 사용자 프로비저닝 인프라에 OpenShift Container Platform을 설치할 때 컴퓨팅 머신의 replicas 매개변수 값을 0으로 설정해야 합니다. 설치 프로그램에서 제공하는 설치에서 매개 변수는 클러스터가 생성 및 관리하는 컴퓨팅 머신 수를 제어합니다. 이 설정은 컴퓨팅 시스템이 수동으로 배포되는 사용자 프로비저닝 설치에는 적용되지 않습니다.
참고
컨트롤 플레인 노드의 기본 리소스는 vCPU 6개와 21GB입니다. 3개의 컨트롤 플레인 노드의 경우 메모리 + vCPU는 최소 5-노드 클러스터와 동등합니다. SMT2가 활성화된 IFL 3개와 함께 각각 120GB 디스크에 설치된 3개의 노드를 백업해야 합니다. 테스트된 최소 설정은 각 컨트롤 플레인 노드에 대해 120GB 디스크에서 3개의 vCPU와 10GB입니다.

3-노드 클러스터 설치의 경우 다음 단계를 따르십시오.

컴퓨팅 노드가 0인 3-노드 클러스터를 배포하는 경우 Ingress 컨트롤러 Pod는 컨트롤 플레인 노드에서 실행됩니다. 3-노드 클러스터 배포에서 HTTP 및 HTTPS 트래픽을 컨트롤 플레인 노드로 라우팅하도록 애플리케이션 인그레스 로드 밸런서를 구성해야 합니다. 자세한 내용은 사용자 프로비저닝 인프라 섹션에 대한 로드 밸런싱 요구 사항 섹션을 참조하십시오.
다음 절차에서 Kubernetes 매니페스트 파일을 생성할 때 <installation_directory>/manifests/cluster-scheduler-02-config.yml 파일의 mastersSchedulable 매개변수가 true로 설정되어 있는지 확인합니다. 이렇게 하면 애플리케이션 워크로드를 컨트롤 플레인 노드에서 실행할 수 있습니다.
Red Hat Enterprise Linux CoreOS(RHCOS) 머신을 생성할 때 어떠한 컴퓨팅 노드도 배포하지 마세요.

2.6.5. CNO(Cluster Network Operator) 구성
링크 복사

클러스터 네트워크의 구성은 CNO(Cluster Network Operator) 구성의 일부로 지정되며 cluster라는 이름의 CR(사용자 정의 리소스) 오브젝트에 저장됩니다. CR은 operator.openshift.io API 그룹에서 Network API의 필드를 지정합니다.

CNO 구성은 Network.config.openshift.io API 그룹의 Network API에서 클러스터 설치 중에 다음 필드를 상속받습니다.

clusterNetwork: Pod IP 주소가 할당되는 IP 주소 풀입니다.
serviceNetwork: 서비스를 위한 IP 주소 풀입니다.
defaultNetwork.type: 클러스터 네트워크 플러그인. 설치 중에 지원되는 유일한 플러그인은 OVNKubernetes 입니다.

CNO 개체의 cluster 라는 이름의 defaultNetwork 개체에 대한 필드를 설정하여 클러스터에 대한 클러스터 네트워크 플러그인 구성을 지정할 수 있습니다.

2.6.5.1. CNO(Cluster Network Operator) 구성 오브젝트
링크 복사

CNO(Cluster Network Operator)의 필드는 다음 표에 설명되어 있습니다.

Expand

표 2.44. CNO(Cluster Network Operator) 구성 오브젝트
필드	유형	설명
`metadata.name`	`string`	CNO 개체 이름입니다. 이 이름은 항상 `cluster`입니다.
`spec.clusterNetwork`	`array`	Pod IP 주소가 할당되는 IP 주소 블록과 클러스터의 각 개별 노드에 할당된 서브넷 접두사 길이를 지정하는 목록입니다. 예를 들면 다음과 같습니다. `spec: clusterNetwork: - cidr: 10.128.0.0/19 hostPrefix: 23 - cidr: 10.128.32.0/19 hostPrefix: 23` Copy to Clipboard Toggle word wrap
`spec.serviceNetwork`	`array`	서비스의 IP 주소 블록입니다. OVN-Kubernetes 네트워크 플러그인은 서비스 네트워크에 대해 단일 IP 주소 블록만 지원합니다. 예를 들면 다음과 같습니다. `spec: serviceNetwork: - 172.30.0.0/14` Copy to Clipboard Toggle word wrap 매니페스트를 생성하기 전에 `install-config.yaml` 파일에서만 이 필드를 사용자 지정할 수 있습니다. 값은 매니페스트 파일에서 읽기 전용입니다.
`spec.defaultNetwork`	`object`	클러스터 네트워크에 대한 네트워크 플러그인을 구성합니다.
`spec.kubeProxyConfig`	`object`	이 개체의 필드는 kube-proxy 구성을 지정합니다. OVN-Kubernetes 클러스터 네트워크 플러그인을 사용하는 경우 kube-proxy 구성은 효과가 없습니다.

중요

여러 네트워크에 객체를 배포해야 하는 클러스터의 경우 install-config.yaml 파일에 정의된 각 네트워크 유형에 대해 clusterNetwork.hostPrefix 매개변수에 동일한 값을 지정해야 합니다. 각 clusterNetwork.hostPrefix 매개변수에 다른 값을 설정하면 OVN-Kubernetes 네트워크 플러그인에 영향을 미쳐 플러그인이 여러 노드 간에 개체 트래픽을 효과적으로 라우팅할 수 없습니다.

defaultNetwork 오브젝트 구성

defaultNetwork 오브젝트의 값은 다음 표에 정의되어 있습니다.

Expand

표 2.45. defaultNetwork 오브젝트
필드	유형	설명
`type`	`string`	`OVNKubernetes` . Red Hat OpenShift Networking 네트워크 플러그인은 설치 중에 선택됩니다. 클러스터를 설치한 후에는 이 값을 변경할 수 없습니다. 참고 OpenShift Container Platform은 기본적으로 OVN-Kubernetes 네트워크 플러그인을 사용합니다.
`ovnKubernetesConfig`	`object`	이 객체는 OVN-Kubernetes 네트워크 플러그인에만 유효합니다.

OVN-Kubernetes 네트워크 플러그인 구성

다음 표에서는 OVN-Kubernetes 네트워크 플러그인의 구성 필드를 설명합니다.

Expand

표 2.46. ovnKubernetesConfig object
필드	유형	설명
`mtu`	`integer`	Geneve(Generic Network Virtualization Encapsulation) 오버레이 네트워크의 MTU(최대 전송 단위)입니다. 이는 기본 네트워크 인터페이스의 MTU를 기준으로 자동 탐지됩니다. 일반적으로 감지된 MTU를 재정의할 필요는 없습니다. 자동 감지 값이 예상 밖인 경우 노드의 기본 네트워크 인터페이스의 MTU가 올바른지 확인합니다. 이 옵션을 사용하여 노드의 기본 네트워크 인터페이스의 MTU 값을 변경할 수 없습니다. 클러스터에 다른 노드에 대한 다른 MTU 값이 필요한 경우, 이 값을 클러스터의 가장 낮은 MTU 값보다 `100` 미만으로 설정해야 합니다. 예를 들어, 클러스터의 일부 노드에 `9001`의 MTU가 있고 일부에는 `1500`의 MTU가 있는 경우 이 값을 `1400`으로 설정해야 합니다.
`genevePort`	`integer`	모든 Geneve 패킷에 사용할 포트입니다. 기본값은 `6081`입니다. 클러스터를 설치한 후에는 이 값을 변경할 수 없습니다.
`ipsecConfig`	`object`	IPsec 구성을 사용자 정의하기 위한 구성 개체를 지정합니다.
`ipv4`	`object`	IPv4 설정에 대한 구성 객체를 지정합니다.
`ipv6`	`object`	IPv6 설정에 대한 구성 개체를 지정합니다.
`policyAuditConfig`	`object`	네트워크 정책 감사 로깅을 사용자 정의할 구성 오브젝트를 지정합니다. 설정되지 않으면 기본값 감사 로그 설정이 사용됩니다.
`gatewayConfig`	`object`	선택 사항: 송신 트래픽이 노드 게이트웨이로 전송되는 방법을 사용자 정의할 구성 오브젝트를 지정합니다. 유효한 값은 `공유` 및 `로컬` 입니다. 기본값은 `공유` 입니다. 기본 설정에서 Open vSwitch(OVS)는 트래픽을 노드 IP 인터페이스로 직접 출력합니다. `로컬` 설정에서는 호스트 네트워크를 통과합니다. 따라서 호스트의 라우팅 테이블에 적용됩니다. 참고 송신 트래픽을 마이그레이션하는 동안 클러스터 네트워크 운영자(CNO)가 변경 사항을 성공적으로 롤아웃할 때까지 작업 부하와 서비스 트래픽이 일부 중단될 것으로 예상할 수 있습니다.

Expand

표 2.47. ovnKubernetesConfig.ipv4 object
필드	유형	설명
`internalTransitSwitchSubnet`	string	기존 네트워크 인프라가 `100.88.0.0/16` IPv4 서브넷과 겹치는 경우 OVN-Kubernetes에서 내부적으로 사용할 다른 IP 주소 범위를 지정할 수 있습니다. 동서 트래픽을 가능하게 하는 분산형 전송 스위치의 서브넷입니다. 이 서브넷은 OVN-Kubernetes 또는 호스트 자체에서 사용하는 다른 서브넷과 겹칠 수 없습니다. 클러스터의 노드당 하나의 IP 주소를 수용할 수 있을 만큼 커야 합니다. 기본값은 `100.88.0.0/16` 입니다.
`internalJoinSubnet`	string	기존 네트워크 인프라가 `100.64.0.0/16` IPv4 서브넷과 겹치는 경우 OVN-Kubernetes에서 내부적으로 사용할 다른 IP 주소 범위를 지정할 수 있습니다. IP 주소 범위가 OpenShift Container Platform 설치에서 사용하는 다른 서브넷과 겹치지 않도록 해야 합니다. IP 주소 범위는 클러스터에 추가할 수 있는 최대 노드 수보다 커야 합니다. 예를 들어 `clusterNetwork.cidr` 값이 `10.128.0.0/14` 이고 `clusterNetwork.hostPrefix` 값이 `/23` 이면 최대 노드 수는 `2^(23-14)=512` 입니다. 기본값은 `100.64.0.0/16` 입니다.

Expand

표 2.48. ovnKubernetesConfig.ipv6 object
필드	유형	설명
`internalTransitSwitchSubnet`	string	기존 네트워크 인프라가 `fd97::/64` IPv6 서브넷과 겹치는 경우 OVN-Kubernetes에서 내부적으로 사용할 다른 IP 주소 범위를 지정할 수 있습니다. 동서 트래픽을 가능하게 하는 분산형 전송 스위치의 서브넷입니다. 이 서브넷은 OVN-Kubernetes 또는 호스트 자체에서 사용하는 다른 서브넷과 겹칠 수 없습니다. 클러스터의 노드당 하나의 IP 주소를 수용할 수 있을 만큼 커야 합니다. 기본값은 `fd97::/64` 입니다.
`internalJoinSubnet`	string	기존 네트워크 인프라가 `fd98::/64` IPv6 서브넷과 겹치는 경우 OVN-Kubernetes에서 내부적으로 사용할 다른 IP 주소 범위를 지정할 수 있습니다. IP 주소 범위가 OpenShift Container Platform 설치에서 사용하는 다른 서브넷과 겹치지 않도록 해야 합니다. IP 주소 범위는 클러스터에 추가할 수 있는 최대 노드 수보다 커야 합니다. 기본값은 `fd98::/64` 입니다.

Expand

표 2.49. policyAuditConfig 오브젝트
필드	유형	설명
`rateLimit`	integer	노드당 1초마다 생성할 최대 메시지 수입니다. 기본값은 초당 `20` 개의 메시지입니다.
`maxFileSize`	integer	감사 로그의 최대 크기(바이트)입니다. 기본값은 `50000000` 또는 50MB입니다.
`maxLogFiles`	integer	보관되는 로그 파일의 최대 수.
`대상`	string	다음 추가 감사 로그 대상 중 하나입니다. `libc` 호스트에서 journald 프로세스의 libc `syslog()` 함수입니다. `udp:<host>:<port>` syslog 서버입니다. `<host>:<port>`를 syslog 서버의 호스트 및 포트로 바꿉니다. `unix:<file>` `<file>`로 지정된 Unix Domain Socket 파일입니다. `null` 감사 로그를 추가 대상으로 보내지 마십시오.
`syslogFacility`	string	RFC5424에 정의된 `kern`과 같은 syslog 기능입니다. 기본값은 `local0`입니다.

Expand

표 2.50. gatewayConfig 오브젝트
필드	유형	설명
`routingViaHost`	`boolean`	Pod에서 호스트 네트워킹 스택으로 송신 트래픽을 보내려면 이 필드를 `true`로 설정합니다. 커널 라우팅 테이블에 수동으로 구성된 경로를 사용하는 고도의 전문 설치 및 애플리케이션의 경우 송신 트래픽을 호스트 네트워킹 스택으로 라우팅해야 할 수 있습니다. 기본적으로 송신 트래픽은 클러스터를 종료하기 위해 OVN에서 처리되며 커널 라우팅 테이블의 특수 경로의 영향을 받지 않습니다. 기본값은 `false`입니다. 이 필드는 Open vSwitch 하드웨어 오프로드 기능과 상호 작용합니다. 이 필드를 `true` 로 설정하면 송신 트래픽이 호스트 네트워킹 스택에서 처리되므로 오프로드의 성능 이점이 제공되지 않습니다.
`ipForwarding`	`object`	`네트워크` 리소스의 `ipForwarding` 사양을 사용하여 OVN-Kubernetes 관리 인터페이스의 모든 트래픽에 대한 IP 전달을 제어할 수 있습니다. Kubernetes 관련 트래픽에 대해서만 IP 전달을 허용하려면 `'제한됨'을` 지정합니다. 모든 IP 트래픽 전달을 허용하려면 `글로벌을` 지정합니다. 새로 설치하는 경우 기본값은 `제한됨` 입니다. OpenShift Container Platform 4.14 이상으로 업데이트하는 경우 기본값은 `Global` 입니다. 참고 기본값인 `Restricted` 를 사용하면 IP 전달이 삭제됩니다.
`ipv4`	`object`	선택 사항: IPv4 주소에 대한 호스트에서 서비스로의 트래픽에 대한 내부 OVN-Kubernetes 마스커레이드 주소를 구성할 객체를 지정합니다.
`ipv6`	`object`	선택 사항: IPv6 주소에 대한 호스트에서 서비스 트래픽으로의 내부 OVN-Kubernetes 마스커레이드 주소를 구성할 객체를 지정합니다.

Expand

표 2.51. gatewayConfig.ipv4 object
필드	유형	설명
`internalMasqueradeSubnet`	`string`	호스트에서 서비스로의 트래픽을 활성화하기 위해 내부적으로 사용되는 위장 IPv4 주소입니다. 호스트는 이러한 IP 주소와 공유 게이트웨이 브리지 인터페이스로 구성됩니다. 기본값은 `169.254.169.0/29` 입니다. 중요 OpenShift Container Platform 4.17 이상 버전의 경우 클러스터는 기본 마스커레이드 서브넷으로 `169.254.0.0/17을` 사용합니다. 업그레이드된 클러스터의 경우 기본 마스커레이드 서브넷에는 변경 사항이 없습니다.

Expand

표 2.52. gatewayConfig.ipv6 object
필드	유형	설명
`internalMasqueradeSubnet`	`string`	호스트에서 서비스로의 트래픽을 활성화하기 위해 내부적으로 사용되는 위장 IPv6 주소입니다. 호스트는 이러한 IP 주소와 공유 게이트웨이 브리지 인터페이스로 구성됩니다. 기본값은 `fd69::/125` 입니다. 중요 OpenShift Container Platform 4.17 이상 버전의 경우 클러스터는 `fd69::/112를` 기본 마스커레이드 서브넷으로 사용합니다. 업그레이드된 클러스터의 경우 기본 마스커레이드 서브넷에는 변경 사항이 없습니다.

Expand

표 2.53. ipsecConfig 객체
필드	유형	설명
`mode`	`string`	IPsec 구현의 동작을 지정합니다. 다음 값 중 하나여야 합니다. `비활성화` : 클러스터 노드에서 IPsec이 활성화되지 않았습니다. `외부` : 외부 호스트와의 네트워크 트래픽에 대해 IPsec이 활성화됩니다. `전체` : 포드 트래픽과 외부 호스트와의 네트워크 트래픽에 대해 IPsec이 활성화됩니다.

IPSec가 활성화된 OVN-Kubernetes 구성의 예

defaultNetwork:
  type: OVNKubernetes
  ovnKubernetesConfig:
    mtu: 1400
    genevePort: 6081
    ipsecConfig:
      mode: Full

defaultNetwork:
  type: OVNKubernetes
  ovnKubernetesConfig:
    mtu: 1400
    genevePort: 6081
    ipsecConfig:
      mode: Full

Copy to Clipboard

Toggle word wrap

2.6.6. Kubernetes 매니페스트 및 Ignition 설정 파일 생성
링크 복사

일부 클러스터 정의 파일을 수정하고 클러스터 시스템을 수동으로 시작해야 하므로 클러스터가 시스템을 구성하는 데 필요한 Kubernetes 매니페스트 및 Ignition 구성 파일을 사용자가 생성해야 합니다.

설치 구성 파일은 Kubernetes 매니페스트로 변환됩니다. 매니페스트는 나중에 클러스터 머신을 구성하는 데 사용되는 Ignition 구성 파일로 래핑됩니다.

중요

OpenShift Container Platform 설치 프로그램에서 생성하는 Ignition 구성 파일에 24시간 후에 만료되는 인증서가 포함되어 있습니다. 이 인증서는 그 후에 갱신됩니다. 인증서를 갱신하기 전에 클러스터가 종료되고 24시간이 지난 후에 클러스터가 다시 시작되면 클러스터는 만료된 인증서를 자동으로 복구합니다. 예외적으로 kubelet 인증서를 복구하려면 대기 중인 node-bootstrapper 인증서 서명 요청(CSR)을 수동으로 승인해야 합니다. 자세한 내용은 만료된 컨트롤 플레인 인증서에서 복구 문서를 참조하십시오.
24 시간 인증서는 클러스터를 설치한 후 16시간에서 22시간으로 인증서가 교체되기 때문에 생성된 후 12시간 이내에 Ignition 구성 파일을 사용하는 것이 좋습니다. 12시간 이내에 Ignition 구성 파일을 사용하면 설치 중에 인증서 업데이트가 실행되는 경우 설치 실패를 방지할 수 있습니다.

참고

매니페스트 및 Ignition 파일을 생성하는 설치 프로그램은 아키텍처에 따라 다르며 클라이언트 이미지 미러에서 얻을 수 있습니다. 설치 프로그램의 Linux 버전은 s390x에서만 실행됩니다. 이 설치 프로그램은 Mac OS 버전으로도 사용할 수 있습니다.

사전 요구 사항

OpenShift Container Platform 설치 프로그램을 가져오셨습니다. 제한된 네트워크 설치의 경우, 해당 파일은 미러 호스트에 있습니다.
install-config.yaml 설치 구성 파일을 생성하셨습니다.

프로세스

OpenShift Container Platform 설치 프로그램이 포함된 디렉터리로 변경하고 클러스터에 대한 Kubernetes 매니페스트를 생성합니다.
```
./openshift-install create manifests --dir <installation_directory>
```
```
$ ./openshift-install create manifests --dir <installation_directory> 
```
1
Copy to Clipboard Toggle word wrap
1
<installation_directory>는 사용자가 만든 install-config.yaml 파일이 포함된 설치 디렉터리를 지정합니다.
주의
3 노드 클러스터를 실행 중이면 다음 단계를 건너 뛰어 컨트롤 플레인 노드 일정을 계획할 수 있도록 하십시오.
중요
기본 예약 불가에서 예약 가능으로 컨트롤 플레인 노드를 구성하면 추가 서브스크립션이 필요합니다. 이는 제어 평면 노드가 컴퓨팅 노드가 되기 때문입니다.
<installation_directory>/manifests/cluster-scheduler-02-config.yml Kubernetes 매니페스트 파일의 mastersSchedulable 매개변수가 false로 설정되어 있는지 확인합니다. 이 설정으로 인해 컨트롤 플레인 머신에서 포드가 예약되지 않습니다.
1. <installation_directory>/manifests/cluster-scheduler-02-config.yml 파일을 엽니다.
2. mastersSchedulable 매개변수를 찾아서 값을 False로 설정되어 있는지 확인합니다.
3. 파일을 저장하고 종료합니다.
Ignition 구성 파일을 생성하려면 설치 프로그램이 포함된 디렉터리에서 다음 명령을 실행합니다.
```
./openshift-install create ignition-configs --dir <installation_directory>
```
```
$ ./openshift-install create ignition-configs --dir <installation_directory> 
```
1
Copy to Clipboard Toggle word wrap
1
<installation_directory>는 동일한 설치 디렉터리를 지정합니다.
설치 디렉터리의 부트스트랩, 컨트롤 플레인 및 컴퓨팅 노드에 대한 Ignition 구성 파일이 생성됩니다. kubeadmin-password 및 kubeconfig 파일은 ./<installation_directory>/auth 디렉터리에 생성됩니다.
```
.
├── auth
│   ├── kubeadmin-password
│   └── kubeconfig
├── bootstrap.ign
├── master.ign
├── metadata.json
└── worker.ign
```
```
.
├── auth
│   ├── kubeadmin-password
│   └── kubeconfig
├── bootstrap.ign
├── master.ign
├── metadata.json
└── worker.ign
```
Copy to Clipboard Toggle word wrap

2.6.7. RHCOS 설치 및 OpenShift Container Platform 부트스트랩 프로세스 시작
링크 복사

프로비저닝하는 IBM Z® 인프라에 OpenShift Container Platform을 설치하려면 Red Hat Enterprise Linux(RHEL) 게스트 가상 머신으로 Red Hat Enterprise Linux CoreOS(RHCOS)를 설치해야 합니다. RHCOS를 설치할 때 설치 중인 머신 유형에 대해 OpenShift Container Platform 설치 프로그램에서 생성한 Ignition 구성 파일을 제공해야 합니다. 적합한 네트워킹, DNS 및 로드 밸런싱 인프라를 구성한 경우 RHCOS 머신이 재부팅된 후 OpenShift Container Platform 부트스트랩 프로세스가 자동으로 시작됩니다.

사전 패키징된 QEMU COW2(QCOW2) 디스크 이미지를 사용하는 RHCOS의 빠른 트랙 설치를 수행할 수 있습니다. 또는 새 QCOW2 디스크 이미지에서 전체 설치를 수행할 수도 있습니다.

시스템의 보안을 강화하려면 빠른 설치로 진행하기 전에 IBM® Secure Execution을 사용하여 RHCOS를 설치할 수 있습니다.

2.6.7.1. IBM Z 또는 IBM LinuxONE 환경의 노드에 대한 암호화 구성
링크 복사

IBM Z® 또는 IBM® LinuxONE에서 OpenShift Container Platform 제어 평면과 컴퓨팅 노드를 선택적으로 보호하기 위해 세 가지 방법 중에서 선택할 수 있습니다.

IBM® 보안 실행
IBM® Crypto Express(CEX)를 통한 Linux Unified Key Setup(LUKS) 암호화
네트워크 바운드 디스크 암호화(NBDE)

2.6.7.1.1. IBM Secure Execution을 사용하여 RHCOS 설치
링크 복사

IBM® Secure Execution을 사용하여 RHCOS를 설치하기 전에 기본 인프라를 준비해야 합니다.

사전 요구 사항

IBM® z15 이상 또는 IBM® LinuxONE III 이상.
Red Hat Enterprise Linux (RHEL) 8 이상.
부트스트랩 Ignition 파일이 있습니다. 파일이 보호되지 않아 다른 사람이 보고 편집할 수 없습니다.
설치 후 부트 이미지가 변경되지 않았는지 확인했습니다.
모든 노드를 IBM® Secure Execution 게스트로 실행해야 합니다.

프로세스

IBM® Secure Execution을 지원하도록 RHEL KVM 호스트를 준비합니다.
- 기본적으로 KVM 호스트는 IBM® Secure Execution 모드에서 게스트를 지원하지 않습니다. IBM® Secure Execution 모드에서 게스트를 지원하려면 KVM 호스트가 커널 매개변수 사양 prot_virt=1을 사용하여 LPAR 모드에서 부팅해야 합니다. RHEL 8에서 prot_virt=1을 활성화하려면 다음 단계를 따르세요.
  1. /boot/loader/entries/ 로 이동하여 부트로더 구성 파일 *.conf를 수정합니다.
  2. 커널 명령줄 매개변수 prot_virt=1을 추가합니다.
  3. zipl 명령을 실행하고 시스템을 재부팅합니다.
    Linux용 IBM® Secure Execution을 지원하여 성공적으로 시작된 KVM 호스트는 다음 커널 메시지를 발행합니다.
    
    prot_virt: Reserving <amount>MB as ultravisor base storage.
    
    Copy to Clipboard Toggle word wrap
  4. KVM 호스트가 이제 IBM® Secure Execution을 지원하는지 확인하려면 다음 명령을 실행하세요.
    
    # cat /sys/firmware/uv/prot_virt_host
    
    Copy to Clipboard Toggle word wrap
    
    출력 예
    
    1
    
    Copy to Clipboard Toggle word wrap
    
    Linux 인스턴스가 해당 환경을 보안 호스트와 일치한다고 감지하는 경우 이 속성 값은 1입니다. 다른 경우에는 값이 0입니다.

Ignition을 통해 KVM 게스트에 호스트 키를 추가합니다.

첫 번째 부팅 시 RHCOS는 호스트 키를 찾아서 이를 사용하여 자신을 다시 암호화합니다. RHCOS는 /etc/se-hostkeys 디렉토리에서 ibm-z-hostkey- 로 시작하는 파일을 검색합니다. 클러스터가 실행 중인 각 머신의 모든 호스트 키는 관리자가 디렉토리에 로드해야 합니다. 처음 부팅한 후에는 다른 컴퓨터에서 VM을 실행할 수 없습니다.

참고

안전한 시스템에서 Ignition 파일을 준비해야 합니다. 예를 들어, 또 다른 IBM® Secure Execution 게스트.

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

{
  "ignition": { "version": "3.0.0" },
  "storage": {
    "files": [
      {
        "path": "/etc/se-hostkeys/ibm-z-hostkey-<your-hostkey>.crt",
        "contents": {
          "source": "data:;base64,<base64 encoded hostkey document>"
        },
        "mode": 420
      },
      {
        "path": "/etc/se-hostkeys/ibm-z-hostkey-<your-hostkey>.crt",
        "contents": {
          "source": "data:;base64,<base64 encoded hostkey document>"
        },
        "mode": 420
      }
    ]
  }
}
```

{
  "ignition": { "version": "3.0.0" },
  "storage": {
    "files": [
      {
        "path": "/etc/se-hostkeys/ibm-z-hostkey-<your-hostkey>.crt",
        "contents": {
          "source": "data:;base64,<base64 encoded hostkey document>"
        },
        "mode": 420
      },
      {
        "path": "/etc/se-hostkeys/ibm-z-hostkey-<your-hostkey>.crt",
        "contents": {
          "source": "data:;base64,<base64 encoded hostkey document>"
        },
        "mode": 420
      }
    ]
  }
}
```

Copy to Clipboard

Toggle word wrap

참고

노드를 여러 IBM Z® 머신에서 실행하려면 필요한 만큼 호스트 키를 추가할 수 있습니다.

Base64로 인코딩된 문자열을 생성하려면 다음 명령을 실행하세요.
```
base64 <your-hostkey>.crt
```
```
base64 <your-hostkey>.crt
```
Copy to Clipboard Toggle word wrap
IBM® Secure Execution을 실행하지 않는 게스트와 비교했을 때, Ignition 단계 전에 전체 이미지가 무작위로 생성된 LUKS 암호로 암호화되기 때문에 머신의 첫 번째 부팅 시간이 더 깁니다.
점화 보호 추가
Ignition 구성 파일에 저장된 비밀을 읽히거나 수정하는 것을 방지하려면 Ignition 구성 파일을 암호화해야 합니다.
참고
원하는 보안을 달성하기 위해 IBM® Secure Execution을 실행할 때 Ignition 로깅 및 로컬 로그인은 기본적으로 비활성화됩니다.
1. 다음 명령을 실행하여 secex-qemu.qcow2 이미지에 대한 공개 GPG 키를 가져오고 해당 키로 Ignition 구성을 암호화합니다.
  gpg --recipient-file /path/to/ignition.gpg.pub --yes --output /path/to/config.ign.gpg --verbose --armor --encrypt /path/to/config.ign
  Copy to Clipboard Toggle word wrap
IBM® Secure Execution QCOW 이미지를 사용하여 노드를 설치하려면 RHCOS의 빠른 설치 과정을 따르세요.
참고
VM을 시작하기 전에 serial=ignition을 serial=ignition_crypted 로 바꾸고 launchSecurity 매개변수를 추가합니다.

검증

RHCOS의 빠른 설치가 완료되고 첫 번째 부팅 시 Ignition이 실행되면 암호 해독이 성공적인지 확인합니다.

복호화가 성공하면 다음 예와 비슷한 출력이 표시됩니다.

출력 예

[    2.801433] systemd[1]: Starting coreos-ignition-setup-user.service - CoreOS Ignition User Config Setup...

[    2.803959] coreos-secex-ignition-decrypt[731]: gpg: key <key_name>: public key "Secure Execution (secex) 38.20230323.dev.0" imported
[    2.808874] coreos-secex-ignition-decrypt[740]: gpg: encrypted with rsa4096 key, ID <key_name>, created <yyyy-mm-dd>
[  OK  ] Finished coreos-secex-igni…S Secex Ignition Config Decryptor.

[    2.801433] systemd[1]: Starting coreos-ignition-setup-user.service - CoreOS Ignition User Config Setup...

[    2.803959] coreos-secex-ignition-decrypt[731]: gpg: key <key_name>: public key "Secure Execution (secex) 38.20230323.dev.0" imported
[    2.808874] coreos-secex-ignition-decrypt[740]: gpg: encrypted with rsa4096 key, ID <key_name>, created <yyyy-mm-dd>
[  OK  ] Finished coreos-secex-igni…S Secex Ignition Config Decryptor.

Copy to Clipboard

Toggle word wrap

복호화에 실패하면 다음 예와 비슷한 출력이 표시됩니다.

출력 예

Starting coreos-ignition-s…reOS Ignition User Config Setup...
[    2.863675] coreos-secex-ignition-decrypt[729]: gpg: key <key_name>: public key "Secure Execution (secex) 38.20230323.dev.0" imported
[    2.869178] coreos-secex-ignition-decrypt[738]: gpg: encrypted with RSA key, ID <key_name>
[    2.870347] coreos-secex-ignition-decrypt[738]: gpg: public key decryption failed: No secret key
[    2.870371] coreos-secex-ignition-decrypt[738]: gpg: decryption failed: No secret key

Starting coreos-ignition-s…reOS Ignition User Config Setup...
[    2.863675] coreos-secex-ignition-decrypt[729]: gpg: key <key_name>: public key "Secure Execution (secex) 38.20230323.dev.0" imported
[    2.869178] coreos-secex-ignition-decrypt[738]: gpg: encrypted with RSA key, ID <key_name>
[    2.870347] coreos-secex-ignition-decrypt[738]: gpg: public key decryption failed: No secret key
[    2.870371] coreos-secex-ignition-decrypt[738]: gpg: decryption failed: No secret key

Copy to Clipboard

Toggle word wrap

2.6.7.1.2. IBM Z 또는 IBM LinuxONE 환경에서 CEX를 통한 LUKS 암호화
링크 복사

IBM Z® 또는 IBM® LinuxONE 환경에서 IBM® Crypto Express(CEX)를 통해 하드웨어 기반 Linux Unified Key Setup(LUKS) 암호화를 활성화하려면 추가 단계가 필요합니다. 이에 대한 자세한 내용은 이 섹션에서 설명합니다.

사전 요구 사항

butane 유틸리티가 설치되어 있습니다.
부탄을 사용하여 기계 구성을 만드는 방법에 대한 지침을 검토했습니다.

프로세스

제어 평면과 컴퓨팅 노드에 대한 Butane 구성 파일을 만듭니다.
- 예를 들어, 디스크 암호화가 있는 제어 평면 노드에 대해 다음 Butane 구성을 사용하여 main-storage.bu 라는 이름의 파일을 만듭니다.
  variant: openshift version: 4.19.0 metadata: name: main-storage labels: machineconfiguration.openshift.io/role: master boot_device: layout: s390x-virt luks: cex: enabled: true openshift: fips: true
  1
  kernel_arguments: - rd.luks.key=/etc/luks/cex.key
  2
  Copy to Clipboard Toggle word wrap
  1
  FIPS 모드를 활성화할지 비활성화할지 지정합니다. 기본적으로 FIPS 모드는 비활성화됩니다. FIPS 모드가 활성화된 경우 OpenShift Container Platform이 실행되는 Red Hat Enterprise Linux CoreOS(RHCOS) 머신은 기본 Kubernetes 암호화 제품군을 우회하고 대신 RHCOS와 함께 제공되는 암호화 모듈을 사용합니다.
  2
  장치를 해독하는 데 필요한 키의 위치를 지정합니다. 이 값은 변경할 수 없습니다.

ignition.platform.id=metal 및 ignition.firstboot를 포함하는 매개변수 파일을 만듭니다.

제어 평면 머신에 대한 커널 매개변수 파일 예

cio_ignore=all,!condev rd.neednet=1 \
console=ttysclp0 \
ignition.firstboot ignition.platform.id=metal \
coreos.inst.ignition_url=http://<http_server>/master.ign \
coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \
ip=<ip_address>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \
rd.znet=qeth,0.0.bdd0,0.0.bdd1,0.0.bdd2,layer2=1 \
rd.zfcp=0.0.5677,0x600606680g7f0056,0x034F000000000000

cio_ignore=all,!condev rd.neednet=1 \
console=ttysclp0 \
ignition.firstboot ignition.platform.id=metal \
coreos.inst.ignition_url=http://<http_server>/master.ign \

1


coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \

2


ip=<ip_address>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \
rd.znet=qeth,0.0.bdd0,0.0.bdd1,0.0.bdd2,layer2=1 \
rd.zfcp=0.0.5677,0x600606680g7f0056,0x034F000000000000

Copy to Clipboard

Toggle word wrap

1: Ignition 구성 파일의 위치를 지정합니다. master.ign 또는 worker.ign을 사용하세요. HTTP 및 HTTPS 프로토콜만 사용할 수 있습니다.
2: 부팅하려는 커널 과 initramfs 에 대한 rootfs 아티팩트의 위치를 지정합니다. HTTP 및 HTTPS 프로토콜만 사용할 수 있습니다.

참고

매개 변수 파일의 모든 옵션을 한 줄로 작성하고 줄 바꿈 문자가 없는지 확인합니다.

2.6.7.1.3. IBM Z 또는 IBM LinuxONE 환경에서 정적 IP로 NBDE 구성
링크 복사

IBM Z® 또는 IBM® LinuxONE 환경에서 NBDE 디스크 암호화를 활성화하려면 추가 단계가 필요합니다. 이에 대한 자세한 내용은 이 섹션에서 설명합니다.

사전 요구 사항

외부 Tang 서버를 설정했습니다. 자세한 내용은 네트워크 바운드 디스크 암호화를 참조하세요.
butane 유틸리티가 설치되어 있습니다.
부탄을 사용하여 기계 구성을 만드는 방법에 대한 지침을 검토했습니다.

프로세스

제어 평면과 컴퓨팅 노드에 대한 Butane 구성 파일을 만듭니다.

다음은 제어 평면 노드에 대한 Butane 구성의 예이며, 디스크 암호화를 위해 master-storage.bu 라는 이름의 파일을 생성합니다.

variant: openshift
version: 4.19.0
metadata:
  name: master-storage
  labels:
    machineconfiguration.openshift.io/role: master
storage:
  luks:
    - clevis:
        tang:
          - thumbprint: QcPr_NHFJammnRCA3fFMVdNBwjs
            url: http://clevis.example.com:7500
      device: /dev/disk/by-partlabel/root
      label: luks-root
      name: root
      wipe_volume: true
  filesystems:
    - device: /dev/mapper/root
      format: xfs
      label: root
      wipe_filesystem: true
openshift:
  fips: true

variant: openshift
version: 4.19.0
metadata:
  name: master-storage
  labels:
    machineconfiguration.openshift.io/role: master
storage:
  luks:
    - clevis:
        tang:
          - thumbprint: QcPr_NHFJammnRCA3fFMVdNBwjs
            url: http://clevis.example.com:7500
      device: /dev/disk/by-partlabel/root
      label: luks-root
      name: root
      wipe_volume: true
  filesystems:
    - device: /dev/mapper/root
      format: xfs
      label: root
      wipe_filesystem: true
openshift:
  fips: true

1

Copy to Clipboard

Toggle word wrap

1: FIPS 모드 활성화 또는 비활성화 여부입니다. 기본적으로 FIPS 모드는 비활성화됩니다. FIPS 모드가 활성화된 경우 OpenShift Container Platform이 실행되는 Red Hat Enterprise Linux CoreOS(RHCOS) 머신은 기본 Kubernetes 암호화 제품군을 우회하고 대신 RHCOS와 함께 제공되는 암호화 모듈을 사용합니다.

다음 명령을 실행하여 컴퓨터를 부팅하기 위한 사용자 지정 initramfs 파일을 만듭니다.

coreos-installer pxe customize \
    /root/rhcos-bootfiles/rhcos-<release>-live-initramfs.s390x.img \
    --dest-device /dev/disk/by-id/scsi-<serial_number> --dest-karg-append \
    ip=<ip_address>::<gateway_ip>:<subnet_mask>::<network_device>:none \
    --dest-karg-append nameserver=<nameserver_ip> \
    --dest-karg-append rd.neednet=1 -o \
    /root/rhcos-bootfiles/<node_name>-initramfs.s390x.img

$ coreos-installer pxe customize \
    /root/rhcos-bootfiles/rhcos-<release>-live-initramfs.s390x.img \
    --dest-device /dev/disk/by-id/scsi-<serial_number> --dest-karg-append \
    ip=<ip_address>::<gateway_ip>:<subnet_mask>::<network_device>:none \
    --dest-karg-append nameserver=<nameserver_ip> \
    --dest-karg-append rd.neednet=1 -o \
    /root/rhcos-bootfiles/<node_name>-initramfs.s390x.img

Copy to Clipboard

Toggle word wrap

참고

처음 부팅하기 전에 클러스터의 각 노드에 대한 initramfs를 사용자 정의하고 PXE 커널 매개변수를 추가해야 합니다.

ignition.platform.id=metal 및 ignition.firstboot를 포함하는 매개변수 파일을 만듭니다.

제어 평면 머신에 대한 커널 매개변수 파일 예

cio_ignore=all,!condev rd.neednet=1 \
console=ttysclp0 \
ignition.firstboot ignition.platform.id=metal \
coreos.inst.ignition_url=http://<http_server>/master.ign \
coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \
ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \
rd.znet=qeth,0.0.bdd0,0.0.bdd1,0.0.bdd2,layer2=1 \
rd.zfcp=0.0.5677,0x600606680g7f0056,0x034F000000000000 \
zfcp.allow_lun_scan=0

cio_ignore=all,!condev rd.neednet=1 \
console=ttysclp0 \
ignition.firstboot ignition.platform.id=metal \
coreos.inst.ignition_url=http://<http_server>/master.ign \

1


coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \

2


ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns> \
rd.znet=qeth,0.0.bdd0,0.0.bdd1,0.0.bdd2,layer2=1 \
rd.zfcp=0.0.5677,0x600606680g7f0056,0x034F000000000000 \
zfcp.allow_lun_scan=0

Copy to Clipboard

Toggle word wrap

1: Ignition 구성 파일의 위치를 지정합니다. master.ign 또는 worker.ign을 사용하세요. HTTP 및 HTTPS 프로토콜만 지원됩니다.
2: 부팅하는 커널 과 initramfs 에 대한 rootfs 아티팩트의 위치를 지정합니다. HTTP 및 HTTPS 프로토콜만 지원됩니다.

참고

매개 변수 파일의 모든 옵션을 한 줄로 작성하고 줄 바꿈 문자가 없는지 확인합니다.

2.6.7.2. 사전 패키징된 QCOW2 디스크 이미지를 사용한 빠른 설치
링크 복사

RHCOS(Red Hat Enterprise Linux CoreOS)의 빠른 설치로 머신을 생성하고 사전 패키징된 RHCOS(Red Hat Enterprise Linux CoreOS) QEMU COW2(QCOW2) 디스크 이미지를 가져오려면 다음 단계를 완료합니다.

사전 요구 사항

이 절차에서는 KVM이 있는 RHEL 8.6 이상에서 실행되는 LPAR이 하나 이상인 경우를 RHEL KVM 호스트라고 합니다.
RHEL KVM 호스트에 KVM/QEMU 하이퍼바이저가 설치되어 있어야 합니다.
노드의 호스트 이름 및 역방향 조회를 수행할 수 있는 DNS(Domain name server)입니다.
IP 주소를 제공하는 DHCP 서버입니다.

프로세스

Red Hat Customer Portal의 제품 다운로드 페이지 또는 RHCOS 이미지 미러 페이지에서 RHEL QCOW2(QEMU copy-on-write) 디스크 이미지 파일을 받습니다.
중요
RHCOS 이미지는 OpenShift Container Platform 릴리스에 따라 변경되지 않을 수 있습니다. 설치하는 OpenShift Container Platform 버전과 같거나 그 이하의 버전 중 가장 최신 버전의 이미지를 다운로드해야 합니다. 다음 프로세스에 설명된 적절한 RHCOS QCOW2 이미지만 사용합니다.
QCOW2 디스크 이미지 및 Ignition 파일을 RHEL KVM 호스트의 공통 디렉터리에 다운로드합니다.
예: /var/lib/libvirt/images
참고
Ignition 파일은 OpenShift Container Platform 설치 프로그램에서 생성됩니다.

각 KVM 게스트 노드에 대해 QCOW2 디스크 이미지 백업 파일을 사용하여 새 디스크 이미지를 생성합니다.

qemu-img create -f qcow2 -F qcow2 -b /var/lib/libvirt/images/{source_rhcos_qemu} /var/lib/libvirt/images/{vmname}.qcow2 {size}

$ qemu-img create -f qcow2 -F qcow2 -b /var/lib/libvirt/images/{source_rhcos_qemu} /var/lib/libvirt/images/{vmname}.qcow2 {size}

Copy to Clipboard

Toggle word wrap

Ignition 파일 및 새 디스크 이미지를 사용하여 새 KVM 게스트 노드를 생성합니다.

virt-install --noautoconsole \
   --connect qemu:///system \
   --name <vm_name> \
   --memory <memory_mb> \
   --vcpus <vcpus> \
   --disk <disk> \
   --launchSecurity type="s390-pv" \
   --import \
   --network network=<virt_network_parm>,mac=<mac_address> \
   --disk path=<ign_file>,format=raw,readonly=on,serial=ignition,startup_policy=optional

$ virt-install --noautoconsole \
   --connect qemu:///system \
   --name <vm_name> \
   --memory <memory_mb> \
   --vcpus <vcpus> \
   --disk <disk> \
   --launchSecurity type="s390-pv" \

1


   --import \
   --network network=<virt_network_parm>,mac=<mac_address> \
   --disk path=<ign_file>,format=raw,readonly=on,serial=ignition,startup_policy=optional

2

Copy to Clipboard

Toggle word wrap

1: IBM® Secure Execution이 활성화된 경우 launchSecurity type="s390-pv" 매개변수를 추가합니다.
2: IBM® Secure Execution이 활성화된 경우 serial=ignition을 serial=ignition_crypted 로 바꾸세요.

2.6.7.3. 새 QCOW2 디스크 이미지에 전체 설치
링크 복사

새 QCOW2(QCOW2) 디스크 이미지에 전체 설치로 머신을 생성하려면 다음 단계를 완료합니다.

사전 요구 사항

이 절차에서는 KVM이 있는 RHEL 8.6 이상에서 실행되는 LPAR이 하나 이상인 경우를 RHEL KVM 호스트라고 합니다.
RHEL KVM 호스트에 KVM/QEMU 하이퍼바이저가 설치되어 있어야 합니다.
노드의 호스트 이름 및 역방향 조회를 수행할 수 있는 DNS(Domain name server)입니다.
HTTP 또는 HTTPS 서버가 설정됩니다.

프로세스

Red Hat Customer Portal의 Product Downloads 페이지 또는 RHCOS image mirror 페이지에서RHEL kernel, initramfs, rootfs 파일을 받으십시오.
중요
RHCOS 이미지는 OpenShift Container Platform 릴리스에 따라 변경되지 않을 수 있습니다. 설치하는 OpenShift Container Platform 버전과 같거나 그 이하의 버전 중 가장 최신 버전의 이미지를 다운로드해야 합니다. 다음 프로세스에 설명된 적절한 RHCOS QCOW2 이미지만 사용합니다.
OpenShift Container Platform 버전 번호가 파일 이름에 포함됩니다. 다음 예와 유사합니다.
- kernel: rhcos-<version>-live-kernel-<architecture>
- initramfs: rhcos-<version>-live-initramfs.<architecture>.img
- rootfs: rhcos-<version>-live-rootfs.<architecture>.img
virt-install을 시작하기 전에 다운로드한 RHEL 라이브 커널, initramfs 및 rootfs 및 Ignition 파일을 HTTP 또는 HTTPS 서버로 이동합니다.
참고
Ignition 파일은 OpenShift Container Platform 설치 프로그램에서 생성됩니다.

RHEL 커널, initramfs 및 Ignition 파일, 새 디스크 이미지, 수정된 매개 변수 인수를 사용하여 새 KVM 게스트 노드를 만듭니다.

virt-install \
   --connect qemu:///system \
   --name <vm_name> \
   --memory <memory_mb> \
   --vcpus <vcpus> \
   --location <media_location>,kernel=<rhcos_kernel>,initrd=<rhcos_initrd> \ /

$ virt-install \
   --connect qemu:///system \
   --name <vm_name> \
   --memory <memory_mb> \
   --vcpus <vcpus> \
   --location <media_location>,kernel=<rhcos_kernel>,initrd=<rhcos_initrd> \ /

1


   --disk <vm_name>.qcow2,size=<image_size>,cache=none,io=native \
   --network network=<virt_network_parm> \
   --boot hd \
   --extra-args "rd.neednet=1" \
   --extra-args "coreos.inst.install_dev=/dev/<block_device>" \
   --extra-args "coreos.inst.ignition_url=http://<http_server>/bootstrap.ign" \

2


   --extra-args "coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img" \

3


   --extra-args "ip=<ip>::<gateway>:<netmask>:<hostname>::none nameserver=<dns>" \
   --noautoconsole \
   --wait

Copy to Clipboard

Toggle word wrap

1: --location 매개변수에는 HTTP 또는 HTTPS 서버에서 커널/initrd의 위치를 지정합니다.
2: Ignition 구성 파일의 위치를 지정합니다. bootstrap.ign, master.ign 또는 worker.ign을 사용하십시오. HTTP 및 HTTPS 프로토콜만 지원됩니다.
3: 부팅하는 커널 과 initramfs 에 대한 rootfs 아티팩트의 위치를 지정합니다. HTTP 및 HTTPS 프로토콜만 지원됩니다.

2.6.7.4. 고급 RHCOS 설치 참조
링크 복사

이 섹션에서는 Red Hat Enterprise Linux CoreOS(RHCOS) 수동 설치 프로세스를 수정할 수 있는 네트워크 구성 및 기타 고급 옵션을 설명합니다. 다음 표에서는 RHCOS 라이브 설치 프로그램 및 coreos-installer 명령과 함께 사용할 수있는 커널 인수 및 명령 줄 옵션에 대해 설명합니다.

2.6.7.4.1. ISO 설치를 위한 네트워킹 옵션
링크 복사

ISO 이미지에서 RHCOS를 설치하는 경우, 해당 이미지를 부팅할 때 수동으로 커널 인수를 추가하여 노드의 네트워킹을 구성할 수 있습니다. 네트워킹 인수를 지정하지 않으면 RHCOS에서 Ignition 구성 파일을 가져오는 데 네트워킹이 필요함을 감지하면 initramfs에서 DHCP가 활성화됩니다.

중요

네트워킹 인수를 수동으로 추가할 때 initramfs에서 네트워크를 가져오려면 rd.neednet=1 커널 인수도 추가해야 합니다.

다음 정보는 ISO 설치를 위해 RHCOS 노드에서 네트워킹을 구성하는 방법에 대한 예를 제공합니다. 예제에서는 ip= 및 nameserver= 커널 인수를 사용하는 방법을 설명합니다.

참고

커널 인수를 추가할 때 순서가 중요합니다: ip= 및 nameserver=.

이는 시스템 부팅 중에 dracut 툴로 전달되는 네트워킹 옵션입니다. dracut에서 지원하는 네트워킹 옵션에 대한 자세한 내용은 dracut.cmdline 메뉴얼 페이지를 참조하십시오.

다음은 ISO 설치를 위한 네트워킹 옵션의 예입니다.

DHCP 또는 정적 IP 주소 구성

IP 주소를 구성하려면 DHCP(ip=dhcp)를 사용하거나 개별 고정 IP 주소(ip=<host_ip>)를 설정합니다. 정적 IP를 설정하는 경우 각 노드에서 DNS 서버 IP 주소 (nameserver=<dns_ip>)를 확인합니다. 다음 예제 세트:

노드의 IP 주소는 10.10.10.2 입니다.
게이트웨이 주소는 10.10.10.254로 지정
넷마스크를 255.255.255.0 으로 변경
core0.example.com 의 호스트 이름
4.4.4.41의 DNS 서버 주소
auto-configuration 값을 none으로 설정합니다. IP 네트워킹이 정적으로 구성되면 자동 구성이 필요하지 않습니다.

ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
nameserver=4.4.4.41

ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
nameserver=4.4.4.41

Copy to Clipboard

Toggle word wrap

참고

DHCP를 사용하여 RHCOS 시스템의 IP 주소 지정을 구성하는 경우 시스템은 DHCP를 통해 DNS 서버 정보도 가져옵니다. DHCP 기반 배포의 경우 DHCP 서버 구성을 통해 RHCOS 노드에서 사용할 DNS 서버 주소를 정의할 수 있습니다.

정적 호스트 이름 없이 IP 주소 구성

정적 호스트 이름을 할당하지 않고도 IP 주소를 구성할 수 있습니다. 사용자가 정적 호스트 이름을 설정하지 않으면 역방향 DNS 조회를 통해 자동으로 선택되어 설정됩니다. 정적 호스트 이름 없이 IP 주소를 구성하려면 다음 예를 참조하세요.

노드의 IP 주소는 10.10.10.2 입니다.
게이트웨이 주소는 10.10.10.254로 지정
넷마스크를 255.255.255.0 으로 변경
4.4.4.41의 DNS 서버 주소
auto-configuration 값을 none으로 설정합니다. IP 네트워킹이 정적으로 구성되면 자동 구성이 필요하지 않습니다.

ip=10.10.10.2::10.10.10.254:255.255.255.0::enp1s0:none
nameserver=4.4.4.41

ip=10.10.10.2::10.10.10.254:255.255.255.0::enp1s0:none
nameserver=4.4.4.41

Copy to Clipboard

Toggle word wrap

여러 네트워크 인터페이스 지정

여러 개의 ip= 항목을 설정하여 여러 개의 네트워크 인터페이스를 지정할 수 있습니다.

ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
ip=10.10.10.3::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none

ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
ip=10.10.10.3::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none

Copy to Clipboard

Toggle word wrap

기본 게이트웨이 및 경로 구성

선택 사항: rd.route= 값을 설정하여 추가 네트워크에 대한 경로를 구성할 수 있습니다.

참고

하나 이상의 네트워크를 구성할 때 하나의 기본 게이트웨이가 필요합니다. 추가 네트워크 게이트웨이가 기본 네트워크 게이트웨이와 다른 경우 기본 게이트웨이가 기본 네트워크 게이트웨이어야 합니다.

다음 명령을 실행하여 기본 게이트웨이를 구성합니다.
```
ip=::10.10.10.254::::
```
```
ip=::10.10.10.254::::
```
Copy to Clipboard Toggle word wrap
추가 네트워크에 대한 경로를 구성하려면 다음 명령을 입력하세요.
```
rd.route=20.20.20.0/24:20.20.20.254:enp2s0
```
```
rd.route=20.20.20.0/24:20.20.20.254:enp2s0
```
Copy to Clipboard Toggle word wrap

단일 인터페이스에서 DHCP 비활성화

두 개 이상의 네트워크 인터페이스가 있고 그 중 하나의 인터페이스만 사용하는 경우, 단일 인터페이스에서 DHCP를 비활성화할 수 있습니다. 이 예에서 enp1s0 인터페이스는 정적 네트워킹 구성을 갖고 있으며, 사용되지 않는 enp2s0 에 대해 DHCP가 비활성화되어 있습니다.

ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
ip=::::core0.example.com:enp2s0:none

ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp1s0:none
ip=::::core0.example.com:enp2s0:none

Copy to Clipboard

Toggle word wrap

DHCP와 정적 IP 구성 결합

여러 네트워크 인터페이스가 있는 시스템에서는 DHCP 및 정적 IP 구성을 결합할 수 있습니다. 예:

ip=enp1s0:dhcp
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none

ip=enp1s0:dhcp
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0:none

Copy to Clipboard

Toggle word wrap

개별 인터페이스에서 VLAN 구성

선택 사항: vlan= 매개변수를 사용하여 개별 인터페이스에서 VLAN을 구성할 수 있습니다.

네트워크 인터페이스에서 VLAN을 구성하고 고정 IP 주소를 사용하려면 다음 명령을 실행하세요.

ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0.100:none
vlan=enp2s0.100:enp2s0

ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:enp2s0.100:none
vlan=enp2s0.100:enp2s0

Copy to Clipboard

Toggle word wrap

네트워크 인터페이스에서 VLAN을 구성하고 DHCP를 사용하려면 다음 명령을 실행하세요.
```
ip=enp2s0.100:dhcp
vlan=enp2s0.100:enp2s0
```
```
ip=enp2s0.100:dhcp
vlan=enp2s0.100:enp2s0
```
Copy to Clipboard Toggle word wrap

여러 DNS 서버 제공

각 서버에 nameserver= 항목을 추가하여 여러 DNS 서버를 제공할 수 있습니다. 예:

nameserver=1.1.1.1
nameserver=8.8.8.8

nameserver=1.1.1.1
nameserver=8.8.8.8

Copy to Clipboard

Toggle word wrap

2.6.8. 부트스트랩 프로세스가 완료될 때까지 대기 중
링크 복사

OpenShift Container Platform 부트스트랩 프로세스는 클러스터 노드가 먼저 디스크에 설치된 영구 RHCOS 환경으로 부팅된 후에 시작됩니다. Ignition 구성 파일을 통해 제공되는 구성 정보는 부트스트랩 프로세스를 초기화하고 머신에 OpenShift Container Platform을 설치하는 데 사용됩니다. 부트스트랩 프로세스가 완료될 때까지 기다려야 합니다.

사전 요구 사항

클러스터에 대한 Ignition 구성 파일이 생성되어 있습니다.
적합한 네트워크, DNS 및 로드 밸런싱 인프라가 구성되어 있습니다.
설치 프로그램을 받아서 클러스터의 Ignition 구성 파일을 생성했습니다.
클러스터 머신에 RHCOS를 설치하고 OpenShift Container Platform 설치 프로그램에서 생성된 Ignition 구성 파일을 제공했습니다.

프로세스

부트스트랩 프로세스를 모니터링합니다.

./openshift-install --dir <installation_directory> wait-for bootstrap-complete \
    --log-level=info

$ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete \

1


    --log-level=info

2

Copy to Clipboard

Toggle word wrap

1: <installation_directory>는 설치 파일을 저장한 디렉터리의 경로를 지정합니다.
2: 다른 설치 세부 사항을 보려면 info 대신 warn, debug 또는 error를 지정합니다.

출력 예

INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443...
INFO API v1.32.3 up
INFO Waiting up to 30m0s for bootstrapping to complete...
INFO It is now safe to remove the bootstrap resources

INFO Waiting up to 30m0s for the Kubernetes API at https://api.test.example.com:6443...
INFO API v1.32.3 up
INFO Waiting up to 30m0s for bootstrapping to complete...
INFO It is now safe to remove the bootstrap resources

Copy to Clipboard

Toggle word wrap

이 명령은 Kubernetes API 서버가 컨트롤 플레인 시스템에서 부트스트랩되었다는 신호를 보낼 때 성공합니다.

부트스트랩 프로세스가 완료되면 로드 밸런서에서 부트스트랩 머신을 제거합니다.
중요
이 시점에 로드 밸런서에서 부트스트랩 시스템을 제거해야 합니다. 부트스트랩 머신 자체를 제거하거나 다시 포맷할 수도 있습니다.

2.6.9. CLI를 사용하여 클러스터에 로그인
링크 복사

클러스터 kubeconfig 파일을 내보내서 기본 시스템 사용자로 클러스터에 로그인할 수 있습니다. kubeconfig 파일에는 CLI에서 올바른 클러스터 및 API 서버에 클라이언트를 연결하는 데 사용하는 클러스터에 대한 정보가 포함되어 있습니다. 이 파일은 클러스터별로 고유하며 OpenShift Container Platform 설치 과정에서 생성됩니다.

사전 요구 사항

OpenShift Container Platform 클러스터를 배포했습니다.
oc CLI를 설치했습니다.

프로세스

kubeadmin 인증 정보를 내보냅니다.
```
export KUBECONFIG=<installation_directory>/auth/kubeconfig
```
```
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig 
```
1
Copy to Clipboard Toggle word wrap
1
<installation_directory>는 설치 파일을 저장한 디렉터리의 경로를 지정합니다.
내보낸 구성을 사용하여 oc 명령을 성공적으로 실행할 수 있는지 확인합니다.
```
oc whoami
```
```
$ oc whoami
```
Copy to Clipboard Toggle word wrap
출력 예
```
system:admin
```
```
system:admin
```
Copy to Clipboard Toggle word wrap

2.6.10. 머신의 인증서 서명 요청 승인
링크 복사

클러스터에 시스템을 추가하면 추가한 시스템별로 보류 중인 인증서 서명 요청(CSR)이 두 개씩 생성됩니다. 이러한 CSR이 승인되었는지 확인해야 하며, 필요한 경우 이를 직접 승인해야 합니다. 클라이언트 요청을 먼저 승인한 다음 서버 요청을 승인해야 합니다.

사전 요구 사항

클러스터에 시스템을 추가했습니다.

프로세스

클러스터가 시스템을 인식하는지 확인합니다.
```
oc get nodes
```
```
$ oc get nodes
```
Copy to Clipboard Toggle word wrap
출력 예
```
NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  63m  v1.32.3
master-1  Ready     master  63m  v1.32.3
master-2  Ready     master  64m  v1.32.3
```
```
NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  63m  v1.32.3
master-1  Ready     master  63m  v1.32.3
master-2  Ready     master  64m  v1.32.3
```
Copy to Clipboard Toggle word wrap
출력에 생성된 모든 시스템이 나열됩니다.
참고
이전 출력에는 일부 CSR이 승인될 때까지 컴퓨팅 노드(작업자 노드라고도 함)가 포함되지 않을 수 있습니다.

보류 중인 CSR을 검토하고 클러스터에 추가한 각 시스템에 대해 Pending 또는 Approved 상태의 클라이언트 및 서버 요청이 표시되는지 확인합니다.

oc get csr

$ oc get csr

Copy to Clipboard

Toggle word wrap

출력 예

NAME        AGE     REQUESTOR                                                                   CONDITION
csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
...

NAME        AGE     REQUESTOR                                                                   CONDITION
csr-8b2br   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
csr-8vnps   15m     system:serviceaccount:openshift-machine-config-operator:node-bootstrapper   Pending
...

Copy to Clipboard

Toggle word wrap

예에서는 두 시스템이 클러스터에 참여하고 있습니다. 목록에는 승인된 CSR이 더 많이 나타날 수도 있습니다.

CSR이 승인되지 않은 경우, 추가된 시스템에 대한 모든 보류 중인 CSR이 Pending 상태로 전환된 후 클러스터 시스템의 CSR을 승인합니다.
참고
CSR은 교체 주기가 자동으로 만료되므로 클러스터에 시스템을 추가한 후 1시간 이내에 CSR을 승인하십시오. 한 시간 내에 승인하지 않으면 인증서가 교체되고 각 노드에 대해 두 개 이상의 인증서가 표시됩니다. 이러한 인증서를 모두 승인해야 합니다. 클라이언트 CSR이 승인되면 Kubelet은 인증서에 대한 보조 CSR을 생성하므로 수동 승인이 필요합니다. 그러면 Kubelet에서 동일한 매개변수를 사용하여 새 인증서를 요청하는 경우 인증서 갱신 요청은 machine-approver에 의해 자동으로 승인됩니다.
참고
베어 메탈 및 기타 사용자 프로비저닝 인프라와 같이 머신 API를 사용하도록 활성화되지 않는 플랫폼에서 실행되는 클러스터의 경우 CSR(Kubelet service Certificate Request)을 자동으로 승인하는 방법을 구현해야 합니다. 요청이 승인되지 않으면 API 서버가 kubelet에 연결될 때 서비스 인증서가 필요하므로 oc exec, oc rsh, oc logs 명령을 성공적으로 수행할 수 없습니다. Kubelet 엔드 포인트에 연결하는 모든 작업을 수행하려면 이 인증서 승인이 필요합니다. 이 방법은 새 CSR을 감시하고 CSR이 system:node 또는 system:admin 그룹의 node-bootstrapper 서비스 계정에 의해 제출되었는지 확인하고 노드의 ID를 확인합니다.
- 개별적으로 승인하려면 유효한 CSR 각각에 대해 다음 명령을 실행하십시오.
  $ oc adm certificate approve <csr_name>
  1
  Copy to Clipboard Toggle word wrap
  1
  <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.
- 보류 중인 CSR을 모두 승인하려면 다음 명령을 실행하십시오.
  $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approve
  Copy to Clipboard Toggle word wrap
  참고
  일부 Operator는 일부 CSR이 승인될 때까지 사용할 수 없습니다.

이제 클라이언트 요청이 승인되었으므로 클러스터에 추가한 각 머신의 서버 요청을 검토해야 합니다.

oc get csr

$ oc get csr

Copy to Clipboard

Toggle word wrap

출력 예

NAME        AGE     REQUESTOR                                                                   CONDITION
csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
...

NAME        AGE     REQUESTOR                                                                   CONDITION
csr-bfd72   5m26s   system:node:ip-10-0-50-126.us-east-2.compute.internal                       Pending
csr-c57lv   5m26s   system:node:ip-10-0-95-157.us-east-2.compute.internal                       Pending
...

Copy to Clipboard

Toggle word wrap

나머지 CSR이 승인되지 않고 Pending 상태인 경우 클러스터 머신의 CSR을 승인합니다.
- 개별적으로 승인하려면 유효한 CSR 각각에 대해 다음 명령을 실행하십시오.
  $ oc adm certificate approve <csr_name>
  1
  Copy to Clipboard Toggle word wrap
  1
  <csr_name>은 현재 CSR 목록에 있는 CSR의 이름입니다.
- 보류 중인 CSR을 모두 승인하려면 다음 명령을 실행하십시오.
  $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve
  Copy to Clipboard Toggle word wrap

모든 클라이언트 및 서버 CSR이 승인된 후 머신은 Ready 상태가 됩니다. 다음 명령을 실행하여 확인합니다.

oc get nodes

$ oc get nodes

Copy to Clipboard

Toggle word wrap

출력 예

NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  73m  v1.32.3
master-1  Ready     master  73m  v1.32.3
master-2  Ready     master  74m  v1.32.3
worker-0  Ready     worker  11m  v1.32.3
worker-1  Ready     worker  11m  v1.32.3

NAME      STATUS    ROLES   AGE  VERSION
master-0  Ready     master  73m  v1.32.3
master-1  Ready     master  73m  v1.32.3
master-2  Ready     master  74m  v1.32.3
worker-0  Ready     worker  11m  v1.32.3
worker-1  Ready     worker  11m  v1.32.3

Copy to Clipboard

Toggle word wrap

참고

머신이 Ready 상태로 전환하는 데 서버 CSR의 승인 후 몇 분이 걸릴 수 있습니다.

추가 정보

인증서 서명 요청

2.6.11. Operator의 초기 설정
링크 복사

컨트롤 플레인이 초기화된 후 일부 Operator를 즉시 구성하여 모두 사용 가능하도록 해야 합니다.

사전 요구 사항

컨트롤 플레인이 초기화되어 있습니다.

프로세스

클러스터 구성 요소가 온라인 상태인지 확인합니다.

watch -n5 oc get clusteroperators

$ watch -n5 oc get clusteroperators

Copy to Clipboard

Toggle word wrap

출력 예

NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
authentication                             4.19.0    True        False         False      19m
baremetal                                  4.19.0    True        False         False      37m
cloud-credential                           4.19.0    True        False         False      40m
cluster-autoscaler                         4.19.0    True        False         False      37m
config-operator                            4.19.0    True        False         False      38m
console                                    4.19.0    True        False         False      26m
csi-snapshot-controller                    4.19.0    True        False         False      37m
dns                                        4.19.0    True        False         False      37m
etcd                                       4.19.0    True        False         False      36m
image-registry                             4.19.0    True        False         False      31m
ingress                                    4.19.0    True        False         False      30m
insights                                   4.19.0    True        False         False      31m
kube-apiserver                             4.19.0    True        False         False      26m
kube-controller-manager                    4.19.0    True        False         False      36m
kube-scheduler                             4.19.0    True        False         False      36m
kube-storage-version-migrator              4.19.0    True        False         False      37m
machine-api                                4.19.0    True        False         False      29m
machine-approver                           4.19.0    True        False         False      37m
machine-config                             4.19.0    True        False         False      36m
marketplace                                4.19.0    True        False         False      37m
monitoring                                 4.19.0    True        False         False      29m
network                                    4.19.0    True        False         False      38m
node-tuning                                4.19.0    True        False         False      37m
openshift-apiserver                        4.19.0    True        False         False      32m
openshift-controller-manager               4.19.0    True        False         False      30m
openshift-samples                          4.19.0    True        False         False      32m
operator-lifecycle-manager                 4.19.0    True        False         False      37m
operator-lifecycle-manager-catalog         4.19.0    True        False         False      37m
operator-lifecycle-manager-packageserver   4.19.0    True        False         False      32m
service-ca                                 4.19.0    True        False         False      38m
storage                                    4.19.0    True        False         False      37m

NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
authentication                             4.19.0    True        False         False      19m
baremetal                                  4.19.0    True        False         False      37m
cloud-credential                           4.19.0    True        False         False      40m
cluster-autoscaler                         4.19.0    True        False         False      37m
config-operator                            4.19.0    True        False         False      38m
console                                    4.19.0    True        False         False      26m
csi-snapshot-controller                    4.19.0    True        False         False      37m
dns                                        4.19.0    True        False         False      37m
etcd                                       4.19.0    True        False         False      36m
image-registry                             4.19.0    True        False         False      31m
ingress                                    4.19.0    True        False         False      30m
insights                                   4.19.0    True        False         False      31m
kube-apiserver                             4.19.0    True        False         False      26m
kube-controller-manager                    4.19.0    True        False         False      36m
kube-scheduler                             4.19.0    True        False         False      36m
kube-storage-version-migrator              4.19.0    True        False         False      37m
machine-api                                4.19.0    True        False         False      29m
machine-approver                           4.19.0    True        False         False      37m
machine-config                             4.19.0    True        False         False      36m
marketplace                                4.19.0    True        False         False      37m
monitoring                                 4.19.0    True        False         False      29m
network                                    4.19.0    True        False         False      38m
node-tuning                                4.19.0    True        False         False      37m
openshift-apiserver                        4.19.0    True        False         False      32m
openshift-controller-manager               4.19.0    True        False         False      30m
openshift-samples                          4.19.0    True        False         False      32m
operator-lifecycle-manager                 4.19.0    True        False         False      37m
operator-lifecycle-manager-catalog         4.19.0    True        False         False      37m
operator-lifecycle-manager-packageserver   4.19.0    True        False         False      32m
service-ca                                 4.19.0    True        False         False      38m
storage                                    4.19.0    True        False         False      37m

Copy to Clipboard

Toggle word wrap

사용할 수 없는 Operator를 구성합니다.

2.6.11.1. 기본 OperatorHub 카탈로그 소스 비활성화
링크 복사

Red Hat 및 커뮤니티 프로젝트에서 제공하는 콘텐츠를 소싱하는 Operator 카탈로그는 OpenShift Container Platform을 설치하는 동안 기본적으로 OperatorHub용으로 구성됩니다. 제한된 네트워크 환경에서는 클러스터 관리자로서 기본 카탈로그를 비활성화해야 합니다.

프로세스

OperatorHub 오브젝트에 disableAllDefaultSources: true를 추가하여 기본 카탈로그의 소스를 비활성화합니다.

oc patch OperatorHub cluster --type json \
    -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'

$ oc patch OperatorHub cluster --type json \
    -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'

Copy to Clipboard

Toggle word wrap

작은 정보

또는 웹 콘솔을 사용하여 카탈로그 소스를 관리할 수 있습니다. 관리 클러스터 설정 구성 OperatorHub 페이지에서 소스 탭을 클릭하면 개별 소스를 생성, 업데이트, 삭제, 비활성화 및 활성화할 수 있습니다.

2.6.11.2. 이미지 레지스트리 스토리지 구성
링크 복사

기본 스토리지를 제공하지 않는 플랫폼에서는 처음에 Image Registry Operator를 사용할 수 없습니다. 설치한 후에 스토리지를 사용하도록 레지스트리를 구성하여 Registry Operator를 사용 가능하도록 만들어야 합니다.

프로덕션 클러스터에 필요한 영구 볼륨을 구성하는 과정의 지침이 표시됩니다. 해당하는 경우, 프로덕션 환경 외 클러스터에서만 사용할 수 있는 저장 위치로서 빈 디렉터리를 구성하는 과정의 지침이 표시됩니다.

업그레이드 중에 Recreate 롤아웃 전략을 사용하여 이미지 레지스트리의 블록 스토리지 유형 사용을 허용하기 위한 추가 지침이 제공됩니다.

2.6.11.2.1. IBM Z용 레지스트리 스토리지 구성
링크 복사

클러스터 관리자는 설치한 후 스토리지를 사용하도록 레지스트리를 구성해야 합니다.

사전 요구 사항

cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
IBM Z®에 클러스터가 있습니다.
Red Hat OpenShift Data Foundation과 같이 클러스터용 영구 스토리지를 프로비저닝합니다.
중요
OpenShift Container Platform은 복제본이 하나만 있는 경우 이미지 레지스트리 스토리지에 대한 ReadWriteOnce 액세스를 지원합니다. ReadWriteOnce 액세스에는 레지스트리가 Recreate 롤아웃 전략을 사용해야 합니다. 두 개 이상의 복제본으로 고 가용성을 지원하는 이미지 레지스트리를 배포하려면 ReadWriteMany 액세스가 필요합니다.
"100Gi" 용량이 필요합니다.

프로세스

스토리지를 사용하도록 레지스트리를 구성하기 위해 configs.imageregistry/cluster 리소스에서 spec.storage.pvc를 변경합니다.
참고
공유 스토리지를 사용하는 경우 보안 설정을 검토하여 외부 액세스를 방지합니다.
레지스트리 pod가 없는지 확인합니다.
```
oc get pod -n openshift-image-registry -l docker-registry=default
```
```
$ oc get pod -n openshift-image-registry -l docker-registry=default
```
Copy to Clipboard Toggle word wrap
출력 예
```
No resources found in openshift-image-registry namespace
```
```
No resources found in openshift-image-registry namespace
```
Copy to Clipboard Toggle word wrap
참고
출력에 레지스트리 Pod가 있는 경우 이 절차를 계속할 필요가 없습니다.
레지스트리 구성을 확인합니다.
```
oc edit configs.imageregistry.operator.openshift.io
```
```
$ oc edit configs.imageregistry.operator.openshift.io
```
Copy to Clipboard Toggle word wrap
출력 예
```
storage:
  pvc:
    claim:
```
```
storage:
  pvc:
    claim:
```
Copy to Clipboard Toggle word wrap
image-registry-storage PVC의 자동 생성을 허용하도록 claim 필드를 비워 둡니다.

clusteroperator 상태를 확인합니다.

oc get clusteroperator image-registry

$ oc get clusteroperator image-registry

Copy to Clipboard

Toggle word wrap

출력 예

NAME             VERSION              AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
image-registry   4.19                 True        False         False      6h50m

NAME             VERSION              AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
image-registry   4.19                 True        False         False      6h50m

Copy to Clipboard

Toggle word wrap

이미지를 빌드 및 푸시할 수 있도록 레지스트리의 관리가 설정되어 있는지 확인하십시오.
- 다음을 실행합니다.
  $ oc edit configs.imageregistry/cluster
  Copy to Clipboard Toggle word wrap
  다음으로 라인을 변경하십시오.
  managementState: Removed
  Copy to Clipboard Toggle word wrap
  다음으로 변경
  managementState: Managed
  Copy to Clipboard Toggle word wrap

2.6.11.2.2. 프로덕션 환경 외 클러스터에서 이미지 레지스트리의 스토리지 구성
링크 복사

이미지 레지스트리 Operator에 대한 스토리지를 구성해야 합니다. 프로덕션 환경 외 클러스터의 경우, 이미지 레지스트리를 빈 디렉터리로 설정할 수 있습니다. 이렇게 하는 경우 레지스트리를 다시 시작하면 모든 이미지가 손실됩니다.

프로세스

이미지 레지스트리 스토리지를 빈 디렉터리로 설정하려면 다음을 수행하십시오.
```
oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'
```
```
$ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"storage":{"emptyDir":{}}}}'
```
Copy to Clipboard Toggle word wrap
주의
프로덕션 환경 외 클러스터에 대해서만 이 옵션을 구성하십시오.
Image Registry Operator가 구성 요소를 초기화하기 전에 이 명령을 실행하면 oc patch 명령이 실패하며 다음 오류가 발생합니다.
```
Error from server (NotFound): configs.imageregistry.operator.openshift.io "cluster" not found
```
```
Error from server (NotFound): configs.imageregistry.operator.openshift.io "cluster" not found
```
Copy to Clipboard Toggle word wrap
몇 분 후에 명령을 다시 실행하십시오.

2.6.12. 사용자 프로비저닝 인프라에 설치 완료
링크 복사

Operator 구성을 완료한 후 제공하는 인프라에 클러스터 설치를 완료할 수 있습니다.

사전 요구 사항

컨트롤 플레인이 초기화되어 있습니다.
초기 Operator 구성을 완료해야 합니다.

프로세스

다음 명령을 사용하여 모든 클러스터 구성 요소가 온라인 상태인지 확인합니다.

watch -n5 oc get clusteroperators

$ watch -n5 oc get clusteroperators

Copy to Clipboard

Toggle word wrap

출력 예

NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
authentication                             4.19.0    True        False         False      19m
baremetal                                  4.19.0    True        False         False      37m
cloud-credential                           4.19.0    True        False         False      40m
cluster-autoscaler                         4.19.0    True        False         False      37m
config-operator                            4.19.0    True        False         False      38m
console                                    4.19.0    True        False         False      26m
csi-snapshot-controller                    4.19.0    True        False         False      37m
dns                                        4.19.0    True        False         False      37m
etcd                                       4.19.0    True        False         False      36m
image-registry                             4.19.0    True        False         False      31m
ingress                                    4.19.0    True        False         False      30m
insights                                   4.19.0    True        False         False      31m
kube-apiserver                             4.19.0    True        False         False      26m
kube-controller-manager                    4.19.0    True        False         False      36m
kube-scheduler                             4.19.0    True        False         False      36m
kube-storage-version-migrator              4.19.0    True        False         False      37m
machine-api                                4.19.0    True        False         False      29m
machine-approver                           4.19.0    True        False         False      37m
machine-config                             4.19.0    True        False         False      36m
marketplace                                4.19.0    True        False         False      37m
monitoring                                 4.19.0    True        False         False      29m
network                                    4.19.0    True        False         False      38m
node-tuning                                4.19.0    True        False         False      37m
openshift-apiserver                        4.19.0    True        False         False      32m
openshift-controller-manager               4.19.0    True        False         False      30m
openshift-samples                          4.19.0    True        False         False      32m
operator-lifecycle-manager                 4.19.0    True        False         False      37m
operator-lifecycle-manager-catalog         4.19.0    True        False         False      37m
operator-lifecycle-manager-packageserver   4.19.0    True        False         False      32m
service-ca                                 4.19.0    True        False         False      38m
storage                                    4.19.0    True        False         False      37m

NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
authentication                             4.19.0    True        False         False      19m
baremetal                                  4.19.0    True        False         False      37m
cloud-credential                           4.19.0    True        False         False      40m
cluster-autoscaler                         4.19.0    True        False         False      37m
config-operator                            4.19.0    True        False         False      38m
console                                    4.19.0    True        False         False      26m
csi-snapshot-controller                    4.19.0    True        False         False      37m
dns                                        4.19.0    True        False         False      37m
etcd                                       4.19.0    True        False         False      36m
image-registry                             4.19.0    True        False         False      31m
ingress                                    4.19.0    True        False         False      30m
insights                                   4.19.0    True        False         False      31m
kube-apiserver                             4.19.0    True        False         False      26m
kube-controller-manager                    4.19.0    True        False         False      36m
kube-scheduler                             4.19.0    True        False         False      36m
kube-storage-version-migrator              4.19.0    True        False         False      37m
machine-api                                4.19.0    True        False         False      29m
machine-approver                           4.19.0    True        False         False      37m
machine-config                             4.19.0    True        False         False      36m
marketplace                                4.19.0    True        False         False      37m
monitoring                                 4.19.0    True        False         False      29m
network                                    4.19.0    True        False         False      38m
node-tuning                                4.19.0    True        False         False      37m
openshift-apiserver                        4.19.0    True        False         False      32m
openshift-controller-manager               4.19.0    True        False         False      30m
openshift-samples                          4.19.0    True        False         False      32m
operator-lifecycle-manager                 4.19.0    True        False         False      37m
operator-lifecycle-manager-catalog         4.19.0    True        False         False      37m
operator-lifecycle-manager-packageserver   4.19.0    True        False         False      32m
service-ca                                 4.19.0    True        False         False      38m
storage                                    4.19.0    True        False         False      37m

Copy to Clipboard

Toggle word wrap

또는 다음 명령은 모든 클러스터를 사용할 수 있을 때 알립니다. 또한 인증 정보를 검색하고 표시합니다.

./openshift-install --dir <installation_directory> wait-for install-complete

$ ./openshift-install --dir <installation_directory> wait-for install-complete

1

Copy to Clipboard

Toggle word wrap

1: <installation_directory>는 설치 파일을 저장한 디렉터리의 경로를 지정합니다.

출력 예

INFO Waiting up to 30m0s for the cluster to initialize...

INFO Waiting up to 30m0s for the cluster to initialize...

Copy to Clipboard

Toggle word wrap

Cluster Version Operator가 Kubernetes API 서버에서 OpenShift Container Platform 클러스터 배포를 완료하면 명령이 성공합니다.

중요

설치 프로그램에서 생성하는 Ignition 구성 파일에 24시간 후에 만료되는 인증서가 포함되어 있습니다. 이 인증서는 그 후에 갱신됩니다. 인증서를 갱신하기 전에 클러스터가 종료되고 24시간이 지난 후에 클러스터가 다시 시작되면 클러스터는 만료된 인증서를 자동으로 복구합니다. 예외적으로 kubelet 인증서를 복구하려면 대기 중인 node-bootstrapper 인증서 서명 요청(CSR)을 수동으로 승인해야 합니다. 자세한 내용은 만료된 컨트롤 플레인 인증서에서 복구 문서를 참조하십시오.
24 시간 인증서는 클러스터를 설치한 후 16시간에서 22시간으로 인증서가 교체되기 때문에 생성된 후 12시간 이내에 Ignition 구성 파일을 사용하는 것이 좋습니다. 12시간 이내에 Ignition 구성 파일을 사용하면 설치 중에 인증서 업데이트가 실행되는 경우 설치 실패를 방지할 수 있습니다.

Kubernetes API 서버가 Pod와 통신하고 있는지 확인합니다.

모든 Pod 목록을 보려면 다음 명령을 사용하십시오.

oc get pods --all-namespaces

$ oc get pods --all-namespaces

Copy to Clipboard

Toggle word wrap

출력 예

NAMESPACE                         NAME                                            READY   STATUS      RESTARTS   AGE
openshift-apiserver-operator      openshift-apiserver-operator-85cb746d55-zqhs8   1/1     Running     1          9m
openshift-apiserver               apiserver-67b9g                                 1/1     Running     0          3m
openshift-apiserver               apiserver-ljcmx                                 1/1     Running     0          1m
openshift-apiserver               apiserver-z25h4                                 1/1     Running     0          2m
openshift-authentication-operator authentication-operator-69d5d8bf84-vh2n8        1/1     Running     0          5m
...

NAMESPACE                         NAME                                            READY   STATUS      RESTARTS   AGE
openshift-apiserver-operator      openshift-apiserver-operator-85cb746d55-zqhs8   1/1     Running     1          9m
openshift-apiserver               apiserver-67b9g                                 1/1     Running     0          3m
openshift-apiserver               apiserver-ljcmx                                 1/1     Running     0          1m
openshift-apiserver               apiserver-z25h4                                 1/1     Running     0          2m
openshift-authentication-operator authentication-operator-69d5d8bf84-vh2n8        1/1     Running     0          5m
...

Copy to Clipboard

Toggle word wrap

다음 명령을 사용하여 이전 명령의 출력에 나열된 Pod의 로그를 표시합니다.
```
oc logs <pod_name> -n <namespace>
```
```
$ oc logs <pod_name> -n <namespace> 
```
1
Copy to Clipboard Toggle word wrap
1
이전 명령의 출력에 표시된 대로 Pod 이름과 네임스페이스를 지정합니다.
Pod 로그가 표시되면 Kubernetes API 서버는 클러스터 시스템과 통신할 수 있습니다.

FCP(Fibre Channel Protocol)를 사용하는 설치에는 다중 경로를 활성화하기 위해 추가 단계가 필요합니다. 설치 중에 멀티패스를 활성화하지 마십시오.
자세한 내용은 설치 후 머신 구성 작업 설명서의 "RHCOS에서 커널 인수를 사용하여 다중 경로 활성화"를 참조하세요.
클러스터 등록 페이지에서 클러스터를 등록합니다.

2.6.13. 다음 단계
링크 복사

클러스터 사용자 정의

2.6.1. 사전 요구 사항링크 복사링크가 클립보드에 복사되었습니다!

2.6.2. 네트워크가 제한된 환경에서의 설치 정보링크 복사링크가 클립보드에 복사되었습니다!

2.6.2.1. 추가 제한링크 복사링크가 클립보드에 복사되었습니다!

2.6.3. 사용자 프로비저닝 인프라 준비링크 복사링크가 클립보드에 복사되었습니다!

2.6.4. 수동으로 설치 구성 파일 만들기링크 복사링크가 클립보드에 복사되었습니다!

2.6.4.1. IBM Z용 샘플 install-config.yaml 파일링크 복사링크가 클립보드에 복사되었습니다!

2.6.4.2. 설치 중 클러스터 단위 프록시 구성링크 복사링크가 클립보드에 복사되었습니다!

2.6.4.3. 3개의 노드 클러스터 구성링크 복사링크가 클립보드에 복사되었습니다!

2.6.5. CNO(Cluster Network Operator) 구성링크 복사링크가 클립보드에 복사되었습니다!

2.6.5.1. CNO(Cluster Network Operator) 구성 오브젝트링크 복사링크가 클립보드에 복사되었습니다!

defaultNetwork 오브젝트 구성

OVN-Kubernetes 네트워크 플러그인 구성

2.6.6. Kubernetes 매니페스트 및 Ignition 설정 파일 생성링크 복사링크가 클립보드에 복사되었습니다!

2.6.7. RHCOS 설치 및 OpenShift Container Platform 부트스트랩 프로세스 시작링크 복사링크가 클립보드에 복사되었습니다!

2.6.7.1. IBM Z 또는 IBM LinuxONE 환경의 노드에 대한 암호화 구성링크 복사링크가 클립보드에 복사되었습니다!

2.6.7.1.1. IBM Secure Execution을 사용하여 RHCOS 설치링크 복사링크가 클립보드에 복사되었습니다!

2.6.7.1.2. IBM Z 또는 IBM LinuxONE 환경에서 CEX를 통한 LUKS 암호화링크 복사링크가 클립보드에 복사되었습니다!

2.6.7.1.3. IBM Z 또는 IBM LinuxONE 환경에서 정적 IP로 NBDE 구성링크 복사링크가 클립보드에 복사되었습니다!

2.6.7.2. 사전 패키징된 QCOW2 디스크 이미지를 사용한 빠른 설치링크 복사링크가 클립보드에 복사되었습니다!

2.6.7.3. 새 QCOW2 디스크 이미지에 전체 설치링크 복사링크가 클립보드에 복사되었습니다!

2.6.7.4. 고급 RHCOS 설치 참조링크 복사링크가 클립보드에 복사되었습니다!

2.6.7.4.1. ISO 설치를 위한 네트워킹 옵션링크 복사링크가 클립보드에 복사되었습니다!

DHCP 또는 정적 IP 주소 구성

정적 호스트 이름 없이 IP 주소 구성

여러 네트워크 인터페이스 지정

기본 게이트웨이 및 경로 구성

단일 인터페이스에서 DHCP 비활성화

DHCP와 정적 IP 구성 결합

개별 인터페이스에서 VLAN 구성

여러 DNS 서버 제공

2.6.8. 부트스트랩 프로세스가 완료될 때까지 대기 중링크 복사링크가 클립보드에 복사되었습니다!

2.6.9. CLI를 사용하여 클러스터에 로그인링크 복사링크가 클립보드에 복사되었습니다!

2.6.10. 머신의 인증서 서명 요청 승인링크 복사링크가 클립보드에 복사되었습니다!

2.6.11. Operator의 초기 설정링크 복사링크가 클립보드에 복사되었습니다!

2.6.11.1. 기본 OperatorHub 카탈로그 소스 비활성화링크 복사링크가 클립보드에 복사되었습니다!

2.6.11.2. 이미지 레지스트리 스토리지 구성링크 복사링크가 클립보드에 복사되었습니다!

2.6.11.2.1. IBM Z용 레지스트리 스토리지 구성링크 복사링크가 클립보드에 복사되었습니다!

2.6.11.2.2. 프로덕션 환경 외 클러스터에서 이미지 레지스트리의 스토리지 구성링크 복사링크가 클립보드에 복사되었습니다!

2.6.12. 사용자 프로비저닝 인프라에 설치 완료링크 복사링크가 클립보드에 복사되었습니다!

2.6.13. 다음 단계링크 복사링크가 클립보드에 복사되었습니다!

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

Red Hat 소개

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

2.6.1. 사전 요구 사항
링크 복사

2.6.2. 네트워크가 제한된 환경에서의 설치 정보
링크 복사

2.6.2.1. 추가 제한
링크 복사

2.6.3. 사용자 프로비저닝 인프라 준비
링크 복사

2.6.4. 수동으로 설치 구성 파일 만들기
링크 복사

2.6.4.1. IBM Z용 샘플 install-config.yaml 파일
링크 복사

2.6.4.2. 설치 중 클러스터 단위 프록시 구성
링크 복사

2.6.4.3. 3개의 노드 클러스터 구성
링크 복사

2.6.5. CNO(Cluster Network Operator) 구성
링크 복사

2.6.5.1. CNO(Cluster Network Operator) 구성 오브젝트
링크 복사

2.6.6. Kubernetes 매니페스트 및 Ignition 설정 파일 생성
링크 복사

2.6.7. RHCOS 설치 및 OpenShift Container Platform 부트스트랩 프로세스 시작
링크 복사

2.6.7.1. IBM Z 또는 IBM LinuxONE 환경의 노드에 대한 암호화 구성
링크 복사

2.6.7.1.1. IBM Secure Execution을 사용하여 RHCOS 설치
링크 복사

2.6.7.1.2. IBM Z 또는 IBM LinuxONE 환경에서 CEX를 통한 LUKS 암호화
링크 복사

2.6.7.1.3. IBM Z 또는 IBM LinuxONE 환경에서 정적 IP로 NBDE 구성
링크 복사

2.6.7.2. 사전 패키징된 QCOW2 디스크 이미지를 사용한 빠른 설치
링크 복사

2.6.7.3. 새 QCOW2 디스크 이미지에 전체 설치
링크 복사

2.6.7.4. 고급 RHCOS 설치 참조
링크 복사

2.6.7.4.1. ISO 설치를 위한 네트워킹 옵션
링크 복사

2.6.8. 부트스트랩 프로세스가 완료될 때까지 대기 중
링크 복사

2.6.9. CLI를 사용하여 클러스터에 로그인
링크 복사

2.6.10. 머신의 인증서 서명 요청 승인
링크 복사

2.6.11. Operator의 초기 설정
링크 복사

2.6.11.1. 기본 OperatorHub 카탈로그 소스 비활성화
링크 복사

2.6.11.2. 이미지 레지스트리 스토리지 구성
링크 복사

2.6.11.2.1. IBM Z용 레지스트리 스토리지 구성
링크 복사

2.6.11.2.2. 프로덕션 환경 외 클러스터에서 이미지 레지스트리의 스토리지 구성
링크 복사

2.6.12. 사용자 프로비저닝 인프라에 설치 완료
링크 복사

2.6.13. 다음 단계
링크 복사