에이전트 기반 설치 관리자를 사용하여 온프레미스 클러스터 설치


OpenShift Container Platform 4.12

에이전트 기반 설치 관리자를 사용하여 온프레미스 OpenShift Container Platform 클러스터 설치

Red Hat OpenShift Documentation Team

초록

이 문서에서는 에이전트 기반 설치 관리자를 사용하여 온프레미스 OpenShift Container Platform 클러스터를 설치하는 방법을 설명합니다.

1장. 에이전트 기반 설치 관리자를 사용하여 설치 준비

1.1. 에이전트 기반 설치 관리자 정보

에이전트 기반 설치 방법은 원하는 방식으로 온-프레미스 서버를 부팅할 수 있는 유연성을 제공합니다.The Agent-based installation method provides the flexibility to boot your on-premises servers in any way that you choose. 지원 설치 서비스를 쉽게 사용할 수 있는 기능과 Air-gapped 환경을 포함하여 오프라인으로 실행할 수 있는 기능을 결합합니다. 에이전트 기반 설치는 OpenShift Container Platform 설치 프로그램의 하위 명령입니다. 사용 가능한 릴리스 이미지와 함께 OpenShift Container Platform 클러스터를 배포하는 데 필요한 모든 정보가 포함된 부팅 가능한 ISO 이미지를 생성합니다.

구성은 설치 관리자 프로비저닝 인프라 및 사용자 프로비저닝 인프라 설치 방법과 동일한 형식으로 되어 있습니다. 에이전트 기반 설치 관리자는 선택적으로 ZTP(Zero Touch Provisioning) 사용자 지정 리소스를 생성하거나 허용할 수 있습니다. ZTP를 사용하면 베어 메탈 장비의 선언적 구성으로 새로운 에지 사이트를 프로비저닝할 수 있습니다.

1.2. 에이전트 기반 설치 관리자 이해

OpenShift Container Platform 사용자는 연결이 끊긴 환경에서 지원 설치 관리자 호스팅 서비스의 이점을 활용할 수 있습니다.

에이전트 기반 설치는 지원 검색 에이전트와 지원 서비스가 포함된 부팅 가능한 ISO로 구성됩니다. 둘 다 클러스터 설치를 수행하는 데 필요하지만 두 번째는 호스트 중 하나에서만 실행됩니다.

openshift-install agent create image 하위 명령은 사용자가 제공하는 입력을 기반으로 임시 ISO를 생성합니다. 다음 매니페스트를 통해 입력을 제공하도록 선택할 수 있습니다.

기본 설정:

  • install-config.yaml
  • agent-config.yaml

또는

선택 사항: ZTP 매니페스트

  • cluster-manifests/cluster-deployment.yaml
  • cluster-manifests/agent-cluster-install.yaml
  • cluster-manifests/pull-secret.yaml
  • cluster-manifests/infraenv.yaml
  • cluster-manifests/cluster-image-set.yaml
  • cluster-manifests/nmstateconfig.yaml
  • mirror/registries.conf
  • mirror/ca-bundle.crt

1.2.1. 에이전트 기반 설치 프로그램 워크플로

컨트롤 플레인 호스트 중 하나는 부팅 프로세스 시작 시 지원 서비스를 실행하고 결국 부트스트랩 호스트가 됩니다. 이 노드를 rendezvous host (node 0)라고 합니다. 지원 서비스를 사용하면 모든 호스트가 요구 사항을 충족하고 OpenShift Container Platform 클러스터 배포를 트리거합니다. 모든 노드에는 디스크에 기록된 RHCOS(Red Hat Enterprise Linux CoreOS) 이미지가 있습니다. 부트스트랩이 아닌 노드가 재부팅되고 클러스터 배포를 시작합니다. 노드가 재부팅되면 rendezvous 호스트가 재부팅되고 클러스터에 참여합니다. 부트스트랩이 완료되고 클러스터가 배포됩니다.

그림 1.1. 노드 설치 워크플로

에이전트 기반 설치 프로그램 워크플로

openshift-install agent create image 하위 명령을 통해 다음 토폴로지에 대해 연결이 끊긴 OpenShift Container Platform 클러스터를 설치할 수 있습니다.

  • 단일 노드 OpenShift Container Platform 클러스터(SNO): 마스터와 작업자 둘 다인 노드입니다.
  • 3-노드 OpenShift Container Platform 클러스터 : 작업자 노드이기도 하는 마스터 노드가 3개인 컴팩트 클러스터입니다.
  • 고가용성 OpenShift Container Platform 클러스터(HA): 여러 개의 작업자 노드가 있는 마스터 노드 3개

1.3. FIPS 컴플라이언스 정보

많은 OpenShift Container Platform 고객은 시스템을 프로덕션 환경에 도입하기 전에 일정 수준의 규제 준비 또는 컴플라이언스를 갖춰야 합니다. 이러한 규정 준비는 국가 표준, 산업 표준 또는 조직의 기업 거버넌스 프레임워크에 따라 규정될 수 있습니다. FIPS(Federal Information Processing Standards) 규정 준수는 노드에서 지원되는 암호화 기술만 허용되도록 매우 안전한 환경에서 필요한 가장 중요한 구성 요소 중 하나입니다.

중요

클러스터의 FIPS 모드를 활성화하려면 FIPS 모드에서 작동하도록 구성된 RHEL(Red Hat Enterprise Linux) 컴퓨터에서 설치 프로그램을 실행해야 합니다. RHEL에서 FIPS 모드 구성에 대한 자세한 내용은 FIPS 모드에서 시스템 설치를 참조하십시오. FIPS 검증 또는 모듈 In Process 암호화 라이브러리 사용은 x86_64,ppc64les390x 아키텍처의 OpenShift Container Platform 배포에서 지원됩니다.

1.4. 에이전트 기반 설치 관리자를 통한 FIPS 구성

클러스터 배포 중에 RHCOS(Red Hat Enterprise Linux CoreOS) 시스템이 클러스터에 배포될 때 FIPS(Federal Information Processing Standards) 변경 사항이 적용됩니다. RHEL(Red Hat Enterprise Linux) 머신의 경우 작업자 시스템으로 사용하려는 시스템에 운영 체제를 설치할 때 FIPS 모드를 활성화해야 합니다.

install-config.yamlagent-config.yaml 의 기본 방법을 통해 FIPS 모드를 활성화할 수 있습니다.

  1. install-config.yaml 파일에서 fips 필드의 값을 True 로 설정해야 합니다.

    샘플 install-config.yaml.file

    apiVersion: v1
    baseDomain: test.example.com
    metadata:
      name: sno-cluster
    fips: True

  2. 선택 사항: ZTP 매니페스트를 사용하는 경우 agent-cluster-install.yaml 파일의 Agent-install.openshift.io/install-config-overrides 필드에서 fips 값을 True 로 설정해야 합니다.

    agent-cluster-install.yaml 파일 샘플

    apiVersion: extensions.hive.openshift.io/v1beta1
    kind: AgentClusterInstall
    metadata:
      annotations:
        agent-install.openshift.io/install-config-overrides: '{"fips": True}'
      name: sno-cluster
      namespace: sno-cluster-test

1.5. 네트워킹 정보

초기 부팅 중에 모든 호스트가 지원 서비스를 확인할 수 있도록 에이전트 ISO를 생성할 때 ndezvous IP 를 알고 있어야 합니다. DHCP(Dynamic Host Configuration Protocol) 서버를 사용하여 IP 주소를 할당하는 경우 배포된 컨트롤 플레인의 일부가 될 호스트 중 하나의 IP 주소로 rendezvousIP 필드를 설정해야 합니다. DHCP 서버가 없는 환경에서는 IP 주소를 정적으로 정의할 수 있습니다.

고정 IP 주소 외에도 NMState 형식의 모든 네트워크 구성을 적용할 수 있습니다. 여기에는 VLAN 및 NIC 본딩이 포함됩니다.

1.5.1. DHCP

기본 방법: install-config.yamlagent-config.yaml

rendezvousIP 필드의 값을 지정해야 합니다. networkConfig 필드를 비워 둘 수 있습니다.

agent-config.yaml.file 샘플

apiVersion: v1alpha1
kind: AgentConfig
metadata:
  name: sno-cluster
rendezvousIP: 192.168.111.80 
1

1
rendezvous 호스트의 IP 주소입니다.

1.5.2. 정적 네트워킹

  1. 기본 방법: install-config.yamlagent-config.yaml

    agent-config.yaml.file 샘플

      cat > agent-config.yaml << EOF
      apiVersion: v1alpha1
      kind: AgentConfig
      metadata:
        name: sno-cluster
      rendezvousIP: 192.168.111.80 
    1
    
      hosts:
        - hostname: master-0
          interfaces:
            - name: eno1
              macAddress: 00:ef:44:21:e6:a5 
    2
    
          networkConfig:
            interfaces:
              - name: eno1
                type: ethernet
                state: up
                mac-address: 00:ef:44:21:e6:a5
                ipv4:
                  enabled: true
                  address:
                    - ip: 192.168.111.80 
    3
    
                      prefix-length: 23 
    4
    
                  dhcp: false
            dns-resolver:
              config:
                server:
                  - 192.168.111.1 
    5
    
            routes:
              config:
                - destination: 0.0.0.0/0
                  next-hop-address: 192.168.111.1 
    6
    
                  next-hop-interface: eno1
                  table-id: 254
      EOF

    1
    rendezvousIP 필드에 값을 지정하지 않으면 networkConfig 필드에 지정된 고정 IP 주소에서 하나의 주소가 선택됩니다.
    2
    호스트에 있는 인터페이스의 MAC 주소로, 구성을 적용할 호스트를 결정하는 데 사용됩니다.
    3
    대상 베어 메탈 호스트의 고정 IP 주소입니다.
    4
    대상 베어 메탈 호스트의 고정 IP 주소의 서브넷 접두사입니다.
    5
    대상 베어 메탈 호스트의 DNS 서버입니다.
    6
    노드 트래픽의 다음 홉 주소입니다. 지정된 인터페이스에 설정된 IP 주소와 동일한 서브넷에 있어야 합니다.
  2. 선택적 방법: ZTP 매니페스트

    ZTP 사용자 정의 리소스의 선택적 방법은 6개의 사용자 지정 리소스로 구성됩니다. nmstateconfig.yaml 파일에서 고정 IP를 구성할 수 있습니다.

    apiVersion: agent-install.openshift.io/v1beta1
    kind: NMStateConfig
    metadata:
      name: master-0
      namespace: openshift-machine-api
      labels:
        cluster0-nmstate-label-name: cluster0-nmstate-label-value
    spec:
      config:
        interfaces:
          - name: eth0
            type: ethernet
            state: up
            mac-address: 52:54:01:aa:aa:a1
            ipv4:
              enabled: true
              address:
                - ip: 192.168.122.2 
    1
    
                  prefix-length: 23 
    2
    
              dhcp: false
        dns-resolver:
          config:
            server:
              - 192.168.122.1 
    3
    
        routes:
          config:
            - destination: 0.0.0.0/0
              next-hop-address: 192.168.122.1 
    4
    
              next-hop-interface: eth0
              table-id: 254
      interfaces:
        - name: eth0
          macAddress: 52:54:01:aa:aa:a1 
    5
    1
    대상 베어 메탈 호스트의 고정 IP 주소입니다.
    2
    대상 베어 메탈 호스트의 고정 IP 주소의 서브넷 접두사입니다.
    3
    대상 베어 메탈 호스트의 DNS 서버입니다.
    4
    노드 트래픽의 다음 홉 주소입니다. 지정된 인터페이스에 설정된 IP 주소와 동일한 서브넷에 있어야 합니다.
    5
    호스트에 있는 인터페이스의 MAC 주소로, 구성을 적용할 호스트를 결정하는 데 사용됩니다.

rendezvous IP는 config 필드에 지정된 고정 IP 주소에서 선택됩니다.

1.6. 예: Bonds 및 VLAN 인터페이스 노드 네트워크 구성

다음 agent-config.yaml 파일은 본딩 및 VLAN 인터페이스에 대한 매니페스트의 예입니다.

  apiVersion: v1alpha1
  kind: AgentConfig
  rendezvousIP: 10.10.10.14
  hosts:
    - hostname: master0
      role: master
      interfaces:
       - name: enp0s4
         macAddress: 00:21:50:90:c0:10
       - name: enp0s5
         macAddress: 00:21:50:90:c0:20
      networkConfig:
        interfaces:
          - name: bond0.300 
1

            type: vlan 
2

            state: up
            vlan:
              base-iface: bond0
              id: 300
            ipv4:
              enabled: true
              address:
                - ip: 10.10.10.14
                  prefix-length: 24
              dhcp: false
          - name: bond0 
3

            type: bond 
4

            state: up
            mac-address: 00:21:50:90:c0:10 
5

            ipv4:
              enabled: false
            ipv6:
              enabled: false
            link-aggregation:
              mode: active-backup 
6

              options:
                miimon: "150" 
7

              port:
               - enp0s4
               - enp0s5
        dns-resolver: 
8

          config:
            server:
              - 10.10.10.11
              - 10.10.10.12
        routes:
          config:
            - destination: 0.0.0.0/0
              next-hop-address: 10.10.10.10 
9

              next-hop-interface: bond0.300 
10

              table-id: 254
1 3
인터페이스 이름입니다.
2
인터페이스 유형입니다. 이 예제에서는 VLAN을 만듭니다.
4
인터페이스 유형입니다. 이 예제에서는 본딩을 생성합니다.
5
인터페이스의 mac 주소입니다.
6
mode 속성은 본딩 모드를 지정합니다.
7
MII 링크 모니터링 빈도를 밀리초 단위로 지정합니다. 이 예제에서는 150 밀리초마다 본딩 링크를 검사합니다.
8
선택 사항: DNS 서버의 검색 및 서버 설정을 지정합니다.
9
노드 트래픽의 다음 홉 주소입니다. 지정된 인터페이스에 설정된 IP 주소와 동일한 서브넷에 있어야 합니다.
10
노드 트래픽을 위한 다음 홉 인터페이스입니다.

1.7. 베어 메탈의 샘플 install-config.yaml 파일

install-config.yaml 파일을 사용자 지정하여 OpenShift Container Platform 클러스터 플랫폼에 대한 자세한 정보를 지정하거나 필수 매개변수 값을 수정할 수 있습니다.

apiVersion: v1
baseDomain: example.com 
1

compute: 
2

- name: worker
  replicas: 0 
3

controlPlane: 
4

  name: master
  replicas: 1 
5

metadata:
  name: sno-cluster 
6

networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14 
7

    hostPrefix: 23 
8

  networkType: OVNKubernetes 
9

  serviceNetwork: 
10

  - 172.30.0.0/16
platform:
  none: {} 
11

fips: false 
12

pullSecret: '{"auths": ...}' 
13

sshKey: 'ssh-ed25519 AAAA...' 
14
1
클러스터의 기본 도메인입니다. 모든 DNS 레코드는 이 기본 도메인의 하위 도메인이어야 하며 클러스터 이름을 포함해야 합니다.
2 4
controlPlane 섹션은 단일 매핑이지만 compute 섹션은 일련의 매핑입니다. 서로 다른 데이터 구조의 요구사항을 충족하도록 compute 섹션의 첫 번째 줄은 하이픈(-)으로 시작해야 하며 controlPlane 섹션의 첫 번째 줄은 하이픈으로 시작할 수 없습니다. 하나의 컨트롤 플레인 풀만 사용됩니다.
3
이 매개 변수는 설치 프로세스를 트리거하기 전에 에이전트 기반 설치가 검색 대기하는 컴퓨팅 시스템 수를 제어합니다. 생성된 ISO로 부팅해야 하는 컴퓨팅 머신 수입니다.
참고

3-노드 클러스터를 설치하는 경우 RHCOS(Red Hat Enterprise Linux CoreOS) 시스템을 설치할 때 컴퓨팅 머신을 배포하지 마십시오.

5
클러스터에 추가하는 컨트롤 플레인 시스템의 수입니다. 클러스터에서 이 값을 클러스터의 etcd 끝점 수로 사용하므로 이 값은 배포하는 컨트롤 플레인 시스템의 수와 일치해야 합니다.
6
DNS 레코드에 지정한 클러스터 이름입니다.
7
Pod IP 주소가 할당되는 IP 주소 블록입니다. 이 블록은 기존 물리적 네트워크와 중복되지 않아야합니다. 이러한 IP 주소는 Pod 네트워크에 사용됩니다. 외부 네트워크에서 Pod에 액세스해야 하는 경우, 트래픽을 관리하도록 로드 밸런서와 라우터를 설정해야 합니다.
참고

클래스 E CIDR 범위는 향후 사용을 위해 예약되어 있습니다. 클래스 E CIDR 범위를 사용하려면 네트워킹 환경에서 클래스 E CIDR 범위 내의 IP 주소를 수락해야 합니다.

8
개별 노드 각각에 할당할 서브넷 접두사 길이입니다. 예를 들어 hostPrefix23으로 설정하면 지정된 cidr 이외 /23 서브넷이 각 노드에 할당되어 510(2^(32 - 23) - 2) Pod IP 주소가 허용됩니다. 외부 네트워크에서 노드에 액세스해야 하는 경우 트래픽을 관리하도록 로드 밸런서와 라우터를 구성합니다.
9
설치할 클러스터 네트워크 플러그인입니다. 지원되는 값은 OVNKubernetes (기본값) 및 OpenShiftSDN 입니다.
10
서비스 IP 주소에 사용할 IP 주소 풀입니다. IP 주소 풀은 하나만 입력할 수 있습니다. 이 블록은 기존 물리적 네트워크와 중복되지 않아야합니다. 외부 네트워크에서 서비스에 액세스해야 하는 경우, 트래픽을 관리하도록 로드 밸런서와 라우터를 구성합니다.
11
단일 노드 클러스터에 대해 플랫폼을 none 으로 설정해야 합니다. 다중 노드 클러스터의 경우 플랫폼을 vsphere 또는 baremetal 로 설정할 수 있습니다.
참고

플랫폼을 vsphere 또는 baremetal 로 설정하면 다음 세 가지 방법으로 클러스터 노드의 IP 주소 끝점을 구성할 수 있습니다.

  • IPv4
  • IPv6
  • IPv4 및 IPv6 병렬(dual-stack)

듀얼 스택 네트워킹의 예

networking:
  clusterNetwork:
    - cidr: 172.21.0.0/16
      hostPrefix: 23
    - cidr: fd02::/48
      hostPrefix: 64
  machineNetwork:
    - cidr: 192.168.11.0/16
    - cidr: 2001:DB8::/32
  serviceNetwork:
    - 172.22.0.0/16
    - fd03::/112
  networkType: OVNKubernetes
platform:
  baremetal:
    apiVIPs:
    - 192.168.11.3
    - 2001:DB8::4
    ingressVIPs:
    - 192.168.11.4
    - 2001:DB8::5

12
FIPS 모드 활성화 또는 비활성화 여부입니다. 기본적으로 FIPS 모드는 비활성화됩니다. FIPS 모드가 활성화되면 OpenShift Container Platform이 실행되는 RHCOS(Red Hat Enterprise Linux CoreOS) 시스템에서 기본 Kubernetes 암호화 제품군은 우회하고 RHCOS와 함께 제공되는 암호화 모듈을 대신 사용합니다.
중요

FIPS 검증 또는 모듈 In Process 암호화 라이브러리 사용은 x86_64,ppc64les390x 아키텍처의 OpenShift Container Platform 배포에서만 지원됩니다.

13
이 풀 시크릿을 사용하면 OpenShift Container Platform 구성 요소에 대한 컨테이너 이미지를 제공하는 Quay.io를 포함하여 인증 기관에서 제공하는 서비스로 인증할 수 있습니다.
14
RHCOS(Red Hat Enterprise Linux CoreOS)의 core 사용자에 대한 SSH 공용 키입니다.
참고

설치 디버깅 또는 재해 복구를 수행하려는 프로덕션 OpenShift Container Platform 클러스터의 경우 ssh-agent 프로세스가 사용하는 SSH 키를 지정합니다.

1.8. 에이전트 ISO 생성 전 검증

에이전트 기반 설치 관리자는 ISO를 생성하기 전에 사용자 정의 YAML 파일에서 유효성 검사를 수행합니다. 검증에 성공하면 에이전트 ISO가 생성됩니다.

install-config.yaml

  • baremetal,vspherenone 플랫폼은 지원되지 않습니다.
  • 플랫폼으로 사용되지 않는 경우 컨트롤 플레인 복제본 수는 1 이고 총 작업자 복제본 수는 0 이어야 합니다.
  • networkType 매개변수는 플랫폼이 없는 경우 OVNKubernetes 여야 합니다.
  • 베어 메탈 및 vSphere 플랫폼에 대해 apiVIPsingressVIPs 매개변수를 설정해야 합니다.
  • agent-config.yaml 파일에 해당하는 베어 메탈 플랫폼 구성의 일부 호스트별 필드는 무시됩니다. 이러한 필드가 설정된 경우 경고 메시지가 기록됩니다.

agent-config.yaml

  • 각 인터페이스에는 정의된 MAC 주소가 있어야 합니다. 또한 모든 인터페이스에 다른 MAC 주소가 있어야 합니다.
  • 각 호스트에 대해 하나 이상의 인터페이스를 정의해야 합니다.
  • WWN(World Wide Name) 벤더 확장은 루트 장치 팁에서 지원되지 않습니다.
  • host 오브젝트의 role 매개변수에는 master 또는 worker 값이 있어야 합니다.

1.8.1. ZTP 매니페스트

agent-cluster-install.yaml

  • IPv6의 경우 networkType 매개변수에 지원되는 유일한 값은 OVNKubernetes 입니다. OpenshiftSDN 값은 IPv4에만 사용할 수 있습니다.

cluster-image-set.yaml

  • ReleaseImage 매개변수는 설치 프로그램에 정의된 릴리스와 일치해야 합니다.

1.9. 루트 장치 팁 정보

rootDeviceHints 매개 변수를 사용하면 설치 프로그램이 RHCOS (Red Hat Enterprise Linux CoreOS) 이미지를 특정 장치에 프로비저닝할 수 있습니다. 설치 프로그램은 장치를 검색한 순서대로 검사하고 검색된 값을 팁과 비교합니다. 설치 프로그램은 팁과 일치하는 첫 번째 검색된 장치를 사용합니다. 이 설정은 여러 팁을 결합할 수 있지만 장치는 설치 프로그램이이를 선택할 수 있도록 모든 팁과 일치해야 합니다.

Expand
표 1.2. 서브 필드
서브 필드설명

deviceName

/dev/vda와 같은 Linux 장치 이름을 포함하는 문자열. 팁은 실제 값과 정확히 일치해야 합니다.

hctl

0:0:0:0과 같은 SCSI 버스 주소를 포함하는 문자열. 팁은 실제 값과 정확히 일치해야 합니다.

model

공급 업체별 장치 식별자가 포함된 문자열. 팁은 실제 값의 하위 문자열입니다.

vendor

장치의 공급 업체 또는 제조업체 이름이 포함된 문자열입니다. 팁은 실제 값의 하위 문자열입니다.

serialNumber

장치 일련 번호가 포함된 문자열입니다. 팁은 실제 값과 정확히 일치해야 합니다.

minSizeGigabytes

장치의 최소 크기 (기가 바이트)를 나타내는 정수입니다.

wwn

고유 저장소 식별자를 포함하는 문자열입니다. 팁은 실제 값과 정확히 일치해야 합니다. udevadm 명령을 사용하여 wwn 값을 검색하고 명령이 ID_WWN_WITH_EXTENSION 의 값을 출력하는 경우 이 값을 사용하여 wwn 하위 필드를 지정해야 합니다.

rotational

장치가 회전 디스크 여야하는지 (true) 아닌지 (false)를 나타내는 부울 값입니다.

사용 예

     - name: master-0
       role: master
       rootDeviceHints:
         deviceName: "/dev/sda"

1.10. 다음 단계

2장. 연결 해제된 설치 미러링 이해

연결이 끊긴 설치에는 미러 레지스트리를 사용하고 클러스터가 외부 콘텐츠에 대한 조직의 제어를 충족하는 컨테이너 이미지만 사용하도록 할 수 있습니다. 연결이 끊긴 환경에서 프로비저닝하는 인프라에 클러스터를 설치하기 전에 필요한 컨테이너 이미지를 해당 환경에 미러링해야 합니다. 컨테이너 이미지를 미러링하려면 미러링을 위한 레지스트리가 있어야 합니다.

다음 절차 중 하나를 사용하여 OpenShift Container Platform 이미지 저장소를 미러 레지스트리에 미러링할 수 있습니다.

에이전트 기반 설치 관리자를 사용하여 연결이 끊긴 설치에 미러 이미지를 사용하려면 install-config.yaml 파일을 수정해야 합니다.

oc adm release mirror 또는 oc mirror 명령의 출력을 사용하여 릴리스 이미지를 미러링할 수 있습니다. 이는 미러 레지스트리를 설정하는 데 사용한 명령에 따라 달라집니다.

다음 예제에서는 oc adm release mirror 명령의 출력을 보여줍니다.

$ oc adm release mirror

출력 예

To use the new mirrored repository to install, add the following
section to the install-config.yaml:

imageContentSources:

mirrors:
virthost.ostest.test.metalkube.org:5000/localimages/local-release-image
source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
mirrors:
virthost.ostest.test.metalkube.org:5000/localimages/local-release-image
source: registry.ci.openshift.org/ocp/release

다음 예제는 oc-mirror 플러그인에서 생성한 imageContentSourcePolicy.yaml 파일의 일부를 보여줍니다. 파일은 결과 디렉터리(예: oc-mirror-workspace/results-1682697932/ )에서 찾을 수 있습니다.

Example imageContentSourcePolicy.yaml file

spec:
  repositoryDigestMirrors:
  - mirrors:
    - virthost.ostest.test.metalkube.org:5000/openshift/release
    source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
  - mirrors:
    - virthost.ostest.test.metalkube.org:5000/openshift/release-images
    source: quay.io/openshift-release-dev/ocp-release

미러링된 이미지를 사용하도록 에이전트 기반 설치 관리자를 구성하려면 oc adm release mirror 명령 또는 oc-mirror 플러그인의 출력을 사용해야 합니다.

프로세스

  1. oc-mirror 플러그인을 사용하여 릴리스 이미지를 미러링한 경우 다음을 수행합니다.

    1. 결과 디렉터리에 있는 imageContentSourcePolicy.yaml 을 엽니다(예: oc-mirror-workspace/results-1682697932/ ).
    2. yaml 파일의 repositoryDigestMirrors 섹션에 텍스트를 복사합니다.
  2. oc adm release mirror 명령을 사용하여 릴리스 이미지를 미러링한 경우 다음을 수행합니다.

    • 명령 출력의 imageContentSources 섹션에 텍스트를 복사합니다.
  3. 복사된 텍스트를 install-config.yaml 파일의 imageContentSources 필드에 붙여넣습니다.
  4. 미러 레지스트리에 사용된 인증서 파일을 yaml 파일의 additionalTrustBundle 필드에 추가합니다.

    중요

    값은 미러 레지스트리에 사용한 인증서 파일의 내용이어야 합니다. 인증서 파일은 신뢰할 수 있는 기존 인증 기관 또는 미러 레지스트리에 대해 생성한 자체 서명 인증서일 수 있습니다.

    install-config.yaml 파일 예

      additionalTrustBundle: |
        -----BEGIN CERTIFICATE-----
        ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
        -----END CERTIFICATE-----

  5. {ztp} manifests를 사용하는 경우: registries.confca-bundle.crt 파일을 미러 경로에 추가하여 에이전트 ISO 이미지에 미러 구성을 추가합니다.

    참고

    oc adm release mirror 명령 또는 oc mirror 플러그인의 출력에서 registries.conf 파일을 생성할 수 있습니다. /etc/containers/registries.conf 파일의 형식이 변경되었습니다. 현재 버전은 TOML 형식의 버전 2입니다.

    registries.conf 파일 예

    [[registry]]
    location = "registry.ci.openshift.org/ocp/release" mirror-by-digest-only = true
    
    [[registry.mirror]] location = "virthost.ostest.test.metalkube.org:5000/localimages/local-release-image"
    
    [[registry]]
    location = "quay.io/openshift-release-dev/ocp-v4.0-art-dev" mirror-by-digest-only = true
    
    [[registry.mirror]] location = "virthost.ostest.test.metalkube.org:5000/localimages/local-release-image"

3.1. 사전 요구 사항

다음 절차에서는 연결이 끊긴 환경에 단일 노드 OpenShift Container Platform을 배포합니다. 이 절차를 기반으로 사용하고 요구 사항에 따라 수정할 수 있습니다.

절차

  1. 로그인 인증 정보를 사용하여 OpenShift Container Platform 웹 콘솔에 로그인합니다.
  2. Datacenter 로 이동합니다.

    에이전트 설치
  3. 로컬 에서 에이전트 기반 설치 관리자 실행을 클릭합니다. 에이전트 페이지를 사용하여 베어 메탈에 OpenShift Container Platform을 로컬로 설치합니다.
  4. 선택 사항: 또는 Select an OpenShift Container Platform 클러스터 유형에서 Bare Metal (x86_64) 을 클릭하여 페이지를 생성할 수도 있습니다. OpenShift Container Platform 클러스터 생성: 베어 메탈 페이지로 이동합니다. 그런 다음 로컬 에이전트 기반 을 선택하여 에이전트 페이지를 사용하여 로컬로 베어 메탈에 OpenShift Container Platform 설치 로 이동합니다.

    에이전트 설치 베어 메탈
  5. 운영 체제 및 아키텍처를 선택합니다.
  6. 설치 프로그램 다운로드를 클릭하여 설치 프로그램을 다운로드하고 추출합니다.
  7. 풀 시크릿 다운로드를 클릭하거나 풀 시크릿 복사를 클릭하여 풀 시크릿을 다운로드하거나 복사할 수 있습니다.
  8. 명령행 툴 다운로드를 클릭하고 openshift-install 바이너리를 PATH 에 있는 디렉터리에 배치합니다.
  9. 다음 명령을 실행하여 nmstate 종속성을 설치합니다.

    $ sudo dnf install /usr/bin/nmstatectl -y
  10. openshift-install 바이너리를 PATH에 있는 디렉터리에 배치합니다.
  11. 다음 명령을 실행하여 설치 구성을 저장할 디렉터리를 생성합니다.

    $ mkdir ~/<directory_name>
    참고

    에이전트 기반 설치에 권장되는 방법입니다. ZTP 매니페스트 사용은 선택 사항입니다.

  12. install-config.yaml 파일을 생성합니다.

    $ cat << EOF > ./my-cluster/install-config.yaml
    apiVersion: v1
    baseDomain: test.example.com
    compute:
    - architecture: amd64
      hyperthreading: Enabled
      name: worker
      replicas: 0
    controlPlane:
      architecture: amd64
      hyperthreading: Enabled
      name: master
      replicas: 1
    metadata:
      name: sno-cluster 
    1
    
    networking:
      clusterNetwork:
      - cidr: 10.128.0.0/14
        hostPrefix: 23
      machineNetwork:
      - cidr: 192.168.111.0/16
      networkType: OVNKubernetes 
    2
    
      serviceNetwork:
      - 172.30.0.0/16
    platform:
      none: {}
    pullSecret: '<pull_secret>' 
    3
    
    sshKey: |
      <ssh_pub_key> 
    4
    
      EOF
    1
    필수 항목입니다.
    2
    설치할 클러스터 네트워크 플러그인입니다. 지원되는 값은 OVNKubernetesOpenShiftSDN 입니다. 기본값은 OVNKubernetes 입니다.
    3
    풀 시크릿을 입력합니다.
    4
    ssh 공개 키를 입력합니다.
    참고

    플랫폼을 vSphere 또는 baremetal 로 설정하면 다음 세 가지 방법으로 클러스터 노드의 IP 주소 끝점을 구성할 수 있습니다.

    • IPv4
    • IPv6
    • IPv4 및 IPv6 병렬(dual-stack)

    듀얼 스택 네트워킹의 예

    networking:
      clusterNetwork:
        - cidr: 172.21.0.0/16
          hostPrefix: 23
        - cidr: fd02::/48
          hostPrefix: 64
      machineNetwork:
        - cidr: 192.168.11.0/16
        - cidr: 2001:DB8::/32
      serviceNetwork:
        - 172.22.0.0/16
        - fd03::/112
      networkType: OVNKubernetes
    platform:
      baremetal:
        apiVIPs:
        - 192.168.11.3
        - 2001:DB8::4
        ingressVIPs:
        - 192.168.11.4
        - 2001:DB8::5

    IPv6는 베어 메탈 플랫폼에서만 지원됩니다.

  13. agent-config.yaml 파일을 생성합니다.

    $ cat > agent-config.yaml << EOF
    apiVersion: v1alpha1
    kind: AgentConfig
    metadata:
      name: sno-cluster
    rendezvousIP: 192.168.111.80 
    1
    
    hosts: 
    2
    
      - hostname: master-0 
    3
    
        interfaces:
          - name: eno1
            macAddress: 00:ef:44:21:e6:a5
        rootDeviceHints: 
    4
    
          deviceName: /dev/sdb
        networkConfig: 
    5
    
          interfaces:
            - name: eno1
              type: ethernet
              state: up
              mac-address: 00:ef:44:21:e6:a5
              ipv4:
                enabled: true
                address:
                  - ip: 192.168.111.80
                    prefix-length: 23
                dhcp: false
          dns-resolver:
            config:
              server:
                - 192.168.111.1
          routes:
            config:
              - destination: 0.0.0.0/0
                next-hop-address: 192.168.111.2
                next-hop-interface: eno1
                table-id: 254
      EOF
    1
    이 IP 주소는 부트스트랩 프로세스를 수행하고 assisted-service 구성 요소를 실행하는 노드를 결정하는 데 사용됩니다. networkConfig 매개변수에 하나 이상의 호스트의 IP 주소를 지정하지 않는 경우 rendezvous IP 주소를 제공해야 합니다. 이 주소를 제공하지 않으면 제공된 호스트의 networkConfig 에서 하나의 IP 주소가 선택됩니다.
    2
    호스트 구성은 선택 사항입니다. 정의된 호스트 수는 compute.replicascontrolPlane.replicas 매개변수 값의 합계인 install-config.yaml 파일에 정의된 총 호스트 수를 초과해서는 안 됩니다.
    3
    선택적 hostname 매개변수는 DHCP(Dynamic Host Configuration Protocol) 또는 역방향 DNS 조회에서 가져온 호스트 이름을 재정의합니다. 각 호스트에는 이러한 방법 중 하나에서 제공하는 고유한 호스트 이름이 있어야 합니다.
    4
    rootDeviceHints 매개변수를 사용하면 RHCOS(Red Hat Enterprise Linux CoreOS) 이미지를 특정 장치에 프로비저닝할 수 있습니다. 장치를 검색한 순서대로 검사하고 검색된 값을 팁 값과 비교합니다. 힌트 값과 일치하는 첫 번째 검색된 장치를 사용합니다.
    5
    이 선택적 매개 변수를 설정하여 NMState 형식으로 호스트의 네트워크 인터페이스를 구성합니다.
  14. 다음 명령을 실행하여 에이전트 이미지를 생성합니다.

    $ openshift-install --dir <install_directory> agent create image
    참고

    RHCOS(Red Hat Enterprise Linux CoreOS)는 기본 디스크에서 다중 경로를 지원하므로 하드웨어 장애에 대한 탄력성이 강화된 호스트 가용성을 높일 수 있습니다. 기본 /etc/multipath.conf 구성이 있는 에이전트 ISO 이미지에서 멀티패스는 기본적으로 활성화됩니다.

  15. 베어 메탈 시스템에서 agent.x86_64.iso 이미지를 부팅합니다.
  16. 선택 사항: 부트스트랩 호스트(ndezvous 호스트)가 재부팅되는 시기를 확인하려면 다음 명령을 실행합니다.

    $ ./openshift-install --dir <install_directory> agent wait-for bootstrap-complete \ 
    1
    
        --log-level=info 
    2
    1
    & lt;install_directory > 의 경우 에이전트 ISO가 생성된 디렉터리의 경로를 지정합니다.
    2
    다른 설치 세부 사항을 보려면 info 대신 warn, debug 또는 error를 지정합니다.

    출력 예

    ...................................................................
    ...................................................................
    INFO Bootstrap configMap status is complete
    INFO cluster bootstrap is complete

    이 명령은 Kubernetes API 서버가 컨트롤 플레인 시스템에서 부트스트랩되었다는 신호를 보낼 때 성공합니다.

  17. 진행 상황을 추적하고 성공적으로 설치를 확인하려면 다음 명령을 실행합니다.

    $ openshift-install --dir <install_directory> agent wait-for install-complete 
    1
    1
    & lt;install_directory > 디렉터리에 대해 에이전트 ISO가 생성된 디렉터리의 경로를 지정합니다.

    출력 예

    ...................................................................
    ...................................................................
    INFO Cluster is installed
    INFO Install complete!
    INFO To access the cluster as the system:admin user when using 'oc', run
    INFO     export KUBECONFIG=/home/core/installer/auth/kubeconfig
    INFO Access the OpenShift web-console here: https://console-openshift-console.apps.sno-cluster.test.example.com

참고

선택적 ZTP 매니페스트 방법을 사용하는 경우 다음 세 가지 방법으로 AgentClusterInstall.yaml 파일을 통해 클러스터 노드의 IP 주소 끝점을 구성할 수 있습니다.

  • IPv4
  • IPv6
  • IPv4 및 IPv6 병렬(dual-stack)

듀얼 스택 네트워킹의 예

apiVIP: 192.168.11.3
ingressVIP: 192.168.11.4
clusterDeploymentRef:
  name: mycluster
imageSetRef:
  name: openshift-4.12
networking:
  clusterNetwork:
  - cidr: 172.21.0.0/16
    hostPrefix: 23
  - cidr: fd02::/48
    hostPrefix: 64
  machineNetwork:
  - cidr: 192.168.11.0/16
  - cidr: 2001:DB8::/32
  serviceNetwork:
  - 172.22.0.0/16
  - fd03::/112
  networkType: OVNKubernetes

IPv6는 베어 메탈 플랫폼에서만 지원됩니다.

3.3. 에이전트 기반 설치 실패에서 로그 데이터 수집

다음 절차에 따라 지원 케이스를 제공하기 위해 실패한 에이전트 기반 설치에 대한 로그 데이터를 수집합니다.

프로세스

  1. 다음 명령을 실행하고 출력을 수집합니다.

    $ ./openshift-install --dir <install_directory> agent wait-for bootstrap-complete --log-level=debug

    오류 메시지의 예

    ...
    ERROR Bootstrap failed to complete: : bootstrap process timed out: context deadline exceeded

  2. 이전 명령의 출력에 오류가 있거나 부트스트랩이 진행되지 않은 경우 노드 0에서 다음 명령을 실행하고 출력을 수집합니다.

    $ ssh core@<node-ip> sudo /usr/local/bin/agent-gather -O > <local_tmp_path>/agent-gather.tar.xz
    참고

    노드 0에서 데이터를 수집할 때만 필요하지만 모든 노드에서 이 데이터를 수집하는 것이 유용할 수 있습니다.

  3. 부트스트랩이 완료되고 클러스터 노드가 재부팅되면 다음 명령을 실행하고 출력을 수집합니다.

    $ ./openshift-install --dir <install_directory> agent wait-for install-complete --log-level=debug
  4. 이전 명령의 출력에 오류가 표시되면 다음 단계를 수행합니다.

    1. 다음 명령을 실행하여 kubeconfig 파일을 환경으로 내보냅니다.

      $ export KUBECONFIG=<install_directory>/auth/kubeconfig
    2. 디버깅에 대한 정보를 수집하려면 다음 명령을 실행합니다.

      $ oc adm must-gather
    3. 다음 명령을 실행하여 작업 디렉터리에 생성된 must-gather 디렉터리에서 압축 파일을 만듭니다.

      $ tar cvaf must-gather.tar.gz <must_gather_directory>
  5. /auth 하위 디렉토리를 제외하고 배포 중에 사용되는 설치 디렉터리를 Red Hat 고객 포털 의 지원 케이스에 연결합니다.
  6. 이 절차에서 수집된 다른 모든 데이터를 지원 케이스에 첨부합니다.

3.4. ZTP 사용자 정의 리소스 샘플

선택 사항: ZTP(Zero touch provisioning) CR(사용자 정의 리소스) 오브젝트를 사용하여 에이전트 기반 설치 프로그램과 함께 OpenShift Container Platform 클러스터를 설치할 수 있습니다.

다음 ZTP 사용자 정의 리소스를 사용자 지정하여 OpenShift Container Platform 클러스터에 대한 자세한 정보를 지정할 수 있습니다. 다음 샘플 ZTP 사용자 지정 리소스는 단일 노드 클러스터용입니다.

agent-cluster-install.yaml

  apiVersion: extensions.hive.openshift.io/v1beta1
  kind: AgentClusterInstall
  metadata:
    name: test-agent-cluster-install
    namespace: cluster0
  spec:
    clusterDeploymentRef:
      name: ostest
    imageSetRef:
      name: openshift-4.12
    networking:
      clusterNetwork:
      - cidr: 10.128.0.0/14
        hostPrefix: 23
      serviceNetwork:
      - 172.30.0.0/16
    provisionRequirements:
      controlPlaneAgents: 1
      workerAgents: 0
    sshPublicKey: <YOUR_SSH_PUBLIC_KEY>

cluster-deployment.yaml

apiVersion: hive.openshift.io/v1
kind: ClusterDeployment
metadata:
  name: ostest
  namespace: cluster0
spec:
  baseDomain: test.metalkube.org
  clusterInstallRef:
    group: extensions.hive.openshift.io
    kind: AgentClusterInstall
    name: test-agent-cluster-install
    version: v1beta1
  clusterName: ostest
  controlPlaneConfig:
    servingCertificates: {}
  platform:
    agentBareMetal:
      agentSelector:
        matchLabels:
          bla: aaa
  pullSecretRef:
    name: pull-secret

cluster-image-set.yaml

apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  name: openshift-4.12
spec:
  releaseImage: registry.ci.openshift.org/ocp/release:4.12.0-0.nightly-2022-06-06-025509

infra-env.yaml

apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: myinfraenv
  namespace: cluster0
spec:
  clusterRef:
    name: ostest
    namespace: cluster0
  pullSecretRef:
    name: pull-secret
  sshAuthorizedKey: <YOUR_SSH_PUBLIC_KEY>
  nmStateConfigLabelSelector:
    matchLabels:
      cluster0-nmstate-label-name: cluster0-nmstate-label-value

nmstateconfig.yaml

apiVersion: agent-install.openshift.io/v1beta1
kind: NMStateConfig
metadata:
  name: master-0
  namespace: openshift-machine-api
  labels:
    cluster0-nmstate-label-name: cluster0-nmstate-label-value
spec:
  config:
    interfaces:
      - name: eth0
        type: ethernet
        state: up
        mac-address: 52:54:01:aa:aa:a1
        ipv4:
          enabled: true
          address:
            - ip: 192.168.122.2
              prefix-length: 23
          dhcp: false
    dns-resolver:
      config:
        server:
          - 192.168.122.1
    routes:
      config:
        - destination: 0.0.0.0/0
          next-hop-address: 192.168.122.1
          next-hop-interface: eth0
          table-id: 254
  interfaces:
    - name: "eth0"
      macAddress: 52:54:01:aa:aa:a1

pull-secret.yaml

apiVersion: v1
kind: Secret
type: kubernetes.io/dockerconfigjson
metadata:
  name: pull-secret
  namespace: cluster0
stringData:
  .dockerconfigjson: 'YOUR_PULL_SECRET'

다중 클러스터 엔진 Operator를 설치하고 에이전트 기반 OpenShift Container Platform 설치 프로그램을 사용하여 허브 클러스터를 배포할 수 있습니다. 다음 절차는 부분적으로 자동화되며 초기 클러스터를 배포한 후 수동 단계가 필요합니다.

4.1. 사전 요구 사항

연결이 끊긴 환경의 필요한 OpenShift Container Platform 컨테이너 이미지, 다중 클러스터 엔진 Operator 및 LSO(Local Storage Operator)를 로컬 미러 레지스트리에 미러링할 수 있습니다. 미러 레지스트리의 로컬 DNS 호스트 이름과 포트를 기록해야 합니다.

참고

OpenShift Container Platform 이미지 저장소를 미러 레지스트리에 미러링하려면 oc adm release image 또는 oc mirror 명령을 사용할 수 있습니다. 이 절차에서는 oc mirror 명령이 예제로 사용됩니다.

프로세스

  1. 유효한 install-config.yamlagent-config.yaml 파일을 포함할 < assets_directory > 폴더를 생성합니다. 이 디렉터리는 모든 자산을 저장하는 데 사용됩니다.
  2. OpenShift Container Platform 이미지 리포지토리, 다중 클러스터 엔진 및 LSO를 미러링하려면 다음 설정으로 ImageSetConfiguration.yaml 파일을 생성합니다.

    Example ImageSetConfiguration.yaml

      kind: ImageSetConfiguration
      apiVersion: mirror.openshift.io/v1alpha2
      archiveSize: 4 
    1
    
      storageConfig: 
    2
    
        imageURL: <your-local-registry-dns-name>:<your-local-registry-port>/mirror/oc-mirror-metadata 
    3
    
        skipTLS: true
      mirror:
        platform:
          architectures:
            - "amd64"
          channels:
            - name: stable-4.12 
    4
    
              type: ocp
        additionalImages:
          - name: registry.redhat.io/ubi8/ubi:latest
        operators:
          - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.12 
    5
    
            packages: 
    6
    
              - name: multicluster-engine 
    7
    
              - name: local-storage-operator 
    8

    1
    이미지 세트 내의 각 파일의 최대 크기(GiB)를 지정합니다.
    2
    이미지 세트 메타데이터를 수신할 백엔드 위치를 설정합니다. 이 위치는 레지스트리 또는 로컬 디렉터리일 수 있습니다. 기술 프리뷰 OCI 기능을 사용하지 않는 한 storageConfig 값을 지정해야 합니다.
    3
    스토리지 백엔드의 레지스트리 URL을 설정합니다.
    4
    설치 중인 버전의 OpenShift Container Platform 이미지가 포함된 채널을 설정합니다.
    5
    설치 중인 OpenShift Container Platform 이미지가 포함된 Operator 카탈로그를 설정합니다.
    6
    이미지 세트에 포함할 특정 Operator 패키지 및 채널만 지정합니다. 이 필드를 제거하여 카탈로그의 모든 패키지를 검색합니다.
    7
    멀티 클러스터 엔진 패키지 및 채널.
    8
    LSO 패키지 및 채널
    참고

    이 파일은 콘텐츠를 미러링할 때 oc mirror 명령에 필요합니다.

  3. 특정 OpenShift Container Platform 이미지 저장소, 다중 클러스터 엔진 및 LSO를 미러링하려면 다음 명령을 실행합니다.

    $ oc mirror --dest-skip-tls --config ocp-mce-imageset.yaml docker://<your-local-registry-dns-name>:<your-local-registry-port>
  4. install-config.yaml 파일에서 레지스트리 및 인증서를 업데이트합니다.

    Example imageContentSources.yaml

      imageContentSources:
        - source: "quay.io/openshift-release-dev/ocp-release"
          mirrors:
            - "<your-local-registry-dns-name>:<your-local-registry-port>/openshift/release-images"
        - source: "quay.io/openshift-release-dev/ocp-v4.0-art-dev"
          mirrors:
            - "<your-local-registry-dns-name>:<your-local-registry-port>/openshift/release"
        - source: "registry.redhat.io/ubi8"
          mirrors:
            - "<your-local-registry-dns-name>:<your-local-registry-port>/ubi8"
        - source: "registry.redhat.io/multicluster-engine"
          mirrors:
            - "<your-local-registry-dns-name>:<your-local-registry-port>/multicluster-engine"
        - source: "registry.redhat.io/rhel8"
          mirrors:
            - "<your-local-registry-dns-name>:<your-local-registry-port>/rhel8"
        - source: "registry.redhat.io/redhat"
          mirrors:
            - "<your-local-registry-dns-name>:<your-local-registry-port>/redhat"

    또한 install-config.yamladditionalTrustBundle 필드에 인증서가 있는지 확인합니다.

    예: install-config.yaml

    additionalTrustBundle: |
      -----BEGIN CERTIFICATE-----
      zzzzzzzzzzz
      -----END CERTIFICATE-------

    중요

    oc mirror 명령은 여러 출력을 사용하여 oc-mirror-workspace 라는 폴더를 생성합니다. 여기에는 OpenShift Container Platform 및 선택한 Operator에 필요한 모든 미러를 식별하는 imageContentSourcePolicy.yaml 파일이 포함됩니다.

  5. 다음 명령을 실행하여 클러스터 매니페스트를 생성합니다.

    $ openshift-install agent create cluster-manifests

    이 명령은 미러 구성이 포함된 미러 폴더를 포함하도록 클러스터 매니페스트 폴더를 업데이트합니다.

다중 클러스터 엔진 Operator, LSO(Local Storage Operator)에 필요한 매니페스트를 생성하고 에이전트 기반 OpenShift Container Platform 클러스터를 허브 클러스터로 배포합니다.

프로세스

  1. < assets_directory> 폴더에 openshift 라는 하위 폴더를 생성합니다. 이 하위 폴더는 배포된 클러스터를 추가로 사용자 지정하기 위해 설치 중에 적용할 추가 매니페스트를 저장하는 데 사용됩니다. & lt;assets_directory > 폴더에는 install-config.yamlagent-config.yaml 파일을 포함한 모든 자산이 포함되어 있습니다.

    참고

    설치 프로그램에서 추가 매니페스트를 확인하지 않습니다.

  2. 다중 클러스터 엔진의 경우 다음 매니페스트를 생성하여 < assets_directory>/openshift 폴더에 저장합니다.

    Example mce_namespace.yaml

      apiVersion: v1
      kind: Namespace
      metadata:
        labels:
          openshift.io/cluster-monitoring: "true"
        name: multicluster-engine

    Example mce_operatorgroup.yaml

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: multicluster-engine-operatorgroup
        namespace: multicluster-engine
      spec:
        targetNamespaces:
        - multicluster-engine

    Example mce_subscription.yaml

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: multicluster-engine
        namespace: multicluster-engine
      spec:
        channel: "stable-2.1"
        name: multicluster-engine
        source: redhat-operators
        sourceNamespace: openshift-marketplace

    참고

    지원되는 설치 관리자(AI)를 사용하여 RHACM(Red Hat Advanced Cluster Management)을 사용하여 대규모로 DCU(Distributed Unit)를 설치할 수 있습니다. 이러한 분산 단위는 hub 클러스터에서 활성화되어야 합니다. AI 서비스에는 수동으로 생성되는 PV(영구 볼륨)가 필요합니다.

  3. AI 서비스의 경우 다음 매니페스트를 생성하여 < assets_directory>/openshift 폴더에 저장합니다.

    Example lso_namespace.yaml

      apiVersion: v1
      kind: Namespace
      metadata:
        annotations:
          openshift.io/cluster-monitoring: "true"
        name: openshift-local-storage

    Example lso_operatorgroup.yaml

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: local-operator-group
        namespace: openshift-local-storage
      spec:
        targetNamespaces:
          - openshift-local-storage

    Example lso_subscription.yaml

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: local-storage-operator
        namespace: openshift-local-storage
      spec:
        installPlanApproval: Automatic
        name: local-storage-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace

    참고

    모든 매니페스트를 생성한 후 파일 시스템이 다음과 같이 표시되어야 합니다.

    파일 시스템 예

    <assets_directory>
        ├─ install-config.yaml
        ├─ agent-config.yaml
        └─ /openshift
            ├─ mce_namespace.yaml
            ├─ mce_operatorgroup.yaml
            ├─ mce_subscription.yaml
            ├─ lso_namespace.yaml
            ├─ lso_operatorgroup.yaml
            └─ lso_subscription.yaml

  4. 다음 명령을 실행하여 에이전트 ISO 이미지를 생성합니다.

    $ openshift-install agent create image --dir <assets_directory>
  5. 이미지가 준비되면 대상 시스템을 부팅하고 설치가 완료될 때까지 기다립니다.
  6. 설치를 모니터링하려면 다음 명령을 실행합니다.

    $ openshift-install agent wait-for install-complete --dir <assets_directory>
    참고

    완전한 기능 허브 클러스터를 구성하려면 다음 매니페스트를 생성하고 $ oc apply -f <manifest-name> 명령을 실행하여 수동으로 적용해야 합니다. 매니페스트 생성 순서가 중요하며 필요한 경우 대기 조건이 표시됩니다.

  7. AI 서비스에 필요한 PV의 경우 다음 매니페스트를 생성합니다.

      apiVersion: local.storage.openshift.io/v1
      kind: LocalVolume
      metadata:
       name: assisted-service
       namespace: openshift-local-storage
      spec:
       logLevel: Normal
       managementState: Managed
       storageClassDevices:
         - devicePaths:
             - /dev/vda
             - /dev/vdb
           storageClassName: assisted-service
           volumeMode: Filesystem
  8. 다음 명령을 사용하여 후속 매니페스트를 적용하기 전에 PV의 가용성을 기다립니다.

    $ oc wait localvolume -n openshift-local-storage assisted-service --for condition=Available --timeout 10m
    참고
    The `devicePath` is an example and may vary depending on the actual hardware configuration used.
  9. 다중 클러스터 엔진 인스턴스에 대한 매니페스트를 생성합니다.

    Example MultiClusterEngine.yaml

      apiVersion: multicluster.openshift.io/v1
      kind: MultiClusterEngine
      metadata:
        name: multiclusterengine
      spec: {}

  10. AI 서비스를 활성화하는 매니페스트를 생성합니다.

    agentserviceconfig.yaml

      apiVersion: agent-install.openshift.io/v1beta1
      kind: AgentServiceConfig
      metadata:
        name: agent
        namespace: assisted-installer
      spec:
       databaseStorage:
        storageClassName: assisted-service
        accessModes:
        - ReadWriteOnce
        resources:
         requests:
          storage: 10Gi
       filesystemStorage:
        storageClassName: assisted-service
        accessModes:
        - ReadWriteOnce
        resources:
         requests:
          storage: 10Gi

  11. 나중에 대화하는 클러스터를 배포할 매니페스트를 생성합니다.

    Example clusterimageset.yaml

      apiVersion: hive.openshift.io/v1
      kind: ClusterImageSet
      metadata:
        name: "4.12"
      spec:
        releaseImage: quay.io/openshift-release-dev/ocp-release:4.12.0-x86_64

  12. 에이전트가 설치된 클러스터(Multicluster 엔진 및 지원 서비스를 호스트)를 hub 클러스터 클러스터로 가져오는 매니페스트를 생성합니다.

    예: autoimport.yaml

      apiVersion: cluster.open-cluster-management.io/v1
      kind: ManagedCluster
      metadata:
       labels:
         local-cluster: "true"
         cloud: auto-detect
         vendor: auto-detect
       name: local-cluster
      spec:
       hubAcceptsClient: true

  13. 관리 클러스터가 생성될 때까지 기다립니다.

    $ oc wait -n multicluster-engine managedclusters local-cluster --for condition=ManagedClusterJoined=True --timeout 10m

검증

  • 관리 클러스터 설치에 성공했는지 확인하려면 다음 명령을 실행합니다.

    $ oc get managedcluster
    NAME            HUB ACCEPTED   MANAGED CLUSTER URLS             JOINED   AVAILABLE  AGE
    local-cluster   true           https://<your cluster url>:6443   True     True       77m

Legal Notice

Copyright © Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of the OpenJS Foundation.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2026 Red Hat
맨 위로 이동