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


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

참고

관리 클러스터는 관리 클러스터가 아닙니다. 관리형 클러스터는 hub 클러스터가 관리하는 클러스터입니다.

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

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

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

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

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

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

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

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 개체의 CustomKubeconfig 라는 상태 매개변수에 있습니다. CustomKubeConfig 매개변수는 선택 사항이며, kubeAPIServerDNSName 매개변수가 비어 있지 않은 경우에만 매개변수를 추가할 수 있습니다. CustomKubeConfig 매개변수를 설정하면 해당 매개변수는 HostedCluster 네임스페이스에 <hosted_cluster_name>-custom-admin-kubeconfig 라는 이름의 비밀을 생성합니다. 이 비밀을 사용하여 HostedCluster API 서버에 액세스할 수 있습니다. 설치 후 작업 중에 CustomKubeConfig 매개변수를 제거하면 관련된 모든 비밀과 상태 참조가 삭제됩니다.

참고

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

HostedCluster 개체의 사양에서 kubeAPIServerDNSName 매개변수를 제거하면 새로 생성된 모든 비밀과 CustomKubeconfig 참조가 클러스터와 status 매개변수에서 제거됩니다.

4.5.4. CLI를 사용하여 호스팅 클러스터 만들기

베어메탈 인프라에서는 호스팅된 클러스터를 만들거나 가져올 수 있습니다. 멀티클러스터 엔진 Operator에 대한 추가 기능으로 Assisted Installer를 활성화하고 Agent 플랫폼으로 호스팅된 클러스터를 생성하면 HyperShift Operator가 호스팅된 제어 평면 네임스페이스에 Agent Cluster API 공급자를 설치합니다. 에이전트 클러스터 API 공급자는 제어 평면을 호스팅하는 관리 클러스터와 컴퓨팅 노드만으로 구성된 호스팅 클러스터를 연결합니다.

사전 요구 사항

  • 각 호스트 클러스터에는 클러스터 전체 이름이 있어야 합니다. 호스팅된 클러스터 이름은 기존 관리형 클러스터와 동일할 수 없습니다. 그렇지 않으면 멀티클러스터 엔진 운영자는 호스팅된 클러스터를 관리할 수 없습니다.
  • 호스팅된 클러스터 이름으로 '클러스터'라는 단어를 사용하지 마세요.
  • 멀티클러스터 엔진 운영자가 관리하는 클러스터의 네임스페이스에 호스팅된 클러스터를 만들 수 없습니다.
  • 최상의 보안 및 관리 관행을 위해 다른 호스팅 클러스터와 별도로 호스팅 클러스터를 만드세요.
  • 클러스터에 대해 기본 스토리지 클래스가 구성되어 있는지 확인합니다. 그렇지 않으면 보류 중인 영구 볼륨 클레임(PVC)이 표시될 수 있습니다.
  • 기본적으로 hcp create cluster agent 명령을 사용하면 명령은 구성된 노드 포트를 사용하여 호스팅된 클러스터를 생성합니다. 베어 메탈에서 호스팅되는 클러스터의 기본 게시 전략은 로드 밸런서를 통해 서비스를 노출하는 것입니다. 웹 콘솔이나 Red Hat Advanced Cluster Management를 사용하여 호스팅 클러스터를 생성하는 경우 Kubernetes API 서버 외에 서비스에 대한 게시 전략을 설정하려면 HostedCluster 사용자 정의 리소스에서 servicePublishingStrategy 정보를 수동으로 지정해야 합니다.
  • 인프라, 방화벽, 포트 및 서비스와 관련된 요구 사항을 포함하여 "베어 메탈에서 호스팅되는 제어 평면에 대한 요구 사항"에 설명된 요구 사항을 충족하는지 확인하세요. 예를 들어, 해당 요구 사항은 다음 예제 명령에서 볼 수 있듯이 관리 클러스터의 베어 메탈 호스트에 적절한 영역 레이블을 추가하는 방법을 설명합니다.

    $ oc label node [compute-node-1] topology.kubernetes.io/zone=zone1
    Copy to Clipboard Toggle word wrap
    $ oc label node [compute-node-2] topology.kubernetes.io/zone=zone2
    Copy to Clipboard Toggle word wrap
    $ oc label node [compute-node-3] topology.kubernetes.io/zone=zone3
    Copy to Clipboard Toggle word wrap
  • 하드웨어 인벤토리에 베어 메탈 노드를 추가했는지 확인하세요.

프로세스

  1. 다음 명령을 입력하여 네임스페이스를 만듭니다.

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

    <hosted_cluster_namespace>를 호스팅된 클러스터 네임스페이스의 식별자로 바꾸세요. HyperShift 연산자는 네임스페이스를 생성합니다. 베어 메탈 인프라에서 호스팅된 클러스터를 생성하는 동안 생성된 클러스터 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. 서비스 게시 전략을 구성합니다. 기본적으로 호스팅 클러스터는 NodePort 서비스 게시 전략을 사용합니다. 이는 노드 포트가 추가 인프라 없이도 항상 사용 가능하기 때문입니다. 하지만 로드 밸런서를 사용하도록 서비스 게시 전략을 구성할 수 있습니다.

    • 기본 NodePort 전략을 사용하는 경우 관리 클러스터 노드가 아닌 호스팅된 클러스터 컴퓨팅 노드를 가리키도록 DNS를 구성합니다. 자세한 내용은 "베어 메탈의 DNS 구성"을 참조하세요.
    • 프로덕션 환경에서는 LoadBalancer 전략을 사용하세요. 이 전략은 인증서 처리와 자동 DNS 확인을 제공합니다. 다음 예제에서는 호스팅된 클러스터 구성 파일에서 서비스 게시 LoadBalancer 전략을 변경하는 방법을 보여줍니다.

      # ...
      spec:
        services:
        - service: APIServer
          servicePublishingStrategy:
            type: LoadBalancer 
      1
      
        - service: Ignition
          servicePublishingStrategy:
            type: Route
        - service: Konnectivity
          servicePublishingStrategy:
            type: Route
        - service: OAuthServer
          servicePublishingStrategy:
            type: Route
        - service: OIDC
          servicePublishingStrategy:
            type: Route
        sshKey:
          name: <ssh_key>
      # ...
      Copy to Clipboard Toggle word wrap
      1
      API 서버 유형으로 LoadBalancer를 지정합니다. 다른 모든 서비스의 경우 유형으로 경로를 지정합니다.
  4. 다음 명령을 입력하여 호스팅된 클러스터 구성 파일에 변경 사항을 적용합니다.

    $ oc apply -f hosted_cluster_config.yaml
    Copy to Clipboard Toggle word wrap
  5. 다음 명령을 입력하여 호스팅된 클러스터, 노드 풀 및 포드가 생성되었는지 확인하세요.

    $ oc get hostedcluster \
      <hosted_cluster_namespace> -n \
      <hosted_cluster_namespace> -o \
      jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .
    Copy to Clipboard Toggle word wrap
    $ oc get nodepool \
      <hosted_cluster_namespace> -n \
      <hosted_cluster_namespace> -o \
      jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .
    Copy to Clipboard Toggle word wrap
    $ oc get pods -n <hosted_cluster_namespace>
    Copy to Clipboard Toggle word wrap
  6. 호스팅된 클러스터가 준비되었는지 확인하세요. 사용 가능: True 상태는 클러스터의 준비 상태를 나타내고 노드 풀 상태는 AllMachinesReady: True를 나타냅니다. 이러한 상태는 모든 클러스터 운영자의 상태를 나타냅니다.
  7. 호스팅된 클러스터에 MetalLB를 설치하세요:

    1. 호스팅된 클러스터에서 kubeconfig 파일을 추출하고 다음 명령을 입력하여 호스팅된 클러스터 액세스를 위한 환경 변수를 설정합니다.

      $ oc get secret \
        <hosted_cluster_namespace>-admin-kubeconfig \
        -n <hosted_cluster_namespace> \
        -o jsonpath='{.data.kubeconfig}' \
        | base64 -d > \
        kubeconfig-<hosted_cluster_namespace>.yaml
      Copy to Clipboard Toggle word wrap
      $ export KUBECONFIG="/path/to/kubeconfig-<hosted_cluster_namespace>.yaml"
      Copy to Clipboard Toggle word wrap
    2. install-metallb-operator.yaml 파일을 만들어 MetalLB Operator를 설치합니다.

      apiVersion: v1
      kind: Namespace
      metadata:
        name: metallb-system
      ---
      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: metallb-operator
        namespace: metallb-system
      ---
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: metallb-operator
        namespace: metallb-system
      spec:
        channel: "stable"
        name: metallb-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
        installPlanApproval: Automatic
      # ...
      Copy to Clipboard Toggle word wrap
    3. 다음 명령을 입력하여 파일을 적용합니다.

      $ oc apply -f install-metallb-operator.yaml
      Copy to Clipboard Toggle word wrap
    4. deploy-metallb-ipaddresspool.yaml 파일을 만들어 MetalLB IP 주소 풀을 구성합니다.

      apiVersion: metallb.io/v1beta1
      kind: IPAddressPool
      metadata:
        name: metallb
        namespace: metallb-system
      spec:
        autoAssign: true
        addresses:
        - 10.11.176.71-10.11.176.75
      ---
      apiVersion: metallb.io/v1beta1
      kind: L2Advertisement
      metadata:
        name: l2advertisement
        namespace: metallb-system
      spec:
        ipAddressPools:
        - metallb
      # ...
      Copy to Clipboard Toggle word wrap
    5. 다음 명령을 입력하여 구성을 적용합니다.

      $ oc apply -f deploy-metallb-ipaddresspool.yaml
      Copy to Clipboard Toggle word wrap
    6. 다음 명령을 입력하여 운영자 상태, IP 주소 풀, L2Advertisement 리소스를 확인하여 MetalLB가 설치되었는지 확인하세요.

      $ oc get pods -n metallb-system
      Copy to Clipboard Toggle word wrap
      $ oc get ipaddresspool -n metallb-system
      Copy to Clipboard Toggle word wrap
      $ oc get l2advertisement -n metallb-system
      Copy to Clipboard Toggle word wrap
  8. 수신을 위해 로드 밸런서를 구성합니다.

    1. ingress-loadbalancer.yaml 파일을 만듭니다.

      apiVersion: v1
      kind: Service
      metadata:
        annotations:
          metallb.universe.tf/address-pool: metallb
        name: metallb-ingress
        namespace: openshift-ingress
      spec:
        ports:
          - name: http
            protocol: TCP
            port: 80
            targetPort: 80
          - name: https
            protocol: TCP
            port: 443
            targetPort: 443
        selector:
          ingresscontroller.operator.openshift.io/deployment-ingresscontroller: default
        type: LoadBalancer
      # ...
      Copy to Clipboard Toggle word wrap
    2. 다음 명령을 입력하여 구성을 적용합니다.

      $ oc apply -f ingress-loadbalancer.yaml
      Copy to Clipboard Toggle word wrap
    3. 다음 명령을 입력하여 로드 밸런서 서비스가 예상대로 작동하는지 확인하세요.

      $ oc get svc metallb-ingress -n openshift-ingress
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME              TYPE           CLUSTER-IP       EXTERNAL-IP    PORT(S)                      AGE
      metallb-ingress   LoadBalancer   172.31.127.129   10.11.176.71   80:30961/TCP,443:32090/TCP   16h
      Copy to Clipboard Toggle word wrap

  9. 로드 밸런서와 함께 작동하도록 DNS를 구성합니다.

    1. *.apps.<hosted_cluster_namespace>.<base_domain> 와일드카드 DNS 레코드를 로드 밸런서 IP 주소로 가리켜 도메인에 대한 DNS를 구성합니다.
    2. 다음 명령을 입력하여 DNS 확인을 확인하세요.

      $ nslookup console-openshift-console.apps.<hosted_cluster_namespace>.<base_domain> <load_balancer_ip_address>
      Copy to Clipboard Toggle word wrap

      출력 예

      Server:         10.11.176.1
      Address:        10.11.176.1#53
      
      Name:   console-openshift-console.apps.my-hosted-cluster.sample-base-domain.com
      Address: 10.11.176.71
      Copy to Clipboard Toggle word wrap

검증

  1. 다음 명령을 입력하여 클러스터 운영자를 확인하세요.

    $ oc get clusteroperators
    Copy to Clipboard Toggle word wrap

    모든 연산자가 AVAILABLE: True , PROGRESSING: False , DEGRADED: False로 표시되는지 확인하세요.

  2. 다음 명령을 입력하여 노드를 확인하세요.

    $ oc get nodes
    Copy to Clipboard Toggle word wrap

    각 노드가 READY 상태인지 확인하세요.

  3. 웹 브라우저에 다음 URL을 입력하여 콘솔에 대한 액세스를 테스트하세요.

    https://console-openshift-console.apps.<hosted_cluster_namespace>.<base_domain>
    Copy to Clipboard Toggle word wrap

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 머신이 에이전트로 결합할 수 있는 initrd.img,kernel.img, rootfs.img 와 같은 PXE 이미지를 다운로드하여 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의 논리 파티션(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>:<hostname>::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를 사용하여 Red Hat Enterprise Linux CoreOS(RHCOS)를 설치할 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. 다음 명령을 실행하여 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를 사용하려면 z/VM 에이전트에 대한 NMStateConfig 속성을 구성하여 두 번째 시작 시 IP 매개변수가 유지되도록 해야 합니다.

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>:<hostname>::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를 사용하여 Red Hat Enterprise Linux CoreOS(RHCOS)를 설치할 DASD를 지정합니다. FCP 유형 디스크에 설치하는 경우 rd.zfcp=<adapter>,<wwpn>,<lun>을 사용하여 RHCOS를 설치할 FCP 디스크를 지정합니다.
    참고

    FCP 다중 경로 구성의 경우 1개 대신 2개의 디스크를 제공하세요.

    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 객체를 확장하면 호스팅된 제어 평면에 더 많은 컴퓨팅 노드를 추가할 수 있습니다.

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

프로세스

  1. 다음 명령을 실행하여 NodePool 객체를 두 개의 노드로 확장합니다.

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

    클러스터 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. 에이전트가 기존 클러스터에 추가됨 상태에 도달하면 다음 명령을 입력하여 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

    클러스터 운영자는 노드에 작업 부하를 추가하여 조정을 시작합니다.

  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. 클러스터 운영자 상태를 확인하려면 다음 명령을 실행하세요.

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

클러스터의 각 구성 요소에 대해 출력에는 다음과 같은 클러스터 운영자 상태가 표시됩니다. NAME , VERSION , AVAILABLE , PROGRESSING , DEGRADED , SINCE , MESSAGE .

출력 예는 초기 연산자 구성을 참조하세요.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2025 Red Hat