4.7. RHEL KVM을 사용하여 IBM Z 및 IBM LinuxONE에서 다중 아키텍처 컴퓨팅 머신으로 클러스터 생성
RHEL KVM을 사용하여 IBM Z® 및 IBM® LinuxONE(s390x
)에서 다중 아키텍처 컴퓨팅 머신이 있는 클러스터를 생성하려면 기존 단일 아키텍처 x86_64
클러스터가 있어야 합니다. 그런 다음 s390x
컴퓨팅 머신을 OpenShift Container Platform 클러스터에 추가할 수 있습니다.
s390x
노드를 클러스터에 추가하려면 먼저 다중 아키텍처 페이로드를 사용하는 클러스터로 클러스터를 업그레이드해야 합니다. 다중 아키텍처 페이로드로 마이그레이션하는 방법에 대한 자세한 내용은 다중 아키텍처 컴퓨팅 머신이 있는 클러스터로 마이그레이션 을 참조하십시오.
다음 절차에서는 RHEL KVM 인스턴스를 사용하여 RHCOS 컴퓨팅 머신을 생성하는 방법을 설명합니다. 이를 통해 클러스터에 s390x
노드를 추가하고 다중 아키텍처 컴퓨팅 머신이 있는 클러스터를 배포할 수 있습니다.
4.7.1. 클러스터 호환성 확인
다른 아키텍처의 컴퓨팅 노드를 클러스터에 추가하려면 먼저 클러스터가 다중 아키텍처 호환인지 확인해야 합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있어야 합니다.
프로세스
다음 명령을 실행하여 클러스터에서 아키텍처 페이로드를 사용하는지 확인할 수 있습니다.
$ oc adm release info -o jsonpath="{ .metadata.metadata}"
검증
다음 출력이 표시되면 클러스터에서 다중 아키텍처 페이로드를 사용하는 것입니다.
{ "release.openshift.io/architecture": "multi", "url": "https://access.redhat.com/errata/<errata_version>" }
그런 다음 클러스터에 다중 아키텍처 컴퓨팅 노드 추가를 시작할 수 있습니다.
다음 출력이 표시되면 클러스터에서 다중 아키텍처 페이로드를 사용하지 않습니다.
{ "url": "https://access.redhat.com/errata/<errata_version>" }
중요클러스터가 다중 아키텍처 컴퓨팅 머신을 지원하도록 클러스터를 마이그레이션하려면 다중 아키텍처 컴퓨팅 머신이 있는 클러스터로 마이그레이션 절차를 따르십시오.
4.7.2. virt-install
을 사용하여 RHCOS 머신 생성
virt-install
을 사용하여 클러스터에 대해 더 많은 RHCOS(Red Hat Enterprise Linux CoreOS) 컴퓨팅 머신을 생성할 수 있습니다.
사전 요구 사항
- 이 절차에서 RHEL KVM 호스트라고 하는 KVM을 사용하여 RHEL 8.7 이상에서 하나 이상의 LPAR이 실행됩니다.
- RHEL KVM 호스트에 KVM/QEMU 하이퍼바이저가 설치되어 있어야 합니다.
- 노드의 호스트 이름 및 역방향 조회를 수행할 수 있는 DNS(Domain Name Server)가 있습니다.
- HTTP 또는 HTTPS 서버가 설정됩니다.
프로세스
UDP 집계를 비활성화합니다.
현재 UDP 집계는 IBM Z®에서 지원되지 않으며
x86_64
컨트롤 플레인 및 추가s390x
컴퓨팅 머신이 있는 다중 아키텍처 컴퓨팅 클러스터에서 자동으로 비활성화되지 않습니다. 추가 컴퓨팅 노드가 클러스터에 올바르게 추가되도록 하려면 UDP 집계를 수동으로 비활성화해야 합니다.다음 콘텐츠를 사용하여 YAML 파일
udp-aggregation-config.yaml
을 생성합니다.apiVersion: v1 kind: ConfigMap data: disable-udp-aggregation: "true" metadata: name: udp-aggregation-config namespace: openshift-network-operator
다음 명령을 실행하여 ConfigMap 리소스를 생성합니다.
$ oc create -f udp-aggregation-config.yaml
다음 명령을 실행하여 클러스터에서 Ignition 구성 파일을 추출합니다.
$ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign
-
클러스터에서 내보낸
worker.ign
Ignition 구성 파일을 HTTP 서버로 업로드합니다. 이 파일의 URL을 기록해 둡니다. Ignition 파일이 URL에서 사용 가능한지 확인할 수 있습니다. 다음 예제에서는 컴퓨팅 노드에 대한 Ignition 구성 파일을 가져옵니다.
$ curl -k http://<HTTP_server>/worker.ign
다음 명령을 실행하여 RHEL 라이브
커널
,initramfs
,rootfs
파일을 다운로드합니다.$ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \ | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.kernel.location')
$ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \ | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.initramfs.location')
$ curl -LO $(oc -n openshift-machine-config-operator get configmap/coreos-bootimages -o jsonpath='{.data.stream}' \ | jq -r '.architectures.s390x.artifacts.metal.formats.pxe.rootfs.location')
-
virt-install
을 시작하기 전에 다운로드한 RHEL 라이브커널
,initramfs
및rootfs
파일을 HTTP 또는 HTTPS 서버로 이동합니다. RHEL
커널
,initramfs
및 Ignition 파일, 새 디스크 이미지, 조정된 parm 줄 인수를 사용하여 새 KVM 게스트 노드를 만듭니다.$ virt-install \ --connect qemu:///system \ --name {vm_name} \ --autostart \ --os-variant rhel9.2 \ 1 --cpu host \ --vcpus {vcpus} \ --memory {memory_mb} \ --disk {vm_name}.qcow2,size={image_size | default(100,true)} \ --network network={virt_network_parm} \ --location {media_location},kernel={rhcos_kernel},initrd={rhcos_initrd} \ 2 --extra-args "rd.neednet=1" \ --extra-args "coreos.inst.install_dev=/dev/vda" \ --extra-args "coreos.inst.ignition_url={worker_ign}" \ 3 --extra-args "coreos.live.rootfs_url={rhcos_rootfs}" \ 4 --extra-args "ip={ip}::{default_gateway}:{subnet_mask_length}:{vm_name}::none:{MTU}" \ --extra-args "nameserver={dns}" \ --extra-args "console=ttysclp0" \ --noautoconsole \ --wait
- 1
os-variant
의 경우 RHCOS 컴퓨팅 머신의 RHEL 버전을 지정합니다.rhel9.2
는 권장 버전입니다. 지원되는 RHEL 버전의 운영 체제를 쿼리하려면 다음 명령을 실행합니다.$ osinfo-query os -f short-id
참고os-variant
은 대소문자를 구분합니다.- 2
--location
에 대해 HTTP 또는 HTTPS 서버의 kernel/initrd 위치를 지정합니다.- 3
coreos.inst.ignition_url=
의 경우 머신 역할의worker.ign
Ignition 파일을 지정합니다. HTTP 및 HTTPS 프로토콜만 지원됩니다.- 4
coreos.live.rootfs_url=
의 경우 부팅 중인커널
및initramfs
와 일치하는 rootfs 아티팩트를 지정합니다. HTTP 및 HTTPS 프로토콜만 지원됩니다.
참고HAProxy를 로드 밸런서로 사용하는 경우
/etc/haproxy/haproxy.cfg
구성 파일에서ingress-router-443
및ingress-router-80
에 대한 HAProxy 규칙을 업데이트합니다.- 계속해서 클러스터에 추가 컴퓨팅 머신을 만듭니다.
4.7.3. 시스템의 인증서 서명 요청 승인
클러스터에 시스템을 추가하면 추가한 시스템별로 보류 중인 인증서 서명 요청(CSR)이 두 개씩 생성됩니다. 이러한 CSR이 승인되었는지 확인해야 하며, 필요한 경우 이를 직접 승인해야 합니다. 클라이언트 요청을 먼저 승인한 다음 서버 요청을 승인해야 합니다.
사전 요구 사항
- 클러스터에 시스템을 추가했습니다.
프로세스
클러스터가 시스템을 인식하는지 확인합니다.
$ oc get nodes
출력 예
NAME STATUS ROLES AGE VERSION master-0 Ready master 63m v1.27.3 master-1 Ready master 63m v1.27.3 master-2 Ready master 64m v1.27.3
출력에 생성된 모든 시스템이 나열됩니다.
참고이전 출력에는 일부 CSR이 승인될 때까지 컴퓨팅 노드(작업자 노드라고도 함)가 포함되지 않을 수 있습니다.
보류 중인 CSR을 검토하고 클러스터에 추가한 각 시스템에 대해
Pending
또는Approved
상태의 클라이언트 및 서버 요청이 표시되는지 확인합니다.$ oc get csr
출력 예
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 ...
예에서는 두 시스템이 클러스터에 참여하고 있습니다. 목록에는 승인된 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
- 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
참고일부 Operator는 일부 CSR이 승인될 때까지 사용할 수 없습니다.
이제 클라이언트 요청이 승인되었으므로 클러스터에 추가한 각 머신의 서버 요청을 검토해야 합니다.
$ oc get csr
출력 예
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 ...
나머지 CSR이 승인되지 않고
Pending
상태인 경우 클러스터 머신의 CSR을 승인합니다.개별적으로 승인하려면 유효한 CSR 각각에 대해 다음 명령을 실행하십시오.
$ oc adm certificate approve <csr_name> 1
- 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
모든 클라이언트 및 서버 CSR이 승인된 후 머신은
Ready
상태가 됩니다. 다음 명령을 실행하여 확인합니다.$ oc get nodes
출력 예
NAME STATUS ROLES AGE VERSION master-0 Ready master 73m v1.27.3 master-1 Ready master 73m v1.27.3 master-2 Ready master 74m v1.27.3 worker-0 Ready worker 11m v1.27.3 worker-1 Ready worker 11m v1.27.3
참고머신이
Ready
상태로 전환하는 데 서버 CSR의 승인 후 몇 분이 걸릴 수 있습니다.
추가 정보
- CSR에 대한 자세한 내용은 인증서 서명 요청을 참조하십시오.