Red Hat Summit2.7. IBM Z 및 IBM LinuxONE의 LPAR에 클러스터 설치
OpenShift Container Platform 버전 4.19에서는 프로비저닝하는 IBM Z® 또는 IBM® LinuxONE 인프라의 논리 파티션(LPAR)에 클러스터를 설치할 수 있습니다.
이 문서는 IBM Z®에만 해당하지만, 모든 정보는 IBM® LinuxONE에도 적용됩니다.
2.7.1. 사전 요구 사항
- 사용자 제공 인프라를 사용하여 IBM Z에 클러스터 설치 준비 작업을 완료했습니다.
- OpenShift Container Platform 설치 및 업데이트 프로세스에 대한 세부 정보를 검토했습니다.
- 클러스터 설치 방법을 선택하고 사용자를 위해 준비하는 방법 에 대한 설명서를 읽어보세요.
- 설치 프로세스를 시작하기 전에 설치 디렉터리를 정리해야 합니다. 이렇게 하면 설치 프로세스 중에 필요한 설치 파일이 생성되고 업데이트됩니다.
-
클러스터에 대해 OpenShift Data Foundation이나 기타 지원되는 스토리지 프로토콜을 사용하여 영구 스토리지를 프로비저닝했습니다. 프라이빗 이미지 레지스트리를 배포하려면
ReadWriteMany액세스 권한을 사용하여 영구 스토리지를 설정해야 합니다. - 방화벽을 사용하는 경우 클러스터가 액세스해야 하는 사이트를 허용하도록 구성했습니다 .
프록시를 구성하는 경우에도 해당 사이트 목록을 검토하십시오.
2.7.2. 사용자 프로비저닝 인프라 준비
사용자 프로비저닝 인프라에 OpenShift Container Platform을 설치하기 전에 기본 인프라를 준비해야 합니다.
이 섹션에서는 OpenShift Container Platform 설치를 준비하기 위해 클러스터 인프라를 설정하는 데 필요한 높은 수준의 단계에 대해 자세히 설명합니다. 여기에는 클러스터 노드에 대한 IP 네트워킹 및 네트워크 연결 구성, Ignition 파일의 웹 서버 준비, 방화벽을 통해 필요한 포트 활성화, 필수 DNS 및 로드 밸런싱 인프라 설정 등이 포함됩니다.
준비 후 클러스터 인프라는 사용자 프로비저닝 인프라가 있는 클러스터의 요구 사항 섹션에 설명된 요구 사항을 충족해야 합니다.
사전 요구 사항
- OpenShift Container Platform 4.x 테스트된 통합 페이지를 검토했습니다.
- 사용자 프로비저닝 인프라가 있는 클러스터의 요구 사항 섹션에 자세히 설명된 인프라 요구 사항을 검토했습니다.
프로세스
- 고정 IP 주소를 설정합니다.
- 클러스터 노드에 Ignition 파일을 제공하기 위해 HTTP 또는 HTTPS 서버를 설정합니다.
- 네트워크 인프라가 클러스터 구성 요소 간 필수 네트워크 연결을 제공하는지 확인합니다. 요구 사항에 대한 자세한 내용은 사용자 프로비저닝 인프라 섹션의 네트워킹 요구 사항 섹션을 참조하십시오.
OpenShift Container Platform 클러스터 구성 요소가 통신하는 데 필요한 포트를 활성화하도록 방화벽을 구성합니다. 필요한 포트에 대한 자세한 내용은 사용자 프로비저닝 인프라 섹션의 네트워킹 요구 사항 섹션을 참조하십시오.
중요기본적으로 OpenShift Container Platform 클러스터에서는 포트
1936에 액세스할 수 있습니다. 각 제어 평면 노드가 이 포트에 액세스해야 하기 때문입니다.Ingress 로드 밸런서를 사용하여 이 포트를 노출하지 마세요. 그렇게 하면 Ingress 컨트롤러와 관련된 통계 및 측정 항목과 같은 민감한 정보가 노출될 수 있습니다.
클러스터에 필요한 DNS 인프라를 설정합니다.
- Kubernetes API, 애플리케이션 와일드카드, 부트스트랩 시스템, 컨트롤 플레인 시스템 및 컴퓨팅 시스템의 DNS 이름 확인을 구성합니다.
Kubernetes API, 부트스트랩 시스템, 컨트롤 플레인 시스템 및 컴퓨팅 시스템에 대한 역방향 DNS 확인을 구성합니다.
OpenShift Container Platform DNS 요구 사항에 대한 자세한 내용은 사용자 프로비저닝 DNS 요구 사항 섹션을 참조하십시오.
DNS 구성을 확인합니다.
- 설치 노드에서 Kubernetes API의 레코드 이름, 와일드카드 경로 및 클러스터 노드에 대해 DNS 조회를 실행합니다. 응답의 IP 주소가 올바른 구성 요소에 해당하는지 확인합니다.
설치 노드에서 로드 밸런서 및 클러스터 노드의 IP 주소에 대해 역방향 DNS 조회를 실행합니다. 응답의 레코드 이름이 올바른 구성 요소에 해당하는지 확인합니다.
자세한 DNS 검증 단계는 사용자 프로비저닝 인프라에 대한 DNS 확인 섹션을 참조하십시오.
- 필요한 API 및 애플리케이션 수신 로드 밸런싱 인프라를 프로비저닝합니다. 요구 사항에 대한 자세한 내용은 사용자 프로비저닝 인프라에 대한 로드 밸런싱 요구 사항 섹션을 참조하십시오.
일부 로드 밸런싱 솔루션에는 로드 밸런싱을 초기화하기 전에 클러스터 노드의 DNS 이름을 확인해야 합니다.
2.7.3. 수동으로 설치 구성 파일 만들기
클러스터를 설치하려면 설치 구성 파일을 수동으로 만들어야 합니다.
사전 요구 사항
- 설치 프로그램에서 사용할 SSH 공개 키가 로컬 컴퓨터에 있습니다. 디버깅 및 재해 복구를 위해 클러스터 노드에 대한 SSH 인증에 이 키를 사용할 수 있습니다.
- OpenShift Container Platform 설치 프로그램과 클러스터의 풀 시크릿이 있습니다.
프로세스
필요한 설치 자산을 저장할 설치 디렉터리를 만듭니다.
mkdir <installation_directory>
$ mkdir <installation_directory>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 중요디렉터리를 만들어야 합니다. 부트스트랩 X.509 인증서와 같은 일부 설치 자산은 만료 간격이 짧으므로 설치 디렉터리를 재사용해서는 안 됩니다. 다른 클러스터 설치의 개별 파일을 재사용하려면 해당 파일을 사용자 디렉터리에 복사하면 됩니다. 그러나 설치 자산의 파일 이름은 릴리스간에 변경될 수 있습니다. 따라서 이전 OpenShift Container Platform 버전에서 설치 파일을 복사할 때는 주의하십시오.
제공된 샘플
install-config.yaml파일 템플릿을 사용자 정의하고<installation_directory>에 파일을 저장합니다.참고이 설정 파일의 이름을
install-config.yaml로 지정해야 합니다.install-config.yaml파일을 백업해 두면 여러 클러스터를 설치하는 데 사용할 수 있습니다.중요다음 단계에서 설치 프로세스가 파일을 사용하므로 지금
install-config.yaml파일을 백업하세요.
2.7.3.1. IBM Z용 샘플 install-config.yaml 파일
install-config.yaml 파일을 사용자 지정하여 OpenShift Container Platform 클러스터 플랫폼에 대한 자세한 정보를 지정하거나 필수 매개변수 값을 수정할 수 있습니다.
- 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
- Red Hat OpenShift Cluster Manager의 풀 시크릿입니다 . 이 풀 시크릿을 사용하면 OpenShift Container Platform 구성 요소에 대한 컨테이너 이미지를 제공하는 Quay.io를 포함하여 인증 기관에서 제공하는 서비스로 인증할 수 있습니다.
- 16
- Red Hat Enterprise Linux CoreOS(RHCOS)의
핵심사용자를 위한 SSH 공개 키입니다.참고설치 디버깅 또는 재해 복구를 수행하려는 프로덕션 OpenShift Container Platform 클러스터의 경우
ssh-agent프로세스가 사용하는 SSH 키를 지정합니다.
2.7.3.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파일을 편집하고 프록시 설정을 추가합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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
$ ./openshift-install wait-for install-complete --log-level debugCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 파일을 저장해 놓고 OpenShift Container Platform을 설치할 때 참조하십시오.
제공되는 install-config.yaml 파일의 프록시 설정을 사용하는 cluster라는 이름의 클러스터 전체 프록시가 설치 프로그램에 의해 생성됩니다. 프록시 설정을 제공하지 않아도 cluster Proxy 오브젝트는 계속 생성되지만 spec은 nil이 됩니다.
cluster라는 Proxy 오브젝트만 지원되며 추가 프록시는 생성할 수 없습니다.
2.7.3.3. 3개의 노드 클러스터 구성
필요한 경우 3개의 컨트롤 플레인 시스템으로 구성된 최소 3개의 노드 클러스터에 제로 컴퓨팅 머신을 배포할 수 있습니다. 이를 통해 클러스터 관리자와 개발자들이 테스트, 개발, 프로덕션에 사용할 수 있는 소형화되고 리소스 효율이 높은 클러스터를 제공합니다.
3-노드 OpenShift Container Platform 환경에서 세 개의 컨트롤 플레인 머신을 예약할 수 있습니다. 즉, 애플리케이션 워크로드가 해당 플랫폼에서 실행되도록 예약됩니다.
사전 요구 사항
-
기존
install-config.yaml파일이 있습니다.
프로세스
install-config.yaml파일에서 다음compute스탠자에 표시된 대로 컴퓨팅 복제본 수가0으로 설정되어 있는지 확인합니다.compute: - name: worker platform: {} replicas: 0compute: - name: worker platform: {} replicas: 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고배포 중인 컴퓨팅 머신 수에 관계없이 사용자 프로비저닝 인프라에 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.7.4. 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.7.4.1. CNO(Cluster Network Operator) 구성 오브젝트
CNO(Cluster Network Operator)의 필드는 다음 표에 설명되어 있습니다.
| 필드 | 유형 | 설명 |
|---|---|---|
|
|
|
CNO 개체 이름입니다. 이 이름은 항상 |
|
|
| Pod IP 주소가 할당되는 IP 주소 블록과 클러스터의 각 개별 노드에 할당된 서브넷 접두사 길이를 지정하는 목록입니다. 예를 들면 다음과 같습니다. |
|
|
| 서비스의 IP 주소 블록입니다. OVN-Kubernetes 네트워크 플러그인은 서비스 네트워크에 대해 단일 IP 주소 블록만 지원합니다. 예를 들면 다음과 같습니다. spec: serviceNetwork: - 172.30.0.0/14
매니페스트를 생성하기 전에 |
|
|
| 클러스터 네트워크에 대한 네트워크 플러그인을 구성합니다. |
|
|
| 이 개체의 필드는 kube-proxy 구성을 지정합니다. OVN-Kubernetes 클러스터 네트워크 플러그인을 사용하는 경우 kube-proxy 구성은 효과가 없습니다. |
여러 네트워크에 객체를 배포해야 하는 클러스터의 경우 install-config.yaml 파일에 정의된 각 네트워크 유형에 대해 clusterNetwork.hostPrefix 매개변수에 동일한 값을 지정해야 합니다. 각 clusterNetwork.hostPrefix 매개변수에 다른 값을 설정하면 OVN-Kubernetes 네트워크 플러그인에 영향을 미쳐 플러그인이 여러 노드 간에 개체 트래픽을 효과적으로 라우팅할 수 없습니다.
defaultNetwork 오브젝트 구성
defaultNetwork 오브젝트의 값은 다음 표에 정의되어 있습니다.
| 필드 | 유형 | 설명 |
|---|---|---|
|
|
|
참고 OpenShift Container Platform은 기본적으로 OVN-Kubernetes 네트워크 플러그인을 사용합니다. |
|
|
| 이 객체는 OVN-Kubernetes 네트워크 플러그인에만 유효합니다. |
OVN-Kubernetes 네트워크 플러그인 구성
다음 표에서는 OVN-Kubernetes 네트워크 플러그인의 구성 필드를 설명합니다.
| 필드 | 유형 | 설명 |
|---|---|---|
|
|
| Geneve(Generic Network Virtualization Encapsulation) 오버레이 네트워크의 MTU(최대 전송 단위)입니다. 이는 기본 네트워크 인터페이스의 MTU를 기준으로 자동 탐지됩니다. 일반적으로 감지된 MTU를 재정의할 필요는 없습니다. 자동 감지 값이 예상 밖인 경우 노드의 기본 네트워크 인터페이스의 MTU가 올바른지 확인합니다. 이 옵션을 사용하여 노드의 기본 네트워크 인터페이스의 MTU 값을 변경할 수 없습니다.
클러스터에 다른 노드에 대한 다른 MTU 값이 필요한 경우, 이 값을 클러스터의 가장 낮은 MTU 값보다 |
|
|
|
모든 Geneve 패킷에 사용할 포트입니다. 기본값은 |
|
|
| IPsec 구성을 사용자 정의하기 위한 구성 개체를 지정합니다. |
|
|
| IPv4 설정에 대한 구성 객체를 지정합니다. |
|
|
| IPv6 설정에 대한 구성 개체를 지정합니다. |
|
|
| 네트워크 정책 감사 로깅을 사용자 정의할 구성 오브젝트를 지정합니다. 설정되지 않으면 기본값 감사 로그 설정이 사용됩니다. |
|
|
|
선택 사항: 송신 트래픽이 노드 게이트웨이로 전송되는 방법을 사용자 정의할 구성 오브젝트를 지정합니다. 유효한 값은 참고 송신 트래픽을 마이그레이션하는 동안 클러스터 네트워크 운영자(CNO)가 변경 사항을 성공적으로 롤아웃할 때까지 작업 부하와 서비스 트래픽이 일부 중단될 것으로 예상할 수 있습니다. |
| 필드 | 유형 | 설명 |
|---|---|---|
|
| string |
기존 네트워크 인프라가
기본값은 |
|
| string |
기존 네트워크 인프라가
기본값은 |
| 필드 | 유형 | 설명 |
|---|---|---|
|
| string |
기존 네트워크 인프라가
기본값은 |
|
| string |
기존 네트워크 인프라가
기본값은 |
| 필드 | 유형 | 설명 |
|---|---|---|
|
| integer |
노드당 1초마다 생성할 최대 메시지 수입니다. 기본값은 초당 |
|
| integer |
감사 로그의 최대 크기(바이트)입니다. 기본값은 |
|
| integer | 보관되는 로그 파일의 최대 수. |
|
| string | 다음 추가 감사 로그 대상 중 하나입니다.
|
|
| string |
RFC5424에 정의된 |
| 필드 | 유형 | 설명 |
|---|---|---|
|
|
|
Pod에서 호스트 네트워킹 스택으로 송신 트래픽을 보내려면 이 필드를
이 필드는 Open vSwitch 하드웨어 오프로드 기능과 상호 작용합니다. 이 필드를 |
|
|
|
참고
기본값인 |
|
|
| 선택 사항: IPv4 주소에 대한 호스트에서 서비스로의 트래픽에 대한 내부 OVN-Kubernetes 마스커레이드 주소를 구성할 객체를 지정합니다. |
|
|
| 선택 사항: IPv6 주소에 대한 호스트에서 서비스 트래픽으로의 내부 OVN-Kubernetes 마스커레이드 주소를 구성할 객체를 지정합니다. |
| 필드 | 유형 | 설명 |
|---|---|---|
|
|
|
호스트에서 서비스로의 트래픽을 활성화하기 위해 내부적으로 사용되는 위장 IPv4 주소입니다. 호스트는 이러한 IP 주소와 공유 게이트웨이 브리지 인터페이스로 구성됩니다. 기본값은 중요
OpenShift Container Platform 4.17 이상 버전의 경우 클러스터는 기본 마스커레이드 서브넷으로 |
| 필드 | 유형 | 설명 |
|---|---|---|
|
|
|
호스트에서 서비스로의 트래픽을 활성화하기 위해 내부적으로 사용되는 위장 IPv6 주소입니다. 호스트는 이러한 IP 주소와 공유 게이트웨이 브리지 인터페이스로 구성됩니다. 기본값은 중요
OpenShift Container Platform 4.17 이상 버전의 경우 클러스터는 |
| 필드 | 유형 | 설명 |
|---|---|---|
|
|
| IPsec 구현의 동작을 지정합니다. 다음 값 중 하나여야 합니다.
|
IPSec가 활성화된 OVN-Kubernetes 구성의 예
2.7.5. 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 Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>는 사용자가 만든install-config.yaml파일이 포함된 설치 디렉터리를 지정합니다.
주의3 노드 클러스터를 실행 중이면 다음 단계를 건너 뛰어 컨트롤 플레인 노드 일정을 계획할 수 있도록 하십시오.
중요기본 예약 불가에서 예약 가능으로 컨트롤 플레인 노드를 구성하면 추가 서브스크립션이 필요합니다. 이는 제어 평면 노드가 컴퓨팅 노드가 되기 때문입니다.
<installation_directory>/manifests/cluster-scheduler-02-config.ymlKubernetes 매니페스트 파일의mastersSchedulable매개변수가false로 설정되어 있는지 확인합니다. 이 설정으로 인해 컨트롤 플레인 머신에서 포드가 예약되지 않습니다.-
<installation_directory>/manifests/cluster-scheduler-02-config.yml파일을 엽니다. -
mastersSchedulable매개변수를 찾아서 값을False로 설정되어 있는지 확인합니다. - 파일을 저장하고 종료합니다.
-
Ignition 구성 파일을 생성하려면 설치 프로그램이 포함된 디렉터리에서 다음 명령을 실행합니다.
./openshift-install create ignition-configs --dir <installation_directory>
$ ./openshift-install create ignition-configs --dir <installation_directory>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>는 동일한 설치 디렉터리를 지정합니다.
설치 디렉터리의 부트스트랩, 컨트롤 플레인 및 컴퓨팅 노드에 대한 Ignition 구성 파일이 생성됩니다.
kubeadmin-password및kubeconfig파일은./<installation_directory>/auth디렉터리에 생성됩니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7.6. IBM Z 또는 IBM LinuxONE 환경에서 부팅 볼륨 암호화 구성
IBM Z® 또는 IBM® LinuxONE에서 OpenShift Container Platform 제어 평면과 컴퓨팅 노드의 부트 볼륨을 선택적으로 암호화하기 위해 두 가지 방법 중에서 선택할 수 있습니다.
- IBM® Crypto Express(CEX)를 통한 Linux Unified Key Setup(LUKS) 암호화
- 네트워크 바운드 디스크 암호화(NBDE)
2.7.6.1. IBM Z 또는 IBM LinuxONE 환경에서 CEX를 통한 LUKS 암호화
IBM Z® 또는 IBM® LinuxONE 환경에서 IBM® Crypto Express(CEX)를 통해 하드웨어 기반 Linux Unified Key Setup(LUKS) 암호화를 활성화하려면 추가 단계가 필요합니다. 이에 대한 자세한 내용은 이 섹션에서 설명합니다.
사전 요구 사항
-
butane유틸리티가 설치되어 있습니다. - 부탄을 사용하여 기계 구성을 만드는 방법에 대한 지침을 검토했습니다.
프로세스
컨트롤 플레인 및 컴퓨팅 노드에 대한 Butane 구성 파일을 생성하는 적절한 방법을 선택합니다.
DASD 유형 디스크에 설치하는 경우 디스크 암호화가 있는 제어 평면 노드에 대한 다음 Butane 구성을 사용하여
main-storage.bu라는 이름의 파일을 만듭니다. 예:Copy to Clipboard Copied! Toggle word wrap Toggle overflow FCP 유형 디스크에 설치하는 경우 디스크 암호화가 있는 제어 평면 노드에 대한 다음 Butane 구성을 사용하여
main-storage.bu라는 이름의 파일을 만듭니다. 예:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ignition.platform.id=metal및ignition.firstboot를포함하는 매개변수 파일을 만듭니다.제어 평면 머신에 대한 커널 매개변수 파일 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 디스크 유형에 따라 고유한 완전한 경로를 지정합니다. DASD 유형 또는 FCP 유형 디스크가 될 수 있습니다.
- 2
- Ignition 구성 파일의 위치를 지정합니다.
master.ign또는worker.ign을사용하세요. HTTP 및 HTTPS 프로토콜만 사용할 수 있습니다. - 3
- 부팅하려는
커널과initramfs에 대한rootfs아티팩트의 위치를 지정합니다. HTTP 및 HTTPS 프로토콜만 사용할 수 있습니다. - 4
- 루트 장치를 지정합니다. DASD 유형 디스크에 설치하는 경우 DASD 장치를 지정하려면
rd.dasd=0.0.xxxx로 바꾸세요.
참고매개 변수 파일의 모든 옵션을 한 줄로 작성하고 줄 바꿈 문자가 없는지 확인합니다.
2.7.6.2. IBM Z 또는 IBM LinuxONE 환경에서 정적 IP로 NBDE 구성
IBM Z® 또는 IBM® LinuxONE 환경에서 NBDE 디스크 암호화를 활성화하려면 추가 단계가 필요합니다. 이에 대한 자세한 내용은 이 섹션에서 설명합니다.
사전 요구 사항
- 외부 Tang 서버를 설정했습니다. 자세한 내용은 네트워크 바운드 디스크 암호화를 참조하세요.
-
butane유틸리티가 설치되어 있습니다. - 부탄을 사용하여 기계 구성을 만드는 방법에 대한 지침을 검토했습니다.
프로세스
제어 평면과 컴퓨팅 노드에 대한 Butane 구성 파일을 만듭니다.
다음은 제어 평면 노드에 대한 Butane 구성의 예이며, 디스크 암호화를 위해
master-storage.bu라는 이름의 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 컴퓨터를 부팅하기 위한 사용자 지정 initramfs 파일을 만듭니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고처음 부팅하기 전에 클러스터의 각 노드에 대한 initramfs를 사용자 정의하고 PXE 커널 매개변수를 추가해야 합니다.
ignition.platform.id=metal및ignition.firstboot를포함하는 매개변수 파일을 만듭니다.제어 평면 머신에 대한 커널 매개변수 파일 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 블록 장치 유형을 지정합니다. DASD 유형 디스크에 설치하는 경우
/dev/dasda를지정합니다. FCP 유형 디스크에 설치하는 경우/dev/sda를지정합니다. NVMe 유형 디스크에 설치하는 경우/dev/nvme0n1을지정합니다. - 2
- Ignition 구성 파일의 위치를 지정합니다.
master.ign또는worker.ign을사용하세요. HTTP 및 HTTPS 프로토콜만 지원됩니다. - 3
- 부팅하는
커널과initramfs에 대한rootfs아티팩트의 위치를 지정합니다. HTTP 및 HTTPS 프로토콜만 지원됩니다. - 4
- DASD 유형 디스크에 설치하는 경우 DASD 장치를 지정하려면
rd.dasd=0.0.xxxx로 바꾸세요.
참고매개 변수 파일의 모든 옵션을 한 줄로 작성하고 줄 바꿈 문자가 없는지 확인합니다.
2.7.7. RHCOS 설치 및 OpenShift Container Platform 부트스트랩 프로세스 시작
프로비저닝하는 IBM Z® 인프라에 OpenShift Container Platform을 설치하려면 LPAR에 Red Hat Enterprise Linux CoreOS(RHCOS)를 설치해야 합니다. RHCOS를 설치할 때 설치 중인 머신 유형에 대해 OpenShift Container Platform 설치 프로그램에서 생성한 Ignition 구성 파일을 제공해야 합니다. 적절한 네트워킹, DNS 및 부하 분산 인프라를 구성한 경우 RHCOS 게스트 머신이 재부팅된 후 OpenShift Container Platform 부트스트랩 프로세스가 자동으로 시작됩니다.
머신을 생성하려면 다음 단계를 완료하십시오.
사전 요구 사항
- 생성한 머신에 액세스할 수 있는 프로비저닝 머신에서 실행 중인 HTTP 또는 HTTPS 서버.
- 보안 부팅을 활성화하려면 해당 Red Hat 제품 서명 키를 확보하고 IBM 문서에서 IBM Z 및 IBM LinuxONE의 보안 부팅을 읽어야 합니다.
프로세스
- 프로비저닝 머신에서 Linux에 로그인합니다.
RHCOS 이미지 미러 에서 Red Hat Enterprise Linux CoreOS(RHCOS) 커널, initramfs 및 rootfs 파일을 가져옵니다.
중요RHCOS 이미지는 OpenShift Container Platform 릴리스에 따라 변경되지 않을 수 있습니다. 설치하는 OpenShift Container Platform 버전과 같거나 그 이하의 버전 중 가장 최신 버전의 이미지를 다운로드해야 합니다. 이 프로세스에는 아래 설명된 적절한 kernel, initramfs 및 rootfs 아티팩트만 사용하십시오.
OpenShift Container Platform 버전 번호가 파일 이름에 포함됩니다. 다음 예와 유사합니다.
-
kernel:
rhcos-<version>-live-kernel-<architecture> -
initramfs:
rhcos-<version>-live-initramfs.<architecture>.img rootfs:
rhcos-<version>-live-rootfs.<architecture>.img참고rootfs 이미지는 FCP 및 DASD에 대해 동일합니다.
-
kernel:
매개 변수 파일을 생성합니다. 다음 매개 변수는 특정 가상 머신에 지정해야 합니다.
ip=에 다음 7 개의 항목을 지정하십시오.- 컴퓨터의 IP 주소
- 빈 문자열
- 게이트웨이
- 넷 마스크
-
hostname.domainname형식의 시스템 호스트 및 도메인 이름. 이 값을 생략하면 RHCOS는 역방향 DNS 조회를 통해 호스트 이름을 얻습니다. - 네트워크 인터페이스 이름. 이 값을 생략하면 RHCOS는 사용 가능한 모든 인터페이스에 IP 구성을 적용합니다.
-
고정 IP 주소를 사용하는 경우
none을 지정합니다.
-
coreos.inst.ignition_url=의 경우 시스템 역할의 Ignition 파일을 지정합니다.bootstrap.ign,master.ign또는worker.ign을 사용하십시오. HTTP 및 HTTPS 프로토콜만 지원됩니다. -
coreos.live.rootfs_url=의 경우 부팅 중인 커널 및 initramfs와 일치하는 rootfs 아티팩트를 지정합니다. HTTP 및 HTTPS 프로토콜만 지원됩니다. -
선택 사항: 보안 부팅을 활성화하려면
coreos.inst.secure_ipl을추가하세요. DASD 유형 디스크에 설치하려면 다음 작업을 완료합니다.
-
For
coreos.inst.install_dev=, specify/dev/disk/by-path/ccw-<device_id>. <device_id>의 경우 (예:0.0.1000)를 지정합니다. -
rd.dasd=의 경우 RHCOS를 설치할 DASD를 지정합니다. 변경되지 않은 다른 모든 매개변수는 그대로 두십시오.
부트스트랩 시스템의 매개 변수 파일 예
bootstrap-0.parmCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 디스크 유형에 따라 고유한 완전한 경로를 지정합니다. 이는 DASD 유형, FCP 유형 또는 NVMe 유형 디스크일 수 있습니다.
- 2
- Ignition 구성 파일의 위치를 지정합니다.
bootstrap.ign,master.ign또는worker.ign을 사용하십시오. HTTP 및 HTTPS 프로토콜만 지원됩니다. - 3
- 부팅하는
커널과initramfs에 대한rootfs아티팩트의 위치를 지정합니다. HTTP 및 HTTPS 프로토콜만 지원됩니다. - 4
- 선택 사항: 보안 부팅을 활성화하려면
coreos.inst.secure_ipl을추가합니다.
매개 변수 파일의 모든 옵션을 한 줄로 작성하고 줄 바꿈 문자가 없는지 확인합니다.
-
For
FCP 유형 디스크에 설치하려면 다음 작업을 완료합니다.
RHCOS를 설치할 FCP 디스크를 지정하려면
rd.zfcp=<adapter>,<wwpn>,<lun>을 사용합니다. 멀티패스의 경우 추가 경로마다 이 단계를 반복합니다.참고여러 경로를 사용하여 설치할 때 나중에 문제가 발생할 수 있으므로 설치 후에 직접 멀티패스를 활성화해야 합니다.
-
설치 장치를
coreos.inst.install_dev=/dev/disk/by-id/scsi-<serial_number>로 설정합니다.
선택 사항:
generic.ins파일을 만듭니다.일부 설치 방법에는 하드웨어 관리 콘솔(HMC), DVD 또는 FTP 서버의 파일 시스템에서 설치 데이터의 위치와 데이터를 복사할 메모리 위치를 매핑한
generic.ins파일도 필요합니다. RHEL 설치 미디어에는 샘플generic.ins파일이 제공됩니다. 이 파일에는 초기 RAM 디스크(initrd.img), 커널 이미지(kernel.img), 매개변수(generic.prm) 파일의 파일 이름과 각 파일의 메모리 위치가 포함되어 있습니다.generic.ins파일 예images/kernel.img 0x00000000 images/initrd.img 0x02000000 images/genericdvd.prm 0x00010480 images/initrd.addrsize 0x00010408
images/kernel.img 0x00000000 images/initrd.img 0x02000000 images/genericdvd.prm 0x00010480 images/initrd.addrsize 0x00010408Copy to Clipboard Copied! Toggle word wrap Toggle overflow 변경되지 않은 다른 모든 매개변수는 그대로 두십시오.
중요다중 경로를 완벽하게 활성화하려면 추가적인 설치 후 단계가 필요합니다. 자세한 내용은 머신 구성 의 "RHCOS에서 커널 인수를 사용하여 다중 경로 활성화"를 참조하세요.
다음은 다중 경로를 사용하는 컴퓨팅 노드에 대한 예시 매개변수 파일
worker-1.parm입니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 매개 변수 파일의 모든 옵션을 한 줄로 작성하고 줄 바꿈 문자가 없는지 확인합니다.
- 예를 들어 FTP를 사용하여 initramfs, 커널, 매개변수 파일 및 RHCOS 이미지를 LPAR로 전송합니다. FTP를 사용하여 파일을 전송하고 부팅하는 방법에 대한 자세한 내용은 LPAR에 RHEL을 설치하기 위해 IBM Z®에서 설치 부팅을 참조하세요.
- 기계를 부팅하세요
- 클러스터의 다른 컴퓨터에 대해 이 프로세스를 반복합니다.
2.7.7.1. 고급 RHCOS 설치 참조
이 섹션에서는 Red Hat Enterprise Linux CoreOS(RHCOS) 수동 설치 프로세스를 수정할 수 있는 네트워크 구성 및 기타 고급 옵션을 설명합니다. 다음 표에서는 RHCOS 라이브 설치 프로그램 및 coreos-installer 명령과 함께 사용할 수있는 커널 인수 및 명령 줄 옵션에 대해 설명합니다.
2.7.7.1.1. ISO 설치를 위한 네트워킹 및 본딩 옵션
ISO 이미지에서 RHCOS를 설치하는 경우, 해당 이미지를 부팅할 때 수동으로 커널 인수를 추가하여 노드의 네트워킹을 구성할 수 있습니다. 네트워킹 인수를 지정하지 않으면 RHCOS에서 Ignition 구성 파일을 가져오는 데 네트워킹이 필요함을 감지하면 initramfs에서 DHCP가 활성화됩니다.
네트워킹 인수를 수동으로 추가할 때 initramfs에서 네트워크를 가져오려면 rd.neednet=1 커널 인수도 추가해야 합니다.
다음 정보는 ISO 설치를 위해 RHCOS 노드에서 네트워킹과 본딩을 구성하는 방법에 대한 예를 제공합니다. 예제에서는 ip=, nameserver=, bond= 커널 인수를 사용하는 방법을 설명합니다.
커널 인수를 추가할 때 순서가 중요합니다: ip=, nameserver= 및 bond= 입니다.
이는 시스템 부팅 중에 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.41DHCP를 사용하여 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여러 네트워크 인터페이스 지정
여러 개의 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기본 게이트웨이 및 경로 구성
선택 사항: rd.route= 값을 설정하여 추가 네트워크에 대한 경로를 구성할 수 있습니다.
하나 이상의 네트워크를 구성할 때 하나의 기본 게이트웨이가 필요합니다. 추가 네트워크 게이트웨이가 기본 네트워크 게이트웨이와 다른 경우 기본 게이트웨이가 기본 네트워크 게이트웨이어야 합니다.
다음 명령을 실행하여 기본 게이트웨이를 구성합니다.
ip=::10.10.10.254::::
ip=::10.10.10.254::::Copy to Clipboard Copied! Toggle word wrap Toggle overflow 추가 네트워크에 대한 경로를 구성하려면 다음 명령을 입력하세요.
rd.route=20.20.20.0/24:20.20.20.254:enp2s0
rd.route=20.20.20.0/24:20.20.20.254:enp2s0Copy to Clipboard Copied! Toggle word wrap Toggle overflow
단일 인터페이스에서 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:noneDHCP와 정적 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개별 인터페이스에서 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:enp2s0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 네트워크 인터페이스에서 VLAN을 구성하고 DHCP를 사용하려면 다음 명령을 실행하세요.
ip=enp2s0.100:dhcp vlan=enp2s0.100:enp2s0
ip=enp2s0.100:dhcp vlan=enp2s0.100:enp2s0Copy to Clipboard Copied! Toggle word wrap Toggle overflow
여러 DNS 서버 제공
각 서버에 nameserver= 항목을 추가하여 여러 DNS 서버를 제공할 수 있습니다. 예:
nameserver=1.1.1.1 nameserver=8.8.8.8
nameserver=1.1.1.1
nameserver=8.8.8.8여러 네트워크 인터페이스를 단일 인터페이스에 결합
선택 사항: bond= 옵션을 사용하여 여러 네트워크 인터페이스를 단일 인터페이스에 결합할 수 있습니다. 다음 예를 참조하세요.
본딩된 인터페이스를 구성하기 위한 구문은 다음과 같습니다.
bond=<name>[:<network_interfaces>][:options]<name>은 본딩 장치 이름(bond0)이고,<network_interfaces>는물리적(이더넷) 인터페이스(em1,em2)의 쉼표로 구분된 목록을 나타내며, options는 본딩 옵션의 쉼표로 구분된 목록입니다. 사용 가능한 옵션을 보려면modinfo bonding을 입력하십시오.bond=를 사용하여 결합된 인터페이스를 생성할 때 IP 주소가 할당되는 방법과 결합된 인터페이스에 대한 기타 정보를 지정해야 합니다.DHCP를 사용하도록 결합된 인터페이스를 구성하려면 bond의 IP 주소를
dhcp로 설정하십시오. 예를 들면 다음과 같습니다.bond=bond0:em1,em2:mode=active-backup ip=bond0:dhcp
bond=bond0:em1,em2:mode=active-backup ip=bond0:dhcpCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 고정 IP 주소를 사용하도록 결합된 인터페이스를 구성하려면 원하는 특정 IP 주소 및 관련 정보를 입력합니다. 예를 들면 다음과 같습니다.
bond=bond0:em1,em2:mode=active-backup,fail_over_mac=1 ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0:none
bond=bond0:em1,em2:mode=active-backup,fail_over_mac=1
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0:none
공유 OSA/RoCE 카드를 사용할 때 문제가 발생하지 않도록 활성 백업 모드에서 항상 fail_over_mac=1 옵션을 설정합니다.
여러 네트워크 인터페이스를 단일 인터페이스에 결합
선택 사항: vlan= 매개변수를 사용하여 본딩된 인터페이스에서 VLAN을 구성하고 DHCP를 사용할 수 있습니다(예:
ip=bond0.100:dhcp bond=bond0:em1,em2:mode=active-backup vlan=bond0.100:bond0
ip=bond0.100:dhcp
bond=bond0:em1,em2:mode=active-backup
vlan=bond0.100:bond0다음 예를 사용하여 VLAN으로 본딩된 인터페이스를 구성하고 고정 IP 주소를 사용하세요.
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0.100:none bond=bond0:em1,em2:mode=active-backup vlan=bond0.100:bond0
ip=10.10.10.2::10.10.10.254:255.255.255.0:core0.example.com:bond0.100:none
bond=bond0:em1,em2:mode=active-backup
vlan=bond0.100:bond0네트워크 팀 사용
선택 사항: team= 매개변수를 사용하여 본딩 대신 네트워크 팀을 사용할 수 있습니다.
팀 인터페이스를 구성하는 구문은
team=name[:network_interfaces]입니다.name은 팀 장치 이름(
team0)이고 network_interfaces는 쉼표로 구분된 실제 인터페이스(ethernet) 인터페이스(em1, em2) 목록을 나타냅니다.
팀 구성은 RHCOS가 향후 RHEL 버전으로 전환하면 더 이상 사용되지 않을 예정입니다. 자세한 내용은 Red Hat Knowledgebase 문서를 참조하십시오.
다음 예제를 사용하여 네트워크 팀을 구성합니다.
team=team0:em1,em2 ip=team0:dhcp
team=team0:em1,em2
ip=team0:dhcp2.7.8. 부트스트랩 프로세스가 완료될 때까지 대기 중
OpenShift Container Platform 부트스트랩 프로세스는 클러스터 노드가 먼저 디스크에 설치된 영구 RHCOS 환경으로 부팅된 후에 시작됩니다. Ignition 구성 파일을 통해 제공되는 구성 정보는 부트스트랩 프로세스를 초기화하고 머신에 OpenShift Container Platform을 설치하는 데 사용됩니다. 부트스트랩 프로세스가 완료될 때까지 기다려야 합니다.
사전 요구 사항
- 클러스터에 대한 Ignition 구성 파일이 생성되어 있습니다.
- 적합한 네트워크, DNS 및 로드 밸런싱 인프라가 구성되어 있습니다.
- 설치 프로그램을 받아서 클러스터의 Ignition 구성 파일을 생성했습니다.
- 클러스터 머신에 RHCOS를 설치하고 OpenShift Container Platform 설치 프로그램에서 생성된 Ignition 구성 파일을 제공했습니다.
- 사용자 시스템에서 직접 인터넷에 액세스하거나 HTTP 또는 HTTPS 프록시를 사용할 수 있습니다.
프로세스
부트스트랩 프로세스를 모니터링합니다.
./openshift-install --dir <installation_directory> wait-for bootstrap-complete \ --log-level=info$ ./openshift-install --dir <installation_directory> wait-for bootstrap-complete \1 --log-level=info2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
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 resourcesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이 명령은 Kubernetes API 서버가 컨트롤 플레인 시스템에서 부트스트랩되었다는 신호를 보낼 때 성공합니다.
부트스트랩 프로세스가 완료되면 로드 밸런서에서 부트스트랩 머신을 제거합니다.
중요이 시점에 로드 밸런서에서 부트스트랩 시스템을 제거해야 합니다. 부트스트랩 머신 자체를 제거하거나 다시 포맷할 수도 있습니다.
2.7.9. CLI를 사용하여 클러스터에 로그인
클러스터 kubeconfig 파일을 내보내서 기본 시스템 사용자로 클러스터에 로그인할 수 있습니다. kubeconfig 파일에는 CLI에서 올바른 클러스터 및 API 서버에 클라이언트를 연결하는 데 사용하는 클러스터에 대한 정보가 포함되어 있습니다. 이 파일은 클러스터별로 고유하며 OpenShift Container Platform 설치 과정에서 생성됩니다.
사전 요구 사항
- OpenShift Container Platform 클러스터를 배포했습니다.
-
ocCLI를 설치했습니다.
프로세스
kubeadmin인증 정보를 내보냅니다.export KUBECONFIG=<installation_directory>/auth/kubeconfig
$ export KUBECONFIG=<installation_directory>/auth/kubeconfig1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<installation_directory>는 설치 파일을 저장한 디렉터리의 경로를 지정합니다.
내보낸 구성을 사용하여
oc명령을 성공적으로 실행할 수 있는지 확인합니다.oc whoami
$ oc whoamiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
system:admin
system:adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7.10. 머신의 인증서 서명 요청 승인
클러스터에 시스템을 추가하면 추가한 시스템별로 보류 중인 인증서 서명 요청(CSR)이 두 개씩 생성됩니다. 이러한 CSR이 승인되었는지 확인해야 하며, 필요한 경우 이를 직접 승인해야 합니다. 클라이언트 요청을 먼저 승인한 다음 서버 요청을 승인해야 합니다.
사전 요구 사항
- 클러스터에 시스템을 추가했습니다.
프로세스
클러스터가 시스템을 인식하는지 확인합니다.
oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
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.3Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력에 생성된 모든 시스템이 나열됩니다.
참고이전 출력에는 일부 CSR이 승인될 때까지 컴퓨팅 노드(작업자 노드라고도 함)가 포함되지 않을 수 있습니다.
보류 중인 CSR을 검토하고 클러스터에 추가한 각 시스템에 대해
Pending또는Approved상태의 클라이언트 및 서버 요청이 표시되는지 확인합니다.oc get csr
$ oc get csrCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME AGE REQUESTOR CONDITION csr-mddf5 20m system:node:master-01.example.com Approved,Issued csr-z5rln 16m system:node:worker-21.example.com Approved,Issued
NAME AGE REQUESTOR CONDITION csr-mddf5 20m system:node:master-01.example.com Approved,Issued csr-z5rln 16m system:node:worker-21.example.com Approved,IssuedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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>
$ oc adm certificate approve <csr_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs --no-run-if-empty oc adm certificate approveCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고일부 Operator는 일부 CSR이 승인될 때까지 사용할 수 없습니다.
이제 클라이언트 요청이 승인되었으므로 클러스터에 추가한 각 머신의 서버 요청을 검토해야 합니다.
oc get csr
$ oc get csrCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
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 Copied! Toggle word wrap Toggle overflow 나머지 CSR이 승인되지 않고
Pending상태인 경우 클러스터 머신의 CSR을 승인합니다.개별적으로 승인하려면 유효한 CSR 각각에 대해 다음 명령을 실행하십시오.
oc adm certificate approve <csr_name>
$ oc adm certificate approve <csr_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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$ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approveCopy to Clipboard Copied! Toggle word wrap Toggle overflow
모든 클라이언트 및 서버 CSR이 승인된 후 머신은
Ready상태가 됩니다. 다음 명령을 실행하여 확인합니다.oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고머신이
Ready상태로 전환하는 데 서버 CSR의 승인 후 몇 분이 걸릴 수 있습니다.
추가 정보
2.7.11. Operator의 초기 설정
컨트롤 플레인이 초기화된 후 일부 Operator를 즉시 구성하여 모두 사용 가능하도록 해야 합니다.
사전 요구 사항
- 컨트롤 플레인이 초기화되어 있습니다.
프로세스
클러스터 구성 요소가 온라인 상태인지 확인합니다.
watch -n5 oc get clusteroperators
$ watch -n5 oc get clusteroperatorsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 사용할 수 없는 Operator를 구성합니다.
2.7.11.1. 이미지 레지스트리 스토리지 구성
기본 스토리지를 제공하지 않는 플랫폼에서는 처음에 Image Registry Operator를 사용할 수 없습니다. 설치한 후에 스토리지를 사용하도록 레지스트리를 구성하여 Registry Operator를 사용 가능하도록 만들어야 합니다.
프로덕션 클러스터에 필요한 영구 볼륨을 구성하는 과정의 지침이 표시됩니다. 해당하는 경우, 프로덕션 환경 외 클러스터에서만 사용할 수 있는 저장 위치로서 빈 디렉터리를 구성하는 과정의 지침이 표시됩니다.
업그레이드 중에 Recreate 롤아웃 전략을 사용하여 이미지 레지스트리의 블록 스토리지 유형 사용을 허용하기 위한 추가 지침이 제공됩니다.
2.7.11.1.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=defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
No resources found in openshift-image-registry namespace
No resources found in openshift-image-registry namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고출력에 레지스트리 Pod가 있는 경우 이 절차를 계속할 필요가 없습니다.
레지스트리 구성을 확인합니다.
oc edit configs.imageregistry.operator.openshift.io
$ oc edit configs.imageregistry.operator.openshift.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
storage: pvc: claim:storage: pvc: claim:Copy to Clipboard Copied! Toggle word wrap Toggle overflow image-registry-storagePVC의 자동 생성을 허용하도록claim필드를 비워 둡니다.clusteroperator상태를 확인합니다.oc get clusteroperator image-registry
$ oc get clusteroperator image-registryCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
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 6h50mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이미지를 빌드 및 푸시할 수 있도록 레지스트리의 관리가 설정되어 있는지 확인하십시오.
다음을 실행합니다.
oc edit configs.imageregistry/cluster
$ oc edit configs.imageregistry/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음으로 라인을 변경하십시오.
managementState: Removed
managementState: RemovedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음으로 변경
managementState: Managed
managementState: ManagedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.7.11.1.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 Copied! Toggle word wrap Toggle overflow 주의프로덕션 환경 외 클러스터에 대해서만 이 옵션을 구성하십시오.
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 foundCopy to Clipboard Copied! Toggle word wrap Toggle overflow 몇 분 후에 명령을 다시 실행하십시오.
2.7.12. 사용자 프로비저닝 인프라에 설치 완료
Operator 구성을 완료한 후 제공하는 인프라에 클러스터 설치를 완료할 수 있습니다.
사전 요구 사항
- 컨트롤 플레인이 초기화되어 있습니다.
- 초기 Operator 구성을 완료해야 합니다.
프로세스
다음 명령을 사용하여 모든 클러스터 구성 요소가 온라인 상태인지 확인합니다.
watch -n5 oc get clusteroperators
$ watch -n5 oc get clusteroperatorsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 또는 다음 명령은 모든 클러스터를 사용할 수 있을 때 알립니다. 또한 인증 정보를 검색하고 표시합니다.
./openshift-install --dir <installation_directory> wait-for install-complete
$ ./openshift-install --dir <installation_directory> wait-for install-complete1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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 Copied! Toggle word wrap Toggle overflow 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-namespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 사용하여 이전 명령의 출력에 나열된 Pod의 로그를 표시합니다.
oc logs <pod_name> -n <namespace>
$ oc logs <pod_name> -n <namespace>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 이전 명령의 출력에 표시된 대로 Pod 이름과 네임스페이스를 지정합니다.
Pod 로그가 표시되면 Kubernetes API 서버는 클러스터 시스템과 통신할 수 있습니다.
FCP(Fibre Channel Protocol)를 사용하는 설치에는 다중 경로를 활성화하기 위해 추가 단계가 필요합니다. 설치 중에 멀티패스를 활성화하지 마십시오.
자세한 내용은 설치 후 머신 구성 작업 설명서의 "RHCOS에서 커널 인수를 사용하여 다중 경로 활성화"를 참조하세요.
검증
OpenShift Container Platform 부트스트랩 프로세스 중에 보안 부팅을 활성화한 경우 다음 확인 단계가 필요합니다.
다음 명령을 실행하여 노드를 디버깅합니다.
oc debug node/<node_name>
$ oc debug node/<node_name> chroot /hostCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 보안 부팅이 활성화되었는지 확인하세요.
cat /sys/firmware/ipl/secure
$ cat /sys/firmware/ipl/secureCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
1
11 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 보안 부팅이 활성화되어 있으면 값은
1이고, 보안 부팅이 활성화되어 있지 않으면 값은0입니다.
다음 명령을 실행하여 IPL 재구성을 나열하세요.
lsreipl
# lsreiplCopy to Clipboard Copied! Toggle word wrap Toggle overflow FCP 디스크에 대한 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow DASD 디스크에 대한 출력 예
for DASD output: Re-IPL type: ccw Device: 0.0.525d Loadparm: "" clear: 0
for DASD output: Re-IPL type: ccw Device: 0.0.525d Loadparm: "" clear: 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 노드를 종료합니다.
sudo shutdown -h
sudo shutdown -hCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 하드웨어 관리 콘솔(HMC)에서 LPAR 부팅을 시작합니다. IBM 문서에서 LPAR에서 보안 부팅을 시작하는 방법을 참조하세요.
- 노드가 돌아오면 보안 부팅 상태를 다시 확인하세요.
2.7.13. OpenShift Container Platform의 Telemetry 액세스
OpenShift Container Platform 4.19에서는 클러스터 상태와 업데이트 성공에 대한 측정 항목을 제공하기 위해 기본적으로 실행되는 Telemetry 서비스에 인터넷 액세스가 필요합니다. 클러스터가 인터넷에 연결되어 있으면 Telemetry가 자동으로 실행되고 OpenShift Cluster Manager에 클러스터가 자동으로 등록됩니다.
OpenShift Cluster Manager 인벤토리가 올바르거나 OpenShift Cluster Manager를 사용하여 자동으로 또는 OpenShift Cluster Manager를 사용하여 수동으로 유지 관리되는지 확인한 후 subscription watch를 사용하여 계정 또는 다중 클러스터 수준에서 OpenShift Container Platform 서브스크립션을 추적합니다.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}