4.5. IBM Z에 호스팅된 컨트롤 플레인 배포


관리 클러스터로 작동하도록 클러스터를 구성하여 호스팅되는 컨트롤 플레인을 배포할 수 있습니다. 관리 클러스터는 컨트롤 플레인이 호스팅되는 OpenShift Container Platform 클러스터입니다. 관리 클러스터를 호스팅 클러스터라고도 합니다.

참고

관리 클러스터는 관리 클러스터가 아닙니다. 관리형 클러스터는 hub 클러스터가 관리하는 클러스터입니다. 관리 클러스터는 Kubernetes Operator 2.7에 대해 OpenShift Container Platform 4.17 및 다중 클러스터 엔진부터 지원되는 x86_64 아키텍처 또는 Kubernetes Operator 2.10용 OpenShift Container Platform 4.20 및 멀티 클러스터 엔진부터 지원되는 s390x 아키텍처에서 실행할 수 있습니다.

hypershift 애드온을 사용하여 해당 클러스터에 HyperShift Operator를 배포하여 관리형 클러스터를 관리 클러스터로 변환할 수 있습니다. 그런 다음 호스팅된 클러스터를 생성할 수 있습니다.

다중 클러스터 엔진 Operator는 관리하는 허브 클러스터인 기본 로컬 클러스터 및 hub 클러스터만 관리 클러스터로 지원합니다.

베어 메탈에서 호스팅되는 컨트롤 플레인을 프로비저닝하려면 에이전트 플랫폼을 사용할 수 있습니다. 에이전트 플랫폼은 중앙 인프라 관리 서비스를 사용하여 호스트된 클러스터에 작업자 노드를 추가합니다. 자세한 내용은 "중앙 인프라 관리 서비스 활성화"를 참조하십시오.

각 IBM Z 시스템 호스트는 중앙 인프라 관리에서 제공하는 PXE 또는 ISO 이미지로 시작해야 합니다. 각 호스트가 시작되면 에이전트 프로세스를 실행하여 호스트의 세부 정보를 검색하고 설치를 완료합니다. 에이전트 사용자 정의 리소스는 각 호스트를 나타냅니다.

에이전트 플랫폼을 사용하여 호스팅된 클러스터를 생성하면 HyperShift Operator가 호스팅된 컨트롤 플레인 네임스페이스에 에이전트 클러스터 API 공급자를 설치합니다.

  • Kubernetes Operator 버전 2.7 이상용 멀티 클러스터 엔진은 OpenShift Container Platform 클러스터에 설치해야 합니다. OpenShift Container Platform OperatorHub에서 다중 클러스터 엔진 Operator를 Operator로 설치할 수 있습니다.
  • 다중 클러스터 엔진 Operator에는 하나 이상의 관리형 OpenShift Container Platform 클러스터가 있어야 합니다. local-cluster 는 multicluster engine Operator 2.7 이상에서 자동으로 가져옵니다. local-cluster 에 대한 자세한 내용은 Red Hat Advanced Cluster Management 설명서의 고급 구성 을 참조하십시오. 다음 명령을 실행하여 허브 클러스터의 상태를 확인할 수 있습니다.

    $ oc get managedclusters local-cluster
    Copy to Clipboard Toggle word wrap
  • HyperShift Operator를 실행하려면 작업자 노드가 3개 이상 있는 호스팅 클러스터가 필요합니다.
  • 중앙 인프라 관리 서비스를 활성화해야 합니다. 자세한 내용은 중앙 인프라 관리 서비스 활성화를 참조하십시오.
  • 호스팅된 컨트롤 플레인 명령줄 인터페이스를 설치해야 합니다. 자세한 내용은 호스팅된 컨트롤 플레인 명령줄 인터페이스 설치를 참조하십시오.
참고

관리 클러스터는 Kubernetes Operator 2.7에 대해 OpenShift Container Platform 4.17 및 다중 클러스터 엔진부터 지원되는 x86_64 아키텍처 또는 Kubernetes Operator 2.10용 OpenShift Container Platform 4.20 및 멀티 클러스터 엔진부터 지원되는 s390x 아키텍처에서 실행할 수 있습니다.

4.5.2. IBM Z 인프라 요구사항

에이전트 플랫폼은 인프라를 생성하지 않지만 인프라를 위해 다음 리소스가 필요합니다.

  • 에이전트: 에이전트 는 검색 이미지 또는 PXE 이미지로 부팅되고 OpenShift Container Platform 노드로 프로비저닝할 준비가 된 호스트를 나타냅니다.
  • DNS: API 및 Ingress 끝점은 라우팅할 수 있어야 합니다.

호스트된 컨트롤 플레인 기능은 기본적으로 활성화되어 있습니다. 기능을 비활성화하고 수동으로 활성화하거나 기능을 비활성화해야 하는 경우 호스팅된 컨트롤 플레인 기능 활성화 또는 비활성화를 참조하십시오.

4.5.3. IBM Z에서 호스팅된 컨트롤 플레인의 DNS 구성

호스팅된 클러스터의 API 서버는 NodePort 서비스로 노출됩니다. API 서버에 연결할 수 있는 대상을 가리키는 api.<hosted_cluster_name>.<base_domain >에 대한 DNS 항목이 있어야 합니다.

DNS 항목은 호스팅된 컨트롤 플레인을 실행하는 관리형 클러스터의 노드 중 하나를 가리키는 레코드만큼 단순할 수 있습니다.

이 항목은 들어오는 트래픽을 Ingress Pod로 리디렉션하기 위해 배포된 로드 밸런서를 가리킬 수도 있습니다.

DNS 구성의 다음 예제를 참조하십시오.

$ cat /var/named/<example.krnl.es.zone>
Copy to Clipboard Toggle word wrap

출력 예

$ TTL 900
@ IN  SOA bastion.example.krnl.es.com. hostmaster.example.krnl.es.com. (
      2019062002
      1D 1H 1W 3H )
  IN NS bastion.example.krnl.es.com.
;
;
api                   IN A 1xx.2x.2xx.1xx 
1

api-int               IN A 1xx.2x.2xx.1xx
;
;
*.apps        IN A 1xx.2x.2xx.1xx
;
;EOF
Copy to Clipboard Toggle word wrap

1
레코드는 호스팅된 컨트롤 플레인의 수신 및 송신 트래픽을 처리하는 API 로드 밸런서의 IP 주소를 나타냅니다.

IBM z/VM의 경우 에이전트의 IP 주소에 해당하는 IP 주소를 추가합니다.

compute-0              IN A 1xx.2x.2xx.1yy
compute-1              IN A 1xx.2x.2xx.1yy
Copy to Clipboard Toggle word wrap

4.5.3.1. 사용자 정의 DNS 이름 정의

클러스터 관리자는 노드 부트스트랩 및 컨트롤 플레인 통신에 사용되는 내부 끝점과 다른 외부 API DNS 이름을 사용하여 호스팅 클러스터를 생성할 수 있습니다. 다음과 같은 이유로 다른 DNS 이름을 정의할 수 있습니다.

  • 내부 루트 CA에 바인딩되는 컨트롤 플레인 기능을 중단하지 않고 사용자용 TLS 인증서를 공용 CA의 인증서로 교체하려면 다음을 수행합니다.
  • 분할 수평 DNS 및 NAT 시나리오를 지원합니다.
  • 올바른 kubeconfig 및 DNS 구성으로 Show Login Command 기능과 같은 기능을 사용할 수 있는 독립 실행형 컨트롤 플레인과 유사한 환경을 보장하기 위해 다음을 수행합니다.

HostedCluster 오브젝트의 kubeAPIServerDNSName 매개변수에 도메인 이름을 입력하여 초기 설정 중 또는 설치 후 작업 중에 DNS 이름을 정의할 수 있습니다.

사전 요구 사항

  • kubeAPIServerDNSName 매개변수에 설정한 DNS 이름을 다루는 유효한 TLS 인증서가 있습니다.
  • 올바른 주소에 도달하고 가리킬 수 있는 확인 가능한 DNS 이름 URI가 있습니다.

프로세스

  • HostedCluster 오브젝트의 사양에서 kubeAPIServerDNSName 매개변수와 도메인의 주소를 추가하고 다음 예와 같이 사용할 인증서를 지정합니다.

    #...
    spec:
      configuration:
        apiServer:
          servingCerts:
            namedCertificates:
            - names:
              - xxx.example.com
              - yyy.example.com
              servingCertificate:
                name: <my_serving_certificate>
      kubeAPIServerDNSName: <custom_address> 
    1
    Copy to Clipboard Toggle word wrap
    1
    kubeAPIServerDNSName 매개변수의 값은 유효한 도메인이어야 합니다.

kubeAPIServerDNSName 매개변수를 정의하고 인증서를 지정하면 Control Plane Operator 컨트롤러에서 custom-admin- kubeconfig 라는 kubeconfig 파일을 생성합니다. 여기서 파일이 HostedControlPlane 네임스페이스에 저장됩니다. 인증서 생성은 루트 CA에서 발생하며 HostedControlPlane 네임스페이스는 만료 및 갱신을 관리합니다.

Control Plane Operator는 HostedControlPlane 네임스페이스에서 CustomKubeconfig 라는 새 kubeconfig 파일을 보고합니다. 해당 파일은 kubeAPIServerDNSName 매개변수에서 정의된 새 서버를 사용합니다.

사용자 정의 kubeconfig 파일에 대한 참조는 HostedCluster 오브젝트의 CustomKubeconfigstatus 매개변수에 있습니다. CustomKubeConfig 매개변수는 선택 사항이며 kubeAPIServerDNSName 매개변수가 비어 있지 않은 경우에만 매개변수를 추가할 수 있습니다. CustomKubeConfig 매개변수를 설정한 후 매개변수는 HostedCluster 네임스페이스에서 < hosted_cluster_name>-custom-admin-kubeconfig 라는 보안 생성을 트리거합니다. 시크릿을 사용하여 HostedCluster API 서버에 액세스할 수 있습니다. 설치 후 작업 중에 CustomKubeConfig 매개변수를 제거하면 모든 관련 보안 및 상태 참조가 삭제됩니다.

참고

사용자 정의 DNS 이름을 정의해도 데이터 플레인에 직접적인 영향을 미치지 않으므로 예상되는 롤아웃이 발생하지 않습니다. HostedControlPlane 네임스페이스는 HyperShift Operator에서 변경 사항을 수신하고 해당 매개변수를 삭제합니다.

HostedCluster 오브젝트의 사양에서 kubeAPIServerDNSName 매개변수를 제거하면 새로 생성된 모든 보안 및 CustomKubeconfig 참조가 클러스터 및 status 매개변수에서 제거됩니다.

4.5.4. IBM Z용 베어 메탈에 호스팅 클러스터 생성

호스트 클러스터를 생성하거나 가져올 수 있습니다. 지원 설치 프로그램이 다중 클러스터 엔진 Operator에 대한 애드온으로 활성화되고 에이전트 플랫폼을 사용하여 호스팅된 클러스터를 생성하는 경우 HyperShift Operator는 호스팅된 컨트롤 플레인 네임스페이스에 에이전트 클러스터 API 공급자를 설치합니다.

4.5.4.1. IBM Z용 베어 메탈에 호스팅 클러스터 생성

베어 메탈 인프라에서 호스팅된 클러스터를 생성하거나 가져올 수 있습니다. 지원 설치 관리자를 다중 클러스터 엔진 Operator에 대한 애드온으로 활성화하고 에이전트 플랫폼을 사용하여 호스팅된 클러스터를 생성한 후 HyperShift Operator는 호스팅된 컨트롤 플레인 네임스페이스에 에이전트 클러스터 API 공급자를 설치합니다. 에이전트 클러스터 API 공급자는 컨트롤 플레인과 컴퓨팅 노드로 구성된 호스팅 클러스터를 호스팅하는 관리 클러스터를 연결합니다.

사전 요구 사항

  • 각 호스트 클러스터에는 클러스터 전체 이름이 있어야 합니다. 호스팅된 클러스터 이름은 기존 관리 클러스터와 같을 수 없습니다. 그러지 않으면 다중 클러스터 엔진 Operator가 호스팅된 클러스터를 관리할 수 없습니다.
  • 클러스터를 호스팅 클러스터 이름으로 사용하지 마십시오.
  • 다중 클러스터 엔진 Operator 관리 클러스터의 네임스페이스에 호스팅 클러스터를 생성할 수 없습니다.
  • 최상의 보안 및 관리 관행을 위해 다른 호스팅 클러스터와 별도로 호스팅 클러스터를 생성합니다.
  • 클러스터에 대해 기본 스토리지 클래스가 구성되어 있는지 확인합니다. 그러지 않으면 보류 중인 PVC(영구 볼륨 클레임)가 표시될 수 있습니다.

프로세스

  1. 다음 명령을 입력하여 네임스페이스를 생성합니다.

    $ oc create ns <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap

    & lt;hosted_cluster_namespace&gt;를 호스팅된 클러스터 네임스페이스의 식별자로 바꿉니다. HyperShift Operator는 네임스페이스를 생성합니다. 베어 메탈 인프라에서 호스팅된 클러스터 생성 프로세스 중에 생성된 Cluster API 공급자 역할에 네임스페이스가 이미 있어야 합니다.

  2. 다음 명령을 입력하여 호스팅된 클러스터에 대한 구성 파일을 생성합니다.

    $ hcp create cluster agent \
      --name=<hosted_cluster_name> \
    1
    
      --pull-secret=<path_to_pull_secret> \
    2
    
      --agent-namespace=<hosted_control_plane_namespace> \
    3
    
      --base-domain=<base_domain> \
    4
    
      --api-server-address=api.<hosted_cluster_name>.<base_domain> \
    5
    
      --etcd-storage-class=<etcd_storage_class> \
    6
    
      --ssh-key=<path_to_ssh_key> \
    7
    
      --namespace=<hosted_cluster_namespace> \
    8
    
      --control-plane-availability-policy=HighlyAvailable \
    9
    
      --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release_image>-multi \
    10
    
      --node-pool-replicas=<node_pool_replica_count> \
    11
    
      --render \
      --render-sensitive \
      --ssh-key <home_directory>/<path_to_ssh_key>/<ssh_key> > hosted-cluster-config.yaml 
    12
    Copy to Clipboard Toggle word wrap
    1
    호스트된 클러스터의 이름을 지정합니다( : ).
    2
    풀 시크릿의 경로를 지정합니다(예: /user/name/pullsecret ).
    3
    호스트된 컨트롤 플레인 네임스페이스를 지정합니다(예: clusters-example ). oc get agent -n <hosted_control_plane_namespace> 명령을 사용하여 이 네임스페이스 에서 에이전트를 사용할 수 있는지 확인합니다.
    4
    krnl.es 와 같은 기본 도메인을 지정합니다.
    5
    --api-server-address 플래그는 호스팅된 클러스터의 Kubernetes API 통신에 사용할 IP 주소를 정의합니다. --api-server-address 플래그를 설정하지 않으면 관리 클러스터에 연결하려면 로그인해야 합니다.
    6
    lvm-storageclass 와 같은 etcd 스토리지 클래스 이름을 지정합니다.
    7
    SSH 공개 키의 경로를 지정합니다. 기본 파일 경로는 ~/.ssh/id_rsa.pub 입니다.
    8
    호스팅된 클러스터 네임스페이스를 지정합니다.
    9
    호스팅된 컨트롤 플레인 구성 요소의 가용성 정책을 지정합니다. 지원되는 옵션은 SingleReplicaHighlyAvailable 입니다. 기본값은 HighlyAvailable 입니다.
    10
    사용하려는 지원되는 OpenShift Container Platform 버전 (예: 4.19.0-multi )을 지정합니다. 연결이 끊긴 환경을 사용하는 경우 < ocp_release_image >를 다이제스트 이미지로 교체합니다. OpenShift Container Platform 릴리스 이미지 다이제스트를 추출하려면 OpenShift Container Platform 릴리스 이미지 다이제스트 추출을 참조하십시오.
    11
    3 과 같은 노드 풀 복제본 수를 지정합니다. 동일한 수의 복제본을 생성하려면 복제본 수를 0 이상으로 지정해야 합니다. 그렇지 않으면 노드 풀을 생성하지 않습니다.
    12
    --ssh-key 플래그 후 user/.ssh/id_rsa 와 같은 SSH 키의 경로를 지정합니다.
  3. 다음 명령을 입력하여 호스팅 클러스터 구성 파일에 변경 사항을 적용합니다.

    $ oc apply -f hosted_cluster_config.yaml
    Copy to Clipboard Toggle word wrap
  4. 다음 명령을 입력하여 호스팅된 클러스터, 노드 풀 및 Pod 생성을 확인합니다.

    $ oc get hostedcluster \
      <hosted_cluster_name> -n \
      <hosted_cluster_namespace> -o \
      jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .
    Copy to Clipboard Toggle word wrap
    $ oc get hostedcluster \
      <nodepool_name> -n \
      <hosted_cluster_namespace> -o \
      jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .
    Copy to Clipboard Toggle word wrap
    $ oc get pods -n <hosted_control_plane_namespace>
    Copy to Clipboard Toggle word wrap
  5. 호스트 클러스터가 준비되었는지 확인합니다. Available: True 는 컨트롤 플레인의 준비 상태를 나타냅니다.

4.5.5. IBM Z에서 호스팅된 컨트롤 플레인에 대한 InfraEnv 리소스 생성

InfraEnv 는 PXE 이미지로 부팅되는 호스트가 에이전트로 참여할 수 있는 환경입니다. 이 경우 에이전트는 호스팅된 컨트롤 플레인과 동일한 네임스페이스에 생성됩니다.

프로세스

  1. 구성을 포함할 YAML 파일을 생성합니다. 다음 예제를 참조하십시오.

    apiVersion: agent-install.openshift.io/v1beta1
    kind: InfraEnv
    metadata:
      name: <hosted_cluster_name>
      namespace: <hosted_control_plane_namespace>
    spec:
      cpuArchitecture: s390x
      pullSecretRef:
        name: pull-secret
      sshAuthorizedKey: <ssh_public_key>
    Copy to Clipboard Toggle word wrap
  2. 파일을 infraenv-config.yaml 로 저장합니다.
  3. 다음 명령을 입력하여 구성을 적용합니다.

    $ oc apply -f infraenv-config.yaml
    Copy to Clipboard Toggle word wrap
  4. IBM Z 시스템이 에이전트로 참여할 수 있는 PXE 또는 ISO 이미지(예: initrd.img,kernel.img 또는 rootfs.img )를 다운로드하는 URL을 가져오려면 다음 명령을 입력합니다.

    $ oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name> -o json
    Copy to Clipboard Toggle word wrap

4.5.6. InfraEnv 리소스에 IBM Z 에이전트 추가

호스팅된 컨트롤 플레인에 컴퓨팅 노드를 연결하려면 노드 풀을 확장하는 데 도움이 되는 에이전트를 생성합니다. IBM Z 환경에 에이전트를 추가하려면 이 섹션에 자세히 설명된 추가 단계가 필요합니다.

달리 명시하지 않는 한, 이러한 절차는 IBM Z 및 IBM LinuxONE의 z/VM 및 RHEL KVM 설치에 모두 적용됩니다.

4.5.6.1. IBM Z KVM을 에이전트로 추가

IBM Z with KVM의 경우 다음 명령을 실행하여 InfraEnv 리소스에서 다운로드한 PXE 이미지로 IBM Z 환경을 시작합니다. 에이전트가 생성되면 호스트는 지원 서비스와 통신하고 관리 클러스터의 InfraEnv 리소스와 동일한 네임스페이스에 등록합니다.

프로세스

  1. 다음 명령을 실행합니다.

    virt-install \
       --name "<vm_name>" \ 
    1
    
       --autostart \
       --ram=16384 \
       --cpu host \
       --vcpus=4 \
       --location "<path_to_kernel_initrd_image>,kernel=kernel.img,initrd=initrd.img" \ 
    2
    
       --disk <qcow_image_path> \ 
    3
    
       --network network:macvtap-net,mac=<mac_address> \ 
    4
    
       --graphics none \
       --noautoconsole \
       --wait=-1
       --extra-args "rd.neednet=1 nameserver=<nameserver>   coreos.live.rootfs_url=http://<http_server>/rootfs.img random.trust_cpu=on rd.luks.options=discard ignition.firstboot ignition.platform.id=metal console=tty1 console=ttyS1,115200n8 coreos.inst.persistent-kargs=console=tty1 console=ttyS1,115200n8" 
    5
    Copy to Clipboard Toggle word wrap
    1
    가상 머신의 이름을 지정합니다.
    2
    kernel_initrd_image 파일의 위치를 지정합니다.
    3
    디스크 이미지 경로를 지정합니다.
    4
    Mac 주소를 지정합니다.
    5
    에이전트의 서버 이름을 지정합니다.
  2. ISO 부팅의 경우 InfraEnv 리소스에서 ISO를 다운로드하고 다음 명령을 실행하여 노드를 부팅합니다.

    virt-install \
      --name "<vm_name>" \ 
    1
    
      --autostart \
      --memory=16384 \
      --cpu host \
      --vcpus=4 \
      --network network:macvtap-net,mac=<mac_address> \ 
    2
    
      --cdrom "<path_to_image.iso>" \ 
    3
    
      --disk <qcow_image_path> \
      --graphics none \
      --noautoconsole \
      --os-variant <os_version> \ 
    4
    
      --wait=-1
    Copy to Clipboard Toggle word wrap
    1
    가상 머신의 이름을 지정합니다.
    2
    Mac 주소를 지정합니다.
    3
    image.iso 파일의 위치를 지정합니다.
    4
    사용 중인 운영 체제 버전을 지정합니다.

4.5.6.2. IBM Z LPAR을 에이전트로 추가

IBM Z 또는 IBM LinuxONE의 Logical Partition (LPAR)을 호스팅된 컨트롤 플레인에 컴퓨팅 노드로 추가할 수 있습니다.

프로세스

  1. 에이전트를 위한 부팅 매개변수 파일을 생성합니다.

    매개변수 파일 예

    rd.neednet=1 cio_ignore=all,!condev \
    console=ttysclp0 \
    ignition.firstboot ignition.platform.id=metal
    coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \
    1
    
    coreos.inst.persistent-kargs=console=ttysclp0
    ip=<ip>::<gateway>:<netmask>::<interface>:none nameserver=<dns> \
    2
    
    rd.znet=qeth,<network_adaptor_range>,layer2=1
    rd.<disk_type>=<adapter> \
    3
    
    zfcp.allow_lun_scan=0
    ai.ip_cfg_override=1 \
    4
    
    random.trust_cpu=on rd.luks.options=discard
    Copy to Clipboard Toggle word wrap

    1
    coreos.live.rootfs_url 아티팩트의 경우 시작 중인 커널initramfs 와 일치하는 rootfs 아티팩트를 지정합니다. HTTP 및 HTTPS 프로토콜만 지원됩니다.
    2
    ip 매개변수의 경우 IBM Z 및 IBM LinuxONE에 z/VM으로 클러스터 설치에 설명된 대로 IP 주소를 수동으로 할당합니다.
    3
    DASD 유형 디스크에 설치하는 경우 rd.dasd 를 사용하여 RHCOS(Red Hat Enterprise Linux CoreOS)를 설치할 DASD를 지정합니다. FCP 유형 디스크에 설치하려면 rd.zfcp=<adapter>,<wwpn>,<lun >을 사용하여 RHCOS를 설치할 FCP 디스크를 지정합니다.
    4
    OSA(Open Systems Adapter) 또는 HiperSockets를 사용할 때 이 매개변수를 지정합니다.
  2. InfraEnv 리소스에서 .insinitrd.img.addrsize 파일을 다운로드합니다.

    기본적으로 .insinitrd.img.addrsize 파일의 URL은 InfraEnv 리소스에서 사용할 수 없습니다. 해당 아티팩트를 가져오려면 URL을 편집해야 합니다.

    1. followign 명령을 실행하여 ins-file 을 포함하도록 커널 URL 끝점을 업데이트합니다.

      $ curl -k -L -o generic.ins "< url for ins-file >"
      Copy to Clipboard Toggle word wrap

      예제 URL

      https://…/boot-artifacts/ins-file?arch=s390x&version=4.17.0
      Copy to Clipboard Toggle word wrap

    2. s390x- initrd -addrsize:을 포함하도록 initrd URL 끝점을 업데이트합니다.

      예제 URL

      https://…./s390x-initrd-addrsize?api_key=<api-key>&arch=s390x&version=4.17.0
      Copy to Clipboard Toggle word wrap

  3. initrd,kernel,generic.insinitrd.img.addrsize 매개변수 파일을 파일 서버로 전송합니다. FTP를 사용하여 파일을 전송하고 부팅하는 방법에 대한 자세한 내용은 "LPAR에 설치"를 참조하십시오.
  4. 머신을 시작합니다.
  5. 클러스터의 다른 모든 시스템에 대해 절차를 반복합니다.

4.5.6.3. IBM z/VM을 에이전트로 추가

z/VM 게스트에 고정 IP를 사용하려면 IP 매개변수가 두 번째 시작 시 지속되도록 z/VM 에이전트에 대한 NMStateConfig 속성을 구성해야 합니다.

InfraEnv 리소스에서 다운로드한 PXE 이미지로 IBM Z 환경을 시작하려면 다음 단계를 완료합니다. 에이전트가 생성되면 호스트는 지원 서비스와 통신하고 관리 클러스터의 InfraEnv 리소스와 동일한 네임스페이스에 등록합니다.

프로세스

  1. 매개 변수 파일을 업데이트하여 rootfs_url,network_adaptordisk_type 값을 추가합니다.

    매개변수 파일 예

    rd.neednet=1 cio_ignore=all,!condev \
    console=ttysclp0  \
    ignition.firstboot ignition.platform.id=metal \
    coreos.live.rootfs_url=http://<http_server>/rhcos-<version>-live-rootfs.<architecture>.img \
    1
    
    coreos.inst.persistent-kargs=console=ttysclp0
    ip=<ip>::<gateway>:<netmask>::<interface>:none nameserver=<dns> \
    2
    
    rd.znet=qeth,<network_adaptor_range>,layer2=1
    rd.<disk_type>=<adapter> \
    3
    
    zfcp.allow_lun_scan=0
    ai.ip_cfg_override=1 \
    4
    Copy to Clipboard Toggle word wrap

    1
    coreos.live.rootfs_url 아티팩트의 경우 시작 중인 커널initramfs 와 일치하는 rootfs 아티팩트를 지정합니다. HTTP 및 HTTPS 프로토콜만 지원됩니다.
    2
    ip 매개변수의 경우 IBM Z 및 IBM LinuxONE에 z/VM으로 클러스터 설치에 설명된 대로 IP 주소를 수동으로 할당합니다.
    3
    DASD 유형 디스크에 설치하는 경우 rd.dasd 를 사용하여 RHCOS(Red Hat Enterprise Linux CoreOS)를 설치할 DASD를 지정합니다. FCP 유형 디스크에 설치하려면 rd.zfcp=<adapter>,<wwpn>,<lun >을 사용하여 RHCOS를 설치할 FCP 디스크를 지정합니다.
    참고

    FCP 다중 경로 구성의 경우 대신 두 개의 디스크를 제공합니다.

    rd.zfcp=<adapter1>,<wwpn1>,<lun1> \
    rd.zfcp=<adapter2>,<wwpn2>,<lun2>
    Copy to Clipboard Toggle word wrap

    4
    OSA(Open Systems Adapter) 또는 HiperSockets를 사용할 때 이 매개변수를 지정합니다.
  2. 다음 명령을 실행하여 initrd, 커널 이미지 및 매개변수 파일을 게스트 VM으로 이동합니다.

    vmur pun -r -u -N kernel.img $INSTALLERKERNELLOCATION/<image name>
    Copy to Clipboard Toggle word wrap
    vmur pun -r -u -N generic.parm $PARMFILELOCATION/paramfilename
    Copy to Clipboard Toggle word wrap
    vmur pun -r -u -N initrd.img $INSTALLERINITRAMFSLOCATION/<image name>
    Copy to Clipboard Toggle word wrap
  3. 게스트 VM 콘솔에서 다음 명령을 실행합니다.

    cp ipl c
    Copy to Clipboard Toggle word wrap
  4. 에이전트 및 해당 속성을 나열하려면 다음 명령을 입력합니다.

    $ oc -n <hosted_control_plane_namespace> get agents
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME    CLUSTER APPROVED    ROLE    STAGE
    50c23cda-cedc-9bbd-bcf1-9b3a5c75804d    auto-assign
    5e498cd3-542c-e54f-0c58-ed43e28b568a    auto-assign
    Copy to Clipboard Toggle word wrap

  5. 다음 명령을 실행하여 에이전트를 승인합니다.

    $ oc -n <hosted_control_plane_namespace> patch agent \
      50c23cda-cedc-9bbd-bcf1-9b3a5c75804d -p \
      '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-zvm-0.hostedn.example.com"}}' \
    1
    
      --type merge
    Copy to Clipboard Toggle word wrap
    1
    선택적으로 사양에 에이전트 ID < installation_disk_id > 및 < hostname >을 설정할 수 있습니다.
  6. 다음 명령을 실행하여 에이전트가 승인되었는지 확인합니다.

    $ oc -n <hosted_control_plane_namespace> get agents
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                            CLUSTER     APPROVED   ROLE          STAGE
    50c23cda-cedc-9bbd-bcf1-9b3a5c75804d             true       auto-assign
    5e498cd3-542c-e54f-0c58-ed43e28b568a             true       auto-assign
    Copy to Clipboard Toggle word wrap

4.5.7. IBM Z에서 호스팅된 클러스터의 NodePool 오브젝트 확장

NodePool 오브젝트는 호스팅된 클러스터를 생성할 때 생성됩니다. NodePool 오브젝트를 스케일링하면 호스팅된 컨트롤 플레인에 더 많은 컴퓨팅 노드를 추가할 수 있습니다.

노드 풀을 확장하면 머신이 생성됩니다. Cluster API 공급자는 승인된 에이전트를 찾고 현재 검증이 사용되지 않으며, 노드 풀 사양에 지정된 요구 사항을 충족합니다. 에이전트의 상태 및 조건을 확인하여 에이전트 설치를 모니터링할 수 있습니다.

프로세스

  1. 다음 명령을 실행하여 NodePool 오브젝트를 두 개의 노드로 확장합니다.

    $ oc -n <clusters_namespace> scale nodepool <nodepool_name> --replicas 2
    Copy to Clipboard Toggle word wrap

    Cluster API 에이전트 공급자는 호스트 클러스터에 할당된 두 개의 에이전트를 임의로 선택합니다. 이러한 에이전트는 다른 상태를 통과하고 마지막으로 호스팅된 클러스터에 OpenShift Container Platform 노드로 참여합니다. 에이전트는 다음 순서로 전환 단계를 통과합니다.

    • 바인딩
    • 검색
    • 충분하지 않음
    • 설치
    • installing-in-progress
    • added-to-existing-cluster
  2. 다음 명령을 실행하여 특정 확장 에이전트의 상태를 확인합니다.

    $ oc -n <hosted_control_plane_namespace> get agent -o \
      jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} \
      Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'
    Copy to Clipboard Toggle word wrap

    출력 예

    BMH: Agent: 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d State: known-unbound
    BMH: Agent: 5e498cd3-542c-e54f-0c58-ed43e28b568a State: insufficient
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 전환 단계를 확인합니다.

    $ oc -n <hosted_control_plane_namespace> get agent
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                   CLUSTER           APPROVED       ROLE        STAGE
    50c23cda-cedc-9bbd-bcf1-9b3a5c75804d   hosted-forwarder   true          auto-assign
    5e498cd3-542c-e54f-0c58-ed43e28b568a                      true          auto-assign
    da503cf1-a347-44f2-875c-4960ddb04091   hosted-forwarder   true          auto-assign
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 호스팅된 클러스터에 액세스할 kubeconfig 파일을 생성합니다.

    $ hcp create kubeconfig \
      --namespace <clusters_namespace> \
      --name <hosted_cluster_namespace> > <hosted_cluster_name>.kubeconfig
    Copy to Clipboard Toggle word wrap
  5. 에이전트가 add-to-existing-cluster 상태에 도달한 후 다음 명령을 입력하여 OpenShift Container Platform 노드를 볼 수 있는지 확인합니다.

    $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                             STATUS   ROLES    AGE      VERSION
    worker-zvm-0.hostedn.example.com Ready    worker   5m41s    v1.24.0+3882f8f
    worker-zvm-1.hostedn.example.com Ready    worker   6m3s     v1.24.0+3882f8f
    Copy to Clipboard Toggle word wrap

    클러스터 Operator는 노드에 워크로드를 추가하여 조정하기 시작합니다.

  6. 다음 명령을 입력하여 NodePool 오브젝트를 확장할 때 두 개의 머신이 생성되었는지 확인합니다.

    $ oc -n <hosted_control_plane_namespace> get machine.cluster.x-k8s.io
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                CLUSTER  NODENAME PROVIDERID     PHASE     AGE   VERSION
    hosted-forwarder-79558597ff-5tbqp   hosted-forwarder-crqq5   worker-zvm-0.hostedn.example.com   agent://50c23cda-cedc-9bbd-bcf1-9b3a5c75804d   Running   41h   4.15.0
    hosted-forwarder-79558597ff-lfjfk   hosted-forwarder-crqq5   worker-zvm-1.hostedn.example.com   agent://5e498cd3-542c-e54f-0c58-ed43e28b568a   Running   41h   4.15.0
    Copy to Clipboard Toggle word wrap

  7. 다음 명령을 실행하여 클러스터 버전을 확인합니다.

    $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                         VERSION       AVAILABLE   PROGRESSING   SINCE   STATUS
    clusterversion.config.openshift.io/version   4.15.0-ec.2   True        False         40h     Cluster version is 4.15.0-ec.2
    Copy to Clipboard Toggle word wrap

  8. 다음 명령을 실행하여 클러스터 Operator 상태를 확인합니다.

    $ oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusteroperators
    Copy to Clipboard Toggle word wrap

클러스터의 각 구성 요소에 대해 출력에는 NAME,VERSION,AVAILABLE,PROGRESSING,DEGRADED,SINCE, MESSAGE.

출력 예제는 Initial Operator 설정을 참조하십시오.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2025 Red Hat