1.9. 호스트 인벤토리 소개
호스트 인벤토리 관리 및 온-프레미스 클러스터 설치는 다중 클러스터 엔진 Operator 중앙 인프라 관리 기능을 사용하여 사용할 수 있습니다.
주요 인프라 관리 기능은 라이프사이클 동안 베어 메탈 호스트를 관리하는 데 중점을 둔 멀티 클러스터 엔진 Operator의 Red Hat OpenShift Container Platform 설치 경험입니다.
지원 설치 프로그램은 에이전트를 사용하여 대상 호스트에서 사전 설치된 검증을 실행하는 OpenShift Container Platform 설치 방법과 설치 진행 상황을 평가하고 추적하는 중앙 서비스입니다.
Red Hat OpenShift용 인프라 Operator는 지원 설치 관리자 서비스를 실행하는 워크로드를 관리하고 설치하는 다중 클러스터 엔진 운영자 구성 요소입니다.
콘솔을 사용하여 온프레미스 OpenShift Container Platform 클러스터를 생성하는 데 사용할 수 있는 베어 메탈 또는 가상 머신 풀인 호스트 인벤토리를 생성할 수 있습니다. 이러한 클러스터는 컨트롤 플레인 전용 머신 또는 컨트롤 플레인의 전용 머신이 있는 독립 실행형 클러스터일 수 있습니다. 여기서 컨트롤 플레인은 허브 클러스터에서 Pod로 실행됩니다. ../../html-single/..#hosted-control-planes-intro
ZTP(ZTP)를 사용하여 콘솔, API 또는 GitOps를 사용하여 독립 실행형 클러스터를 설치할 수 있습니다. ZTP에 대한 자세한 내용은 Red Hat OpenShift Container Platform 설명서의 연결이 끊긴 환경에 GitOps ZTP 설치를 참조하십시오.
시스템은 Discovery Image로 부팅한 후 호스트 인벤토리를 결합합니다. Discovery Image는 다음이 포함된 Red Hat CoreOS 라이브 이미지입니다.
- 검색, 검증 및 설치 작업을 수행하는 에이전트입니다.
- 해당하는 경우 엔드포인트, 토큰, 정적 네트워크 구성을 포함하여 허브 클러스터에서 서비스에 연결하는 데 필요한 구성입니다.
공통 속성 세트를 공유하는 호스트 세트인 각 인프라 환경에 대해 하나의 Discovery Image가 있습니다. InfraEnv
사용자 정의 리소스 정의는 이 인프라 환경 및 관련 Discovery Image를 나타냅니다. InfraEnv
사용자 정의 리소스에서 osImageVersion
필드를 설정하여 검색 이미지에 사용되는 Red Hat Core OS 버전을 지정할 수 있습니다. 값을 지정하지 않으면 최신 Red Hat Core OS 버전이 사용됩니다.
호스트가 부팅되고 에이전트가 서비스에 연결되면 서비스는 해당 호스트를 나타내는 허브 클러스터에 새 Agent
사용자 정의 리소스를 생성합니다. 에이전트
리소스는 호스트 인벤토리를 구성합니다.
나중에 OpenShift 노드로 인벤토리에 호스트를 설치할 수 있습니다. 에이전트는 필요한 구성과 함께 운영 체제를 디스크에 쓰고 호스트를 재부팅합니다.
참고: Red Hat Advanced Cluster Management 2.9 이상 및 중앙 인프라 관리는 Nutanix 가상 머신을 생성하여 추가 구성이 필요한 AgentClusterInstall
을 사용하여 Nutanix 플랫폼을 지원합니다. 자세한 내용은 지원 설치 관리자 설명서의 선택적: Nutanix에 설치를 참조하십시오.
호스트 인벤토리 및 중앙 인프라 관리에 대해 자세히 알아보려면 계속 읽으십시오.
1.9.1. 중앙 인프라 관리 서비스 활성화
중앙 인프라 관리 서비스는 다중 클러스터 엔진 Operator와 함께 제공되며 OpenShift Container Platform 클러스터를 배포합니다. 허브 클러스터에서 MultiClusterHub Operator를 활성화하면 중앙 인프라 관리 서비스가 자동으로 배포되지만 서비스를 수동으로 활성화해야 합니다.
1.9.1.1. 사전 요구 사항
중앙 인프라 관리 서비스를 활성화하기 전에 다음 사전 요구 사항을 참조하십시오.
- 지원되는 OpenShift Container Platform 버전과 지원되는 Red Hat Advanced Cluster Management for Kubernetes 버전에 배포된 허브 클러스터가 있어야 합니다.
- 허브 클러스터(연결됨)에 대한 인터넷 액세스 또는 환경 생성에 필요한 이미지를 검색하기 위해 인터넷에 연결되어 있는 내부 또는 미러 레지스트리에 대한 연결이 필요합니다.
- 베어 메탈 프로비저닝에 필요한 포트를 열어야 합니다. OpenShift Container Platform 설명서에서 필요한 포트 활성화를 참조하십시오.
- 베어 메탈 호스트 사용자 정의 리소스 정의가 필요합니다.
- OpenShift Container Platform 풀 시크릿 이 필요합니다. 자세한 내용은 이미지 풀 시크릿 사용을 참조하십시오.
- 구성된 기본 스토리지 클래스가 필요합니다.
- 연결이 끊긴 환경의 경우 OpenShift Container Platform 설명서에서 네트워크 맨 엣지에서 클러스터에 대한 절차를 완료합니다.
다음 섹션을 참조하십시오.
1.9.1.2. 베어 메탈 호스트 사용자 정의 리소스 정의 생성
중앙 인프라 관리 서비스를 활성화하기 전에 베어 메탈 호스트 사용자 정의 리소스 정의가 필요합니다.
다음 명령을 실행하여 베어 메탈 호스트 사용자 정의 리소스 정의가 있는지 확인합니다.
oc get crd baremetalhosts.metal3.io
- 베어 메탈 호스트 사용자 정의 리소스 정의가 있는 경우 출력에 리소스가 생성된 날짜가 표시됩니다.
- 리소스가 없는 경우 다음과 유사한 오류가 표시됩니다.
Error from server (NotFound): customresourcedefinitions.apiextensions.k8s.io "baremetalhosts.metal3.io" not found
베어 메탈 호스트 사용자 정의 리소스 정의가 없는 경우 metal3.io_baremetalhosts.yaml 파일을 다운로드하고 다음 명령을 실행하여 리소스를 생성하여 콘텐츠를 적용합니다.
oc apply -f
1.9.1.3. 프로비저닝 리소스 생성 또는 수정
중앙 인프라 관리 서비스를 활성화하려면 프로비저닝
리소스가 필요합니다.
다음 명령을 실행하여
프로비저닝
리소스가 있는지 확인합니다.oc get provisioning
-
프로비저닝 리소스가 이미 있는 경우
프로비저닝
리소스 를 계속 수정합니다. -
프로비저닝
리소스가 없는 경우 리소스를 찾을 수 없음
오류가 표시됩니다.프로비저닝
리소스 생성을 계속합니다.
-
프로비저닝 리소스가 이미 있는 경우
1.9.1.3.1. 프로비저닝 리소스 수정
프로비저닝
리소스가 이미 있는 경우 hub 클러스터가 다음 플랫폼 중 하나에 설치된 경우 리소스를 수정해야 합니다.
- 베어 메탈
- Red Hat OpenStack Platform
- VMware vSphere
-
사용자 프로비저닝 인프라(UPI) 방법 및 플랫폼은
None
입니다.
허브 클러스터가 다른 플랫폼에 설치된 경우 연결이 끊긴 환경에서 중앙 인프라 관리 활성화 또는 연결된 환경에서 중앙 인프라 관리 활성화에서 계속 진행하십시오.
다음 명령을 실행하여 Bare Metal Operator가 모든 네임스페이스를 조사할 수 있도록
프로비저닝
리소스를 수정합니다.oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"watchAllNamespaces": true }}'
1.9.1.3.2. 프로비저닝 리소스 생성
프로비저닝
리소스가 없는 경우 다음 단계를 완료합니다.
다음 YAML 콘텐츠를 추가하여
프로비저닝
리소스를 생성합니다.apiVersion: metal3.io/v1alpha1 kind: Provisioning metadata: name: provisioning-configuration spec: provisioningNetwork: "Disabled" watchAllNamespaces: true
다음 명령을 실행하여 콘텐츠를 적용합니다.
oc apply -f
1.9.1.4. 연결이 끊긴 환경에서 중앙 인프라 관리 활성화
연결이 끊긴 환경에서 중앙 인프라 관리를 활성화하려면 다음 단계를 완료합니다.
인프라 Operator와 동일한 네임스페이스에
ConfigMap
을 생성하여 미러 레지스트리의ca-bundle.crt
및registries.conf
값을 지정합니다. 파일ConfigMap
은 다음 예와 유사할 수 있습니다.apiVersion: v1 kind: ConfigMap metadata: name: <mirror-config> namespace: multicluster-engine labels: app: assisted-service data: ca-bundle.crt: | <certificate-content> registries.conf: | unqualified-search-registries = ["registry.access.redhat.com", "docker.io"] [[registry]] prefix = "" location = "registry.redhat.io/multicluster-engine" mirror-by-digest-only = true [[registry.mirror]] location = "mirror.registry.com:5000/multicluster-engine"
참고: 다이제스트를 사용하여 릴리스 이미지가 지정되므로
mirror-by-digest-only
를true
로 설정해야 합니다.unqualified-search-registries
목록의 레지스트리는PUBLIC_CONTAINER_REGISTRIES
환경 변수의 인증 무시 목록에 자동으로 추가됩니다. 관리 클러스터의 풀 시크릿을 검증할 때 지정된 레지스트리는 인증이 필요하지 않습니다.-
모든
osImage
요청과 함께 보낼 헤더 및 쿼리 매개변수를 나타내는 키 쌍을 작성합니다. 두 매개변수가 모두 필요하지 않은 경우 헤더 또는 쿼리 매개변수에만 대한 키 쌍을 작성합니다.
중요: 헤더 및 쿼리 매개변수는 HTTPS를 사용하는 경우에만 암호화됩니다. 보안 문제를 방지하려면 HTTPS를 사용해야 합니다.
headers
라는 파일을 생성하고 다음 예제와 유사한 콘텐츠를 추가합니다.{ "Authorization": "Basic xyz" }
query_params
라는 파일을 생성하고 다음 예와 유사한 콘텐츠를 추가합니다.{ "api_key": "myexampleapikey", }
다음 명령을 실행하여 생성한 매개변수 파일에서 시크릿을 생성합니다. 하나의 매개변수 파일만 생성한 경우 생성하지 않은 파일의 인수를 제거합니다.
oc create secret generic -n multicluster-engine os-images-http-auth --from-file=./query_params --from-file=./headers
자체 서명 또는 타사 CA 인증서와 함께 HTTPS
osImages
를 사용하려면image-service-additional-ca
ConfigMap
에 인증서를 추가합니다. 인증서를 생성하려면 다음 명령을 실행합니다.oc -n multicluster-engine create configmap image-service-additional-ca --from-file=tls.crt
-
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> filesystemStorage: accessModes: - ReadWriteOnce resources: requests: storage: <fs_volume_size> mirrorRegistryRef: name: <mirror_config> 1 unauthenticatedRegistries: - <unauthenticated_registry> 2 imageStorage: accessModes: - ReadWriteOnce resources: requests: storage: <img_volume_size> 3 OSImageAdditionalParamsRef: name: os-images-http-auth OSImageCACertRef: name: image-service-additional-ca osImages: - openshiftVersion: "<ocp_version>" 4 version: "<ocp_release_version>" 5 url: "<iso_url>" 6 cpuArchitecture: "x86_64"
+
- 1
mirror_config
를 미러 레지스트리 구성 세부 정보가 포함된ConfigMap
의 이름으로 교체합니다.- 2
- 인증이 필요하지 않은 미러 레지스트리를 사용하는 경우 선택적
unauthenticated_registry
매개변수를 포함합니다. 이 목록의 항목은 검증되지 않았거나 풀 시크릿에 항목이 있어야 합니다. - 3
img_volume_size
를imageStorage
필드의 볼륨 크기로 바꿉니다(예: 운영 체제 이미지당10Gi
). 최소 값은10Gi
이지만 권장 값은 최소50Gi
입니다. 이 값은 클러스터 이미지에 할당된 스토리지 양을 지정합니다. 실행 중인 Red Hat Enterprise Linux CoreOS의 각 인스턴스에 대해 1GB의 이미지 스토리지를 허용해야 합니다. Red Hat Enterprise Linux CoreOS 클러스터 및 인스턴스가 많은 경우 더 높은 값을 사용해야 할 수 있습니다.- 4
ocp_version
을 설치할 OpenShift Container Platform 버전으로 교체합니다(예:4.14
).- 5
ocp_release_version
을 특정 설치 버전 (예:49.83.202103251640-0
)으로 바꿉니다.- 6
iso_url
을 ISO URL로 바꿉니다(예:https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.13/4.13.3/rhcos-4.13.3-x86_64-live.x86_64.iso
). rhoc 에서 다른 값을 찾을 수 있습니다.
자체 서명 또는 타사 CA 인증서가 있는 HTTPS osImages
를 사용하는 경우 OSImageCACertRef
사양의 인증서를 참조하십시오.
중요: AgentServiceConfig
사용자 정의 리소스의 spec.osImages
릴리스를 버전 4.13 이상인 경우 클러스터를 생성할 때 사용하는 OpenShift Container Platform 릴리스 이미지가 동일해야 합니다. 버전 4.13 이상용 Red Hat Enterprise Linux CoreOS 이미지는 이전 이미지와 호환되지 않습니다.
assisted-service
및 assisted-image-service
배포를 확인하고 Pod가 준비되어 실행 중인지 확인하여 중앙 인프라 관리 서비스가 정상인지 확인할 수 있습니다.
1.9.1.5. 연결된 환경에서 중앙 인프라 관리 활성화
연결된 환경에서 중앙 인프라 관리를 활성화하려면 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
- 1
db_volume_size
를databaseStorage
필드의 볼륨 크기(예:10Gi
)로 바꿉니다. 이 값은 클러스터의 데이터베이스 테이블 및 데이터베이스 뷰와 같은 파일을 저장하기 위해 할당된 스토리지 양을 지정합니다. 필요한 최소 값은1Gi
입니다. 클러스터가 여러 개인 경우 더 높은 값을 사용해야 할 수 있습니다.- 2
fs_volume_size
를filesystemStorage
필드의 볼륨 크기로 바꿉니다(예: 클러스터당200M
, 지원되는 OpenShift Container Platform 버전당2-3Gi
). 필요한 최소 값은1Gi
이지만 권장 값은100Gi
이상이어야 합니다. 이 값은 클러스터의 로그, 매니페스트 및kubeconfig
파일을 저장하기 위해 할당된 스토리지 양을 지정합니다. 클러스터가 여러 개인 경우 더 높은 값을 사용해야 할 수 있습니다.- 3
img_volume_size
를imageStorage
필드의 볼륨 크기로 바꿉니다(예: 운영 체제 이미지당10Gi
). 최소 값은10Gi
이지만 권장 값은 최소50Gi
입니다. 이 값은 클러스터 이미지에 할당된 스토리지 양을 지정합니다. 실행 중인 Red Hat Enterprise Linux CoreOS의 각 인스턴스에 대해 1GB의 이미지 스토리지를 허용해야 합니다. Red Hat Enterprise Linux CoreOS 클러스터 및 인스턴스가 많은 경우 더 높은 값을 사용해야 할 수 있습니다.
중앙 인프라 관리 서비스가 구성되어 있습니다. assisted-service
및 assisted-image-service
배포를 확인하고 Pod가 준비되고 실행 중인지 확인하여 정상 상태인지 확인할 수 있습니다.
1.9.1.6. 지원 설치 관리자를 사용하여 FIPS 지원 클러스터 설치
FIPS 모드에 있는 OpenShift Container Platform 클러스터 버전 4.15 및 이전 버전을 설치할 때 AgentServiceConfig
리소스에서 설치 프로그램이 RHEL (Red Hat Enterprise Linux) 버전 8을 실행하도록 지정해야 합니다.
필수 액세스: AgentServiceConfig
및 AgentClusterInstall
리소스를 편집할 수 있는 권한이 있어야 합니다.
AgentServiceConfig
리소스를 업데이트하려면 다음 단계를 완료합니다.
다음 명령을 사용하여 관리 클러스터에 로그인합니다.
oc login
AgentServiceConfig
리소스에agent-install.openshift.io/service-image-base: el8
주석을 추가합니다.AgentServiceConfig
리소스는 다음 YAML과 유사할 수 있습니다.apiVersion: agent-install.openshift.io/v1beta1 kind: AgentServiceConfig metadata: annotations: agent-install.openshift.io/service-image-base: el8 ...
1.9.1.7. 추가 리소스
- 제로 터치 프로비저닝에 대한 자세한 내용은 OpenShift Container Platform 설명서 의 네트워크 맨 위까지의 챌린지 를 참조하십시오.
- 이미지 풀 시크릿 사용
1.9.2. Amazon Web Services에서 중앙 인프라 관리 활성화
Amazon Web Services에서 Hub 클러스터를 실행하고 중앙 인프라 관리 서비스를 활성화하려면 중앙 인프라 관리 서비스를 활성화한 후 다음 단계를 완료합니다.
hub 클러스터에 로그인했는지 확인하고 다음 명령을 실행하여
assisted-image-service
에 구성된 고유한 도메인을 찾습니다.oc get routes --all-namespaces | grep assisted-image-service
도메인은 다음 예와 유사할 수 있습니다.
assisted-image-service-multicluster-engine.apps.<yourdomain>.com
hub 클러스터에 로그인했는지 확인하고
NLB
type
매개변수를 사용하여 고유한 도메인으로 새IngressController
를 생성합니다. 다음 예제를 참조하십시오.apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: ingress-controller-with-nlb namespace: openshift-ingress-operator spec: domain: nlb-apps.<domain>.com routeSelector: matchLabels: router-type: nlb endpointPublishingStrategy: type: LoadBalancerService loadBalancer: scope: External providerParameters: type: AWS aws: type: NLB
-
nlb-apps.<
매개변수에 <domain
>.com에서 <yourdomain
>을 <yourdomain>으로 교체하여IngressController
의 domainyourdomain
>을 추가합니다. 다음 명령을 실행하여 새
IngressController
를 적용합니다.oc apply -f ingresscontroller.yaml
다음 단계를 완료하여 새
IngressController
의spec.domain
매개변수 값이 기존IngressController
와 충돌하지 않는지 확인합니다.다음 명령을 실행하여 모든
IngressController
를 나열합니다.oc get ingresscontroller -n openshift-ingress-operator
방금 생성한
ingress-controller-with-nlb
를 제외하고 각IngressController
에서 다음 명령을 실행합니다.oc edit ingresscontroller <name> -n openshift-ingress-operator
spec.domain
보고서가 없는 경우nlb-apps.<domain>.com을 제외한 클러스터에 노출된 모든 경로와 일치하는 기본 도메인
을 추가합니다.spec.domain
보고서가 제공된 경우nlb-apps.<domain>.com
경로가 지정된 범위에서 제외되었는지 확인합니다.
다음 명령을 실행하여
nlb-apps
위치를 사용하도록assisted-image-service
경로를 편집합니다.oc edit route assisted-image-service -n <namespace>
기본 네임스페이스는 다중 클러스터 엔진 Operator를 설치한 위치입니다.
assisted-image-service
경로에 다음 행을 추가합니다.metadata: labels: router-type: nlb name: assisted-image-service
assisted-image-service
경로에서spec.host
의 URL 값을 찾습니다. URL은 다음 예와 유사할 수 있습니다.assisted-image-service-multicluster-engine.apps.<yourdomain>.com
-
새
IngressController
에 구성된 도메인과 일치하도록 URL의 앱을nlb-
로 교체합니다.apps
Amazon Web Services에서 중앙 인프라 관리 서비스가 활성화되어 있는지 확인하려면 다음 명령을 실행하여 Pod가 정상 상태인지 확인합니다.
oc get pods -n multicluster-engine | grep assist
-
새 호스트 인벤토리를 생성하고 다운로드 URL이 새
nlb-apps
URL을 사용하는지 확인합니다.
1.9.3. 콘솔을 사용하여 호스트 인벤토리 생성
호스트 인벤토리(인프라 환경)를 생성하여 OpenShift Container Platform 클러스터를 설치할 수 있는 물리적 또는 가상 머신을 검색할 수 있습니다.
1.9.3.1. 사전 요구 사항
- 중앙 인프라 관리 서비스를 활성화해야 합니다. 자세한 내용은 중앙 인프라 관리 서비스 활성화를 참조하십시오.
1.9.3.2. 호스트 인벤토리 생성
콘솔을 사용하여 호스트 인벤토리를 생성하려면 다음 단계를 완료합니다.
- 콘솔에서 인프라 > 호스트 인벤토리 로 이동하여 인프라 환경 생성 을 클릭합니다.
호스트 인벤토리 설정에 다음 정보를 추가합니다.
-
이름: 인프라 환경의 고유 이름입니다. 콘솔을 사용하여 인프라 환경을 생성하면 선택한 이름으로
InfraEnv
리소스의 새 네임스페이스도 생성됩니다. 명령줄 인터페이스를 사용하여InfraEnv
리소스를 생성하고 콘솔에서 리소스를 모니터링하려면 네임스페이스와InfraEnv
에 동일한 이름을 사용합니다. - 네트워크 유형: 인프라 환경에 추가하는 호스트가 DHCP 또는 정적 네트워킹을 사용하는지 여부를 지정합니다. 정적 네트워킹 구성에는 추가 단계가 필요합니다.
- Location: 호스트의 지리적 위치를 지정합니다. 지리적 위치는 호스트가 있는 데이터 센터를 정의하는 데 사용할 수 있습니다.
- labels: 이 인프라 환경에서 검색된 호스트에 레이블을 추가할 수 있는 선택적 필드입니다. 지정된 위치가 레이블 목록에 자동으로 추가됩니다.
- 인프라 공급자 인증 정보: 인프라 공급자 인증 정보를 선택하면 풀 시크릿 및 SSH 공개 키 필드가 인증 정보에 자동으로 채워집니다. 자세한 내용은 온-프레미스 환경에 대한 인증 정보 만들기 를 참조하십시오.
- 풀 시크릿: OpenShift Container Platform 리소스에 액세스할 수 있는 OpenShift Container Platform 풀 시크릿 입니다. 인프라 공급자 인증 정보를 선택한 경우 이 필드가 자동으로 채워집니다.
-
SSH 공개 키: 호스트와의 보안 통신을 활성화하는 SSH 키입니다. 문제 해결을 위해 호스트에 연결하는 데 사용할 수 있습니다. 클러스터를 설치한 후에는 더 이상 SSH 키를 사용하여 호스트에 연결할 수 없습니다. 키는 일반적으로
id_rsa.pub
파일에 있습니다. 기본 파일 경로는~/.ssh/id_rsa.pub
입니다. SSH 공개 키 값이 포함된 인프라 공급자 인증 정보를 선택한 경우 이 필드가 자동으로 채워집니다. 호스트에 프록시 설정을 활성화하려면 활성화할 설정을 선택하고 다음 정보를 입력합니다.
- HTTP 프록시 URL: HTTP 요청에 대한 프록시의 URL입니다.
- HTTPS 프록시 URL: HTTP 요청에 대한 프록시의 URL입니다. URL은 HTTP로 시작해야 합니다. HTTPS는 지원되지 않습니다. 값을 지정하지 않으면 HTTP 프록시 URL이 기본적으로 HTTP 및 HTTPS 연결에 사용됩니다.
-
프록시 도메인 없음: 프록시를 사용하지 않으려는 쉼표로 구분된 도메인 목록입니다. 마침표(
.
)로 도메인 이름을 시작하여 해당 도메인에 있는 모든 하위 도메인을 포함합니다. 모든 대상에 대해 프록시를 바이패스하려면 별표(*
)를 추가합니다.
- 선택적으로 NTP 풀 또는 서버의 쉼표로 구분된 IP 또는 도메인 이름 목록을 제공하여 고유한 NTP(Network Time Protocol) 소스를 추가합니다.
-
이름: 인프라 환경의 고유 이름입니다. 콘솔을 사용하여 인프라 환경을 생성하면 선택한 이름으로
콘솔에서 사용할 수 없는 고급 구성 옵션이 필요한 경우 명령줄 인터페이스를 사용하여 호스트 인벤토리 생성을 계속합니다.
고급 구성 옵션이 필요하지 않은 경우 정적 네트워킹을 구성하여 계속해서 인프라 환경에 호스트를 추가할 수 있습니다.
1.9.3.3. 호스트 인벤토리에 액세스
호스트 인벤토리에 액세스하려면 콘솔에서 인프라 > 호스트 인벤토리 를 선택합니다. 목록에서 인프라 환경을 선택하여 세부 정보 및 호스트를 확인합니다.
1.9.3.4. 추가 리소스
베어 메탈에서 호스팅된 컨트롤 플레인을 구성하는 프로세스의 일부로 호스트 인벤토리를 생성한 경우 다음 절차를 완료합니다.
1.9.4. 명령줄 인터페이스를 사용하여 호스트 인벤토리 생성
호스트 인벤토리(인프라 환경)를 생성하여 OpenShift Container Platform 클러스터를 설치할 수 있는 물리적 또는 가상 머신을 검색할 수 있습니다. 자동화된 배포를 위해 콘솔 대신 명령행 인터페이스를 사용하거나 다음 고급 구성 옵션에 사용합니다.
- 검색된 호스트를 기존 클러스터 정의에 자동으로 바인딩
- Discovery Image의 ignition 구성 덮어쓰기
- iPXE 동작 제어
- Discovery Image의 커널 인수 수정
- 검색 단계에서 호스트가 신뢰할 수 있는 추가 인증서 전달
- 최신 버전의 기본 옵션이 아닌 테스트를 위해 부팅할 Red Hat CoreOS 버전을 선택합니다.
1.9.4.1. 사전 요구 사항
- 중앙 인프라 관리 서비스를 활성화해야 합니다. 자세한 내용은 중앙 인프라 관리 서비스 활성화를 참조하십시오.
1.9.4.2. 호스트 인벤토리 생성
명령줄 인터페이스를 사용하여 호스트 인벤토리(인프라 환경)를 생성하려면 다음 단계를 완료합니다.
다음 명령을 실행하여 허브 클러스터에 로그인합니다.
oc login
리소스의 네임스페이스를 생성합니다.
namespace.yaml
이라는 파일을 생성하고 다음 콘텐츠를 추가합니다.apiVersion: v1 kind: Namespace metadata: name: <your_namespace> 1
- 1
- 네임스페이스에서 동일한 이름을 사용하여 콘솔에서 인벤토리를 모니터링합니다.
다음 명령을 실행하여 YAML 콘텐츠를 적용합니다.
oc apply -f namespace.yaml
OpenShift Container Platform 풀 보안이 포함된
Secret
사용자 정의 리소스를 생성합니다.pull-secret.yaml
파일을 생성하고 다음 콘텐츠를 추가합니다.apiVersion: v1 kind: Secret type: kubernetes.io/dockerconfigjson metadata: name: pull-secret 1 namespace: <your_namespace> stringData: .dockerconfigjson: <your_pull_secret> 2
다음 명령을 실행하여 YAML 콘텐츠를 적용합니다.
oc apply -f pull-secret.yaml
인프라 환경을 생성합니다.
infra-env.yaml
파일을 생성하고 다음 콘텐츠를 추가합니다. 필요한 경우 값을 바꿉니다.apiVersion: agent-install.openshift.io/v1beta1 kind: InfraEnv metadata: name: myinfraenv namespace: <your_namespace> spec: proxy: httpProxy: <http://user:password@ipaddr:port> httpsProxy: <http://user:password@ipaddr:port> noProxy: additionalNTPSources: sshAuthorizedKey: pullSecretRef: name: <name> agentLabels: <key>: <value> nmStateConfigLabelSelector: matchLabels: <key>: <value> clusterRef: name: <cluster_name> namespace: <project_name> ignitionConfigOverride: '{"ignition": {"version": "3.1.0"}, …}' cpuArchitecture: x86_64 ipxeScriptType: DiscoveryImageAlways kernelArguments: - operation: append value: audit=0 additionalTrustBundle: <bundle> osImageVersion: <version>
InfraEnv
표에서 다음 필드 설명을 참조하십시오.
필드 | 선택 사항 또는 필수 | 설명 |
---|---|---|
| 선택 사항 |
|
| 선택 사항 |
HTTP 요청에 대한 프록시의 URL입니다. URL은 |
| 선택 사항 |
HTTP 요청에 대한 프록시의 URL입니다. URL은 |
| 선택 사항 | 프록시를 사용하지 않으려는 쉼표로 구분된 도메인 및 CIDR 목록입니다. |
| 선택 사항 | 모든 호스트에 추가할 NTP(Network Time Protocol) 소스(hostname 또는 IP) 목록입니다. DHCP와 같은 다른 옵션을 사용하여 구성된 NTP 소스에 추가됩니다. |
| 선택 사항 | 검색 단계에서 디버깅에 사용할 수 있도록 모든 호스트에 추가된 SSH 공개 키입니다. 검색 단계는 호스트가 검색 이미지를 부팅하는 단계입니다. |
| 필수 항목 | 풀 보안이 포함된 Kubernetes 시크릿의 이름입니다. |
| 선택 사항 |
|
| 선택 사항 |
호스트의 고정 IP, 브리지 및 본딩과 같은 고급 네트워크 구성을 통합합니다. 호스트 네트워크 구성은 선택한 라벨을 사용하여 하나 이상의 |
| 선택 사항 |
독립 실행형 온-프레미스 클러스터를 설명하는 기존 |
| 선택 사항 |
Red Hat CoreOS 라이브 이미지의 ignition 구성(예: 파일 추가)을 수정합니다. 필요한 경우에만 |
| 선택 사항 | 지원되는 CPU 아키텍처(x86_64, aarch64, ppc64le 또는 s390x) 중 하나를 선택합니다. 기본값은 x86_64입니다. |
| 선택 사항 |
|
| 선택 사항 |
Discovery Image가 부팅될 때 에 대한 커널 인수를 수정할 수 있습니다. |
| 선택 사항 |
PEM 인코딩 X.509 인증서 번들, 일반적으로 호스트가 다시 암호화하는 MITTM(man-in-the-middle) 프록시가 있는 네트워크에 있거나 호스트가 컨테이너 이미지 레지스트리와 같은 다른 목적으로 인증서를 신뢰해야 하는 경우 필요합니다. |
| 선택 사항 |
|
다음 명령을 실행하여 YAML 콘텐츠를 적용합니다.
oc apply -f infra-env.yaml
호스트 인벤토리가 생성되었는지 확인하려면 다음 명령을 사용하여 상태를 확인합니다.
oc describe infraenv myinfraenv -n <your_namespace>
다음 주요 속성 목록을 참조하십시오.
-
conditions
: 이미지가 생성되었는지를 나타내는 표준 Kubernetes 상태입니다. -
isoDownloadURL
: Discovery Image를 다운로드할 URL입니다. -
createdTime
: 이미지가 마지막으로 생성된 시간입니다.InfraEnv
를 수정하는 경우 새 이미지를 다운로드하기 전에 타임스탬프가 업데이트되었는지 확인합니다.
참고: InfraEnv
리소스를 수정하는 경우, createdTime
속성을 확인하여 InfraEnv
에서 새 Discovery Image를 생성했는지 확인합니다. 이미 호스트를 부팅한 경우 최신 Discovery Image를 사용하여 다시 부팅합니다.
필요한 경우 정적 네트워킹을 구성하고 인프라 환경에 호스트를 추가할 수 있습니다.
1.9.4.3. 추가 리소스
1.9.5. 인프라 환경에 대한 고급 네트워킹 구성
단일 인터페이스에서 DHCP 이외의 네트워킹이 필요한 호스트의 경우 고급 네트워킹을 구성해야 합니다. 필수 구성에는 하나 이상의 호스트에 대한 네트워킹을 설명하는 NMStateConfig
리소스의 인스턴스 생성이 포함됩니다.
각 NMStateConfig
리소스에는 InfraEnv
리소스의 nmStateConfigLabelSelector
와 일치하는 레이블이 포함되어야 합니다. nmStateConfigLabelSelector
에 대한 자세한 내용은 명령줄 인터페이스를 사용하여 호스트 인벤토리 생성 을 참조하십시오.
Discovery Image에는 참조된 모든 NMStateConfig
리소스에 정의된 네트워크 구성이 포함되어 있습니다. 부팅 후 각 호스트는 각 구성을 네트워크 인터페이스와 비교하고 적절한 구성을 적용합니다.
1.9.5.1. 사전 요구 사항
- 중앙 인프라 관리 서비스를 활성화해야 합니다. 자세한 내용은 중앙 인프라 관리 서비스 활성화를 참조하십시오.
- 호스트 인벤토리를 생성해야 합니다. 자세한 내용은 콘솔을 사용하여 호스트 인벤토리 생성 을 참조하십시오.
1.9.5.2. 명령줄 인터페이스를 사용하여 고급 네트워킹 구성
명령줄 인터페이스를 사용하여 인프라 환경에 대한 고급 네트워킹을 구성하려면 다음 단계를 완료합니다.
nmstateconfig.yaml
이라는 파일을 생성하고 다음 템플릿과 유사한 콘텐츠를 추가합니다. 필요한 경우 값을 바꿉니다.apiVersion: agent-install.openshift.io/v1beta1 kind: NMStateConfig metadata: name: mynmstateconfig namespace: <your-infraenv-namespace> labels: some-key: <some-value> spec: config: interfaces: - name: eth0 type: ethernet state: up mac-address: 02:00:00:80:12:14 ipv4: enabled: true address: - ip: 192.168.111.30 prefix-length: 24 dhcp: false - name: eth1 type: ethernet state: up mac-address: 02:00:00:80:12:15 ipv4: enabled: true address: - ip: 192.168.140.30 prefix-length: 24 dhcp: false dns-resolver: config: server: - 192.168.126.1 routes: config: - destination: 0.0.0.0/0 next-hop-address: 192.168.111.1 next-hop-interface: eth1 table-id: 254 - destination: 0.0.0.0/0 next-hop-address: 192.168.140.1 next-hop-interface: eth1 table-id: 254 interfaces: - name: "eth0" macAddress: "02:00:00:80:12:14" - name: "eth1" macAddress: "02:00:00:80:12:15"
필드 | 선택 사항 또는 필수 | 설명 |
---|---|---|
| 필수 항목 | 구성 중인 호스트 또는 호스트와 관련된 이름을 사용합니다. |
| 필수 항목 |
네임스페이스는 |
| 필수 항목 |
|
| 선택 사항 |
|
| 선택 사항 |
지정된 |
참고: 이미지 서비스는 InfraEnv
속성을 업데이트하거나 레이블 선택기와 일치하는 NMStateConfig
리소스를 변경할 때 새 이미지를 자동으로 생성합니다.
리소스를 생성한 후 InfraEnv
NMStateConfig
리소스를 추가하는 경우 InfraEnv에서 InfraEnv
에서 createdTime
속성을 확인하여 새 Discovery Image를 생성해야 합니다. 이미 호스트를 부팅한 경우 최신 Discovery Image를 사용하여 다시 부팅합니다.
다음 명령을 실행하여 YAML 콘텐츠를 적용합니다.
oc apply -f nmstateconfig.yaml
1.9.5.3. 추가 리소스
1.9.6. Discovery Image를 사용하여 호스트 인벤토리에 호스트 추가
호스트 인벤토리(인프라 환경)를 생성한 후 호스트를 검색하여 인벤토리에 추가할 수 있습니다.
인벤토리에 호스트를 추가하려면 ISO 파일을 다운로드하여 각 서버에 연결할 방법을 선택합니다. 예를 들어 가상 미디어를 사용하거나 ISO 파일을 USB 드라이브에 작성하여 ISO 파일을 다운로드할 수 있습니다.
중요: 설치가 실패하지 않도록 하려면 설치 프로세스 중에 장치에 Discovery ISO 미디어를 계속 연결하고 각 호스트를 한 번에 부팅하도록 설정합니다.
1.9.6.1. 사전 요구 사항
- 중앙 인프라 관리 서비스를 활성화해야 합니다. 자세한 내용은 중앙 인프라 관리 서비스 활성화를 참조하십시오.
- 호스트 인벤토리를 생성해야 합니다. 자세한 내용은 콘솔을 사용하여 호스트 인벤토리 생성 을 참조하십시오.
1.9.6.2. 콘솔을 사용하여 호스트 추가
다음 단계를 완료하여 ISO 파일을 다운로드합니다.
- 콘솔에서 Infrastructure > Host inventory 를 선택합니다.
- 목록에서 인프라 환경을 선택합니다.
호스트 추가를 클릭하고 Discovery ISO 사용을 선택합니다.
이제 ISO 파일을 다운로드할 URL이 표시됩니다. 부팅된 호스트가 호스트 인벤토리 테이블에 나타납니다. 호스트가 표시되는 데 몇 분이 걸릴 수 있습니다.
참고: 기본적으로 제공되는 ISO는 최소 ISO입니다. 최소 ISO에는 루트 파일 시스템인
RootFS
가 포함되어 있지 않습니다.RootFS
는 나중에 다운로드됩니다. 전체 ISO를 표시하려면 URL의최소.iso
를full.iso
로 바꿉니다.- 사용할 수 있도록 각 호스트를 승인합니다. 작업을 클릭하고 승인을 선택하여 인벤토리 테이블에서 호스트를 선택할 수 있습니다.
1.9.6.3. 명령줄 인터페이스를 사용하여 호스트 추가
isoDownloadURL
속성에서 ISO 파일을 다운로드할 URL은 InfraEnv
리소스의 상태에 있습니다. InfraEnv
리소스에 대한 자세한 내용은 명령줄 인터페이스를 사용하여 호스트 인벤토리 생성 을 참조하십시오.
부팅된 각 호스트는 동일한 네임스페이스에 에이전트
리소스를 생성합니다.
다음 명령을 실행하여
InfraEnv
사용자 정의 리소스에서 다운로드 URL을 확인합니다.oc get infraenv -n <infra env namespace> <infra env name> -o jsonpath='{.status.isoDownloadURL}'
다음 출력을 참조하십시오.
https://assisted-image-service-assisted-installer.apps.example-acm-hub.com/byapikey/eyJhbGciOiJFUzI1NiIsInC93XVCJ9.eyJpbmZyYV9lbnZfaWQcTA0Y38sWVjYi02MTA0LTQ4NDMtODasdkOGIxYTZkZGM5ZTUifQ.3ydTpHaXJmTasd7uDp2NvGUFRKin3Z9Qct3lvDky1N-5zj3KsRePhAM48aUccBqmucGt3g/4.16/x86_64/minimal.iso
참고: 기본적으로 제공되는 ISO는 최소 ISO입니다. 최소 ISO에는 루트 파일 시스템인
RootFS
가 포함되어 있지 않습니다.RootFS
는 나중에 다운로드됩니다. 전체 ISO를 표시하려면 URL의최소.iso
를full.iso
로 바꿉니다.URL을 사용하여 ISO 파일을 다운로드하고 ISO 파일로 호스트를 부팅합니다.
다음으로 각 호스트를 승인해야 합니다. 다음 절차를 참조하십시오.
다음 명령을 실행하여 모든
에이전트
를 나열합니다.oc get agent -n <infra env namespace>
다음 출력과 유사한 출력이 표시됩니다.
NAME CLUSTER APPROVED ROLE STAGE 24a92a6f-ea35-4d6f-9579-8f04c0d3591e false auto-assign
목록에서 모든
에이전트
를 승인하고잘못된 승인 상태로
승인합니다. 다음 명령을 실행합니다.oc patch agent -n <infra env namespace> <agent name> -p '{"spec":{"approved":true}}' --type merge
다음 명령을 실행하여 승인 상태를 확인합니다.
oc get agent -n <infra env namespace>
true
값을 사용하여 다음 출력과 유사한 출력이 표시됩니다.NAME CLUSTER APPROVED ROLE STAGE 173e3a84-88e2-4fe1-967f-1a9242503bec true auto-assign
1.9.6.4. 추가 리소스
1.9.7. 호스트 인벤토리에 베어 메탈 호스트 자동 추가
호스트 인벤토리(인프라 환경)를 생성한 후 호스트를 검색하여 인벤토리에 추가할 수 있습니다. 베어 메탈 Operator가 각 베어 메탈 호스트의 BMC(Baseboard Management Controller)와 각 호스트에 대해 BareMetalHost
리소스 및 관련 BMC 시크릿을 생성하여 인프라 환경의 검색 이미지 부팅을 자동화할 수 있습니다. 자동화는 인프라 환경을 참조하는 BareMetalHost
의 레이블로 설정됩니다.
자동화는 다음 작업을 수행합니다.
- 인프라 환경에서 표시하는 Discovery Image를 사용하여 각 베어 메탈 호스트 부팅
- 인프라 환경 또는 관련 네트워크 구성이 업데이트되는 경우 각 호스트를 최신 검색 이미지로 재부팅
-
검색 시 각
에이전트
리소스를 해당BareMetalHost
리소스와 연결합니다. -
호스트 이름, 역할 및 설치 디스크와 같은
BareMetalHost
의 정보를 기반으로에이전트
리소스 속성 업데이트 -
클러스터 노드로 사용할
에이전트
승인
1.9.7.1. 사전 요구 사항
- 중앙 인프라 관리 서비스를 활성화해야 합니다. 자세한 내용은 중앙 인프라 관리 서비스 활성화를 참조하십시오.
- 호스트 인벤토리를 생성해야 합니다. 자세한 내용은 콘솔을 사용하여 호스트 인벤토리 생성 을 참조하십시오.
1.9.7.2. 콘솔을 사용하여 베어 메탈 호스트 추가
콘솔을 사용하여 호스트 인벤토리에 베어 메탈 호스트를 자동으로 추가하려면 다음 단계를 완료합니다.
- 콘솔에서 Infrastructure > Host inventory 를 선택합니다.
- 목록에서 인프라 환경을 선택합니다.
- 호스트 추가를 클릭하고 BMC 양식으로 를 선택합니다.
- 필요한 정보를 추가하고 생성 을 클릭합니다.
1.9.7.3. 명령줄 인터페이스를 사용하여 베어 메탈 호스트 추가
명령줄 인터페이스를 사용하여 호스트 인벤토리에 베어 메탈 호스트를 자동으로 추가하려면 다음 단계를 완료합니다.
다음 YAML 콘텐츠를 적용하고 필요한 경우 값을 교체하여 BMC 시크릿을 생성합니다.
apiVersion: v1 kind: Secret metadata: name: <bmc-secret-name> namespace: <your_infraenv_namespace> 1 type: Opaque data: username: <username> password: <password>
- 1
- 네임스페이스는
InfraEnv
의 네임스페이스와 동일해야 합니다.
다음 YAML 콘텐츠를 적용하고 필요한 경우 값을 교체하여 베어 메탈 호스트를 생성합니다.
apiVersion: metal3.io/v1alpha1 kind: BareMetalHost metadata: name: <bmh-name> namespace: <your_infraenv_namespace> 1 annotations: inspect.metal3.io: disabled labels: infraenvs.agent-install.openshift.io: <your-infraenv> 2 spec: online: true automatedCleaningMode: disabled 3 bootMACAddress: <your-mac-address> 4 bmc: address: <machine-address> 5 credentialsName: <bmc-secret-name> 6 rootDeviceHints: deviceName: /dev/sda 7
- 1
- 네임스페이스는
InfraEnv
의 네임스페이스와 동일해야 합니다. - 2
- 이름은
InfrEnv
의 이름과 일치해야 하며 동일한 네임스페이스에 있어야 합니다. - 3
- 값을 설정하지 않으면
메타데이터
값이 자동으로 사용됩니다. - 4
- MAC 주소가 호스트의 상호 작용 중 하나의 MAC 주소와 일치하는지 확인합니다.
- 5
- BMC 주소를 사용합니다. 자세한 내용은 대역 외 관리 IP 주소에 대한 포트 액세스를 참조하십시오.
- 6
credentialsName
값이 생성한 BMC 시크릿의 이름과 일치하는지 확인합니다.- 7
- 선택 사항: 설치 디스크를 선택합니다. 사용 가능한 루트 장치 팁은 BareMetalHost 사양 을 참조하십시오. 호스트를 검색 이미지로 부팅하고 해당
에이전트
리소스가 생성되면 이 팁에 따라 설치 디스크가 설정됩니다.
호스트를 켜면 이미지가 다운로드되기 시작합니다. 이 작업은 몇 분 정도 걸릴 수 있습니다. 호스트가 검색되면 에이전트
사용자 지정 리소스가 자동으로 생성됩니다.
1.9.7.4. 명령줄 인터페이스를 사용하여 관리형 클러스터 노드 제거
관리형 클러스터에서 관리형 클러스터 노드를 제거하려면 지원되는 OpenShift Container Platform 버전에서 실행 중인 허브 클러스터가 필요합니다. 노드를 부팅하는 데 필요한 정적 네트워킹 구성을 사용할 수 있어야 합니다. 에이전트 및 베어 메탈 호스트를 삭제할 때 NMStateConfig
리소스를 삭제하지 마십시오.
1.9.7.4.1. 베어 메탈 호스트를 사용하여 관리형 클러스터 노드 제거
허브 클러스터에 베어 메탈 호스트가 있고 관리 클러스터에서 관리 클러스터 노드를 제거하려면 다음 단계를 완료합니다.
삭제하려는 노드의
BareMetalHost
리소스에 다음 주석을 추가합니다.bmac.agent-install.openshift.io/remove-agent-and-node-on-delete: true
다음 명령을 실행하여
BareMetalHost
리소스를 삭제합니다. <bmh-name&
gt;을BareMetalHost
의 이름으로 바꿉니다.oc delete bmh <bmh-name>
1.9.7.4.2. 베어 메탈 호스트 없이 관리형 클러스터 노드 제거
hub 클러스터에 베어 메탈 호스트가 없고 관리 클러스터에서 관리 클러스터 노드를 제거하려면 OpenShift Container Platform 설명서의 노드 삭제 지침을 따르십시오.
1.9.7.5. 추가 리소스
- 제로 터치 프로비저닝에 대한 자세한 내용은 OpenShift Container Platform 설명서 의 네트워크 맨 위에 있는 클러스터를 참조하십시오.
- 베어 메탈 호스트 사용에 필요한 포트에 대한 자세한 내용은 OpenShift Container Platform 설명서 의 대역 외 관리 IP 주소에 대한 포트 액세스를 참조하십시오.
- 루트 장치 팁에 대한 자세한 내용은 OpenShift Container Platform 설명서의 베어 메탈 구성 을 참조하십시오.
- 이미지 풀 시크릿 사용
- 온-프레미스 환경에 대한 인증 정보 생성
- 컴퓨팅 머신 스케일링에 대한 자세한 내용은 OpenShift Container Platform 설명서에서 컴퓨팅 머신 세트 수동 스케일링을 참조하십시오.
1.9.8. 호스트 인벤토리 관리
콘솔을 사용하거나 명령줄 인터페이스를 사용하여 호스트 인벤토리를 관리하고 기존 호스트를 편집하고 Agent
리소스를 편집할 수 있습니다.
1.9.8.1. 콘솔을 사용하여 호스트 인벤토리 관리
Discovery ISO로 성공적으로 부팅한 각 호스트는 호스트 인벤토리에 행으로 표시됩니다. 콘솔을 사용하여 호스트를 편집하고 관리할 수 있습니다. 호스트를 수동으로 부팅하고 베어 메탈 Operator 자동화를 사용하지 않는 경우 콘솔에서 호스트를 승인해야 사용할 수 있습니다. OpenShift 노드로 설치할 준비가 된 호스트의 상태는 Available
입니다.
1.9.8.2. 명령줄 인터페이스를 사용하여 호스트 인벤토리 관리
에이전트 리소스는
각 호스트를 나타냅니다. 에이전트
리소스에서 다음 속성을 설정할 수 있습니다.
clusterDeploymentName
이 속성을 클러스터에 노드로 설치하려는 경우 사용할
ClusterDeployment
의 네임스페이스 및 이름으로 설정합니다.선택 사항:
role
클러스터에서 호스트의 역할을 설정합니다. 가능한 값은
master
,worker
,auto-assign
입니다. 기본값은auto-assign
입니다.hostname
호스트의 호스트 이름을 설정합니다. 호스트에 유효한 호스트 이름이 자동으로 할당되는 경우(예: DHCP 사용) 선택 사항입니다.
승인됨
호스트를 OpenShift 노드로 설치할 수 있는지 여부를 나타냅니다. 이 속성은 기본값이
False
인 부울입니다. 호스트를 수동으로 부팅하고 베어 메탈 Operator 자동화를 사용하지 않는 경우 호스트를 설치하기 전에 이 속성을True
로 설정해야 합니다.installation_disk_id
선택한 설치 디스크의 ID가 호스트의 인벤토리에 표시됩니다.
installerArgs
호스트의 coreos-installer 인수에 대한 덮어쓰기가 포함된 JSON 형식의 문자열입니다. 이 속성을 사용하여 커널 인수를 수정할 수 있습니다. 다음 예제 구문을 참조하십시오.
["--append-karg", "ip=192.0.2.2::192.0.2.254:255.255.255.0:core0.example.com:enp1s0:none", "--save-partindex", "4"]
ignitionConfigOverrides
호스트의 ignition 구성에 대한 덮어쓰기가 포함된 JSON 형식의 문자열입니다. 이 속성을 사용하여 ignition을 사용하여 호스트에 파일을 추가할 수 있습니다. 다음 예제 구문을 참조하십시오.
{"ignition": "version": "3.1.0"}, "storage": {"files": [{"path": "/tmp/example", "contents": {"source": "data:text/plain;base64,aGVscGltdHJhcHBlZGluYXN3YWdnZXJzcGVj"}}]}}
nodeLabels
호스트를 설치한 후 노드에 적용되는 라벨 목록입니다.
에이전트
리소스의 상태에
는 다음과 같은 속성이 있습니다.
role
클러스터에서 호스트의 역할을 설정합니다. 이전에
Agent
리소스에서역할을
설정하면 값이상태에
표시됩니다.인벤토리
호스트에서 실행 중인 에이전트가 검색하는 호스트 속성을 포함합니다.
진행 상황
호스트 설치 진행 중입니다.
ntpSources
호스트의 구성된 NTP(Network Time Protocol) 소스입니다.
conditions
True
또는False
값과 함께 다음 표준 Kubernetes 조건을 포함합니다.-
SpecSynced: 지정된 모든 속성이 성공적으로 적용되면
True
입니다.false
오류가 발생하면 false입니다. -
connected: 설치 서비스에 대한 에이전트 연결이 중단되지 않으면
True
입니다. 에이전트가 잠시 후에 설치 서비스에 도달하지 않은 경우false
입니다. -
RequirementsMet: 호스트가 설치를 시작할 준비가 되면
True
입니다. -
validated: 모든 호스트 검증이 통과하면
True
입니다. -
installed: 호스트가 OpenShift 노드로 설치된 경우
True
입니다. -
Bound: 호스트가 클러스터에 바인딩된 경우
True
입니다. -
cleanup:
Agent
resouce를 삭제하라는 요청이 실패하면False
입니다.
-
SpecSynced: 지정된 모든 속성이 성공적으로 적용되면
debugInfo
설치 로그 및 이벤트를 다운로드하기 위한 URL이 포함되어 있습니다.
validationsInfo
설치에 성공했는지 확인하기 위해 호스트가 검색된 후 에이전트가 실행되는 검증에 대한 정보가 포함되어 있습니다. 값이
False
인 경우 문제를 해결합니다.installation_disk_id
선택한 설치 디스크의 ID가 호스트의 인벤토리에 표시됩니다.