클러스터

복사 및 붙여넣기 기능을 구성하여 더 빠르게 개발하십시오. assisted-installer 에서 copy-from-mac 기능을 구성하려면 nmstate 정의 인터페이스 및 mac-mapping 인터페이스에 mac-address 를 추가해야 합니다. mac-mapping 인터페이스는 nmstate 정의 인터페이스 외부에 제공됩니다. 따라서 동일한 mac-address 를 두 번 제공해야 합니다.

호스팅된 클러스터 생성에 자동화 템플릿을 사용하고 prehook 작업이 실패하면 호스팅된 클러스터 생성이 여전히 진행 중인 것처럼 보입니다. 호스트 클러스터가 완전한 실패 상태로 설계되었으므로 클러스터를 계속 생성하려고 하기 때문에 이는 정상입니다.

hub 클러스터에서volSync ManagedClusterAddOn 을 제거하면 관리 클러스터에서volSync Operator 서브스크립션을 제거하지만 CSV(클러스터 서비스 버전)는 제거되지 않습니다. 관리형 클러스터에서 CSV를 제거하려면volSync를 제거하는 각 관리 클러스터에서 다음 명령을 실행합니다.

oc delete csv -n openshift-operators volsync-product.v0.6.0

다른 버전의 CryostatSync가 설치되어 있는 경우 v0.6.0 을 설치된 버전으로 교체합니다.

ManagedClusterSet 을 삭제한 후 클러스터를 클러스터 세트에 연결하는 각 관리 클러스터에 추가된 레이블은 자동으로 제거되지 않습니다. 삭제된 관리 클러스터 세트에 포함된 각 관리 클러스터에서 레이블을 수동으로 제거합니다. 레이블은 cluster.open-cluster-management.io/clusterset:<ManagedClusterSet Name> 과 유사합니다.

ClusterPool 에 대해 Hive ClusterClaim 을 생성하고 ClusterClaimspec 라이프 사이클 필드를 잘못된 golang 시간 값으로 수동으로 설정하는 경우 제품은 잘못된 형식의 클레임뿐만 아니라 모든 ClusterClaims 이행 및 재조정을 중지합니다.

이 오류가 발생하면 clusterclaim-controller pod 로그에 다음 내용이 표시됩니다. 이 로그는 풀 이름과 유효하지 않은 라이프 사이클이 포함된 특정 예입니다.

E0203 07:10:38.266841       1 reflector.go:138] sigs.k8s.io/controller-runtime/pkg/cache/internal/informers_map.go:224: Failed to watch *v1.ClusterClaim: failed to list *v1.ClusterClaim: v1.ClusterClaimList.Items: []v1.ClusterClaim: v1.ClusterClaim.v1.ClusterClaim.Spec: v1.ClusterClaimSpec.Lifetime: unmarshalerDecoder: time: unknown unit "w" in duration "1w", error found in #10 byte of ...|time":"1w"}},{"apiVe|..., bigger context ...|clusterPoolName":"policy-aas-hubs","lifetime":"1w"}},{"apiVersion":"hive.openshift.io/v1","kind":"Cl|...

유효하지 않은 클레임을 삭제할 수 있습니다.

잘못된 클레임이 삭제되면 클레임이 추가 상호 작용 없이 성공적으로 조정되기 시작합니다.

clusterimageset 은 fast 채널이지만 프로비저닝된 클러스터는 stable 채널에 있습니다. 현재 제품은 채널을 프로비저닝된 OpenShift Container Platform 클러스터와 동기화하지 않습니다.

OpenShift Container Platform 콘솔에서 올바른 채널로 변경합니다. Administration > Cluster Settings > Details Channel 을 클릭합니다.

사용자 정의 CA 인증서로 클러스터를 관리하는 허브 클러스터의 백업을 복원한 후 관리 클러스터와 hub 클러스터 간의 연결이 실패할 수 있습니다. 이는 복원된 허브 클러스터에서 CA 인증서가 백업되지 않았기 때문입니다. 연결을 복원하려면 관리 클러스터의 네임스페이스에 있는 사용자 정의 CA 인증서 정보를 복원된 허브 클러스터의 < managed_cluster>-admin-kubeconfig 시크릿에 복사합니다.

팁: 백업 사본을 생성하기 전에 이 CA 인증서를 hub 클러스터에 복사하는 경우 백업 사본에 시크릿 정보가 포함됩니다. 나중에 백업 사본을 사용하여 복원하면 허브와 관리 클러스터 간의 연결이 자동으로 완료됩니다.

disableHubSelfManagement 를 false 로 설정하는 동안 local-cluster가 삭제되면 MulticlusterHub Operator가 local-cluster를 다시 생성합니다. local-cluster를 분리하면 local-cluster가 자동으로 다시 생성되지 않을 수 있습니다.

콘솔을 사용하여 온-프레미스 클러스터를 만들 때 클러스터에 사용 가능한 서브넷을 선택해야 합니다. 필수 필드로 표시되지 않습니다.

Infrastructure Operator를 사용하여 OpenShift Container Platform 클러스터를 생성할 때 ISO 이미지의 파일 이름이 너무 길 수 있습니다. 긴 이미지 이름을 사용하면 이미지 프로비저닝과 클러스터 프로비저닝이 실패합니다. 이 문제가 있는지 확인하려면 다음 단계를 완료합니다.

이 문제가 발생하면 인프라 Operator가 이미지 서비스를 사용하지 않았기 때문에 일반적으로 다음 버전의 OpenShift Container Platform에 있습니다.

이 오류를 방지하려면 OpenShift Container Platform을 버전 4.8.18 이상 또는 4.9.7 이상으로 업그레이드하십시오.

검색 이미지로 부팅하고 호스트를 자동으로 추가하기 위해 호스트 인벤토리 또는 InfraEnv 사용자 정의 리소스를 사용할 수 없습니다. BareMetalHost 리소스에 이전 InfraEnv 리소스를 사용한 후 이미지를 직접 부팅하려는 경우 새 InfraEnv 리소스를 생성하여 문제를 해결할 수 있습니다.

실수로 local-cluster 라는 클러스터를 다른 이름으로 다시 가져오려고 하면 local 클러스터의 상태 및 다시 가져오기된 클러스터의 상태가 오프라인으로 표시됩니다.

이 경우 복구하려면 다음 단계를 완료합니다.

관리 클러스터를 자동으로 프로비저닝하도록 구성된 자동화 템플릿은 다음 두 조건이 충족되면 실패할 수 있습니다.

klusterlet Operator를 설치하여 관리 클러스터를 가져오는 경우 klusterlet Operator의 버전이 Hub 클러스터 버전과 동일하거나 klusterlet Operator가 작동하지 않아야 합니다.

관리 클러스터의 네임스페이스를 수동으로 삭제할 수 없습니다. 관리형 클러스터 네임스페이스는 관리 클러스터를 분리한 후 자동으로 삭제됩니다. 관리 클러스터가 분리되기 전에 관리 클러스터 네임스페이스를 수동으로 삭제하는 경우 관리 클러스터에 관리 클러스터를 삭제한 후 지속적인 종료 상태가 표시됩니다. 이 종료 관리 클러스터를 삭제하려면 분리된 관리 클러스터에서 종료자를 수동으로 제거합니다.

Hub 클러스터 및 관리 클러스터 시간이 동기화되지 않아 알 수 없고 결국 몇 분 내에 사용할 수 있습니다. OpenShift Container Platform 허브 클러스터 시간이 올바르게 구성되었는지 확인합니다. 노드 사용자 지정을 참조하십시오.

IBM OpenShift Container Platform Kubernetes Service 버전 3.11 클러스터를 가져올 수 없습니다. 이후 버전의 IBM OpenShift Kubernetes Service가 지원됩니다.

클라우드 공급자 측에서 클라우드 공급자 액세스 키를 변경하는 경우 다중 클러스터 엔진 Operator 콘솔에서 이 클라우드 공급자에 대한 해당 인증 정보도 업데이트해야 합니다. 이는 관리 클러스터가 호스팅되는 클라우드 공급자에서 인증 정보가 만료되고 관리 클러스터를 삭제하려고 할 때 필요합니다.

hub 클러스터에서 리소스에 대한 맵을 검색합니다. 사용자 RBAC 설정에 따라 사용자가 관리 클러스터의 노드 데이터를 볼 수 없습니다. 검색 결과는 클러스터의 노드 페이지에 표시되는 결과와 다를 수 있습니다.

관리 클러스터를 삭제하면 1시간 후에도 상태가 계속 Destroying 으로 표시되고 클러스터가 삭제되지 않습니다. 이 문제를 해결하려면 다음 단계를 완료합니다.

Red Hat Advanced Cluster Management 콘솔을 사용하여 OpenShift Container Platform Dedicated 환경에 있는 OpenShift Container Platform 관리 클러스터를 업그레이드할 수 없습니다.

특정 관리 클러스터에서 특정 리소스의 검색 세부 정보 페이지가 실패할 수 있습니다. 검색하려면 먼저 관리 클러스터의 work-manager 애드온이 Available 상태에 있는지 확인해야 합니다.

Red Hat OpenShift Container Platform 및 비 OpenShift Container Platform 클러스터는 모두 Red Hat Advanced Cluster Management 2.10 이상의 새로 설치를 사용하는 경우 Pod 로그 기능을 지원합니다.

Red Hat Advanced Cluster Management 2.9에서 2.10으로 업그레이드한 경우 OpenShift Container Platform 관리형 클러스터에서 Pod 로그 기능을 사용하려면 ManagedServiceAccount 애드온을 수동으로 활성화해야 합니다. ManagedServiceAccount를 활성화하는 방법을 알아보려면 ManagedServiceAccount 애드온 을 참조하십시오.

또는 ManagedServiceAccount 대신 LoadBalancer 를 사용하여 비 OpenShift Container Platform 관리 클러스터에서 Pod 로그 기능을 활성화할 수 있습니다.

LoadBalancer 를 활성화하려면 다음 단계를 완료합니다.

LoadBalancer 유형에 대한 자세한 내용은 Kubernetes 문서의 서비스 페이지를 참조하십시오.

OpenShift Container Platform 4.10.z에서 클러스터 전체 프록시 구성으로 호스팅 서비스 클러스터를 생성하면 nodeip-configuration.service 서비스가 작업자 노드에서 시작되지 않습니다.

Azure에서 OpenShift Container Platform 4.11 클러스터를 프로비저닝하면 인증 Operator 시간 초과 오류로 인해 실패합니다. 이 문제를 해결하려면 install-config.yaml 파일에서 다른 작업자 노드 유형을 사용하거나 vmNetworkingType 매개변수를 Basic 으로 설정합니다. 다음 install-config.yaml 예제를 참조하십시오.

compute:
- hyperthreading: Enabled
  name: 'worker'
  replicas: 3
  platform:
    azure:
      type:  Standard_D2s_v3
      osDisk:
        diskSizeGB: 128
      vmNetworkingType: 'Basic'

iPXE는 오픈 소스 네트워크 부팅 펌웨어입니다. 자세한 내용은 iPXE 를 참조하십시오.

노드를 부팅할 때 일부 DHCP 서버의 URL 길이 제한이 InfraEnv 사용자 정의 리소스 정의의 ipxeScript URL을 차단하여 콘솔에 다음과 같은 오류 메시지가 표시됩니다.

부팅 가능한 장치 없음

이 문제를 해결하려면 다음 단계를 완료하십시오.

Red Hat Advanced Cluster Management 2.6에서 삭제된 BareMetalAssets API를 사용하는 경우 BareMetalAssets API가 ClusterDeployment 에 바인딩되어 있으므로 Red Hat Advanced Cluster Management 2.7로 업그레이드한 후 ClusterDeployment 을 삭제할 수 없습니다.

이 문제를 해결하려면 Red Hat Advanced Cluster Management 2.7로 업그레이드하기 전에 종료자 를 제거하려면 다음 명령을 실행합니다.

oc patch clusterdeployment <clusterdeployment-name> -p '{"metadata":{"finalizers":null}}' --type=merge

중앙 인프라 관리 서비스를 사용하여 연결이 끊긴 환경에 클러스터를 배포할 때 클러스터 노드가 설치를 시작하지 못할 수 있습니다.

이 문제는 클러스터가 OpenShift Container Platform 버전 4.12.0에서 4.12.2를 통해 제공되는 Red Hat Enterprise Linux CoreOS 라이브 ISO 이미지에서 생성된 검색 ISO 이미지를 사용하기 때문에 발생합니다. 이미지에는 registry.redhat.io 및 registry.access.redhat.com 에서 소싱한 이미지의 서명이 필요한 제한적인 /etc/containers/policy.json 파일이 포함되어 있습니다. 연결이 끊긴 환경에서 미러링된 이미지에 서명이 미러링되지 않아 검색 시 이미지 풀링이 실패할 수 있습니다. 에이전트 이미지가 클러스터 노드와 연결되지 않아 지원 서비스와의 통신이 실패합니다.

이 문제를 해결하려면 /etc/containers/policy.json 파일을 제한 없이 설정하는 클러스터에 ignition 덮어쓰기를 적용합니다. Ignition 재정의는 InfraEnv 사용자 정의 리소스 정의에서 설정할 수 있습니다. 다음 예제에서는 재정의가 있는 InfraEnv 사용자 정의 리소스 정의를 보여줍니다.

apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: cluster
  namespace: cluster
spec:
  ignitionConfigOverride: '{"ignition":{"version":"3.2.0"},"storage":{"files":[{"path":"/etc/containers/policy.json","mode":420,"overwrite":true,"contents":{"source":"data:text/plain;charset=utf-8;base64,ewogICAgImRlZmF1bHQiOiBbCiAgICAgICAgewogICAgICAgICAgICAidHlwZSI6ICJpbnNlY3VyZUFjY2VwdEFueXRoaW5nIgogICAgICAgIH0KICAgIF0sCiAgICAidHJhbnNwb3J0cyI6CiAgICAgICAgewogICAgICAgICAgICAiZG9ja2VyLWRhZW1vbiI6CiAgICAgICAgICAgICAgICB7CiAgICAgICAgICAgICAgICAgICAgIiI6IFt7InR5cGUiOiJpbnNlY3VyZUFjY2VwdEFueXRoaW5nIn1dCiAgICAgICAgICAgICAgICB9CiAgICAgICAgfQp9"}}]}}'

다음 예제에서는 생성된 제한되지 않은 파일을 보여줍니다.

{
    "default": [
        {
            "type": "insecureAcceptAnything"
        }
    ],
    "transports": {
        "docker-daemon": {
        "": [
        {
            "type": "insecureAcceptAnything"
        }
        ]
    }
    }
}

이 설정이 변경되면 클러스터가 설치됩니다.

통합 흐름은 기본 프로비저닝 프로세스입니다. Bare Metal Operator(BMO)에 BareMetalHost 리소스를 사용하여 호스트를 라이브 ISO에 연결하는 경우 Ironic Python 에이전트는 다음 작업을 수행합니다.

지원 설치 관리자 에이전트가 느리게 시작되고 관리 클러스터를 배포하는 경우 관리 클러스터가 Pending 상태로 중단되고 에이전트 리소스가 없을 수 있습니다. 통합 흐름을 비활성화하여 문제를 해결할 수 있습니다.

중요: 통합 흐름을 비활성화할 때 지원 설치 관리자 에이전트만 라이브 ISO에서 실행되므로 열려 있는 포트 수를 줄이고 Ironic Python 에이전트 에이전트에서 활성화한 기능을 비활성화합니다.

통합 흐름을 비활성화하지 않고 활성화하거나 비활성화할 포트 번호를 결정하려면 네트워크 구성 을 참조하십시오.

통합 흐름을 비활성화하려면 다음 단계를 완료합니다.

Clustersets API 를 사용하는 경우 selectorType: LaberSelector 설정은 지원되지 않습니다. selectorType: ExclusiveClusterSetLabel 설정이 지원됩니다.

hub 클러스터가 관리 클러스터에 도달하거나 통신할 수 없는 경우 다음과 같은 제한 사항이 발생합니다.

다음은 managed-serviceaccount 애드온에 대한 알려진 문제 및 제한 사항입니다.

KubeVirt 호스팅 클러스터의 콘솔에서 대량 제거 옵션을 사용하면 KubeVirt 호스팅 클러스터가 제거되지 않습니다.

행 작업 드롭다운 메뉴를 사용하여 KubeVirt 호스팅 클러스터를 대신 삭제합니다.

ClusterCurator 리소스를 사용하여 OpenShift Container Platform Dedicated 클러스터를 업그레이드하면 클러스터 큐레이터가 OpenShift Container Platform Dedicated 클러스터를 지원하지 않기 때문에 업그레이드가 실패합니다.

관리형 클러스터를 설치하는 동안 ClusterDeployment 리소스를 사용하여 사용자 정의 인그레스 도메인을 지정할 수 있지만, SyncSet 리소스를 사용하여 설치 후에만 변경 사항을 적용합니다. 결과적으로 clusterdeployment.yaml 파일의 spec 필드에 사용자가 지정한 Ingress 도메인이 표시되지만 상태는 여전히 기본 도메인을 표시합니다.

4.16 이전 Red Hat OpenShift Container Platform 버전으로 단일 노드 OpenShift 클러스터를 설치하려면 InfraEnv 사용자 정의 리소스 및 부팅된 호스트에서 단일 노드 OpenShift 클러스터를 설치하기 위해 사용 중인 동일한 OpenShift Container Platform 버전을 사용해야 합니다. 버전이 일치하지 않으면 설치에 실패합니다.

이 문제를 해결하려면 Discovery ISO로 호스트를 부팅하기 전에 InfraEnv 리소스를 편집하고 다음 콘텐츠를 포함합니다.

apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
spec:
  osImageVersion: 4.15

osImageVersion 필드는 설치하려는 Red Hat OpenShift Container Platform 클러스터 버전과 일치해야 합니다.

주석 및 ManagedCluster 이름이 일치하지 않으면 콘솔에 클러스터가 Pending 가져오기 로 표시됩니다. 다중 클러스터 엔진 Operator는 클러스터를 사용할 수 없습니다. 주석이 없고 ManagedCluster 이름이 HostedCluster 리소스의 Infra-ID 값과 일치하지 않는 경우에도 동일한 문제가 발생합니다."

콘솔을 사용하여 기존 호스트 클러스터에 새 노드 풀을 추가하면 동일한 버전의 OpenShift Container Platform이 옵션 목록에 두 번 이상 표시될 수 있습니다. 원하는 버전의 목록에서 인스턴스를 선택할 수 있습니다.

노드 풀이 작업자가 0개로 축소되면 콘솔의 호스트 목록에는 노드가 준비 됨 상태로 계속 표시됩니다. 다음 두 가지 방법으로 노드 수를 확인할 수 있습니다.

듀얼 스택 네트워크를 사용하는 환경에서 호스팅 클러스터를 생성할 때 다음과 같은 DNS 관련 문제가 발생할 수 있습니다.

이러한 문제를 해결하려면 듀얼 스택 네트워크의 DNS 구성 지침에 따라 DNS 서버 설정을 구성합니다.

베어 메탈(Agent) 플랫폼에서 호스팅된 컨트롤 플레인 기능은 에이전트가 Ignition을 가져오는 데 사용하는 토큰을 주기적으로 순환합니다. 버그로 인해 새 토큰이 전파되지 않습니다. 그 결과 잠시 전에 생성된 에이전트 리소스가 있는 경우 Ignition을 가져오지 못할 수 있습니다.

이 문제를 해결하려면 에이전트 사양에서 IgnitionEndpointTokenReference 속성이 참조하는 보안을 삭제한 다음 에이전트 리소스에서 레이블을 추가하거나 수정합니다. 그런 다음 시스템은 에이전트 리소스가 수정되었음을 감지하고 새 토큰을 사용하여 시크릿을 다시 생성할 수 있습니다.

중요:

RBAC는 콘솔 수준 및 API 수준에서 검증됩니다. 콘솔의 작업은 사용자 액세스 역할 권한에 따라 활성화하거나 비활성화할 수 있습니다. 제품의 특정 라이프사이클에 대한 RBAC에 대한 자세한 내용은 다음 섹션을 참조하십시오.

다음 클러스터 풀 RBAC 작업을 확인합니다.

클러스터 라이프사이클에 대해 다음 콘솔 및 API RBAC 테이블을 확인합니다.

인증 정보에 대한 액세스는 Kubernetes에서 제어합니다. 인증 정보는 Kubernetes 시크릿으로 저장되고 보호됩니다. 다음 권한은 Red Hat Advanced Cluster Management for Kubernetes의 보안에 적용됩니다.

OpenShift Container Platform 설명서에서 인프라 머신 세트 생성에 설명된 절차를 따르십시오. 인프라 노드는 관리되지 않은 워크로드가 해당 워크로드가 실행되지 않도록 Kubernetes taint 및 레이블 로 구성됩니다.

다중 클러스터 엔진 Operator에서 제공하는 인프라 노드 활성화와 호환되려면 인프라 노드에 다음과 같은 테인트 및 라벨이 적용되어야 합니다.

metadata:
  labels:
    node-role.kubernetes.io/infra: ""
spec:
  taints:
  - effect: NoSchedule
    key: node-role.kubernetes.io/infra

Operator Lifecycle Manager 서브스크립션을 적용하기 전에 다음 추가 구성을 추가합니다.

spec:
  config:
    nodeSelector:
      node-role.kubernetes.io/infra: ""
    tolerations:
    - key: node-role.kubernetes.io/infra
      effect: NoSchedule
      operator: Exists

MultiClusterEngine 사용자 정의 리소스를 적용하기 전에 다음 추가 구성을 추가합니다.

spec:
  nodeSelector:
    node-role.kubernetes.io/infra: ""

Amazon S3(Simple Storage Service) 시크릿을 생성하려면 콘솔에서 다음 작업을 완료합니다.

릴리스 이미지를 참조하는 YAML 파일은 acm-hive-openshift-releases GitHub 리포지토리에서 유지 관리됩니다. 파일은 콘솔에서 사용 가능한 릴리스 이미지 목록을 생성하는 데 사용됩니다. 여기에는 OpenShift Container Platform의 최신 빠른 채널 이미지가 포함됩니다.

콘솔에는 세 가지 최신 버전의 OpenShift Container Platform의 최신 릴리스 이미지만 표시됩니다. 예를 들어 콘솔 옵션에 다음 릴리스 이미지가 표시될 수 있습니다.

quay.io/openshift-release-dev/ocp-release:4.13.1-x86_64

콘솔에 최신 릴리스 이미지로 클러스터를 생성하는 데 도움이 되는 최신 버전이 표시됩니다. 특정 버전의 클러스터를 생성해야 하는 경우 이전 릴리스 이미지 버전도 사용할 수 있습니다.

참고: 콘솔에 클러스터를 생성할 때 표시되는 이미지: 'true' 레이블이 있는 이미지만 선택할 수 있습니다. ClusterImageSet 리소스의 이 레이블의 예는 다음 콘텐츠에 제공됩니다. 4.x.1 을 제품의 현재 버전으로 바꿉니다.

apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  labels:
    channel: fast
    visible: 'true'
  name: img4.x.1-x86-64-appsub
spec:
  releaseImage: quay.io/openshift-release-dev/ocp-release:4.x.1-x86_64

추가 릴리스 이미지가 저장되지만 콘솔에는 표시되지 않습니다. 사용 가능한 모든 릴리스 이미지를 보려면 다음 명령을 실행합니다.

oc get clusterimageset

리포지토리에는 릴리스 이미지로 작업할 때 사용하는 디렉터리인 clusterImageSets 디렉터리가 있습니다. clusterImageSets 디렉터리에는 다음과 같은 디렉터리가 있습니다.

다음 옵션을 사용하여 ClusterImageSet 을 구성할 수 있습니다.

두 아키텍처의 파일이 있는 릴리스 이미지를 수동으로 생성하여 허브 클러스터의 아키텍처와 다른 아키텍처에 클러스터를 생성할 수 있습니다.

예를 들어 ppc64le,aarch64 또는 s390x 아키텍처에서 실행 중인 hub 클러스터에서 x86_64 클러스터를 생성해야 할 수 있습니다. 두 파일 세트를 모두 사용하여 릴리스 이미지를 생성하는 경우 새 릴리스 이미지를 사용하면 OpenShift Container Platform 릴리스 레지스트리에서 다중 아키텍처 이미지 매니페스트를 제공할 수 있으므로 클러스터 생성이 성공합니다.

OpenShift Container Platform 4.13 이상에서는 기본적으로 여러 아키텍처를 지원합니다. 다음 clusterImageSet 을 사용하여 클러스터를 프로비저닝할 수 있습니다. 4.x.0 을 현재 버전으로 바꿉니다.

apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  labels:
    channel: fast
    visible: 'true'
  name: img4.x.0-multi-appsub
spec:
  releaseImage: quay.io/openshift-release-dev/ocp-release:4.x.0-multi

여러 아키텍처를 지원하지 않는 OpenShift Container Platform 이미지의 릴리스 이미지를 생성하려면 아키텍처 유형에 대해 다음 예와 유사한 단계를 완료합니다.

생성 프로세스에서는 병합된 릴리스 이미지를 사용하여 클러스터를 생성합니다.

중앙 인프라 관리 서비스를 활성화하기 전에 다음 사전 요구 사항을 참조하십시오.

중앙 인프라 관리 서비스를 활성화하기 전에 베어 메탈 호스트 사용자 정의 리소스 정의가 필요합니다.

중앙 인프라 관리 서비스를 활성화하려면 프로비저닝 리소스가 필요합니다.

연결이 끊긴 환경에서 중앙 인프라 관리를 활성화하려면 다음 단계를 완료합니다.

중요: 헤더 및 쿼리 매개변수는 HTTPS를 사용하는 경우에만 암호화됩니다. 보안 문제를 방지하려면 HTTPS를 사용해야 합니다.

자체 서명 또는 타사 CA 인증서가 있는 HTTPS osImages 를 사용하는 경우 OSImageCACertRef 사양의 인증서를 참조하십시오.

중요: AgentServiceConfig 사용자 정의 리소스의 spec.osImages 릴리스를 버전 4.13 이상인 경우 클러스터를 생성할 때 사용하는 OpenShift Container Platform 릴리스 이미지는 버전 4.13 이상이어야 합니다. 버전 4.13 이상용 Red Hat Enterprise Linux CoreOS 이미지는 버전 4.13 이전의 이미지와 호환되지 않습니다.

assisted-service 및 assisted-image-service 배포를 확인하고 Pod가 준비되어 실행 중인지 확인하여 중앙 인프라 관리 서비스가 정상인지 확인할 수 있습니다.

연결된 환경에서 중앙 인프라 관리를 활성화하려면 agent_service_config.yaml 파일에 다음 YAML 콘텐츠를 저장하여 AgentServiceConfig 사용자 지정 리소스를 생성합니다.

apiVersion: agent-install.openshift.io/v1beta1
kind: AgentServiceConfig
metadata:
 name: agent
spec:
  databaseStorage:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: <db_volume_size> 1
  filesystemStorage:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: <fs_volume_size> 2
  imageStorage:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: <img_volume_size> 3

중앙 인프라 관리 서비스가 구성되어 있습니다. assisted-service 및 assisted-image-service 배포를 확인하고 Pod가 준비되고 실행 중인지 확인하여 정상 상태인지 확인할 수 있습니다.

콘솔을 사용하여 호스트 인벤토리를 생성하려면 다음 단계를 완료합니다.

콘솔에서 사용할 수 없는 고급 구성 옵션이 필요한 경우 명령줄 인터페이스를 사용하여 호스트 인벤토리 생성을 계속합니다.

고급 구성 옵션이 필요하지 않은 경우 정적 네트워킹을 구성하여 계속해서 인프라 환경에 호스트를 추가할 수 있습니다.

호스트 인벤토리에 액세스하려면 콘솔에서 인프라 > 호스트 인벤토리 를 선택합니다. 목록에서 인프라 환경을 선택하여 세부 정보 및 호스트를 확인합니다.

명령줄 인터페이스를 사용하여 호스트 인벤토리(인프라 환경)를 생성하려면 다음 단계를 완료합니다.

다음 주요 속성 목록을 참조하십시오.

참고: InfraEnv 리소스를 수정하는 경우, createdTime 속성을 확인하여 InfraEnv 에서 새 Discovery Image를 생성했는지 확인합니다. 이미 호스트를 부팅한 경우 최신 Discovery Image를 사용하여 다시 부팅합니다.

필요한 경우 정적 네트워킹을 구성하고 인프라 환경에 호스트를 추가할 수 있습니다.

명령줄 인터페이스를 사용하여 인프라 환경에 대한 고급 네트워킹을 구성하려면 다음 단계를 완료합니다.

참고: 이미지 서비스는 InfraEnv 속성을 업데이트하거나 레이블 선택기와 일치하는 NMStateConfig 리소스를 변경할 때 새 이미지를 자동으로 생성합니다. InfraEnv 리소스를 생성한 후 NMStateConfig 리소스를 추가하는 경우 InfraEnv에서 InfraEnv 에서 createdTime 속성을 확인하여 새 Discovery Image를 생성해야 합니다. 이미 호스트를 부팅한 경우 최신 Discovery Image를 사용하여 다시 부팅합니다.

다음 단계를 완료하여 ISO를 다운로드합니다.

이제 ISO를 다운로드할 URL이 표시됩니다. 부팅된 호스트가 호스트 인벤토리 테이블에 나타납니다. 호스트가 표시되는 데 몇 분이 걸릴 수 있습니다. 각 호스트를 사용하려면 먼저 승인해야 합니다. 작업을 클릭하고 승인을 선택하여 인벤토리 테이블에서 호스트를 선택할 수 있습니다.

InfraEnv 리소스의 상태에서 isoDownloadURL 속성에서 ISO를 다운로드하는 URL을 볼 수 있습니다. InfraEnv 리소스에 대한 자세한 내용은 명령줄 인터페이스를 사용하여 호스트 인벤토리 생성을 참조하십시오.

부팅된 각 호스트는 동일한 네임스페이스에 에이전트 리소스를 생성합니다. 각 호스트를 사용하려면 먼저 승인해야 합니다.

콘솔을 사용하여 호스트 인벤토리에 베어 메탈 호스트를 자동으로 추가하려면 다음 단계를 완료합니다.

명령줄 인터페이스를 사용하여 호스트 인벤토리에 베어 메탈 호스트를 자동으로 추가하려면 다음 단계를 완료합니다.

호스트를 켜면 이미지가 다운로드되기 시작합니다. 이 작업은 몇 분 정도 걸릴 수 있습니다. 호스트가 검색되면 에이전트 사용자 지정 리소스가 자동으로 생성됩니다.

통합 흐름은 기본적으로 활성화되어 있습니다. 호스트가 나타나지 않으면 통합 흐름을 일시적으로 비활성화해야 할 수 있습니다. 통합 흐름을 비활성화하려면 다음 단계를 완료합니다.

관리형 클러스터에서 관리형 클러스터 노드를 제거하려면 OpenShift Container Platform 버전 4.13 이상을 실행 중인 허브 클러스터가 필요합니다. 노드를 부팅하는 데 필요한 정적 네트워킹 구성을 사용할 수 있어야 합니다. 에이전트 및 베어 메탈 호스트를 삭제할 때 NMStateConfig 리소스를 삭제하지 마십시오.

Discovery ISO로 성공적으로 부팅한 각 호스트는 호스트 인벤토리에 행으로 표시됩니다. 콘솔을 사용하여 호스트를 편집하고 관리할 수 있습니다. 호스트를 수동으로 부팅하고 베어 메탈 Operator 자동화를 사용하지 않는 경우 콘솔에서 호스트를 승인해야 사용할 수 있습니다. OpenShift 노드로 설치할 준비가 된 호스트의 상태는 Available 입니다.

에이전트 리소스는 각 호스트를 나타냅니다. 에이전트 리소스에서 다음 속성을 설정할 수 있습니다.

에이전트 리소스의 상태에 는 다음과 같은 속성이 있습니다.

클러스터를 생성하기 전에 clusterImageSets 리포지토리를 복제하여 hub 클러스터에 적용해야 합니다. 다음 단계를 참조하십시오.

클러스터를 생성할 때 Red Hat OpenShift Container Platform 릴리스 이미지를 선택합니다.

참고: Nutanix 플랫폼을 사용하는 경우 ClusterImageSet 리소스의 releaseImage 에 x86_64 아키텍처를 사용하고 표시되는 라벨 값을 'true' 로 설정해야 합니다. 다음 예제를 참조하십시오.

apiVersion: hive.openshift.io/v1
kind: ClusterImageSet
metadata:
  labels:
    channel: stable
    visible: 'true'
  name: img4.x.47-x86-64-appsub
spec:
  releaseImage: quay.io/openshift-release-dev/ocp-release:4.x.47-x86_64

ClusterDeployment 은 클러스터의 라이프사이클을 제어하는 데 사용되는 Hive 사용자 정의 리소스입니다.

Hive 사용 설명서에 따라 ClusterDeployment 사용자 정의 리소스를 생성하고 개별 클러스터를 생성합니다.

ClusterPool 은 여러 클러스터를 생성하는 데 사용되는 Hive 사용자 정의 리소스이기도 합니다.

Cluster Pools 문서에 따라 Hive ClusterPool API로 클러스터를 생성합니다.