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}"

검증

  1. 다음 출력이 표시되면 클러스터에서 다중 아키텍처 페이로드를 사용하는 것입니다.

    {
     "release.openshift.io/architecture": "multi",
     "url": "https://access.redhat.com/errata/<errata_version>"
    }

    그런 다음 클러스터에 다중 아키텍처 컴퓨팅 노드 추가를 시작할 수 있습니다.

  2. 다음 출력이 표시되면 클러스터에서 다중 아키텍처 페이로드를 사용하지 않습니다.

    {
     "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 서버가 설정됩니다.

프로세스

  1. UDP 집계를 비활성화합니다.

    현재 UDP 집계는 IBM Z®에서 지원되지 않으며 x86_64 컨트롤 플레인 및 추가 s390x 컴퓨팅 머신이 있는 다중 아키텍처 컴퓨팅 클러스터에서 자동으로 비활성화되지 않습니다. 추가 컴퓨팅 노드가 클러스터에 올바르게 추가되도록 하려면 UDP 집계를 수동으로 비활성화해야 합니다.

    1. 다음 콘텐츠를 사용하여 YAML 파일 udp-aggregation-config.yaml 을 생성합니다.

      apiVersion: v1
      kind: ConfigMap
      data:
        disable-udp-aggregation: "true"
      metadata:
        name: udp-aggregation-config
        namespace: openshift-network-operator
    2. 다음 명령을 실행하여 ConfigMap 리소스를 생성합니다.

      $ oc create -f udp-aggregation-config.yaml
  2. 다음 명령을 실행하여 클러스터에서 Ignition 구성 파일을 추출합니다.

    $ oc extract -n openshift-machine-api secret/worker-user-data-managed --keys=userData --to=- > worker.ign
  3. 클러스터에서 내보낸 worker.ign Ignition 구성 파일을 HTTP 서버로 업로드합니다. 이 파일의 URL을 기록해 둡니다.
  4. Ignition 파일이 URL에서 사용 가능한지 확인할 수 있습니다. 다음 예제에서는 컴퓨팅 노드에 대한 Ignition 구성 파일을 가져옵니다.

    $ curl -k http://<HTTP_server>/worker.ign
  5. 다음 명령을 실행하여 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')
  6. virt-install 을 시작하기 전에 다운로드한 RHEL 라이브 커널,initramfsrootfs 파일을 HTTP 또는 HTTPS 서버로 이동합니다.
  7. 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-443ingress-router-80 에 대한 HAProxy 규칙을 업데이트합니다.

  8. 계속해서 클러스터에 추가 컴퓨팅 머신을 만듭니다.

4.7.3. 시스템의 인증서 서명 요청 승인

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

사전 요구 사항

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

프로세스

  1. 클러스터가 시스템을 인식하는지 확인합니다.

    $ 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이 승인될 때까지 컴퓨팅 노드(작업자 노드라고도 함)가 포함되지 않을 수 있습니다.

  2. 보류 중인 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이 더 많이 나타날 수도 있습니다.

  3. 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이 승인될 때까지 사용할 수 없습니다.

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

    $ 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
    ...

  5. 나머지 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
  6. 모든 클라이언트 및 서버 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의 승인 후 몇 분이 걸릴 수 있습니다.

추가 정보

Red Hat logoGithubRedditYoutube

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.