호스팅된 컨트롤 플레인
OpenShift Container Platform에서 호스팅된 컨트롤 플레인 사용
초록
1장. 호스팅된 컨트롤 플레인 릴리스 노트 링크 복사링크가 클립보드에 복사되었습니다!
릴리스 노트에는 사용되지 않는 새로운 기능, 변경 사항 및 알려진 문제에 대한 정보가 포함되어 있습니다.
1.1. OpenShift Container Platform 4.20의 호스팅된 컨트롤 플레인 릴리스 노트 링크 복사링크가 클립보드에 복사되었습니다!
이번 릴리스에서는 OpenShift Container Platform 4.20의 호스팅된 컨트롤 플레인을 사용할 수 있습니다. OpenShift Container Platform 4.20의 호스팅된 컨트롤 플레인은 Kubernetes Operator 버전 2.10에 대한 다중 클러스터 엔진을 지원합니다.
1.1.1. 새로운 기능 및 개선 사항 링크 복사링크가 클립보드에 복사되었습니다!
1.1.1.1. 호스트 클러스터에서 워크로드 확장 링크 복사링크가 클립보드에 복사되었습니다!
이제 호스팅된 클러스터의 워크로드를 축소하지 않고 scale UpOnly 동작을 사용하여 워크로드를 확장할 수 있습니다. 자세한 내용은 호스팅 클러스터의 워크로드 확장을 참조하십시오.
1.1.1.2. 호스트 클러스터에서 워크로드 확장 및 축소 링크 복사링크가 클립보드에 복사되었습니다!
이제 호스팅된 클러스터에서 scale UpAndScaleDown 동작을 사용하여 워크로드를 확장하고 축소할 수 있습니다. 자세한 내용은 호스트 클러스터의 워크로드 확장 및 축소를 참조하십시오.
1.1.1.3. 호스트 클러스터에서 무시된 라벨의 균형 조정 링크 복사링크가 클립보드에 복사되었습니다!
노드 풀을 확장한 후 balancingIgnoredLabels 를 설정하여 노드 풀에 머신을 균등하게 배포할 수 있습니다. 자세한 내용은 호스트 클러스터에서 분산을 무시한 라벨을 참조하십시오.
1.1.1.4. 호스트 클러스터에서 우선순위 확장기 설정 링크 복사링크가 클립보드에 복사되었습니다!
이제 호스트 클러스터에서 우선 순위 확장기를 구성하여 우선 순위가 낮은 머신보다 우선 순위가 높은 머신을 생성할 수 있습니다. 자세한 내용은 호스팅 클러스터에서 우선순위 확장기 설정을 참조하십시오.
1.1.1.5. 연결이 끊긴 환경에서 IBM Z의 호스팅된 컨트롤 플레인은 일반적으로 사용 가능 링크 복사링크가 클립보드에 복사되었습니다!
이 릴리스에서 연결이 끊긴 환경에서 IBM Z의 호스팅 컨트롤 플레인은 일반 Availablilty 기능입니다. 자세한 내용은 연결이 끊긴 환경에서 IBM Z에 호스팅된 컨트롤 플레인 배포를 참조하십시오.
1.1.2. 버그 수정 링크 복사링크가 클립보드에 복사되었습니다!
-
이번 업데이트 이전에는
hc.spec.configuration.apiServer.servingCerts.namedCertificates의 사용자 정의 인증서에 대한 SAN 검증에서*.example.com과 같은 와일드카드 DNS 패턴을 올바르게 처리하지 못했습니다. 결과적으로 사용자 정의 인증서의 와일드카드 DNS 패턴은 탐지되지 않고 내부 Kubernetes API 서버 인증서 SAN과 충돌하여 인증서 검증 실패 및 잠재적인 배포 문제가 발생할 수 있었습니다. 이 릴리스에서는 RFC 호환 와일드카드 지원을 포함하도록 향상된 DNS SAN 충돌 감지 기능을 제공하여*.example.com일치하는 와일드카드 패턴을 올바르게 처리하는 양방향 충돌 검증을 구현합니다.결과적으로 와일드카드 DNS 패턴이 올바르게 검증되어 인증서 충돌을 방지하고 와일드카드 인증서 지원을 통해 더 안정적인 호스트 클러스터 배포를 보장합니다. (OCPBUGS-60381) -
이번 업데이트 이전에는 Azure 클라우드 공급자가 Azure 로드 밸런서에 대해 기본 ping 대상인
HTTP:10256/healthz를 설정하지 않았습니다. 대신 Azure에서 실행된LoadBalancer유형의 서비스에는TCP:30810의 ping 대상이 있었습니다. 그 결과 클러스터 전체 서비스에 대한 상태 프로브가 작동하지 않았으며 업그레이드 중에 다운타임이 발생했습니다. 이번 릴리스에서는 클라우드 구성의ClusterServiceLoadBalancerHealthProbeMode속성이shared로 설정됩니다. 결과적으로 Azure의 로드 밸런서에는 노드에서 실행되는kube-proxy상태 끝점을 가리키는HTTP:10256/healthz올바른 상태 점검 대상인 HTTP:10256/healthz가 있습니다. (OCPBUGS-58031) -
이번 업데이트 이전에는
HostedCluster리소스에서additionalTrustBundle매개변수를 제거한 후 HyperShift Operator에서user-ca-bundle구성 맵을 지우지 못했습니다. 그 결과user-ca-bundle구성 맵이 업데이트되지 않아 Ignition 페이로드를 생성하지 못했습니다. 이번 릴리스에서는 HyperShift Operator가HostedCluster리소스에서 제거될 때 컨트롤 플레인 네임스페이스에서user-ca-bundle구성 맵을 적극적으로 제거합니다. 결과적으로user-ca-bundle구성 맵이 올바르게 지워 ignition 페이로드 생성이 활성화됩니다. (OCPBUGS-57336) -
이번 업데이트 이전에는 Kubernetes API 서버 서비스 게시 전략이
PublicAndPrivate엔드포인트 액세스를 통해LoadBalancer인 경우 외부 DNS Operator가 DNS 레코드를 등록하지 않은 경우에도 프라이빗 라우터에서 OAuth 경로를 허용한 경우 AWS에서 호스팅 클러스터를 생성하려고 했습니다. 그 결과 개인 라우터에서 경로 URL을 올바르게 확인하지 못했으며 OAuth 서버에 액세스할 수 없었습니다. Console Cluster Operator도 시작되지 않았으며 호스트 클러스터 설치에 실패했습니다. 이번 릴리스에서는 개인 라우터가 외부 DNS가 정의된 경우에만 OAuth 경로를 허용합니다. 그렇지 않으면 라우터가 관리 클러스터의 경로를 허용합니다. 결과적으로 OAuth 경로에 액세스하고 Console Cluster Operator가 올바르게 시작되고 호스팅 클러스터 설치에 성공합니다. (OCPBUGS-56914) -
이번 릴리스 이전에는 관리 OpenShift 클러스터의 IDMS 또는 ICSP에서 registry.redhat.io 또는 registry.redhat.io/redhat을 가리키는 소스를 정의하고 미러 레지스트리에 필요한 OLM 카탈로그 이미지가 포함되지 않은 경우, 무단 이미지 가져오기로 인해
HostedCluster리소스에 대한 프로비저닝이 중단되었습니다. 그 결과HostedCluster리소스가 배포되지 않았으며 미러링된 레지스트리에서 필수 카탈로그 이미지를 가져올 수 없는 차단된 상태로 남아 있었습니다. 이번 릴리스에서는 권한 부여 오류로 인해 필요한 이미지를 가져올 수 없는 경우 이제 프로비저닝이 명시적으로 실패합니다. OLM CatalogSource 이미지 확인을 위해 레지스트리 재정의 논리가 레지스트리의 루트(예: registry.redhat.io)의 일치를 허용하도록 개선되었습니다. 레지스트리 덮어쓰기에서 작동 중인 이미지를 생성하지 않는 경우 원래ImageReference를 사용하기 위한 대체 메커니즘도 도입되었습니다. 결과적으로 적절한 경우 시스템이 원래 소스에서 올바르게 가져오기 때문에 미러 레지스트리에 필요한 OLM 카탈로그 이미지가 없는 경우에도HostedCluster리소스를 성공적으로 배포할 수 있습니다. (OCPBUGS-56492) -
이번 업데이트 이전에는 AWS 클라우드 공급자가 AWS 로드 밸런서에 대해 기본 ping 대상인
HTTP:10256/healthz를 설정하지 않았습니다. AWS에서 실행되는LoadBalancer유형의 서비스의 경우 AWS에서 생성된 로드 밸런서 오브젝트에는TCP:32518의 ping 대상이 있습니다. 그 결과 클러스터 전체 서비스에 대한 상태 프로브가 작동하지 않았으며 업그레이드하는 동안 해당 서비스가 중단되었습니다. 이번 릴리스에서는 클라우드 구성의ClusterServiceLoadBalancerHealthProbeMode속성이Shared로 설정됩니다. 이 클라우드 구성은 AWS 클라우드 공급자에게 전달됩니다. 결과적으로 AWS의 로드 밸런서에는 노드에서 실행 중인kube-proxy상태 끝점을 가리키는 올바른 상태 점검 ping 대상인HTTP:10256/healthz가 있습니다. (OCPBUGS-56011) -
이번 업데이트 이전에는
--disable-cluster-capabilities옵션을 사용하여 이미지 레지스트리 기능을 비활성화하면 호스팅된 컨트롤 플레인에서 이미지 레지스트리에 대한 관리 ID를 구성해야 합니다. 이번 릴리스에서는 이미지 레지스트리가 비활성화되면 이미지 레지스트리 관리 ID 구성이 선택 사항입니다. (OCPBUGS-55892) -
이번 업데이트 이전에는 관리 클러스터의
ImageDigestMirrorSet(IDMS) 및ImageContentSourcePolicy(ICSP) 리소스가 이미지 교체를 위해 루트 레지스트리 이름만 미러 또는 소스로 지정할 수 있다는 점을 고려하지 않고 처리되었습니다. 그 결과 루트 레지스트리 이름만 사용한 IDMS 및 ICSP 항목이 예상대로 작동하지 않았습니다. 이번 릴리스에서는 미러 교체 논리에서 루트 레지스트리 이름만 제공되는 경우를 올바르게 처리합니다. 결과적으로 문제가 더 이상 발생하지 않으며 루트 레지스트리 미러 교체가 지원됩니다. (OCPBUGS-54483) -
이번 업데이트 이전에는 호스팅된 컨트롤 플레인이
HostedCluster리소스에 레지스트리 메타데이터 및 릴리스 이미지 공급자 캐시를 올바르게 유지하지 않았습니다. 그 결과HostedCluster컨트롤러 조정에서 릴리스 및 이미지 메타데이터의 캐시가 재설정되었습니다. 이번 릴리스에서는HostedCluster리소스에서 캐시 손실을 수정하는 데 사용하는 일반적인 레지스트리 공급자가 도입되었습니다. 이렇게 하면 이미지 풀 및 네트워크 트래픽 수가 줄어들어 전체 성능이 향상됩니다. (OCPBUGS-53259) -
이번 업데이트 이전에는 클라이언트 시크릿을 지정하지 않은 OIDC 클라이언트를 사용하여
HostedCluster리소스에 대해 OIDC 공급자를 구성하면 시스템에서 기본 시크릿 이름을 자동으로 생성합니다. 결과적으로 보안을 사용하지 않는 OIDC 공용 클라이언트를 구성할 수 없었습니다. 이 릴리스에서는 이 문제가 해결되었습니다. 클라이언트 시크릿을 제공하지 않으면 기본 시크릿 이름이 생성되지 않으므로 공용 클라이언트에 대한 적절한 지원이 활성화됩니다. (OCPBUGS-58149) - 이번 업데이트 이전에는 여러 미러 이미지로 인해 이미지 조회 실패로 인해 호스팅된 컨트롤 플레인 페이로드 오류가 발생했습니다. 이로 인해 사용자가 호스팅된 클러스터를 생성할 수 없었습니다. 이번 릴리스에서는 호스트된 컨트롤 플레인 페이로드에서 여러 미러를 지원하므로 기본 미러를 사용할 수 없는 경우 오류가 발생하지 않습니다. 결과적으로 사용자는 호스팅된 클러스터를 생성할 수 있습니다. (OCPBUGS-54720)
이번 업데이트 이전에는 호스팅 클러스터가 시간이 지남에 따라 여러 버전으로 업그레이드되면
HostedCluster리소스의 버전 기록이 10개의 항목을 초과하는 경우가 있었습니다. 그러나 API에는 버전 기록 필드에 대해 최대 10개의 항목의 엄격한 검증 제한이 있었습니다. 결과적으로 버전 기록이 10개의 항목을 초과하면 사용자가HostedCluster리소스를 편집하거나 업데이트할 수 없었습니다. 주석 추가(예: 클러스터 크기 덮어쓰기의 경우) 또는 요청 제공 노드 크기 조정과 같은 유지 관리 작업을 수행하는 작업은 "status.version.history: Too many: 11: must have at most 10 items"로 검증 오류로 실패했습니다. 이 오류로 인해 ROSA SREs가 고객 API 액세스에 영향을 미칠 수 있는 중요한 유지 관리 작업을 수행하지 못했습니다.이번 릴리스에서는
HostedClusterAPI의 버전 기록 필드에서 최대 항목 검증 제약 조건이 제거되어 검증 오류를 트리거하지 않고 기록이 10개 항목 이상으로 증가할 수 있습니다. 결과적으로 이제 버전 기록에 있는 항목 수와 관계없이HostedCluster리소스를 편집하고 업데이트할 수 있으므로 관리자가 여러 버전 업그레이드가 발생한 클러스터에서 필요한 유지 관리 작업을 수행할 수 있습니다. (OCPBUGS-58200)이번 업데이트 이전에는 CLI 리팩토링에 따라
MarkPersistentFlagRequired함수가 올바르게 작동을 중지했습니다. 클러스터 생성에 중요한--name및--pull-secret플래그는 필수로 표시되지만 검증은 적용되지 않았습니다. 결과적으로 사용자는 필요한--name또는--pull-secret플래그를 제공하지 않고hypershift create cluster명령을 실행할 수 있었으며 CLI에서 이러한 필수 플래그가 누락되었다고 즉시 경고하지 않았습니다. 이로 인해 배포가 잘못 구성되고 나중에 오류 메시지가 혼동될 수 있었습니다.이번 릴리스에서는
RawCreateOptions.Validate()함수에 명시적으로 검증하여--name및--pull-secret플래그가 있는지 확인하여 플래그 중 하나가 누락되었을 때 명확한 오류 메시지를 반환합니다. 또한 올바른 검증을 보장하기 위해 기본 "example" 값이 name 필드에서 제거됩니다. 결과적으로 사용자가 필수--name또는--pull-secret플래그 없이 클러스터를 생성하려고 하면 이제 필요한 플래그가 누락되었음을 나타내는 즉각적이고 명확한 오류 메시지가 표시됩니다(예: "Error: --name is required" 또는 "Error: --pull-secret is required"), 이로 인해 잘못 구성된 배포를 방지하고 사용자 환경을 개선할 수 있습니다. (OCPBUGS-37323)이번 업데이트 이전에는
GetSupportedOCPVersions()함수의 변수 섀도우 버그로 인해supportedVersions변수가:=대신=을 사용하여 잘못 할당되어 의도한 외부 범위 변수를 업데이트하지 않고 즉시 삭제되었던 로컬 변수를 생성했습니다. 결과적으로 사용자가 HyperShift Operator를 사용하여hypershift version명령을 실행할 때 CLI는 서버 버전에 <unknown>을 표시하거나 "nil pointer dereference" 오류와 함께 패닉을 표시하여 사용자가 배포된 HyperShift Operator 버전을 확인하지 못하도록 합니다.이번 릴리스에서는
GetSupportedOCPVersions()함수의supportedVersions :=에서supportedVersions =로 변수 할당을 수정하여 구성 맵을 외부 범위 변수에 적절하게 할당하여 지원되는 버전 데이터가 올바르게 입력되도록 합니다. 결과적으로 HyperShift Operator가 배포되고 실행 중인 Operator버전을 확인할 수 있도록 hypershift버전 명령에서 서버 버전(예: 서버 버전: f001510b35842df352d1ab55d961be3fdc2dae32")이 올바르게 표시됩니다. (OCPBUGS-57316)- 이번 업데이트 이전에는 HyperShift Operator가 모든 경우에 Kubernetes API Server SAN(주체 대체 이름)을 검증했습니다. 결과적으로 사용자는 PKI(공개 키 인프라) 조정 중에 잘못된 API 서버 SAN이 발생하는 경우가 있었습니다. 이번 릴리스에서는 PKI 조정이 비활성화되지 않은 경우에만 Kubernetes API 서버 SAN의 유효성을 검사합니다. (OCPBUGS-56457)
이번 업데이트 이전에는 공유 수신 컨트롤러에서
HostedCluster.Spec.KubeAPIServerDNSName필드를 처리하지 않았으므로 사용자 정의 kube-apiserver DNS 이름이 라우터 구성에 추가되지 않았습니다. 그 결과 사용자 정의 DNS 이름(HostedCluster.Spec.KubeAPIServerDNSName을 통해)을 사용하는 호스팅된 컨트롤 플레인에서 kube-apiserver로 향하는 트래픽이 올바르게 라우팅되지 않아KubeAPIExternalName기능이 공유 수신을 사용하는 플랫폼에서 작동하지 않습니다.이번 릴리스에서는 공유 수신 컨트롤러에
HostedCluster.Spec.KubeAPIServerDNSName에 대한 처리가 추가되었습니다. 호스트 클러스터가 사용자 지정 kube-apiserver DNS 이름을 지정하면 컨트롤러가 이제 트래픽을 kube-apiserver 서비스로 보내는 경로를 자동으로 생성합니다. 결과적으로 사용자 정의 kube-apiserver DNS 이름으로 향하는 트래픽이 공유 수신 컨트롤러에서 올바르게 라우팅되므로KubeAPIExternalName기능이 공유 수신을 사용하는 플랫폼에서 작동할 수 있습니다. (OCPBUGS-57790)
1.1.3. 확인된 문제 링크 복사링크가 클립보드에 복사되었습니다!
-
주석 및
ManagedCluster리소스 이름이 일치하지 않으면 Kubernetes Operator 콘솔의 다중 클러스터 엔진에 클러스터가Pending 가져오기로 표시됩니다. 다중 클러스터 엔진 Operator는 클러스터를 사용할 수 없습니다. 주석이 없고ManagedCluster이름이HostedCluster리소스의Infra-ID값과 일치하지 않는 경우에도 동일한 문제가 발생합니다. - Kubernetes Operator 콘솔에 다중 클러스터 엔진을 사용하여 기존 호스트 클러스터에 새 노드 풀을 추가하면 동일한 OpenShift Container Platform 버전이 옵션 목록에 두 번 이상 표시될 수 있습니다. 원하는 버전의 목록에서 인스턴스를 선택할 수 있습니다.
노드 풀이 작업자가 0개로 축소되면 콘솔의 호스트 목록에는 노드가
준비됨 상태로 계속 표시됩니다. 다음 두 가지 방법으로 노드 수를 확인할 수 있습니다.- 콘솔에서 노드 풀로 이동하여 0개의 노드가 있는지 확인합니다.
명령줄 인터페이스에서 다음 명령을 실행합니다.
다음 명령을 실행하여 0개의 노드가 노드 풀에 있는지 확인합니다.
oc get nodepool -A
$ oc get nodepool -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 0 노드가 클러스터에 있는지 확인합니다.
oc get nodes --kubeconfig
$ oc get nodes --kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 0 에이전트가 클러스터에 바인딩된 것으로 보고되었는지 확인합니다.
oc get agents -A
$ oc get agents -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
듀얼 스택 네트워크를 사용하는 환경에서 호스팅 클러스터를 생성할 때
ContainerCreating상태에서 Pod가 중단될 수 있습니다. 이 문제는openshift-service-ca-operator리소스에서 DNS 확인에 필요한metrics-tls시크릿을 생성할 수 없기 때문에 발생합니다. 결과적으로 Pod는 Kubernetes API 서버를 확인할 수 없습니다. 이 문제를 해결하려면 듀얼 스택 네트워크의 DNS 서버 설정을 구성합니다. 관리 클러스터와 동일한 네임스페이스에 호스팅 클러스터를 생성한 경우 관리형 호스팅 클러스터를 분리하면 호스팅 클러스터를 포함하여 관리 클러스터 네임스페이스의 모든 항목이 삭제됩니다. 다음 상황에서는 관리 클러스터와 동일한 네임스페이스에 호스팅 클러스터를 생성할 수 있습니다.
- 기본 호스팅 클러스터 네임스페이스를 사용하여 Kubernetes Operator 콘솔용 다중 클러스터 엔진을 통해 에이전트 플랫폼에 호스팅된 클러스터를 생성하셨습니다.
- 호스팅된 클러스터 네임스페이스를 호스팅된 클러스터 이름과 동일하게 지정하여 명령줄 인터페이스 또는 API를 통해 호스팅된 클러스터를 생성하셨습니다.
-
콘솔 또는 API를 사용하여 호스트 클러스터의
spec.services.servicePublishingStrategy.nodePort.address필드에 IPv6 주소를 지정하면 8 hextets가 있는 전체 IPv6 주소가 필요합니다. 예를 들어2620:52:0:1306::30을 지정하는 대신2620:52:0:1306:0:0:0:30을 지정해야 합니다.
1.1.4. 일반 가용성 및 기술 프리뷰 기능 링크 복사링크가 클립보드에 복사되었습니다!
이 릴리스의 일부 기능은 현재 기술 프리뷰 단계에 있습니다. 이러한 실험적 기능은 프로덕션용이 아닙니다. 이러한 기능에 대한 지원 범위에 대한 자세한 내용은 Red Hat 고객 포털에서 기술 프리뷰 기능 지원 범위를 참조하십시오.
IBM Power 및 IBM Z의 경우 다음과 같은 예외가 적용됩니다.
- 버전 4.20 이상의 경우 64비트 x86 아키텍처 또는 s390x 아키텍처를 기반으로 하는 머신 유형 및 IBM Power 또는 IBM Z에서 노드 풀을 실행해야 합니다.
- 버전 4.19 이하의 경우 64비트 x86 아키텍처를 기반으로 하는 머신 유형 및 IBM Power 또는 IBM Z의 노드 풀에서 컨트롤 플레인을 실행해야 합니다.
| 기능 | 4.18 | 4.19 | 4.20 |
|---|---|---|---|
| 베어 메탈이 아닌 에이전트 시스템을 사용하는 OpenShift Container Platform용 호스팅 컨트롤 플레인 | 기술 프리뷰 | 기술 프리뷰 | 기술 프리뷰 |
| RHOSP의 OpenShift Container Platform용 호스팅 컨트롤 플레인 | 개발자 프리뷰 | 기술 프리뷰 | 기술 프리뷰 |
| 사용자 정의 테인트 및 톨러레이션 | 기술 프리뷰 | 기술 프리뷰 | 기술 프리뷰 |
| OpenShift Virtualization을 위해 호스팅된 컨트롤 플레인의 NVIDIA GPU 장치 | 기술 프리뷰 | 기술 프리뷰 | 기술 프리뷰 |
| 연결이 끊긴 환경에서 IBM Z에서 호스팅되는 컨트롤 플레인 | 기술 프리뷰 | 기술 프리뷰 | 일반적으로 사용 가능 |
2장. 호스팅된 컨트롤 플레인 개요 링크 복사링크가 클립보드에 복사되었습니다!
독립 실행형 또는 호스팅된 컨트롤 플레인 구성의 두 가지 다른 컨트롤 플레인 구성을 사용하여 OpenShift Container Platform 클러스터를 배포할 수 있습니다. 독립 실행형 구성은 전용 가상 머신 또는 물리적 시스템을 사용하여 컨트롤 플레인을 호스팅합니다. OpenShift Container Platform의 호스팅된 컨트롤 플레인을 사용하면 각 컨트롤 플레인의 전용 가상 또는 물리적 머신 없이도 관리 클러스터에서 컨트롤 플레인을 Pod로 생성합니다.
2.1. 호스트된 컨트롤 플레인 소개 링크 복사링크가 클립보드에 복사되었습니다!
호스팅되는 컨트롤 플레인은 다음 플랫폼에서 Kubernetes Operator에 지원되는 멀티 클러스터 엔진 버전을 사용하여 사용할 수 있습니다.
- 에이전트 공급자를 사용하여 베어 메탈
- 비베어 메탈 에이전트 시스템, 기술 프리뷰 기능
- OpenShift Virtualization
- AWS(Amazon Web Services)
- IBM Z
- IBM Power
- RHOSP(Red Hat OpenStack Platform) 17.1, 기술 프리뷰 기능
호스트된 컨트롤 플레인 기능은 기본적으로 활성화되어 있습니다.
다중 클러스터 엔진 Operator는 RHACM(Red Hat Advanced Cluster Management)의 통합 부분이며 RHACM에서 기본적으로 활성화됩니다. 그러나 호스팅된 컨트롤 플레인을 사용하려면 RHACM이 필요하지 않습니다.
2.1.1. 호스트된 컨트롤 플레인 아키텍처 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform은 종종 클러스터가 컨트롤 플레인과 데이터 플레인으로 구성된 결합형 또는 독립 실행형 모델로 배포됩니다. 컨트롤 플레인에는 상태를 확인하는 API 끝점, 스토리지 끝점, 워크로드 스케줄러, 작업자가 포함됩니다. 데이터 플레인에는 워크로드 및 애플리케이션이 실행되는 컴퓨팅, 스토리지 및 네트워킹이 포함됩니다.
독립 실행형 컨트롤 플레인은 쿼럼을 보장하기 위해 최소 수를 사용하여 물리적 또는 가상 노드 전용 그룹에 의해 호스팅됩니다. 네트워크 스택이 공유됩니다. 클러스터에 대한 관리자 액세스는 클러스터의 컨트롤 플레인, 머신 관리 API 및 클러스터 상태에 기여하는 기타 구성 요소를 시각화할 수 있습니다.
독립 실행형 모델이 제대로 작동하지만 일부 상황에서는 컨트롤 플레인 및 데이터 플레인이 분리되는 아키텍처가 필요합니다. 이러한 경우 데이터 플레인은 전용 물리적 호스팅 환경을 사용하는 별도의 네트워크 도메인에 있습니다. 컨트롤 플레인은 Kubernetes의 네이티브 배포 및 상태 저장 세트와 같은 고급 프리미티브를 사용하여 호스팅됩니다. 컨트롤 플레인은 다른 워크로드로 처리됩니다.
2.1.2. 호스팅된 컨트롤 플레인의 장점 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 컨트롤 플레인을 사용하면 진정한 하이브리드 클라우드 접근 방식을 구축하고 다른 여러 가지 이점을 누릴 수 있습니다.
- 컨트롤 플레인이 분리되고 전용 호스팅 서비스 클러스터에서 호스팅되므로 관리와 워크로드 간의 보안 경계가 더욱 강화됩니다. 결과적으로 클러스터의 인증 정보를 다른 사용자에게 유출될 가능성이 줄어듭니다. 인프라 시크릿 계정 관리도 분리되므로 클러스터 인프라 관리자는 실수로 컨트롤 플레인 인프라를 삭제할 수 없습니다.
- 호스팅된 컨트롤 플레인을 사용하면 더 적은 수의 노드에서 많은 컨트롤 플레인을 실행할 수 있습니다. 이로 인해 클러스터 비용이 더 경제적이 됩니다.
- 컨트롤 플레인은 OpenShift Container Platform에서 시작되는 Pod로 구성되므로 컨트롤 플레인이 빠르게 시작됩니다. 모니터링, 로깅, 자동 확장과 같은 컨트롤 플레인 및 워크로드에 동일한 원칙이 적용됩니다.
- 인프라 화면에서 레지스트리, HAProxy, 클러스터 모니터링, 스토리지 노드 및 기타 인프라 구성 요소를 테넌트의 클라우드 공급자 계정으로 푸시하여 테넌트에서 사용을 분리할 수 있습니다.
- 운영 화면에서 다중 클러스터 관리는 더 중앙 집중화되어 클러스터 상태 및 일관성에 영향을 미치는 외부 요인이 줄어듭니다. 사이트 안정성 엔지니어는 문제를 디버그하고 클러스터 데이터 플레인으로 이동하여 문제 해결 시간 (TTR: Time to Resolution)이 단축되고 생산성 향상으로 이어질 수 있습니다.
2.2. 호스팅된 컨트롤 플레인과 OpenShift Container Platform의 차이점 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 컨트롤 플레인은 OpenShift Container Platform의 폼 요소입니다. 호스팅된 클러스터와 독립형 OpenShift Container Platform 클러스터는 다르게 구성 및 관리됩니다. OpenShift Container Platform과 호스팅된 컨트롤 플레인의 차이점을 알아보려면 다음 표를 참조하십시오.
2.2.1. 클러스터 생성 및 라이프사이클 링크 복사링크가 클립보드에 복사되었습니다!
| OpenShift Container Platform | 호스팅된 컨트롤 플레인 |
|---|---|
|
|
기존 OpenShift Container Platform 클러스터에서 |
2.2.2. 클러스터 구성 링크 복사링크가 클립보드에 복사되었습니다!
| OpenShift Container Platform | 호스팅된 컨트롤 플레인 |
|---|---|
|
|
|
2.2.3. etcd 암호화 링크 복사링크가 클립보드에 복사되었습니다!
| OpenShift Container Platform | 호스팅된 컨트롤 플레인 |
|---|---|
|
AES-GCM 또는 AES-CBC와 함께 |
Amazon Web Services의 AES-CBC 또는 KMS와 함께 |
2.2.4. Operator 및 컨트롤 플레인 링크 복사링크가 클립보드에 복사되었습니다!
| OpenShift Container Platform | 호스팅된 컨트롤 플레인 |
|---|---|
| 독립 실행형 OpenShift Container Platform 클러스터에는 각 컨트롤 플레인 구성 요소에 대한 별도의 Operator가 포함되어 있습니다. | 호스팅된 클러스터에는 관리 클러스터의 호스팅된 컨트롤 플레인 네임스페이스에서 실행되는 컨트롤 플레인 Operator라는 단일 Operator가 포함되어 있습니다. |
| etcd는 컨트롤 플레인 노드에 마운트된 스토리지를 사용합니다. etcd 클러스터 Operator는 etcd를 관리합니다. | etcd는 스토리지에 영구 볼륨 클레임을 사용하며 Control Plane Operator에서 관리합니다. |
| Ingress Operator, 네트워크 관련 Operator 및 OLM(Operator Lifecycle Manager)은 클러스터에서 실행됩니다. | Ingress Operator, 네트워크 관련 Operator 및 OLM(Operator Lifecycle Manager)은 관리 클러스터의 호스팅된 컨트롤 플레인 네임스페이스에서 실행됩니다. |
| OAuth 서버는 클러스터 내에서 실행되며 클러스터의 경로를 통해 노출됩니다. | OAuth 서버는 컨트롤 플레인 내부에서 실행되며 관리 클러스터의 경로, 노드 포트 또는 로드 밸런서를 통해 노출됩니다. |
2.2.5. 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
| OpenShift Container Platform | 호스팅된 컨트롤 플레인 |
|---|---|
|
CVO(Cluster Version Operator)는 업데이트 프로세스를 오케스트레이션하고 |
호스팅된 컨트롤 플레인 업데이트로 인해 |
| OpenShift Container Platform 클러스터를 업데이트하면 컨트롤 플레인 및 컴퓨팅 머신이 모두 업데이트됩니다. | 호스팅 클러스터를 업데이트한 후 컨트롤 플레인만 업데이트됩니다. 노드 풀 업데이트를 별도로 수행합니다. |
2.2.6. 머신 구성 및 관리 링크 복사링크가 클립보드에 복사되었습니다!
| OpenShift Container Platform | 호스팅된 컨트롤 플레인 |
|---|---|
|
|
|
| 컨트롤 플레인 시스템 세트를 사용할 수 있습니다. | 컨트롤 플레인 시스템 세트가 없습니다. |
|
|
|
|
|
|
| 머신 및 머신 세트는 클러스터에 노출됩니다. | 업스트림 Cluster CAPI Operator의 머신, 머신 세트 및 머신 배포는 머신을 관리하는 데 사용되지만 사용자에게 노출되지 않습니다. |
| 클러스터를 업데이트할 때 모든 머신 세트가 자동으로 업그레이드됩니다. | 호스트된 클러스터 업데이트와 독립적으로 노드 풀을 업데이트합니다. |
| 클러스터에서 인플레이스 업그레이드만 지원됩니다. | 호스팅된 클러스터에서 교체 및 인플레이스 업그레이드가 모두 지원됩니다. |
| Machine Config Operator는 머신 구성을 관리합니다. | Machine Config Operator는 호스팅된 컨트롤 플레인에 존재하지 않습니다. |
|
|
|
| MCP(Machine Config Daemon)는 각 노드의 구성 변경 및 업데이트를 관리합니다. | 인플레이스 업그레이드의 경우 노드 풀 컨트롤러는 구성에 따라 머신을 업데이트하는 런타임 Pod를 생성합니다. |
| SR-IOV Operator와 같은 머신 구성 리소스를 수정할 수 있습니다. | 머신 구성 리소스를 수정할 수 없습니다. |
2.2.7. 네트워킹 링크 복사링크가 클립보드에 복사되었습니다!
| OpenShift Container Platform | 호스팅된 컨트롤 플레인 |
|---|---|
| Kube API 서버와 노드가 동일한 VPC(Virtual Private Cloud)에 있으므로 Kube API 서버는 노드와 직접 통신합니다. | Kube API 서버는 Konnectivity를 통해 노드와 통신합니다. Kube API 서버 및 노드는 다른 VPC(Virtual Private Cloud)에 있습니다. |
| 노드는 내부 로드 밸런서를 통해 Kube API 서버와 통신합니다. | 노드는 외부 로드 밸런서 또는 노드 포트를 통해 Kube API 서버와 통신합니다. |
2.2.8. 웹 콘솔 링크 복사링크가 클립보드에 복사되었습니다!
| OpenShift Container Platform | 호스팅된 컨트롤 플레인 |
|---|---|
| 웹 콘솔에는 컨트롤 플레인의 상태가 표시됩니다. | 웹 콘솔에 컨트롤 플레인의 상태가 표시되지 않습니다. |
| 웹 콘솔을 사용하여 클러스터를 업데이트할 수 있습니다. | 웹 콘솔을 사용하여 호스팅된 클러스터를 업데이트할 수 없습니다. |
| 웹 콘솔에는 시스템과 같은 인프라 리소스가 표시됩니다. | 웹 콘솔에 인프라 리소스가 표시되지 않습니다. |
|
웹 콘솔을 사용하여 | 웹 콘솔을 사용하여 머신을 구성할 수 없습니다. |
2.3. 호스팅된 컨트롤 플레인, 다중 클러스터 엔진 Operator 및 RHACM 간의 관계 링크 복사링크가 클립보드에 복사되었습니다!
Kubernetes Operator에 다중 클러스터 엔진을 사용하여 호스팅되는 컨트롤 플레인을 구성할 수 있습니다. 멀티 클러스터 엔진 Operator 클러스터 라이프사이클은 다양한 인프라 클라우드 공급자, 프라이빗 클라우드 및 온프레미스 데이터 센터에서 Kubernetes 클러스터를 생성, 가져오기, 관리 및 제거하는 프로세스를 정의합니다.
다중 클러스터 엔진 Operator는 RHACM(Red Hat Advanced Cluster Management)의 통합 부분이며 RHACM에서 기본적으로 활성화됩니다. 그러나 호스팅된 컨트롤 플레인을 사용하려면 RHACM이 필요하지 않습니다.
다중 클러스터 엔진 Operator는 OpenShift Container Platform 및 RHACM 허브 클러스터에 대한 클러스터 관리 기능을 제공하는 클러스터 라이프사이클 Operator입니다. 멀티 클러스터 엔진 Operator는 클러스터 플릿 관리를 개선하고 클라우드 및 데이터 센터 전체에서 OpenShift Container Platform 클러스터 라이프사이클 관리를 지원합니다.
그림 2.1. 클러스터 라이프사이클 및 기반
OpenShift Container Platform에서 다중 클러스터 엔진 Operator를 독립 실행형 클러스터 관리자 또는 RHACM 허브 클러스터의 일부로 사용할 수 있습니다.
관리 클러스터를 호스팅 클러스터라고도 합니다.
독립 실행형 또는 호스팅된 컨트롤 플레인 구성의 두 가지 다른 컨트롤 플레인 구성을 사용하여 OpenShift Container Platform 클러스터를 배포할 수 있습니다. 독립 실행형 구성은 전용 가상 머신 또는 물리적 시스템을 사용하여 컨트롤 플레인을 호스팅합니다. OpenShift Container Platform의 호스팅된 컨트롤 플레인을 사용하면 각 컨트롤 플레인의 전용 가상 또는 물리적 머신 없이도 관리 클러스터에서 컨트롤 플레인을 Pod로 생성합니다.
그림 2.2. RHACM 및 다중 클러스터 엔진 Operator 소개 다이어그램
2.3.1. RHACM에서 다중 클러스터 엔진 Operator 호스트 클러스터 검색 링크 복사링크가 클립보드에 복사되었습니다!
호스트 클러스터를 RHACM(Red Hat Advanced Cluster Management) 허브 클러스터로 가져와서 RHACM 관리 구성 요소를 사용하여 관리하려면 Red Hat Advanced Cluster Management 공식 설명서의 지침을 참조하십시오.
2.4. 호스팅된 컨트롤 플레인 버전 관리 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 컨트롤 플레인 기능에는 별도의 버전 관리 및 지원 수준이 필요할 수 있는 다음 구성 요소가 포함되어 있습니다.
- 관리 클러스터
- HyperShift Operator
-
호스트된 컨트롤 플레인(
hcp) 명령줄 인터페이스(CLI) -
Hypershift.openshift.ioAPI - Control Plane Operator
2.4.1. 관리 클러스터 링크 복사링크가 클립보드에 복사되었습니다!
프로덕션 사용을 위한 관리 클러스터에서는 소프트웨어 카탈로그를 통해 사용할 수 있는 Kubernetes Operator용 다중 클러스터 엔진이 필요합니다. 다중 클러스터 엔진 Operator는 HyperShift Operator의 지원되는 빌드를 번들로 제공합니다. 관리 클러스터가 계속 지원되려면 다중 클러스터 엔진 Operator가 실행되는 OpenShift Container Platform 버전을 사용해야 합니다. 일반적으로 다중 클러스터 엔진 Operator의 새 릴리스는 다음 OpenShift Container Platform 버전에서 실행됩니다.
- OpenShift Container Platform의 최신 GA 버전
- OpenShift Container Platform의 최신 GA 버전 이전의 두 가지 버전
관리 클러스터에서 HyperShift Operator를 통해 설치할 수 있는 OpenShift Container Platform 버전의 전체 목록은 HyperShift Operator 버전에 따라 다릅니다. 그러나 목록에는 항상 관리 클러스터와 동일한 OpenShift Container Platform 버전과 관리 클러스터를 기준으로 두 개의 이전 마이너 버전이 포함됩니다. 예를 들어 관리 클러스터가 4.17을 실행 중이고 지원되는 다중 클러스터 엔진 Operator인 경우 HyperShift Operator는 4.17, 4.16, 4.15 및 4.14 호스팅 클러스터를 설치할 수 있습니다.
OpenShift Container Platform의 각 메이저, 마이너 또는 패치 버전 릴리스에서 호스팅되는 컨트롤 플레인의 두 가지 구성 요소가 릴리스됩니다.
- HyperShift Operator
-
hcp명령줄 인터페이스(CLI)
2.4.2. HyperShift Operator 링크 복사링크가 클립보드에 복사되었습니다!
HyperShift Operator는 HostedCluster API 리소스로 표시되는 호스팅 클러스터의 라이프사이클을 관리합니다. HyperShift Operator는 각 OpenShift Container Platform 릴리스와 함께 릴리스됩니다. HyperShift Operator는 hypershift 네임스페이스에 supported-versions 구성 맵을 생성합니다. 구성 맵에는 지원되는 호스팅 클러스터 버전이 포함되어 있습니다.
동일한 관리 클러스터에서 다른 버전의 컨트롤 플레인을 호스팅할 수 있습니다.
supported-versions 구성 맵 오브젝트의 예
2.4.3. 호스팅된 컨트롤 플레인 CLI 링크 복사링크가 클립보드에 복사되었습니다!
hcp CLI를 사용하여 호스트된 클러스터를 생성할 수 있습니다. 다중 클러스터 엔진 Operator에서 CLI를 다운로드할 수 있습니다. hcp version 명령을 실행하면 CLI에서 kubeconfig 파일에 대해 지원하는 최신 OpenShift Container Platform이 출력에 표시됩니다.
2.4.4. hypershift.openshift.io API 링크 복사링크가 클립보드에 복사되었습니다!
HostedCluster 및 NodePool 과 같은 hypershift.openshift.io API 리소스를 사용하여 대규모로 OpenShift Container Platform 클러스터를 생성하고 관리할 수 있습니다. HostedCluster 리소스에는 컨트롤 플레인 및 일반 데이터 플레인 구성이 포함되어 있습니다. HostedCluster 리소스를 생성할 때 연결된 노드가 없는 완전히 작동하는 컨트롤 플레인이 있습니다. NodePool 리소스는 HostedCluster 리소스에 연결된 확장 가능한 작업자 노드 집합입니다.
API 버전 정책은 일반적으로 Kubernetes API 버전 관리 정책과 일치합니다.
호스팅된 컨트롤 플레인을 업데이트하려면 호스팅된 클러스터 및 노드 풀을 업데이트해야 합니다. 자세한 내용은 "호스팅된 컨트롤 플레인 업데이트"를 참조하십시오.
2.4.5. Control Plane Operator 링크 복사링크가 클립보드에 복사되었습니다!
Control Plane Operator는 다음 아키텍처의 각 OpenShift Container Platform 페이로드 릴리스 이미지의 일부로 릴리스됩니다.
- amd64
- arm64
- 다중 아키텍처
2.5. 호스팅된 컨트롤 플레인의 일반 개념 및 가상 사용자집 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform에 호스팅되는 컨트롤 플레인을 사용하는 경우 주요 개념과 관련 가상 사용자를 이해하는 것이 중요합니다.
2.5.1. 개념 링크 복사링크가 클립보드에 복사되었습니다!
- 데이터 플레인
- 워크로드 및 애플리케이션이 실행되는 컴퓨팅, 스토리지 및 네트워킹이 포함된 클러스터의 일부입니다.
- 호스트된 클러스터
- 관리 클러스터에서 호스팅되는 컨트롤 플레인 및 API 끝점이 있는 OpenShift Container Platform 클러스터입니다. 호스트된 클러스터에는 컨트롤 플레인과 해당 데이터 플레인이 포함됩니다.
- 호스트된 클러스터 인프라
- 테넌트 또는 최종 사용자 클라우드 계정에 존재하는 네트워크, 컴퓨팅 및 스토리지 리소스입니다.
- 호스트된 컨트롤 플레인
- 호스팅된 클러스터의 API 끝점에 의해 노출되는 관리 클러스터에서 실행되는 OpenShift Container Platform 컨트롤 플레인입니다. 컨트롤 플레인의 구성 요소에는 etcd, Kubernetes API 서버, Kubernetes 컨트롤러 관리자 및 VPN이 포함됩니다.
- 호스트 클러스터
- 관리 클러스터를 참조하십시오.
- 관리형 클러스터
- 허브 클러스터가 관리하는 클러스터입니다. 이 용어는 Kubernetes Operator의 다중 클러스터 엔진에서 Red Hat Advanced Cluster Management에서 관리하는 클러스터 라이프사이클에 따라 다릅니다. 관리형 클러스터는 관리 클러스터와 동일하지 않습니다. 자세한 내용은 관리 클러스터를 참조하십시오.
- 관리 클러스터
- HyperShift Operator가 배포되고 호스팅된 클러스터의 컨트롤 플레인이 호스팅되는 OpenShift Container Platform 클러스터입니다. 관리 클러스터는 호스팅 클러스터와 동일합니다.
- 관리 클러스터 인프라
- 관리 클러스터의 네트워크, 컴퓨팅 및 스토리지 리소스입니다.
- 노드 풀
- 호스트 클러스터와 연결된 컴퓨팅 노드 세트를 관리하는 리소스입니다. 컴퓨팅 노드는 호스팅된 클러스터 내에서 애플리케이션과 워크로드를 실행합니다.
2.5.2. 가상 사용자 링크 복사링크가 클립보드에 복사되었습니다!
- 클러스터 인스턴스 관리자
-
이 역할의 사용자는 독립 실행형 OpenShift Container Platform의 관리자와 동일한 것으로 간주됩니다. 이 사용자에게는 프로비저닝된 클러스터에
cluster-admin역할이 있지만 클러스터 업데이트 또는 구성 시 전원이 켜지지 않을 수 있습니다. 이 사용자는 클러스터에 예상된 일부 구성을 확인하기 위해 읽기 전용 액세스 권한이 있을 수 있습니다. - 클러스터 인스턴스 사용자
- 이 역할의 사용자는 독립 실행형 OpenShift Container Platform의 개발자와 동일한 것으로 간주됩니다. 이 사용자에게는 소프트웨어 카탈로그 또는 시스템에 대한 보기가 없습니다.
- 클러스터 서비스 소비자
- 이 역할에서 컨트롤 플레인 및 작업자 노드를 요청하거나, 드라이브 업데이트를 요청하거나, 외부화된 구성을 수정할 수 있다고 가정합니다. 일반적으로 이 사용자는 클라우드 인증 정보 또는 인프라 암호화 키를 관리하거나 액세스하지 않습니다. 클러스터 서비스 소비자 가상 사용자는 호스트된 클러스터를 요청하고 노드 풀과 상호 작용할 수 있습니다. 이 역할에는 논리 경계 내에서 호스팅된 클러스터 및 노드 풀을 생성, 읽기, 업데이트 또는 삭제하는 RBAC가 있다고 가정합니다.
- 클러스터 서비스 공급자
이 역할에는 일반적으로 관리 클러스터에 대한
cluster-admin역할이 있고 HyperShift Operator의 가용성을 모니터링하고 소유할 수 있는 RBAC와 테넌트의 호스트 클러스터에 대한 컨트롤 플레인이 있는 사용자입니다. 클러스터 서비스 공급자 개인은 다음 예제를 포함하여 여러 활동을 담당합니다.- 컨트롤 플레인 가용성, 가동 시간 및 안정성에 대한 서비스 수준 오브젝트 보유
- 컨트롤 플레인을 호스팅할 관리 클러스터의 클라우드 계정 구성
- 사용 가능한 컴퓨팅 리소스에 대한 호스트 인식이 포함된 사용자 프로비저닝 인프라 구성
3장. 호스팅된 컨트롤 플레인 배포 준비 링크 복사링크가 클립보드에 복사되었습니다!
3.1. 호스트된 컨트롤 플레인 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
호스트된 컨트롤 플레인의 컨텍스트에서 관리 클러스터 는 HyperShift Operator가 배포되고 호스팅된 클러스터의 컨트롤 플레인이 호스팅되는 OpenShift Container Platform 클러스터입니다.
컨트롤 플레인은 호스팅된 클러스터와 연결되며 단일 네임스페이스에서 Pod로 실행됩니다. 클러스터 서비스 소비자가 호스팅된 클러스터를 생성할 때 컨트롤 플레인과 독립적인 작업자 노드를 생성합니다.
다음 요구 사항은 호스트된 컨트롤 플레인에 적용됩니다.
- HyperShift Operator를 실행하려면 관리 클러스터에 3개 이상의 작업자 노드가 필요합니다.
-
DNS(Domain Name Service) 프로토콜이 예상대로 작동하도록 하려면 TCP(Transmission Control Protocol) 및 UDP(User Datagram Protocol)에서 방화벽 포트
53을 열어야 합니다. - 베어 메탈 플랫폼 또는 OpenShift Virtualization과 같이 관리 클러스터와 작업자 노드를 온프레미스에서 모두 실행할 수 있습니다. 또한 AWS(Amazon Web Services)와 같은 클라우드 인프라에서 관리 클러스터와 작업자 노드를 모두 실행할 수 있습니다.
-
AWS 및 작업자 노드에서 관리 클러스터를 실행하거나 온프레미스에서 작업자 노드를 실행하는 것과 같은 혼합 인프라를 사용하거나 온프레미스에서 AWS 및 관리 클러스터에서 작업자 노드를 실행하는 경우
PublicAndPrivate게시 전략을 사용하고 지원 매트릭스의 대기 시간 요구 사항을 따라야 합니다. - Bare Metal Operator가 머신을 시작하는 베어 메탈 호스트(BMH) 배포에서 호스팅된 컨트롤 플레인은 BMC(Baseboard Management Controller)에 연결할 수 있어야 합니다. 보안 프로필에서 Cluster Baremetal Operator에서 Redfish 자동화를 활성화하기 위해 BMH에 BMC가 있는 네트워크에 액세스할 수 없는 경우 BYO ISO 지원을 사용할 수 있습니다. 그러나 BYO 모드에서는 OpenShift Container Platform에서 BMH의 전원을 자동화할 수 없습니다.
3.1.1. 호스팅된 컨트롤 플레인 지원 매트릭스 링크 복사링크가 클립보드에 복사되었습니다!
Kubernetes Operator용 멀티 클러스터 엔진에 HyperShift Operator가 포함되어 있으므로 호스트된 컨트롤 플레인 릴리스는 다중 클러스터 엔진 Operator 릴리스와 일치합니다. 자세한 내용은 OpenShift Operator 라이프 사이클 을 참조하십시오.
3.1.1.1. 관리 클러스터 지원 링크 복사링크가 클립보드에 복사되었습니다!
지원되는 독립 실행형 OpenShift Container Platform 클러스터는 관리 클러스터가 될 수 있습니다.
단일 노드 OpenShift Container Platform 클러스터는 관리 클러스터로 지원되지 않습니다. 리소스 제약 조건이 있는 경우 독립 실행형 OpenShift Container Platform 컨트롤 플레인과 호스팅된 컨트롤 플레인 간에 인프라를 공유할 수 있습니다. 자세한 내용은 "호스트 및 독립 실행형 컨트롤 플레인 간 공유 인프라"를 참조하십시오.
다음 표는 다중 클러스터 엔진 Operator 버전을 지원하는 관리 클러스터 버전에 매핑합니다.
| 관리 클러스터 버전 | 지원되는 다중 클러스터 엔진 Operator 버전 |
|---|---|
| 4.14 - 4.17 | 2.6 |
| 4.15 - 4.17 | 2.7 |
| 4.16 - 4.18 | 2.8 |
| 4.17 - 4.19 | 2.9 |
| 4.18 - 4.20 | 2.10 |
3.1.1.2. 호스트된 클러스터 지원 링크 복사링크가 클립보드에 복사되었습니다!
호스트 클러스터의 경우 관리 클러스터 버전과 호스팅된 클러스터 버전 간에는 직접적인 관계가 없습니다. 호스팅된 클러스터 버전은 다중 클러스터 엔진 Operator 버전에 포함된 HyperShift Operator에 따라 다릅니다.
관리 클러스터와 호스팅 클러스터 간에 최대 대기 시간이 200ms인지 확인합니다. 이 요구 사항은 관리 클러스터가 AWS에 있고 컴퓨팅 노드가 온프레미스인 경우와 같이 혼합 인프라 배포에서 특히 중요합니다.
다음 표에서는 다중 클러스터 엔진 Operator 버전과 연결된 HyperShift Operator를 사용하여 생성할 수 있는 호스팅 클러스터 버전을 보여줍니다.
HyperShift Operator는 다음 표에서 호스팅된 클러스터 버전을 지원하지만 다중 클러스터 엔진 Operator는 현재 버전보다 2 이전 버전만 지원합니다. 예를 들어 현재 호스팅된 클러스터 버전이 4.20인 경우 multicluster 엔진 Operator는 버전 4.18을 지금까지 지원합니다. 다중 클러스터 엔진 Operator에서 지원하는 버전 중 하나 이전 버전보다 이전 버전의 호스팅 클러스터를 사용하려면 멀티 클러스터 엔진 Operator에서 관리되지 않도록 호스트된 클러스터를 분리하거나 이전 버전의 multicluster engine Operator를 사용할 수 있습니다. 멀티 클러스터 엔진 Operator에서 호스트 클러스터를 분리하는 방법은 관리에서 클러스터 제거(RHACM 문서)를 참조하십시오. 다중 클러스터 엔진 Operator 지원에 대한 자세한 내용은 The multicluster engine for Kubernetes operator 2.10 Support Matrix (Red Hat Knowledgebase)를 참조하십시오.
| 호스팅 클러스터 버전 | 다중 클러스터 엔진 Operator 2.6의 Hypershift Operator | 다중 클러스터 엔진 Operator 2.7의 Hypershift Operator | 다중 클러스터 엔진 Operator 2.8의 Hypershift Operator | 다중 클러스터 엔진 Operator 2.9의 Hypershift Operator | 다중 클러스터 엔진 Operator 2.10의 Hypershift Operator |
|---|---|---|---|---|---|
| 4.14 | 제공됨 | 제공됨 | 제공됨 | 제공됨 | 제공됨 |
| 4.15 | 제공됨 | 제공됨 | 제공됨 | 제공됨 | 제공됨 |
| 4.16 | 제공됨 | 제공됨 | 제공됨 | 제공됨 | 제공됨 |
| 4.17 | 없음 | 제공됨 | 제공됨 | 제공됨 | 제공됨 |
| 4.18 | 없음 | 없음 | 제공됨 | 제공됨 | 제공됨 |
| 4.19 | 없음 | 없음 | 없음 | 제공됨 | 제공됨 |
| 4.20 | 없음 | 없음 | 없음 | 없음 | 제공됨 |
3.1.1.3. 호스트된 클러스터 플랫폼 지원 링크 복사링크가 클립보드에 복사되었습니다!
호스트된 클러스터는 하나의 인프라 플랫폼만 지원합니다. 예를 들어 다른 인프라 플랫폼에서 여러 노드 풀을 생성할 수 없습니다.
다음 표는 호스팅된 컨트롤 플레인의 각 플랫폼에 지원되는 OpenShift Container Platform 버전을 나타냅니다.
IBM Power 및 IBM Z의 경우:
- 64비트 x86 아키텍처 또는 s390x 아키텍처를 기반으로 하는 머신 유형에서 컨트롤 플레인을 실행해야 합니다.
- IBM Power 또는 IBM Z에서 노드 풀을 실행해야 합니다.
다음 표에서 관리 클러스터 버전은 다중 클러스터 엔진 Operator가 활성화된 OpenShift Container Platform 버전입니다.
| 호스트된 클러스터 플랫폼 | 관리 클러스터 버전 | 호스팅 클러스터 버전 |
|---|---|---|
| Amazon Web Services | 4.16 - 4.20 | 4.16 - 4.20 |
| IBM Power | 4.17 - 4.20 | 4.17 - 4.20 |
| IBM Z | 4.17 - 4.20 | 4.17 - 4.20 |
| OpenShift Virtualization | 4.14 - 4.20 | 4.14 - 4.20 |
| 베어 메탈 | 4.14 - 4.20 | 4.14 - 4.20 |
| 비 바이어(bare-metal) 에이전트 머신 (기술 프리뷰) | 4.16 - 4.20 | 4.16 - 4.20 |
| Red Hat OpenStack Platform (RHOSP) (기술 프리뷰) | 4.19 - 4.20 | 4.19 - 4.20 |
3.1.1.4. 다중 아키텍처 지원 링크 복사링크가 클립보드에 복사되었습니다!
다음 표는 플랫폼별로 구성된 여러 아키텍처의 호스팅 컨트롤 플레인에 대한 지원 상태를 나타냅니다.
| OpenShift Container Platform 버전 | ARM64 컨트롤 플레인 | ARM64 컴퓨팅 노드 |
|---|---|---|
| 4.20 | 정식 출시일 (GA) | 정식 출시일 (GA) |
| 4.19 | 정식 출시일 (GA) | 정식 출시일 (GA) |
| 4.18 | 정식 출시일 (GA) | 정식 출시일 (GA) |
| 4.17 | 정식 출시일 (GA) | 정식 출시일 (GA) |
| 4.16 | 기술 프리뷰 | 정식 출시일 (GA) |
| 4.15 | 기술 프리뷰 | 정식 출시일 (GA) |
| 4.14 | 기술 프리뷰 | 정식 출시일 (GA) |
| OpenShift Container Platform 버전 | ARM64 컨트롤 플레인 | ARM64 컴퓨팅 노드 |
|---|---|---|
| 4.20 | 사용할 수 없음 | 기술 프리뷰 |
| 4.19 | 사용할 수 없음 | 기술 프리뷰 |
| 4.18 | 사용할 수 없음 | 기술 프리뷰 |
| 4.17 | 사용할 수 없음 | 기술 프리뷰 |
| 4.16 | 사용할 수 없음 | 기술 프리뷰 |
| 4.15 | 사용할 수 없음 | 기술 프리뷰 |
| 4.14 | 사용할 수 없음 | 기술 프리뷰 |
| OpenShift Container Platform 버전 | ARM64 컨트롤 플레인 | ARM64 컴퓨팅 노드 |
|---|---|---|
| 4.20 | 사용할 수 없음 | 사용할 수 없음 |
| 4.19 | 사용할 수 없음 | 사용할 수 없음 |
| 4.18 | 사용할 수 없음 | 사용할 수 없음 |
| 4.17 | 사용할 수 없음 | 사용할 수 없음 |
| OpenShift Container Platform 버전 | 컨트롤 플레인 | 컴퓨팅 노드 |
|---|---|---|
| 4.20 |
|
|
| 4.19 |
|
|
| 4.18 |
|
|
| 4.17 |
|
|
| OpenShift Container Platform 버전 | 컨트롤 플레인 | 컴퓨팅 노드 |
|---|---|---|
| 4.20 |
|
|
| 4.19 |
|
|
| 4.18 |
|
|
| 4.17 |
|
|
| OpenShift Container Platform 버전 | ARM64 컨트롤 플레인 | ARM64 컴퓨팅 노드 |
|---|---|---|
| 4.20 | 사용할 수 없음 | 사용할 수 없음 |
| 4.19 | 사용할 수 없음 | 사용할 수 없음 |
| 4.18 | 사용할 수 없음 | 사용할 수 없음 |
| 4.17 | 사용할 수 없음 | 사용할 수 없음 |
| 4.16 | 사용할 수 없음 | 사용할 수 없음 |
| 4.15 | 사용할 수 없음 | 사용할 수 없음 |
| 4.14 | 사용할 수 없음 | 사용할 수 없음 |
3.1.1.5. 다중 클러스터 엔진 Operator 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
다른 버전의 multicluster 엔진 Operator로 업데이트할 때 다중 클러스터 엔진 Operator 버전에 포함된 HyperShift Operator가 호스트된 클러스터 버전을 지원하는 경우 호스팅된 클러스터를 계속 실행할 수 있습니다. 다음 표는 업데이트된 다중 클러스터 엔진 Operator 버전에서 지원되는 호스팅 클러스터 버전을 보여줍니다.
HyperShift Operator는 다음 표에서 호스팅된 클러스터 버전을 지원하지만 다중 클러스터 엔진 Operator는 현재 버전보다 2 이전 버전만 지원합니다. 예를 들어 현재 호스팅된 클러스터 버전이 4.20인 경우 multicluster 엔진 Operator는 버전 4.18을 지금까지 지원합니다. 다중 클러스터 엔진 Operator에서 지원하는 버전 중 하나 이전 버전보다 이전 버전의 호스팅 클러스터를 사용하려면 멀티 클러스터 엔진 Operator에서 관리되지 않도록 호스트된 클러스터를 분리하거나 이전 버전의 multicluster engine Operator를 사용할 수 있습니다. 멀티 클러스터 엔진 Operator에서 호스트 클러스터를 분리하는 방법은 관리에서 클러스터 제거(RHACM 문서)를 참조하십시오. 다중 클러스터 엔진 Operator 지원에 대한 자세한 내용은 The multicluster engine for Kubernetes operator 2.10 Support Matrix (Red Hat Knowledgebase)를 참조하십시오.
| 업데이트된 다중 클러스터 엔진 Operator 버전 | 지원되는 호스팅 클러스터 버전 |
|---|---|
| 2.5에서 2.6으로 업데이트됨 | OpenShift Container Platform 4.14 - 4.15 |
| 2.6에서 2.7로 업데이트 | OpenShift Container Platform 4.14 - 4.16 |
| 2.7에서 2.8로 업데이트되었습니다. | OpenShift Container Platform 4.14 - 4.17 |
| 2.8에서 2.9로 업데이트되었습니다. | OpenShift Container Platform 4.14 - 4.18 |
| 2.9에서 2.10으로 업데이트되었습니다. | OpenShift Container Platform 4.14 - 4.19 |
예를 들어 관리 클러스터에 OpenShift Container Platform 4.18 호스팅 클러스터가 있고 다중 클러스터 엔진 Operator 2.8에서 2.9로 업데이트하는 경우 호스팅된 클러스터를 계속 실행할 수 있습니다.
3.1.1.6. 기술 프리뷰 기능 링크 복사링크가 클립보드에 복사되었습니다!
다음 목록은 이 릴리스의 기술 프리뷰 상태가 있는 기능을 나타냅니다.
- 베어 메탈이 아닌 에이전트 시스템을 사용하는 호스팅된 컨트롤 플레인
- 호스트된 컨트롤 플레인에 대한 사용자 정의 테인트 및 허용 오차
- OpenShift Virtualization을 위해 호스팅된 컨트롤 플레인의 NVIDIA GPU 장치
- RHOSP(Red Hat OpenStack Platform)에서 호스팅되는 컨트롤 플레인
3.1.2. FIPS 지원 호스트 클러스터 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 컨트롤 플레인의 바이너리는 FIP와 호환되며 호스트된 컨트롤 플레인 명령줄 인터페이스를 제외하고 hcp.
FIPS 지원 호스팅 클러스터를 배포하려면 FIPS 지원 관리 클러스터를 사용해야 합니다. 관리 클러스터에 대한 FIPS 모드를 활성화하려면 FIPS 모드에서 작동하도록 구성된 RHEL(Red Hat Enterprise Linux) 컴퓨터에서 설치 프로그램을 실행해야 합니다. RHEL에서 FIPS 모드를 구성하는 방법에 대한 자세한 내용은 RHEL을 FIPS 모드로 전환 을 참조하십시오.
FIPS 모드에서 부팅된 RHEL 또는 Red Hat Enterprise Linux CoreOS(RHCOS)를 실행하는 경우 OpenShift Container Platform 코어 구성 요소는 x86_64, ppc64le 및 s390x 아키텍처에서만 FIPS 140-2/140-3 검증에 대해 NIST에 제출된 RHEL 암호화 라이브러리를 사용합니다.
FIPS 모드에서 관리 클러스터를 설정한 후 호스트된 클러스터 생성 프로세스가 해당 관리 클러스터에서 실행됩니다.
3.1.3. 호스팅된 컨트롤 플레인의 CIDR 범위 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform에 호스팅되는 컨트롤 플레인을 배포하려면 다음과 같은 필수 Classless Inter-Domain Routing (CIDR) 서브넷 범위를 사용합니다.
-
v4InternalSubnet: 100.65.0.0/16 (OVN-Kubernetes) -
clusterNetwork: 10.132.0.0/14 (pod 네트워크) -
serviceNetwork: 172.31.0.0/16
OpenShift Container Platform CIDR 범위 정의에 대한 자세한 내용은 "CIDR 범위 정의"를 참조하십시오.
3.2. 호스팅된 컨트롤 플레인의 크기 조정 지침 링크 복사링크가 클립보드에 복사되었습니다!
호스트 클러스터 워크로드 및 작업자 노드 수를 포함한 많은 요인은 특정 수의 작업자 노드 내에 적합한 호스팅 컨트롤 플레인 수에 영향을 미칩니다. 이 크기 조정 가이드를 사용하여 호스트된 클러스터 용량 계획에 도움이 됩니다. 이 가이드에서는 고가용성 호스팅 컨트롤 플레인 토폴로지를 가정합니다. 로드 기반 크기 조정 예제는 베어 메탈 클러스터에서 측정되었습니다. 클라우드 기반 인스턴스에는 메모리 크기와 같은 제한 요소가 다를 수 있습니다.
다음 리소스 사용률 크기 조정을 재정의하고 메트릭 서비스 모니터링을 비활성화할 수 있습니다.
OpenShift Container Platform 버전 4.12.9 이상에서 테스트된 다음 고가용성 호스팅 컨트롤 플레인 요구 사항을 참조하십시오.
- 78 Pod
- etcd의 경우 3GiB PV
- 최소 vCPU: 약 5.5코어
- 최소 메모리: 약 19GiB
3.2.1. Pod 제한 링크 복사링크가 클립보드에 복사되었습니다!
각 노드의 maxPods 설정은 컨트롤 플레인 노드에 들어갈 수 있는 호스트 클러스터 수에 영향을 미칩니다. 모든 control-plane 노드에서 maxPods 값을 기록하는 것이 중요합니다. 고가용성 호스팅 컨트롤 플레인마다 약 75개의 Pod를 계획합니다.
베어 메탈 노드의 경우 기본 maxPods 설정 250는 제한 요소가 될 수 있습니다. 이는 머신에 많은 리소스가 부족하더라도 Pod 요구 사항을 충족하는 각 노드에 대해 약 3개의 호스팅 컨트롤 플레인이 적합하기 때문입니다. KubeletConfig 값을 구성하여 maxPods 값을 500으로 설정하면 호스트된 컨트롤 플레인 밀도가 증가할 수 있으므로 추가 컴퓨팅 리소스를 활용할 수 있습니다.
3.2.2. 요청 기반 리소스 제한 링크 복사링크가 클립보드에 복사되었습니다!
클러스터에서 호스팅할 수 있는 최대 호스팅 컨트롤 플레인 수는 Pod의 호스팅된 컨트롤 플레인 CPU 및 메모리 요청을 기반으로 계산됩니다.
고가용성 호스트 컨트롤 플레인은 5개의 vCPU 및 18GiB 메모리를 요청하는 78 Pod로 구성됩니다. 이러한 기준 번호는 클러스터 작업자 노드 리소스 용량과 비교하여 호스팅되는 컨트롤 플레인의 최대 수를 추정합니다.
3.2.3. 로드 기반 제한 링크 복사링크가 클립보드에 복사되었습니다!
클러스터에서 호스팅할 수 있는 최대 호스팅 컨트롤 플레인 수는 일부 워크로드가 호스팅된 컨트롤 플레인 Kubernetes API 서버에 배치될 때 호스팅된 컨트롤 플레인 CPU 및 메모리 사용률을 기반으로 계산됩니다.
다음 방법은 워크로드가 증가할 때 호스팅된 컨트롤 플레인 리소스 사용률을 측정하는 데 사용됩니다.
- KubeVirt 플랫폼을 사용하는 동안 각각 8 vCPU 및 32GiB를 사용하는 9개의 작업자가 있는 호스트 클러스터
다음 정의에 따라 API 컨트롤 플레인 과부하에 중점을 두도록 구성된 워크로드 테스트 프로필입니다.
- 각 네임스페이스에 대해 생성된 오브젝트로, 총 네임스페이스 100개까지 확장
- 연속 오브젝트 삭제 및 생성에 대한 추가 API 과부하
- 워크로드 쿼리-초당 (QPS) 및 Burst 설정은 클라이언트 측 제한을 제거하기 위해 높은 설정
로드가 1000개의 QPS로 증가하면 호스트된 컨트롤 플레인 리소스 사용률이 9개의 vCPU 및 2.5GB 메모리로 증가합니다.
일반적인 크기 조정을 위해 중간 호스트 클러스터 로드인 1000 QPS API 속도와 호스트 클러스터 로드가 많은 2000 QPS API를 고려하십시오.
이 테스트에서는 예상되는 API 로드에 따라 컴퓨팅 리소스 사용률을 높이기 위한 추정 요소를 제공합니다. 정확한 사용률 비율은 클러스터 워크로드의 유형 및 속도에 따라 다를 수 있습니다.
다음 예제에서는 워크로드 및 API 속도 정의에 대한 호스팅된 컨트롤 플레인 리소스 스케일링을 보여줍니다.
| QPS(API 속도) | vCPU 사용 | 메모리 사용량(GiB) |
|---|---|---|
| 낮은 부하 (50 QPS 미만) | 2.9 | 11.1 |
| 중간 로드 (1000 QPS) | 11.9 | 13.6 |
| 높은 부하 (2000 QPS) | 20.9 | 16.1 |
호스트된 컨트롤 플레인 크기 조정은 API 활동, etcd 활동 또는 둘 다로 인해 발생하는 컨트롤 플레인 로드 및 워크로드에 관한 것입니다. 데이터베이스 실행과 같은 데이터 플레인 로드에 중점을 둔 호스팅된 Pod 워크로드는 API 비율이 높지 않을 수 있습니다.
3.2.4. 크기 조정 계산 예 링크 복사링크가 클립보드에 복사되었습니다!
이 예제에서는 다음 시나리오에 대한 크기 조정 지침을 제공합니다.
-
hypershift.openshift.io/control-plane노드로 레이블이 지정된 베어 메탈 작업자 세 개 -
maxPods값이 500으로 설정 - 예상되는 API 속도는 로드 기반 제한에 따라 중간 또는 약 1000입니다.
| 제한 설명 | 서버 1 | 서버 2 |
|---|---|---|
| 작업자 노드의 vCPU 수 | 64 | 128 |
| 작업자 노드의 메모리(GiB) | 128 | 256 |
| 작업자당 최대 Pod 수 | 500 | 500 |
| 컨트롤 플레인을 호스팅하는 데 사용되는 작업자 수 | 3 | 3 |
| 최대 QPS 대상 속도(초당 API 요청) | 1000 | 1000 |
| 작업자 노드 크기 및 API 속도를 기반으로 계산된 값 | 서버 1 | 서버 2 | 계산 노트 |
| vCPU 요청을 기반으로 작업자당 최대 호스트 컨트롤 플레인 | 12.8 | 25.6 | 호스트된 컨트롤 플레인당 총 vCPU 요청 수 5개 |
| vCPU 사용을 기반으로 작업자당 최대 호스트 컨트롤 플레인 | 5.4 | 10.7 | vCPUS Cryostat (2.9 측정 유휴 vCPU 사용량 + (QPS 대상 비율 Cryostat 1000) × 9.0 QPS 증가당 vCPU 사용량 측정) |
| 메모리 요청을 기반으로 작업자당 최대 호스트 컨트롤 플레인 | 7.1 | 14.2 | 작업자 메모리 GiB Cryostat 18GiB의 호스트된 컨트롤 플레인당 총 메모리 요청 |
| 메모리 사용량을 기반으로 작업자당 최대 호스트된 컨트롤 플레인 | 9.4 | 18.8 | 작업자 메모리 GiB Cryostat (1.1 측정 유휴 메모리 사용량 + (QPS 대상 비율 Cryostat 1000) × 2.5는 1000 QPS 증가당 메모리 사용량 측정) |
| 노드 Pod 제한에 따라 작업자당 최대 호스트 컨트롤 플레인 | 6.7 | 6.7 |
호스팅된 컨트롤 플레인당 500 |
| 이전에 언급된 최소 최대값 | 5.4 | 6.7 | |
| vCPU 제한 요소 |
| ||
| 관리 클러스터 내의 최대 호스트 컨트롤 플레인 수 | 16 | 20 | 이전에 언급된 최소 최대 × 3 개의 컨트롤 플레인 작업자 |
| 이름 | 설명 |
|
| 클러스터가 고가용성 호스팅 컨트롤 플레인 리소스 요청을 기반으로 호스팅할 수 있는 최대 호스트 컨트롤 플레인 수입니다. |
|
| 모든 호스팅 컨트롤 플레인이 클러스터 Kube API 서버에 약 50 QPS를 생성하는 경우 클러스터에서 호스팅할 수 있는 호스트 컨트롤 플레인의 최대 최대 수입니다. |
|
| 모든 호스팅된 컨트롤 플레인이 클러스터 Kube API 서버에 약 1000개의 QPS를 생성하는 경우 클러스터에서 호스팅할 수 있는 호스트 컨트롤 플레인의 최대 최대 수입니다. |
|
| 모든 호스팅된 컨트롤 플레인이 약 2000 QPS를 클러스터 Kube API 서버로 만드는 경우 클러스터에서 호스팅할 수 있는 호스팅되는 컨트롤 플레인의 최대 수입니다. |
|
| 클러스터에서 호스트된 컨트롤 플레인의 기존 평균 QPS를 기반으로 호스팅할 수 있는 최대 호스트 컨트롤 플레인 수입니다. 활성 호스트 컨트롤 플레인이 없는 경우 낮은 QPS를 기대할 수 있습니다. |
3.3. 리소스 사용률 측정 덮어쓰기 링크 복사링크가 클립보드에 복사되었습니다!
리소스 사용률에 대한 기준 측정 세트는 호스트된 클러스터마다 다를 수 있습니다.
3.3.1. 호스트 클러스터의 리소스 사용률 측정 덮어쓰기 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 워크로드의 유형 및 속도를 기반으로 리소스 사용률 측정을 덮어쓸 수 있습니다.
프로세스
다음 명령을 실행하여
ConfigMap리소스를 생성합니다.oc create -f <your-config-map-file.yaml>
$ oc create -f <your-config-map-file.yaml>Copy to Clipboard Copied! Toggle word wrap Toggle overflow <
your-config-map-file.yaml>을hcp-sizing-baseline구성 맵이 포함된 YAML 파일의 이름으로 바꿉니다.local-cluster네임스페이스에hcp-sizing-baseline구성 맵을 생성하여 덮어쓸 측정값을 지정합니다. 구성 맵은 다음 YAML 파일과 유사할 수 있습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
hypershift-addon-agent배포를 삭제하여hypershift-addon-agentPod를 다시 시작합니다.oc delete deployment hypershift-addon-agent \ -n open-cluster-management-agent-addon
$ oc delete deployment hypershift-addon-agent \ -n open-cluster-management-agent-addonCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
hypershift-addon-agentPod 로그를 관찰합니다. 다음 명령을 실행하여 재정의된 측정이 구성 맵에서 업데이트되었는지 확인합니다.oc logs hypershift-addon-agent -n open-cluster-management-agent-addon
$ oc logs hypershift-addon-agent -n open-cluster-management-agent-addonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 로그는 다음 출력과 유사할 수 있습니다.
출력 예
2024-01-05T19:41:05.392Z INFO agent.agent-reconciler agent/agent.go:793 setting cpuRequestPerHCP to 5 2024-01-05T19:41:05.392Z INFO agent.agent-reconciler agent/agent.go:802 setting memoryRequestPerHCP to 18 2024-01-05T19:53:54.070Z INFO agent.agent-reconciler agent/hcp_capacity_calculation.go:141 The worker nodes have 12.000000 vCPUs 2024-01-05T19:53:54.070Z INFO agent.agent-reconciler agent/hcp_capacity_calculation.go:142 The worker nodes have 49.173369 GB memory
2024-01-05T19:41:05.392Z INFO agent.agent-reconciler agent/agent.go:793 setting cpuRequestPerHCP to 5 2024-01-05T19:41:05.392Z INFO agent.agent-reconciler agent/agent.go:802 setting memoryRequestPerHCP to 18 2024-01-05T19:53:54.070Z INFO agent.agent-reconciler agent/hcp_capacity_calculation.go:141 The worker nodes have 12.000000 vCPUs 2024-01-05T19:53:54.070Z INFO agent.agent-reconciler agent/hcp_capacity_calculation.go:142 The worker nodes have 49.173369 GB memoryCopy to Clipboard Copied! Toggle word wrap Toggle overflow hcp-sizing-baseline구성 맵에서 재정의된 측정이 제대로 업데이트되지 않으면hypershift-addon-agentPod 로그에 다음 오류 메시지가 표시될 수 있습니다.오류 예
2024-01-05T19:53:54.052Z ERROR agent.agent-reconciler agent/agent.go:788 failed to get configmap from the hub. Setting the HCP sizing baseline with default values. {"error": "configmaps \"hcp-sizing-baseline\" not found"}2024-01-05T19:53:54.052Z ERROR agent.agent-reconciler agent/agent.go:788 failed to get configmap from the hub. Setting the HCP sizing baseline with default values. {"error": "configmaps \"hcp-sizing-baseline\" not found"}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3.2. 메트릭 서비스 모니터링 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
하이퍼shift-addon 관리 클러스터 애드온을 활성화한 후 OpenShift Container Platform 모니터링이 hypershift- 에서 메트릭을 수집할 수 있도록 기본적으로 메트릭 서비스 모니터링이 구성됩니다.
addon
프로세스
다음 단계를 완료하여 메트릭 서비스 모니터링을 비활성화할 수 있습니다.
다음 명령을 실행하여 허브 클러스터에 로그인합니다.
oc login
$ oc loginCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
hypershift-addon-deploy-config배포 구성 사양을 편집합니다.oc edit addondeploymentconfig hypershift-addon-deploy-config \ -n multicluster-engine
$ oc edit addondeploymentconfig hypershift-addon-deploy-config \ -n multicluster-engineCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예와 같이
disableMetrics=true사용자 지정 변수를 사양에 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
disableMetrics=true사용자 지정 변수는 신규 및 기존hypershift-addon관리 클러스터 애드온 모두에 대한 메트릭 서비스 모니터링을 비활성화합니다.
다음 명령을 실행하여 구성 사양에 변경 사항을 적용합니다.
oc apply -f <filename>.yaml
$ oc apply -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4. 호스팅된 컨트롤 플레인 명령줄 인터페이스 설치 링크 복사링크가 클립보드에 복사되었습니다!
호스트된 컨트롤 플레인 명령줄 인터페이스인 hcp 는 호스팅된 컨트롤 플레인을 시작하는 데 사용할 수 있는 툴입니다. 관리 및 구성과 같은 Day 2 작업의 경우 GitOps 또는 자체 자동화 툴을 사용합니다.
3.4.1. 터미널에서 호스팅된 컨트롤 플레인 명령줄 인터페이스 설치 링크 복사링크가 클립보드에 복사되었습니다!
터미널에서 호스팅되는 컨트롤 플레인 CLI(명령줄 인터페이스) hcp 를 설치할 수 있습니다.
사전 요구 사항
- OpenShift Container Platform 클러스터에 Kubernetes Operator 2.5 이상을 위한 다중 클러스터 엔진을 설치했습니다. Red Hat Advanced Cluster Management를 설치할 때 멀티 클러스터 엔진 Operator가 자동으로 설치됩니다. OpenShift Container Platform 소프트웨어 카탈로그의 Operator로 Red Hat Advanced Management 없이 다중 클러스터 엔진 Operator를 설치할 수도 있습니다.
프로세스
다음 명령을 실행하여
hcp바이너리를 다운로드하려면 URL을 가져옵니다.oc get ConsoleCLIDownload hcp-cli-download -o json | jq -r ".spec"
$ oc get ConsoleCLIDownload hcp-cli-download -o json | jq -r ".spec"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
hcp바이너리를 다운로드합니다.wget <hcp_cli_download_url>
$ wget <hcp_cli_download_url>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
hcp_cli_download_url을 이전 단계에서 얻은 URL로 바꿉니다.
다음 명령을 실행하여 다운로드한 아카이브의 압축을 풉니다.
tar xvzf hcp.tar.gz
$ tar xvzf hcp.tar.gzCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
hcp바이너리 파일을 실행 가능하게 만듭니다.chmod +x hcp
$ chmod +x hcpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
hcp바이너리 파일을 경로의 디렉터리로 이동합니다.sudo mv hcp /usr/local/bin/.
$ sudo mv hcp /usr/local/bin/.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Mac 컴퓨터에서 CLI를 다운로드하는 경우 hcp 바이너리 파일에 대한 경고가 표시될 수 있습니다. 바이너리 파일을 실행할 수 있도록 보안 설정을 조정해야 합니다.
검증
다음 명령을 실행하여 사용 가능한 매개변수 목록이 표시되는지 확인합니다.
hcp create cluster <platform> --help
$ hcp create cluster <platform> --help1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
hcp create cluster명령을 사용하여 호스팅된 클러스터를 생성하고 관리할 수 있습니다. 지원되는 플랫폼은aws,agent,kubevirt입니다.
3.4.2. 웹 콘솔을 사용하여 호스팅된 컨트롤 플레인 명령줄 인터페이스 설치 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 웹 콘솔을 사용하여 호스팅된 컨트롤 플레인 CLI(명령줄 인터페이스), hcp 를 설치할 수 있습니다.
사전 요구 사항
- OpenShift Container Platform 클러스터에 Kubernetes Operator 2.5 이상을 위한 다중 클러스터 엔진을 설치했습니다. Red Hat Advanced Cluster Management를 설치할 때 멀티 클러스터 엔진 Operator가 자동으로 설치됩니다. OpenShift Container Platform 소프트웨어 카탈로그의 Operator로 Red Hat Advanced Management 없이 다중 클러스터 엔진 Operator를 설치할 수도 있습니다.
프로세스
- OpenShift Container Platform 웹 콘솔에서 도움말 아이콘 → 명령줄 툴 을 클릭합니다.
- 플랫폼에 대한 hcp CLI 다운로드를 클릭합니다.
다음 명령을 실행하여 다운로드한 아카이브의 압축을 풉니다.
tar xvzf hcp.tar.gz
$ tar xvzf hcp.tar.gzCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 바이너리 파일을 실행 가능하게 만듭니다.
chmod +x hcp
$ chmod +x hcpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 바이너리 파일을 경로의 디렉터리로 이동합니다.
sudo mv hcp /usr/local/bin/.
$ sudo mv hcp /usr/local/bin/.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Mac 컴퓨터에서 CLI를 다운로드하는 경우 hcp 바이너리 파일에 대한 경고가 표시될 수 있습니다. 바이너리 파일을 실행할 수 있도록 보안 설정을 조정해야 합니다.
검증
다음 명령을 실행하여 사용 가능한 매개변수 목록이 표시되는지 확인합니다.
hcp create cluster <platform> --help
$ hcp create cluster <platform> --help1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
hcp create cluster명령을 사용하여 호스팅된 클러스터를 생성하고 관리할 수 있습니다. 지원되는 플랫폼은aws,agent,kubevirt입니다.
3.4.3. 콘텐츠 게이트웨이를 사용하여 호스팅된 컨트롤 플레인 명령줄 인터페이스 설치 링크 복사링크가 클립보드에 복사되었습니다!
콘텐츠 게이트웨이를 사용하여 호스팅된 컨트롤 플레인 CLI(명령줄 인터페이스), hcp 를 설치할 수 있습니다.
사전 요구 사항
- OpenShift Container Platform 클러스터에 Kubernetes Operator 2.7 이상용 다중 클러스터 엔진을 설치했습니다. Red Hat Advanced Cluster Management를 설치할 때 멀티 클러스터 엔진 Operator가 자동으로 설치됩니다. Red Hat Advanced Management 없이 OpenShift Container Platform OperatorHub의 Operator로 다중 클러스터 엔진 Operator를 설치할 수도 있습니다.
프로세스
-
콘텐츠 게이트웨이로 이동하여
hcp바이너리를 다운로드합니다. 다음 명령을 실행하여 다운로드한 아카이브의 압축을 풉니다.
tar xvzf hcp.tar.gz
$ tar xvzf hcp.tar.gzCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
hcp바이너리 파일을 실행 가능하게 만듭니다.chmod +x hcp
$ chmod +x hcpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
hcp바이너리 파일을 경로의 디렉터리로 이동합니다.sudo mv hcp /usr/local/bin/.
$ sudo mv hcp /usr/local/bin/.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Mac 컴퓨터에서 CLI를 다운로드하는 경우 hcp 바이너리 파일에 대한 경고가 표시될 수 있습니다. 바이너리 파일을 실행할 수 있도록 보안 설정을 조정해야 합니다.
검증
다음 명령을 실행하여 사용 가능한 매개변수 목록이 표시되는지 확인합니다.
hcp create cluster <platform> --help
$ hcp create cluster <platform> --help1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
hcp create cluster명령을 사용하여 호스팅된 클러스터를 생성하고 관리할 수 있습니다. 지원되는 플랫폼은aws,agent,kubevirt입니다.
3.5. 호스트된 클러스터 워크로드 배포 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform의 호스트된 컨트롤 플레인을 시작하기 전에 호스트 클러스터의 Pod를 인프라 노드에 예약할 수 있도록 노드에 레이블을 올바르게 지정해야 합니다. 다음과 같은 이유로 노드 레이블 지정도 중요합니다.
-
고가용성 및 적절한 워크로드 배포를 보장합니다. 예를 들어 OpenShift Container Platform 서브스크립션에 컨트롤 플레인 워크로드 수가 발생하지 않도록 하려면
node-role.kubernetes.io/infra레이블을 설정할 수 있습니다. - 컨트롤 플레인 워크로드가 관리 클러스터의 다른 워크로드와 분리되어 있는지 확인하려면 다음을 수행하십시오.
컨트롤 플레인 워크로드가 배포에 대한 올바른 멀티 테넌시 배포 수준에서 구성되었는지 확인하려면 다음을 수행합니다. 배포 수준은 다음과 같습니다.
- 모든 공유: 호스팅된 클러스터의 컨트롤 플레인은 컨트롤 플레인에 지정된 모든 노드에서 실행할 수 있습니다.
- 격리 요청: 자체 전용 노드에서 Serving Pod가 요청됩니다.
- 공유 없음: 모든 컨트롤 플레인에는 자체 전용 노드가 있습니다.
노드를 단일 호스트 클러스터에 배치하는 방법에 대한 자세한 내용은 "관리 클러스터 노드 정의"를 참조하십시오.
워크로드에 관리 클러스터를 사용하지 마십시오. 컨트롤 플레인이 실행되는 노드에서 워크로드가 실행되지 않아야 합니다.
3.5.1. 관리 클러스터 노드 레이블 지정 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 컨트롤 플레인을 배포하기 위한 적절한 노드 레이블링은 사전 요구 사항입니다.
관리 클러스터 관리자는 관리 클러스터 노드에서 다음 레이블 및 테인트를 사용하여 컨트롤 플레인 워크로드를 예약합니다.
-
Hypershift.openshift.io/control-plane: true: 이 레이블과 테인트를 사용하여 호스트된 컨트롤 플레인 워크로드를 실행하는 노드를 전용으로 사용합니다.true값을 설정하면 컨트롤 플레인 노드를 관리 클러스터의 인프라 구성 요소 또는 실수로 배포된 워크로드와 같은 다른 구성 요소와 공유하지 않습니다. -
Hypershift.openshift.io/cluster: ${HostedControlPlane Namespace}: 노드를 단일 호스트 클러스터에 전용으로 설정하려면 이 레이블과 테인트를 사용합니다.
control-plane Pod를 호스팅하는 노드에 다음 레이블을 적용합니다.
-
node-role.kubernetes.io/infra: 서브스크립션에 컨트롤 플레인 워크로드 수가 발생하지 않도록 이 라벨을 사용합니다. topology.kubernetes.io/zone: 관리 클러스터 노드에서 이 레이블을 사용하여 장애 도메인에서 고가용성 클러스터를 배포합니다. 영역은 위치, 랙 이름 또는 영역이 설정된 노드의 호스트 이름이 될 수 있습니다. 예를 들어 관리 클러스터에는worker-1a,worker-1b,worker-2a및worker-2b와 같은 노드가 있습니다.worker-1a및worker-1b노드는rack1에 있으며worker-2a및 worker-2b 노드는rack2에 있습니다. 각 랙을 가용성 영역으로 사용하려면 다음 명령을 입력합니다.oc label node/worker-1a node/worker-1b topology.kubernetes.io/zone=rack1
$ oc label node/worker-1a node/worker-1b topology.kubernetes.io/zone=rack1Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc label node/worker-2a node/worker-2b topology.kubernetes.io/zone=rack2
$ oc label node/worker-2a node/worker-2b topology.kubernetes.io/zone=rack2Copy to Clipboard Copied! Toggle word wrap Toggle overflow
호스팅된 클러스터의 Pod에는 허용 오차가 있으며 스케줄러는 선호도 규칙을 사용하여 스케줄링합니다. Pod는 컨트롤 플레인 및 Pod에 대한 클러스터 의 테인트를 허용합니다. 스케줄러는 hypershift.openshift.io/control-plane 및 hypershift.openshift.io/cluster: ${HostedControlPlane Namespace} 로 레이블이 지정된 노드에 Pod 예약에 우선순위를 지정합니다.
ControllerAvailabilityPolicy 옵션의 경우 호스팅된 컨트롤 플레인 명령줄 인터페이스인 hcp, deploy의 기본값인 HighlyAvailable 을 사용합니다. 이 옵션을 사용하면 topology.kubernetes.io/zone 을 토폴로지 키로 설정하여 다양한 장애 도메인에서 호스트된 클러스터 내에서 각 배포에 대한 Pod를 예약할 수 있습니다. 다른 장애 도메인에서 호스팅된 클러스터 내에서 배포에 대한 Pod 예약은 고가용성 컨트롤 플레인에만 사용할 수 있습니다.
프로세스
호스트 클러스터를 활성화하려면 다음 예와 같이 Pod를 인프라 노드에 예약해야 합니다. HostedCluster.spec.nodeSelector 를 설정합니다.
spec:
nodeSelector:
node-role.kubernetes.io/infra: ""
spec:
nodeSelector:
node-role.kubernetes.io/infra: ""
이렇게 하면 각 호스팅된 클러스터의 호스팅 컨트롤 플레인이 적합한 인프라 노드 워크로드이며 기본 OpenShift Container Platform 노드에 액세스할 필요가 없습니다.
3.5.2. 우선순위 클래스 링크 복사링크가 클립보드에 복사되었습니다!
기본 제공 우선순위 클래스 4개가 호스트된 클러스터 Pod의 우선 순위 및 선점에 영향을 미칩니다. 다음과 같은 순서로 관리 클러스터에 Pod를 생성할 수 있습니다.
-
Hypershift-operator: HyperShift Operator Pod -
Hypershift-etcd: etcd 용 Pod -
Hypershift-api-critical: API 호출 및 리소스 승인에 필요한 Pod입니다. 이러한 Pod에는kube-apiserver, 집계 API 서버 및 웹 후크와 같은 Pod가 포함됩니다. -
Hypershift-control-plane: API-critical는 아니지만 클러스터 버전 Operator와 같이 높은 우선 순위가 필요한 컨트롤 플레인의 Pod입니다.
3.5.3. 사용자 정의 테인트 및 톨러레이션 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 호스트 클러스터의 Pod는 control-plane 및 cluster taint를 허용합니다. 그러나 호스팅된 클러스터가 HostedCluster.spec.tolerations 를 설정하여 호스트당 클러스터별로 해당 테인트를 허용할 수 있도록 노드에서 사용자 지정 테인트를 사용할 수도 있습니다.
호스팅된 클러스터에 대한 허용 오차를 전달하는 것은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 다음 링크를 참조하십시오.
설정 예
spec:
tolerations:
- effect: NoSchedule
key: kubernetes.io/custom
operator: Exists
spec:
tolerations:
- effect: NoSchedule
key: kubernetes.io/custom
operator: Exists
--tolerations hcp CLI 인수를 사용하여 클러스터를 생성하는 동안 호스트된 클러스터에 허용 오차를 설정할 수도 있습니다.
CLI 인수 예
--toleration="key=kubernetes.io/custom,operator=Exists,effect=NoSchedule"
--toleration="key=kubernetes.io/custom,operator=Exists,effect=NoSchedule"
호스트별로 호스팅된 클러스터 Pod 배치를 세밀하게 제어하려면 nodeSelectors 와 함께 사용자 정의 허용 오차를 사용합니다. 호스트 클러스터 그룹을 공동 배치하고 다른 호스팅 클러스터에서 격리할 수 있습니다. 인프라 및 컨트롤 플레인 노드에 호스팅 클러스터를 배치할 수도 있습니다.
호스팅된 클러스터의 허용 오차는 컨트롤 플레인의 Pod에만 분배됩니다. 가상 머신을 실행하기 위해 pod와 같은 관리 클러스터 및 인프라 관련 Pod에서 실행되는 다른 Pod를 구성하려면 다른 프로세스를 사용해야 합니다.
3.5.4. 컨트롤 플레인 격리 링크 복사링크가 클립보드에 복사되었습니다!
호스트된 컨트롤 플레인을 구성하여 네트워크 트래픽 또는 컨트롤 플레인 Pod를 분리할 수 있습니다.
3.5.4.1. 네트워크 정책 격리 링크 복사링크가 클립보드에 복사되었습니다!
호스트된 각 컨트롤 플레인은 전용 Kubernetes 네임스페이스에서 실행되도록 할당됩니다. 기본적으로 Kubernetes 네임스페이스는 모든 네트워크 트래픽을 거부합니다.
다음 네트워크 트래픽은 Kubernetes CNI(Container Network Interface)에서 강제 적용하는 네트워크 정책을 통해 허용됩니다.
- 동일한 네임스페이스(Intra-tenant)의 수신 pod-to-pod 통신
-
테넌트의 호스트된
kube-apiserverPod에 포트 6443의 수신 -
network.openshift.io/policy-group: 모니터링 라벨을 사용하여 관리 클러스터 Kubernetes 네임스페이스의 메트릭 스크랩을 모니터링할 수 있습니다.
3.5.4.2. 컨트롤 플레인 Pod 격리 링크 복사링크가 클립보드에 복사되었습니다!
네트워크 정책 외에도 각 호스팅된 컨트롤 플레인 포드는 restricted 보안 컨텍스트 제약 조건을 사용하여 실행됩니다. 이 정책은 모든 호스트 기능에 대한 액세스를 거부하고 고객 컨트롤 플레인을 호스팅하는 각 네임스페이스에 고유하게 할당된 SELinux 컨텍스트를 사용하여 Pod를 UID로 실행해야 합니다.
이 정책은 다음 제약 조건을 확인합니다.
- Pod는 권한으로 실행할 수 없습니다.
- Pod는 호스트 디렉터리 볼륨을 마운트할 수 없습니다.
- Pod는 사전 할당된 UID 범위에서 사용자로 실행해야 합니다.
- Pod는 사전 할당된 MCS 라벨을 사용하여 실행해야 합니다.
- Pod는 호스트 네트워크 네임스페이스에 액세스할 수 없습니다.
- Pod는 호스트 네트워크 포트를 노출할 수 없습니다.
- Pod는 호스트 PID 네임스페이스에 액세스할 수 없습니다.
-
기본적으로 Pod는
KILL,MKNOD,SETUID및SETGID와 같은 Linux 기능을 삭제합니다.
각 관리 클러스터 작업자 노드에서 kubelet 및 crio 와 같은 관리 구성 요소는 호스팅된 컨트롤 플레인을 지원하는 Pod의 SELinux 컨텍스트에 액세스할 수 없는 SELinux 레이블로 보호됩니다.
다음 SELinux 레이블은 주요 프로세스 및 소켓에 사용됩니다.
-
kubelet:
system_u:system_r:unconfined_service_t:s0 -
crio:
system_u:system_r:container_runtime_t:s0 -
crio.sock:
system_u:object_r:container_var_run_t:s0 -
<example user container processes>:
system_u:system_r:container_t:s0:c14,c24
3.6. 호스팅된 컨트롤 플레인 기능 활성화 또는 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 컨트롤 플레인 기능 및 hypershift-addon 관리 클러스터 애드온은 기본적으로 활성화되어 있습니다. 기능을 비활성화하거나 비활성화한 후 수동으로 활성화하려면 다음 절차를 참조하십시오.
3.6.1. 수동으로 호스트된 컨트롤 플레인 기능 활성화 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 컨트롤 플레인을 수동으로 활성화해야 하는 경우 다음 단계를 완료합니다.
프로세스
다음 명령을 실행하여 기능을 활성화합니다.
oc patch mce multiclusterengine --type=merge -p \ '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": true}]}}}'$ oc patch mce multiclusterengine --type=merge -p \ '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": true}]}}}'1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 기본
MultiClusterEngine리소스 인스턴스 이름은multiclusterengine이지만 다음 명령을 실행하여 클러스터에서MultiClusterEngine이름을 가져올 수 있습니다.$ oc get mce.
다음 명령을 실행하여
MultiClusterEngine사용자 정의 리소스에서hypershift및hypershift-local-hosting기능이 활성화되어 있는지 확인합니다.oc get mce multiclusterengine -o yaml
$ oc get mce multiclusterengine -o yaml1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 기본
MultiClusterEngine리소스 인스턴스 이름은multiclusterengine이지만 다음 명령을 실행하여 클러스터에서MultiClusterEngine이름을 가져올 수 있습니다.$ oc get mce.
출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.6.1.1. local-cluster의 하이퍼shift-addon 관리 클러스터 애드온 수동 활성화 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 컨트롤 플레인 기능을 활성화하면 하이퍼shift-addon 관리 클러스터 애드온이 자동으로 활성화됩니다. hypershift-addon 관리 클러스터 애드온을 수동으로 활성화해야 하는 경우 hypershift-addon 을 사용하여 local-cluster 에 HyperShift Operator를 설치하려면 다음 단계를 완료합니다.
프로세스
다음 예와 유사한 파일을 생성하여
hypershift-addon이라는ManagedClusterAddon애드온을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 파일을 적용합니다.
oc apply -f <filename>
$ oc apply -f <filename>Copy to Clipboard Copied! Toggle word wrap Toggle overflow filename을 생성한 파일의 이름으로 바꿉니다.다음 명령을 실행하여
hypershift-addon관리 클러스터 애드온이 설치되었는지 확인합니다.oc get managedclusteraddons -n local-cluster hypershift-addon
$ oc get managedclusteraddons -n local-cluster hypershift-addonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 애드온이 설치된 경우 출력은 다음 예와 유사합니다.
NAME AVAILABLE DEGRADED PROGRESSING hypershift-addon True
NAME AVAILABLE DEGRADED PROGRESSING hypershift-addon TrueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
하이퍼shift-addon 관리 클러스터 애드온이 설치되어 있으며 호스팅 클러스터를 사용하여 호스팅 클러스터를 생성하고 관리할 수 있습니다.
3.6.2. 호스트된 컨트롤 플레인 기능 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
HyperShift Operator를 설치 제거하고 호스팅된 컨트롤 플레인 기능을 비활성화할 수 있습니다. 호스팅된 컨트롤 플레인 기능을 비활성화할 때 호스트 클러스터 항목 관리에 설명된 대로 다중 클러스터 엔진 Operator에서 호스팅 클러스터 및 관리 클러스터 리소스를 제거해야 합니다.
3.6.2.1. HyperShift Operator 설치 제거 링크 복사링크가 클립보드에 복사되었습니다!
HyperShift Operator를 설치 제거하고 local-cluster 에서 hypershift-addon 을 비활성화하려면 다음 단계를 완료하십시오.
프로세스
다음 명령을 실행하여 호스트 클러스터가 실행되고 있지 않은지 확인합니다.
oc get hostedcluster -A
$ oc get hostedcluster -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow 중요호스트 클러스터가 실행 중인 경우
hypershift-addon이 비활성화된 경우에도 HyperShift Operator가 제거되지 않습니다.다음 명령을 실행하여
hypershift-addon을 비활성화합니다.oc patch mce multiclusterengine --type=merge -p \ '{"spec":{"overrides":{"components":[{"name":"hypershift-local-hosting","enabled": false}]}}}'$ oc patch mce multiclusterengine --type=merge -p \1 '{"spec":{"overrides":{"components":[{"name":"hypershift-local-hosting","enabled": false}]}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 기본
MultiClusterEngine리소스 인스턴스 이름은multiclusterengine이지만 다음 명령을 실행하여 클러스터에서MultiClusterEngine이름을 가져올 수 있습니다.$ oc get mce.
참고hypershift-addon을 비활성화한 후 다중 클러스터 엔진 Operator 콘솔에서local-cluster의hypershift-addon을 비활성화할 수도 있습니다.
3.6.2.2. 호스트된 컨트롤 플레인 기능 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 컨트롤 플레인 기능을 비활성화하려면 다음 단계를 완료합니다.
사전 요구 사항
- HyperShift Operator를 설치 제거했습니다. 자세한 내용은 "HyperShift Operator 제거"를 참조하십시오.
프로세스
다음 명령을 실행하여 호스팅된 컨트롤 플레인 기능을 비활성화합니다.
oc patch mce multiclusterengine --type=merge -p \ '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": false}]}}}'$ oc patch mce multiclusterengine --type=merge -p \1 '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": false}]}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 기본
MultiClusterEngine리소스 인스턴스 이름은multiclusterengine이지만 다음 명령을 실행하여 클러스터에서MultiClusterEngine이름을 가져올 수 있습니다.$ oc get mce.
다음 명령을 실행하여
hypershift및hypershift-local-hosting기능이MultiClusterEngine사용자 정의 리소스에서 비활성화되어 있는지 확인할 수 있습니다.oc get mce multiclusterengine -o yaml
$ oc get mce multiclusterengine -o yaml1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 기본
MultiClusterEngine리소스 인스턴스 이름은multiclusterengine이지만 다음 명령을 실행하여 클러스터에서MultiClusterEngine이름을 가져올 수 있습니다.$ oc get mce.
hypershift및hypershift-local-hosting에enabled:flags가false로 설정된 다음 예제를 참조하십시오.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4장. 호스트된 컨트롤 플레인 배포 링크 복사링크가 클립보드에 복사되었습니다!
4.1. AWS에 호스팅된 컨트롤 플레인 배포 링크 복사링크가 클립보드에 복사되었습니다!
호스팅 클러스터는 관리 클러스터에서 호스팅되 는 API 끝점 및 컨트롤 플레인이 있는 OpenShift Container Platform 클러스터입니다. 호스트된 클러스터에는 컨트롤 플레인과 해당 데이터 플레인이 포함됩니다. 온프레미스에서 호스팅되는 컨트롤 플레인을 구성하려면 관리 클러스터에 Kubernetes Operator용 다중 클러스터 엔진을 설치해야 합니다. hypershift-addon 관리 클러스터 애드온을 사용하여 기존 관리 클러스터에 HyperShift Operator를 배포하면 해당 클러스터를 관리 클러스터로 활성화하고 호스팅된 클러스터를 생성할 수 있습니다. 로컬 클러스터 관리 클러스터에 대해 애드온은 기본적으로 활성화되어 있습니다.
하이퍼shift-addon 관리 클러스터
다중 클러스터 엔진 Operator 콘솔 또는 호스팅된 컨트롤 플레인 CLI(명령줄 인터페이스), hcp 를 사용하여 호스팅된 클러스터를 생성할 수 있습니다. 호스팅된 클러스터는 관리 클러스터로 자동으로 가져옵니다. 그러나 이 자동 가져오기 기능을 다중 클러스터 엔진 Operator로 비활성화 할 수 있습니다.
4.1.1. AWS에 호스팅된 컨트롤 플레인 배포 준비 링크 복사링크가 클립보드에 복사되었습니다!
AWS(Amazon Web Services)에 호스팅된 컨트롤 플레인을 배포할 준비가 되면 다음 정보를 고려하십시오.
- 각 호스트 클러스터에는 클러스터 전체 이름이 있어야 합니다. 호스트된 클러스터 이름은 다중 클러스터 엔진 Operator가 이를 관리하기 위해 기존 관리 클러스터와 같을 수 없습니다.
-
클러스터를 호스팅
클러스터이름으로 사용하지 마십시오. - 호스팅된 컨트롤 플레인의 동일한 플랫폼에서 관리 클러스터 및 작업자를 실행합니다.
- 호스트된 클러스터는 다중 클러스터 엔진 Operator 관리 클러스터의 네임스페이스에서 생성할 수 없습니다.
4.1.1.1. 관리 클러스터를 구성하기 위한 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
관리 클러스터를 구성하려면 다음 사전 요구 사항이 있어야 합니다.
- OpenShift Container Platform 클러스터에 Kubernetes Operator 2.5 이상을 위한 다중 클러스터 엔진을 설치했습니다. RHACM(Red Hat Advanced Cluster Management)을 설치할 때 multicluster engine Operator가 자동으로 설치됩니다. 멀티 클러스터 엔진 Operator는 OpenShift Container Platform 소프트웨어 카탈로그의 Operator로 RHACM 없이 설치할 수도 있습니다.
다중 클러스터 엔진 Operator에 대해 하나 이상의 관리형 OpenShift Container Platform 클러스터가 있어야 합니다.
local-cluster는 다중 클러스터 엔진 Operator 버전 2.5 이상에서 자동으로 가져옵니다. 다음 명령을 실행하여 허브 클러스터의 상태를 확인할 수 있습니다.oc get managedclusters local-cluster
$ oc get managedclusters local-clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
awsCLI(명령줄 인터페이스) 를 설치했습니다. -
호스팅된 컨트롤 플레인 CLI(
hcp)를 설치했습니다.
4.1.2. hcp CLI를 사용하여 AWS에서 호스트된 클러스터에 액세스 링크 복사링크가 클립보드에 복사되었습니다!
hcp CLI(명령줄 인터페이스)를 사용하여 kubeconfig 파일을 생성하여 호스팅된 클러스터에 액세스할 수 있습니다.
프로세스
다음 명령을 입력하여
kubeconfig파일을 생성합니다.hcp create kubeconfig --namespace <hosted_cluster_namespace> \ --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
$ hcp create kubeconfig --namespace <hosted_cluster_namespace> \ --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow kubeconfig파일을 저장한 후 다음 명령을 입력하여 호스팅된 클러스터에 액세스할 수 있습니다.oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.3. Amazon Web Services S3 버킷 및 S3 OIDC 시크릿 생성 링크 복사링크가 클립보드에 복사되었습니다!
AWS(Amazon Web Services)에서 호스팅된 클러스터를 생성하고 관리하려면 S3 버킷 및 S3 OIDC 시크릿을 생성해야 합니다.
프로세스
다음 명령을 실행하여 클러스터의 호스트 OIDC 검색 문서에 액세스할 수 있는 S3 버킷을 생성합니다.
aws s3api create-bucket --bucket <bucket_name> \ --create-bucket-configuration LocationConstraint=<region> \ --region <region>
$ aws s3api create-bucket --bucket <bucket_name> \1 --create-bucket-configuration LocationConstraint=<region> \2 --region <region>3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow aws s3api delete-public-access-block --bucket <bucket_name>
$ aws s3api delete-public-access-block --bucket <bucket_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;bucket_name>을 생성 중인 S3 버킷의 이름으로 바꿉니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;bucket_name>을 생성 중인 S3 버킷의 이름으로 바꿉니다.
aws s3api put-bucket-policy --bucket <bucket_name> \ --policy file://policy.json
$ aws s3api put-bucket-policy --bucket <bucket_name> \1 --policy file://policy.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;bucket_name>을 생성 중인 S3 버킷의 이름으로 바꿉니다.
참고Mac 컴퓨터를 사용하는 경우 정책이 작동하려면 버킷 이름을 내보내야 합니다.
-
HyperShift Operator에 대해
hypershift-operator-oidc-provider-s3-credentials라는 OIDC S3 시크릿을 생성합니다. -
로컬 클러스터네임스페이스에 시크릿을 저장합니다. 다음 표를 참조하여 보안에 다음 필드가 포함되어 있는지 확인합니다.
Expand 표 4.1. AWS 시크릿의 필수 필드 필드 이름 설명 bucket호스팅된 클러스터에 대한 호스트 OIDC 검색 문서에 대한 공용 액세스 권한이 있는 S3 버킷이 포함되어 있습니다.
credentials버킷에 액세스할 수 있는
기본프로필의 자격 증명이 포함된 파일에 대한 참조입니다. 기본적으로 HyperShift는기본프로필만 사용하여버킷을 작동합니다.regionS3 버킷의 리전을 지정합니다.
AWS 시크릿을 생성하려면 다음 명령을 실행합니다.
oc create secret generic <secret_name> \ --from-file=credentials=<path>/.aws/credentials \ --from-literal=bucket=<s3_bucket> \ --from-literal=region=<region> \ -n local-cluster
$ oc create secret generic <secret_name> \ --from-file=credentials=<path>/.aws/credentials \ --from-literal=bucket=<s3_bucket> \ --from-literal=region=<region> \ -n local-clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고보안에 대한 재해 복구 백업은 자동으로 활성화되지 않습니다. 재해 복구를 위해
hypershift-operator-oidc-provider-s3-credentials시크릿을 백업할 수 있는 레이블을 추가하려면 다음 명령을 실행합니다.oc label secret hypershift-operator-oidc-provider-s3-credentials \ -n local-cluster cluster.open-cluster-management.io/backup=true
$ oc label secret hypershift-operator-oidc-provider-s3-credentials \ -n local-cluster cluster.open-cluster-management.io/backup=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.4. 호스팅된 클러스터에 대해 라우팅 가능한 퍼블릭 영역 생성 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 클러스터의 애플리케이션에 액세스하려면 라우팅 가능한 퍼블릭 영역을 구성해야 합니다. 퍼블릭 영역이 있는 경우 이 단계를 건너뜁니다. 그렇지 않으면 퍼블릭 영역이 기존 기능에 영향을 미칩니다.
프로세스
DNS 레코드에 대해 라우팅 가능한 퍼블릭 영역을 생성하려면 다음 명령을 입력합니다.
aws route53 create-hosted-zone \ --name <basedomain> \ --caller-reference $(whoami)-$(date --rfc-3339=date)
$ aws route53 create-hosted-zone \ --name <basedomain> \1 --caller-reference $(whoami)-$(date --rfc-3339=date)Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;basedomain>을 기본 도메인으로 바꿉니다(예:www.example.com).
4.1.5. AWS IAM 역할 및 STS 인증 정보 생성 링크 복사링크가 클립보드에 복사되었습니다!
AWS(Amazon Web Services)에서 호스팅된 클러스터를 생성하기 전에 AWS IAM 역할 및 STS 인증 정보를 생성해야 합니다.
프로세스
다음 명령을 실행하여 사용자의 Amazon 리소스 이름(ARN)을 가져옵니다.
aws sts get-caller-identity --query "Arn" --output text
$ aws sts get-caller-identity --query "Arn" --output textCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
arn:aws:iam::1234567890:user/<aws_username>
arn:aws:iam::1234567890:user/<aws_username>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 단계에서 이 출력을 <
arn>의 값으로 사용합니다.역할에 대한 신뢰 관계 구성이 포함된 JSON 파일을 생성합니다. 다음 예제를 참조하십시오.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;arn>을 이전 단계에서 언급한 사용자의 ARN으로 바꿉니다.
다음 명령을 실행하여 IAM(Identity and Access Management) 역할을 생성합니다.
aws iam create-role \ --role-name <name> \ --assume-role-policy-document file://<file_name>.json \ --query "Role.Arn"
$ aws iam create-role \ --role-name <name> \1 --assume-role-policy-document file://<file_name>.json \2 --query "Role.Arn"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
arn:aws:iam::820196288204:role/myrole
arn:aws:iam::820196288204:role/myroleCopy to Clipboard Copied! Toggle word wrap Toggle overflow 역할에 대한 다음 권한 정책이 포함된
policy.json이라는 JSON 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
policy.json파일을 역할에 연결합니다.aws iam put-role-policy \ --role-name <role_name> \ --policy-name <policy_name> \ --policy-document file://policy.json
$ aws iam put-role-policy \ --role-name <role_name> \1 --policy-name <policy_name> \2 --policy-document file://policy.json3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
sts-creds.json이라는 JSON 파일에서 STS 자격 증명을 검색합니다.aws sts get-session-token --output json > sts-creds.json
$ aws sts get-session-token --output json > sts-creds.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow sts-creds.json파일의 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.6. 호스팅된 컨트롤 플레인에 AWS PrivateLink 활성화 링크 복사링크가 클립보드에 복사되었습니다!
PrivateLink를 사용하여 AWS(Amazon Web Services)에서 호스팅되는 컨트롤 플레인을 프로비저닝하려면 호스팅된 컨트롤 플레인에 대해 AWS PrivateLink를 활성화합니다.
프로세스
-
HyperShift Operator에 대한 AWS 인증 정보 시크릿을 생성하고
hypershift-operator-private-link-credentials로 이름을 지정합니다. 보안은 관리 클러스터로 사용 중인 관리 클러스터의 네임스페이스인 관리 클러스터 네임스페이스에 있어야 합니다.local-cluster를 사용한 경우local-cluster네임스페이스에 시크릿을 생성합니다. - 다음 표를 참조하여 보안에 필수 필드가 포함되어 있는지 확인합니다.
| 필드 이름 | 설명 | 선택 사항 또는 필수 |
|---|---|---|
|
| Private Link에서 사용할 수 있는 리전 | 필수 항목 |
|
| 인증 정보 액세스 키 ID입니다. | 필수 항목 |
|
| 인증 정보 액세스 키 시크릿입니다. | 필수 항목 |
AWS 시크릿을 생성하려면 다음 명령을 실행합니다.
oc create secret generic <secret_name> \ --from-literal=aws-access-key-id=<aws_access_key_id> \ --from-literal=aws-secret-access-key=<aws_secret_access_key> \ --from-literal=region=<region> -n local-cluster
$ oc create secret generic <secret_name> \
--from-literal=aws-access-key-id=<aws_access_key_id> \
--from-literal=aws-secret-access-key=<aws_secret_access_key> \
--from-literal=region=<region> -n local-cluster
보안에 대한 재해 복구 백업은 자동으로 활성화되지 않습니다. 다음 명령을 실행하여 재해 복구를 위해 hypershift-operator-private-link-credentials 시크릿을 백업할 수 있는 레이블을 추가합니다.
oc label secret hypershift-operator-private-link-credentials \ -n local-cluster \ cluster.open-cluster-management.io/backup=""
$ oc label secret hypershift-operator-private-link-credentials \
-n local-cluster \
cluster.open-cluster-management.io/backup=""
4.1.7. AWS에서 호스팅된 컨트롤 플레인의 외부 DNS 활성화 링크 복사링크가 클립보드에 복사되었습니다!
컨트롤 플레인과 데이터 플레인은 호스팅된 컨트롤 플레인에서 분리되어 있습니다. 다음 두 개의 독립적인 영역에서 DNS를 구성할 수 있습니다.
-
호스트 클러스터 내의 워크로드에 대한 수신(예:
*.apps.service-consumer-domain.com). -
서비스 공급자 도메인을 통한 API 또는 OAuth 끝점과 같은 관리 클러스터 내의 서비스 끝점에 대한 수신:
*.service-provider-domain.com.
hostedCluster.spec.dns 의 입력은 호스팅 클러스터 내의 워크로드에 대한 수신을 관리합니다. hostedCluster.spec.services.servicePublishingStrategy.route.hostname 의 입력은 관리 클러스터 내의 서비스 끝점에 대한 수신을 관리합니다.
외부 DNS는 LoadBalancer 또는 Route 의 게시 유형을 지정하고 해당 게시 유형의 호스트 이름을 제공하는 호스팅 클러스터 서비스에 대한 이름 레코드를 생성합니다. Private 또는 PublicAndPrivate 엔드포인트 액세스 유형이 있는 호스팅 클러스터의 경우 APIServer 및 OAuth 서비스만 호스트 이름을 지원합니다. 프라이빗 호스트 클러스터의 경우 DNS 레코드는 VPC의 VPC(Virtual Private Cloud) 끝점의 프라이빗 IP 주소로 확인됩니다.
호스팅된 컨트롤 플레인은 다음 서비스를 노출합니다.
-
APIServer -
OIDC
HostedCluster 사양에서 servicePublishingStrategy 필드를 사용하여 이러한 서비스를 노출할 수 있습니다. 기본적으로 LoadBalancer 및 Route 유형의 servicePublishingStrategy 에서는 다음 방법 중 하나로 서비스를 게시할 수 있습니다.
-
LoadBalancer유형의서비스상태에 있는 로드 밸런서의 호스트 이름을 사용하여 다음을 수행합니다. -
Route리소스의status.host필드를 사용합니다.
그러나 관리 서비스 컨텍스트에 호스팅된 컨트롤 플레인을 배포할 때 이러한 방법은 기본 관리 클러스터의 ingress 하위 도메인과 관리 클러스터 라이프사이클 및 재해 복구에 대한 제한 옵션을 노출할 수 있습니다.
LoadBalancer 및 Route 게시 유형에 DNS indirection이 계층화된 경우 관리형 서비스 운영자는 서비스 수준 도메인을 사용하여 모든 공용 호스팅 클러스터 서비스를 게시할 수 있습니다. 이 아키텍처를 사용하면 DNS 이름을 새 LoadBalancer 또는 경로에 다시 매핑할 수 있으며 관리 클러스터의 인그레스 도메인을 노출하지 않습니다. 호스팅된 컨트롤 플레인은 외부 DNS를 사용하여 해당 간접 계층을 달성합니다.
관리 클러스터의 hypershift 네임스페이스에 HyperShift Operator와 함께 external-dns 를 배포할 수 있습니다. 외부 DNS는 external-dns.alpha.kubernetes.io/hostname 주석이 있는 서비스 또는 경로를 감시합니다. 해당 주석은 A 레코드 또는 경로 (예: CNAME 레코드)와 같은 서비스를 가리키는 DNS 레코드를 생성하는 데 사용됩니다.
클라우드 환경에서만 외부 DNS를 사용할 수 있습니다. 다른 환경의 경우 DNS 및 서비스를 수동으로 구성해야 합니다.
외부 DNS에 대한 자세한 내용은 외부 DNS 를 참조하십시오.
4.1.7.1. 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
AWS(Amazon Web Services)에서 호스팅된 컨트롤 플레인에 대한 외부 DNS를 설정하려면 다음 사전 요구 사항을 충족해야 합니다.
- 외부 공용 도메인을 생성하셨습니다.
- AWS Route53 관리 콘솔에 액세스할 수 있습니다.
- 호스팅된 컨트롤 플레인에 대해 AWS PrivateLink를 활성화했습니다.
4.1.7.2. 호스팅된 컨트롤 플레인의 외부 DNS 설정 링크 복사링크가 클립보드에 복사되었습니다!
외부 DNS 또는 서비스 수준 DNS를 사용하여 호스팅되는 컨트롤 플레인을 프로비저닝할 수 있습니다.
-
HyperShift Operator에 대한 AWS(Amazon Web Services) 인증 정보 시크릿을 생성하고
local-cluster네임스페이스에hypershift-operator-external-dns-credentials이름을 지정합니다. 다음 표를 참조하여 보안에 필수 필드가 있는지 확인합니다.
Expand 표 4.3. AWS 시크릿의 필수 필드 필드 이름 설명 선택 사항 또는 필수 provider서비스 수준 DNS 영역을 관리하는 DNS 공급자입니다.
필수 항목
domain-filter서비스 수준 도메인입니다.
필수 항목
credentials모든 외부 DNS 유형을 지원하는 자격 증명 파일입니다.
AWS 키를 사용할 때 선택 사항
aws-access-key-id인증 정보 액세스 키 ID입니다.
AWS DNS 서비스를 사용할 때 선택 사항
aws-secret-access-key인증 정보 액세스 키 시크릿입니다.
AWS DNS 서비스를 사용할 때 선택 사항
AWS 시크릿을 생성하려면 다음 명령을 실행합니다.
oc create secret generic <secret_name> \ --from-literal=provider=aws \ --from-literal=domain-filter=<domain_name> \ --from-file=credentials=<path_to_aws_credentials_file> -n local-cluster
$ oc create secret generic <secret_name> \ --from-literal=provider=aws \ --from-literal=domain-filter=<domain_name> \ --from-file=credentials=<path_to_aws_credentials_file> -n local-clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고보안에 대한 재해 복구 백업은 자동으로 활성화되지 않습니다. 재해 복구를 위해 시크릿을 백업하려면 다음 명령을 입력하여
hypershift-operator-external-dns-credentials를 추가합니다.oc label secret hypershift-operator-external-dns-credentials \ -n local-cluster \ cluster.open-cluster-management.io/backup=""
$ oc label secret hypershift-operator-external-dns-credentials \ -n local-cluster \ cluster.open-cluster-management.io/backup=""Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.7.3. 퍼블릭 DNS 호스팅 영역 생성 링크 복사링크가 클립보드에 복사되었습니다!
외부 DNS Operator는 퍼블릭 DNS 호스팅 영역을 사용하여 퍼블릭 호스팅 클러스터를 생성합니다.
퍼블릭 DNS 호스팅 영역을 생성하여 외부 DNS 도메인 필터로 사용할 수 있습니다. AWS Route 53 관리 콘솔에서 다음 단계를 완료합니다.
프로세스
- Route 53 관리 콘솔에서 호스팅 영역 생성을 클릭합니다.
- 호스팅 영역 구성 페이지에서 도메인 이름을 입력하고 공용 호스팅 영역이 유형으로 선택되어 있는지 확인하고 호스트 영역 생성 을 클릭합니다.
- 영역이 생성되면 레코드 탭에서 Value/Route 트래픽의 값을 열로 기록해 둡니다.
- 기본 도메인에서 NS 레코드를 생성하여 DNS 요청을 위임된 영역으로 리디렉션합니다. 값 필드에 이전 단계에서 기록한 값을 입력합니다.
- 레코드 생성을 클릭합니다.
새 하위 영역에 테스트 항목을 생성하고 다음 예와 같이
dig명령을 사용하여 테스트하여 DNS 호스팅 영역이 작동하는지 확인합니다.dig +short test.user-dest-public.aws.kerberos.com
$ dig +short test.user-dest-public.aws.kerberos.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
192.168.1.1
192.168.1.1Copy to Clipboard Copied! Toggle word wrap Toggle overflow LoadBalancer및Route서비스의 호스트 이름을 설정하는 호스팅 클러스터를 생성하려면 다음 명령을 입력합니다.hcp create cluster aws --name=<hosted_cluster_name> \ --endpoint-access=PublicAndPrivate \ --external-dns-domain=<public_hosted_zone> ...
$ hcp create cluster aws --name=<hosted_cluster_name> \ --endpoint-access=PublicAndPrivate \ --external-dns-domain=<public_hosted_zone> ...1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;public_hosted_zone>을 생성한 공개 호스팅 영역으로 바꿉니다.
호스트된 클러스터에 대한
services블록의 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Control Plane Operator는 Services 및 Routes 리소스를 생성하고 external-dns.alpha.kubernetes.io/hostname 주석으로 주석을 추가합니다. 서비스 및 경로 의 경우 컨트롤 플레인 Operator는 서비스 끝점의 servicePublishingStrategy 필드에 있는 hostname 매개변수 값을 사용합니다. DNS 레코드를 만들려면 external-dns 배포와 같은 메커니즘을 사용할 수 있습니다.
공용 서비스에 대해서만 서비스 수준 DNS를 간접으로 구성할 수 있습니다. hypershift.local 프라이빗 영역을 사용하므로 프라이빗 서비스의 호스트 이름을 설정할 수 없습니다.
다음 표에서는 서비스 및 엔드포인트 조합에 대한 호스트 이름을 설정하는 것이 유효한 시기를 보여줍니다.
| 서비스 | 퍼블릭 | PublicAndPrivate | 프라이빗 |
|---|---|---|---|
|
| Y | Y | N |
|
| Y | Y | N |
|
| Y | N | N |
|
| Y | N | N |
4.1.7.4. AWS에서 외부 DNS를 사용하여 호스트 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
AWS(Amazon Web Services)에서 PublicAndPrivate 또는 Public publishing 전략을 사용하여 호스팅 클러스터를 생성하려면 관리 클러스터에 다음과 같은 아티팩트가 구성되어 있어야 합니다.
- 퍼블릭 DNS 호스팅 영역
- 외부 DNS Operator
- HyperShift Operator
hcp CLI(명령줄 인터페이스)를 사용하여 호스팅된 클러스터를 배포할 수 있습니다.
프로세스
관리 클러스터에 액세스하려면 다음 명령을 입력합니다.
export KUBECONFIG=<path_to_management_cluster_kubeconfig>
$ export KUBECONFIG=<path_to_management_cluster_kubeconfig>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 External DNS Operator가 실행 중인지 확인합니다.
oc get pod -n hypershift -lapp=external-dns
$ oc get pod -n hypershift -lapp=external-dnsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME READY STATUS RESTARTS AGE external-dns-7c89788c69-rn8gp 1/1 Running 0 40s
NAME READY STATUS RESTARTS AGE external-dns-7c89788c69-rn8gp 1/1 Running 0 40sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 외부 DNS를 사용하여 호스팅된 클러스터를 생성하려면 다음 명령을 입력합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Amazon 리소스 이름(ARN)을 지정합니다(예:
arn:aws:iam::820196288204:role/myrole). - 2
- 인스턴스 유형을 지정합니다(예:
m6i.xlarge). - 3
- AWS 리전을 지정합니다(예:
us-east-1). - 4
- 호스팅된 클러스터 이름을 지정합니다(예:
my-external-aws). - 5
- 서비스 소비자가 소유한 공개 호스팅 영역을 지정합니다(예:
service-consumer-domain.com). - 6
- 노드 복제본 수를 지정합니다(예: 2).
- 7
- 풀 시크릿 파일의 경로를 지정합니다.
- 8
- 사용하려는 지원되는 OpenShift Container Platform 버전을 지정합니다(예:
4.20.0-multi). - 9
- 서비스 공급자가 소유한 공개 호스팅 영역을 지정합니다(예:
service-provider-domain.com). - 10
- 을
PublicAndPrivate로 설정합니다. 공용 또는구성으로만 외부 DNS를 사용할 수 있습니다.PublicAndPrivate - 11
- AWS STS 자격 증명 파일의 경로를 지정합니다(예:
/home/user/sts-creds/sts-creds.json).
4.1.7.5. 사용자 정의 DNS 이름 정의 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 노드 부트스트랩 및 컨트롤 플레인 통신에 사용되는 내부 끝점과 다른 외부 API DNS 이름을 사용하여 호스팅 클러스터를 생성할 수 있습니다. 다음과 같은 이유로 다른 DNS 이름을 정의할 수 있습니다.
- 내부 루트 CA에 바인딩되는 컨트롤 플레인 기능을 중단하지 않고 사용자용 TLS 인증서를 공용 CA의 인증서로 교체하려면 다음을 수행합니다.
- 분할 수평 DNS 및 NAT 시나리오를 지원합니다.
-
올바른
kubeconfig및 DNS 구성으로Show Login Command기능과 같은 기능을 사용할 수 있는 독립 실행형 컨트롤 플레인과 유사한 환경을 보장하기 위해 다음을 수행합니다.
HostedCluster 오브젝트의 kubeAPIServerDNSName 매개변수에 도메인 이름을 입력하여 초기 설정 중 또는 설치 후 작업 중에 DNS 이름을 정의할 수 있습니다.
사전 요구 사항
-
kubeAPIServerDNSName매개변수에 설정한 DNS 이름을 다루는 유효한 TLS 인증서가 있습니다. - 올바른 주소에 도달하고 가리킬 수 있는 확인 가능한 DNS 이름 URI가 있습니다.
프로세스
HostedCluster오브젝트의 사양에서kubeAPIServerDNSName매개변수와 도메인의 주소를 추가하고 다음 예와 같이 사용할 인증서를 지정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
kubeAPIServerDNSName매개변수의 값은 유효한 도메인이어야 합니다.
kubeAPIServerDNSName 매개변수를 정의하고 인증서를 지정하면 Control Plane Operator 컨트롤러에서 custom-admin- 라는 kubeconfig 파일을 생성합니다. 여기서 파일이 kubeconfig HostedControlPlane 네임스페이스에 저장됩니다. 인증서 생성은 루트 CA에서 발생하며 HostedControlPlane 네임스페이스는 만료 및 갱신을 관리합니다.
Control Plane Operator는 HostedControlPlane 네임스페이스에서 CustomKubeconfig 라는 새 kubeconfig 파일을 보고합니다. 해당 파일은 kubeAPIServerDNSName 매개변수에서 정의된 새 서버를 사용합니다.
사용자 정의 kubeconfig 파일에 대한 참조는 HostedCluster 오브젝트의 CustomKubeconfig 로 status 매개변수에 있습니다. CustomKubeConfig 매개변수는 선택 사항이며 kubeAPIServerDNSName 매개변수가 비어 있지 않은 경우에만 매개변수를 추가할 수 있습니다. CustomKubeConfig 매개변수를 설정한 후 매개변수는 HostedCluster 네임스페이스에서 < hosted_cluster_name>-custom-admin-kubeconfig 라는 보안 생성을 트리거합니다. 시크릿을 사용하여 HostedCluster API 서버에 액세스할 수 있습니다. 설치 후 작업 중에 CustomKubeConfig 매개변수를 제거하면 모든 관련 보안 및 상태 참조가 삭제됩니다.
사용자 정의 DNS 이름을 정의해도 데이터 플레인에 직접적인 영향을 미치지 않으므로 예상되는 롤아웃이 발생하지 않습니다. HostedControlPlane 네임스페이스는 HyperShift Operator에서 변경 사항을 수신하고 해당 매개변수를 삭제합니다.
HostedCluster 오브젝트의 사양에서 kubeAPIServerDNSName 매개변수를 제거하면 새로 생성된 모든 보안 및 CustomKubeconfig 참조가 클러스터 및 status 매개변수에서 제거됩니다.
4.1.8. AWS에서 호스트 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
hcp CLI(명령줄 인터페이스)를 사용하여 AWS(Amazon Web Services)에서 호스팅된 클러스터를 생성할 수 있습니다.
AWS(Amazon Web Services)에서 호스팅되는 컨트롤 플레인의 경우 기본적으로 AMD64 호스팅 클러스터를 사용합니다. 그러나 호스팅된 컨트롤 플레인이 ARM64 호스팅 클러스터에서 실행되도록 할 수 있습니다. 자세한 내용은 " ARM64 아키텍처에서 호스팅된 클러스터 실행"을 참조하십시오.
노드 풀 및 호스팅 클러스터의 호환 가능한 조합은 다음 표를 참조하십시오.
| 호스트된 클러스터 | 노드 풀 |
|---|---|
| AMD64 | AMD64 또는 ARM64 |
| ARM64 | ARM64 또는 AMD64 |
사전 요구 사항
-
호스트된 컨트롤 플레인 CLI,
hcp를 설정했습니다. -
로컬 클러스터 관리 클러스터를관리 클러스터로 활성화했습니다. - AWS IAM(Identity and Access Management) 역할 및 AWS STS(Security Token Service) 인증 정보를 생성하셨습니다.
프로세스
AWS에서 호스팅된 클러스터를 생성하려면 다음 명령을 실행합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 호스팅된 클러스터의 이름을 지정합니다(
예: ). - 2
- 인프라 이름을 지정합니다. <
hosted_cluster_name> 및 <. 그러지 않으면 Kubernetes Operator 콘솔의 다중 클러스터 엔진에 클러스터가 제대로 표시되지 않을 수 있습니다.infra_id>에 동일한 값을 제공해야 합니다 - 3
- 기본 도메인을 지정합니다(예:
example.com). - 4
- AWS STS 자격 증명 파일의 경로를 지정합니다(예:
/home/user/sts-creds/sts-creds.json). - 5
- 풀 시크릿의 경로를 지정합니다(예:
/user/name/pullsecret). - 6
- AWS 리전 이름을 지정합니다(예:
us-east-1). - 7
- 노드 풀 복제본 수를 지정합니다(예:
3). - 8
- 기본적으로 모든
HostedCluster및NodePool사용자 정의 리소스는클러스터네임스페이스에 생성됩니다.--namespace <namespace> 매개변수를 사용하여 특정 네임스페이스에서HostedCluster및NodePool사용자 정의 리소스를 생성할 수 있습니다. - 9
- Amazon 리소스 이름(ARN)을 지정합니다(예:
arn:aws:iam::820196288204:role/myrole). - 10
- EC2 인스턴스가 공유 또는 단일 테넌트 하드웨어에서 실행되는지 여부를 표시하려면 이 필드를 포함합니다.
--render-into플래그는 Kubernetes 리소스를 이 필드에 지정하는 YAML 파일에 렌더링합니다. 그런 다음 다음 단계로 이동하여 YAML 파일을 편집합니다.
이전 명령에
--render-into플래그를 포함하는 경우 지정된 YAML 파일을 편집합니다. YAML 파일에서NodePool사양을 편집하여 다음 예와 유사하게 EC2 인스턴스를 공유 또는 단일 테넌트 하드웨어에서 실행해야 하는지 여부를 나타냅니다.YAML 파일의 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
호스팅 클러스터의 상태를 확인하여
AVAILABLE의 값이True인지 확인합니다. 다음 명령을 실행합니다.oc get hostedclusters -n <hosted_cluster_namespace>
$ oc get hostedclusters -n <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 노드 풀 목록을 가져옵니다.
oc get nodepools --namespace <hosted_cluster_namespace>
$ oc get nodepools --namespace <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.8.1. AWS에서 호스트된 클러스터에 액세스 링크 복사링크가 클립보드에 복사되었습니다!
리소스에서 kubeconfig 파일 및 kubeadmin 자격 증명을 직접 가져와서 호스팅된 클러스터에 액세스할 수 있습니다.
호스팅된 클러스터의 액세스 보안에 대해 잘 알고 있어야 합니다. 호스팅 클러스터 네임스페이스에는 호스팅된 클러스터 리소스가 포함되어 있으며 호스팅된 컨트롤 플레인 네임스페이스는 호스팅된 컨트롤 플레인이 실행되는 위치입니다. 보안 이름 형식은 다음과 같습니다.
-
kubeconfigsecret: <hosted-cluster-namespace>-<name>-admin-kubeconfig. 예를 들어 cluster-hypershift-demo-admin-kubeconfig. -
kubeadmin암호 시크릿: <hosted-cluster-namespace>-<name>-kubeadmin-password. 예를 들어 cluster-hypershift-demo-kubeadmin-password.
프로세스
kubeconfig시크릿에는 Base64로 인코딩된kubeconfig필드가 포함되어 있으며 다음 명령과 함께 사용할 파일에 디코딩하고 저장할 수 있습니다.oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow kubeadmin암호 시크릿도 Base64로 인코딩됩니다. 이를 디코딩하고 암호를 사용하여 호스팅된 클러스터의 API 서버 또는 콘솔에 로그인할 수 있습니다.
4.1.8.2. kubeadmin 인증 정보를 사용하여 AWS에서 호스트된 클러스터에 액세스 링크 복사링크가 클립보드에 복사되었습니다!
AWS(Amazon Web Services)에서 호스팅된 클러스터를 생성한 후 kubeconfig 파일을 가져오고 시크릿 및 kubeadmin 인증 정보를 가져와 호스팅된 클러스터에 액세스할 수 있습니다.
호스팅 클러스터 네임스페이스에는 호스팅된 클러스터 리소스와 액세스 보안이 포함됩니다. 호스팅된 컨트롤 플레인은 호스팅된 컨트롤 플레인 네임스페이스에서 실행됩니다.
보안 이름 형식은 다음과 같습니다.
-
kubeconfig시크릿: <hosted_cluster_namespace>-<name>-admin-kubeconfig. 예를 들어 cluster-hypershift-demo-admin-kubeconfig. -
kubeadmin암호 시크릿: <hosted_cluster_namespace>-<name>-kubeadmin-password. 예를 들어 cluster-hypershift-demo-kubeadmin-password.
kubeadmin 암호 시크릿은 Base64로 인코딩되며 kubeconfig 시크릿에는 Base64로 인코딩된 kubeconfig 구성이 포함되어 있습니다. Base64로 인코딩된 kubeconfig 구성을 디코딩하여 < hosted_cluster_name>.kubeconfig 파일에 저장해야 합니다.
프로세스
호스트된
클러스터에 액세스하려면 디코딩된 kubeconfig 구성이 포함된 <hosted_cluster_name>.kubeconfig파일을 사용합니다. 다음 명령을 실행합니다.oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow API 서버 또는 호스팅된 클러스터의 콘솔에 로그인하려면
kubeadmin암호 시크릿을 디코딩해야 합니다.
4.1.8.3. hcp CLI를 사용하여 AWS에서 호스트된 클러스터에 액세스 링크 복사링크가 클립보드에 복사되었습니다!
hcp CLI(명령줄 인터페이스)를 사용하여 호스팅된 클러스터에 액세스할 수 있습니다.
프로세스
다음 명령을 입력하여
kubeconfig파일을 생성합니다.hcp create kubeconfig --namespace <hosted_cluster_namespace> \ --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
$ hcp create kubeconfig --namespace <hosted_cluster_namespace> \ --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow kubeconfig파일을 저장한 후 다음 명령을 입력하여 호스팅된 클러스터에 액세스합니다.oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.9. 호스트된 클러스터에서 사용자 정의 API 서버 인증서 구성 링크 복사링크가 클립보드에 복사되었습니다!
API 서버의 사용자 정의 인증서를 구성하려면 HostedCluster 구성의 spec.configuration.apiServer 섹션에 인증서 세부 정보를 지정합니다.
day-1 또는 day-2 작업 중에 사용자 정의 인증서를 구성할 수 있습니다. 그러나 호스트 클러스터 생성 중에 서비스 게시 전략은 변경할 수 없으므로 구성하려는 Kubernetes API 서버의 호스트 이름이 무엇인지 알아야 합니다.
사전 요구 사항
관리 클러스터에 사용자 정의 인증서가 포함된 Kubernetes 시크릿을 생성했습니다. 보안에는 다음 키가 포함되어 있습니다.
-
TLS.crt: 인증서 -
TLS.key: 개인 키
-
-
HostedCluster구성에 로드 밸런서를 사용하는 서비스 게시 전략이 포함된 경우 인증서의 SAN(주체 대체 이름)이 내부 API 끝점(api-int)과 충돌하지 않는지 확인합니다. 내부 API 끝점은 플랫폼에서 자동으로 생성 및 관리합니다. 사용자 정의 인증서와 내부 API 끝점 모두에서 동일한 호스트 이름을 사용하는 경우 라우팅 충돌이 발생할 수 있습니다. 이 규칙의 유일한 예외는Private또는PublicAndPrivate구성이 있는 공급자로 AWS를 사용하는 경우입니다. 이러한 경우 SAN 충돌은 플랫폼에 의해 관리됩니다. - 인증서는 외부 API 끝점에 유효해야 합니다.
- 인증서의 유효 기간은 클러스터의 예상 라이프 사이클과 일치합니다.
프로세스
다음 명령을 입력하여 사용자 정의 인증서로 보안을 생성합니다.
oc create secret tls sample-hosted-kas-custom-cert \ --cert=path/to/cert.crt \ --key=path/to/key.key \ -n <hosted_cluster_namespace>
$ oc create secret tls sample-hosted-kas-custom-cert \ --cert=path/to/cert.crt \ --key=path/to/key.key \ -n <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예와 같이 사용자 정의 인증서 세부 정보를 사용하여
HostedCluster구성을 업데이트합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여
HostedCluster구성에 변경 사항을 적용합니다.oc apply -f <hosted_cluster_config>.yaml
$ oc apply -f <hosted_cluster_config>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
- API 서버 pod를 확인하여 새 인증서가 마운트되었는지 확인합니다.
- 사용자 정의 도메인 이름을 사용하여 API 서버에 대한 연결을 테스트합니다.
-
브라우저에서 인증서 세부 정보를 확인하거나
openssl과 같은 도구를 사용하여 확인합니다.
4.1.10. AWS의 여러 영역에서 호스팅 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
hcp CLI(명령줄 인터페이스)를 사용하여 AWS(Amazon Web Services)의 여러 영역에서 호스팅 클러스터를 생성할 수 있습니다.
사전 요구 사항
- AWS IAM(Identity and Access Management) 역할 및 AWS STS(Security Token Service) 인증 정보를 생성하셨습니다.
프로세스
다음 명령을 실행하여 AWS의 여러 영역에 호스팅 클러스터를 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 호스팅된 클러스터의 이름을 지정합니다(
예: ). - 2
- 노드 풀 복제본 수를 지정합니다(예:
2). - 3
- 기본 도메인을 지정합니다(예:
example.com). - 4
- 풀 시크릿의 경로를 지정합니다(예:
/user/name/pullsecret). - 5
- Amazon 리소스 이름(ARN)을 지정합니다(예:
arn:aws:iam::820196288204:role/myrole). - 6
- AWS 리전 이름을 지정합니다(예:
us-east-1). - 7
- AWS 리전 내의 가용성 영역을 지정합니다(예:
us-east-1a,us-east-1b). - 8
- AWS STS 자격 증명 파일의 경로를 지정합니다(예:
/home/user/sts-creds/sts-creds.json).
지정된 각 영역에 대해 다음 인프라가 생성됩니다.
- 퍼블릭 서브넷
- 프라이빗 서브넷
- NAT 게이트웨이
- 프라이빗 경로 테이블
공용 경로 테이블은 퍼블릭 서브넷에서 공유됩니다.
각 영역에 대해 하나의 NodePool 리소스가 생성됩니다. 노드 풀 이름은 영역 이름으로 접미사가 지정됩니다. 영역의 프라이빗 서브넷은 spec.platform.aws.subnet.id 에 설정됩니다.
4.1.10.1. AWS STS 인증 정보를 제공하여 호스트 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
hcp create cluster aws 명령을 사용하여 호스팅된 클러스터를 생성하는 경우 호스팅된 클러스터에 대한 인프라 리소스를 생성할 수 있는 권한이 있는 AWS(Amazon Web Services) 계정 인증 정보를 제공해야 합니다.
인프라 리소스에는 다음 예가 포함됩니다.
- Virtual Private Cloud (VPC)
- 서브넷
- NAT(네트워크 주소 변환) 게이트웨이
다음 방법 중 하나를 사용하여 AWS 인증 정보를 제공할 수 있습니다.
- AWS STS(Security Token Service) 인증 정보
- 다중 클러스터 엔진 Operator의 AWS 클라우드 공급자 시크릿
프로세스
AWS STS 인증 정보를 제공하여 AWS에서 호스팅된 클러스터를 생성하려면 다음 명령을 입력합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 호스팅된 클러스터의 이름을 지정합니다(
예: ). - 2
- 노드 풀 복제본 수를 지정합니다(예:
2). - 3
- 기본 도메인을 지정합니다(예:
example.com). - 4
- 풀 시크릿의 경로를 지정합니다(예:
/user/name/pullsecret). - 5
- AWS STS 자격 증명 파일의 경로를 지정합니다(예:
/home/user/sts-creds/sts-creds.json). - 6
- AWS 리전 이름을 지정합니다(예:
us-east-1). - 7
- Amazon 리소스 이름(ARN)을 지정합니다(예:
arn:aws:iam::820196288204:role/myrole).
4.1.11. ARM64 아키텍처에서 호스트 클러스터 실행 링크 복사링크가 클립보드에 복사되었습니다!
AWS(Amazon Web Services)에서 호스팅되는 컨트롤 플레인의 경우 기본적으로 AMD64 호스팅 클러스터를 사용합니다. 그러나 호스팅된 컨트롤 플레인이 ARM64 호스팅 클러스터에서 실행되도록 할 수 있습니다.
노드 풀 및 호스팅 클러스터의 호환 가능한 조합은 다음 표를 참조하십시오.
| 호스트된 클러스터 | 노드 풀 |
|---|---|
| AMD64 | AMD64 또는 ARM64 |
| ARM64 | ARM64 또는 AMD64 |
4.1.11.1. ARM64 OpenShift Container Platform 클러스터에서 호스트 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
기본 릴리스 이미지를 다중 아키텍처 릴리스 이미지로 재정의하여 ARM64 OpenShift Container Platform 클러스터에서 AWS(Amazon Web Services)의 호스트 클러스터를 실행할 수 있습니다.
다중 아키텍처 릴리스 이미지를 사용하지 않는 경우 노드 풀의 컴퓨팅 노드가 생성되지 않고 호스트 클러스터에서 다중 아키텍처 릴리스 이미지를 사용하거나 릴리스 이미지를 기반으로 NodePool 사용자 정의 리소스를 업데이트할 때까지 노드 풀의 조정이 중지됩니다.
사전 요구 사항
- AWS에 설치된 64비트 ARM 인프라가 있는 OpenShift Container Platform 클러스터가 있어야 합니다. 자세한 내용은 Creating an OpenShift Container Platform Cluster: AWS (ARM) 를 참조하십시오.
- AWS IAM(Identity and Access Management) 역할 및 AWS STS(Security Token Service) 인증 정보를 생성해야 합니다. 자세한 내용은 "AWS IAM 역할 및 STS 인증 정보 생성"을 참조하십시오.
프로세스
다음 명령을 입력하여 ARM64 OpenShift Container Platform 클러스터에 호스팅된 클러스터를 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 호스팅된 클러스터의 이름을 지정합니다(
예: ). - 2
- 노드 풀 복제본 수를 지정합니다(예:
3). - 3
- 기본 도메인을 지정합니다(예:
example.com). - 4
- 풀 시크릿의 경로를 지정합니다(예:
/user/name/pullsecret). - 5
- AWS STS 자격 증명 파일의 경로를 지정합니다(예:
/home/user/sts-creds/sts-creds.json). - 6
- AWS 리전 이름을 지정합니다(예:
us-east-1). - 7
- 사용하려는 지원되는 OpenShift Container Platform 버전을 지정합니다(예:
4.20.0-multi). 연결이 끊긴 환경을 사용하는 경우 <ocp_release_image>를 다이제스트 이미지로 교체합니다. OpenShift Container Platform 릴리스 이미지 다이제스트를 추출하려면 "OpenShift Container Platform 릴리스 이미지 다이제스트 추출"을 참조하십시오. - 8
- Amazon 리소스 이름(ARN)을 지정합니다(예:
arn:aws:iam::820196288204:role/myrole).
4.1.11.2. AWS 호스팅 클러스터에서 ARM 또는 AMD NodePool 오브젝트 생성 링크 복사링크가 클립보드에 복사되었습니다!
동일한 호스팅 컨트롤 플레인의 64비트 ARM 및 AMD에서 NodePool 오브젝트인 애플리케이션 워크로드를 예약할 수 있습니다. NodePool 사양에 arch 필드를 정의하여 NodePool 오브젝트에 필요한 프로세서 아키텍처를 설정할 수 있습니다. arch 필드에 유효한 값은 다음과 같습니다.
-
arm64 -
amd64
사전 요구 사항
-
HostedCluster사용자 정의 리소스를 사용하려면 다중 아키텍처 이미지가 있어야 합니다. 여러 아키텍처의 Nightly 이미지에 액세스할 수 있습니다.
프로세스
다음 명령을 실행하여 ARM 또는 AMD
NodePool오브젝트를 AWS의 호스팅 클러스터에 추가합니다.hcp create nodepool aws \ --cluster-name <hosted_cluster_name> \ --name <node_pool_name> \ --node-count <node_pool_replica_count> \ --arch <architecture>
$ hcp create nodepool aws \ --cluster-name <hosted_cluster_name> \1 --name <node_pool_name> \2 --node-count <node_pool_replica_count> \3 --arch <architecture>4 Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.12. AWS에서 개인 호스트 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
local-cluster 를 호스팅 클러스터로 활성화한 후 AWS(Amazon Web Services)에 호스팅 클러스터 또는 개인 호스팅 클러스터를 배포할 수 있습니다.
기본적으로 호스팅된 클러스터는 퍼블릭 DNS와 관리 클러스터의 기본 라우터를 통해 공개적으로 액세스할 수 있습니다.
AWS의 프라이빗 클러스터의 경우 호스팅 클러스터와의 모든 통신은 AWS PrivateLink를 통해 수행됩니다.
사전 요구 사항
- AWS PrivateLink를 활성화했습니다. 자세한 내용은 "AWS PrivateLink 활성화"를 참조하십시오.
- AWS IAM(Identity and Access Management) 역할 및 AWS STS(Security Token Service) 인증 정보를 생성하셨습니다. 자세한 내용은 "AWS IAM 역할 및 STS 인증 정보 생성" 및 "IAM(Identity and Access Management) 권한"을 참조하십시오.
- AWS에 bastion 인스턴스를 구성했습니다.
프로세스
다음 명령을 입력하여 AWS에 개인 호스팅 클러스터를 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 호스팅된 클러스터의 이름을 지정합니다(
예: ). - 2
- 노드 풀 복제본 수를 지정합니다(예:
3). - 3
- 기본 도메인을 지정합니다(예:
example.com). - 4
- 풀 시크릿의 경로를 지정합니다(예:
/user/name/pullsecret). - 5
- AWS STS 자격 증명 파일의 경로를 지정합니다(예:
/home/user/sts-creds/sts-creds.json). - 6
- AWS 리전 이름을 지정합니다(예:
us-east-1). - 7
- 클러스터가 공용인지 프라이빗인지 여부를 정의합니다.
- 8
- Amazon 리소스 이름(ARN)을 지정합니다(예:
arn:aws:iam::820196288204:role/myrole). ARN 역할에 대한 자세한 내용은 "IAM(Identity and Access Management) 권한"을 참조하십시오.
호스팅 클러스터의 다음 API 끝점은 프라이빗 DNS 영역을 통해 액세스할 수 있습니다.
-
api.<hosted_cluster_name>.hypershift.local -
*.apps.<hosted_cluster_name>.hypershift.local
4.1.12.1. AWS에서 프라이빗 관리 클러스터에 액세스 링크 복사링크가 클립보드에 복사되었습니다!
CLI(명령줄 인터페이스)를 사용하여 프라이빗 관리 클러스터에 액세스할 수 있습니다.
프로세스
다음 명령을 입력하여 노드의 개인 IP를 찾습니다.
aws ec2 describe-instances \ --filter="Name=tag:kubernetes.io/cluster/<infra_id>,Values=owned" \ | jq '.Reservations[] | .Instances[] | select(.PublicDnsName=="") \ | .PrivateIpAddress'
$ aws ec2 describe-instances \ --filter="Name=tag:kubernetes.io/cluster/<infra_id>,Values=owned" \ | jq '.Reservations[] | .Instances[] | select(.PublicDnsName=="") \ | .PrivateIpAddress'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 노드에 복사할 수 있는 호스팅된 클러스터에 대한
kubeconfig파일을 생성합니다.hcp create kubeconfig > <hosted_cluster_kubeconfig>
$ hcp create kubeconfig > <hosted_cluster_kubeconfig>Copy to Clipboard Copied! Toggle word wrap Toggle overflow bastion을 통해 노드 중 하나에 SSH로 연결하려면 다음 명령을 입력합니다.
ssh -o ProxyCommand="ssh ec2-user@<bastion_ip> \ -W %h:%p" core@<node_ip>
$ ssh -o ProxyCommand="ssh ec2-user@<bastion_ip> \ -W %h:%p" core@<node_ip>Copy to Clipboard Copied! Toggle word wrap Toggle overflow SSH 쉘에서 다음 명령을 입력하여
kubeconfig파일 콘텐츠를 노드의 파일에 복사합니다.mv <path_to_kubeconfig_file> <new_file_name>
$ mv <path_to_kubeconfig_file> <new_file_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여
kubeconfig파일을 내보냅니다.export KUBECONFIG=<path_to_kubeconfig_file>
$ export KUBECONFIG=<path_to_kubeconfig_file>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 호스팅된 클러스터 상태를 확인합니다.
oc get clusteroperators clusterversion
$ oc get clusteroperators clusterversionCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.2. 베어 메탈에 호스팅된 컨트롤 플레인 배포 링크 복사링크가 클립보드에 복사되었습니다!
관리 클러스터로 작동하도록 클러스터를 구성하여 호스팅되는 컨트롤 플레인을 배포할 수 있습니다. 관리 클러스터는 컨트롤 플레인이 호스팅되는 OpenShift Container Platform 클러스터입니다. 경우에 따라 관리 클러스터를 호스팅 클러스터라고도 합니다.
관리 클러스터는 관리 클러스터와 동일하지 않습니다. 관리형 클러스터는 hub 클러스터가 관리하는 클러스터입니다.
호스트된 컨트롤 플레인 기능은 기본적으로 활성화되어 있습니다.
다중 클러스터 엔진 Operator는 관리하는 허브 클러스터인 기본 로컬 클러스터 및 hub 클러스터만 관리 클러스터로 지원합니다. Red Hat Advanced Cluster Management를 설치한 경우 local-cluster 라고도 하는 관리 허브 클러스터를 관리 클러스터로 사용할 수 있습니다.
호스팅 클러스터는 관리 클러스터에서 호스팅되 는 API 끝점 및 컨트롤 플레인이 있는 OpenShift Container Platform 클러스터입니다. 호스트된 클러스터에는 컨트롤 플레인과 해당 데이터 플레인이 포함됩니다. 다중 클러스터 엔진 Operator 콘솔 또는 호스트된 컨트롤 플레인 명령줄 인터페이스(hcp)를 사용하여 호스트된 클러스터를 생성할 수 있습니다.
호스팅된 클러스터는 관리 클러스터로 자동으로 가져옵니다. 이 자동 가져오기 기능을 비활성화하려면 "호스트된 클러스터의 자동 가져오기 비활성화"를 참조하십시오.
4.2.1. 베어 메탈에 호스팅된 컨트롤 플레인 배포 준비 링크 복사링크가 클립보드에 복사되었습니다!
베어 메탈에 호스팅된 컨트롤 플레인을 배포할 준비가 되면 다음 정보를 고려하십시오.
- 호스팅된 컨트롤 플레인의 동일한 플랫폼에서 관리 클러스터 및 작업자를 실행합니다.
-
모든 베어 메탈 호스트에는 중앙 인프라 관리에서 제공하는 검색 이미지 ISO를 수동으로 시작해야 합니다. 수동으로 또는
Cluster-Baremetal-Operator를 사용하여 호스트를 시작할 수 있습니다. 각 호스트가 시작되면 에이전트 프로세스를 실행하여 호스트 세부 정보를 검색하고 설치를 완료합니다.에이전트사용자 정의 리소스는 각 호스트를 나타냅니다. - 호스트된 컨트롤 플레인에 대한 스토리지를 구성할 때 권장 etcd 사례를 고려하십시오. 대기 시간 요구 사항을 충족하는지 확인하려면 각 컨트롤 플레인 노드에서 실행되는 모든 호스팅 컨트롤 플레인 etcd 인스턴스에 빠른 스토리지 장치를 전용으로 지정합니다. LVM 스토리지를 사용하여 호스팅된 etcd pod의 로컬 스토리지 클래스를 구성할 수 있습니다. 자세한 내용은 "Recommended etcd practices" 및 "Persistent storage using logical volume manager storage"를 참조하십시오.
4.2.1.1. 관리 클러스터를 구성하기 위한 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
- Kubernetes Operator 2.2 이상용 멀티 클러스터 엔진이 OpenShift Container Platform 클러스터에 설치되어 있어야 합니다. OpenShift Container Platform 소프트웨어 카탈로그에서 다중 클러스터 엔진 Operator를 Operator로 설치할 수 있습니다.
다중 클러스터 엔진 Operator에는 하나 이상의 관리형 OpenShift Container Platform 클러스터가 있어야 합니다.
local-cluster는 멀티 클러스터 엔진 Operator 2.2 이상에서 자동으로 가져옵니다.local-cluster에 대한 자세한 내용은 Red Hat Advanced Cluster Management 설명서의 고급 구성 을 참조하십시오. 다음 명령을 실행하여 허브 클러스터의 상태를 확인할 수 있습니다.oc get managedclusters local-cluster
$ oc get managedclusters local-clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
관리 클러스터의 베어 메탈 호스트에
topology.kubernetes.io/zone레이블을 추가해야 합니다. 각 호스트에topology.kubernetes.io/zone의 고유 값이 있는지 확인합니다. 그렇지 않으면 호스팅되는 모든 컨트롤 플레인 Pod가 단일 노드에 예약되므로 단일 장애 지점이 발생합니다. - 베어 메탈에서 호스팅되는 컨트롤 플레인을 프로비저닝하려면 에이전트 플랫폼을 사용할 수 있습니다. 에이전트 플랫폼은 중앙 인프라 관리 서비스를 사용하여 호스트된 클러스터에 작업자 노드를 추가합니다. 자세한 내용은 중앙 인프라 관리 서비스 활성화를 참조하십시오.
- 호스팅된 컨트롤 플레인 명령줄 인터페이스를 설치해야 합니다.
4.2.1.2. 베어 메탈 방화벽, 포트 및 서비스 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
포트가 관리 클러스터, 컨트롤 플레인 및 호스팅 클러스터 간에 통신할 수 있도록 방화벽, 포트 및 서비스 요구 사항을 충족해야 합니다.
서비스는 기본 포트에서 실행됩니다. 그러나 NodePort 게시 전략을 사용하는 경우 서비스는 NodePort 서비스에서 할당한 포트에서 실행됩니다.
방화벽 규칙, 보안 그룹 또는 기타 액세스 제어를 사용하여 필요한 소스만 액세스를 제한합니다. 필요한 경우 포트를 공개적으로 노출하지 마십시오. 프로덕션 배포의 경우 로드 밸런서를 사용하여 단일 IP 주소를 통한 액세스를 단순화합니다.
허브 클러스터에 프록시 구성이 있는 경우 모든 호스팅 클러스터 API 끝점을 프록시 오브젝트의 no 필드에 추가하여 호스팅된 클러스터 API 엔드포인트에 연결할 수 있는지 확인합니다. 자세한 내용은 "클러스터 전체 프록시 구성"을 참조하십시오.
Proxy
호스팅된 컨트롤 플레인은 베어 메탈에 다음 서비스를 노출합니다.
APIServer-
APIServer서비스는 기본적으로 포트 6443에서 실행되며 컨트롤 플레인 구성 요소 간 통신을 위해 수신 액세스가 필요합니다. - MetalLB 로드 밸런싱을 사용하는 경우 로드 밸런서 IP 주소에 사용되는 IP 범위에 대한 수신 액세스를 허용합니다.
-
OAuthServer-
OAuthServer서비스는 경로 및 수신을 사용하여 서비스를 노출할 때 기본적으로 포트 443에서 실행됩니다. -
NodePort게시 전략을 사용하는 경우OAuthServer서비스에 방화벽 규칙을 사용합니다.
-
Konnectivity-
Konnectivity서비스는 경로 및 Ingress를 사용하여 서비스를 노출할 때 기본적으로 포트 443에서 실행됩니다. -
Konnectivity에이전트는 컨트롤 플레인이 호스팅된 클러스터의 네트워크에 액세스할 수 있도록 역방향 터널을 설정합니다. 에이전트는 egress를 사용하여Konnectivity서버에 연결합니다. 서버는 포트 443의 경로를 사용하거나 수동으로 할당된NodePort를 사용하여 노출됩니다. - 클러스터 API 서버 주소가 내부 IP 주소인 경우 워크로드 서브넷에서 포트 6443의 IP 주소로 액세스를 허용합니다.
- 주소가 외부 IP 주소인 경우 6443 포트에서 노드에서 해당 외부 IP 주소로 송신을 허용합니다.
-
Ignition-
Ignition서비스는 경로 및 수신을 사용하여 서비스를 노출할 때 기본적으로 포트 443에서 실행됩니다. -
NodePort게시 전략을 사용하는 경우Ignition서비스에 방화벽 규칙을 사용합니다.
-
베어 메탈에는 다음 서비스가 필요하지 않습니다.
-
OVNSbDb -
OIDC
4.2.1.3. 베어 메탈 인프라 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
에이전트 플랫폼은 인프라를 생성하지 않지만 인프라에 대한 다음과 같은 요구 사항이 있습니다.
- 에이전트: 에이전트 는 검색 이미지로 부팅되고 OpenShift Container Platform 노드로 프로비저닝할 준비가 된 호스트를 나타냅니다.
- DNS: API 및 수신 끝점은 라우팅할 수 있어야 합니다.
4.2.2. 베어 메탈의 DNS 구성 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 클러스터의 API 서버는 NodePort 서비스로 노출됩니다. API Server에 연결할 수 있는 대상을 가리키는 api.<hosted_cluster_name>.<base_domain >에 대한 DNS 항목이 있어야 합니다.
DNS 항목은 호스팅된 컨트롤 플레인을 실행하는 관리 클러스터에서 노드 중 하나를 가리키는 레코드만큼 간단할 수 있습니다. 이 항목은 들어오는 트래픽을 인그레스 포드로 리디렉션하기 위해 배포된 로드 밸런서를 가리킬 수도 있습니다.
DNS 구성 예
이전 예에서 *.apps.example.krnl.es. IN A 192.168.122.23 은 구성된 경우 호스팅 클러스터 또는 로드 밸런서의 노드입니다.
IPv6 네트워크에서 연결이 끊긴 환경에 대해 DNS를 구성하는 경우 구성은 다음 예와 같습니다.
IPv6 네트워크의 DNS 구성 예
듀얼 스택 네트워크에서 연결이 끊긴 환경에 대해 DNS를 구성하는 경우 IPv4 및 IPv6 모두에 대한 DNS 항목을 포함해야 합니다.
듀얼 스택 네트워크의 DNS 구성 예
4.2.2.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매개변수와 도메인의 주소를 추가하고 다음 예와 같이 사용할 인증서를 지정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
kubeAPIServerDNSName매개변수의 값은 유효한 도메인이어야 합니다.
kubeAPIServerDNSName 매개변수를 정의하고 인증서를 지정하면 Control Plane Operator 컨트롤러에서 custom-admin- 라는 kubeconfig 파일을 생성합니다. 여기서 파일이 kubeconfig HostedControlPlane 네임스페이스에 저장됩니다. 인증서 생성은 루트 CA에서 발생하며 HostedControlPlane 네임스페이스는 만료 및 갱신을 관리합니다.
Control Plane Operator는 HostedControlPlane 네임스페이스에서 CustomKubeconfig 라는 새 kubeconfig 파일을 보고합니다. 해당 파일은 kubeAPIServerDNSName 매개변수에서 정의된 새 서버를 사용합니다.
사용자 정의 kubeconfig 파일에 대한 참조는 HostedCluster 오브젝트의 CustomKubeconfig 로 status 매개변수에 있습니다. CustomKubeConfig 매개변수는 선택 사항이며 kubeAPIServerDNSName 매개변수가 비어 있지 않은 경우에만 매개변수를 추가할 수 있습니다. CustomKubeConfig 매개변수를 설정한 후 매개변수는 HostedCluster 네임스페이스에서 < hosted_cluster_name>-custom-admin-kubeconfig 라는 보안 생성을 트리거합니다. 시크릿을 사용하여 HostedCluster API 서버에 액세스할 수 있습니다. 설치 후 작업 중에 CustomKubeConfig 매개변수를 제거하면 모든 관련 보안 및 상태 참조가 삭제됩니다.
사용자 정의 DNS 이름을 정의해도 데이터 플레인에 직접적인 영향을 미치지 않으므로 예상되는 롤아웃이 발생하지 않습니다. HostedControlPlane 네임스페이스는 HyperShift Operator에서 변경 사항을 수신하고 해당 매개변수를 삭제합니다.
HostedCluster 오브젝트의 사양에서 kubeAPIServerDNSName 매개변수를 제거하면 새로 생성된 모든 보안 및 CustomKubeconfig 참조가 클러스터 및 status 매개변수에서 제거됩니다.
4.2.3. InfraEnv 리소스 생성 링크 복사링크가 클립보드에 복사되었습니다!
베어 메탈에 호스팅 클러스터를 생성하려면 먼저 InfraEnv 리소스가 필요합니다.
4.2.3.1. InfraEnv 리소스 생성 및 노드 추가 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 컨트롤 플레인에서 컨트롤 플레인 구성 요소는 데이터 플레인이 전용 노드에서 실행되는 동안 관리 클러스터에서 Pod로 실행됩니다. 지원 서비스를 사용하여 하드웨어를 하드웨어 인벤토리에 추가하는 검색 ISO로 하드웨어를 부팅할 수 있습니다. 나중에 호스트 클러스터를 생성할 때 인벤토리의 하드웨어가 데이터 플레인 노드를 프로비저닝하는 데 사용됩니다. 검색 ISO를 가져오는 데 사용되는 오브젝트는 InfraEnv 리소스입니다. 검색 ISO에서 베어 메탈 노드를 부팅하도록 클러스터를 구성하는 BareMetalHost 오브젝트를 생성해야 합니다.
프로세스
다음 명령을 입력하여 하드웨어 인벤토리를 저장할 네임스페이스를 생성합니다.
oc --kubeconfig ~/<directory_example>/mgmt-kubeconfig create \ namespace <namespace_example>
$ oc --kubeconfig ~/<directory_example>/mgmt-kubeconfig create \ namespace <namespace_example>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
- <directory_example>
-
은 관리 클러스터의
kubeconfig파일이 저장된 디렉터리의 이름입니다. - <namespace_example>
생성 중인 네임스페이스의 이름입니다(예:
hardware-inventory).출력 예
namespace/hardware-inventory created
namespace/hardware-inventory createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 명령을 입력하여 관리 클러스터의 풀 시크릿을 복사합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
- <directory_example>
-
은 관리 클러스터의
kubeconfig파일이 저장된 디렉터리의 이름입니다. - <namespace_example>
생성 중인 네임스페이스의 이름입니다(예:
hardware-inventory).출력 예
secret/pull-secret created
secret/pull-secret createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
YAML 파일에 다음 콘텐츠를 추가하여
InfraEnv리소스를 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 YAML 파일에 변경 사항을 적용합니다.
oc apply -f <infraenv_config>.yaml
$ oc apply -f <infraenv_config>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow &
lt;infraenv_config>를 파일 이름으로 바꿉니다.다음 명령을 입력하여
InfraEnv리소스가 생성되었는지 확인합니다.oc --kubeconfig ~/<directory_example>/mgmt-kubeconfig \ -n <namespace_example> get infraenv hosted
$ oc --kubeconfig ~/<directory_example>/mgmt-kubeconfig \ -n <namespace_example> get infraenv hostedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 두 가지 방법 중 하나를 수행하여 베어 메탈 호스트를 추가합니다.
Metal3 Operator를 사용하지 않는 경우
InfraEnv리소스에서 검색 ISO를 가져오고 다음 단계를 완료하여 호스트를 수동으로 부팅합니다.다음 명령을 입력하여 라이브 ISO를 다운로드합니다.
oc get infraenv -A
$ oc get infraenv -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow oc get infraenv <namespace_example> -o jsonpath='{.status.isoDownloadURL}' -n <namespace_example> <iso_url>$ oc get infraenv <namespace_example> -o jsonpath='{.status.isoDownloadURL}' -n <namespace_example> <iso_url>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
ISO를 부팅합니다. 노드는 지원 서비스와 통신하고
InfraEnv리소스와 동일한 네임스페이스에 에이전트로 등록합니다. 각 에이전트에 대해 설치 디스크 ID와 호스트 이름을 설정하고 에이전트를 사용할 준비가 되었음을 나타내기 위해 승인합니다. 다음 명령을 입력합니다.
oc -n <hosted_control_plane_namespace> get agents
$ oc -n <hosted_control_plane_namespace> get agentsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CLUSTER APPROVED ROLE STAGE 86f7ac75-4fc4-4b36-8130-40fa12602218 auto-assign e57a637f-745b-496e-971d-1abbf03341ba auto-assign
NAME CLUSTER APPROVED ROLE STAGE 86f7ac75-4fc4-4b36-8130-40fa12602218 auto-assign e57a637f-745b-496e-971d-1abbf03341ba auto-assignCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc -n <hosted_control_plane_namespace> \ patch agent 86f7ac75-4fc4-4b36-8130-40fa12602218 \ -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-0.example.krnl.es"}}' \ --type merge$ oc -n <hosted_control_plane_namespace> \ patch agent 86f7ac75-4fc4-4b36-8130-40fa12602218 \ -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-0.example.krnl.es"}}' \ --type mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc -n <hosted_control_plane_namespace> \ patch agent 23d0c614-2caa-43f5-b7d3-0b3564688baa -p \ '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-1.example.krnl.es"}}' \ --type merge$ oc -n <hosted_control_plane_namespace> \ patch agent 23d0c614-2caa-43f5-b7d3-0b3564688baa -p \ '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-1.example.krnl.es"}}' \ --type mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc -n <hosted_control_plane_namespace> get agents
$ oc -n <hosted_control_plane_namespace> get agentsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CLUSTER APPROVED ROLE STAGE 86f7ac75-4fc4-4b36-8130-40fa12602218 true auto-assign e57a637f-745b-496e-971d-1abbf03341ba true auto-assign
NAME CLUSTER APPROVED ROLE STAGE 86f7ac75-4fc4-4b36-8130-40fa12602218 true auto-assign e57a637f-745b-496e-971d-1abbf03341ba true auto-assignCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Metal3 Operator를 사용하는 경우 다음 오브젝트를 생성하여 베어 메탈 호스트 등록을 자동화할 수 있습니다.
YAML 파일을 생성하고 다음 콘텐츠를 추가합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
- <namespace_example>
- 해당 네임스페이스입니다.
- <password>
- 은 시크릿의 암호입니다.
- <username>
- 시크릿의 사용자 이름입니다.
- <bmc_address>
BareMetalHost오브젝트의 BMC 주소입니다.참고이 YAML 파일을 적용하면 다음 오브젝트가 생성됩니다.
- BMC(Baseboard Management Controller)에 대한 인증 정보가 있는 시크릿
-
BareMetalHost오브젝트 - HyperShift Operator가 에이전트를 관리할 수 있는 역할
infraenvs.agent-install.openshift.io: 호스팅사용자 정의 레이블을 사용하여BareMetalHost오브젝트에서InfraEnv리소스를 참조하는 방법을 확인합니다. 이렇게 하면 노드가 ISO가 생성된 상태로 부팅됩니다.
다음 명령을 입력하여 YAML 파일에 변경 사항을 적용합니다.
oc apply -f <bare_metal_host_config>.yaml
$ oc apply -f <bare_metal_host_config>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow &
lt;bare_metal_host_config>를 파일 이름으로 바꿉니다.
다음 명령을 입력한 다음
BareMetalHost오브젝트가프로비저닝상태로 이동할 때까지 몇 분 정도 기다립니다.oc --kubeconfig ~/<directory_example>/mgmt-kubeconfig -n <namespace_example> get bmh
$ oc --kubeconfig ~/<directory_example>/mgmt-kubeconfig -n <namespace_example> get bmhCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME STATE CONSUMER ONLINE ERROR AGE hosted-worker0 provisioning true 106s hosted-worker1 provisioning true 106s hosted-worker2 provisioning true 106s
NAME STATE CONSUMER ONLINE ERROR AGE hosted-worker0 provisioning true 106s hosted-worker1 provisioning true 106s hosted-worker2 provisioning true 106sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 노드가 부팅되고 에이전트로 표시되는지 확인합니다. 이 프로세스에는 몇 분이 걸릴 수 있으며, 명령을 두 번 이상 입력해야 할 수 있습니다.
oc --kubeconfig ~/<directory_example>/mgmt-kubeconfig -n <namespace_example> get agent
$ oc --kubeconfig ~/<directory_example>/mgmt-kubeconfig -n <namespace_example> get agentCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CLUSTER APPROVED ROLE STAGE aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0201 true auto-assign aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0202 true auto-assign aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0203 true auto-assign
NAME CLUSTER APPROVED ROLE STAGE aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0201 true auto-assign aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0202 true auto-assign aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0203 true auto-assignCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.2.3.2. 콘솔을 사용하여 InfraEnv 리소스 생성 링크 복사링크가 클립보드에 복사되었습니다!
콘솔을 사용하여 InfraEnv 리소스를 생성하려면 다음 단계를 완료합니다.
프로세스
- OpenShift Container Platform 웹 콘솔을 열고 관리자 인증 정보를 입력하여 로그인합니다. 콘솔을 여는 지침은 "웹 콘솔 액세스"를 참조하십시오.
- 콘솔 헤더에서 모든 클러스터 가 선택되어 있는지 확인합니다.
- 인프라 → 호스트 인벤토리 → 인프라 환경 생성 을 클릭합니다.
-
InfraEnv리소스를 생성한 후 Add hosts 를 클릭하고 사용 가능한 옵션에서 선택하여 InfraEnv 보기 내에서 베어 메탈 호스트를 추가합니다.
4.2.4. 베어 메탈에서 호스트 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
CLI(명령줄 인터페이스), 콘솔 또는 미러 레지스트리를 사용하여 베어 메탈에 호스팅된 클러스터를 생성할 수 있습니다.
4.2.4.1. CLI를 사용하여 호스트된 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
베어 메탈 인프라에서 호스팅된 클러스터를 생성하거나 가져올 수 있습니다. 지원 설치 관리자를 다중 클러스터 엔진 Operator에 대한 애드온으로 활성화하고 에이전트 플랫폼을 사용하여 호스팅된 클러스터를 생성한 후 HyperShift Operator는 호스팅된 컨트롤 플레인 네임스페이스에 에이전트 클러스터 API 공급자를 설치합니다. 에이전트 클러스터 API 공급자는 컨트롤 플레인과 컴퓨팅 노드로 구성된 호스팅 클러스터를 호스팅하는 관리 클러스터를 연결합니다.
사전 요구 사항
- 각 호스트 클러스터에는 클러스터 전체 이름이 있어야 합니다. 호스팅된 클러스터 이름은 기존 관리 클러스터와 같을 수 없습니다. 그러지 않으면 다중 클러스터 엔진 Operator가 호스팅된 클러스터를 관리할 수 없습니다.
-
클러스터를 호스팅
클러스터이름으로 사용하지 마십시오. - 다중 클러스터 엔진 Operator 관리 클러스터의 네임스페이스에 호스팅 클러스터를 생성할 수 없습니다.
- 최상의 보안 및 관리 관행을 위해 다른 호스팅 클러스터와 별도로 호스팅 클러스터를 생성합니다.
- 클러스터에 대해 기본 스토리지 클래스가 구성되어 있는지 확인합니다. 그러지 않으면 보류 중인 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
$ oc label node [compute-node-1] topology.kubernetes.io/zone=zone1Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc label node [compute-node-2] topology.kubernetes.io/zone=zone2
$ oc label node [compute-node-2] topology.kubernetes.io/zone=zone2Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc label node [compute-node-3] topology.kubernetes.io/zone=zone3
$ oc label node [compute-node-3] topology.kubernetes.io/zone=zone3Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 하드웨어 인벤토리에 베어 메탈 노드를 추가해야 합니다.
프로세스
다음 명령을 입력하여 네임스페이스를 생성합니다.
oc create ns <hosted_cluster_namespace>
$ oc create ns <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow &
lt;hosted_cluster_namespace>를 호스팅된 클러스터 네임스페이스의 식별자로 바꿉니다. HyperShift Operator는 네임스페이스를 생성합니다. 베어 메탈 인프라에서 호스팅된 클러스터 생성 프로세스 중에 생성된 Cluster API 공급자 역할에 네임스페이스가 이미 있어야 합니다.다음 명령을 입력하여 호스팅된 클러스터에 대한 구성 파일을 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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
- 호스팅된 컨트롤 플레인 구성 요소의 가용성 정책을 지정합니다. 지원되는 옵션은
SingleReplica및HighlyAvailable입니다. 기본값은HighlyAvailable입니다. - 10
- 사용하려는 지원되는 OpenShift Container Platform 버전 (예:
4.20.0-multi)을 지정합니다. 연결이 끊긴 환경을 사용하는 경우 <ocp_release_image>를 다이제스트 이미지로 교체합니다. OpenShift Container Platform 릴리스 이미지 다이제스트를 추출하려면 OpenShift Container Platform 릴리스 이미지 다이제스트 추출을 참조하십시오. - 11
3과 같은 노드 풀 복제본 수를 지정합니다. 동일한 수의 복제본을 생성하려면 복제본 수를0이상으로 지정해야 합니다. 그렇지 않으면 노드 풀을 생성하지 않습니다.- 12
--ssh-key플래그 후user/.ssh/id_rsa와 같은 SSH 키의 경로를 지정합니다.
서비스 게시 전략을 구성합니다. 노드 포트는 추가 인프라 없이 항상 사용할 수 있으므로 호스트된 클러스터는
NodePort서비스 게시 전략을 사용합니다. 그러나 로드 밸런서를 사용하도록 서비스 게시 전략을 구성할 수 있습니다.-
기본
NodePort전략을 사용하는 경우 관리 클러스터 노드가 아닌 호스팅 클러스터 컴퓨팅 노드를 가리키도록 DNS를 구성합니다. 자세한 내용은 " bare metal의 DNS 구성"을 참조하십시오. 프로덕션 환경의 경우 이 전략이 인증서 처리 및 자동 DNS 확인을 제공하므로
LoadBalancer전략을 사용합니다. 다음 예제에서는 호스팅된 클러스터 구성 파일에서LoadBalancer전략을 변경하는 방법을 보여줍니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
LoadBalancer를 API 서버 유형으로 지정합니다. 기타 모든 서비스에 대해Route를 유형으로 지정합니다.
-
기본
다음 명령을 입력하여 호스팅 클러스터 구성 파일에 변경 사항을 적용합니다.
oc apply -f hosted_cluster_config.yaml
$ oc apply -f hosted_cluster_config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 호스팅된 클러스터, 노드 풀 및 Pod 생성을 확인합니다.
oc get hostedcluster \ <hosted_cluster_namespace> -n \ <hosted_cluster_namespace> -o \ jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .$ oc get hostedcluster \ <hosted_cluster_namespace> -n \ <hosted_cluster_namespace> -o \ jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get nodepool \ <hosted_cluster_namespace> -n \ <hosted_cluster_namespace> -o \ jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .$ oc get nodepool \ <hosted_cluster_namespace> -n \ <hosted_cluster_namespace> -o \ jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get pods -n <hosted_cluster_namespace>
$ oc get pods -n <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
호스트 클러스터가 준비되었는지 확인합니다.
Available: True는 클러스터의 준비 상태를 나타내며 노드 풀 상태에AllMachinesReady: True가 표시됩니다. 이러한 상태는 모든 클러스터 Operator의 상태를 나타냅니다. 호스팅된 클러스터에 MetalLB를 설치합니다.
호스트 클러스터에서
kubeconfig파일을 추출하고 다음 명령을 입력하여 호스팅된 클러스터 액세스의 환경 변수를 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow export KUBECONFIG="/path/to/kubeconfig-<hosted_cluster_namespace>.yaml"
$ export KUBECONFIG="/path/to/kubeconfig-<hosted_cluster_namespace>.yaml"Copy to Clipboard Copied! Toggle word wrap Toggle overflow install-metallb-operator.yaml파일을 생성하여 MetalLB Operator를 설치합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 파일을 적용합니다.
oc apply -f install-metallb-operator.yaml
$ oc apply -f install-metallb-operator.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow deploy-metallb-ipaddresspool.yaml파일을 생성하여 MetalLB IP 주소 풀을 구성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 구성을 적용합니다.
oc apply -f deploy-metallb-ipaddresspool.yaml
$ oc apply -f deploy-metallb-ipaddresspool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 Operator 상태, IP 주소 풀,
L2Advertisement리소스를 확인하여 MetalLB의 설치를 확인합니다.oc get pods -n metallb-system
$ oc get pods -n metallb-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc get ipaddresspool -n metallb-system
$ oc get ipaddresspool -n metallb-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc get l2advertisement -n metallb-system
$ oc get l2advertisement -n metallb-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Ingress에 대한 로드 밸런서를 구성합니다.
ingress-loadbalancer.yaml파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 구성을 적용합니다.
oc apply -f ingress-loadbalancer.yaml
$ oc apply -f ingress-loadbalancer.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 로드 밸런서 서비스가 예상대로 작동하는지 확인합니다.
oc get svc metallb-ingress -n openshift-ingress
$ oc get svc metallb-ingress -n openshift-ingressCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
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
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 16hCopy to Clipboard Copied! Toggle word wrap Toggle overflow
로드 밸런서에서 작동하도록 DNS를 구성합니다.
-
로드 밸런서 IP 주소에
*.> 와일드카드 DNS 레코드를 가리켜 apps 도메인의 DNS를 구성합니다.apps.<hosted_cluster_namespace>.<base_domain 다음 명령을 입력하여 DNS 확인을 확인합니다.
nslookup console-openshift-console.apps.<hosted_cluster_namespace>.<base_domain> <load_balancer_ip_address>
$ nslookup console-openshift-console.apps.<hosted_cluster_namespace>.<base_domain> <load_balancer_ip_address>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
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
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.71Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
로드 밸런서 IP 주소에
검증
다음 명령을 입력하여 클러스터 Operator를 확인합니다.
oc get clusteroperators
$ oc get clusteroperatorsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 모든 Operator에
AVAILABLE: True,PROGRESSING: False,DEGRADED: False가 표시되는지 확인합니다.다음 명령을 입력하여 노드를 확인합니다.
oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 각 노드에
READY상태가 있는지 확인합니다.웹 브라우저에 다음 URL을 입력하여 콘솔에 대한 액세스를 테스트합니다.
https://console-openshift-console.apps.<hosted_cluster_namespace>.<base_domain>
https://console-openshift-console.apps.<hosted_cluster_namespace>.<base_domain>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.2.4.2. 콘솔을 사용하여 베어 메탈에서 호스트 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
콘솔을 사용하여 호스팅된 클러스터를 생성하려면 다음 단계를 완료합니다.
프로세스
- OpenShift Container Platform 웹 콘솔을 열고 관리자 인증 정보를 입력하여 로그인합니다. 콘솔을 여는 지침은 "웹 콘솔 액세스"를 참조하십시오.
- 콘솔 헤더에서 모든 클러스터 가 선택되어 있는지 확인합니다.
- 인프라 → 클러스터를 클릭합니다.
클러스터 → 호스트 인벤토리 → 호스팅 컨트롤 플레인 생성 을 클릭합니다.
클러스터 생성 페이지가 표시됩니다.
클러스터 생성 페이지에서 프롬프트에 따라 클러스터, 노드 풀, 네트워킹 및 자동화에 대한 세부 정보를 입력합니다.
참고클러스터에 대한 세부 정보를 입력하면 다음 팁이 유용할 수 있습니다.
- 사전 정의된 값을 사용하여 콘솔에서 필드를 자동으로 채우려면 호스트 인벤토리 인증 정보를 생성할 수 있습니다. 자세한 내용은 "온-프레미스 환경에 대한 인증 정보 생성"을 참조하십시오.
- 클러스터 세부 정보 페이지에서 풀 시크릿은 OpenShift Container Platform 리소스에 액세스하는 데 사용하는 OpenShift Container Platform 풀 시크릿입니다. 호스트 인벤토리 인증 정보를 선택한 경우 가져오기 보안이 자동으로 채워집니다.
- 노드 풀 페이지에서 네임스페이스에는 노드 풀의 호스트가 포함되어 있습니다. 콘솔을 사용하여 호스트 인벤토리를 생성한 경우 콘솔은 전용 네임스페이스를 생성합니다.
-
네트워킹 페이지에서 API 서버 게시 전략을 선택합니다. 호스팅된 클러스터의 API 서버는 기존 로드 밸런서를 사용하거나
NodePort유형의 서비스로 노출될 수 있습니다. API 서버에 연결할 수 있는 대상을 가리키는api.<hosted_cluster_name>.<base_domain> 설정에 대한 DNS 항목이 있어야 합니다. 이 항목은 관리 클러스터의 노드 중 하나를 가리키는 레코드이거나 수신 트래픽을 Ingress pod로 리디렉션하는 로드 밸런서를 가리키는 레코드일 수 있습니다.
항목을 검토하고 생성 을 클릭합니다.
호스팅된 클러스터 보기가 표시됩니다.
- Hosted 클러스터 보기에서 호스팅된 클러스터의 배포를 모니터링합니다.
- 호스팅된 클러스터에 대한 정보가 표시되지 않는 경우 모든 클러스터가 선택되어 있는지 확인한 다음 클러스터 이름을 클릭합니다.
- 컨트롤 플레인 구성 요소가 준비될 때까지 기다립니다. 이 프로세스는 몇 분 정도 걸릴 수 있습니다.
- 노드 풀 상태를 보려면 NodePool 섹션으로 스크롤합니다. 노드를 설치하는 프로세스에는 약 10분이 걸립니다. 노드를 클릭하여 노드가 호스팅된 클러스터에 참여하고 있는지 확인할 수도 있습니다.
다음 단계
- 웹 콘솔에 액세스하려면 웹 콘솔 액세스를 참조하십시오.
4.2.4.3. 미러 레지스트리를 사용하여 베어 메탈에서 호스팅 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
미러 레지스트리를 사용하여 hcp create cluster 명령에 --image-content-sources 플래그를 지정하여 베어 메탈에 호스팅 클러스터를 생성할 수 있습니다.
프로세스
YAML 파일을 생성하여 ICSP(Image Content Source Policies)를 정의합니다. 다음 예제를 참조하십시오.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
파일을
icsp.yaml로 저장합니다. 이 파일에는 미러 레지스트리가 포함되어 있습니다. 미러 레지스트리를 사용하여 호스팅된 클러스터를 생성하려면 다음 명령을 실행합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 호스팅된 클러스터의 이름을 지정합니다(
예: ). - 2
- 풀 시크릿의 경로를 지정합니다(예:
/user/name/pullsecret). - 3
- 호스팅된 컨트롤 플레인 네임스페이스를 지정합니다(예: cluster
-example).oc get agent -n <hosted-control-plane-namespace> 명령을 사용하여 이 네임스페이스에서 에이전트를 사용할 수 있는지 확인합니다. - 4
- 기본 도메인을 지정합니다(예:
krnl.es). - 5
--api-server-address플래그는 호스팅된 클러스터의 Kubernetes API 통신에 사용되는 IP 주소를 정의합니다.--api-server-address플래그를 설정하지 않으면 관리 클러스터에 연결하려면 로그인해야 합니다.- 6
- ICSP 및 미러 레지스트리를 정의하는
icsp.yaml파일을 지정합니다. - 7
- SSH 공개 키의 경로를 지정합니다. 기본 파일 경로는
~/.ssh/id_rsa.pub입니다. - 8
- 호스팅된 클러스터 네임스페이스를 지정합니다.
- 9
- 사용하려는 지원되는 OpenShift Container Platform 버전을 지정합니다(예:
4.20.0-multi). 연결이 끊긴 환경을 사용하는 경우 <ocp_release_image>를 다이제스트 이미지로 교체합니다. OpenShift Container Platform 릴리스 이미지 다이제스트를 추출하려면 "OpenShift Container Platform 릴리스 이미지 다이제스트 추출"을 참조하십시오.
다음 단계
- 콘솔을 사용하여 호스팅된 클러스터를 만들 때 재사용할 수 있는 인증 정보를 생성하려면 온프레미스 환경에 대한 인증 정보 생성 을 참조하십시오.
- 호스트된 클러스터에 액세스하려면 호스팅 된 클러스터 액세스를 참조하십시오.
- Discovery Image를 사용하여 호스트 인벤토리에 호스트를 추가하려면 Discovery Image 를 사용하여 호스트 인벤토리에 호스트 추가를 참조하십시오.
- OpenShift Container Platform 릴리스 이미지 다이제스트를 추출하려면 OpenShift Container Platform 릴리스 이미지 다이제스트 추출을 참조하십시오.
4.2.5. 호스트된 클러스터 생성 확인 링크 복사링크가 클립보드에 복사되었습니다!
배포 프로세스가 완료되면 호스트 클러스터가 성공적으로 생성되었는지 확인할 수 있습니다. 호스팅된 클러스터를 생성한 후 몇 분 후에 다음 단계를 수행합니다.
프로세스
extract 명령을 입력하여 새 호스팅 클러스터에 대한 kubeconfig를 가져옵니다.
oc extract -n <hosted-control-plane-namespace> secret/admin-kubeconfig \ --to=- > kubeconfig-<hosted-cluster-name>
$ oc extract -n <hosted-control-plane-namespace> secret/admin-kubeconfig \ --to=- > kubeconfig-<hosted-cluster-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow kubeconfig를 사용하여 호스팅된 클러스터의 클러스터 Operator를 확인합니다. 다음 명령을 실행합니다.
oc get co --kubeconfig=kubeconfig-<hosted-cluster-name>
$ oc get co --kubeconfig=kubeconfig-<hosted-cluster-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE console 4.10.26 True False False 2m38s dns 4.10.26 True False False 2m52s image-registry 4.10.26 True False False 2m8s ingress 4.10.26 True False False 22m
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE console 4.10.26 True False False 2m38s dns 4.10.26 True False False 2m52s image-registry 4.10.26 True False False 2m8s ingress 4.10.26 True False False 22mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 호스팅 클러스터에서 실행 중인 Pod를 볼 수도 있습니다.
oc get pods -A --kubeconfig=kubeconfig-<hosted-cluster-name>
$ oc get pods -A --kubeconfig=kubeconfig-<hosted-cluster-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.2.6. 호스트된 클러스터에서 사용자 정의 API 서버 인증서 구성 링크 복사링크가 클립보드에 복사되었습니다!
API 서버의 사용자 정의 인증서를 구성하려면 HostedCluster 구성의 spec.configuration.apiServer 섹션에 인증서 세부 정보를 지정합니다.
day-1 또는 day-2 작업 중에 사용자 정의 인증서를 구성할 수 있습니다. 그러나 호스트 클러스터 생성 중에 서비스 게시 전략은 변경할 수 없으므로 구성하려는 Kubernetes API 서버의 호스트 이름이 무엇인지 알아야 합니다.
사전 요구 사항
관리 클러스터에 사용자 정의 인증서가 포함된 Kubernetes 시크릿을 생성했습니다. 보안에는 다음 키가 포함되어 있습니다.
-
TLS.crt: 인증서 -
TLS.key: 개인 키
-
-
HostedCluster구성에 로드 밸런서를 사용하는 서비스 게시 전략이 포함된 경우 인증서의 SAN(주체 대체 이름)이 내부 API 끝점(api-int)과 충돌하지 않는지 확인합니다. 내부 API 끝점은 플랫폼에서 자동으로 생성 및 관리합니다. 사용자 정의 인증서와 내부 API 끝점 모두에서 동일한 호스트 이름을 사용하는 경우 라우팅 충돌이 발생할 수 있습니다. 이 규칙의 유일한 예외는Private또는PublicAndPrivate구성이 있는 공급자로 AWS를 사용하는 경우입니다. 이러한 경우 SAN 충돌은 플랫폼에 의해 관리됩니다. - 인증서는 외부 API 끝점에 유효해야 합니다.
- 인증서의 유효 기간은 클러스터의 예상 라이프 사이클과 일치합니다.
프로세스
다음 명령을 입력하여 사용자 정의 인증서로 보안을 생성합니다.
oc create secret tls sample-hosted-kas-custom-cert \ --cert=path/to/cert.crt \ --key=path/to/key.key \ -n <hosted_cluster_namespace>
$ oc create secret tls sample-hosted-kas-custom-cert \ --cert=path/to/cert.crt \ --key=path/to/key.key \ -n <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예와 같이 사용자 정의 인증서 세부 정보를 사용하여
HostedCluster구성을 업데이트합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여
HostedCluster구성에 변경 사항을 적용합니다.oc apply -f <hosted_cluster_config>.yaml
$ oc apply -f <hosted_cluster_config>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
- API 서버 pod를 확인하여 새 인증서가 마운트되었는지 확인합니다.
- 사용자 정의 도메인 이름을 사용하여 API 서버에 대한 연결을 테스트합니다.
-
브라우저에서 인증서 세부 정보를 확인하거나
openssl과 같은 도구를 사용하여 확인합니다.
4.3. OpenShift Virtualization에 호스팅된 컨트롤 플레인 배포 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 컨트롤 플레인 및 OpenShift Virtualization을 사용하면 KubeVirt 가상 머신에서 호스팅하는 작업자 노드로 OpenShift Container Platform 클러스터를 생성할 수 있습니다. OpenShift Virtualization에서 호스팅되는 컨트롤 플레인은 다음과 같은 몇 가지 이점을 제공합니다.
- 동일한 기본 베어 메탈 인프라에서 호스트된 컨트롤 플레인 및 호스팅된 클러스터를 패키징하여 리소스 사용량 개선
- 강력한 격리를 제공하기 위해 호스팅되는 컨트롤 플레인과 호스팅 클러스터를 분리
- 베어 메탈 노드 부트스트랩 프로세스를 제거하여 클러스터 프로비저닝 시간 단축
- 동일한 기본 OpenShift Container Platform 클러스터에서 많은 릴리스 관리
호스트된 컨트롤 플레인 기능은 기본적으로 활성화되어 있습니다.
호스팅된 컨트롤 플레인 명령줄 인터페이스 hcp 를 사용하여 OpenShift Container Platform 호스팅 클러스터를 생성할 수 있습니다. 호스팅된 클러스터는 관리 클러스터로 자동으로 가져옵니다. 이 자동 가져오기 기능을 비활성화하려면 "호스트된 클러스터의 자동 가져오기 비활성화"를 참조하십시오.
4.3.1. OpenShift Virtualization에 호스팅된 컨트롤 플레인을 배포하기 위한 요구사항 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Virtualization에 호스팅된 컨트롤 플레인을 배포할 준비가 되면 다음 정보를 고려하십시오.
- 베어 메탈에서 관리 클러스터를 실행합니다.
- 각 호스트 클러스터에는 클러스터 전체 이름이 있어야 합니다.
-
클러스터를 호스팅
클러스터이름으로 사용하지 마십시오. - 호스트된 클러스터는 다중 클러스터 엔진 Operator 관리 클러스터의 네임스페이스에서 생성할 수 없습니다.
- 호스트된 컨트롤 플레인에 대한 스토리지를 구성할 때 권장 etcd 사례를 고려하십시오. 대기 시간 요구 사항을 충족하는지 확인하려면 각 컨트롤 플레인 노드에서 실행되는 모든 호스팅 컨트롤 플레인 etcd 인스턴스에 빠른 스토리지 장치를 전용으로 지정합니다. LVM 스토리지를 사용하여 호스팅된 etcd pod의 로컬 스토리지 클래스를 구성할 수 있습니다. 자세한 내용은 "Recommended etcd practices" 및 "Persistent storage using Logical Volume Manager storage"를 참조하십시오.
4.3.1.1. 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Virtualization에서 OpenShift Container Platform 클러스터를 생성하려면 다음 사전 요구 사항을 충족해야 합니다.
-
KUBECONFIG환경 변수에 지정된 OpenShift Container Platform 클러스터 버전 4.14 이상에 대한 관리자 액세스 권한이 있어야 합니다. OpenShift Container Platform 관리 클러스터에는 다음 명령에 표시된 대로 와일드카드 DNS 경로가 활성화되어 있어야 합니다.
oc patch ingresscontroller -n openshift-ingress-operator default \ --type=json \ -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'$ oc patch ingresscontroller -n openshift-ingress-operator default \ --type=json \ -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow - OpenShift Container Platform 관리 클러스터에는 OpenShift Virtualization, 버전 4.14 이상이 설치되어 있습니다. 자세한 내용은 "웹 콘솔을 사용하여 OpenShift Virtualization 설치"를 참조하십시오.
- OpenShift Container Platform 관리 클러스터는 온프레미스 베어 메탈입니다.
-
OpenShift Container Platform 관리 클러스터는
OVNKubernetes를 기본 Pod 네트워크 CNI(Container Network Interface)로 사용하여 구성해야 합니다. CNI가 OVN-Kubernetes인 경우에만 노드에서 실시간 마이그레이션이 지원됩니다. OpenShift Container Platform 관리 클러스터에는 기본 스토리지 클래스가 있습니다. 자세한 내용은 "Postinstallation storage configuration"을 참조하십시오. 다음 예제에서는 기본 스토리지 클래스를 설정하는 방법을 보여줍니다.
oc patch storageclass ocs-storagecluster-ceph-rbd \ -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'$ oc patch storageclass ocs-storagecluster-ceph-rbd \ -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
quay.io/openshift-release-dev리포지토리에 유효한 풀 시크릿 파일이 있습니다. 자세한 내용은 "사용자 프로비저닝 인프라가 있는 x86_64 플랫폼에 OpenShift 설치"를 참조하십시오. - 호스팅된 컨트롤 플레인 명령줄 인터페이스를 설치했습니다.
- 로드 밸런서를 구성했습니다. 자세한 내용은 " MetalLB 구성"을 참조하십시오.
최적의 네트워크 성능을 위해 KubeVirt 가상 머신을 호스팅하는 OpenShift Container Platform 클러스터에서 네트워크 최대 전송 단위(MTU)를 사용하고 있습니다. 더 낮은 MTU 설정을 사용하는 경우 호스트된 Pod의 네트워크 대기 시간과 처리량이 영향을 받습니다. MTU가 9000 이상인 경우에만 노드 풀에서 멀티 큐를 활성화합니다.
중요클러스터의 MTU 값은 설치 후 작업으로 변경할 수 없습니다.
다중 클러스터 엔진 Operator에는 하나 이상의 관리형 OpenShift Container Platform 클러스터가 있습니다.
local-cluster가 자동으로 가져옵니다.local-cluster에 대한 자세한 내용은 다중 클러스터 엔진 Operator 설명서의 "고급 구성"을 참조하십시오. 다음 명령을 실행하여 허브 클러스터의 상태를 확인할 수 있습니다.oc get managedclusters local-cluster
$ oc get managedclusters local-clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
OpenShift Virtualization 가상 머신을 호스팅하는 OpenShift Container Platform 클러스터에서는 실시간 마이그레이션을 활성화할 수 있도록 RWX(
ReadWriteMany) 스토리지 클래스를 사용하고 있습니다.
4.3.1.2. 방화벽 및 포트 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
포트가 관리 클러스터, 컨트롤 플레인 및 호스팅 클러스터 간에 통신할 수 있도록 방화벽 및 포트 요구 사항을 충족하는지 확인합니다.
kube-apiserver서비스는 기본적으로 포트 6443에서 실행되며 컨트롤 플레인 구성 요소 간의 통신을 위해 수신 액세스가 필요합니다.-
NodePort게시 전략을 사용하는 경우kube-apiserver서비스에 할당된 노드 포트가 노출되어 있는지 확인합니다. - MetalLB 로드 밸런싱을 사용하는 경우 로드 밸런서 IP 주소에 사용되는 IP 범위에 대한 수신 액세스를 허용합니다.
-
-
NodePort게시 전략을 사용하는 경우ignition-server및Oauth-server설정에 방화벽 규칙을 사용합니다. 호스팅된 클러스터에서 양방향 통신을 허용하도록 역방향 터널을 설정하는
konnectivity에이전트에는 포트 6443의 클러스터 API 서버 주소에 대한 송신 액세스가 필요합니다. 이 송신 액세스를 사용하면 에이전트가kube-apiserver서비스에 도달할 수 있습니다.- 클러스터 API 서버 주소가 내부 IP 주소인 경우 워크로드 서브넷에서 포트 6443의 IP 주소로 액세스를 허용합니다.
- 주소가 외부 IP 주소인 경우 6443 포트에서 노드에서 해당 외부 IP 주소로 송신을 허용합니다.
- 기본 6443 포트를 변경하는 경우 해당 변경 사항을 반영하도록 규칙을 조정합니다.
- 클러스터에서 실행되는 워크로드에 필요한 모든 포트를 열어야 합니다.
- 방화벽 규칙, 보안 그룹 또는 기타 액세스 제어를 사용하여 필요한 소스만 액세스를 제한합니다. 필요한 경우 포트를 공개적으로 노출하지 마십시오.
- 프로덕션 배포의 경우 로드 밸런서를 사용하여 단일 IP 주소를 통한 액세스를 단순화합니다.
4.3.2. 컴퓨팅 노드를 위한 실시간 마이그레이션 링크 복사링크가 클립보드에 복사되었습니다!
호스트된 클러스터 가상 머신(VM)의 관리 클러스터는 업데이트 또는 유지 관리 수행 중이지만 호스트된 클러스터 VM은 호스트된 클러스터 워크로드 중단을 방지하기 위해 자동으로 실시간 마이그레이션될 수 있습니다. 결과적으로 KubeVirt 플랫폼 호스팅 클러스터의 가용성 및 작동에 영향을 미치지 않고 관리 클러스터를 업데이트할 수 있습니다.
VM이 root 볼륨 및 kubevirt-csi CSI 공급자에 매핑되는 스토리지 클래스에 대해 RWX( ReadWriteMany ) 스토리지를 사용하는 경우 KubeVirt VM의 실시간 마이그레이션이 기본적으로 활성화됩니다.
NodePool 오브젝트의 status 섹션에서 KubeVirtNodesLiveMigratable 조건을 확인하여 노드 풀의 VM을 실시간 마이그레이션할 수 있는지 확인할 수 있습니다.
다음 예제에서는 RWX 스토리지가 사용되지 않기 때문에 VM을 실시간 마이그레이션할 수 없습니다.
VM을 실시간 마이그레이션할 수 없는 구성의 예
다음 예에서 VM은 실시간 마이그레이션 요구 사항을 충족합니다.
VM을 실시간으로 마이그레이션할 수 있는 구성 예
실시간 마이그레이션은 정상적인 상황에서 VM을 중단하지 않도록 보호할 수 있지만 인프라 노드 장애와 같은 이벤트는 실패한 노드에서 호스팅되는 모든 VM을 다시 시작할 수 있습니다. 실시간 마이그레이션이 성공하려면 VM이 호스팅되는 소스 노드가 올바르게 작동해야 합니다.
노드 풀의 VM을 실시간 마이그레이션할 수 없는 경우 관리 클러스터에서 유지 관리하는 동안 호스트된 클러스터에서 워크로드 중단이 발생할 수 있습니다. 기본적으로 호스팅되는 컨트롤 플레인 컨트롤러는 VM을 중지하기 전에 실시간 마이그레이션할 수 없는 KubeVirt VM에서 호스팅되는 워크로드를 드레이닝하려고 합니다. VM을 중지하기 전에 호스팅된 클러스터 노드를 드레이닝하면 Pod 중단 예산으로 인해 호스팅된 클러스터 내에서 워크로드 가용성을 보호할 수 있습니다.
4.3.3. KubeVirt 플랫폼을 사용하여 호스트 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 4.14 이상에서는 KubeVirt로 클러스터를 생성하여 외부 인프라로 생성할 수 있습니다.
4.3.3.1. CLI를 사용하여 KubeVirt 플랫폼에서 호스트 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
호스트된 클러스터를 생성하려면 호스팅된 컨트롤 플레인 CLI(명령줄 인터페이스) hcp 를 사용할 수 있습니다.
프로세스
다음 명령을 입력하여 KubeVirt 플랫폼을 사용하여 호스팅된 클러스터를 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고--release-image플래그를 사용하여 특정 OpenShift Container Platform 릴리스로 호스팅 클러스터를 설정할 수 있습니다.--node-pool-replicas플래그에 따라 두 개의 가상 머신 작업자 복제본이 있는 클러스터에 대한 기본 노드 풀이 생성됩니다.잠시 후 다음 명령을 입력하여 호스팅된 컨트롤 플레인 포드가 실행 중인지 확인합니다.
oc -n clusters-<hosted-cluster-name> get pods
$ oc -n clusters-<hosted-cluster-name> get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow KubeVirt 가상 머신에서 지원하는 작업자 노드가 있는 호스팅된 클러스터는 일반적으로 완전히 프로비저닝되는 데 10-15분이 걸립니다.
검증
호스트 클러스터의 상태를 확인하려면 다음 명령을 입력하여 해당
HostedCluster리소스를 참조하십시오.oc get --namespace clusters hostedclusters
$ oc get --namespace clusters hostedclustersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 완전히 프로비저닝된
HostedCluster오브젝트를 설명하는 다음 예제 출력을 참조하십시오.NAMESPACE NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE clusters my-hosted-cluster <4.x.0> example-admin-kubeconfig Completed True False The hosted control plane is available
NAMESPACE NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE clusters my-hosted-cluster <4.x.0> example-admin-kubeconfig Completed True False The hosted control plane is availableCopy to Clipboard Copied! Toggle word wrap Toggle overflow &
lt;4.x.0>을 사용하려는 지원되는 OpenShift Container Platform 버전으로 바꿉니다.
4.3.3.2. 외부 인프라를 사용하여 KubeVirt 플랫폼으로 호스트 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 HyperShift Operator는 동일한 클러스터 내에서 호스팅되는 클러스터의 컨트롤 플레인 Pod와 KubeVirt 작업자 VM을 모두 호스팅합니다. 외부 인프라 기능을 사용하면 작업자 노드 VM을 컨트롤 플레인 Pod와 별도의 클러스터에 배치할 수 있습니다.
- 관리 클러스터 는 HyperShift Operator를 실행하고 호스팅된 클러스터의 컨트롤 플레인 Pod를 호스팅하는 OpenShift Container Platform 클러스터입니다.
- 인프라 클러스터 는 호스팅된 클러스터의 KubeVirt 작업자 VM을 실행하는 OpenShift Container Platform 클러스터입니다.
- 기본적으로 관리 클러스터는 VM을 호스팅하는 인프라 클러스터 역할을 합니다. 그러나 외부 인프라의 경우 관리 및 인프라 클러스터는 다릅니다.
사전 요구 사항
- KubeVirt 노드를 호스팅하려면 외부 인프라 클러스터에 네임스페이스가 있어야 합니다.
-
외부 인프라 클러스터에 대한
kubeconfig파일이 있어야 합니다.
프로세스
hcp 명령줄 인터페이스를 사용하여 호스트된 클러스터를 생성할 수 있습니다.
인프라 클러스터에 KubeVirt 작업자 VM을 배치하려면 다음 예와 같이
--infra-kubeconfig-file및--infra-namespace인수를 사용합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 해당 명령을 입력하면 컨트롤 플레인 Pod가 HyperShift Operator가 실행되는 관리 클러스터에서 호스팅되고 KubeVirt VM은 별도의 인프라 클러스터에서 호스팅됩니다.
4.3.3.3. 콘솔을 사용하여 호스트 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
콘솔을 사용하여 KubeVirt 플랫폼으로 호스팅된 클러스터를 생성하려면 다음 단계를 완료하십시오.
프로세스
- OpenShift Container Platform 웹 콘솔을 열고 관리자 인증 정보를 입력하여 로그인합니다.
- 콘솔 헤더에서 모든 클러스터 가 선택되어 있는지 확인합니다.
- Infrastructure > Clusters를 클릭합니다.
- Create cluster > Red Hat OpenShift Virtualization > Hosted를 클릭합니다.
클러스터 생성 페이지에서 프롬프트에 따라 클러스터 및 노드 풀에 대한 세부 정보를 입력합니다.
참고- 사전 정의된 값을 사용하여 콘솔에서 필드를 자동으로 채우려면 OpenShift Virtualization 인증 정보를 생성할 수 있습니다. 자세한 내용은 "온-프레미스 환경에 대한 인증 정보 생성"을 참조하십시오.
- 클러스터 세부 정보 페이지에서 풀 시크릿은 OpenShift Container Platform 리소스에 액세스하는 데 사용하는 OpenShift Container Platform 풀 시크릿입니다. OpenShift Virtualization 인증 정보를 선택한 경우 풀 시크릿이 자동으로 채워집니다.
노드 풀 페이지에서 네트워킹 옵션 섹션을 확장하고 노드 풀에 대한 네트워킹 옵션을 구성합니다.
-
추가 네트워크 필드에 <
namespace>/<name> 형식으로 네트워크 이름을입력합니다(예:my-namespace/network1). 네임스페이스와 이름은 유효한 DNS 레이블이어야 합니다. 여러 네트워크가 지원됩니다. - 기본적으로 Attach default pod network 확인란이 선택됩니다. 추가 네트워크가 있는 경우에만 이 확인란을 지울 수 있습니다.
-
추가 네트워크 필드에 <
항목을 검토하고 생성 을 클릭합니다.
호스팅된 클러스터 보기가 표시됩니다.
검증
- Hosted 클러스터 보기에서 호스팅된 클러스터의 배포를 모니터링합니다. 호스팅된 클러스터에 대한 정보가 표시되지 않는 경우 모든 클러스터가 선택되어 있는지 확인하고 클러스터 이름을 클릭합니다.
- 컨트롤 플레인 구성 요소가 준비될 때까지 기다립니다. 이 프로세스는 몇 분 정도 걸릴 수 있습니다.
- 노드 풀 상태를 보려면 NodePool 섹션으로 스크롤합니다. 노드를 설치하는 프로세스에는 약 10분이 걸립니다. 노드를 클릭하여 노드가 호스팅된 클러스터에 참여하고 있는지 확인할 수도 있습니다.
4.3.4. OpenShift Virtualization에서 호스팅된 컨트롤 플레인의 기본 수신 및 DNS 구성 링크 복사링크가 클립보드에 복사되었습니다!
모든 OpenShift Container Platform 클러스터에는 기본 애플리케이션 Ingress 컨트롤러가 포함되어 있으며, 이와 연결된 와일드카드 DNS 레코드가 있어야 합니다. 기본적으로 HyperShift KubeVirt 공급자를 사용하여 생성된 호스팅 클러스터는 KubeVirt 가상 머신이 실행되는 OpenShift Container Platform 클러스터의 하위 도메인이 자동으로 됩니다.
예를 들어 OpenShift Container Platform 클러스터에 다음과 같은 기본 인그레스 DNS 항목이 있을 수 있습니다.
*.apps.mgmt-cluster.example.com
*.apps.mgmt-cluster.example.com
결과적으로 guest 라는 이름의 KubeVirt 호스팅 클러스터에는 다음과 같은 기본 수신이 있습니다.
*.apps.guest.apps.mgmt-cluster.example.com
*.apps.guest.apps.mgmt-cluster.example.com
프로세스
기본 인그레스 DNS가 제대로 작동하려면 KubeVirt 가상 머신을 호스팅하는 클러스터에서 와일드카드 DNS 경로를 허용해야 합니다.
다음 명령을 입력하여 이 동작을 구성할 수 있습니다.
oc patch ingresscontroller -n openshift-ingress-operator default \ --type=json \ -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'$ oc patch ingresscontroller -n openshift-ingress-operator default \ --type=json \ -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
기본 호스팅 클러스터 수신을 사용하는 경우 포트 443을 통한 HTTPS 트래픽으로 제한됩니다. 포트 80을 통한 일반 HTTP 트래픽이 거부됩니다. 이 제한은 기본 수신 동작에만 적용됩니다.
4.3.4.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매개변수와 도메인의 주소를 추가하고 다음 예와 같이 사용할 인증서를 지정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
kubeAPIServerDNSName매개변수의 값은 유효한 도메인이어야 합니다.
kubeAPIServerDNSName 매개변수를 정의하고 인증서를 지정하면 Control Plane Operator 컨트롤러에서 custom-admin- 라는 kubeconfig 파일을 생성합니다. 여기서 파일이 kubeconfig HostedControlPlane 네임스페이스에 저장됩니다. 인증서 생성은 루트 CA에서 발생하며 HostedControlPlane 네임스페이스는 만료 및 갱신을 관리합니다.
Control Plane Operator는 HostedControlPlane 네임스페이스에서 CustomKubeconfig 라는 새 kubeconfig 파일을 보고합니다. 해당 파일은 kubeAPIServerDNSName 매개변수에서 정의된 새 서버를 사용합니다.
사용자 정의 kubeconfig 파일에 대한 참조는 HostedCluster 오브젝트의 CustomKubeconfig 로 status 매개변수에 있습니다. CustomKubeConfig 매개변수는 선택 사항이며 kubeAPIServerDNSName 매개변수가 비어 있지 않은 경우에만 매개변수를 추가할 수 있습니다. CustomKubeConfig 매개변수를 설정한 후 매개변수는 HostedCluster 네임스페이스에서 < hosted_cluster_name>-custom-admin-kubeconfig 라는 보안 생성을 트리거합니다. 시크릿을 사용하여 HostedCluster API 서버에 액세스할 수 있습니다. 설치 후 작업 중에 CustomKubeConfig 매개변수를 제거하면 모든 관련 보안 및 상태 참조가 삭제됩니다.
사용자 정의 DNS 이름을 정의해도 데이터 플레인에 직접적인 영향을 미치지 않으므로 예상되는 롤아웃이 발생하지 않습니다. HostedControlPlane 네임스페이스는 HyperShift Operator에서 변경 사항을 수신하고 해당 매개변수를 삭제합니다.
HostedCluster 오브젝트의 사양에서 kubeAPIServerDNSName 매개변수를 제거하면 새로 생성된 모든 보안 및 CustomKubeconfig 참조가 클러스터 및 status 매개변수에서 제거됩니다.
4.3.5. 수신 및 DNS 동작 사용자 정의 링크 복사링크가 클립보드에 복사되었습니다!
기본 수신 및 DNS 동작을 사용하지 않으려면 생성 시 KubeVirt 호스팅 클러스터를 고유 기본 도메인으로 구성할 수 있습니다. 이 옵션을 사용하려면 생성 중에 수동 구성 단계가 필요하며 클러스터 생성, 로드 밸런서 생성 및 와일드카드 DNS 구성의 세 가지 주요 단계가 포함됩니다.
4.3.5.1. 기본 도메인을 지정하는 호스팅된 클러스터 배포 링크 복사링크가 클립보드에 복사되었습니다!
기본 도메인을 지정하는 호스팅 클러스터를 생성하려면 다음 단계를 완료합니다.
프로세스
다음 명령을 실행합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 결과적으로 호스팅된 클러스터에는 클러스터 이름과 기본 도메인(예:
.apps.example.hypershift.lab)에 대해 구성된 수신 와일드카드가 있습니다. 호스트 클러스터는 고유한 기본 도메인을 사용하여 호스팅 클러스터를 생성한 후 필요한 DNS 레코드 및 로드 밸런서를 구성해야 하므로부분적상태로 유지됩니다.
검증
다음 명령을 입력하여 호스팅 클러스터의 상태를 확인합니다.
oc get --namespace clusters hostedclusters
$ oc get --namespace clusters hostedclustersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE example example-admin-kubeconfig Partial True False The hosted control plane is available
NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE example example-admin-kubeconfig Partial True False The hosted control plane is availableCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 클러스터에 액세스합니다.
hcp create kubeconfig --name <hosted_cluster_name> \ > <hosted_cluster_name>-kubeconfig
$ hcp create kubeconfig --name <hosted_cluster_name> \ > <hosted_cluster_name>-kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc --kubeconfig <hosted_cluster_name>-kubeconfig get co
$ oc --kubeconfig <hosted_cluster_name>-kubeconfig get coCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE console <4.x.0> False False False 30m RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.example.hypershift.lab): Get "https://console-openshift-console.apps.example.hypershift.lab": dial tcp: lookup console-openshift-console.apps.example.hypershift.lab on 172.31.0.10:53: no such host ingress <4.x.0> True False True 28m The "default" ingress controller reports Degraded=True: DegradedConditions: One or more other status conditions indicate a degraded state: CanaryChecksSucceeding=False (CanaryChecksRepetitiveFailures: Canary route checks for the default ingress controller are failing)
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE console <4.x.0> False False False 30m RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.example.hypershift.lab): Get "https://console-openshift-console.apps.example.hypershift.lab": dial tcp: lookup console-openshift-console.apps.example.hypershift.lab on 172.31.0.10:53: no such host ingress <4.x.0> True False True 28m The "default" ingress controller reports Degraded=True: DegradedConditions: One or more other status conditions indicate a degraded state: CanaryChecksSucceeding=False (CanaryChecksRepetitiveFailures: Canary route checks for the default ingress controller are failing)Copy to Clipboard Copied! Toggle word wrap Toggle overflow &
lt;4.x.0>을 사용하려는 지원되는 OpenShift Container Platform 버전으로 바꿉니다.
다음 단계
출력에서 오류를 수정하려면 "로드 밸런서 설정" 및 " 와일드카드 DNS 설정"의 단계를 완료합니다.
호스팅 클러스터가 베어 메탈에 있는 경우 로드 밸런서 서비스를 설정하려면 MetalLB가 필요할 수 있습니다. 자세한 내용은 " MetalLB 구성"을 참조하십시오.
4.3.5.2. 로드 밸런서 설정 링크 복사링크가 클립보드에 복사되었습니다!
Ingress 트래픽을 KubeVirt VM으로 라우팅하고 로드 밸런서 IP 주소에 와일드카드 DNS 항목을 할당하는 로드 밸런서 서비스를 설정합니다.
프로세스
호스팅된 클러스터 인그레스를 노출하는
NodePort서비스가 이미 존재합니다. 노드 포트를 내보내고 해당 포트를 대상으로 하는 로드 밸런서 서비스를 생성할 수 있습니다.다음 명령을 입력하여 HTTP 노드 포트를 가져옵니다.
oc --kubeconfig <hosted_cluster_name>-kubeconfig get services \ -n openshift-ingress router-nodeport-default \ -o jsonpath='{.spec.ports[?(@.name=="http")].nodePort}'$ oc --kubeconfig <hosted_cluster_name>-kubeconfig get services \ -n openshift-ingress router-nodeport-default \ -o jsonpath='{.spec.ports[?(@.name=="http")].nodePort}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 단계에서 사용할 HTTP 노드 포트 값을 확인합니다.
다음 명령을 입력하여 HTTPS 노드 포트를 가져옵니다.
oc --kubeconfig <hosted_cluster_name>-kubeconfig get services \ -n openshift-ingress router-nodeport-default \ -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}'$ oc --kubeconfig <hosted_cluster_name>-kubeconfig get services \ -n openshift-ingress router-nodeport-default \ -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 단계에서 사용할 HTTPS 노드 포트 값을 확인합니다.
YAML 파일에 다음 정보를 입력합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 로드 밸런서 서비스를 생성합니다.
oc create -f <file_name>.yaml
$ oc create -f <file_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.5.3. 와일드카드 DNS 설정 링크 복사링크가 클립보드에 복사되었습니다!
로드 밸런서 서비스의 외부 IP를 참조하는 와일드카드 DNS 레코드 또는 CNAME을 설정합니다.
프로세스
다음 명령을 입력하여 외부 IP 주소를 가져옵니다.
oc -n clusters-<hosted_cluster_name> get service <hosted-cluster-name>-apps \ -o jsonpath='{.status.loadBalancer.ingress[0].ip}'$ oc -n clusters-<hosted_cluster_name> get service <hosted-cluster-name>-apps \ -o jsonpath='{.status.loadBalancer.ingress[0].ip}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
192.168.20.30
192.168.20.30Copy to Clipboard Copied! Toggle word wrap Toggle overflow 외부 IP 주소를 참조하는 와일드카드 DNS 항목을 구성합니다. 다음 예제 DNS 항목을 확인합니다.
*.apps.<hosted_cluster_name\>.<base_domain\>.
*.apps.<hosted_cluster_name\>.<base_domain\>.Copy to Clipboard Copied! Toggle word wrap Toggle overflow DNS 항목은 클러스터 내부 및 외부에서 라우팅할 수 있어야 합니다.
DNS 확인 예
dig +short test.apps.example.hypershift.lab 192.168.20.30
dig +short test.apps.example.hypershift.lab 192.168.20.30Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 입력하여 호스팅 클러스터 상태가
Partial에서Completed로 이동했는지 확인합니다.oc get --namespace clusters hostedclusters
$ oc get --namespace clusters hostedclustersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE example <4.x.0> example-admin-kubeconfig Completed True False The hosted control plane is available
NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE example <4.x.0> example-admin-kubeconfig Completed True False The hosted control plane is availableCopy to Clipboard Copied! Toggle word wrap Toggle overflow &
lt;4.x.0>을 사용하려는 지원되는 OpenShift Container Platform 버전으로 바꿉니다.
4.3.6. MetalLB 구성 링크 복사링크가 클립보드에 복사되었습니다!
MetalLB를 구성하기 전에 MetalLB Operator를 설치해야 합니다.
프로세스
호스팅된 클러스터에서 MetalLB를 구성하려면 다음 단계를 완료합니다.
다음 샘플 YAML 콘텐츠를
configure-metallb.yaml파일에 저장하여MetalLB리소스를 생성합니다.apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb-system
apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 YAML 콘텐츠를 적용합니다.
oc apply -f configure-metallb.yaml
$ oc apply -f configure-metallb.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
metallb.metallb.io/metallb created
metallb.metallb.io/metallb createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow create-ip-address-pool.yaml파일에 다음 샘플 YAML 콘텐츠를 저장하여IPAddressPool리소스를 만듭니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 노드 네트워크 내에서 사용 가능한 IP 주소 범위를 사용하여 주소 풀을 생성합니다. IP 주소 범위를 네트워크에서 사용 가능한 IP 주소의 사용되지 않는 풀로 바꿉니다.
다음 명령을 입력하여 YAML 콘텐츠를 적용합니다.
oc apply -f create-ip-address-pool.yaml
$ oc apply -f create-ip-address-pool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
ipaddresspool.metallb.io/metallb created
ipaddresspool.metallb.io/metallb createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow l2advertisement.yaml파일에 다음 샘플 YAML 콘텐츠를 저장하여L2Advertisement리소스를 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 YAML 콘텐츠를 적용합니다.
oc apply -f l2advertisement.yaml
$ oc apply -f l2advertisement.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
l2advertisement.metallb.io/metallb created
l2advertisement.metallb.io/metallb createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.7. 노드 풀에 대한 추가 네트워크, 보장된 CPU 및 VM 스케줄링 구성 링크 복사링크가 클립보드에 복사되었습니다!
노드 풀에 대한 추가 네트워크를 구성해야 하는 경우 가상 머신(VM)에 대한 보장된 CPU 액세스를 요청하거나 KubeVirt VM의 스케줄링을 관리해야 하는 경우 다음 절차를 참조하십시오.
4.3.7.1. 노드 풀에 여러 네트워크 추가 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 노드 풀에서 생성한 노드는 Pod 네트워크에 연결됩니다. Multus 및 NetworkAttachmentDefinitions를 사용하여 추가 네트워크를 노드에 연결할 수 있습니다.
프로세스
노드에 여러 네트워크를 추가하려면 다음 명령을 실행하여
--additional-network인수를 사용합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 호스트 클러스터의 이름을 지정합니다(예:
my-hosted-cluster). - 2
- 작업자 노드 수를 지정합니다(예:
2). - 3
- 풀 시크릿의 경로를 지정합니다(예:
/user/name/pullsecret). - 4
- 메모리 값을 지정합니다(예:
8Gi). - 5
- CPU 값을 지정합니다(예:
2). - 6
-additional-network인수의 값을name:<namespace/name> 로 설정합니다. <namespace/name>을 NetworkAttachmentDefinitions의 네임스페이스 및 이름으로 바꿉니다.
4.3.7.1.1. 추가 네트워크를 기본값으로 사용 링크 복사링크가 클립보드에 복사되었습니다!
기본 Pod 네트워크를 비활성화하여 추가 네트워크를 노드의 기본 네트워크로 추가할 수 있습니다.
프로세스
노드에 기본 네트워크를 추가하려면 다음 명령을 실행합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.7.2. 보장된 CPU 리소스 요청 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 KubeVirt VM은 노드의 다른 워크로드와 CPU를 공유할 수 있습니다. 이는 VM의 성능에 영향을 미칠 수 있습니다. 성능에 미치는 영향을 방지하기 위해 VM에 대해 보장된 CPU 액세스를 요청할 수 있습니다.
프로세스
보장된 CPU 리소스를 요청하려면 다음 명령을 실행하여
--qos-class인수를Guaranteed로 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.7.3. 노드 세트에서 KubeVirt VM 예약 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 노드 풀에서 생성한 KubeVirt VM은 사용 가능한 모든 노드에 예약됩니다. VM을 실행하는 데 충분한 용량이 있는 특정 노드 세트에서 KubeVirt VM을 예약할 수 있습니다.
프로세스
특정 노드 세트의 노드 풀 내에서 KubeVirt VM을 예약하려면 다음 명령을 실행하여
--vm-node-selector인수를 사용합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.8. 노드 풀 확장 링크 복사링크가 클립보드에 복사되었습니다!
oc scale 명령을 사용하여 노드 풀을 수동으로 확장할 수 있습니다.
프로세스
다음 명령을 실행합니다.
NODEPOOL_NAME=${CLUSTER_NAME}-work NODEPOOL_REPLICAS=5 $ oc scale nodepool/$NODEPOOL_NAME --namespace clusters \ --replicas=$NODEPOOL_REPLICASNODEPOOL_NAME=${CLUSTER_NAME}-work NODEPOOL_REPLICAS=5 $ oc scale nodepool/$NODEPOOL_NAME --namespace clusters \ --replicas=$NODEPOOL_REPLICASCopy to Clipboard Copied! Toggle word wrap Toggle overflow 잠시 후 다음 명령을 입력하여 노드 풀의 상태를 확인합니다.
oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodes
$ oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.8.1. 노드 풀 추가 링크 복사링크가 클립보드에 복사되었습니다!
이름, 복제본 수 및 메모리 및 CPU 요구 사항과 같은 추가 정보를 지정하여 호스팅된 클러스터에 대한 노드 풀을 생성할 수 있습니다.
프로세스
노드 풀을 생성하려면 다음 정보를 입력합니다. 이 예에서 노드 풀에는 VM에 더 많은 CPU가 할당됩니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cluster 네임스페이스에
nodepool리소스를 나열하여 노드 풀의상태를확인합니다.oc get nodepools --namespace clusters
$ oc get nodepools --namespace clustersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE example example 5 5 False False <4.x.0> example-extra-cpu example 2 False False True True Minimum availability requires 2 replicas, current 0 available
NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE example example 5 5 False False <4.x.0> example-extra-cpu example 2 False False True True Minimum availability requires 2 replicas, current 0 availableCopy to Clipboard Copied! Toggle word wrap Toggle overflow &
lt;4.x.0>을 사용하려는 지원되는 OpenShift Container Platform 버전으로 바꿉니다.
검증
잠시 후 다음 명령을 입력하여 노드 풀의 상태를 확인할 수 있습니다.
oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodes
$ oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 노드 풀이 예상되는 상태에 있는지 확인합니다.
oc get nodepools --namespace clusters
$ oc get nodepools --namespace clustersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE example example 5 5 False False <4.x.0> example-extra-cpu example 2 2 False False <4.x.0>
NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE example example 5 5 False False <4.x.0> example-extra-cpu example 2 2 False False <4.x.0>Copy to Clipboard Copied! Toggle word wrap Toggle overflow &
lt;4.x.0>을 사용하려는 지원되는 OpenShift Container Platform 버전으로 바꿉니다.
4.3.9. OpenShift Virtualization에서 호스트된 클러스터 생성 확인 링크 복사링크가 클립보드에 복사되었습니다!
호스팅 클러스터가 성공적으로 생성되었는지 확인하려면 다음 단계를 완료합니다.
프로세스
다음 명령을 입력하여
HostedCluster리소스가완료된상태로 전환되었는지 확인합니다.oc get --namespace clusters hostedclusters <hosted_cluster_name>
$ oc get --namespace clusters hostedclusters <hosted_cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAMESPACE NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE clusters example 4.12.2 example-admin-kubeconfig Completed True False The hosted control plane is available
NAMESPACE NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE clusters example 4.12.2 example-admin-kubeconfig Completed True False The hosted control plane is availableCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 호스팅 클러스터의 모든 클러스터 운영자가 온라인 상태인지 확인합니다.
hcp create kubeconfig --name <hosted_cluster_name> \ > <hosted_cluster_name>-kubeconfig
$ hcp create kubeconfig --name <hosted_cluster_name> \ > <hosted_cluster_name>-kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc get co --kubeconfig=<hosted_cluster_name>-kubeconfig
$ oc get co --kubeconfig=<hosted_cluster_name>-kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.10. 호스트된 클러스터에서 사용자 정의 API 서버 인증서 구성 링크 복사링크가 클립보드에 복사되었습니다!
API 서버의 사용자 정의 인증서를 구성하려면 HostedCluster 구성의 spec.configuration.apiServer 섹션에 인증서 세부 정보를 지정합니다.
day-1 또는 day-2 작업 중에 사용자 정의 인증서를 구성할 수 있습니다. 그러나 호스트 클러스터 생성 중에 서비스 게시 전략은 변경할 수 없으므로 구성하려는 Kubernetes API 서버의 호스트 이름이 무엇인지 알아야 합니다.
사전 요구 사항
관리 클러스터에 사용자 정의 인증서가 포함된 Kubernetes 시크릿을 생성했습니다. 보안에는 다음 키가 포함되어 있습니다.
-
TLS.crt: 인증서 -
TLS.key: 개인 키
-
-
HostedCluster구성에 로드 밸런서를 사용하는 서비스 게시 전략이 포함된 경우 인증서의 SAN(주체 대체 이름)이 내부 API 끝점(api-int)과 충돌하지 않는지 확인합니다. 내부 API 끝점은 플랫폼에서 자동으로 생성 및 관리합니다. 사용자 정의 인증서와 내부 API 끝점 모두에서 동일한 호스트 이름을 사용하는 경우 라우팅 충돌이 발생할 수 있습니다. 이 규칙의 유일한 예외는Private또는PublicAndPrivate구성이 있는 공급자로 AWS를 사용하는 경우입니다. 이러한 경우 SAN 충돌은 플랫폼에 의해 관리됩니다. - 인증서는 외부 API 끝점에 유효해야 합니다.
- 인증서의 유효 기간은 클러스터의 예상 라이프 사이클과 일치합니다.
프로세스
다음 명령을 입력하여 사용자 정의 인증서로 보안을 생성합니다.
oc create secret tls sample-hosted-kas-custom-cert \ --cert=path/to/cert.crt \ --key=path/to/key.key \ -n <hosted_cluster_namespace>
$ oc create secret tls sample-hosted-kas-custom-cert \ --cert=path/to/cert.crt \ --key=path/to/key.key \ -n <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예와 같이 사용자 정의 인증서 세부 정보를 사용하여
HostedCluster구성을 업데이트합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여
HostedCluster구성에 변경 사항을 적용합니다.oc apply -f <hosted_cluster_config>.yaml
$ oc apply -f <hosted_cluster_config>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
- API 서버 pod를 확인하여 새 인증서가 마운트되었는지 확인합니다.
- 사용자 정의 도메인 이름을 사용하여 API 서버에 대한 연결을 테스트합니다.
-
브라우저에서 인증서 세부 정보를 확인하거나
openssl과 같은 도구를 사용하여 확인합니다.
4.4. 베어 메탈이 아닌 에이전트 시스템에 호스트된 컨트롤 플레인 배포 링크 복사링크가 클립보드에 복사되었습니다!
호스팅 클러스터로 작동하도록 클러스터를 구성하여 호스팅 컨트롤 플레인을 배포할 수 있습니다. 호스팅 클러스터는 컨트롤 플레인이 호스팅되는 OpenShift Container Platform 클러스터입니다. 호스팅 클러스터를 관리 클러스터라고도 합니다.
베어 메탈이 아닌 에이전트 시스템의 호스팅된 컨트롤 플레인은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 다음 링크를 참조하십시오.
관리 클러스터는 관리 클러스터와 동일하지 않습니다. 관리형 클러스터는 hub 클러스터가 관리하는 클러스터입니다.
호스트된 컨트롤 플레인 기능은 기본적으로 활성화되어 있습니다.
다중 클러스터 엔진 Operator는 기본 로컬 클러스터 관리 허브 클러스터 만 지원합니다. RHACM(Red Hat Advanced Cluster Management) 2.10에서 local-cluster 관리 허브 클러스터를 호스팅 클러스터로 사용할 수 있습니다.
호스팅 클러스터는 호스팅 클러스터에서 호스팅되 는 API 끝점 및 컨트롤 플레인이 있는 OpenShift Container Platform 클러스터입니다. 호스트된 클러스터에는 컨트롤 플레인과 해당 데이터 플레인이 포함됩니다. 다중 클러스터 엔진 Operator 콘솔 또는 hcp CLI(명령줄 인터페이스)를 사용하여 호스팅된 클러스터를 생성할 수 있습니다.
호스팅된 클러스터는 관리 클러스터로 자동으로 가져옵니다. 이 자동 가져오기 기능을 비활성화하려면 "호스트된 클러스터의 자동 가져오기 비활성화"를 참조하십시오.
4.4.1. 베어 메탈이 아닌 에이전트 시스템에 호스팅된 컨트롤 플레인 배포 준비 링크 복사링크가 클립보드에 복사되었습니다!
베어 메탈에 호스팅된 컨트롤 플레인을 배포할 준비가 되면 다음 정보를 고려하십시오.
- 에이전트 플랫폼을 사용하여 에이전트 시스템을 호스트된 클러스터에 작업자 노드로 추가할 수 있습니다. 에이전트 머신은 Discovery Image로 부팅되고 OpenShift Container Platform 노드로 프로비저닝할 준비가 된 호스트를 나타냅니다. 에이전트 플랫폼은 중앙 인프라 관리 서비스의 일부입니다. 자세한 내용은 중앙 인프라 관리 서비스 활성화를 참조하십시오.
- 베어 메탈이 아닌 모든 호스트는 중앙 인프라 관리에서 제공하는 Discovery Image ISO로 수동 부팅이 필요합니다.
- 노드 풀을 확장하면 모든 복제본에 대해 머신이 생성됩니다. 모든 머신에 대해 Cluster API 공급자는 승인된 에이전트를 찾아 설치하며, 검증을 통과하고, 현재 사용되지 않으며, 노드 풀 사양에 지정된 요구 사항을 충족합니다. 에이전트의 상태 및 조건을 확인하여 에이전트 설치를 모니터링할 수 있습니다.
- 노드 풀을 축소하면 에이전트가 해당 클러스터에서 바인딩되지 않습니다. 에이전트를 재사용하려면 먼저 Discovery 이미지를 사용하여 다시 시작해야 합니다.
- 호스트된 컨트롤 플레인에 대한 스토리지를 구성할 때 권장 etcd 사례를 고려하십시오. 대기 시간 요구 사항을 충족하는지 확인하려면 각 컨트롤 플레인 노드에서 실행되는 모든 호스팅 컨트롤 플레인 etcd 인스턴스에 빠른 스토리지 장치를 전용으로 지정합니다. LVM 스토리지를 사용하여 호스팅된 etcd pod의 로컬 스토리지 클래스를 구성할 수 있습니다. 자세한 내용은 OpenShift Container Platform 설명서의 "Red Hat etcd 권장" 및 "논리 볼륨 관리자 스토리지를 사용하여 영구 스토리지"를 참조하십시오.
4.4.1.1. 베어 메탈이 아닌 에이전트 시스템에 호스트된 컨트롤 플레인을 배포하기 위한 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
비bare-metal 에이전트 시스템에 호스팅되는 컨트롤 플레인을 배포하기 전에 다음 사전 요구 사항을 충족해야 합니다.
- Kubernetes Operator 2.5 이상을 위한 멀티 클러스터 엔진이 OpenShift Container Platform 클러스터에 설치되어 있어야 합니다. OpenShift Container Platform 소프트웨어 카탈로그에서 다중 클러스터 엔진 Operator를 Operator로 설치할 수 있습니다.
다중 클러스터 엔진 Operator에 대해 하나 이상의 관리형 OpenShift Container Platform 클러스터가 있어야 합니다.
local-cluster관리 클러스터를 자동으로 가져옵니다.local-cluster에 대한 자세한 내용은 Red Hat Advanced Cluster Management 설명서의 고급 구성 을 참조하십시오. 다음 명령을 실행하여 관리 클러스터의 상태를 확인할 수 있습니다.oc get managedclusters local-cluster
$ oc get managedclusters local-clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 중앙 인프라 관리를 활성화했습니다. 자세한 내용은 Red Hat Advanced Cluster Management 설명서에서 중앙 인프라 관리 서비스 활성화를 참조하십시오.
-
hcp명령줄 인터페이스를 설치했습니다. - 호스팅된 클러스터에는 클러스터 전체 이름이 있습니다.
- 동일한 인프라에서 관리 클러스터 및 작업자를 실행하고 있습니다.
4.4.1.2. 베어 메탈이 아닌 에이전트 시스템에 대한 방화벽, 포트 및 서비스 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
포트가 관리 클러스터, 컨트롤 플레인 및 호스팅 클러스터 간에 통신할 수 있도록 방화벽 및 포트 요구 사항을 충족해야 합니다.
서비스는 기본 포트에서 실행됩니다. 그러나 NodePort 게시 전략을 사용하는 경우 서비스는 NodePort 서비스에서 할당한 포트에서 실행됩니다.
방화벽 규칙, 보안 그룹 또는 기타 액세스 제어를 사용하여 필요한 소스만 액세스를 제한합니다. 필요한 경우 포트를 공개적으로 노출하지 마십시오. 프로덕션 배포의 경우 로드 밸런서를 사용하여 단일 IP 주소를 통한 액세스를 단순화합니다.
호스팅된 컨트롤 플레인은 베어 메탈이 아닌 에이전트 시스템에 다음 서비스를 노출합니다.
APIServer-
APIServer서비스는 기본적으로 포트 6443에서 실행되며 컨트롤 플레인 구성 요소 간 통신을 위해 수신 액세스가 필요합니다. - MetalLB 로드 밸런싱을 사용하는 경우 로드 밸런서 IP 주소에 사용되는 IP 범위에 대한 수신 액세스를 허용합니다.
-
OAuthServer-
OAuthServer서비스는 경로 및 수신을 사용하여 서비스를 노출할 때 기본적으로 포트 443에서 실행됩니다. -
NodePort게시 전략을 사용하는 경우OAuthServer서비스에 방화벽 규칙을 사용합니다.
-
Konnectivity-
Konnectivity서비스는 경로 및 Ingress를 사용하여 서비스를 노출할 때 기본적으로 포트 443에서 실행됩니다. -
Konnectivity에이전트는 컨트롤 플레인이 호스팅된 클러스터의 네트워크에 액세스할 수 있도록 역방향 터널을 설정합니다. 에이전트는 egress를 사용하여Konnectivity서버에 연결합니다. 서버는 포트 443의 경로를 사용하거나 수동으로 할당된NodePort를 사용하여 노출됩니다. - 클러스터 API 서버 주소가 내부 IP 주소인 경우 워크로드 서브넷에서 포트 6443의 IP 주소로 액세스를 허용합니다.
- 주소가 외부 IP 주소인 경우 6443 포트에서 노드에서 해당 외부 IP 주소로 송신을 허용합니다.
-
Ignition-
Ignition서비스는 경로 및 수신을 사용하여 서비스를 노출할 때 기본적으로 포트 443에서 실행됩니다. -
NodePort게시 전략을 사용하는 경우Ignition서비스에 방화벽 규칙을 사용합니다.
-
베어 메탈이 아닌 에이전트 머신에는 다음 서비스가 필요하지 않습니다.
-
OVNSbDb -
OIDC
4.4.1.3. 베어 메탈이 아닌 에이전트 시스템에 대한 인프라 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
에이전트 플랫폼은 인프라를 생성하지 않지만 다음과 같은 인프라 요구 사항이 있습니다.
- 에이전트: 에이전트 는 검색 이미지로 부팅되고 OpenShift Container Platform 노드로 프로비저닝할 준비가 된 호스트를 나타냅니다.
- DNS: API 및 수신 끝점은 라우팅할 수 있어야 합니다.
4.4.2. 베어 메탈이 아닌 에이전트 시스템에서 DNS 구성 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 클러스터의 API 서버는 NodePort 서비스로 노출됩니다. API Server에 연결할 수 있는 대상을 가리키는 api.<hosted_cluster_name>.<basedomain >에 대한 DNS 항목이 있어야 합니다.
DNS 항목은 호스팅된 컨트롤 플레인을 실행하는 관리형 클러스터의 노드 중 하나를 가리키는 레코드만큼 단순할 수 있습니다. 이 항목은 들어오는 트래픽을 인그레스 포드로 리디렉션하기 위해 배포된 로드 밸런서를 가리킬 수도 있습니다.
IPv4 네트워크에서 연결된 환경에 대한 DNS를 구성하는 경우 다음 예제 DNS 구성을 참조하십시오.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow IPv6 네트워크에서 연결이 끊긴 환경에 대한 DNS를 구성하는 경우 다음 예제 DNS 구성을 참조하십시오.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 듀얼 스택 네트워크에서 연결이 끊긴 환경에 대해 DNS를 구성하는 경우 IPv4 및 IPv6 모두에 대한 DNS 항목을 포함해야 합니다. 다음 예제 DNS 구성을 참조하십시오.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4.2.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매개변수와 도메인의 주소를 추가하고 다음 예와 같이 사용할 인증서를 지정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
kubeAPIServerDNSName매개변수의 값은 유효한 도메인이어야 합니다.
kubeAPIServerDNSName 매개변수를 정의하고 인증서를 지정하면 Control Plane Operator 컨트롤러에서 custom-admin- 라는 kubeconfig 파일을 생성합니다. 여기서 파일이 kubeconfig HostedControlPlane 네임스페이스에 저장됩니다. 인증서 생성은 루트 CA에서 발생하며 HostedControlPlane 네임스페이스는 만료 및 갱신을 관리합니다.
Control Plane Operator는 HostedControlPlane 네임스페이스에서 CustomKubeconfig 라는 새 kubeconfig 파일을 보고합니다. 해당 파일은 kubeAPIServerDNSName 매개변수에서 정의된 새 서버를 사용합니다.
사용자 정의 kubeconfig 파일에 대한 참조는 HostedCluster 오브젝트의 CustomKubeconfig 로 status 매개변수에 있습니다. CustomKubeConfig 매개변수는 선택 사항이며 kubeAPIServerDNSName 매개변수가 비어 있지 않은 경우에만 매개변수를 추가할 수 있습니다. CustomKubeConfig 매개변수를 설정한 후 매개변수는 HostedCluster 네임스페이스에서 < hosted_cluster_name>-custom-admin-kubeconfig 라는 보안 생성을 트리거합니다. 시크릿을 사용하여 HostedCluster API 서버에 액세스할 수 있습니다. 설치 후 작업 중에 CustomKubeConfig 매개변수를 제거하면 모든 관련 보안 및 상태 참조가 삭제됩니다.
사용자 정의 DNS 이름을 정의해도 데이터 플레인에 직접적인 영향을 미치지 않으므로 예상되는 롤아웃이 발생하지 않습니다. HostedControlPlane 네임스페이스는 HyperShift Operator에서 변경 사항을 수신하고 해당 매개변수를 삭제합니다.
HostedCluster 오브젝트의 사양에서 kubeAPIServerDNSName 매개변수를 제거하면 새로 생성된 모든 보안 및 CustomKubeconfig 참조가 클러스터 및 status 매개변수에서 제거됩니다.
4.4.3. CLI를 사용하여 베어 메탈이 아닌 에이전트 시스템에서 호스트 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
에이전트 플랫폼을 사용하여 호스팅된 클러스터를 생성하면 HyperShift Operator가 호스팅된 컨트롤 플레인 네임스페이스에 에이전트 클러스터 API 공급자를 설치합니다. 베어 메탈에서 호스팅 클러스터를 생성하거나 가져올 수 있습니다.
호스트 클러스터를 생성할 때 다음 지침을 검토하십시오.
- 각 호스트 클러스터에는 클러스터 전체 이름이 있어야 합니다. 호스트된 클러스터 이름은 다중 클러스터 엔진 Operator가 이를 관리하기 위해 기존 관리 클러스터와 같을 수 없습니다.
-
클러스터를 호스팅
클러스터이름으로 사용하지 마십시오. - 호스트된 클러스터는 다중 클러스터 엔진 Operator 관리 클러스터의 네임스페이스에서 생성할 수 없습니다.
프로세스
다음 명령을 입력하여 호스팅된 컨트롤 플레인 네임스페이스를 생성합니다.
oc create ns <hosted_cluster_namespace>-<hosted_cluster_name>
$ oc create ns <hosted_cluster_namespace>-<hosted_cluster_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- <
;hosted_cluster_namespace>를 호스팅된 클러스터 네임스페이스 이름(예: 클러스터 )으로바꿉니다. <hosted_cluster_name>을 호스트된 클러스터 이름으로 교체합니다.
다음 명령을 입력하여 호스팅 클러스터를 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 호스팅된 클러스터의 이름을 지정합니다(
예: ). - 2
- 풀 시크릿의 경로를 지정합니다(예:
/user/name/pullsecret). - 3
- 호스팅된 컨트롤 플레인 네임스페이스를 지정합니다(예: cluster
-example).oc get agent -n <hosted-control-plane-namespace> 명령을 사용하여 이 네임스페이스에서 에이전트를 사용할 수 있는지 확인합니다. - 4
- 기본 도메인을 지정합니다(예:
krnl.es). - 5
--api-server-address플래그는 호스팅된 클러스터의 Kubernetes API 통신에 사용되는 IP 주소를 정의합니다.--api-server-address플래그를 설정하지 않으면 관리 클러스터에 연결하려면 로그인해야 합니다.- 6
- 클러스터에 대해 기본 스토리지 클래스가 구성되어 있는지 확인합니다. 그러지 않으면 보류 중인 PVC로 종료될 수 있습니다. etcd 스토리지 클래스 이름을 지정합니다(예:
lvm-storageclass). - 7
- SSH 공개 키의 경로를 지정합니다. 기본 파일 경로는
~/.ssh/id_rsa.pub입니다. - 8
- 호스팅된 클러스터 네임스페이스를 지정합니다.
- 9
- 호스팅된 컨트롤 플레인 구성 요소의 가용성 정책을 지정합니다. 지원되는 옵션은
SingleReplica및HighlyAvailable입니다. 기본값은HighlyAvailable입니다. - 10
- 사용하려는 지원되는 OpenShift Container Platform 버전을 지정합니다(예:
4.20.0-multi). - 11
- 노드 풀 복제본 수를 지정합니다(예:
3). 동일한 수의 복제본을 생성하려면 복제본 수를0이상으로 지정해야 합니다. 그렇지 않으면 노드 풀이 생성되지 않습니다.
검증
잠시 후 다음 명령을 입력하여 호스팅된 컨트롤 플레인 pod가 실행 중인지 확인합니다.
oc -n <hosted_cluster_namespace>-<hosted_cluster_name> get pods
$ oc -n <hosted_cluster_namespace>-<hosted_cluster_name> get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME READY STATUS RESTARTS AGE catalog-operator-6cd867cc7-phb2q 2/2 Running 0 2m50s control-plane-operator-f6b4c8465-4k5dh 1/1 Running 0 4m32s
NAME READY STATUS RESTARTS AGE catalog-operator-6cd867cc7-phb2q 2/2 Running 0 2m50s control-plane-operator-f6b4c8465-4k5dh 1/1 Running 0 4m32sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4.3.1. 웹 콘솔을 사용하여 베어 메탈이 아닌 에이전트 시스템에서 호스트 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 웹 콘솔을 사용하여 베어 메탈이 아닌 에이전트 시스템에서 호스트 클러스터를 생성할 수 있습니다.
사전 요구 사항
-
cluster-admin권한이 있는 클러스터에 액세스할 수 있습니다. - OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
프로세스
- OpenShift Container Platform 웹 콘솔을 열고 관리자 인증 정보를 입력하여 로그인합니다.
- 콘솔 헤더에서 모든 클러스터를 선택합니다.
- 인프라 → 클러스터를 클릭합니다.
클러스터 호스트 인벤토리 → 호스팅 컨트롤 플레인 생성 을 클릭합니다.
클러스터 생성 페이지가 표시됩니다.
- 클러스터 생성 페이지에서 프롬프트에 따라 클러스터, 노드 풀, 네트워킹 및 자동화에 대한 세부 정보를 입력합니다.
클러스터에 대한 세부 정보를 입력하면 다음 팁이 유용할 수 있습니다.
- 사전 정의된 값을 사용하여 콘솔에서 필드를 자동으로 채우려면 호스트 인벤토리 인증 정보를 생성할 수 있습니다. 자세한 내용은 온-프레미스 환경에 대한 인증 정보 만들기 를 참조하십시오.
- 클러스터 세부 정보 페이지에서 풀 시크릿은 OpenShift Container Platform 리소스에 액세스하는 데 사용하는 OpenShift Container Platform 풀 시크릿입니다. 호스트 인벤토리 인증 정보를 선택한 경우 가져오기 보안이 자동으로 채워집니다.
- 노드 풀 페이지에서 네임스페이스에는 노드 풀의 호스트가 포함되어 있습니다. 콘솔을 사용하여 호스트 인벤토리를 생성한 경우 콘솔은 전용 네임스페이스를 생성합니다.
네트워킹 페이지에서 API 서버 게시 전략을 선택합니다. 호스팅된 클러스터의 API 서버는 기존 로드 밸런서를 사용하거나
NodePort유형의 서비스로 노출될 수 있습니다. API 서버에 연결할 수 있는 대상을 가리키는api.<hosted_cluster_name>.<basedomain> 설정에 대한 DNS 항목이 있어야 합니다. 이 항목은 관리 클러스터의 노드 중 하나를 가리키는 레코드이거나 수신 트래픽을 Ingress pod로 리디렉션하는 로드 밸런서를 가리키는 레코드일 수 있습니다.- 항목을 검토하고 생성 을 클릭합니다.
호스팅된 클러스터 보기가 표시됩니다.
- Hosted 클러스터 보기에서 호스팅된 클러스터의 배포를 모니터링합니다. 호스팅된 클러스터에 대한 정보가 표시되지 않는 경우 모든 클러스터가 선택되어 있는지 확인하고 클러스터 이름을 클릭합니다. 컨트롤 플레인 구성 요소가 준비될 때까지 기다립니다. 이 프로세스는 몇 분 정도 걸릴 수 있습니다.
- 노드 풀 상태를 보려면 NodePool 섹션으로 스크롤합니다. 노드를 설치하는 프로세스에는 약 10분이 걸립니다. 노드를 클릭하여 노드가 호스팅된 클러스터에 참여하고 있는지 확인할 수도 있습니다.
다음 단계
- 웹 콘솔에 액세스하려면 웹 콘솔 액세스를 참조하십시오.
4.4.3.2. 미러 레지스트리를 사용하여 베어 메탈이 아닌 에이전트 시스템에서 호스트 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
미러 레지스트리를 사용하여 hcp create cluster 명령에 --image-content-sources 플래그를 지정하여 베어 메탈이 아닌 에이전트 시스템에서 호스팅된 클러스터를 생성할 수 있습니다.
프로세스
YAML 파일을 생성하여 ICSP(Image Content Source Policies)를 정의합니다. 다음 예제를 참조하십시오.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
파일을
icsp.yaml로 저장합니다. 이 파일에는 미러 레지스트리가 포함되어 있습니다. 미러 레지스트리를 사용하여 호스팅된 클러스터를 생성하려면 다음 명령을 실행합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 호스팅된 클러스터의 이름을 지정합니다(
예: ). - 2
- 풀 시크릿의 경로를 지정합니다(예:
/user/name/pullsecret). - 3
- 호스팅된 컨트롤 플레인 네임스페이스를 지정합니다(예: cluster
-example).oc get agent -n <hosted-control-plane-namespace> 명령을 사용하여 이 네임스페이스에서 에이전트를 사용할 수 있는지 확인합니다. - 4
- 기본 도메인을 지정합니다(예:
krnl.es). - 5
--api-server-address플래그는 호스팅된 클러스터의 Kubernetes API 통신에 사용되는 IP 주소를 정의합니다.--api-server-address플래그를 설정하지 않으면 관리 클러스터에 연결하려면 로그인해야 합니다.- 6
- ICSP 및 미러 레지스트리를 정의하는
icsp.yaml파일을 지정합니다. - 7
- SSH 공개 키의 경로를 지정합니다. 기본 파일 경로는
~/.ssh/id_rsa.pub입니다. - 8
- 호스팅된 클러스터 네임스페이스를 지정합니다.
- 9
- 사용하려는 지원되는 OpenShift Container Platform 버전을 지정합니다(예:
4.20.0-multi). 연결이 끊긴 환경을 사용하는 경우 <ocp_release_image>를 다이제스트 이미지로 교체합니다. OpenShift Container Platform 릴리스 이미지 다이제스트를 추출하려면 OpenShift Container Platform 릴리스 이미지 다이제스트 추출을 참조하십시오.
다음 단계
- 콘솔을 사용하여 호스팅된 클러스터를 만들 때 재사용할 수 있는 인증 정보를 생성하려면 온프레미스 환경에 대한 인증 정보 생성 을 참조하십시오.
- 호스트된 클러스터에 액세스하려면 호스팅 된 클러스터 액세스를 참조하십시오.
- Discovery Image를 사용하여 호스트 인벤토리에 호스트를 추가하려면 Discovery Image 를 사용하여 호스트 인벤토리에 호스트 추가를 참조하십시오.
- OpenShift Container Platform 릴리스 이미지 다이제스트를 추출하려면 OpenShift Container Platform 릴리스 이미지 다이제스트 추출을 참조하십시오.
4.4.4. 베어 메탈이 아닌 에이전트 시스템에서 호스트 클러스터 생성 확인 링크 복사링크가 클립보드에 복사되었습니다!
배포 프로세스가 완료되면 호스트 클러스터가 성공적으로 생성되었는지 확인할 수 있습니다. 호스팅된 클러스터를 생성한 후 몇 분 후에 다음 단계를 수행합니다.
프로세스
다음 명령을 입력하여 새 호스팅 클러스터의
kubeconfig파일을 가져옵니다.oc extract -n <hosted_cluster_namespace> \ secret/<hosted_cluster_name>-admin-kubeconfig --to=- \ > kubeconfig-<hosted_cluster_name>
$ oc extract -n <hosted_cluster_namespace> \ secret/<hosted_cluster_name>-admin-kubeconfig --to=- \ > kubeconfig-<hosted_cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow kubeconfig파일을 사용하여 호스팅된 클러스터의 클러스터 Operator를 확인합니다. 다음 명령을 실행합니다.oc get co --kubeconfig=kubeconfig-<hosted_cluster_name>
$ oc get co --kubeconfig=kubeconfig-<hosted_cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE console 4.10.26 True False False 2m38s csi-snapshot-controller 4.10.26 True False False 4m3s dns 4.10.26 True False False 2m52s
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE console 4.10.26 True False False 2m38s csi-snapshot-controller 4.10.26 True False False 4m3s dns 4.10.26 True False False 2m52sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 호스팅 클러스터에서 실행 중인 Pod를 확인합니다.
oc get pods -A --kubeconfig=kubeconfig-<hosted_cluster_name>
$ oc get pods -A --kubeconfig=kubeconfig-<hosted_cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAMESPACE NAME READY STATUS RESTARTS AGE kube-system konnectivity-agent-khlqv 0/1 Running 0 3m52s openshift-cluster-samples-operator cluster-samples-operator-6b5bcb9dff-kpnbc 2/2 Running 0 20m openshift-monitoring alertmanager-main-0 6/6 Running 0 100s openshift-monitoring openshift-state-metrics-677b9fb74f-qqp6g 3/3 Running 0 104s
NAMESPACE NAME READY STATUS RESTARTS AGE kube-system konnectivity-agent-khlqv 0/1 Running 0 3m52s openshift-cluster-samples-operator cluster-samples-operator-6b5bcb9dff-kpnbc 2/2 Running 0 20m openshift-monitoring alertmanager-main-0 6/6 Running 0 100s openshift-monitoring openshift-state-metrics-677b9fb74f-qqp6g 3/3 Running 0 104sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4.5. 호스트된 클러스터에서 사용자 정의 API 서버 인증서 구성 링크 복사링크가 클립보드에 복사되었습니다!
API 서버의 사용자 정의 인증서를 구성하려면 HostedCluster 구성의 spec.configuration.apiServer 섹션에 인증서 세부 정보를 지정합니다.
day-1 또는 day-2 작업 중에 사용자 정의 인증서를 구성할 수 있습니다. 그러나 호스트 클러스터 생성 중에 서비스 게시 전략은 변경할 수 없으므로 구성하려는 Kubernetes API 서버의 호스트 이름이 무엇인지 알아야 합니다.
사전 요구 사항
관리 클러스터에 사용자 정의 인증서가 포함된 Kubernetes 시크릿을 생성했습니다. 보안에는 다음 키가 포함되어 있습니다.
-
TLS.crt: 인증서 -
TLS.key: 개인 키
-
-
HostedCluster구성에 로드 밸런서를 사용하는 서비스 게시 전략이 포함된 경우 인증서의 SAN(주체 대체 이름)이 내부 API 끝점(api-int)과 충돌하지 않는지 확인합니다. 내부 API 끝점은 플랫폼에서 자동으로 생성 및 관리합니다. 사용자 정의 인증서와 내부 API 끝점 모두에서 동일한 호스트 이름을 사용하는 경우 라우팅 충돌이 발생할 수 있습니다. 이 규칙의 유일한 예외는Private또는PublicAndPrivate구성이 있는 공급자로 AWS를 사용하는 경우입니다. 이러한 경우 SAN 충돌은 플랫폼에 의해 관리됩니다. - 인증서는 외부 API 끝점에 유효해야 합니다.
- 인증서의 유효 기간은 클러스터의 예상 라이프 사이클과 일치합니다.
프로세스
다음 명령을 입력하여 사용자 정의 인증서로 보안을 생성합니다.
oc create secret tls sample-hosted-kas-custom-cert \ --cert=path/to/cert.crt \ --key=path/to/key.key \ -n <hosted_cluster_namespace>
$ oc create secret tls sample-hosted-kas-custom-cert \ --cert=path/to/cert.crt \ --key=path/to/key.key \ -n <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예와 같이 사용자 정의 인증서 세부 정보를 사용하여
HostedCluster구성을 업데이트합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여
HostedCluster구성에 변경 사항을 적용합니다.oc apply -f <hosted_cluster_config>.yaml
$ oc apply -f <hosted_cluster_config>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
- API 서버 pod를 확인하여 새 인증서가 마운트되었는지 확인합니다.
- 사용자 정의 도메인 이름을 사용하여 API 서버에 대한 연결을 테스트합니다.
-
브라우저에서 인증서 세부 정보를 확인하거나
openssl과 같은 도구를 사용하여 확인합니다.
4.5. IBM Z에 호스팅된 컨트롤 플레인 배포 링크 복사링크가 클립보드에 복사되었습니다!
관리 클러스터로 작동하도록 클러스터를 구성하여 호스팅되는 컨트롤 플레인을 배포할 수 있습니다. 관리 클러스터는 컨트롤 플레인이 호스팅되는 OpenShift Container Platform 클러스터입니다. 관리 클러스터를 호스팅 클러스터라고도 합니다.
관리 클러스터는 관리 클러스터가 아닙니다. 관리형 클러스터는 hub 클러스터가 관리하는 클러스터입니다. 관리 클러스터는 Kubernetes Operator 2.7에 대해 OpenShift Container Platform 4.17 및 다중 클러스터 엔진부터 지원되는 x86_64 아키텍처 또는 Kubernetes Operator 2.10용 OpenShift Container Platform 4.20 및 멀티 클러스터 엔진부터 지원되는 s390x 아키텍처에서 실행할 수 있습니다.
hypershift 애드온을 사용하여 해당 클러스터에 HyperShift Operator를 배포하여 관리형 클러스터를 관리 클러스터로 변환할 수 있습니다. 그런 다음 호스팅된 클러스터를 생성할 수 있습니다.
다중 클러스터 엔진 Operator는 관리하는 허브 클러스터인 기본 로컬 클러스터 및 hub 클러스터만 관리 클러스터로 지원합니다.
베어 메탈에서 호스팅되는 컨트롤 플레인을 프로비저닝하려면 에이전트 플랫폼을 사용할 수 있습니다. 에이전트 플랫폼은 중앙 인프라 관리 서비스를 사용하여 호스트된 클러스터에 작업자 노드를 추가합니다. 자세한 내용은 "중앙 인프라 관리 서비스 활성화"를 참조하십시오.
각 IBM Z 시스템 호스트는 중앙 인프라 관리에서 제공하는 PXE 또는 ISO 이미지로 시작해야 합니다. 각 호스트가 시작되면 에이전트 프로세스를 실행하여 호스트의 세부 정보를 검색하고 설치를 완료합니다. 에이전트 사용자 정의 리소스는 각 호스트를 나타냅니다.
에이전트 플랫폼을 사용하여 호스팅된 클러스터를 생성하면 HyperShift Operator가 호스팅된 컨트롤 플레인 네임스페이스에 에이전트 클러스터 API 공급자를 설치합니다.
4.5.1. IBM Z에서 호스팅된 컨트롤 플레인을 구성하기 위한 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
- Kubernetes Operator 버전 2.7 이상용 멀티 클러스터 엔진은 OpenShift Container Platform 클러스터에 설치해야 합니다. OpenShift Container Platform OperatorHub에서 다중 클러스터 엔진 Operator를 Operator로 설치할 수 있습니다.
다중 클러스터 엔진 Operator에는 하나 이상의 관리형 OpenShift Container Platform 클러스터가 있어야 합니다.
local-cluster는 multicluster engine Operator 2.7 이상에서 자동으로 가져옵니다.local-cluster에 대한 자세한 내용은 Red Hat Advanced Cluster Management 설명서의 고급 구성 을 참조하십시오. 다음 명령을 실행하여 허브 클러스터의 상태를 확인할 수 있습니다.oc get managedclusters local-cluster
$ oc get managedclusters local-clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow - HyperShift Operator를 실행하려면 작업자 노드가 3개 이상 있는 호스팅 클러스터가 필요합니다.
- 중앙 인프라 관리 서비스를 활성화해야 합니다. 자세한 내용은 중앙 인프라 관리 서비스 활성화를 참조하십시오.
- 호스팅된 컨트롤 플레인 명령줄 인터페이스를 설치해야 합니다. 자세한 내용은 호스팅된 컨트롤 플레인 명령줄 인터페이스 설치를 참조하십시오.
관리 클러스터는 Kubernetes Operator 2.7에 대해 OpenShift Container Platform 4.17 및 다중 클러스터 엔진부터 지원되는 x86_64 아키텍처 또는 Kubernetes Operator 2.10용 OpenShift Container Platform 4.20 및 멀티 클러스터 엔진부터 지원되는 s390x 아키텍처에서 실행할 수 있습니다.
4.5.2. IBM Z 인프라 요구사항 링크 복사링크가 클립보드에 복사되었습니다!
에이전트 플랫폼은 인프라를 생성하지 않지만 인프라를 위해 다음 리소스가 필요합니다.
- 에이전트: 에이전트 는 검색 이미지 또는 PXE 이미지로 부팅되고 OpenShift Container Platform 노드로 프로비저닝할 준비가 된 호스트를 나타냅니다.
- DNS: API 및 Ingress 끝점은 라우팅할 수 있어야 합니다.
호스트된 컨트롤 플레인 기능은 기본적으로 활성화되어 있습니다. 기능을 비활성화하고 수동으로 활성화하거나 기능을 비활성화해야 하는 경우 호스팅된 컨트롤 플레인 기능 활성화 또는 비활성화를 참조하십시오.
4.5.3. IBM Z에서 호스팅된 컨트롤 플레인의 DNS 구성 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 클러스터의 API 서버는 NodePort 서비스로 노출됩니다. API 서버에 연결할 수 있는 대상을 가리키는 api.<hosted_cluster_name>.<base_domain >에 대한 DNS 항목이 있어야 합니다.
DNS 항목은 호스팅된 컨트롤 플레인을 실행하는 관리형 클러스터의 노드 중 하나를 가리키는 레코드만큼 단순할 수 있습니다.
이 항목은 들어오는 트래픽을 Ingress Pod로 리디렉션하기 위해 배포된 로드 밸런서를 가리킬 수도 있습니다.
DNS 구성의 다음 예제를 참조하십시오.
cat /var/named/<example.krnl.es.zone>
$ cat /var/named/<example.krnl.es.zone>
출력 예
- 1
- 레코드는 호스팅된 컨트롤 플레인의 수신 및 송신 트래픽을 처리하는 API 로드 밸런서의 IP 주소를 나타냅니다.
IBM z/VM의 경우 에이전트의 IP 주소에 해당하는 IP 주소를 추가합니다.
compute-0 IN A 1xx.2x.2xx.1yy compute-1 IN A 1xx.2x.2xx.1yy
compute-0 IN A 1xx.2x.2xx.1yy
compute-1 IN A 1xx.2x.2xx.1yy
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매개변수와 도메인의 주소를 추가하고 다음 예와 같이 사용할 인증서를 지정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
kubeAPIServerDNSName매개변수의 값은 유효한 도메인이어야 합니다.
kubeAPIServerDNSName 매개변수를 정의하고 인증서를 지정하면 Control Plane Operator 컨트롤러에서 custom-admin- 라는 kubeconfig 파일을 생성합니다. 여기서 파일이 kubeconfig HostedControlPlane 네임스페이스에 저장됩니다. 인증서 생성은 루트 CA에서 발생하며 HostedControlPlane 네임스페이스는 만료 및 갱신을 관리합니다.
Control Plane Operator는 HostedControlPlane 네임스페이스에서 CustomKubeconfig 라는 새 kubeconfig 파일을 보고합니다. 해당 파일은 kubeAPIServerDNSName 매개변수에서 정의된 새 서버를 사용합니다.
사용자 정의 kubeconfig 파일에 대한 참조는 HostedCluster 오브젝트의 CustomKubeconfig 로 status 매개변수에 있습니다. CustomKubeConfig 매개변수는 선택 사항이며 kubeAPIServerDNSName 매개변수가 비어 있지 않은 경우에만 매개변수를 추가할 수 있습니다. CustomKubeConfig 매개변수를 설정한 후 매개변수는 HostedCluster 네임스페이스에서 < hosted_cluster_name>-custom-admin-kubeconfig 라는 보안 생성을 트리거합니다. 시크릿을 사용하여 HostedCluster API 서버에 액세스할 수 있습니다. 설치 후 작업 중에 CustomKubeConfig 매개변수를 제거하면 모든 관련 보안 및 상태 참조가 삭제됩니다.
사용자 정의 DNS 이름을 정의해도 데이터 플레인에 직접적인 영향을 미치지 않으므로 예상되는 롤아웃이 발생하지 않습니다. HostedControlPlane 네임스페이스는 HyperShift Operator에서 변경 사항을 수신하고 해당 매개변수를 삭제합니다.
HostedCluster 오브젝트의 사양에서 kubeAPIServerDNSName 매개변수를 제거하면 새로 생성된 모든 보안 및 CustomKubeconfig 참조가 클러스터 및 status 매개변수에서 제거됩니다.
4.5.4. IBM Z용 베어 메탈에 호스팅 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
호스트 클러스터를 생성하거나 가져올 수 있습니다. 지원 설치 프로그램이 다중 클러스터 엔진 Operator에 대한 애드온으로 활성화되고 에이전트 플랫폼을 사용하여 호스팅된 클러스터를 생성하는 경우 HyperShift Operator는 호스팅된 컨트롤 플레인 네임스페이스에 에이전트 클러스터 API 공급자를 설치합니다.
4.5.4.1. IBM Z용 베어 메탈에 호스팅 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
베어 메탈 인프라에서 호스팅된 클러스터를 생성하거나 가져올 수 있습니다. 지원 설치 관리자를 다중 클러스터 엔진 Operator에 대한 애드온으로 활성화하고 에이전트 플랫폼을 사용하여 호스팅된 클러스터를 생성한 후 HyperShift Operator는 호스팅된 컨트롤 플레인 네임스페이스에 에이전트 클러스터 API 공급자를 설치합니다. 에이전트 클러스터 API 공급자는 컨트롤 플레인과 컴퓨팅 노드로 구성된 호스팅 클러스터를 호스팅하는 관리 클러스터를 연결합니다.
사전 요구 사항
- 각 호스트 클러스터에는 클러스터 전체 이름이 있어야 합니다. 호스팅된 클러스터 이름은 기존 관리 클러스터와 같을 수 없습니다. 그러지 않으면 다중 클러스터 엔진 Operator가 호스팅된 클러스터를 관리할 수 없습니다.
-
클러스터를 호스팅
클러스터이름으로 사용하지 마십시오. - 다중 클러스터 엔진 Operator 관리 클러스터의 네임스페이스에 호스팅 클러스터를 생성할 수 없습니다.
- 최상의 보안 및 관리 관행을 위해 다른 호스팅 클러스터와 별도로 호스팅 클러스터를 생성합니다.
- 클러스터에 대해 기본 스토리지 클래스가 구성되어 있는지 확인합니다. 그러지 않으면 보류 중인 PVC(영구 볼륨 클레임)가 표시될 수 있습니다.
프로세스
다음 명령을 입력하여 네임스페이스를 생성합니다.
oc create ns <hosted_cluster_namespace>
$ oc create ns <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow &
lt;hosted_cluster_namespace>를 호스팅된 클러스터 네임스페이스의 식별자로 바꿉니다. HyperShift Operator는 네임스페이스를 생성합니다. 베어 메탈 인프라에서 호스팅된 클러스터 생성 프로세스 중에 생성된 Cluster API 공급자 역할에 네임스페이스가 이미 있어야 합니다.다음 명령을 입력하여 호스팅된 클러스터에 대한 구성 파일을 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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
- 호스팅된 컨트롤 플레인 구성 요소의 가용성 정책을 지정합니다. 지원되는 옵션은
SingleReplica및HighlyAvailable입니다. 기본값은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 키의 경로를 지정합니다.
다음 명령을 입력하여 호스팅 클러스터 구성 파일에 변경 사항을 적용합니다.
oc apply -f hosted_cluster_config.yaml
$ oc apply -f hosted_cluster_config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 호스팅된 클러스터, 노드 풀 및 Pod 생성을 확인합니다.
oc get hostedcluster \ <hosted_cluster_name> -n \ <hosted_cluster_namespace> -o \ jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .$ oc get hostedcluster \ <hosted_cluster_name> -n \ <hosted_cluster_namespace> -o \ jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get hostedcluster \ <nodepool_name> -n \ <hosted_cluster_namespace> -o \ jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .$ oc get hostedcluster \ <nodepool_name> -n \ <hosted_cluster_namespace> -o \ jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get pods -n <hosted_control_plane_namespace>
$ oc get pods -n <hosted_control_plane_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
호스트 클러스터가 준비되었는지 확인합니다.
Available: True는 컨트롤 플레인의 준비 상태를 나타냅니다.
4.5.5. IBM Z에서 호스팅된 컨트롤 플레인에 대한 InfraEnv 리소스 생성 링크 복사링크가 클립보드에 복사되었습니다!
InfraEnv 는 PXE 이미지로 부팅되는 호스트가 에이전트로 참여할 수 있는 환경입니다. 이 경우 에이전트는 호스팅된 컨트롤 플레인과 동일한 네임스페이스에 생성됩니다.
프로세스
구성을 포함할 YAML 파일을 생성합니다. 다음 예제를 참조하십시오.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
파일을
infraenv-config.yaml로 저장합니다. 다음 명령을 입력하여 구성을 적용합니다.
oc apply -f infraenv-config.yaml
$ oc apply -f infraenv-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow IBM Z 시스템이 에이전트로 참여할 수 있는 PXE 또는 ISO 이미지(예:
initrd.img,kernel.img또는rootfs.img)를 다운로드하는 URL을 가져오려면 다음 명령을 입력합니다.oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name> -o json
$ oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name> -o jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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 리소스와 동일한 네임스페이스에 등록합니다.
프로세스
다음 명령을 실행합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ISO 부팅의 경우
InfraEnv리소스에서 ISO를 다운로드하고 다음 명령을 실행하여 노드를 부팅합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.5.6.2. IBM Z LPAR을 에이전트로 추가 링크 복사링크가 클립보드에 복사되었습니다!
IBM Z 또는 IBM LinuxONE의 Logical Partition (LPAR)을 호스팅된 컨트롤 플레인에 컴퓨팅 노드로 추가할 수 있습니다.
프로세스
에이전트를 위한 부팅 매개변수 파일을 생성합니다.
매개변수 파일 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
coreos.live.rootfs_url아티팩트의 경우 시작 중인커널및initramfs와 일치하는rootfs아티팩트를 지정합니다. HTTP 및 HTTPS 프로토콜만 지원됩니다.- 2
ip매개변수의 경우 IBM Z 및 IBM LinuxONE에 z/VM으로 클러스터 설치에 설명된 대로 IP 주소를 수동으로 할당합니다.- 3
- DASD 유형 디스크에 설치하는 경우
rd.dasd를 사용하여 RHCOS(Red Hat Enterprise Linux CoreOS)를 설치할 DASD를 지정합니다. FCP 유형 디스크에 설치하려면rd.zfcp=<adapter>,<wwpn>,<lun>을 사용하여 RHCOS를 설치할 FCP 디스크를 지정합니다. - 4
- OSA(Open Systems Adapter) 또는 HiperSockets를 사용할 때 이 매개변수를 지정합니다.
InfraEnv리소스에서.ins및initrd.img.addrsize파일을 다운로드합니다.기본적으로
.ins및initrd.img.addrsize파일의 URL은InfraEnv리소스에서 사용할 수 없습니다. 해당 아티팩트를 가져오려면 URL을 편집해야 합니다.followign 명령을 실행하여
ins-file을 포함하도록 커널 URL 끝점을 업데이트합니다.curl -k -L -o generic.ins "< url for ins-file >"
$ curl -k -L -o generic.ins "< url for ins-file >"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예제 URL
https://…/boot-artifacts/ins-file?arch=s390x&version=4.17.0
https://…/boot-artifacts/ins-file?arch=s390x&version=4.17.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow s390x-:을 포함하도록 initrd URL 끝점을 업데이트합니다.initrd-addrsize예제 URL
https://…./s390x-initrd-addrsize?api_key=<api-key>&arch=s390x&version=4.17.0
https://…./s390x-initrd-addrsize?api_key=<api-key>&arch=s390x&version=4.17.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
initrd,kernel,generic.ins및initrd.img.addrsize매개변수 파일을 파일 서버로 전송합니다. FTP를 사용하여 파일을 전송하고 부팅하는 방법에 대한 자세한 내용은 "LPAR에 설치"를 참조하십시오. - 머신을 시작합니다.
- 클러스터의 다른 모든 시스템에 대해 절차를 반복합니다.
4.5.6.3. IBM z/VM을 에이전트로 추가 링크 복사링크가 클립보드에 복사되었습니다!
z/VM 게스트에 고정 IP를 사용하려면 IP 매개변수가 두 번째 시작 시 지속되도록 z/VM 에이전트에 대한 NMStateConfig 속성을 구성해야 합니다.
InfraEnv 리소스에서 다운로드한 PXE 이미지로 IBM Z 환경을 시작하려면 다음 단계를 완료합니다. 에이전트가 생성되면 호스트는 지원 서비스와 통신하고 관리 클러스터의 InfraEnv 리소스와 동일한 네임스페이스에 등록합니다.
프로세스
매개 변수 파일을 업데이트하여
rootfs_url,network_adaptor및disk_type값을 추가합니다.매개변수 파일 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
coreos.live.rootfs_url아티팩트의 경우 시작 중인커널및initramfs와 일치하는rootfs아티팩트를 지정합니다. HTTP 및 HTTPS 프로토콜만 지원됩니다.- 2
ip매개변수의 경우 IBM Z 및 IBM LinuxONE에 z/VM으로 클러스터 설치에 설명된 대로 IP 주소를 수동으로 할당합니다.- 3
- DASD 유형 디스크에 설치하는 경우
rd.dasd를 사용하여 RHCOS(Red Hat Enterprise Linux CoreOS)를 설치할 DASD를 지정합니다. FCP 유형 디스크에 설치하려면rd.zfcp=<adapter>,<wwpn>,<lun>을 사용하여 RHCOS를 설치할 FCP 디스크를 지정합니다.참고FCP 다중 경로 구성의 경우 대신 두 개의 디스크를 제공합니다.
예
rd.zfcp=<adapter1>,<wwpn1>,<lun1> \ rd.zfcp=<adapter2>,<wwpn2>,<lun2>
rd.zfcp=<adapter1>,<wwpn1>,<lun1> \ rd.zfcp=<adapter2>,<wwpn2>,<lun2>Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 4
- OSA(Open Systems Adapter) 또는 HiperSockets를 사용할 때 이 매개변수를 지정합니다.
다음 명령을 실행하여
initrd, 커널 이미지 및 매개변수 파일을 게스트 VM으로 이동합니다.vmur pun -r -u -N kernel.img $INSTALLERKERNELLOCATION/<image name>
vmur pun -r -u -N kernel.img $INSTALLERKERNELLOCATION/<image name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow vmur pun -r -u -N generic.parm $PARMFILELOCATION/paramfilename
vmur pun -r -u -N generic.parm $PARMFILELOCATION/paramfilenameCopy to Clipboard Copied! Toggle word wrap Toggle overflow vmur pun -r -u -N initrd.img $INSTALLERINITRAMFSLOCATION/<image name>
vmur pun -r -u -N initrd.img $INSTALLERINITRAMFSLOCATION/<image name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 게스트 VM 콘솔에서 다음 명령을 실행합니다.
cp ipl c
cp ipl cCopy to Clipboard Copied! Toggle word wrap Toggle overflow 에이전트 및 해당 속성을 나열하려면 다음 명령을 입력합니다.
oc -n <hosted_control_plane_namespace> get agents
$ oc -n <hosted_control_plane_namespace> get agentsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CLUSTER APPROVED ROLE STAGE 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d auto-assign 5e498cd3-542c-e54f-0c58-ed43e28b568a auto-assign
NAME CLUSTER APPROVED ROLE STAGE 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d auto-assign 5e498cd3-542c-e54f-0c58-ed43e28b568a auto-assignCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 에이전트를 승인합니다.
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"}}' \ --type merge$ 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 mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 선택적으로 사양에 에이전트 ID <
installation_disk_id> 및 <hostname>을 설정할 수 있습니다.
다음 명령을 실행하여 에이전트가 승인되었는지 확인합니다.
oc -n <hosted_control_plane_namespace> get agents
$ oc -n <hosted_control_plane_namespace> get agentsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CLUSTER APPROVED ROLE STAGE 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d true auto-assign 5e498cd3-542c-e54f-0c58-ed43e28b568a true auto-assign
NAME CLUSTER APPROVED ROLE STAGE 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d true auto-assign 5e498cd3-542c-e54f-0c58-ed43e28b568a true auto-assignCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.5.7. IBM Z에서 호스팅된 클러스터의 NodePool 오브젝트 확장 링크 복사링크가 클립보드에 복사되었습니다!
NodePool 오브젝트는 호스팅된 클러스터를 생성할 때 생성됩니다. NodePool 오브젝트를 스케일링하면 호스팅된 컨트롤 플레인에 더 많은 컴퓨팅 노드를 추가할 수 있습니다.
노드 풀을 확장하면 머신이 생성됩니다. Cluster API 공급자는 승인된 에이전트를 찾고 현재 검증이 사용되지 않으며, 노드 풀 사양에 지정된 요구 사항을 충족합니다. 에이전트의 상태 및 조건을 확인하여 에이전트 설치를 모니터링할 수 있습니다.
프로세스
다음 명령을 실행하여
NodePool오브젝트를 두 개의 노드로 확장합니다.oc -n <clusters_namespace> scale nodepool <nodepool_name> --replicas 2
$ oc -n <clusters_namespace> scale nodepool <nodepool_name> --replicas 2Copy to Clipboard Copied! Toggle word wrap Toggle overflow Cluster API 에이전트 공급자는 호스트 클러스터에 할당된 두 개의 에이전트를 임의로 선택합니다. 이러한 에이전트는 다른 상태를 통과하고 마지막으로 호스팅된 클러스터에 OpenShift Container Platform 노드로 참여합니다. 에이전트는 다음 순서로 전환 단계를 통과합니다.
-
바인딩 -
검색 -
충분하지 않음 -
설치 -
installing-in-progress -
added-to-existing-cluster
-
다음 명령을 실행하여 특정 확장 에이전트의 상태를 확인합니다.
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}'$ 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 Copied! Toggle word wrap Toggle overflow 출력 예
BMH: Agent: 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d State: known-unbound BMH: Agent: 5e498cd3-542c-e54f-0c58-ed43e28b568a State: insufficient
BMH: Agent: 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d State: known-unbound BMH: Agent: 5e498cd3-542c-e54f-0c58-ed43e28b568a State: insufficientCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 전환 단계를 확인합니다.
oc -n <hosted_control_plane_namespace> get agent
$ oc -n <hosted_control_plane_namespace> get agentCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
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
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-assignCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 호스팅된 클러스터에 액세스할
kubeconfig파일을 생성합니다.hcp create kubeconfig \ --namespace <clusters_namespace> \ --name <hosted_cluster_namespace> > <hosted_cluster_name>.kubeconfig
$ hcp create kubeconfig \ --namespace <clusters_namespace> \ --name <hosted_cluster_namespace> > <hosted_cluster_name>.kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 에이전트가
add-to-existing-cluster상태에 도달한 후 다음 명령을 입력하여 OpenShift Container Platform 노드를 볼 수 있는지 확인합니다.oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
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
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+3882f8fCopy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터 Operator는 노드에 워크로드를 추가하여 조정하기 시작합니다.
다음 명령을 입력하여
NodePool오브젝트를 확장할 때 두 개의 머신이 생성되었는지 확인합니다.oc -n <hosted_control_plane_namespace> get machine.cluster.x-k8s.io
$ oc -n <hosted_control_plane_namespace> get machine.cluster.x-k8s.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
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
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.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 클러스터 버전을 확인합니다.
oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,coCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
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
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.2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 클러스터 Operator 상태를 확인합니다.
oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusteroperators
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusteroperatorsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
클러스터의 각 구성 요소에 대해 출력에는 NAME,VERSION,AVAILABLE,PROGRESSING,DEGRADED,SINCE, MESSAGE.
출력 예제는 Initial Operator 설정을 참조하십시오.
4.6. IBM Power에 호스팅된 컨트롤 플레인 배포 링크 복사링크가 클립보드에 복사되었습니다!
호스팅 클러스터로 작동하도록 클러스터를 구성하여 호스팅 컨트롤 플레인을 배포할 수 있습니다. 이 구성은 많은 클러스터를 관리하기 위한 효율적이고 확장 가능한 솔루션을 제공합니다. 호스팅 클러스터는 컨트롤 플레인을 호스팅하는 OpenShift Container Platform 클러스터입니다. 호스팅 클러스터를 관리 클러스터라고도 합니다.
관리 클러스터는 관리 클러스터가 아닙니다. 관리형 클러스터는 hub 클러스터가 관리하는 클러스터입니다.
다중 클러스터 엔진 Operator는 관리 허브 클러스터인 기본 로컬 클러스터와 허브 클러스터를 호스팅 클러스터로만 지원합니다.
베어 메탈 인프라에서 호스팅되는 컨트롤 플레인을 프로비저닝하려면 에이전트 플랫폼을 사용할 수 있습니다. 에이전트 플랫폼은 중앙 인프라 관리 서비스를 사용하여 호스팅된 클러스터에 컴퓨팅 노드를 추가합니다. 자세한 내용은 "중앙 인프라 관리 서비스 활성화"를 참조하십시오.
중앙 인프라 관리에서 제공하는 검색 이미지를 사용하여 각 IBM Power 호스트를 시작해야 합니다. 각 호스트가 시작되면 에이전트 프로세스를 실행하여 호스트의 세부 정보를 검색하고 설치를 완료합니다. 에이전트 사용자 정의 리소스는 각 호스트를 나타냅니다.
에이전트 플랫폼으로 호스팅된 클러스터를 생성하면 HyperShift가 호스팅된 컨트롤 플레인 네임스페이스에 에이전트 클러스터 API 공급자를 설치합니다.
4.6.1. IBM Power에서 호스팅된 컨트롤 플레인을 구성하기 위한 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
- Kubernetes Operator 버전 2.7 이상용 멀티 클러스터 엔진은 OpenShift Container Platform 클러스터에 설치됩니다. RHACM(Red Hat Advanced Cluster Management)을 설치할 때 multicluster engine Operator가 자동으로 설치됩니다. OpenShift Container Platform 소프트웨어 카탈로그에서 RHACM 없이 다중 클러스터 엔진 Operator를 Operator로 설치할 수도 있습니다.
다중 클러스터 엔진 Operator에는 하나 이상의 관리형 OpenShift Container Platform 클러스터가 있어야 합니다.
로컬 클러스터관리 허브 클러스터는 다중 클러스터 엔진 Operator 버전 2.7 이상에서 자동으로 가져옵니다.local-cluster에 대한 자세한 내용은 RHACM 설명서의 고급 구성 을 참조하십시오. 다음 명령을 실행하여 허브 클러스터의 상태를 확인할 수 있습니다.oc get managedclusters local-cluster
$ oc get managedclusters local-clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow - HyperShift Operator를 실행하려면 컴퓨팅 노드가 3개 이상 있는 호스팅 클러스터가 필요합니다.
- 중앙 인프라 관리 서비스를 활성화해야 합니다. 자세한 내용은 "중앙 인프라 관리 서비스 활성화"를 참조하십시오.
- 호스팅된 컨트롤 플레인 명령줄 인터페이스를 설치해야 합니다. 자세한 내용은 "호스트된 컨트롤 플레인 명령줄 인터페이스 설치"를 참조하십시오.
호스트된 컨트롤 플레인 기능은 기본적으로 활성화되어 있습니다. 기능을 비활성화하고 수동으로 기능을 활성화하려면 "호스트된 컨트롤 플레인 기능 수동 활성화"를 참조하십시오. 기능을 비활성화해야 하는 경우 "호스트된 컨트롤 플레인 기능 비활성화"를 참조하십시오.
4.6.2. IBM Power 인프라 요구사항 링크 복사링크가 클립보드에 복사되었습니다!
에이전트 플랫폼은 인프라를 생성하지 않지만 인프라를 위해 다음 리소스가 필요합니다.
- 에이전트: 에이전트 는 검색 이미지로 부팅되고 OpenShift Container Platform 노드로 프로비저닝할 수 있는 호스트를 나타냅니다.
- DNS: API 및 Ingress 끝점은 라우팅할 수 있어야 합니다.
4.6.3. IBM Power에서 호스팅된 컨트롤 플레인에 대한 DNS 구성 링크 복사링크가 클립보드에 복사되었습니다!
네트워크 외부의 클라이언트는 호스팅된 클러스터의 API 서버에 액세스할 수 있습니다. API 서버에 연결할 수 있는 대상을 가리키는 api.<hosted_cluster_name>.<basedomain > 항목에 대한 DNS 항목이 있어야 합니다.
DNS 항목은 호스팅된 컨트롤 플레인을 실행하는 관리 클러스터의 노드 중 하나를 가리키는 레코드만큼 단순할 수 있습니다.
이 항목은 배포된 로드 밸런서를 가리키며 들어오는 트래픽을 인그레스 포드로 리디렉션할 수도 있습니다.
DNS 구성의 다음 예제를 참조하십시오.
cat /var/named/<example.krnl.es.zone>
$ cat /var/named/<example.krnl.es.zone>
출력 예
- 1
- 레코드는 호스팅된 컨트롤 플레인의 수신 및 송신 트래픽을 처리하는 API 로드 밸런서의 IP 주소를 나타냅니다.
IBM Power의 경우 에이전트의 IP 주소에 해당하는 IP 주소를 추가합니다.
설정 예
compute-0 IN A 1xx.2x.2xx.1yy compute-1 IN A 1xx.2x.2xx.1yy
compute-0 IN A 1xx.2x.2xx.1yy
compute-1 IN A 1xx.2x.2xx.1yy
4.6.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매개변수와 도메인의 주소를 추가하고 다음 예와 같이 사용할 인증서를 지정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
kubeAPIServerDNSName매개변수의 값은 유효한 도메인이어야 합니다.
kubeAPIServerDNSName 매개변수를 정의하고 인증서를 지정하면 Control Plane Operator 컨트롤러에서 custom-admin- 라는 kubeconfig 파일을 생성합니다. 여기서 파일이 kubeconfig HostedControlPlane 네임스페이스에 저장됩니다. 인증서 생성은 루트 CA에서 발생하며 HostedControlPlane 네임스페이스는 만료 및 갱신을 관리합니다.
Control Plane Operator는 HostedControlPlane 네임스페이스에서 CustomKubeconfig 라는 새 kubeconfig 파일을 보고합니다. 해당 파일은 kubeAPIServerDNSName 매개변수에서 정의된 새 서버를 사용합니다.
사용자 정의 kubeconfig 파일에 대한 참조는 HostedCluster 오브젝트의 CustomKubeconfig 로 status 매개변수에 있습니다. CustomKubeConfig 매개변수는 선택 사항이며 kubeAPIServerDNSName 매개변수가 비어 있지 않은 경우에만 매개변수를 추가할 수 있습니다. CustomKubeConfig 매개변수를 설정한 후 매개변수는 HostedCluster 네임스페이스에서 < hosted_cluster_name>-custom-admin-kubeconfig 라는 보안 생성을 트리거합니다. 시크릿을 사용하여 HostedCluster API 서버에 액세스할 수 있습니다. 설치 후 작업 중에 CustomKubeConfig 매개변수를 제거하면 모든 관련 보안 및 상태 참조가 삭제됩니다.
사용자 정의 DNS 이름을 정의해도 데이터 플레인에 직접적인 영향을 미치지 않으므로 예상되는 롤아웃이 발생하지 않습니다. HostedControlPlane 네임스페이스는 HyperShift Operator에서 변경 사항을 수신하고 해당 매개변수를 삭제합니다.
HostedCluster 오브젝트의 사양에서 kubeAPIServerDNSName 매개변수를 제거하면 새로 생성된 모든 보안 및 CustomKubeconfig 참조가 클러스터 및 status 매개변수에서 제거됩니다.
4.6.4. CLI를 사용하여 호스트된 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
베어 메탈 인프라에서 호스팅된 클러스터를 생성하거나 가져올 수 있습니다. 지원 설치 관리자를 다중 클러스터 엔진 Operator에 대한 애드온으로 활성화하고 에이전트 플랫폼을 사용하여 호스팅된 클러스터를 생성한 후 HyperShift Operator는 호스팅된 컨트롤 플레인 네임스페이스에 에이전트 클러스터 API 공급자를 설치합니다. 에이전트 클러스터 API 공급자는 컨트롤 플레인과 컴퓨팅 노드로 구성된 호스팅 클러스터를 호스팅하는 관리 클러스터를 연결합니다.
사전 요구 사항
- 각 호스트 클러스터에는 클러스터 전체 이름이 있어야 합니다. 호스팅된 클러스터 이름은 기존 관리 클러스터와 같을 수 없습니다. 그러지 않으면 다중 클러스터 엔진 Operator가 호스팅된 클러스터를 관리할 수 없습니다.
-
클러스터를 호스팅
클러스터이름으로 사용하지 마십시오. - 다중 클러스터 엔진 Operator 관리 클러스터의 네임스페이스에 호스팅 클러스터를 생성할 수 없습니다.
- 최상의 보안 및 관리 관행을 위해 다른 호스팅 클러스터와 별도로 호스팅 클러스터를 생성합니다.
- 클러스터에 대해 기본 스토리지 클래스가 구성되어 있는지 확인합니다. 그러지 않으면 보류 중인 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
$ oc label node [compute-node-1] topology.kubernetes.io/zone=zone1Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc label node [compute-node-2] topology.kubernetes.io/zone=zone2
$ oc label node [compute-node-2] topology.kubernetes.io/zone=zone2Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc label node [compute-node-3] topology.kubernetes.io/zone=zone3
$ oc label node [compute-node-3] topology.kubernetes.io/zone=zone3Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 하드웨어 인벤토리에 베어 메탈 노드를 추가해야 합니다.
프로세스
다음 명령을 입력하여 네임스페이스를 생성합니다.
oc create ns <hosted_cluster_namespace>
$ oc create ns <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow &
lt;hosted_cluster_namespace>를 호스팅된 클러스터 네임스페이스의 식별자로 바꿉니다. HyperShift Operator는 네임스페이스를 생성합니다. 베어 메탈 인프라에서 호스팅된 클러스터 생성 프로세스 중에 생성된 Cluster API 공급자 역할에 네임스페이스가 이미 있어야 합니다.다음 명령을 입력하여 호스팅된 클러스터에 대한 구성 파일을 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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
- 호스팅된 컨트롤 플레인 구성 요소의 가용성 정책을 지정합니다. 지원되는 옵션은
SingleReplica및HighlyAvailable입니다. 기본값은HighlyAvailable입니다. - 10
- 사용하려는 지원되는 OpenShift Container Platform 버전 (예:
4.20.0-multi)을 지정합니다. 연결이 끊긴 환경을 사용하는 경우 <ocp_release_image>를 다이제스트 이미지로 교체합니다. OpenShift Container Platform 릴리스 이미지 다이제스트를 추출하려면 OpenShift Container Platform 릴리스 이미지 다이제스트 추출을 참조하십시오. - 11
3과 같은 노드 풀 복제본 수를 지정합니다. 동일한 수의 복제본을 생성하려면 복제본 수를0이상으로 지정해야 합니다. 그렇지 않으면 노드 풀을 생성하지 않습니다.- 12
--ssh-key플래그 후user/.ssh/id_rsa와 같은 SSH 키의 경로를 지정합니다.
서비스 게시 전략을 구성합니다. 노드 포트는 추가 인프라 없이 항상 사용할 수 있으므로 호스트된 클러스터는
NodePort서비스 게시 전략을 사용합니다. 그러나 로드 밸런서를 사용하도록 서비스 게시 전략을 구성할 수 있습니다.-
기본
NodePort전략을 사용하는 경우 관리 클러스터 노드가 아닌 호스팅 클러스터 컴퓨팅 노드를 가리키도록 DNS를 구성합니다. 자세한 내용은 " bare metal의 DNS 구성"을 참조하십시오. 프로덕션 환경의 경우 이 전략이 인증서 처리 및 자동 DNS 확인을 제공하므로
LoadBalancer전략을 사용합니다. 다음 예제에서는 호스팅된 클러스터 구성 파일에서LoadBalancer전략을 변경하는 방법을 보여줍니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
LoadBalancer를 API 서버 유형으로 지정합니다. 기타 모든 서비스에 대해Route를 유형으로 지정합니다.
-
기본
다음 명령을 입력하여 호스팅 클러스터 구성 파일에 변경 사항을 적용합니다.
oc apply -f hosted_cluster_config.yaml
$ oc apply -f hosted_cluster_config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 호스팅된 클러스터, 노드 풀 및 Pod 생성을 확인합니다.
oc get hostedcluster \ <hosted_cluster_namespace> -n \ <hosted_cluster_namespace> -o \ jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .$ oc get hostedcluster \ <hosted_cluster_namespace> -n \ <hosted_cluster_namespace> -o \ jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get nodepool \ <hosted_cluster_namespace> -n \ <hosted_cluster_namespace> -o \ jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .$ oc get nodepool \ <hosted_cluster_namespace> -n \ <hosted_cluster_namespace> -o \ jsonpath='{.status.conditions[?(@.status=="False")]}' | jq .Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get pods -n <hosted_cluster_namespace>
$ oc get pods -n <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
호스트 클러스터가 준비되었는지 확인합니다.
Available: True는 클러스터의 준비 상태를 나타내며 노드 풀 상태에AllMachinesReady: True가 표시됩니다. 이러한 상태는 모든 클러스터 Operator의 상태를 나타냅니다. 호스팅된 클러스터에 MetalLB를 설치합니다.
호스트 클러스터에서
kubeconfig파일을 추출하고 다음 명령을 입력하여 호스팅된 클러스터 액세스의 환경 변수를 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow export KUBECONFIG="/path/to/kubeconfig-<hosted_cluster_namespace>.yaml"
$ export KUBECONFIG="/path/to/kubeconfig-<hosted_cluster_namespace>.yaml"Copy to Clipboard Copied! Toggle word wrap Toggle overflow install-metallb-operator.yaml파일을 생성하여 MetalLB Operator를 설치합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 파일을 적용합니다.
oc apply -f install-metallb-operator.yaml
$ oc apply -f install-metallb-operator.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow deploy-metallb-ipaddresspool.yaml파일을 생성하여 MetalLB IP 주소 풀을 구성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 구성을 적용합니다.
oc apply -f deploy-metallb-ipaddresspool.yaml
$ oc apply -f deploy-metallb-ipaddresspool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 Operator 상태, IP 주소 풀,
L2Advertisement리소스를 확인하여 MetalLB의 설치를 확인합니다.oc get pods -n metallb-system
$ oc get pods -n metallb-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc get ipaddresspool -n metallb-system
$ oc get ipaddresspool -n metallb-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc get l2advertisement -n metallb-system
$ oc get l2advertisement -n metallb-systemCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Ingress에 대한 로드 밸런서를 구성합니다.
ingress-loadbalancer.yaml파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 구성을 적용합니다.
oc apply -f ingress-loadbalancer.yaml
$ oc apply -f ingress-loadbalancer.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 로드 밸런서 서비스가 예상대로 작동하는지 확인합니다.
oc get svc metallb-ingress -n openshift-ingress
$ oc get svc metallb-ingress -n openshift-ingressCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
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
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 16hCopy to Clipboard Copied! Toggle word wrap Toggle overflow
로드 밸런서에서 작동하도록 DNS를 구성합니다.
-
로드 밸런서 IP 주소에
*.> 와일드카드 DNS 레코드를 가리켜 apps 도메인의 DNS를 구성합니다.apps.<hosted_cluster_namespace>.<base_domain 다음 명령을 입력하여 DNS 확인을 확인합니다.
nslookup console-openshift-console.apps.<hosted_cluster_namespace>.<base_domain> <load_balancer_ip_address>
$ nslookup console-openshift-console.apps.<hosted_cluster_namespace>.<base_domain> <load_balancer_ip_address>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
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
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.71Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
로드 밸런서 IP 주소에
검증
다음 명령을 입력하여 클러스터 Operator를 확인합니다.
oc get clusteroperators
$ oc get clusteroperatorsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 모든 Operator에
AVAILABLE: True,PROGRESSING: False,DEGRADED: False가 표시되는지 확인합니다.다음 명령을 입력하여 노드를 확인합니다.
oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 각 노드에
READY상태가 있는지 확인합니다.웹 브라우저에 다음 URL을 입력하여 콘솔에 대한 액세스를 테스트합니다.
https://console-openshift-console.apps.<hosted_cluster_namespace>.<base_domain>
https://console-openshift-console.apps.<hosted_cluster_namespace>.<base_domain>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.6.5. 에이전트 호스트 클러스터에서 이기종 노드 풀 생성 정보 링크 복사링크가 클립보드에 복사되었습니다!
노드 풀은 동일한 구성을 공유하는 클러스터 내의 노드 그룹입니다. 이기종 노드 풀은 다양한 구성을 통해 풀을 생성하고 다양한 워크로드에 맞게 최적화할 수 있습니다.
에이전트 플랫폼에서 이기종 노드 풀을 생성할 수 있습니다. 이 플랫폼을 사용하면 클러스터에서 단일 호스트 클러스터 내에서 x86_64 또는 ppc64le 과 같은 다양한 머신 유형을 실행할 수 있습니다.
이기종 노드 풀을 생성하려면 다음 일반 단계를 완료해야 합니다.
-
AgentServiceConfigCR(사용자 정의 리소스)을 생성하여 Operator에 데이터베이스 및 파일 시스템과 같은 구성 요소에 필요한 스토리지 양을 알려줍니다. CR은 지원할 OpenShift Container Platform 버전도 정의합니다. - 에이전트 클러스터를 생성합니다.
- 이기종 노드 풀을 생성합니다.
- 호스팅된 컨트롤 플레인의 DNS 구성
-
각 아키텍처에 대한
InfraEnvCR(사용자 정의 리소스)을 생성합니다. - 이기종 클러스터에 에이전트를 추가합니다.
4.6.5.1. AgentServiceConfig 사용자 지정 리소스 생성 링크 복사링크가 클립보드에 복사되었습니다!
에이전트 호스트 클러스터에서 이기종 노드 풀을 생성하려면 두 가지 이기종 아키텍처 운영 체제(OS) 이미지로 AgentServiceConfig CR을 생성해야 합니다.
프로세스
다음 명령을 실행합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Kubernetes Operator
agentserviceconfig구성에 대한 다중 클러스터 엔진, 데이터베이스 볼륨 이름을 지정합니다. - 2
- 다중 클러스터 엔진 Operator
agentserviceconfig구성, 파일 시스템 볼륨 이름을 지정합니다. - 3
- 현재 OpenShift Container Platform 버전을 지정합니다.
- 4
- x86의 현재 OpenShift Container Platform 릴리스 버전을 지정합니다.
- 5
- x86의 ISO URL을 지정합니다.
- 6
- x86의 루트 파일 시스템 URL을 지정합니다.
- 7
- x86의 CPU 아키텍처를 지정합니다.
- 8
- 현재 OpenShift Container Platform 버전을 지정합니다.
- 9
ppc64le의 OpenShift Container Platform 릴리스 버전을 지정합니다.- 10
ppc64le의 ISO URL을 지정합니다.- 11
ppc64le의 루트 파일 시스템 URL을 지정합니다.- 12
ppc64le의 CPU 아키텍처를 지정합니다.
4.6.5.2. 에이전트 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
에이전트 기반 접근 방식은 에이전트 클러스터를 관리하고 프로비저닝합니다. 에이전트 클러스터는 이기종 노드 풀을 사용하여 동일한 클러스터 내에서 다양한 유형의 컴퓨팅 노드를 사용할 수 있습니다.
사전 요구 사항
- 호스트된 클러스터를 생성할 때 이기종 노드 풀을 지원할 수 있도록 다중 아키텍처 릴리스 이미지를 사용했습니다. Multi-arch 릴리스 이미지 페이지에서 최신 다중 아키텍처 이미지를 찾습니다.
프로세스
다음 명령을 실행하여 클러스터 네임스페이스의 환경 변수를 생성합니다.
export CLUSTERS_NAMESPACE=<hosted_cluster_namespace>
$ export CLUSTERS_NAMESPACE=<hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 시스템 클래스리스 도메인 간 라우팅(CIDR) 표기법에 대한 환경 변수를 생성합니다.
export MACHINE_CIDR=192.168.122.0/24
$ export MACHINE_CIDR=192.168.122.0/24Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 호스팅된 제어 네임스페이스를 생성합니다.
oc create ns <hosted_control_plane_namespace>
$ oc create ns <hosted_control_plane_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 클러스터를 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.6.5.3. 이기종 노드 풀 생성 링크 복사링크가 클립보드에 복사되었습니다!
NodePool CR(사용자 정의 리소스)을 사용하여 이기종 노드 풀을 생성하여 다른 워크로드를 특정 하드웨어와 연결하여 비용 및 성능을 최적화할 수 있습니다.
프로세스
NodePoolCR을 정의하려면 다음 예와 유사한 YAML 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- selector 블록은 지정된 라벨과 일치하는 에이전트를 선택합니다. 복제본이 0인 아키텍처
ppc64le의 노드 풀을 생성하려면ppc64le을 지정합니다. 이렇게 하면 선택기 블록이 확장 작업 중에ppc64le아키텍처에서 에이전트만 선택합니다.
4.6.5.4. 호스트된 컨트롤 플레인의 DNS 구성 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 컨트롤 플레인의 DNS(Domain Name Service) 구성은 클라이언트가 내부 구성 요소로 트래픽을 라우팅할 수 있도록 외부 클라이언트가 Ingress 컨트롤러에 도달할 수 있음을 의미합니다. 이 설정을 구성하면 트래픽이 ppc64le 또는 x86_64 컴퓨팅 노드로 라우팅됩니다.
수신 애플리케이션을 호스팅하는 컴퓨팅 노드 중 하나에 *.apps.<cluster_name > 레코드를 가리킬 수 있습니다. 또는 컴퓨팅 노드 상단에 로드 밸런서를 설정할 수 있는 경우 이 로드 밸런서에 레코드를 지정합니다. 이기종 노드 풀을 생성할 때 컴퓨팅 노드가 서로 도달하거나 동일한 네트워크에 유지할 수 있는지 확인합니다.
4.6.5.5. 인프라 환경 리소스 생성 링크 복사링크가 클립보드에 복사되었습니다!
이기종 노드 풀의 경우 각 아키텍처에 대해 infraEnv CR(사용자 정의 리소스)을 생성해야 합니다. 이 구성을 사용하면 노드 프로비저닝 프로세스 중에 올바른 아키텍처별 운영 체제 및 부팅 아티팩트를 사용할 수 있습니다. 예를 들어 x86_64 및 ppc64le 아키텍처가 있는 노드 풀의 경우 x86_64 및 ppc64le 에 대한 InfraEnv CR을 생성합니다.
절차를 시작하기 전에 x86_64 및 ppc64le 아키텍처의 운영 체제 이미지를 AgentServiceConfig 리소스에 추가합니다. 이 후 InfraEnv 리소스를 사용하여 최소 ISO 이미지를 가져올 수 있습니다.
프로세스
다음 명령을 실행하여 이기종 노드 풀용
x86_64아키텍처를 사용하여InfraEnv리소스를 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 이기종 노드 풀에 대한
ppc64le아키텍처를 사용하여InfraEnv리소스를 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
InfraEnv리소스가 성공적으로 생성되었는지 확인합니다.x86_64InfraEnv리소스가 성공적으로 생성되었는지 확인합니다.oc describe InfraEnv <hosted_cluster_name>-<arch_x86>
$ oc describe InfraEnv <hosted_cluster_name>-<arch_x86>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ppc64leInfraEnv리소스가 성공적으로 생성되었는지 확인합니다.oc describe InfraEnv <hosted_cluster_name>-<arch_ppc64le>
$ oc describe InfraEnv <hosted_cluster_name>-<arch_ppc64le>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 명령을 실행하여 가상 머신 또는 베어 메탈 머신이 에이전트로 결합할 수 있는 라이브 ISO를 생성합니다.
x86_64용 라이브 ISO를 생성합니다.oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name>-<arch_x86> -ojsonpath="{.status.isoDownloadURL}"$ oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name>-<arch_x86> -ojsonpath="{.status.isoDownloadURL}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow ppc64le의 라이브 ISO를 생성합니다.oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name>-<arch_ppc64le> -ojsonpath="{.status.isoDownloadURL}"$ oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name>-<arch_ppc64le> -ojsonpath="{.status.isoDownloadURL}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.6.5.6. 이기종 클러스터에 에이전트 추가 링크 복사링크가 클립보드에 복사되었습니다!
라이브 ISO로 부팅하도록 시스템을 수동으로 구성하여 에이전트를 추가합니다. 라이브 ISO를 다운로드하여 베어 메탈 노드 또는 가상 머신을 부팅하는 데 사용할 수 있습니다. 부팅 시 노드는 assisted-service 와 통신하고 InfraEnv 리소스와 동일한 네임스페이스에 에이전트로 등록합니다. 각 에이전트를 생성한 후 사양에 installation_disk_id 및 hostname 매개변수를 선택적으로 설정할 수 있습니다. 그런 다음 에이전트를 승인하여 에이전트를 사용할 준비가 되었다고 표시할 수 있습니다.
프로세스
다음 명령을 실행하여 에이전트 목록을 가져옵니다.
oc -n <hosted_control_plane_namespace> get agents
$ oc -n <hosted_control_plane_namespace> get agentsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CLUSTER APPROVED ROLE STAGE 86f7ac75-4fc4-4b36-8130-40fa12602218 auto-assign e57a637f-745b-496e-971d-1abbf03341ba auto-assign
NAME CLUSTER APPROVED ROLE STAGE 86f7ac75-4fc4-4b36-8130-40fa12602218 auto-assign e57a637f-745b-496e-971d-1abbf03341ba auto-assignCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 에이전트를 패치합니다.
oc -n <hosted_control_plane_namespace> patch agent 86f7ac75-4fc4-4b36-8130-40fa12602218 -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-0.example.krnl.es"}}' --type merge$ oc -n <hosted_control_plane_namespace> patch agent 86f7ac75-4fc4-4b36-8130-40fa12602218 -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-0.example.krnl.es"}}' --type mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 두 번째 에이전트를 패치합니다.
oc -n <hosted_control_plane_namespace> patch agent 23d0c614-2caa-43f5-b7d3-0b3564688baa -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-1.example.krnl.es"}}' --type merge$ oc -n <hosted_control_plane_namespace> patch agent 23d0c614-2caa-43f5-b7d3-0b3564688baa -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-1.example.krnl.es"}}' --type mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 에이전트 승인 상태를 확인합니다.
oc -n <hosted_control_plane_namespace> get agents
$ oc -n <hosted_control_plane_namespace> get agentsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CLUSTER APPROVED ROLE STAGE 86f7ac75-4fc4-4b36-8130-40fa12602218 true auto-assign e57a637f-745b-496e-971d-1abbf03341ba true auto-assign
NAME CLUSTER APPROVED ROLE STAGE 86f7ac75-4fc4-4b36-8130-40fa12602218 true auto-assign e57a637f-745b-496e-971d-1abbf03341ba true auto-assignCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.6.5.7. 노드 풀 확장 링크 복사링크가 클립보드에 복사되었습니다!
에이전트를 승인한 후 노드 풀을 확장할 수 있습니다. 노드 풀에서 구성한 agentLabelSelector 값은 일치하는 에이전트만 클러스터에 추가되도록 합니다. 또한 노드 풀을 축소하는 데 도움이 됩니다. 클러스터에서 특정 아키텍처 노드를 제거하려면 해당 노드 풀을 축소합니다.
프로세스
다음 명령을 실행하여 노드 풀을 확장합니다.
oc -n <clusters_namespace> scale nodepool <nodepool_name> --replicas 2
$ oc -n <clusters_namespace> scale nodepool <nodepool_name> --replicas 2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고Cluster API 에이전트 공급자는 두 에이전트를 임의로 선택하여 호스팅된 클러스터에 할당합니다. 이러한 에이전트는 다른 상태를 통과한 다음 호스팅된 클러스터에 OpenShift Container Platform 노드로 참여합니다. 다양한 에이전트 상태는
바인딩이며,검색,충분하지 않음,,설치중 , 진행 중추가-기존-클러스터.
검증
다음 명령을 실행하여 에이전트를 나열합니다.
oc -n <hosted_control_plane_namespace> get agent
$ oc -n <hosted_control_plane_namespace> get agentCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CLUSTER APPROVED ROLE STAGE 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 hypercluster1 true auto-assign d9198891-39f4-4930-a679-65fb142b108b true auto-assign da503cf1-a347-44f2-875c-4960ddb04091 hypercluster1 true auto-assign
NAME CLUSTER APPROVED ROLE STAGE 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 hypercluster1 true auto-assign d9198891-39f4-4930-a679-65fb142b108b true auto-assign da503cf1-a347-44f2-875c-4960ddb04091 hypercluster1 true auto-assignCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 특정 확장 에이전트의 상태를 확인합니다.
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}'$ 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 Copied! Toggle word wrap Toggle overflow 출력 예
BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficient
BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficientCopy to Clipboard Copied! Toggle word wrap Toggle overflow 에이전트가
add-to-existing-cluster상태에 도달한 후 다음 명령을 실행하여 OpenShift Container Platform 노드가 준비되었는지 확인합니다.oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME STATUS ROLES AGE VERSION ocp-worker-1 Ready worker 5m41s v1.24.0+3882f8f ocp-worker-2 Ready worker 6m3s v1.24.0+3882f8f
NAME STATUS ROLES AGE VERSION ocp-worker-1 Ready worker 5m41s v1.24.0+3882f8f ocp-worker-2 Ready worker 6m3s v1.24.0+3882f8fCopy to Clipboard Copied! Toggle word wrap Toggle overflow 노드에 워크로드를 추가하면 일부 클러스터 Operator를 조정할 수 있습니다. 다음 명령은 노드 풀을 확장한 후 발생한 두 개의 머신 생성을 표시합니다.
oc -n <hosted_control_plane_namespace> get machines
$ oc -n <hosted_control_plane_namespace> get machinesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CLUSTER NODENAME PROVIDERID PHASE AGE VERSION hypercluster1-c96b6f675-m5vch hypercluster1-b2qhl ocp-worker-1 agent://da503cf1-a347-44f2-875c-4960ddb04091 Running 15m 4.11.5 hypercluster1-c96b6f675-tl42p hypercluster1-b2qhl ocp-worker-2 agent://4dac1ab2-7dd5-4894-a220-6a3473b67ee6 Running 15m 4.11.5
NAME CLUSTER NODENAME PROVIDERID PHASE AGE VERSION hypercluster1-c96b6f675-m5vch hypercluster1-b2qhl ocp-worker-1 agent://da503cf1-a347-44f2-875c-4960ddb04091 Running 15m 4.11.5 hypercluster1-c96b6f675-tl42p hypercluster1-b2qhl ocp-worker-2 agent://4dac1ab2-7dd5-4894-a220-6a3473b67ee6 Running 15m 4.11.5Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.7. OpenStack에 호스팅된 컨트롤 플레인 배포 링크 복사링크가 클립보드에 복사되었습니다!
RHOSP(Red Hat OpenStack Platform)에 호스팅된 컨트롤 플레인 클러스터를 배포하는 것은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 다음 링크를 참조하십시오.
RHOSP(Red Hat OpenStack Platform) 17.1에서 실행되는 호스팅된 클러스터로 호스팅되는 컨트롤 플레인을 배포할 수 있습니다.
호스팅 클러스터는 관리 클러스터에서 호스팅되 는 API 끝점 및 컨트롤 플레인이 있는 OpenShift Container Platform 클러스터입니다. 호스트된 컨트롤 플레인을 사용하면 각 컨트롤 플레인의 전용 가상 또는 물리적 시스템 필요 없이 컨트롤 플레인이 관리 클러스터에 Pod로 존재합니다.
4.7.1. OpenStack 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
RHOSP(Red Hat OpenStack Platform)에서 호스팅 클러스터를 생성하기 전에 다음 요구 사항을 충족해야 합니다.
- 관리 OpenShift Container Platform 클러스터 버전 4.17 이상에 대한 관리자 액세스 권한이 있어야 합니다. 이 클러스터는 베어 메탈, RHOSP 또는 지원되는 퍼블릭 클라우드에서 실행할 수 있습니다.
- HyperShift Operator는 "호스팅된 컨트롤 플레인 배포 준비"에 지정된 관리 클러스터에 설치됩니다.
- 관리 클러스터는 OVN-Kubernetes를 기본 Pod 네트워크 CNI로 사용하여 구성됩니다.
-
OpenShift CLI(
oc) 및 호스팅된 컨트롤 플레인 CLI,hcp가 설치됩니다. 로드 밸런서 백엔드(예: Octavia)는 관리 OCP 클러스터에 설치됩니다. 호스트된 각 클러스터에 대해
kube-api서비스를 생성하려면 로드 밸런서가 필요합니다.- ingress가 Octavia 로드 밸런싱으로 구성되면 RHOSP Octavia 서비스가 게스트 클러스터를 호스팅하는 클라우드에서 실행되고 있습니다.
-
quay.io/openshift-release-dev리포지토리에 유효한 풀 시크릿 파일이 있습니다. -
게스트 클러스터에서 관리 클러스터의 기본 외부 네트워크에 연결할 수 있습니다. 이 네트워크에
kube-apiserver로드 밸런서 유형 서비스가 생성됩니다. 수신에 사전 정의된 유동 IP 주소를 사용하는 경우 다음 와일드카드 도메인에 대한 DNS 레코드를 생성했습니다
. *.apps.<cluster_name>.<base_domain> .-
<CLUSTER_NAME>은 관리 클러스터의 이름입니다. -
<base_domain>은 클러스터의 애플리케이션이 있는 상위 DNS 도메인입니다.
-
4.7.2. etcd 로컬 스토리지를 위한 관리 클러스터 준비 링크 복사링크가 클립보드에 복사되었습니다!
RHOSP(Red Hat OpenStack Platform)에 HCP(Hosted Control Plane) 배포에서 기본 Cinder 기반 PVC(영구 볼륨 클레임)를 사용하는 대신 TopoLVM CSI 드라이버로 프로비저닝된 로컬 임시 스토리지를 사용하여 etcd 성능을 향상시킬 수 있습니다.
사전 요구 사항
- HyperShift가 설치된 관리 클러스터에 액세스할 수 있습니다.
- RHOSP 플레이버 및 머신 세트를 생성하고 관리할 수 있습니다.
-
oc및openstackCLI 툴이 설치되어 구성되어 있습니다. - TopoLVM 및 LVM(Logical Volume Manager) 스토리지 개념에 대해 잘 알고 있습니다.
- 관리 클러스터에 LVM Storage Operator가 설치되어 있어야 합니다. 자세한 내용은 OpenShift Container Platform 설명서의 스토리지 섹션에서 "CLI를 사용하여 LVM 스토리지 설치"를 참조하십시오.
프로세스
openstackCLI를 사용하여 추가 임시 디스크로 Nova 플레이버를 만듭니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고해당 플레이버를 사용하여 서버를 생성할 때 Nova에서 임시 디스크를 인스턴스에 자동으로 연결하고
vfat로 포맷합니다.- 새 플레이버를 사용하는 컴퓨팅 시스템 세트를 생성합니다. 자세한 내용은 OpenShift Container Platform 설명서의 "OpenStack에서 컴퓨팅 머신 세트 생성"을 참조하십시오.
- 요구 사항에 맞게 머신 세트를 확장합니다. 고가용성을 위해 클러스터를 배포하는 경우 포드를 적절하게 배포할 수 있도록 최소 3개의 작업자를 배포해야 합니다.
새 작업자 노드에 레이블을 지정하여 etcd 사용을 식별합니다. 예를 들면 다음과 같습니다.
oc label node <node_name> hypershift-capable=true
$ oc label node <node_name> hypershift-capable=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이 레이블은 임의의 레이블입니다. 나중에 업데이트할 수 있습니다.
lvmcluster.yaml이라는 파일에서 etcd의 로컬 스토리지 구성에 다음LVMCluster사용자 지정 리소스를 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 예에서 resource는 다음과 같습니다.
-
임시 디스크 위치는 대부분의 경우
/dev/vdb입니다. 경우에 따라 이 위치가 true인지 확인하고 심볼릭 링크가 지원되지 않습니다. -
기본 Nova 임시 디스크가 VFAT 형식으로 포맷되므로 매개 변수
forceWipeDevicesAndDestroyAllData가True값으로 설정됩니다.
-
임시 디스크 위치는 대부분의 경우
다음 명령을 실행하여
LVMCluster리소스를 적용합니다.oc apply -f lvmcluster.yaml
oc apply -f lvmcluster.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
LVMCluster리소스를 확인합니다.oc get lvmcluster -A
$ oc get lvmcluster -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAMESPACE NAME STATUS openshift-storage etcd-hcp Ready
NAMESPACE NAME STATUS openshift-storage etcd-hcp ReadyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
StorageClass리소스를 확인합니다.oc get storageclass
$ oc get storageclassCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE lvms-etcd-class topolvm.io Delete WaitForFirstConsumer true 23m standard-csi (default) cinder.csi.openstack.org Delete WaitForFirstConsumer true 56m
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE lvms-etcd-class topolvm.io Delete WaitForFirstConsumer true 23m standard-csi (default) cinder.csi.openstack.org Delete WaitForFirstConsumer true 56mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
이제 성능이 높은 etcd 구성으로 호스팅 클러스터를 배포할 수 있습니다. 배포 프로세스는 "OpenStack에서 호스트된 클러스터 생성"에 설명되어 있습니다.
4.7.3. Ingress를 위한 유동 IP 생성 링크 복사링크가 클립보드에 복사되었습니다!
수동으로 개입하지 않고 호스팅 클러스터에서 수신을 사용하려면 유동 IP 주소를 미리 생성할 수 있습니다.
사전 요구 사항
- RHOSP(Red Hat OpenStack Platform) 클라우드에 액세스할 수 있습니다.
수신에 사전 정의된 유동 IP 주소를 사용하는 경우 다음 와일드카드 도메인에 대한 DNS 레코드를 생성했습니다
. *.apps.<cluster_name>.<base_domain> .-
<CLUSTER_NAME>은 관리 클러스터의 이름입니다. -
<base_domain>은 클러스터의 애플리케이션이 있는 상위 DNS 도메인입니다.
-
프로세스
다음 명령을 실행하여 유동 IP 주소를 만듭니다.
openstack floating ip create <external_network_id>
$ openstack floating ip create <external_network_id>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
<external_network_id>- 외부 네트워크의 ID를 지정합니다.
미리 생성하지 않고 --openstack-ingress-floating-ip 플래그를 사용하여 유동 IP 주소를 지정하면 cloud-provider-openstack 구성 요소가 자동으로 생성하려고 합니다. 이 프로세스는 Neutron API 정책에서 특정 IP 주소로 유동 IP 주소를 생성할 수 있는 경우에만 성공합니다.
4.7.4. OpenStack에 RHCOS 이미지 업로드 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 컨트롤 플레인 및 RHOSP(Red Hat OpenStack Platform) 배포에 노드 풀을 배포할 때 사용할 RHCOS 이미지를 지정하려면 이미지를 RHOSP 클라우드에 업로드합니다. 이미지를 업로드하지 않으면ORC(OpenStack Resource Controller)가 OpenShift Container Platform 미러에서 이미지를 다운로드하고 호스팅된 클러스터를 삭제한 후 이미지를 삭제합니다.
사전 요구 사항
- OpenShift Container Platform 미러에서 RHCOS 이미지를 다운로드했습니다.
- RHOSP 클라우드에 액세스할 수 있습니다.
프로세스
다음 명령을 실행하여 RHOSP에 RHCOS 이미지를 업로드합니다.
openstack image create --disk-format qcow2 --file <image_file_name> rhcos
$ openstack image create --disk-format qcow2 --file <image_file_name> rhcosCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
<image_file_name>- RHCOS 이미지의 파일 이름을 지정합니다.
4.7.5. OpenStack에서 호스트된 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
hcp CLI를 사용하여 RHOSP(Red Hat OpenStack Platform)에서 호스팅 클러스터를 생성할 수 있습니다.
사전 요구 사항
- "호스트된 컨트롤 플레인 배포 준비"에서 모든 사전 요구 사항 단계를 완료했습니다.
- "OpenStack 사전 요구 사항"을 검토했습니다.
- " etcd 로컬 스토리지용 관리 클러스터 준비"의 모든 단계를 완료했습니다.
- 관리 클러스터에 액세스할 수 있습니다.
- RHOSP 클라우드에 액세스할 수 있습니다.
프로세스
hcp create명령을 실행하여 호스트된 클러스터를 생성합니다. 예를 들어 " etcd 로컬 스토리지의 관리 클러스터 준비"에 설명된 수행 중인 etcd 구성을 활용하는 클러스터는 다음을 입력합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
클러스터 생성 시 많은 옵션을 사용할 수 있습니다. RHOSP 관련 옵션은 "OpenStack에서 호스팅된 컨트롤 플레인 클러스터를 생성하는 옵션"을 참조하십시오. 일반적인 옵션은 hcp 문서를 참조하십시오.
검증
호스트에서 다음 명령을 실행하여 호스팅 클러스터가 준비되었는지 확인합니다.
oc -n clusters-<cluster_name> get pods
$ oc -n clusters-<cluster_name> get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
<cluster_name>- 클러스터 이름을 지정합니다.
몇 분 후에 호스팅된 컨트롤 플레인 포드가 실행 중임을 출력에 표시되어야 합니다.
출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터의 etcd 구성을 확인하려면 다음을 수행합니다.
다음 명령을 실행하여 etcd PVC(영구 볼륨 클레임)를 확인합니다.
oc get pvc -A
$ oc get pvc -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow 호스팅된 컨트롤 플레인 etcd pod 내에서 다음 명령을 실행하여 마운트 경로와 장치를 확인합니다.
df -h /var/lib
$ df -h /var/libCopy to Clipboard Copied! Toggle word wrap Toggle overflow
클러스터 API 공급자가 생성하는 RHOSP 리소스에는 openshiftClusterID=<infraID> 레이블이 지정됩니다.
호스팅된 클러스터를 생성하는 데 사용하는 YAML 매니페스트의 HostedCluster.Spec.Platform.OpenStack.Tags 필드에 있는 값으로 리소스에 대한 추가 태그를 정의할 수 있습니다. 노드 풀을 확장한 후 태그가 리소스에 적용됩니다.
4.7.5.1. OpenStack에서 호스팅 컨트롤 플레인 클러스터를 생성하는 옵션 링크 복사링크가 클립보드에 복사되었습니다!
RHOSP(Red Hat OpenStack Platform)에 호스팅 컨트롤 플레인 클러스터를 배포하는 동안 hcp CLI에 여러 옵션을 제공할 수 있습니다.
| 옵션 | 설명 | 필수 항목 |
|---|---|---|
|
|
OpenStack CA 인증서 파일의 경로입니다. 제공하지 않으면 | 없음 |
|
|
| 없음 |
|
|
OpenStack 자격 증명 파일의 경로입니다. 제공되지 않는 경우
| 없음 |
|
| 서브넷을 만들 때 제공되는 DNS 서버 주소 목록입니다. | 없음 |
|
| OpenStack 외부 네트워크의 ID입니다. | 없음 |
|
| OpenShift 인그레스의 유동 IP입니다. | 없음 |
|
|
노드에 연결할 추가 포트입니다. 유효한 값은 | 없음 |
|
| 노드 풀의 가용성 영역입니다. | 없음 |
|
| 노드 풀에 플레이버입니다. | 제공됨 |
|
| 노드 풀의 이미지 이름입니다. | 없음 |
5장. 호스팅된 컨트롤 플레인 관리 링크 복사링크가 클립보드에 복사되었습니다!
5.1. AWS에서 호스트된 컨트롤 플레인 관리 링크 복사링크가 클립보드에 복사되었습니다!
AWS(Amazon Web Services)에서 OpenShift Container Platform에 호스팅되는 컨트롤 플레인을 사용하는 경우 인프라 요구 사항은 설정에 따라 다릅니다.
5.1.1. AWS 인프라 및 IAM 권한을 관리하기 위한 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
AWS(Amazon Web Services)에서 OpenShift Container Platform에 대해 호스팅된 컨트롤 플레인을 구성하려면 다음 인프라 요구 사항을 충족해야 합니다.
- 호스팅된 클러스터를 생성하기 전에 호스팅된 컨트롤 플레인을 구성했습니다.
- AWS IAM(Identity and Access Management) 역할 및 AWS STS(Security Token Service) 인증 정보를 생성하셨습니다.
5.1.1.1. AWS의 인프라 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
AWS(Amazon Web Services)에서 호스팅되는 컨트롤 플레인을 사용하는 경우 인프라 요구 사항은 다음 카테고리에 적합합니다.
- 임의의 AWS 계정에서 HyperShift Operator에 대한 사전 요구 사항 및 관리되지 않는 인프라
- 호스트 클러스터 AWS 계정에서 사전 요구 사항 및 관리되지 않는 인프라
- 관리 AWS 계정에서 호스팅되는 컨트롤 플레인 관리 인프라
- 호스트 클러스터 AWS 계정에서 호스팅된 컨트롤 플레인 관리 인프라
- 호스트 클러스터 AWS 계정의 Kubernetes 관리 인프라
Prerequired는 호스팅된 컨트롤 플레인이 제대로 작동하려면 AWS 인프라가 필요하다는 것을 의미합니다. Unmanaged는 Operator 또는 컨트롤러가 사용자를 위한 인프라를 생성하지 않음을 의미합니다.
5.1.1.2. AWS 계정의 HyperShift Operator에 대한 관리되지 않는 인프라 링크 복사링크가 클립보드에 복사되었습니다!
임의의 AWS(Amazon Web Services) 계정은 호스팅된 컨트롤 플레인 서비스 공급자에 따라 다릅니다.
자체 관리형 호스팅 컨트롤 플레인에서 클러스터 서비스 공급자는 AWS 계정을 제어합니다. 클러스터 서비스 공급자는 클러스터 컨트롤 플레인을 호스팅하고 가동 시간을 담당하는 관리자입니다. 관리형 호스팅 컨트롤 플레인에서 AWS 계정은 Red Hat에 속합니다.
HyperShift Operator에 대한 사전 필수 및 관리되지 않는 인프라에서 다음 인프라 요구 사항이 관리 클러스터 AWS 계정에 적용됩니다.
S3 버킷 1개
- OpenID Connect(OIDC)
Route 53 호스팅 영역
- 호스팅된 클러스터의 프라이빗 및 공용 항목을 호스트하는 도메인
5.1.1.3. 관리 AWS 계정에 대한 관리되지 않는 인프라 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 클러스터 AWS(Amazon Web Services) 계정에서 인프라가 필수적이고 관리되지 않는 경우 모든 액세스 모드에 대한 인프라 요구 사항은 다음과 같습니다.
- VPC 1개
- DHCP 옵션 1개
두 개의 서브넷
- 내부 데이터 플레인 서브넷인 프라이빗 서브넷
- 데이터 플레인에서 인터넷에 액세스할 수 있는 공용 서브넷
- 하나의 인터넷 게이트웨이
- 탄력적 IP 1개
- NAT 게이트웨이 1개
- 하나의 보안 그룹(작업자 노드)
- 두 개의 경로 테이블(개인 1개 및 공용)
- 두 개의 Route 53 호스팅 영역
다음 항목에 대한 할당량이 충분합니다.
- 퍼블릭 호스팅 클러스터를 위한 하나의 Ingress 서비스 로드 밸런서
- 프라이빗 호스팅 클러스터용 프라이빗 링크 끝점 1개
개인 링크 네트워킹이 작동하려면 호스팅된 클러스터 AWS 계정의 끝점 영역이 관리 클러스터 AWS 계정의 서비스 끝점에 의해 해결되는 인스턴스의 영역과 일치해야 합니다. AWS에서 영역 이름은 us-east-2b와 같은 별칭이며, 다른 계정의 동일한 영역에 매핑되지는 않습니다. 결과적으로 개인 링크가 작동하려면 관리 클러스터에 해당 리전의 모든 영역에 서브넷 또는 작업자가 있어야 합니다.
5.1.1.4. 관리 AWS 계정에 대한 인프라 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
관리 AWS 계정의 호스팅된 컨트롤 플레인에서 인프라를 관리하는 경우 클러스터의 퍼블릭, 프라이빗 또는 조합 여부에 따라 인프라 요구 사항이 다릅니다.
퍼블릭 클러스터가 있는 계정의 경우 인프라 요구 사항은 다음과 같습니다.
네트워크 로드 밸런서: 로드 밸런서 Kube API 서버
- Kubernetes에서 보안 그룹을 생성합니다.
volumes
- etcd의 경우 (고용도에 따라 1개 또는 3개)
- OVN-Kube의 경우
프라이빗 클러스터가 있는 계정의 경우 인프라 요구 사항은 다음과 같습니다.
- 네트워크 로드 밸런서: 로드 밸런서 개인 라우터
- 엔드포인트 서비스(개인 링크)
퍼블릭 및 프라이빗 클러스터가 있는 계정의 경우 인프라 요구 사항은 다음과 같습니다.
- 네트워크 로드 밸런서: 로드 밸런서 공용 라우터
- 네트워크 로드 밸런서: 로드 밸런서 개인 라우터
- 엔드포인트 서비스(개인 링크)
volumes
- etcd의 경우 (고용도에 따라 1개 또는 3개)
- OVN-Kube의 경우
5.1.1.5. 호스트 클러스터의 AWS 계정에 대한 인프라 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 클러스터 AWS(Amazon Web Services) 계정의 호스팅된 컨트롤 플레인에서 인프라를 관리하는 경우 클러스터의 퍼블릭, 프라이빗 또는 조합 여부에 따라 인프라 요구 사항이 다릅니다.
퍼블릭 클러스터가 있는 계정의 경우 인프라 요구 사항은 다음과 같습니다.
-
노드 풀에는
Role및RolePolicy가 정의된 EC2 인스턴스가 있어야 합니다.
프라이빗 클러스터가 있는 계정의 경우 인프라 요구 사항은 다음과 같습니다.
- 각 가용성 영역에 대해 하나의 개인 링크 끝점
- 노드 풀용 EC2 인스턴스
퍼블릭 및 프라이빗 클러스터가 있는 계정의 경우 인프라 요구 사항은 다음과 같습니다.
- 각 가용성 영역에 대해 하나의 개인 링크 끝점
- 노드 풀용 EC2 인스턴스
5.1.1.6. 호스트 클러스터 AWS 계정의 Kubernetes 관리 인프라 링크 복사링크가 클립보드에 복사되었습니다!
Kubernetes가 호스팅 클러스터 AWS(Amazon Web Services) 계정에서 인프라를 관리하는 경우 인프라 요구 사항은 다음과 같습니다.
- 기본 Ingress의 네트워크 로드 밸런서
- 레지스트리의 S3 버킷
5.1.2. IAM(Identity and Access Management) 권한 링크 복사링크가 클립보드에 복사되었습니다!
호스트된 컨트롤 플레인의 컨텍스트에서 소비자는 ARM(Amazon Resource Name) 역할을 생성합니다. 소비자 는 권한 파일을 생성하기 위한 자동화된 프로세스입니다. 소비자는 CLI 또는 OpenShift Cluster Manager일 수 있습니다. 호스팅된 컨트롤 플레인은 최소 권한 구성 요소의 원칙을 세분적으로 활성화하여 모든 구성 요소가 자체 역할을 사용하여 AWS(Amazon Web Services) 오브젝트를 운영하거나 생성하며 역할이 제품이 정상적으로 작동하는 데 필요한 것으로 제한됩니다.
호스트된 클러스터는 ARN 역할을 입력으로 수신하고 소비자는 각 구성 요소에 대한 AWS 권한 구성을 생성합니다. 결과적으로 구성 요소는 STS 및 사전 구성된 OIDC IDP를 통해 인증할 수 있습니다.
다음 역할은 컨트롤 플레인에서 실행되고 데이터 플레인에서 작동하는 호스팅된 컨트롤 플레인의 일부 구성 요소에서 소비됩니다.
-
controlPlaneOperatorARN -
imageRegistryARN -
ingressARN -
kubeCloudControllerARN -
nodePoolManagementARN -
storageARN -
networkARN
다음 예제는 호스팅된 클러스터의 IAM 역할에 대한 참조를 보여줍니다.
컨트롤 플레인에서 사용하는 역할은 다음 예에 표시됩니다.
ingressARNCopy to Clipboard Copied! Toggle word wrap Toggle overflow imageRegistryARNCopy to Clipboard Copied! Toggle word wrap Toggle overflow storageARNCopy to Clipboard Copied! Toggle word wrap Toggle overflow networkARNCopy to Clipboard Copied! Toggle word wrap Toggle overflow kubeCloudControllerARNCopy to Clipboard Copied! Toggle word wrap Toggle overflow nodePoolManagementARNCopy to Clipboard Copied! Toggle word wrap Toggle overflow controlPlaneOperatorARNCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.1.3. AWS 인프라 및 IAM 리소스 생성 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 hcp create cluster aws 명령은 호스팅된 클러스터를 사용하여 클라우드 인프라를 생성하여 적용합니다. hcp create cluster aws 명령을 사용하여 클러스터를 생성하거나 적용하기 전에 이를 수정하도록 클라우드 인프라 부분을 별도로 생성할 수 있습니다.
클라우드 인프라 부분을 별도로 생성하려면 AWS(Amazon Web Services) 인프라를 생성하고 AWS Identity and Access(IAM) 리소스를 생성하고 클러스터를 생성해야 합니다.
5.1.3.1. AWS 인프라를 별도로 생성 링크 복사링크가 클립보드에 복사되었습니다!
AWS(Amazon Web Services) 인프라를 생성하려면 VPC(Virtual Private Cloud) 및 클러스터에 대한 기타 리소스를 생성해야 합니다. AWS 콘솔 또는 인프라 자동화 및 프로비저닝 툴을 사용할 수 있습니다. AWS 콘솔을 사용하는 방법은 AWS 문서의 VPC 및 기타 VPC 리소스 생성 을 참조하십시오.
VPC에는 NAT(네트워크 주소 변환) 게이트웨이 및 인터넷 게이트웨이와 같은 외부 액세스를 위한 프라이빗 및 퍼블릭 서브넷 및 리소스가 포함되어야 합니다. VPC 외에도 클러스터 수신을 위한 프라이빗 호스팅 영역이 필요합니다. Private Link(프라이빗 또는 PublicAndPrivate 액세스 모드)를 사용하는 클러스터를 생성하는 경우 PrivateLink에 대한 추가 호스팅 영역이 필요합니다.
다음 예제 구성을 사용하여 호스팅된 클러스터에 대한 AWS 인프라를 생성합니다.
- 1
- &
lt;pull_secret_name>을 풀 시크릿 이름으로 바꿉니다. - 2
- &
lt;etcd_encryption_key_name>을 etcd 암호화 키 이름으로 바꿉니다. - 3
- &
lt;ssh_key_name>을 SSH 키 이름으로 바꿉니다. - 4
- &
lt;hosted_cluster_name>을 호스트된 클러스터 이름으로 바꿉니다. - 5
- &
lt;dns_domain>을example.com과 같은 기본 DNS 도메인으로 바꿉니다. - 6
- &
lt;infra_id>를 호스팅된 클러스터와 연결된 IAM 리소스를 식별하는 값으로 바꿉니다. - 7
- &
lt;issuer_url>을 발행자 URL로 바꿉니다. 이 URL은infra_id값으로 끝납니다. 예:https://example-hosted-us-west-1.s3.us-west-1.amazonaws.com/example-hosted-infra-id. - 8
- <
;subnet_xxx>를 서브넷 ID로 바꿉니다. 프라이빗 서브넷과 퍼블릭 서브넷 모두 태그를 지정해야 합니다. 퍼블릭 서브넷의 경우kubernetes.io/role/elb=1을 사용합니다. 프라이빗 서브넷의 경우kubernetes.io/role/internal-elb=1을 사용합니다. - 9
- <
;vpc_xxx>를 VPC ID로 바꿉니다. - 10
- &
lt;node_pool_name>을NodePool리소스의 이름으로 바꿉니다. - 11
- &
lt;instance_profile_name>을 AWS 인스턴스의 이름으로 바꿉니다.
5.1.3.2. AWS IAM 리소스 생성 링크 복사링크가 클립보드에 복사되었습니다!
AWS(Amazon Web Services)에서 다음 IAM 리소스를 생성해야 합니다.
- STS 인증을 활성화하는 데 필요한 IAM의 OpenID Connect(OIDC) ID 공급자입니다.
- Kubernetes 컨트롤러 관리자, 클러스터 API 공급자 및 레지스트리와 같이 공급자와 상호 작용하는 모든 구성 요소에 대해 별도의 7가지 역할
- 클러스터의 모든 작업자 인스턴스에 할당된 프로필인 인스턴스 프로필
5.1.3.3. 호스팅 클러스터를 별도로 생성 링크 복사링크가 클립보드에 복사되었습니다!
AWS(Amazon Web Services)에서 호스팅 클러스터를 별도로 생성할 수 있습니다.
호스팅 클러스터를 별도로 생성하려면 다음 명령을 입력합니다.
- 1
- &
lt;infra_id>를create infra aws명령에 지정한 것과 동일한 ID로 바꿉니다. 이 값은 호스팅된 클러스터와 연결된 IAM 리소스를 식별합니다. - 2
- &
lt;hosted_cluster_name>을 호스트된 클러스터 이름으로 바꿉니다. - 3
- &
lt;path_to_sts_credential_file>을create infra aws명령에 지정한 것과 동일한 이름으로 바꿉니다. - 4
- &
lt;path_to_pull_secret>을 유효한 OpenShift Container Platform 풀 시크릿이 포함된 파일 이름으로 바꿉니다. - 5
--generate-ssh플래그는 선택 사항이지만 작업자에게 SSH를 사용해야 하는 경우 포함할 수 있습니다. SSH 키는 사용자를 위해 생성되며 호스팅된 클러스터와 동일한 네임스페이스에 시크릿으로 저장됩니다.- 6
- <
role_name>을 Amazon Resource Name(ARN)으로 바꿉니다. 예를 들면arn:aws:iam::820196288204:role/myrole입니다. Amazon 리소스 이름(ARN)을 지정합니다(예:arn:aws:iam::820196288204:role/myrole). ARN 역할에 대한 자세한 내용은 "IAM(Identity and Access Management) 권한"을 참조하십시오.
명령에 --render 플래그를 추가하고 클러스터에 적용하기 전에 리소스를 편집할 수 있는 파일로 출력을 리디렉션할 수도 있습니다.
명령을 실행하면 다음 리소스가 클러스터에 적용됩니다.
- 네임스페이스
- 풀 시크릿이 있는 시크릿
-
A
HostedCluster -
A
NodePool - 컨트롤 플레인 구성 요소에 대한 세 가지 AWS STS 시크릿
-
--generate-ssh플래그를 지정한 경우 SSH 키 시크릿 1개
5.1.4. 호스트 클러스터를 단일 아키텍처에서 다중 아키텍처로 전환 링크 복사링크가 클립보드에 복사되었습니다!
단일 아키텍처 64비트 AMD 호스팅 클러스터를 AWS(Amazon Web Services)의 다중 아키텍처 호스팅 클러스터로 전환하여 클러스터에서 실행 중인 워크로드 비용을 줄일 수 있습니다. 예를 들어 64비트 ARM으로 전환하면서 64비트 AMD에서 기존 워크로드를 실행할 수 있으며 중앙 Kubernetes 클러스터에서 이러한 워크로드를 관리할 수 있습니다.
단일 아키텍처 호스팅 클러스터는 하나의 특정 CPU 아키텍처로만 노드 풀을 관리할 수 있습니다. 그러나 다중 아키텍처 호스팅 클러스터는 다른 CPU 아키텍처로 노드 풀을 관리할 수 있습니다. AWS에서 다중 아키텍처 호스팅 클러스터는 64비트 AMD 및 64비트 ARM 노드 풀을 모두 관리할 수 있습니다.
사전 요구 사항
- Kubernetes Operator용 다중 클러스터 엔진과 함께 RHACM(Red Hat Advanced Cluster Management)에 AWS용 OpenShift Container Platform 관리 클러스터를 설치했습니다.
- OpenShift Container Platform 릴리스 페이로드의 64비트 AMD 변형을 사용하는 기존 단일 아키텍처 호스팅 클러스터가 있습니다.
- OpenShift Container Platform 릴리스 페이로드의 동일한 64비트 AMD 변형을 사용하고 기존 호스팅 클러스터에서 관리하는 기존 노드 풀입니다.
다음 명령줄 툴을 설치했는지 확인합니다.
-
oc -
kubectl -
hcp -
skopeo
-
프로세스
다음 명령을 실행하여 단일 아키텍처 호스팅 클러스터의 기존 OpenShift Container Platform 릴리스 이미지를 검토합니다.
oc get hostedcluster/<hosted_cluster_name> \ -o jsonpath='{.spec.release.image}'$ oc get hostedcluster/<hosted_cluster_name> \1 -o jsonpath='{.spec.release.image}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- <
;hosted_cluster_name>을 호스트된 클러스터 이름으로 교체합니다.
출력 예
quay.io/openshift-release-dev/ocp-release:<4.y.z>-x86_64
quay.io/openshift-release-dev/ocp-release:<4.y.z>-x86_641 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;4.y.z>를 사용하는 지원되는 OpenShift Container Platform 버전으로 바꿉니다.
OpenShift Container Platform 릴리스 이미지에서 태그 대신 다이제스트를 사용하는 경우 릴리스 이미지의 다중 아키텍처 태그 버전을 찾습니다.
다음 명령을 실행하여 OpenShift Container Platform 버전의
OCP_VERSION환경 변수를 설정합니다.OCP_VERSION=$(oc image info quay.io/openshift-release-dev/ocp-release@sha256:ac78ebf77f95ab8ff52847ecd22592b545415e1ff6c7ff7f66bf81f158ae4f5e \ -o jsonpath='{.config.config.Labels["io.openshift.release"]}')$ OCP_VERSION=$(oc image info quay.io/openshift-release-dev/ocp-release@sha256:ac78ebf77f95ab8ff52847ecd22592b545415e1ff6c7ff7f66bf81f158ae4f5e \ -o jsonpath='{.config.config.Labels["io.openshift.release"]}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 릴리스 이미지의 다중 아키텍처 태그 버전에 대해
MULTI_ARCH_TAG환경 변수를 설정합니다.MULTI_ARCH_TAG=$(skopeo inspect docker://quay.io/openshift-release-dev/ocp-release@sha256:ac78ebf77f95ab8ff52847ecd22592b545415e1ff6c7ff7f66bf81f158ae4f5e \ | jq -r '.RepoTags' | sed 's/"//g' | sed 's/,//g' \ | grep -w "$OCP_VERSION-multi$" | xargs)
$ MULTI_ARCH_TAG=$(skopeo inspect docker://quay.io/openshift-release-dev/ocp-release@sha256:ac78ebf77f95ab8ff52847ecd22592b545415e1ff6c7ff7f66bf81f158ae4f5e \ | jq -r '.RepoTags' | sed 's/"//g' | sed 's/,//g' \ | grep -w "$OCP_VERSION-multi$" | xargs)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 다중 아키텍처 릴리스 이미지 이름에 대한
IMAGE환경 변수를 설정합니다.IMAGE=quay.io/openshift-release-dev/ocp-release:$MULTI_ARCH_TAG
$ IMAGE=quay.io/openshift-release-dev/ocp-release:$MULTI_ARCH_TAGCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다중 아키텍처 이미지 다이제스트 목록을 보려면 다음 명령을 실행합니다.
oc image info $IMAGE
$ oc image info $IMAGECopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
OS DIGEST linux/amd64 sha256:b4c7a91802c09a5a748fe19ddd99a8ffab52d8a31db3a081a956a87f22a22ff8 linux/ppc64le sha256:66fda2ff6bd7704f1ba72be8bfe3e399c323de92262f594f8e482d110ec37388 linux/s390x sha256:b1c1072dc639aaa2b50ec99b530012e3ceac19ddc28adcbcdc9643f2dfd14f34 linux/arm64 sha256:7b046404572ac96202d82b6cb029b421dddd40e88c73bbf35f602ffc13017f21
OS DIGEST linux/amd64 sha256:b4c7a91802c09a5a748fe19ddd99a8ffab52d8a31db3a081a956a87f22a22ff8 linux/ppc64le sha256:66fda2ff6bd7704f1ba72be8bfe3e399c323de92262f594f8e482d110ec37388 linux/s390x sha256:b1c1072dc639aaa2b50ec99b530012e3ceac19ddc28adcbcdc9643f2dfd14f34 linux/arm64 sha256:7b046404572ac96202d82b6cb029b421dddd40e88c73bbf35f602ffc13017f21Copy to Clipboard Copied! Toggle word wrap Toggle overflow
호스트 클러스터를 단일 아키텍처에서 다중 아키텍처로 전환합니다.
호스팅된 클러스터와 동일한 OpenShift Container Platform 버전을 사용하도록 하여 호스팅된 클러스터의 다중 아키텍처 OpenShift Container Platform 릴리스 이미지를 설정합니다. 다음 명령을 실행합니다.
oc patch -n clusters hostedclusters/<hosted_cluster_name> -p \ '{"spec":{"release":{"image":"quay.io/openshift-release-dev/ocp-release:<4.x.y>-multi"}}}' \ --type=merge$ oc patch -n clusters hostedclusters/<hosted_cluster_name> -p \ '{"spec":{"release":{"image":"quay.io/openshift-release-dev/ocp-release:<4.x.y>-multi"}}}' \1 --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;4.y.z>를 사용하는 지원되는 OpenShift Container Platform 버전으로 바꿉니다.
다음 명령을 실행하여 호스팅된 클러스터에 다중 아키텍처 이미지가 설정되어 있는지 확인합니다.
oc get hostedcluster/<hosted_cluster_name> \ -o jsonpath='{.spec.release.image}'$ oc get hostedcluster/<hosted_cluster_name> \ -o jsonpath='{.spec.release.image}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 명령을 실행하여
HostedControlPlane리소스의 상태가진행중인지 확인합니다.oc get hostedcontrolplane -n <hosted_control_plane_namespace> -oyaml
$ oc get hostedcontrolplane -n <hosted_control_plane_namespace> -oyamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
HostedCluster리소스의 상태가진행중인지 확인합니다.oc get hostedcluster <hosted_cluster_name> \ -n <hosted_cluster_namespace> -oyaml
$ oc get hostedcluster <hosted_cluster_name> \ -n <hosted_cluster_namespace> -oyamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 실행하여 노드 풀이
HostedControlPlane리소스의 다중 아키텍처 릴리스 이미지를 사용하고 있는지 확인합니다.oc get hostedcontrolplane -n clusters-example -oyaml
$ oc get hostedcontrolplane -n clusters-example -oyamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;4.y.z>를 사용하는 지원되는 OpenShift Container Platform 버전으로 바꿉니다.
참고멀티 아키텍처 OpenShift Container Platform 릴리스 이미지는
HostedCluster,HostedControlPlane리소스 및 호스팅된 컨트롤 플레인 Pod에서 업데이트됩니다. 그러나 릴리스 이미지 전환이 호스팅된 클러스터와 노드 풀 간에 분리되므로 기존 노드 풀은 다중 아키텍처 이미지로 자동 전환되지 않습니다. 새로운 다중 아키텍처 호스팅 클러스터에 새 노드 풀을 생성해야 합니다.
다음 단계
- 다중 아키텍처 호스팅 클러스터에서 노드 풀 생성
5.1.5. 다중 아키텍처 호스팅 클러스터에서 노드 풀 생성 링크 복사링크가 클립보드에 복사되었습니다!
호스팅 클러스터를 단일 아키텍처에서 다중 아키텍처로 전환한 후 64비트 AMD 및 64비트 ARM 아키텍처를 기반으로 컴퓨팅 시스템에서 노드 풀을 생성합니다.
프로세스
다음 명령을 입력하여 64비트 ARM 아키텍처를 기반으로 노드 풀을 생성합니다.
hcp create nodepool aws \ --cluster-name <hosted_cluster_name> \ --name <nodepool_name> \ --node-count=<node_count> \ --arch arm64
$ hcp create nodepool aws \ --cluster-name <hosted_cluster_name> \1 --name <nodepool_name> \2 --node-count=<node_count> \3 --arch arm64Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 64비트 AMD 아키텍처를 기반으로 노드 풀을 생성합니다.
hcp create nodepool aws \ --cluster-name <hosted_cluster_name> \ --name <nodepool_name> \ --node-count=<node_count> \ --arch amd64
$ hcp create nodepool aws \ --cluster-name <hosted_cluster_name> \1 --name <nodepool_name> \2 --node-count=<node_count> \3 --arch amd64Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 입력하여 노드 풀이 다중 아키텍처 릴리스 이미지를 사용하고 있는지 확인합니다.
oc get nodepool/<nodepool_name> -oyaml
$ oc get nodepool/<nodepool_name> -oyamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 64비트 AMD 노드 풀 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;4.y.z>를 사용하는 지원되는 OpenShift Container Platform 버전으로 바꿉니다.
64비트 ARM 노드 풀 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.1.6. 호스트 클러스터의 AWS 태그 추가 또는 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 인스턴스 관리자는 호스팅된 클러스터를 다시 만들 필요 없이 AWS(Amazon Web Services) 태그를 추가하거나 업데이트할 수 있습니다. 태그는 관리 및 자동화를 위해 AWS 리소스에 연결된 키-값 쌍입니다.
다음과 같은 목적으로 태그를 사용할 수 있습니다.
- 액세스 제어 관리.
- 추적 또는 표시.
- 클라우드 IAM 조건부 권한 관리.
- 태그를 기반으로 리소스 집계. 예를 들어 태그를 쿼리하여 리소스 사용량 및 청구 비용을 계산할 수 있습니다.
EFS 액세스 지점, 로드 밸런서 리소스, Amazon EBS 볼륨, IAM 사용자, AWS S3 등 다양한 유형의 리소스에 대한 태그를 추가하거나 업데이트할 수 있습니다.
네트워크 로드 밸런서에서는 태그를 추가하거나 업데이트할 수 없습니다. AWS 로드 밸런서는 HostedCluster 리소스에 있는 태그를 조정합니다. 태그를 추가하거나 업데이트하려고 하면 로드 밸런서가 태그를 덮어씁니다.
또한 호스팅된 컨트롤 플레인에서 직접 생성하는 기본 보안 그룹 리소스에서 태그를 업데이트할 수 없습니다.
사전 요구 사항
- AWS에서 호스팅된 클러스터에 대한 클러스터 관리자 권한이 있어야 합니다.
프로세스
EFS 액세스 지점에 대한 태그를 추가하거나 업데이트하려면 1단계와 2단계를 완료합니다. 다른 유형의 리소스에 대한 태그를 추가하거나 업데이트하는 경우 2단계만 완료합니다.
aws-efs-csi-driver-operator서비스 계정에서 다음 예와 같이 두 개의 주석을 추가합니다. 클러스터에서 실행되는 AWS EKS Pod ID Webhook에서 EFS Operator가 사용하는 Pod에 AWS 역할을 올바르게 할당하려면 이러한 주석이 필요합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Operator Pod를 삭제하거나
aws-efs-csi-driver-operator배포를 다시 시작합니다.
HostedCluster리소스에서 다음 예와 같이resourceTags필드에 정보를 입력합니다.HostedCluster리소스 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 1
- 리소스에 추가할 태그를 지정합니다.
5.1.7. AWS에서 노드 풀 용량 블록 구성 링크 복사링크가 클립보드에 복사되었습니다!
호스트 클러스터를 생성한 후 AWS(Amazon Web Services)에서 GPU(그래픽 처리 장치) 예약을 위해 노드 풀 용량 블록을 구성할 수 있습니다.
프로세스
다음 명령을 실행하여 AWS에서 GPU 예약을 생성합니다.
중요GPU 예약 영역은 호스팅된 클러스터 영역과 일치해야 합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 최소 용량 블록을 구입하십시오.
aws ec2 purchase-capacity-block \ --capacity-block-offering-id "${MIN_FEE_ID}" \ --instance-platform "Linux/UNIX"\ --tag-specifications 'ResourceType=capacity-reservation,Tags=[{Key=usage-cluster-type,Value=hypershift-hosted}]' \ --output json > "${CR_OUTPUT_FILE}"$ aws ec2 purchase-capacity-block \ --capacity-block-offering-id "${MIN_FEE_ID}" \1 --instance-platform "Linux/UNIX"\2 --tag-specifications 'ResourceType=capacity-reservation,Tags=[{Key=usage-cluster-type,Value=hypershift-hosted}]' \3 --output json > "${CR_OUTPUT_FILE}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 용량 예약 ID를 설정하는 환경 변수를 생성합니다.
CB_RESERVATION_ID=$(jq -r '.CapacityReservation.CapacityReservationId' "${CR_OUTPUT_FILE}")$ CB_RESERVATION_ID=$(jq -r '.CapacityReservation.CapacityReservationId' "${CR_OUTPUT_FILE}")Copy to Clipboard Copied! Toggle word wrap Toggle overflow GPU 예약이 제공될 때까지 몇 분 정도 기다립니다.
다음 명령을 실행하여 GPU 예약을 사용하도록 노드 풀을 추가합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예제 구성을 사용하여
NodePool리소스에capacityReservation설정을 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 노드 풀 구성을 적용합니다.
oc apply -f /tmp/np.yaml
$ oc apply -f /tmp/np.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 실행하여 새 노드 풀이 성공적으로 생성되었는지 확인합니다.
oc get np -n clusters
$ oc get np -n clustersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAMESPACE NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE clusters cb-np cb-np-hcp 1 1 False False 4.20.0-0.nightly-2025-06-05-224220 False False
NAMESPACE NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE clusters cb-np cb-np-hcp 1 1 False False 4.20.0-0.nightly-2025-06-05-224220 False FalseCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 새 컴퓨팅 노드가 호스팅 클러스터에 생성되었는지 확인합니다.
oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME STATUS ROLES AGE VERSION ip-10-0-132-74.ec2.internal Ready worker 17m v1.33.4 ip-10-0-134-183.ec2.internal Ready worker 4h5m v1.33.4
NAME STATUS ROLES AGE VERSION ip-10-0-132-74.ec2.internal Ready worker 17m v1.33.4 ip-10-0-134-183.ec2.internal Ready worker 4h5m v1.33.4Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.1.7.1. 노드 풀 용량 블록을 구성한 후 호스트된 클러스터 제거 링크 복사링크가 클립보드에 복사되었습니다!
노드 풀 용량 블록을 구성한 후 선택적으로 호스팅된 클러스터를 제거하고 HyperShift Operator를 제거할 수 있습니다.
프로세스
호스트된 클러스터를 삭제하려면 다음 예제 명령을 실행합니다.
hcp destroy cluster aws \ --name cb-np-hcp \ --aws-creds $HOME/.aws/credentials \ --namespace clusters \ --region us-east-2
$ hcp destroy cluster aws \ --name cb-np-hcp \ --aws-creds $HOME/.aws/credentials \ --namespace clusters \ --region us-east-2Copy to Clipboard Copied! Toggle word wrap Toggle overflow HyperShift Operator를 설치 제거하려면 다음 명령을 실행합니다.
hcp install render --format=yaml | oc delete -f -
$ hcp install render --format=yaml | oc delete -f -Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2. 베어 메탈에서 호스트된 컨트롤 플레인 관리 링크 복사링크가 클립보드에 복사되었습니다!
베어 메탈에 호스팅되는 컨트롤 플레인을 배포한 후 다음 작업을 완료하여 호스팅 클러스터를 관리할 수 있습니다.
5.2.1. 호스트된 클러스터에 액세스 링크 복사링크가 클립보드에 복사되었습니다!
리소스에서 직접 kubeconfig 파일 및 kubeadmin 자격 증명을 가져오거나 hcp 명령줄 인터페이스를 사용하여 kubeconfig 파일을 생성하여 호스팅된 클러스터에 액세스할 수 있습니다.
사전 요구 사항
리소스에서 직접 kubeconfig 파일 및 인증 정보를 가져와 호스팅된 클러스터에 액세스하려면 호스팅 클러스터의 액세스 시크릿을 숙지해야 합니다. 호스팅된 클러스터(호스트링) 네임스페이스에는 호스팅 된 클러스터 리소스 및 액세스 보안이 포함되어 있습니다. 호스팅된 컨트롤 플레인 네임스페이스는 호스팅된 컨트롤 플레인이 실행되는 위치입니다.
보안 이름 형식은 다음과 같습니다.
-
kubeconfig시크릿: <hosted_cluster_namespace>-<name>-admin-kubeconfig. 예를 들어 cluster-hypershift-demo-admin-kubeconfig. -
kubeadmin암호 시크릿: <hosted_cluster_namespace>-<name>-kubeadmin-password. 예를 들어 cluster-hypershift-demo-kubeadmin-password.
kubeconfig 시크릿에는 Base64로 인코딩된 kubeconfig 필드가 포함되어 있으며 다음 명령과 함께 사용할 파일에 디코딩하고 저장할 수 있습니다.
oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
kubeadmin 암호 시크릿도 Base64로 인코딩됩니다. 이를 디코딩하고 암호를 사용하여 호스팅된 클러스터의 API 서버 또는 콘솔에 로그인할 수 있습니다.
프로세스
hcpCLI를 사용하여kubeconfig파일을 생성하여 호스팅된 클러스터에 액세스하려면 다음 단계를 수행합니다.다음 명령을 입력하여
kubeconfig파일을 생성합니다.hcp create kubeconfig --namespace <hosted_cluster_namespace> \ --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
$ hcp create kubeconfig --namespace <hosted_cluster_namespace> \ --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow kubeconfig파일을 저장한 후 다음 예제 명령을 입력하여 호스팅된 클러스터에 액세스할 수 있습니다.oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.2. 호스트 클러스터의 NodePool 오브젝트 스케일링 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 클러스터에 노드를 추가하여 NodePool 오브젝트를 확장할 수 있습니다. 노드 풀을 확장할 때 다음 정보를 고려하십시오.
- 노드 풀로 복제본을 확장하면 머신이 생성됩니다. 모든 머신에 대해 클러스터 API 공급자는 노드 풀 사양에 지정된 요구 사항을 충족하는 에이전트를 찾아 설치합니다. 에이전트의 상태 및 조건을 확인하여 에이전트 설치를 모니터링할 수 있습니다.
- 노드 풀을 축소하면 에이전트가 해당 클러스터에서 바인딩되지 않습니다. 에이전트를 재사용하려면 먼저 Discovery 이미지를 사용하여 다시 시작해야 합니다.
프로세스
NodePool오브젝트를 두 개의 노드로 확장합니다.oc -n <hosted_cluster_namespace> scale nodepool <nodepool_name> --replicas 2
$ oc -n <hosted_cluster_namespace> scale nodepool <nodepool_name> --replicas 2Copy to Clipboard Copied! Toggle word wrap Toggle overflow Cluster API 에이전트 공급자는 호스트 클러스터에 할당된 두 개의 에이전트를 임의로 선택합니다. 이러한 에이전트는 다른 상태를 통과하고 마지막으로 호스팅된 클러스터에 OpenShift Container Platform 노드로 참여합니다. 에이전트는 다음 순서로 상태를 통과합니다.
-
바인딩 -
검색 -
충분하지 않음 -
설치 -
installing-in-progress -
added-to-existing-cluster
-
다음 명령을 실행합니다.
oc -n <hosted_control_plane_namespace> get agent
$ oc -n <hosted_control_plane_namespace> get agentCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CLUSTER APPROVED ROLE STAGE 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 hypercluster1 true auto-assign d9198891-39f4-4930-a679-65fb142b108b true auto-assign da503cf1-a347-44f2-875c-4960ddb04091 hypercluster1 true auto-assign
NAME CLUSTER APPROVED ROLE STAGE 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 hypercluster1 true auto-assign d9198891-39f4-4930-a679-65fb142b108b true auto-assign da503cf1-a347-44f2-875c-4960ddb04091 hypercluster1 true auto-assignCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행합니다.
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}'$ 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 Copied! Toggle word wrap Toggle overflow 출력 예
BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficient
BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficientCopy to Clipboard Copied! Toggle word wrap Toggle overflow extract 명령을 입력하여 새 호스팅 클러스터에 대한 kubeconfig를 가져옵니다.
oc extract -n <hosted_cluster_namespace> \ secret/<hosted_cluster_name>-admin-kubeconfig --to=- \ > kubeconfig-<hosted_cluster_name>
$ oc extract -n <hosted_cluster_namespace> \ secret/<hosted_cluster_name>-admin-kubeconfig --to=- \ > kubeconfig-<hosted_cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 에이전트가
add-to-existing-cluster상태에 도달한 후 다음 명령을 입력하여 호스팅된 클러스터에 OpenShift Container Platform 노드를 볼 수 있는지 확인합니다.oc --kubeconfig kubeconfig-<hosted_cluster_name> get nodes
$ oc --kubeconfig kubeconfig-<hosted_cluster_name> get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME STATUS ROLES AGE VERSION ocp-worker-1 Ready worker 5m41s v1.24.0+3882f8f ocp-worker-2 Ready worker 6m3s v1.24.0+3882f8f
NAME STATUS ROLES AGE VERSION ocp-worker-1 Ready worker 5m41s v1.24.0+3882f8f ocp-worker-2 Ready worker 6m3s v1.24.0+3882f8fCopy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터 Operator는 노드에 워크로드를 추가하여 조정하기 시작합니다.
다음 명령을 입력하여
NodePool오브젝트를 확장할 때 두 개의 머신이 생성되었는지 확인합니다.oc -n <hosted_control_plane_namespace> get machines
$ oc -n <hosted_control_plane_namespace> get machinesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CLUSTER NODENAME PROVIDERID PHASE AGE VERSION hypercluster1-c96b6f675-m5vch hypercluster1-b2qhl ocp-worker-1 agent://da503cf1-a347-44f2-875c-4960ddb04091 Running 15m 4.x.z hypercluster1-c96b6f675-tl42p hypercluster1-b2qhl ocp-worker-2 agent://4dac1ab2-7dd5-4894-a220-6a3473b67ee6 Running 15m 4.x.z
NAME CLUSTER NODENAME PROVIDERID PHASE AGE VERSION hypercluster1-c96b6f675-m5vch hypercluster1-b2qhl ocp-worker-1 agent://da503cf1-a347-44f2-875c-4960ddb04091 Running 15m 4.x.z hypercluster1-c96b6f675-tl42p hypercluster1-b2qhl ocp-worker-2 agent://4dac1ab2-7dd5-4894-a220-6a3473b67ee6 Running 15m 4.x.zCopy to Clipboard Copied! Toggle word wrap Toggle overflow clusterversion조정 프로세스는 결국 Ingress 및 Console 클러스터 Operator만 누락된 지점에 도달합니다.다음 명령을 실행합니다.
oc --kubeconfig kubeconfig-<hosted_cluster_name> get clusterversion,co
$ oc --kubeconfig kubeconfig-<hosted_cluster_name> get clusterversion,coCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.2.1. 노드 풀 추가 링크 복사링크가 클립보드에 복사되었습니다!
이름, 복제본 수 및 에이전트 라벨 선택기와 같은 추가 정보를 지정하여 호스팅된 클러스터에 대한 노드 풀을 생성할 수 있습니다.
호스트된 각 클러스터에 대해 단일 에이전트 네임스페이스만 지원됩니다. 결과적으로 호스트된 클러스터에 노드 풀을 추가할 때 노드 풀은 단일 InfraEnv 리소스 또는 동일한 에이전트 네임스페이스에 있는 InfraEnv 리소스에서 있어야 합니다.
프로세스
노드 풀을 생성하려면 다음 정보를 입력합니다.
hcp create nodepool agent \ --cluster-name <hosted_cluster_name> \ --name <nodepool_name> \ --node-count <worker_node_count> \ --agentLabelSelector size=medium
$ hcp create nodepool agent \ --cluster-name <hosted_cluster_name> \1 --name <nodepool_name> \2 --node-count <worker_node_count> \3 --agentLabelSelector size=medium4 Copy to Clipboard Copied! Toggle word wrap Toggle overflow cluster 네임스페이스에
nodepool리소스를 나열하여 노드 풀의상태를확인합니다.oc get nodepools --namespace clusters
$ oc get nodepools --namespace clustersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여
admin-kubeconfig시크릿을 추출합니다.oc extract -n <hosted_control_plane_namespace> secret/admin-kubeconfig --to=./hostedcluster-secrets --confirm
$ oc extract -n <hosted_control_plane_namespace> secret/admin-kubeconfig --to=./hostedcluster-secrets --confirmCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
hostedcluster-secrets/kubeconfig
hostedcluster-secrets/kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 잠시 후 다음 명령을 입력하여 노드 풀의 상태를 확인할 수 있습니다.
oc --kubeconfig ./hostedcluster-secrets get nodes
$ oc --kubeconfig ./hostedcluster-secrets get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 입력하여 사용 가능한 노드 풀 수가 예상 노드 풀 수와 일치하는지 확인합니다.
oc get nodepools --namespace clusters
$ oc get nodepools --namespace clustersCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.2.2. 호스트 클러스터의 노드 자동 확장 활성화 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 클러스터에 용량이 더 필요하고 예비 에이전트를 사용할 수 있는 경우 자동 확장을 활성화하여 새 작업자 노드를 설치할 수 있습니다.
프로세스
자동 확장을 활성화하려면 다음 명령을 입력합니다.
oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> \ --type=json \ -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'$ oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> \ --type=json \ -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고이 예에서 최소 노드 수는 2이고 최대값은 5입니다. 추가할 수 있는 최대 노드 수는 플랫폼에 바인딩될 수 있습니다. 예를 들어 에이전트 플랫폼을 사용하는 경우 사용 가능한 에이전트 수에 따라 최대 노드 수가 바인딩됩니다.
새 노드가 필요한 워크로드를 생성합니다.
다음 예제를 사용하여 워크로드 구성이 포함된 YAML 파일을 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
파일을
workload-config.yaml로 저장합니다. 다음 명령을 입력하여 YAML을 적용합니다.
oc apply -f workload-config.yaml
$ oc apply -f workload-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 명령을 입력하여
admin-kubeconfig시크릿을 추출합니다.oc extract -n <hosted_cluster_namespace> \ secret/<hosted_cluster_name>-admin-kubeconfig \ --to=./hostedcluster-secrets --confirm
$ oc extract -n <hosted_cluster_namespace> \ secret/<hosted_cluster_name>-admin-kubeconfig \ --to=./hostedcluster-secrets --confirmCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
hostedcluster-secrets/kubeconfig
hostedcluster-secrets/kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 새 노드가
Ready상태에 있는지 확인할 수 있습니다.oc --kubeconfig ./hostedcluster-secrets get nodes
$ oc --kubeconfig ./hostedcluster-secrets get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 노드를 제거하려면 다음 명령을 입력하여 워크로드를 삭제합니다.
oc --kubeconfig ./hostedcluster-secrets -n <namespace> \ delete deployment <deployment_name>
$ oc --kubeconfig ./hostedcluster-secrets -n <namespace> \ delete deployment <deployment_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 추가 용량을 요구하지 않고 몇 분 정도 경과할 때까지 기다립니다. 에이전트 플랫폼에서 에이전트는 해제되어 재사용될 수 있습니다. 다음 명령을 입력하여 노드가 제거되었는지 확인할 수 있습니다.
oc --kubeconfig ./hostedcluster-secrets get nodes
$ oc --kubeconfig ./hostedcluster-secrets get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고IBM Z® 에이전트의 경우 Processor Resource/Systems Manager (PR/SM) 모드에서 OSA 네트워크 장치를 사용하는 경우 자동 확장이 지원되지 않습니다. 축소 프로세스 중 새 에이전트가 결합되므로 기존 에이전트를 수동으로 삭제하고 노드 풀을 확장해야 합니다.
5.2.2.3. 호스트 클러스터의 노드 자동 확장 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
노드 자동 확장을 비활성화하려면 다음 절차를 완료합니다.
프로세스
다음 명령을 입력하여 호스팅된 클러스터의 노드 자동 스케일링을 비활성화합니다.
oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> \ --type=json \ -p '[\{"op":"remove", "path": "/spec/autoScaling"}, \{"op": "add", "path": "/spec/replicas", "value": <specify_value_to_scale_replicas>]'$ oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> \ --type=json \ -p '[\{"op":"remove", "path": "/spec/autoScaling"}, \{"op": "add", "path": "/spec/replicas", "value": <specify_value_to_scale_replicas>]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 명령은 YAML 파일에서
"spec.autoScaling"을 제거하고"spec.replicas"를 추가하고 지정한 정수 값에"spec.replicas"를 설정합니다.
5.2.3. 베어 메탈의 호스트 클러스터에서 수신 처리 링크 복사링크가 클립보드에 복사되었습니다!
모든 OpenShift Container Platform 클러스터에는 일반적으로 연결된 외부 DNS 레코드가 있는 기본 애플리케이션 Ingress 컨트롤러가 있습니다. 예를 들어 기본 도메인 krnl.es 를 사용하여 example 이라는 호스팅 클러스터를 생성하는 경우 와일드카드 도메인 *.apps.example.krnl.es 를 라우팅할 수 있을 것으로 예상할 수 있습니다.
프로세스
*.apps 도메인의 로드 밸런서 및 와일드카드 DNS 레코드를 설정하려면 게스트 클러스터에서 다음 작업을 수행합니다.
MetalLB Operator의 구성이 포함된 YAML 파일을 생성하여 MetalLB를 배포합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
파일을
metallb-operator-config.yaml로 저장합니다. 다음 명령을 입력하여 구성을 적용합니다.
oc apply -f metallb-operator-config.yaml
$ oc apply -f metallb-operator-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Operator가 실행되면 MetalLB 인스턴스를 생성합니다.
MetalLB 인스턴스의 구성이 포함된 YAML 파일을 생성합니다.
apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb
apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallbCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
파일을
metallb-instance-config.yaml로 저장합니다. 다음 명령을 입력하여 MetalLB 인스턴스를 생성합니다.
oc apply -f metallb-instance-config.yaml
$ oc apply -f metallb-instance-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
단일 IP 주소를 사용하여
IPAddressPool리소스를 만듭니다. 이 IP 주소는 클러스터 노드에서 사용하는 네트워크와 동일한 서브넷에 있어야 합니다.다음 예와 같은 콘텐츠를 사용하여
ipaddresspool.yaml과 같은 파일을 만듭니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 IP 주소 풀에 대한 구성을 적용합니다.
oc apply -f ipaddresspool.yaml
$ oc apply -f ipaddresspool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
L2 광고를 생성합니다.
다음 예와 같은 콘텐츠를 사용하여
l2advertisement.yaml과 같은 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 구성을 적용합니다.
oc apply -f l2advertisement.yaml
$ oc apply -f l2advertisement.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
LoadBalancer유형의 서비스를 생성한 후 MetalLB는 서비스에 대한 외부 IP 주소를 추가합니다.metallb-loadbalancer-service.yaml이라는 YAML 파일을 생성하여 Ingress 트래픽을 Ingress 배포로 라우팅하는 새 로드 밸런서 서비스를 구성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
metallb-loadbalancer-service.yaml파일을 저장합니다. 다음 명령을 입력하여 YAML 구성을 적용합니다.
oc apply -f metallb-loadbalancer-service.yaml
$ oc apply -f metallb-loadbalancer-service.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 OpenShift Container Platform 콘솔에 연결합니다.
curl -kI https://console-openshift-console.apps.example.krnl.es
$ curl -kI https://console-openshift-console.apps.example.krnl.esCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
HTTP/1.1 200 OK
HTTP/1.1 200 OKCopy to Clipboard Copied! Toggle word wrap Toggle overflow clusterversion및clusteroperator값을 확인하여 모든 항목이 실행 중인지 확인합니다. 다음 명령을 실행합니다.oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,coCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow &
lt;4.x.y>를 사용하려는 지원되는 OpenShift Container Platform 버전 (예:4.20.0-multi)으로 바꿉니다.
5.2.4. 베어 메탈에서 머신 상태 점검 활성화 링크 복사링크가 클립보드에 복사되었습니다!
베어 메탈에서 머신 상태 점검을 활성화하여 비정상 관리형 클러스터 노드를 자동으로 복구 및 교체할 수 있습니다. 관리 클러스터에 설치할 준비가 된 추가 에이전트 시스템이 있어야 합니다.
머신 상태 점검을 활성화하기 전에 다음 제한 사항을 고려하십시오.
-
MachineHealthCheck오브젝트는 수정할 수 없습니다. -
머신 상태 점검에서는 두 개 이상의 노드가
False또는Unknown상태가 8분 이상 유지되는 경우에만 노드를 교체합니다.
관리형 클러스터 노드에 대한 머신 상태 점검을 활성화하면 호스팅된 클러스터에 MachineHealthCheck 오브젝트가 생성됩니다.
프로세스
호스트 클러스터에서 머신 상태 점검을 활성화하려면 NodePool 리소스를 수정합니다. 다음 단계를 완료합니다.
NodePool리소스의spec.nodeDrainTimeout값이0s보다 큰지 확인합니다. <hosted_cluster_namespace>를 호스팅된 클러스터 네임스페이스의 이름으로 바꾸고 <nodepool_name>을 노드 풀 이름으로 바꿉니다. 다음 명령을 실행합니다.oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -o yaml | grep nodeDrainTimeout
$ oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -o yaml | grep nodeDrainTimeoutCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
nodeDrainTimeout: 30s
nodeDrainTimeout: 30sCopy to Clipboard Copied! Toggle word wrap Toggle overflow spec.nodeDrainTimeout값이0s보다 크면 다음 명령을 실행하여 값을 수정합니다.oc patch nodepool -n <hosted_cluster_namespace> <nodepool_name> -p '{"spec":{"nodeDrainTimeout": "30m"}}' --type=merge$ oc patch nodepool -n <hosted_cluster_namespace> <nodepool_name> -p '{"spec":{"nodeDrainTimeout": "30m"}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow NodePool리소스에서spec.management.autoRepair필드를true로 설정하여 머신 상태 점검을 활성화합니다. 다음 명령을 실행합니다.oc patch nodepool -n <hosted_cluster_namespace> <nodepool_name> -p '{"spec": {"management": {"autoRepair":true}}}' --type=merge$ oc patch nodepool -n <hosted_cluster_namespace> <nodepool_name> -p '{"spec": {"management": {"autoRepair":true}}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
NodePool리소스가autoRepair: true값으로 업데이트되었는지 확인합니다.oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -o yaml | grep autoRepair
$ oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -o yaml | grep autoRepairCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.2.5. 베어 메탈에서 머신 상태 점검 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
관리형 클러스터 노드의 머신 상태 점검을 비활성화하려면 NodePool 리소스를 수정합니다.
프로세스
NodePool리소스에서spec.management.autoRepair필드를false로 설정하여 머신 상태 점검을 비활성화합니다. 다음 명령을 실행합니다.oc patch nodepool -n <hosted_cluster_namespace> <nodepool_name> -p '{"spec": {"management": {"autoRepair":false}}}' --type=merge$ oc patch nodepool -n <hosted_cluster_namespace> <nodepool_name> -p '{"spec": {"management": {"autoRepair":false}}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
NodePool리소스가autoRepair: false값으로 업데이트되었는지 확인합니다.oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -o yaml | grep autoRepair
$ oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -o yaml | grep autoRepairCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3. OpenShift Virtualization에서 호스트된 컨트롤 플레인 관리 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Virtualization에 호스팅된 클러스터를 배포한 후 다음 절차를 완료하여 클러스터를 관리할 수 있습니다.
5.3.1. 호스트된 클러스터에 액세스 링크 복사링크가 클립보드에 복사되었습니다!
리소스에서 직접 kubeconfig 파일 및 kubeadmin 자격 증명을 가져오거나 hcp 명령줄 인터페이스를 사용하여 kubeconfig 파일을 생성하여 호스팅된 클러스터에 액세스할 수 있습니다.
사전 요구 사항
리소스에서 직접 kubeconfig 파일 및 인증 정보를 가져와 호스팅된 클러스터에 액세스하려면 호스팅 클러스터의 액세스 시크릿을 숙지해야 합니다. 호스팅된 클러스터(호스트링) 네임스페이스에는 호스팅 된 클러스터 리소스 및 액세스 보안이 포함되어 있습니다. 호스팅된 컨트롤 플레인 네임스페이스는 호스팅된 컨트롤 플레인이 실행되는 위치입니다.
보안 이름 형식은 다음과 같습니다.
-
kubeconfig시크릿: <hosted_cluster_namespace>-<name>-admin-kubeconfig(clusters-hypershift-demo-admin-kubeconfig) -
kubeadmin암호 시크릿: <hosted_cluster_namespace>-<name>-kubeadmin-password(clusters-hypershift-demo-kubeadmin-password)
kubeconfig 시크릿에는 Base64로 인코딩된 kubeconfig 필드가 포함되어 있으며 다음 명령과 함께 사용할 파일에 디코딩하고 저장할 수 있습니다.
oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
kubeadmin 암호 시크릿도 Base64로 인코딩됩니다. 이를 디코딩하고 암호를 사용하여 호스팅된 클러스터의 API 서버 또는 콘솔에 로그인할 수 있습니다.
프로세스
hcpCLI를 사용하여kubeconfig파일을 생성하여 호스팅된 클러스터에 액세스하려면 다음 단계를 수행합니다.다음 명령을 입력하여
kubeconfig파일을 생성합니다.hcp create kubeconfig --namespace <hosted_cluster_namespace> \ --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
$ hcp create kubeconfig --namespace <hosted_cluster_namespace> \ --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow kubeconfig파일을 저장한 후 다음 예제 명령을 입력하여 호스팅된 클러스터에 액세스할 수 있습니다.oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.2. 호스트 클러스터의 노드 자동 확장 활성화 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 클러스터에 용량이 더 필요하고 예비 에이전트를 사용할 수 있는 경우 자동 확장을 활성화하여 새 작업자 노드를 설치할 수 있습니다.
프로세스
자동 확장을 활성화하려면 다음 명령을 입력합니다.
oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> \ --type=json \ -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'$ oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> \ --type=json \ -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고이 예에서 최소 노드 수는 2이고 최대값은 5입니다. 추가할 수 있는 최대 노드 수는 플랫폼에 바인딩될 수 있습니다. 예를 들어 에이전트 플랫폼을 사용하는 경우 사용 가능한 에이전트 수에 따라 최대 노드 수가 바인딩됩니다.
새 노드가 필요한 워크로드를 생성합니다.
다음 예제를 사용하여 워크로드 구성이 포함된 YAML 파일을 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
파일을
workload-config.yaml로 저장합니다. 다음 명령을 입력하여 YAML을 적용합니다.
oc apply -f workload-config.yaml
$ oc apply -f workload-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 명령을 입력하여
admin-kubeconfig시크릿을 추출합니다.oc extract -n <hosted_cluster_namespace> \ secret/<hosted_cluster_name>-admin-kubeconfig \ --to=./hostedcluster-secrets --confirm
$ oc extract -n <hosted_cluster_namespace> \ secret/<hosted_cluster_name>-admin-kubeconfig \ --to=./hostedcluster-secrets --confirmCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
hostedcluster-secrets/kubeconfig
hostedcluster-secrets/kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 새 노드가
Ready상태에 있는지 확인할 수 있습니다.oc --kubeconfig ./hostedcluster-secrets get nodes
$ oc --kubeconfig ./hostedcluster-secrets get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 노드를 제거하려면 다음 명령을 입력하여 워크로드를 삭제합니다.
oc --kubeconfig ./hostedcluster-secrets -n <namespace> \ delete deployment <deployment_name>
$ oc --kubeconfig ./hostedcluster-secrets -n <namespace> \ delete deployment <deployment_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 추가 용량을 요구하지 않고 몇 분 정도 경과할 때까지 기다립니다. 에이전트 플랫폼에서 에이전트는 해제되어 재사용될 수 있습니다. 다음 명령을 입력하여 노드가 제거되었는지 확인할 수 있습니다.
oc --kubeconfig ./hostedcluster-secrets get nodes
$ oc --kubeconfig ./hostedcluster-secrets get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고IBM Z® 에이전트의 경우 Processor Resource/Systems Manager (PR/SM) 모드에서 OSA 네트워크 장치를 사용하는 경우 자동 확장이 지원되지 않습니다. 축소 프로세스 중 새 에이전트가 결합되므로 기존 에이전트를 수동으로 삭제하고 노드 풀을 확장해야 합니다.
5.3.3. OpenShift Virtualization에서 호스팅된 컨트롤 플레인을 위한 스토리지 구성 링크 복사링크가 클립보드에 복사되었습니다!
고급 스토리지 구성을 제공하지 않으면 KubeVirt VM(가상 머신) 이미지, KubeVirt CSI(Container Storage Interface) 매핑 및 etcd 볼륨에 기본 스토리지 클래스가 사용됩니다.
다음 표에는 호스팅 클러스터에서 영구 스토리지를 지원하기 위해 인프라가 제공해야 하는 기능이 나열되어 있습니다.
| 인프라 CSI 공급자 | 호스트된 클러스터 CSI 공급자 | 호스트된 클러스터 기능 |
|---|---|---|
|
모든 RWX |
|
|
|
모든 RWX | Red Hat OpenShift Data Foundation |
Red Hat OpenShift Data Foundation 기능 세트. 외부 모드는 풋프린트가 작으며 독립 실행형 Red Hat Ceph Storage를 사용합니다. 내부 모드에는 더 큰 설치 공간이 있지만 자체 포함되어 있으며 RWX 파일과 같은 확장된 기능이 필요한 사용 사례에 |
OpenShift Virtualization은 호스트된 클러스터에서 스토리지를 처리하므로 특히 블록 스토리지로 제한된 요구 사항이 있는 고객에게 도움이 됩니다.
5.3.3.1. KubeVirt CSI 스토리지 클래스 매핑 링크 복사링크가 클립보드에 복사되었습니다!
kubevirt CSI는 RWX( ReadWriteMany ) 액세스를 수행할 수 있는 인프라 스토리지 클래스 매핑을 지원합니다. 클러스터 생성 중에 인프라 스토리지 클래스를 호스팅된 스토리지 클래스에 매핑할 수 있습니다.
프로세스
인프라 스토리지 클래스를 호스팅된 스토리지 클래스에 매핑하려면 다음 명령을 실행하여
--infra-storage-class-mapping인수를 사용합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 호스팅된 클러스터의 이름을 지정합니다(
예: ). - 2
- 작업자 수를 지정합니다(예:
2). - 3
- 풀 시크릿의 경로를 지정합니다(예:
/user/name/pullsecret). - 4
- 메모리 값을 지정합니다(예:
8Gi). - 5
- CPU 값을 지정합니다(예:
2). - 6
- <
infrastructure_storage_class>를 인프라 스토리지 클래스 이름으로 바꾸고 <hosted_storage_class>를 호스팅된 클러스터 스토리지 클래스 이름으로 교체합니다.hcp create cluster명령 내에서--infra-storage-class-mapping인수를 여러 번 사용할 수 있습니다.
호스팅된 클러스터를 생성하면 인프라 스토리지 클래스가 호스팅된 클러스터 내에서 표시됩니다. 이러한 스토리지 클래스 중 하나를 사용하는 호스팅된 클러스터 내에 PVC(영구 볼륨 클레임)를 생성할 때 KubeVirt CSI는 클러스터 생성 중에 구성한 인프라 스토리지 클래스 매핑을 사용하여 해당 볼륨을 프로비저닝합니다.
kubevirt CSI는 RWX 액세스 권한이 있는 인프라 스토리지 클래스만 매핑을 지원합니다.
다음 표는 볼륨 및 액세스 모드 기능이 KubeVirt CSI 스토리지 클래스에 매핑하는 방법을 보여줍니다.
| 인프라 CSI 기능 | 호스트된 클러스터 CSI 기능 | VM 실시간 마이그레이션 지원 | 참고 |
|---|---|---|---|
|
RWX: |
| 지원됨 |
|
|
RWO |
RWO | 지원되지 않음 | 실시간 마이그레이션 지원 부족은 KubeVirt VM을 호스팅하는 기본 인프라 클러스터를 업데이트하는 기능에 영향을 미칩니다. |
|
RWO |
RWO | 지원되지 않음 |
실시간 마이그레이션 지원 부족은 KubeVirt VM을 호스팅하는 기본 인프라 클러스터를 업데이트하는 기능에 영향을 미칩니다. 인프라 |
5.3.3.2. 단일 KubeVirt CSI 볼륨 스냅샷 클래스 매핑 링크 복사링크가 클립보드에 복사되었습니다!
KubeVirt CSI를 사용하여 인프라 볼륨 스냅샷 클래스를 호스팅된 클러스터에 노출할 수 있습니다.
프로세스
볼륨 스냅샷 클래스를 호스트된 클러스터에 매핑하려면 호스트 클러스터를 생성할 때
--infra-volumesnapshot-class-mapping인수를 사용합니다. 다음 명령을 실행합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 호스팅된 클러스터의 이름을 지정합니다(
예: ). - 2
- 작업자 수를 지정합니다(예:
2). - 3
- 풀 시크릿의 경로를 지정합니다(예:
/user/name/pullsecret). - 4
- 메모리 값을 지정합니다(예:
8Gi). - 5
- CPU 값을 지정합니다(예:
2). - 6
- &
lt;infrastructure_storage_class>를 인프라 클러스터에 있는 스토리지 클래스로 바꿉니다. <hosted_storage_class>를 호스트된 클러스터에 있는 스토리지 클래스로 바꿉니다. - 7
- &
lt;infrastructure_volume_snapshot_class>를 인프라 클러스터에 있는 볼륨 스냅샷 클래스로 바꿉니다. <hosted_volume_snapshot_class>를 호스팅된 클러스터에 있는 볼륨 스냅샷 클래스로 바꿉니다.
참고--infra-storage-class-mapping및--infra-volumesnapshot-class-mapping인수를 사용하지 않는 경우 호스트된 클러스터는 기본 스토리지 클래스 및 볼륨 스냅샷 클래스를 사용하여 생성됩니다. 따라서 인프라 클러스터에서 기본 스토리지 클래스와 볼륨 스냅샷 클래스를 설정해야 합니다.
5.3.3.3. 여러 KubeVirt CSI 볼륨 스냅샷 클래스 매핑 링크 복사링크가 클립보드에 복사되었습니다!
특정 그룹에 할당하여 호스트된 클러스터에 여러 볼륨 스냅샷 클래스를 매핑할 수 있습니다. 인프라 스토리지 클래스와 볼륨 스냅샷 클래스는 동일한 그룹에 속하는 경우에만 서로 호환됩니다.
프로세스
여러 볼륨 스냅샷 클래스를 호스팅된 클러스터에 매핑하려면 호스트 클러스터를 생성할 때
group옵션을 사용합니다. 다음 명령을 실행합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 호스팅된 클러스터의 이름을 지정합니다(
예: ). - 2
- 작업자 수를 지정합니다(예:
2). - 3
- 풀 시크릿의 경로를 지정합니다(예:
/user/name/pullsecret). - 4
- 메모리 값을 지정합니다(예:
8Gi). - 5
- CPU 값을 지정합니다(예:
2). - 6
- &
lt;infrastructure_storage_class>를 인프라 클러스터에 있는 스토리지 클래스로 바꿉니다. <hosted_storage_class>를 호스트된 클러스터에 있는 스토리지 클래스로 바꿉니다. 그룹 이름으로 바꿉니다. 예를 들어infra-storage-class-mygroup/hosted-storage-class-mygroup,group=mygroup및infra-storage-class-mymap/hosted-storage-class-mymap,group=mymap. - 7
- &
lt;infrastructure_volume_snapshot_class>를 인프라 클러스터에 있는 볼륨 스냅샷 클래스로 바꿉니다. <hosted_volume_snapshot_class>를 호스팅된 클러스터에 있는 볼륨 스냅샷 클래스로 바꿉니다. 예를 들어infra-vol-snap-mygroup/hosted-vol-snap-mygroup,group=mygroup및infra-vol-snap-mymap/hosted-vol-snap-mymap,group=mymap.
5.3.3.4. KubeVirt VM 루트 볼륨 구성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 생성 시 --root-volume-storage-class 인수를 사용하여 KubeVirt VM 루트 볼륨을 호스팅하는 데 사용되는 스토리지 클래스를 구성할 수 있습니다.
프로세스
KubeVirt VM의 사용자 정의 스토리지 클래스 및 볼륨 크기를 설정하려면 다음 명령을 실행합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 결과적으로 PVC에서 호스팅되는 VM을 사용하여 호스트된 클러스터를 생성합니다.
5.3.3.5. KubeVirt VM 이미지 캐싱 활성화 링크 복사링크가 클립보드에 복사되었습니다!
KubeVirt VM 이미지 캐싱을 사용하여 클러스터 시작 시간과 스토리지 사용량을 모두 최적화할 수 있습니다. kubevirt VM 이미지 캐싱은 스마트 복제 및 ReadWriteMany 액세스 모드를 사용할 수 있는 스토리지 클래스를 사용할 수 있도록 지원합니다. 스마트 복제에 대한 자세한 내용은 스마트 복제 를 사용하여 데이터 볼륨 복제를 참조하십시오.
이미지 캐싱은 다음과 같이 작동합니다.
- VM 이미지는 호스팅된 클러스터와 연결된 PVC로 가져옵니다.
- 해당 PVC의 고유한 복제본은 클러스터에 작업자 노드로 추가되는 모든 KubeVirt VM에 대해 생성됩니다.
이미지 캐싱은 단일 이미지 가져오기만 요구하여 VM 시작 시간을 줄입니다. 스토리지 클래스가 COW(Copy-On-Write) 복제를 지원하는 경우 전체 클러스터 스토리지 사용량을 추가로 줄일 수 있습니다.
프로세스
이미지 캐싱을 활성화하려면 클러스터 생성 중에 다음 명령을 실행하여
--root-volume-cache-strategy=PVC인수를 사용합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.3.6. kubevirt CSI 스토리지 보안 및 격리 링크 복사링크가 클립보드에 복사되었습니다!
kubevirt CSI(Container Storage Interface)는 기본 인프라 클러스터의 스토리지 기능을 호스팅된 클러스터로 확장합니다. CSI 드라이버는 다음 보안 제약 조건을 사용하여 인프라 스토리지 클래스 및 호스팅 클러스터에 대한 안전하고 격리된 액세스를 보장합니다.
- 호스트 클러스터의 스토리지는 다른 호스팅 클러스터와 격리됩니다.
- 호스트 클러스터의 작업자 노드에는 인프라 클러스터에 대한 직접 API 액세스 권한이 없습니다. 호스트 클러스터는 제어된 KubeVirt CSI 인터페이스를 통해서만 인프라 클러스터에 스토리지를 프로비저닝할 수 있습니다.
- 호스트된 클러스터는 KubeVirt CSI 클러스터 컨트롤러에 액세스할 수 없습니다. 결과적으로 호스팅된 클러스터는 호스팅된 클러스터와 연결되지 않은 인프라 클러스터의 임의의 스토리지 볼륨에 액세스할 수 없습니다. KubeVirt CSI 클러스터 컨트롤러는 호스팅된 컨트롤 플레인 네임스페이스의 Pod에서 실행됩니다.
- KubeVirt CSI 클러스터 컨트롤러의 RBAC(역할 기반 액세스 제어)는 PVC(영구 볼륨 클레임) 액세스를 호스팅된 컨트롤 플레인 네임스페이스로만 제한합니다. 따라서 KubeVirt CSI 구성 요소는 다른 네임스페이스의 스토리지에 액세스할 수 없습니다.
5.3.3.7. etcd 스토리지 구성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 생성 시 --etcd-storage-class 인수를 사용하여 etcd 데이터를 호스팅하는 데 사용되는 스토리지 클래스를 구성할 수 있습니다.
프로세스
etcd의 스토리지 클래스를 구성하려면 다음 명령을 실행합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.4. hcp CLI를 사용하여 NVIDIA GPU 장치 연결 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Virtualization의 호스팅된 클러스터의 hcp 명령행 인터페이스(CLI)를 사용하여 하나 이상의 NVIDIA 그래픽 처리 장치(GPU) 장치를 노드 풀에 연결할 수 있습니다.
노드 풀에 NVIDIA GPU 장치를 연결하는 것은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 다음 링크를 참조하십시오.
사전 요구 사항
- NVIDIA GPU 장치를 GPU 장치가 있는 노드의 리소스로 노출했습니다. 자세한 내용은 NVIDIA GPU Operator with OpenShift Virtualization 에서 참조하십시오.
- NVIDIA GPU 장치를 노드의 확장 리소스로 노출하여 노드 풀에 할당했습니다.
프로세스
다음 명령을 실행하여 클러스터 생성 중에 GPU 장치를 노드 풀에 연결할 수 있습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 호스팅된 클러스터의 이름을 지정합니다(
예: ). - 2
- 작업자 수를 지정합니다(예:
3). - 3
- 풀 시크릿의 경로를 지정합니다(예:
/user/name/pullsecret). - 4
- 메모리 값을 지정합니다(예:
16Gi). - 5
- CPU 값을 지정합니다(예:
2). - 6
- GPU 장치 이름과 개수를 지정합니다(예:
--host-device-name="nvidia-a100,count:2").--host-device-name인수는 인프라 노드에서 GPU 장치의 이름과 노드 풀의 각 VM(가상 머신)에 연결할 GPU 장치의 수를 나타내는 선택적 개수를 사용합니다. 기본 수는1입니다. 예를 들어 2개의 GPU 장치를 3개의 노드 풀 복제본에 연결하면 노드 풀의 모든 VM이 2 GPU 장치에 연결됩니다.
작은 정보--host-device-name인수를 여러 번 사용하여 다양한 유형의 장치를 연결할 수 있습니다.
5.3.5. NodePool 리소스를 사용하여 NVIDIA GPU 장치 연결 링크 복사링크가 클립보드에 복사되었습니다!
NodePool 리소스에서 nodepool.spec.platform.kubevirt.hostDevices 필드를 구성하여 하나 이상의 NVIDIA 그래픽 처리 장치(GPU) 장치를 노드 풀에 연결할 수 있습니다.
노드 풀에 NVIDIA GPU 장치를 연결하는 것은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 다음 링크를 참조하십시오.
프로세스
노드 풀에 하나 이상의 GPU 장치를 연결합니다.
단일 GPU 장치를 연결하려면 다음 예제 구성을 사용하여
NodePool리소스를 구성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 호스팅된 클러스터의 이름을 지정합니다(
예: ). - 2
- 호스팅된 클러스터 네임스페이스의 이름을 지정합니다(예:
클러스터). - 3
- CPU 값을 지정합니다(예:
2). - 4
- 메모리 값을 지정합니다(예:
16Gi). - 5
hostDevices필드는 노드 풀에 연결할 수 있는 다양한 유형의 GPU 장치 목록을 정의합니다.- 6
- 노드 풀의 각 VM(가상 머신)에 연결할 GPU 장치 수를 지정합니다. 예를 들어 2개의 GPU 장치를 3개의 노드 풀 복제본에 연결하면 노드 풀의 모든 VM이 2 GPU 장치에 연결됩니다. 기본 수는
1입니다. - 7
- GPU 장치 이름을 지정합니다(예:
nvidia-a100). - 8
- 작업자 수를 지정합니다(예:
3).
여러 GPU 장치를 연결하려면 다음 예제 구성을 사용하여
NodePool리소스를 구성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.6. KubeVirt 가상 머신 제거 링크 복사링크가 클립보드에 복사되었습니다!
GPU 패스스루를 사용할 때와 같이 KubeVirt VM(VM)을 실시간 마이그레이션할 수 없는 경우 호스트된 클러스터의 NodePool 리소스와 동시에 VM을 제거해야 합니다. 그렇지 않으면 워크로드에서 컴퓨팅 노드를 드레이닝하지 않고 종료할 수 있습니다. 이는 OpenShift Virtualization Operator를 업그레이드하는 경우에도 발생할 수 있습니다. 동기화된 재시작을 수행하려면 하이퍼컨버지드 리소스에서 evictionStrategy 매개변수를 설정하여 워크로드에서 드레이닝된 VM만 재부팅되도록 할 수 있습니다.
프로세스
하이퍼컨버지드리소스 및evictionStrategy매개변수에 허용되는 값에 대한 자세한 내용을 보려면 다음 명령을 입력합니다.oc explain hyperconverged.spec.evictionStrategy
$ oc explain hyperconverged.spec.evictionStrategyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여
하이퍼컨버지드리소스를 패치합니다.oc -n openshift-cnv patch hyperconverged kubevirt-hyperconverged \ --type=merge \ -p '{"spec": {"evictionStrategy": "External"}}'$ oc -n openshift-cnv patch hyperconverged kubevirt-hyperconverged \ --type=merge \ -p '{"spec": {"evictionStrategy": "External"}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 워크로드 업데이트 전략 및 워크로드 업데이트 방법을 패치합니다.
oc -n openshift-cnv patch hyperconverged kubevirt-hyperconverged \ --type=merge \ -p '{"spec": {"workloadUpdateStrategy": {"workloadUpdateMethods": ["LiveMigrate","Evict"]}}}'$ oc -n openshift-cnv patch hyperconverged kubevirt-hyperconverged \ --type=merge \ -p '{"spec": {"workloadUpdateStrategy": {"workloadUpdateMethods": ["LiveMigrate","Evict"]}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 패치를 적용하면 가능한 경우 VM을 실시간 마이그레이션해야 하며 실시간으로 마이그레이션할 수 없는 VM만 제거되도록 지정합니다.
검증
다음 명령을 입력하여 패치 명령이 제대로 적용되었는지 확인합니다.
oc -n openshift-cnv get hyperconverged kubevirt-hyperconverged -ojsonpath='{.spec.evictionStrategy}'$ oc -n openshift-cnv get hyperconverged kubevirt-hyperconverged -ojsonpath='{.spec.evictionStrategy}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
External
ExternalCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.3.7. topologySpreadConstraint를 사용하여 노드 풀 VM 확산 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 노드 풀에서 생성한 KubeVirt 가상 머신(VM)은 VM을 실행할 용량이 있는 사용 가능한 모든 노드에 예약됩니다. 기본적으로 topologySpreadConstraint 제약 조건은 여러 노드에 VM을 예약하도록 설정됩니다.
일부 시나리오에서는 노드 풀 VM이 동일한 노드에서 실행될 수 있으므로 가용성 문제가 발생할 수 있습니다. 단일 노드에 VM을 배포하지 않으려면 Descheduler를 사용하여 topologySpreadConstraint 제약 조건을 지속적으로 준수하여 여러 노드에 VM을 분산합니다.
사전 요구 사항
- Kube Descheduler Operator가 설치되어 있어야 합니다. 자세한 내용은 "디스케줄러 설치"를 참조하십시오.
프로세스
다음 명령을 입력하여
KubeDeschedulerCR(사용자 정의 리소스)을 열고KubeDeschedulerCR을 수정하여SoftTopologyAndDuplicates및KubeVirtRelieveAndMigrate프로필을 사용하여topologySpreadConstraint제약 조건 설정을 유지합니다.cluster라는KubeDeschedulerCR은openshift-kube-descheduler-operator네임스페이스에서 실행됩니다.oc edit kubedescheduler cluster -n openshift-kube-descheduler-operator
$ oc edit kubedescheduler cluster -n openshift-kube-descheduler-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow KubeDescheduler구성의 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4. 베어 메탈이 아닌 에이전트 시스템에서 호스트된 컨트롤 플레인 관리 링크 복사링크가 클립보드에 복사되었습니다!
베어 메탈이 아닌 에이전트 시스템에 호스팅되는 컨트롤 플레인을 배포한 후 다음 작업을 완료하여 호스팅 클러스터를 관리할 수 있습니다.
5.4.1. 호스트된 클러스터에 액세스 링크 복사링크가 클립보드에 복사되었습니다!
리소스에서 직접 kubeconfig 파일 및 kubeadmin 자격 증명을 가져오거나 hcp 명령줄 인터페이스를 사용하여 kubeconfig 파일을 생성하여 호스팅된 클러스터에 액세스할 수 있습니다.
사전 요구 사항
리소스에서 직접 kubeconfig 파일 및 인증 정보를 가져와 호스팅된 클러스터에 액세스하려면 호스팅 클러스터의 액세스 시크릿을 숙지해야 합니다. 호스팅된 클러스터(호스트링) 네임스페이스에는 호스팅 된 클러스터 리소스 및 액세스 보안이 포함되어 있습니다. 호스팅된 컨트롤 플레인 네임스페이스는 호스팅된 컨트롤 플레인이 실행되는 위치입니다.
보안 이름 형식은 다음과 같습니다.
-
kubeconfig시크릿: <hosted_cluster_namespace>-<name>-admin-kubeconfig. 예를 들어 cluster-hypershift-demo-admin-kubeconfig. -
kubeadmin암호 시크릿: <hosted_cluster_namespace>-<name>-kubeadmin-password. 예를 들어 cluster-hypershift-demo-kubeadmin-password.
kubeconfig 시크릿에는 Base64로 인코딩된 kubeconfig 필드가 포함되어 있으며 다음 명령과 함께 사용할 파일에 디코딩하고 저장할 수 있습니다.
oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
kubeadmin 암호 시크릿도 Base64로 인코딩됩니다. 이를 디코딩하고 암호를 사용하여 호스팅된 클러스터의 API 서버 또는 콘솔에 로그인할 수 있습니다.
프로세스
hcpCLI를 사용하여kubeconfig파일을 생성하여 호스팅된 클러스터에 액세스하려면 다음 단계를 수행합니다.다음 명령을 입력하여
kubeconfig파일을 생성합니다.hcp create kubeconfig --namespace <hosted_cluster_namespace> \ --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
$ hcp create kubeconfig --namespace <hosted_cluster_namespace> \ --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow kubeconfig파일을 저장한 후 다음 예제 명령을 입력하여 호스팅된 클러스터에 액세스할 수 있습니다.oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4.2. 호스트 클러스터의 NodePool 오브젝트 스케일링 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 클러스터에 노드를 추가하여 NodePool 오브젝트를 확장할 수 있습니다. 노드 풀을 확장할 때 다음 정보를 고려하십시오.
- 노드 풀로 복제본을 확장하면 머신이 생성됩니다. 모든 머신에 대해 클러스터 API 공급자는 노드 풀 사양에 지정된 요구 사항을 충족하는 에이전트를 찾아 설치합니다. 에이전트의 상태 및 조건을 확인하여 에이전트 설치를 모니터링할 수 있습니다.
- 노드 풀을 축소하면 에이전트가 해당 클러스터에서 바인딩되지 않습니다. 에이전트를 재사용하려면 먼저 Discovery 이미지를 사용하여 다시 시작해야 합니다.
프로세스
NodePool오브젝트를 두 개의 노드로 확장합니다.oc -n <hosted_cluster_namespace> scale nodepool <nodepool_name> --replicas 2
$ oc -n <hosted_cluster_namespace> scale nodepool <nodepool_name> --replicas 2Copy to Clipboard Copied! Toggle word wrap Toggle overflow Cluster API 에이전트 공급자는 호스트 클러스터에 할당된 두 개의 에이전트를 임의로 선택합니다. 이러한 에이전트는 다른 상태를 통과하고 마지막으로 호스팅된 클러스터에 OpenShift Container Platform 노드로 참여합니다. 에이전트는 다음 순서로 상태를 통과합니다.
-
바인딩 -
검색 -
충분하지 않음 -
설치 -
installing-in-progress -
added-to-existing-cluster
-
다음 명령을 실행합니다.
oc -n <hosted_control_plane_namespace> get agent
$ oc -n <hosted_control_plane_namespace> get agentCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CLUSTER APPROVED ROLE STAGE 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 hypercluster1 true auto-assign d9198891-39f4-4930-a679-65fb142b108b true auto-assign da503cf1-a347-44f2-875c-4960ddb04091 hypercluster1 true auto-assign
NAME CLUSTER APPROVED ROLE STAGE 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 hypercluster1 true auto-assign d9198891-39f4-4930-a679-65fb142b108b true auto-assign da503cf1-a347-44f2-875c-4960ddb04091 hypercluster1 true auto-assignCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행합니다.
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}'$ 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 Copied! Toggle word wrap Toggle overflow 출력 예
BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficient
BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficientCopy to Clipboard Copied! Toggle word wrap Toggle overflow extract 명령을 입력하여 새 호스팅 클러스터에 대한 kubeconfig를 가져옵니다.
oc extract -n <hosted_cluster_namespace> \ secret/<hosted_cluster_name>-admin-kubeconfig --to=- \ > kubeconfig-<hosted_cluster_name>
$ oc extract -n <hosted_cluster_namespace> \ secret/<hosted_cluster_name>-admin-kubeconfig --to=- \ > kubeconfig-<hosted_cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 에이전트가
add-to-existing-cluster상태에 도달한 후 다음 명령을 입력하여 호스팅된 클러스터에 OpenShift Container Platform 노드를 볼 수 있는지 확인합니다.oc --kubeconfig kubeconfig-<hosted_cluster_name> get nodes
$ oc --kubeconfig kubeconfig-<hosted_cluster_name> get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME STATUS ROLES AGE VERSION ocp-worker-1 Ready worker 5m41s v1.24.0+3882f8f ocp-worker-2 Ready worker 6m3s v1.24.0+3882f8f
NAME STATUS ROLES AGE VERSION ocp-worker-1 Ready worker 5m41s v1.24.0+3882f8f ocp-worker-2 Ready worker 6m3s v1.24.0+3882f8fCopy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터 Operator는 노드에 워크로드를 추가하여 조정하기 시작합니다.
다음 명령을 입력하여
NodePool오브젝트를 확장할 때 두 개의 머신이 생성되었는지 확인합니다.oc -n <hosted_control_plane_namespace> get machines
$ oc -n <hosted_control_plane_namespace> get machinesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CLUSTER NODENAME PROVIDERID PHASE AGE VERSION hypercluster1-c96b6f675-m5vch hypercluster1-b2qhl ocp-worker-1 agent://da503cf1-a347-44f2-875c-4960ddb04091 Running 15m 4.x.z hypercluster1-c96b6f675-tl42p hypercluster1-b2qhl ocp-worker-2 agent://4dac1ab2-7dd5-4894-a220-6a3473b67ee6 Running 15m 4.x.z
NAME CLUSTER NODENAME PROVIDERID PHASE AGE VERSION hypercluster1-c96b6f675-m5vch hypercluster1-b2qhl ocp-worker-1 agent://da503cf1-a347-44f2-875c-4960ddb04091 Running 15m 4.x.z hypercluster1-c96b6f675-tl42p hypercluster1-b2qhl ocp-worker-2 agent://4dac1ab2-7dd5-4894-a220-6a3473b67ee6 Running 15m 4.x.zCopy to Clipboard Copied! Toggle word wrap Toggle overflow clusterversion조정 프로세스는 결국 Ingress 및 Console 클러스터 Operator만 누락된 지점에 도달합니다.다음 명령을 실행합니다.
oc --kubeconfig kubeconfig-<hosted_cluster_name> get clusterversion,co
$ oc --kubeconfig kubeconfig-<hosted_cluster_name> get clusterversion,coCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4.2.1. 노드 풀 추가 링크 복사링크가 클립보드에 복사되었습니다!
이름, 복제본 수 및 에이전트 라벨 선택기와 같은 추가 정보를 지정하여 호스팅된 클러스터에 대한 노드 풀을 생성할 수 있습니다.
호스트된 각 클러스터에 대해 단일 에이전트 네임스페이스만 지원됩니다. 결과적으로 호스트된 클러스터에 노드 풀을 추가할 때 노드 풀은 단일 InfraEnv 리소스 또는 동일한 에이전트 네임스페이스에 있는 InfraEnv 리소스에서 있어야 합니다.
프로세스
노드 풀을 생성하려면 다음 정보를 입력합니다.
hcp create nodepool agent \ --cluster-name <hosted_cluster_name> \ --name <nodepool_name> \ --node-count <worker_node_count> \ --agentLabelSelector size=medium
$ hcp create nodepool agent \ --cluster-name <hosted_cluster_name> \1 --name <nodepool_name> \2 --node-count <worker_node_count> \3 --agentLabelSelector size=medium4 Copy to Clipboard Copied! Toggle word wrap Toggle overflow cluster 네임스페이스에
nodepool리소스를 나열하여 노드 풀의상태를확인합니다.oc get nodepools --namespace clusters
$ oc get nodepools --namespace clustersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여
admin-kubeconfig시크릿을 추출합니다.oc extract -n <hosted_control_plane_namespace> secret/admin-kubeconfig --to=./hostedcluster-secrets --confirm
$ oc extract -n <hosted_control_plane_namespace> secret/admin-kubeconfig --to=./hostedcluster-secrets --confirmCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
hostedcluster-secrets/kubeconfig
hostedcluster-secrets/kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 잠시 후 다음 명령을 입력하여 노드 풀의 상태를 확인할 수 있습니다.
oc --kubeconfig ./hostedcluster-secrets get nodes
$ oc --kubeconfig ./hostedcluster-secrets get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 입력하여 사용 가능한 노드 풀 수가 예상 노드 풀 수와 일치하는지 확인합니다.
oc get nodepools --namespace clusters
$ oc get nodepools --namespace clustersCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4.2.2. 호스트 클러스터의 노드 자동 확장 활성화 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 클러스터에 용량이 더 필요하고 예비 에이전트를 사용할 수 있는 경우 자동 확장을 활성화하여 새 작업자 노드를 설치할 수 있습니다.
프로세스
자동 확장을 활성화하려면 다음 명령을 입력합니다.
oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> \ --type=json \ -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'$ oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> \ --type=json \ -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고이 예에서 최소 노드 수는 2이고 최대값은 5입니다. 추가할 수 있는 최대 노드 수는 플랫폼에 바인딩될 수 있습니다. 예를 들어 에이전트 플랫폼을 사용하는 경우 사용 가능한 에이전트 수에 따라 최대 노드 수가 바인딩됩니다.
새 노드가 필요한 워크로드를 생성합니다.
다음 예제를 사용하여 워크로드 구성이 포함된 YAML 파일을 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
파일을
workload-config.yaml로 저장합니다. 다음 명령을 입력하여 YAML을 적용합니다.
oc apply -f workload-config.yaml
$ oc apply -f workload-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 명령을 입력하여
admin-kubeconfig시크릿을 추출합니다.oc extract -n <hosted_cluster_namespace> \ secret/<hosted_cluster_name>-admin-kubeconfig \ --to=./hostedcluster-secrets --confirm
$ oc extract -n <hosted_cluster_namespace> \ secret/<hosted_cluster_name>-admin-kubeconfig \ --to=./hostedcluster-secrets --confirmCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
hostedcluster-secrets/kubeconfig
hostedcluster-secrets/kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 새 노드가
Ready상태에 있는지 확인할 수 있습니다.oc --kubeconfig ./hostedcluster-secrets get nodes
$ oc --kubeconfig ./hostedcluster-secrets get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 노드를 제거하려면 다음 명령을 입력하여 워크로드를 삭제합니다.
oc --kubeconfig ./hostedcluster-secrets -n <namespace> \ delete deployment <deployment_name>
$ oc --kubeconfig ./hostedcluster-secrets -n <namespace> \ delete deployment <deployment_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 추가 용량을 요구하지 않고 몇 분 정도 경과할 때까지 기다립니다. 에이전트 플랫폼에서 에이전트는 해제되어 재사용될 수 있습니다. 다음 명령을 입력하여 노드가 제거되었는지 확인할 수 있습니다.
oc --kubeconfig ./hostedcluster-secrets get nodes
$ oc --kubeconfig ./hostedcluster-secrets get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고IBM Z® 에이전트의 경우 Processor Resource/Systems Manager (PR/SM) 모드에서 OSA 네트워크 장치를 사용하는 경우 자동 확장이 지원되지 않습니다. 축소 프로세스 중 새 에이전트가 결합되므로 기존 에이전트를 수동으로 삭제하고 노드 풀을 확장해야 합니다.
5.4.2.3. 호스트 클러스터의 노드 자동 확장 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
노드 자동 확장을 비활성화하려면 다음 절차를 완료합니다.
프로세스
다음 명령을 입력하여 호스팅된 클러스터의 노드 자동 스케일링을 비활성화합니다.
oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> \ --type=json \ -p '[\{"op":"remove", "path": "/spec/autoScaling"}, \{"op": "add", "path": "/spec/replicas", "value": <specify_value_to_scale_replicas>]'$ oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> \ --type=json \ -p '[\{"op":"remove", "path": "/spec/autoScaling"}, \{"op": "add", "path": "/spec/replicas", "value": <specify_value_to_scale_replicas>]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 명령은 YAML 파일에서
"spec.autoScaling"을 제거하고"spec.replicas"를 추가하고 지정한 정수 값에"spec.replicas"를 설정합니다.
5.4.3. 비bare-metal 에이전트 시스템의 호스트 클러스터에서 수신 처리 링크 복사링크가 클립보드에 복사되었습니다!
모든 OpenShift Container Platform 클러스터에는 일반적으로 연결된 외부 DNS 레코드가 있는 기본 애플리케이션 Ingress 컨트롤러가 있습니다. 예를 들어 기본 도메인 krnl.es 를 사용하여 example 이라는 호스팅 클러스터를 생성하는 경우 와일드카드 도메인 *.apps.example.krnl.es 를 라우팅할 수 있을 것으로 예상할 수 있습니다.
프로세스
*.apps 도메인의 로드 밸런서 및 와일드카드 DNS 레코드를 설정하려면 게스트 클러스터에서 다음 작업을 수행합니다.
MetalLB Operator의 구성이 포함된 YAML 파일을 생성하여 MetalLB를 배포합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
파일을
metallb-operator-config.yaml로 저장합니다. 다음 명령을 입력하여 구성을 적용합니다.
oc apply -f metallb-operator-config.yaml
$ oc apply -f metallb-operator-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Operator가 실행되면 MetalLB 인스턴스를 생성합니다.
MetalLB 인스턴스의 구성이 포함된 YAML 파일을 생성합니다.
apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallb
apiVersion: metallb.io/v1beta1 kind: MetalLB metadata: name: metallb namespace: metallbCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
파일을
metallb-instance-config.yaml로 저장합니다. 다음 명령을 입력하여 MetalLB 인스턴스를 생성합니다.
oc apply -f metallb-instance-config.yaml
$ oc apply -f metallb-instance-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
단일 IP 주소를 사용하여
IPAddressPool리소스를 만듭니다. 이 IP 주소는 클러스터 노드에서 사용하는 네트워크와 동일한 서브넷에 있어야 합니다.다음 예와 같은 콘텐츠를 사용하여
ipaddresspool.yaml과 같은 파일을 만듭니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 IP 주소 풀에 대한 구성을 적용합니다.
oc apply -f ipaddresspool.yaml
$ oc apply -f ipaddresspool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
L2 광고를 생성합니다.
다음 예와 같은 콘텐츠를 사용하여
l2advertisement.yaml과 같은 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 구성을 적용합니다.
oc apply -f l2advertisement.yaml
$ oc apply -f l2advertisement.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
LoadBalancer유형의 서비스를 생성한 후 MetalLB는 서비스에 대한 외부 IP 주소를 추가합니다.metallb-loadbalancer-service.yaml이라는 YAML 파일을 생성하여 Ingress 트래픽을 Ingress 배포로 라우팅하는 새 로드 밸런서 서비스를 구성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
metallb-loadbalancer-service.yaml파일을 저장합니다. 다음 명령을 입력하여 YAML 구성을 적용합니다.
oc apply -f metallb-loadbalancer-service.yaml
$ oc apply -f metallb-loadbalancer-service.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 OpenShift Container Platform 콘솔에 연결합니다.
curl -kI https://console-openshift-console.apps.example.krnl.es
$ curl -kI https://console-openshift-console.apps.example.krnl.esCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
HTTP/1.1 200 OK
HTTP/1.1 200 OKCopy to Clipboard Copied! Toggle word wrap Toggle overflow clusterversion및clusteroperator값을 확인하여 모든 항목이 실행 중인지 확인합니다. 다음 명령을 실행합니다.oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,co
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion,coCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow &
lt;4.x.y>를 사용하려는 지원되는 OpenShift Container Platform 버전 (예:4.20.0-multi)으로 바꿉니다.
5.4.4. 베어 메탈이 아닌 에이전트 머신에서 머신 상태 점검 활성화 링크 복사링크가 클립보드에 복사되었습니다!
베어 메탈에서 머신 상태 점검을 활성화하여 비정상 관리형 클러스터 노드를 자동으로 복구 및 교체할 수 있습니다. 관리 클러스터에 설치할 준비가 된 추가 에이전트 시스템이 있어야 합니다.
머신 상태 점검을 활성화하기 전에 다음 제한 사항을 고려하십시오.
-
MachineHealthCheck오브젝트는 수정할 수 없습니다. -
머신 상태 점검에서는 두 개 이상의 노드가
False또는Unknown상태가 8분 이상 유지되는 경우에만 노드를 교체합니다.
관리형 클러스터 노드에 대한 머신 상태 점검을 활성화하면 호스팅된 클러스터에 MachineHealthCheck 오브젝트가 생성됩니다.
프로세스
호스트 클러스터에서 머신 상태 점검을 활성화하려면 NodePool 리소스를 수정합니다. 다음 단계를 완료합니다.
NodePool리소스의spec.nodeDrainTimeout값이0s보다 큰지 확인합니다. <hosted_cluster_namespace>를 호스팅된 클러스터 네임스페이스의 이름으로 바꾸고 <nodepool_name>을 노드 풀 이름으로 바꿉니다. 다음 명령을 실행합니다.oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -o yaml | grep nodeDrainTimeout
$ oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -o yaml | grep nodeDrainTimeoutCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
nodeDrainTimeout: 30s
nodeDrainTimeout: 30sCopy to Clipboard Copied! Toggle word wrap Toggle overflow spec.nodeDrainTimeout값이0s보다 크면 다음 명령을 실행하여 값을 수정합니다.oc patch nodepool -n <hosted_cluster_namespace> <nodepool_name> -p '{"spec":{"nodeDrainTimeout": "30m"}}' --type=merge$ oc patch nodepool -n <hosted_cluster_namespace> <nodepool_name> -p '{"spec":{"nodeDrainTimeout": "30m"}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow NodePool리소스에서spec.management.autoRepair필드를true로 설정하여 머신 상태 점검을 활성화합니다. 다음 명령을 실행합니다.oc patch nodepool -n <hosted_cluster_namespace> <nodepool_name> -p '{"spec": {"management": {"autoRepair":true}}}' --type=merge$ oc patch nodepool -n <hosted_cluster_namespace> <nodepool_name> -p '{"spec": {"management": {"autoRepair":true}}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
NodePool리소스가autoRepair: true값으로 업데이트되었는지 확인합니다.oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -o yaml | grep autoRepair
$ oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -o yaml | grep autoRepairCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4.5. 베어 메탈이 아닌 에이전트 머신에서 머신 상태 점검 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
관리형 클러스터 노드의 머신 상태 점검을 비활성화하려면 NodePool 리소스를 수정합니다.
프로세스
NodePool리소스에서spec.management.autoRepair필드를false로 설정하여 머신 상태 점검을 비활성화합니다. 다음 명령을 실행합니다.oc patch nodepool -n <hosted_cluster_namespace> <nodepool_name> -p '{"spec": {"management": {"autoRepair":false}}}' --type=merge$ oc patch nodepool -n <hosted_cluster_namespace> <nodepool_name> -p '{"spec": {"management": {"autoRepair":false}}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
NodePool리소스가autoRepair: false값으로 업데이트되었는지 확인합니다.oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -o yaml | grep autoRepair
$ oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -o yaml | grep autoRepairCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.5. IBM Power에서 호스트된 컨트롤 플레인 관리 링크 복사링크가 클립보드에 복사되었습니다!
IBM Power에 호스팅된 컨트롤 플레인을 배포한 후 다음 작업을 완료하여 호스트된 클러스터를 관리할 수 있습니다.
5.5.1. IBM Power에서 호스팅된 컨트롤 플레인에 대한 InfraEnv 리소스 생성 링크 복사링크가 클립보드에 복사되었습니다!
InfraEnv 는 라이브 ISO를 시작하는 호스트가 에이전트로 참여할 수 있는 환경입니다. 이 경우 에이전트는 호스팅된 컨트롤 플레인과 동일한 네임스페이스에 생성됩니다.
IBM Power 컴퓨팅 노드의 64비트 x86 베어 메탈에서 호스팅된 컨트롤 플레인에 대한 InfraEnv 리소스를 생성할 수 있습니다.
프로세스
YAML 파일을 생성하여
InfraEnv리소스를 구성합니다. 다음 예제를 참조하십시오.Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
파일을
infraenv-config.yaml로 저장합니다. 다음 명령을 입력하여 구성을 적용합니다.
oc apply -f infraenv-config.yaml
$ oc apply -f infraenv-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow IBM Power 머신이 에이전트로 결합할 수 있는 라이브 ISO를 다운로드하는 URL을 가져오려면 다음 명령을 입력합니다.
oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name> \ -o json
$ oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name> \ -o jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.5.2. InfraEnv 리소스에 IBM Power 에이전트 추가 링크 복사링크가 클립보드에 복사되었습니다!
라이브 ISO로 시작하도록 시스템을 수동으로 구성하여 에이전트를 추가할 수 있습니다.
프로세스
-
라이브 ISO를 다운로드하여 베어 메탈 또는 VM(가상 머신) 호스트를 시작하는 데 사용합니다. 라이브 ISO의 URL은
InfraEnv리소스에서status.isoDownloadURL필드에서 찾을 수 있습니다. 시작 시 호스트는 지원 서비스와 통신하고InfraEnv리소스와 동일한 네임스페이스에 에이전트로 등록합니다. 에이전트 및 일부 속성을 나열하려면 다음 명령을 입력합니다.
oc -n <hosted_control_plane_namespace> get agents
$ oc -n <hosted_control_plane_namespace> get agentsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CLUSTER APPROVED ROLE STAGE 86f7ac75-4fc4-4b36-8130-40fa12602218 auto-assign e57a637f-745b-496e-971d-1abbf03341ba auto-assign
NAME CLUSTER APPROVED ROLE STAGE 86f7ac75-4fc4-4b36-8130-40fa12602218 auto-assign e57a637f-745b-496e-971d-1abbf03341ba auto-assignCopy to Clipboard Copied! Toggle word wrap Toggle overflow 각 에이전트가 생성되면 선택적으로 에이전트의
installation_disk_id및호스트 이름을설정할 수 있습니다.에이전트의
installation_disk_id필드를 설정하려면 다음 명령을 입력합니다.oc -n <hosted_control_plane_namespace> patch agent <agent_name> -p '{"spec":{"installation_disk_id":"<installation_disk_id>","approved":true}}' --type merge$ oc -n <hosted_control_plane_namespace> patch agent <agent_name> -p '{"spec":{"installation_disk_id":"<installation_disk_id>","approved":true}}' --type mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 에이전트의
hostname필드를 설정하려면 다음 명령을 입력합니다.oc -n <hosted_control_plane_namespace> patch agent <agent_name> -p '{"spec":{"hostname":"<hostname>","approved":true}}' --type merge$ oc -n <hosted_control_plane_namespace> patch agent <agent_name> -p '{"spec":{"hostname":"<hostname>","approved":true}}' --type mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
에이전트가 사용할 수 있도록 승인되었는지 확인하려면 다음 명령을 입력합니다.
oc -n <hosted_control_plane_namespace> get agents
$ oc -n <hosted_control_plane_namespace> get agentsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CLUSTER APPROVED ROLE STAGE 86f7ac75-4fc4-4b36-8130-40fa12602218 true auto-assign e57a637f-745b-496e-971d-1abbf03341ba true auto-assign
NAME CLUSTER APPROVED ROLE STAGE 86f7ac75-4fc4-4b36-8130-40fa12602218 true auto-assign e57a637f-745b-496e-971d-1abbf03341ba true auto-assignCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.5.3. IBM Power에서 호스팅된 클러스터의 NodePool 오브젝트 확장 링크 복사링크가 클립보드에 복사되었습니다!
NodePool 오브젝트는 호스팅된 클러스터를 생성할 때 생성됩니다. NodePool 오브젝트를 스케일링하면 호스팅된 컨트롤 플레인에 더 많은 컴퓨팅 노드를 추가할 수 있습니다.
프로세스
다음 명령을 실행하여
NodePool오브젝트를 두 개의 노드로 확장합니다.oc -n <hosted_cluster_namespace> scale nodepool <nodepool_name> --replicas 2
$ oc -n <hosted_cluster_namespace> scale nodepool <nodepool_name> --replicas 2Copy to Clipboard Copied! Toggle word wrap Toggle overflow Cluster API 에이전트 공급자는 호스트 클러스터에 할당된 두 개의 에이전트를 임의로 선택합니다. 이러한 에이전트는 다른 상태를 통과하고 마지막으로 호스팅된 클러스터에 OpenShift Container Platform 노드로 참여합니다. 에이전트는 다음 순서로 전환 단계를 통과합니다.
-
바인딩 -
검색 -
충분하지 않음 -
설치 -
installing-in-progress -
added-to-existing-cluster
-
다음 명령을 실행하여 특정 확장 에이전트의 상태를 확인합니다.
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}'$ 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 Copied! Toggle word wrap Toggle overflow 출력 예
BMH: Agent: 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d State: known-unbound BMH: Agent: 5e498cd3-542c-e54f-0c58-ed43e28b568a State: insufficient
BMH: Agent: 50c23cda-cedc-9bbd-bcf1-9b3a5c75804d State: known-unbound BMH: Agent: 5e498cd3-542c-e54f-0c58-ed43e28b568a State: insufficientCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 전환 단계를 확인합니다.
oc -n <hosted_control_plane_namespace> get agent
$ oc -n <hosted_control_plane_namespace> get agentCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
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
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-assignCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 호스팅된 클러스터에 액세스할
kubeconfig파일을 생성합니다.hcp create kubeconfig --namespace <hosted_cluster_namespace> \ --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
$ hcp create kubeconfig --namespace <hosted_cluster_namespace> \ --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 에이전트가
add-to-existing-cluster상태에 도달한 후 다음 명령을 입력하여 OpenShift Container Platform 노드를 볼 수 있는지 확인합니다.oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
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
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+3882f8fCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여
NodePool오브젝트를 확장할 때 두 개의 머신이 생성되었는지 확인합니다.oc -n <hosted_control_plane_namespace> get machine.cluster.x-k8s.io
$ oc -n <hosted_control_plane_namespace> get machine.cluster.x-k8s.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
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
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.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 클러스터 버전을 확인합니다.
oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversion
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusterversionCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS clusterversion.config.openshift.io/version 4.15.0 True False 40h Cluster version is 4.15.0
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS clusterversion.config.openshift.io/version 4.15.0 True False 40h Cluster version is 4.15.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 Cluster Operator 상태를 확인합니다.
oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusteroperators
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get clusteroperatorsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터의 각 구성 요소에 대해 출력에 다음과 같은 Cluster Operator 상태가 표시됩니다.
-
NAME -
VERSION -
사용 가능 -
PROGRESSING -
DEGRADED -
이후 -
메시지
-
5.6. OpenStack에서 호스트된 컨트롤 플레인 관리 링크 복사링크가 클립보드에 복사되었습니다!
RHOSP(Red Hat OpenStack Platform) 에이전트 시스템에 호스팅된 컨트롤 플레인을 배포한 후 다음 작업을 완료하여 호스팅 클러스터를 관리할 수 있습니다.
5.6.1. 호스트된 클러스터에 액세스 링크 복사링크가 클립보드에 복사되었습니다!
oc CLI를 사용하여 리소스에서 직접 kubeconfig 시크릿을 추출하여 RHOSP(Red Hat OpenStack Platform)에서 호스팅된 클러스터에 액세스할 수 있습니다.
호스팅된 클러스터(호스트링) 네임스페이스에는 호스팅 된 클러스터 리소스 및 액세스 보안이 포함되어 있습니다. 호스팅된 컨트롤 플레인 네임스페이스는 호스팅된 컨트롤 플레인이 실행되는 위치입니다.
보안 이름 형식은 다음과 같습니다.
-
kubeconfig시크릿: <hosted_cluster_namespace>-<name>-admin-kubeconfig. 예를 들어 cluster-hypershift-demo-admin-kubeconfig. -
kubeadmin암호 시크릿: <hosted_cluster_namespace>-<name>-kubeadmin-password. 예를 들어 cluster-hypershift-demo-kubeadmin-password.
kubeconfig 시크릿에는 Base64로 인코딩된 kubeconfig 필드가 포함되어 있습니다. kubeadmin 암호 시크릿도 Base64로 인코딩됩니다. 압축을 풀고 암호를 사용하여 호스팅된 클러스터의 API 서버 또는 콘솔에 로그인할 수 있습니다.
사전 요구 사항
-
ocCLI가 설치되어 있습니다.
프로세스
다음 명령을 입력하여
admin-kubeconfig시크릿을 추출합니다.oc extract -n <hosted_cluster_namespace> \ secret/<hosted_cluster_name>-admin-kubeconfig \ --to=./hostedcluster-secrets --confirm
$ oc extract -n <hosted_cluster_namespace> \ secret/<hosted_cluster_name>-admin-kubeconfig \ --to=./hostedcluster-secrets --confirmCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
hostedcluster-secrets/kubeconfig
hostedcluster-secrets/kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 액세스 권한을 확인하기 위해 호스팅 클러스터의 노드 목록을 확인합니다.
oc --kubeconfig ./hostedcluster-secrets/kubeconfig get nodes
$ oc --kubeconfig ./hostedcluster-secrets/kubeconfig get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.6.2. 호스트 클러스터의 노드 자동 확장 활성화 링크 복사링크가 클립보드에 복사되었습니다!
RHOSP(Red Hat OpenStack Platform)의 호스팅 클러스터에 더 많은 용량이 필요하고 예비 에이전트를 사용할 수 있는 경우 자동 확장을 활성화하여 새 작업자 노드를 설치할 수 있습니다.
프로세스
자동 확장을 활성화하려면 다음 명령을 입력합니다.
oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> \ --type=json \ -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'$ oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> \ --type=json \ -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 새 노드가 필요한 워크로드를 생성합니다.
다음 예제를 사용하여 워크로드 구성이 포함된 YAML 파일을 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
workload-config.yaml이라는 이름으로 파일을 저장합니다. 다음 명령을 입력하여 YAML을 적용합니다.
oc apply -f workload-config.yaml
$ oc apply -f workload-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 명령을 입력하여
admin-kubeconfig시크릿을 추출합니다.oc extract -n <hosted_cluster_namespace> \ secret/<hosted_cluster_name>-admin-kubeconfig \ --to=./hostedcluster-secrets --confirm
$ oc extract -n <hosted_cluster_namespace> \ secret/<hosted_cluster_name>-admin-kubeconfig \ --to=./hostedcluster-secrets --confirmCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
hostedcluster-secrets/kubeconfig
hostedcluster-secrets/kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 새 노드가
Ready상태에 있는지 확인할 수 있습니다.oc --kubeconfig ./hostedcluster-secrets get nodes
$ oc --kubeconfig ./hostedcluster-secrets get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 노드를 제거하려면 다음 명령을 입력하여 워크로드를 삭제합니다.
oc --kubeconfig ./hostedcluster-secrets -n <namespace> \ delete deployment <deployment_name>
$ oc --kubeconfig ./hostedcluster-secrets -n <namespace> \ delete deployment <deployment_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 추가 용량을 요구하지 않고 몇 분 정도 경과할 때까지 기다립니다. 다음 명령을 입력하여 노드가 제거되었는지 확인할 수 있습니다.
oc --kubeconfig ./hostedcluster-secrets get nodes
$ oc --kubeconfig ./hostedcluster-secrets get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.6.3. 가용성 영역에 대한 노드 풀 구성 링크 복사링크가 클립보드에 복사되었습니다!
여러 RHOSP(Red Hat OpenStack Platform) Nova 가용성 영역에 노드 풀을 배포하여 호스팅된 클러스터의 고가용성을 개선할 수 있습니다.
가용성 영역은 내결함성 도메인에 반드시 해당하지 않으며 기본적으로 고가용성 이점을 제공하지 않습니다.
사전 요구 사항
- 호스팅된 클러스터를 생성하셨습니다.
- 관리 클러스터에 액세스할 수 있습니다.
-
hcp및ocCLI가 설치됩니다.
프로세스
필요에 적합한 환경 변수를 설정합니다. 예를 들어
az1가용성 영역에 두 개의 추가 시스템을 생성하려면 다음을 입력합니다.export NODEPOOL_NAME="${CLUSTER_NAME}-az1" \ && export WORKER_COUNT="2" \ && export FLAVOR="m1.xlarge" \ && export AZ="az1"$ export NODEPOOL_NAME="${CLUSTER_NAME}-az1" \ && export WORKER_COUNT="2" \ && export FLAVOR="m1.xlarge" \ && export AZ="az1"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 환경 변수를 사용하여 노드 풀을 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
<cluster_name>- 호스팅된 클러스터의 이름을 지정합니다.
다음 명령을 실행하여 클러스터 네임스페이스에
nodepool리소스를 나열하여 노드 풀의 상태를 확인합니다.oc get nodepools --namespace clusters
$ oc get nodepools --namespace clustersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE example example 5 5 False False 4.17.0 example-az1 example 2 False False True True Minimum availability requires 2 replicas, current 0 available
NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE example example 5 5 False False 4.17.0 example-az1 example 2 False False True True Minimum availability requires 2 replicas, current 0 availableCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 호스팅 클러스터에서 시작될 때 노트를 확인합니다.
oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodes
$ oc --kubeconfig $CLUSTER_NAME-kubeconfig get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME STATUS ROLES AGE VERSION ... example-extra-az-zh9l5 Ready worker 2m6s v1.27.4+18eadca example-extra-az-zr8mj Ready worker 102s v1.27.4+18eadca ...
NAME STATUS ROLES AGE VERSION ... example-extra-az-zh9l5 Ready worker 2m6s v1.27.4+18eadca example-extra-az-zr8mj Ready worker 102s v1.27.4+18eadca ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 노드 풀이 생성되었는지 확인합니다.
oc get nodepools --namespace clusters
$ oc get nodepools --namespace clustersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CLUSTER DESIRED CURRENT AVAILABLE PROGRESSING MESSAGE <node_pool_name> <cluster_name> 2 2 2 False All replicas are available
NAME CLUSTER DESIRED CURRENT AVAILABLE PROGRESSING MESSAGE <node_pool_name> <cluster_name> 2 2 2 False All replicas are availableCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.6.4. 노드 풀에 대한 추가 포트 구성 링크 복사링크가 클립보드에 복사되었습니다!
SR-IOV 또는 여러 네트워크와 같은 고급 네트워킹 시나리오를 지원하도록 노드 풀에 대한 추가 포트를 구성할 수 있습니다.
5.6.4.1. 노드 풀의 추가 포트 사용 사례 링크 복사링크가 클립보드에 복사되었습니다!
노드 풀에 대한 추가 포트를 구성하는 일반적인 이유는 다음과 같습니다.
- SR-IOV(Single Root I/O Virtualization)
- 물리적 네트워크 장치가 여러 VF(가상 기능)로 표시될 수 있습니다. 워크로드는 노드 풀에 추가 포트를 연결하여 SR-IOV 인터페이스를 사용하여 대기 시간이 짧은 고성능 네트워킹을 수행할 수 있습니다.
- DPDK(데이터 플레인 개발 키트)
- 커널을 우회하여 사용자 공간에서 빠른 패킷 처리를 제공합니다. 추가 포트가 있는 노드 풀은 DPDK를 사용하여 네트워크 성능을 개선하는 워크로드에 대한 인터페이스를 노출할 수 있습니다.
- NFS의 Manila RWX 볼륨
-
NFS를 통해 RWX(
ReadWriteMany) 볼륨을 지원하므로 여러 노드가 공유 스토리지에 액세스할 수 있습니다. 노드 풀에 포트를 더 연결하면 워크로드가 Manila에서 사용하는 NFS 네트워크에 연결할 수 있습니다. - Multus CNI
- Pod가 여러 네트워크 인터페이스에 연결할 수 있습니다. 추가 포트가 있는 노드 풀은 듀얼 스택 연결 및 트래픽 분리를 포함하여 보조 네트워크 인터페이스가 필요한 사용 사례를 지원합니다.
5.6.4.2. 노드 풀의 추가 포트 옵션 링크 복사링크가 클립보드에 복사되었습니다!
--openstack-node-additional-port 플래그를 사용하여 OpenStack의 호스팅 클러스터의 노드에 추가 포트를 연결할 수 있습니다. 플래그에는 쉼표로 구분된 매개변수 목록이 사용됩니다. 매개변수를 여러 번 사용하여 여러 추가 포트를 노드에 연결할 수 있습니다.
매개변수는 다음과 같습니다.
| 매개변수 | 설명 | 필수 항목 | 기본 |
|---|---|---|---|
|
| 노드에 연결할 네트워크의 ID입니다. | 제공됨 | 해당 없음 |
|
|
포트에 사용할 VNIC 유형입니다. 지정하지 않으면 Neutron에서 기본 유형 | 없음 | 해당 없음 |
|
| 포트에 대한 포트 보안을 비활성화할지 여부입니다. 지정하지 않으면 Neutron은 네트워크 수준에서 명시적으로 비활성화되지 않는 한 포트 보안을 활성화합니다. | 없음 | 해당 없음 |
|
|
포트에 할당할 IP 주소 쌍 목록입니다. 형식은 | 없음 | 해당 없음 |
5.6.4.3. 노드 풀에 대한 추가 포트 생성 링크 복사링크가 클립보드에 복사되었습니다!
RHOSP(Red Hat OpenStack Platform)에서 실행되는 호스팅된 클러스터에 대한 노드 풀에 대한 추가 포트를 구성할 수 있습니다.
사전 요구 사항
- 호스팅된 클러스터를 생성하셨습니다.
- 관리 클러스터에 액세스할 수 있습니다.
-
hcpCLI가 설치되어 있습니다. - RHOSP에서 추가 네트워크가 생성됩니다.
- 호스트 클러스터에서 사용하는 프로젝트는 추가 네트워크에 액세스할 수 있어야 합니다.
- "노드 풀의 추가 포트 옵션"에 나열된 옵션을 검토했습니다.
프로세스
hcp create nodepool openstack명령을--openstack-node-additional-port옵션으로 실행하여 추가 포트가 연결된 호스팅 클러스터를 생성합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
<cluster_name>- 호스팅된 클러스터의 이름을 지정합니다.
<nodepool_name>- 노드 풀의 이름을 지정합니다.
<replica_count>- 원하는 복제본 수를 지정합니다.
<flavor>- 사용할 RHOSP 플레이버를 지정합니다.
<sriov_net_id>- SR-IOV 네트워크 ID를 지정합니다.
<lb_net_id>- 로드 밸런서 네트워크 ID를 지정합니다.
5.6.5. 노드 풀에 대한 추가 포트 구성 링크 복사링크가 클립보드에 복사되었습니다!
클라우드 네이티브 네트워크 기능(CNF)과 같은 고성능 워크로드를 위해 RHOSP에서 호스팅된 클러스터 노드 성능을 조정할 수 있습니다. 성능 튜닝에는 RHOSP 리소스 구성, 성능 프로필 생성, tuned NodePool 리소스 배포, SR-IOV 장치 지원 활성화가 포함됩니다.
CNF는 클라우드 네이티브 환경에서 실행되도록 설계되었습니다. 라우팅, 방화벽, 로드 밸런싱과 같은 네트워크 서비스를 제공할 수 있습니다. 고성능 컴퓨팅 및 네트워킹 장치를 사용하여 CNF를 실행하도록 노드 풀을 구성할 수 있습니다.
5.6.5.1. 호스트 클러스터 노드의 성능 튜닝 링크 복사링크가 클립보드에 복사되었습니다!
성능 프로필을 생성하고 tuned NodePool 리소스를 배포하여 RHOSP(Red Hat OpenStack Platform) 호스팅 컨트롤 플레인에서 고성능 워크로드를 실행합니다.
사전 요구 사항
- 전용 CPU, 메모리 및 호스트 집계 정보를 포함하여 워크로드를 실행하는 데 필요한 리소스가 있는 RHOSP 플레이버가 있습니다.
- SR-IOV 또는 DPDK 가능 NIC에 연결된 RHOSP 네트워크가 있습니다. 이 네트워크는 호스팅된 클러스터에서 사용하는 프로젝트에서 사용할 수 있어야 합니다.
프로세스
perfprofile.yaml이라는 파일에서 요구 사항을 충족하는 성능 프로필을 생성합니다. 예를 들면 다음과 같습니다.구성 맵의 성능 프로필 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 중요HyperShift Operator 네임스페이스, 분리된 CPU 및 예약된 CPU에 대해 환경 변수가 설정되지 않은 경우 성능 프로필을 적용하기 전에 해당 변수를 생성합니다.
다음 명령을 실행하여 성능 프로필 구성을 적용합니다.
oc apply -f perfprof.yaml
$ oc apply -f perfprof.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
클러스터 이름에 대해
CLUSTER_NAME환경 변수가 설정되어 있지 않은 경우 이를 정의합니다. 다음 명령을 실행하여 노드 풀 이름 환경 변수를 설정합니다.
export NODEPOOL_NAME=$CLUSTER_NAME-cnf
$ export NODEPOOL_NAME=$CLUSTER_NAME-cnfCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 플레이버 환경 변수를 설정합니다.
export FLAVOR="m1.xlarge.nfv"
$ export FLAVOR="m1.xlarge.nfv"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 성능 프로필을 사용하는 노드 풀을 생성합니다.
hcp create nodepool openstack \ --cluster-name $CLUSTER_NAME \ --name $NODEPOOL_NAME \ --node-count 0 \ --openstack-node-flavor $FLAVOR
$ hcp create nodepool openstack \ --cluster-name $CLUSTER_NAME \ --name $NODEPOOL_NAME \ --node-count 0 \ --openstack-node-flavor $FLAVORCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 노드 풀을 패치하여
PerformanceProfile리소스를 참조합니다.oc patch nodepool -n ${HYPERSHIFT_NAMESPACE} ${CLUSTER_NAME} \ -p '{"spec":{"tuningConfig":[{"name":"cnf-performanceprofile"}]}}' --type=merge$ oc patch nodepool -n ${HYPERSHIFT_NAMESPACE} ${CLUSTER_NAME} \ -p '{"spec":{"tuningConfig":[{"name":"cnf-performanceprofile"}]}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 노드 풀을 확장합니다.
oc scale nodepool/$CLUSTER_NAME --namespace ${HYPERSHIFT_NAMESPACE} --replicas=1$ oc scale nodepool/$CLUSTER_NAME --namespace ${HYPERSHIFT_NAMESPACE} --replicas=1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 노드가 준비될 때까지 기다립니다.
다음 명령을 실행하여 노드가 준비될 때까지 기다립니다.
oc wait --for=condition=UpdatingConfig=True nodepool \ -n ${HYPERSHIFT_NAMESPACE} ${CLUSTER_NAME} \ --timeout=5m$ oc wait --for=condition=UpdatingConfig=True nodepool \ -n ${HYPERSHIFT_NAMESPACE} ${CLUSTER_NAME} \ --timeout=5mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 구성 업데이트가 완료될 때까지 기다립니다.
oc wait --for=condition=UpdatingConfig=False nodepool \ -n ${HYPERSHIFT_NAMESPACE} ${CLUSTER_NAME} \ --timeout=30m$ oc wait --for=condition=UpdatingConfig=False nodepool \ -n ${HYPERSHIFT_NAMESPACE} ${CLUSTER_NAME} \ --timeout=30mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 모든 노드가 정상 상태가 될 때까지 기다립니다.
oc wait --for=condition=AllNodesHealthy nodepool \ -n ${HYPERSHIFT_NAMESPACE} ${CLUSTER_NAME} \ --timeout=5m$ oc wait --for=condition=AllNodesHealthy nodepool \ -n ${HYPERSHIFT_NAMESPACE} ${CLUSTER_NAME} \ --timeout=5mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
노드에 SSH를 연결하거나 oc debug 명령을 사용하여 성능 구성을 확인할 수 있습니다.
5.6.5.2. 호스트 클러스터에서 SR-IOV Network Operator 활성화 링크 복사링크가 클립보드에 복사되었습니다!
SR-IOV Network Operator를 활성화하여 NodePool 리소스에서 배포한 노드에서 SR-IOV 가능 장치를 관리할 수 있습니다. Operator는 호스팅 클러스터에서 실행되며 레이블이 지정된 작업자 노드가 필요합니다.
프로세스
다음 명령을 실행하여 호스팅된 클러스터에 대한
kubeconfig파일을 생성합니다.hcp create kubeconfig --name $CLUSTER_NAME > $CLUSTER_NAME-kubeconfig
$ hcp create kubeconfig --name $CLUSTER_NAME > $CLUSTER_NAME-kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
kubeconfig리소스 환경 변수를 생성합니다.export KUBECONFIG=$CLUSTER_NAME-kubeconfig
$ export KUBECONFIG=$CLUSTER_NAME-kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 SR-IOV 기능을 표시하도록 각 작업자 노드에 레이블을 지정합니다.
oc label node <worker_node_name> feature.node.kubernetes.io/network-sriov.capable=true
$ oc label node <worker_node_name> feature.node.kubernetes.io/network-sriov.capable=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
<worker_node_name>- 호스팅된 클러스터의 작업자 노드의 이름을 지정합니다.
- " SR-IOV Network Operator 설치"의 지침에 따라 호스팅된 클러스터에 SR-IOV Network Operator를 설치합니다.
- 설치 후 독립 실행형 클러스터와 동일한 프로세스를 사용하여 호스팅된 클러스터에서 SR-IOV 워크로드를 구성합니다.
6장. 연결이 끊긴 환경에서 호스트된 컨트롤 플레인 배포 링크 복사링크가 클립보드에 복사되었습니다!
6.1. 연결이 끊긴 환경에서 호스트된 컨트롤 플레인 소개 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 컨트롤 플레인의 컨텍스트에서 연결이 끊긴 환경은 인터넷에 연결되지 않고 호스팅된 컨트롤 플레인을 기반으로 사용하는 OpenShift Container Platform 배포입니다. 베어 메탈 또는 OpenShift Virtualization의 연결이 끊긴 환경에서 호스팅되는 컨트롤 플레인을 배포할 수 있습니다.
연결이 끊긴 환경의 호스팅된 컨트롤 플레인은 독립형 OpenShift Container Platform과 다르게 작동합니다.
- 컨트롤 플레인은 관리 클러스터에 있습니다. 컨트롤 플레인은 호스팅된 컨트롤 플레인의 Pod가 컨트롤 플레인 Operator에서 실행되고 관리하는 위치입니다.
- 데이터 플레인은 호스팅된 클러스터의 작업자에 있습니다. 데이터 플레인은 워크로드 및 기타 Pod가 실행되는 위치이며 모두 HostedClusterConfig Operator가 관리합니다.
Pod가 실행 중인 위치에 따라 관리 클러스터에서 생성된 ImageDigestMirrorSet (IDMS) 또는 ImageContentSourcePolicy (ICSP) 또는 호스트된 클러스터의 spec 필드에 설정된 ImageContentSource 의 영향을 받습니다. spec 필드는 호스팅된 클러스터의 IDMS 오브젝트로 변환됩니다.
IPv4, IPv6 및 듀얼 스택 네트워크의 연결이 끊긴 환경에서 호스팅되는 컨트롤 플레인을 배포할 수 있습니다. IPv4는 연결이 끊긴 환경에서 호스팅된 컨트롤 플레인을 배포하는 가장 간단한 네트워크 구성 중 하나입니다. IPv4 범위에는 IPv6 또는 듀얼 스택 설정보다 적은 수의 외부 구성 요소가 필요합니다. 연결이 끊긴 환경의 OpenShift Virtualization에서 호스팅되는 컨트롤 플레인의 경우 IPv4 또는 듀얼 스택 네트워크를 사용합니다.
6.2. 연결이 끊긴 환경에서 OpenShift Virtualization에 호스트된 컨트롤 플레인 배포 링크 복사링크가 클립보드에 복사되었습니다!
연결이 끊긴 환경에서 호스팅되는 컨트롤 플레인을 배포할 때 사용하는 플랫폼에 따라 일부 단계가 다릅니다. 다음 절차는 OpenShift Virtualization의 배포와 관련이 있습니다.
6.2.1. 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
- 관리 클러스터 역할을 하는 연결이 끊긴 OpenShift Container Platform 환경이 있어야 합니다.
- 이미지를 미러링할 내부 레지스트리가 있습니다. 자세한 내용은 연결 해제된 설치 미러링 정보를 참조하십시오.
6.2.2. 연결이 끊긴 환경에서 호스팅된 컨트롤 플레인의 이미지 미러링 구성 링크 복사링크가 클립보드에 복사되었습니다!
이미지 미러링은 registry.redhat.com 또는 quay.io 와 같은 외부 레지스트리에서 이미지를 가져와서 프라이빗 레지스트리에 저장하는 프로세스입니다.
다음 절차에서는 ImageSetConfiguration 오브젝트를 사용하는 바이너리인 oc-mirror 툴이 사용됩니다. 파일에서 다음 정보를 지정할 수 있습니다.
-
미러링할 OpenShift Container Platform 버전입니다. 버전은
quay.io에 있습니다. - 미러링할 추가 Operator입니다. 패키지를 개별적으로 선택합니다.
- 리포지토리에 추가할 추가 이미지입니다.
사전 요구 사항
- 미러링 프로세스를 시작하기 전에 레지스트리 서버가 실행 중인지 확인합니다.
프로세스
이미지 미러링을 구성하려면 다음 단계를 완료합니다.
-
이미지를 푸시하려는 프라이빗 레지스트리와 미러링할 레지스트리를 사용하여
${HOME}/.docker/config.json파일이 업데이트되었는지 확인합니다. 다음 예제를 사용하여 미러링에 사용할
ImageSetConfiguration오브젝트를 만듭니다. 환경에 맞게 필요에 따라 값을 바꿉니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 미러링 프로세스를 시작합니다.
oc-mirror --v2 --config imagesetconfig.yaml \ --workspace file://mirror-file docker://<registry>
$ oc-mirror --v2 --config imagesetconfig.yaml \ --workspace file://mirror-file docker://<registry>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 미러링 프로세스가 완료되면 IDMS(
ImageDigestMirrorSet),ImageTagMirrorSet(ITMS) 및 호스팅된 클러스터에 적용할 카탈로그 소스가 포함된mirror-file이라는 새 폴더가 있습니다.imagesetconfig.yaml파일을 다음과 같이 구성하여 OpenShift Container Platform의 Nightly 또는 CI 버전을 미러링합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 부분적으로 연결이 끊긴 환경이 있는 경우 다음 명령을 입력하여 이미지 세트 구성의 이미지를 레지스트리로 미러링합니다.
oc mirror -c imagesetconfig.yaml \ --workspace file://<file_path> docker://<mirror_registry_url> --v2
$ oc mirror -c imagesetconfig.yaml \ --workspace file://<file_path> docker://<mirror_registry_url> --v2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 자세한 내용은 "부분 연결이 끊긴 환경에서 이미지 세트 미러링"을 참조하십시오.
완전히 연결이 끊긴 환경이 있는 경우 다음 단계를 수행합니다.
다음 명령을 입력하여 지정된 이미지 세트 구성의 이미지를 디스크로 미러링합니다.
oc mirror -c imagesetconfig.yaml file://<file_path> --v2
$ oc mirror -c imagesetconfig.yaml file://<file_path> --v2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 자세한 내용은 "완전하게 연결이 끊긴 환경에서 이미지 세트 미러링"을 참조하십시오.
디스크에서 이미지 세트 파일을 처리하고 다음 명령을 입력하여 콘텐츠를 대상 미러 레지스트리에 미러링합니다.
oc mirror -c imagesetconfig.yaml \ --from file://<file_path> docker://<mirror_registry_url> --v2
$ oc mirror -c imagesetconfig.yaml \ --from file://<file_path> docker://<mirror_registry_url> --v2Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 연결이 끊긴 네트워크에 설치 단계에 따라 최신 다중 클러스터 엔진 Operator 이미지를 미러링합니다.
6.2.3. 관리 클러스터에 오브젝트 적용 링크 복사링크가 클립보드에 복사되었습니다!
미러링 프로세스가 완료되면 관리 클러스터에 두 개의 오브젝트를 적용해야 합니다.
-
ImageContentSourcePolicy(ICSP) 또는ImageDigestMirrorSet(IDMS) - 카탈로그 소스
oc-mirror 툴을 사용하는 경우 출력 아티팩트는 oc-mirror-workspace/results-XXXXXX/ 이라는 폴더에 있습니다.
ICSP 또는 IDMS는 노드를 재시작하지 않고 각 노드에서 kubelet을 다시 시작하는 MachineConfig 변경을 시작합니다. 노드가 READY 로 표시되면 새로 생성된 카탈로그 소스를 적용해야 합니다.
카탈로그 소스는 카탈로그 이미지 다운로드 및 처리와 같은 openshift-marketplace Operator에서 작업을 시작하여 해당 이미지에 포함된 모든 PackageManifest 를 검색합니다.
프로세스
새 소스를 확인하려면 새
CatalogSource를 소스로 사용하여 다음 명령을 실행합니다.oc get packagemanifest
$ oc get packagemanifestCopy to Clipboard Copied! Toggle word wrap Toggle overflow 아티팩트를 적용하려면 다음 단계를 완료합니다.
다음 명령을 입력하여 ICSP 또는 IDMS 아티팩트를 생성합니다.
oc apply -f oc-mirror-workspace/results-XXXXXX/imageContentSourcePolicy.yaml
$ oc apply -f oc-mirror-workspace/results-XXXXXX/imageContentSourcePolicy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 노드가 준비될 때까지 기다린 다음 다음 명령을 입력합니다.
oc apply -f catalogSource-XXXXXXXX-index.yaml
$ oc apply -f catalogSource-XXXXXXXX-index.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
OLM 카탈로그를 미러링하고 미러를 가리키도록 호스팅 클러스터를 구성합니다.
관리(기본값) OLMCatalogPlacement 모드를 사용하면 관리 클러스터의 ICSP에서 재정의 정보를 사용하여 OLM 카탈로그에 사용되는 이미지 스트림이 자동으로 수정되지 않습니다.-
원래 이름 및 태그를 사용하여 OLM 카탈로그가 내부 레지스트리에 올바르게 미러링된 경우
hypershift.openshift.io/olm-catalogs-is-registry-overrides주석을HostedCluster리소스에 추가합니다. 형식은"sr1=dr1,sr2=dr2"입니다. 여기서 소스 레지스트리 문자열은 키이고 대상 레지스트리는 값입니다. OLM 카탈로그 이미지 스트림 메커니즘을 바이패스하려면
HostedCluster리소스에서 다음 4개의 주석을 사용하여 OLM Operator 카탈로그에 사용할 4개의 이미지의 주소를 직접 지정합니다.-
hypershift.openshift.io/certified-operators-catalog-image -
hypershift.openshift.io/community-operators-catalog-image -
hypershift.openshift.io/redhat-marketplace-catalog-image -
hypershift.openshift.io/redhat-operators-catalog-image
-
-
원래 이름 및 태그를 사용하여 OLM 카탈로그가 내부 레지스트리에 올바르게 미러링된 경우
이 경우 이미지 스트림이 생성되지 않으며 Operator 업데이트를 가져오려면 내부 미러를 새로 고칠 때 주석 값을 업데이트해야 합니다.
다음 단계
호스팅된 컨트롤 플레인의 연결이 끊긴 설치를 위해 다중 클러스터 엔진 Operator 배포 단계를 완료하여 다중 클러스터 엔진 Operator를 배포합니다.
6.2.4. 호스트된 컨트롤 플레인의 연결이 끊긴 설치를 위해 다중 클러스터 엔진 Operator 배포 링크 복사링크가 클립보드에 복사되었습니다!
Kubernetes Operator의 멀티 클러스터 엔진은 공급자 전체에 클러스터를 배포하는 데 중요한 역할을 합니다. 다중 클러스터 엔진 Operator가 설치되어 있지 않은 경우 다음 문서를 검토하여 사전 요구 사항 및 설치 단계를 확인하십시오.
6.2.5. 호스팅된 컨트롤 플레인의 연결이 끊긴 설치를 위한 TLS 인증서 구성 링크 복사링크가 클립보드에 복사되었습니다!
연결이 끊긴 배포에서 제대로 작동하려면 관리 클러스터에서 레지스트리 CA 인증서와 호스팅된 클러스터의 작업자 노드를 구성해야 합니다.
6.2.5.1. 관리 클러스터에 레지스트리 CA 추가 링크 복사링크가 클립보드에 복사되었습니다!
레지스트리 CA를 관리 클러스터에 추가하려면 다음 단계를 완료합니다.
프로세스
다음 예와 유사한 구성 맵을 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터 전체 오브젝트
image.config.openshift.io를 패치하여 다음 사양을 포함합니다.spec: additionalTrustedCA: - name: registry-configspec: additionalTrustedCA: - name: registry-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이 패치로 인해 컨트롤 플레인 노드는 프라이빗 레지스트리에서 이미지를 검색할 수 있으며 HyperShift Operator는 호스팅된 클러스터 배포를 위해 OpenShift Container Platform 페이로드를 추출할 수 있습니다.
오브젝트 패치 프로세스를 완료하는 데 몇 분이 걸릴 수 있습니다.
6.2.5.2. 호스트된 클러스터의 작업자 노드에 레지스트리 CA 추가 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 클러스터의 데이터 플레인 작업자가 프라이빗 레지스트리에서 이미지를 검색하려면 레지스트리 CA를 작업자 노드에 추가해야 합니다.
프로세스
hc.spec.additionalTrustBundle파일에서 다음 사양을 추가합니다.spec: additionalTrustBundle: - name: user-ca-bundlespec: additionalTrustBundle: - name: user-ca-bundle1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
user-ca-bundle항목은 다음 단계에서 생성하는 구성 맵입니다.
HostedCluster오브젝트가 생성된 동일한 네임스페이스에서user-ca-bundle구성 맵을 생성합니다. 구성 맵은 다음 예와 유사합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
HostedCluster오브젝트가 생성되는 네임스페이스를 지정합니다.
6.2.6. OpenShift Virtualization에서 호스트된 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
호스팅 클러스터는 관리 클러스터에서 호스팅되는 컨트롤 플레인 및 API 끝점이 있는 OpenShift Container Platform 클러스터입니다. 호스트된 클러스터에는 컨트롤 플레인과 해당 데이터 플레인이 포함됩니다.
6.2.6.1. OpenShift Virtualization에 호스팅된 컨트롤 플레인을 배포하기 위한 요구사항 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Virtualization에 호스팅된 컨트롤 플레인을 배포할 준비가 되면 다음 정보를 고려하십시오.
- 베어 메탈에서 관리 클러스터를 실행합니다.
- 각 호스트 클러스터에는 클러스터 전체 이름이 있어야 합니다.
-
클러스터를 호스팅
클러스터이름으로 사용하지 마십시오. - 호스트된 클러스터는 다중 클러스터 엔진 Operator 관리 클러스터의 네임스페이스에서 생성할 수 없습니다.
- 호스트된 컨트롤 플레인에 대한 스토리지를 구성할 때 권장 etcd 사례를 고려하십시오. 대기 시간 요구 사항을 충족하는지 확인하려면 각 컨트롤 플레인 노드에서 실행되는 모든 호스팅 컨트롤 플레인 etcd 인스턴스에 빠른 스토리지 장치를 전용으로 지정합니다. LVM 스토리지를 사용하여 호스팅된 etcd pod의 로컬 스토리지 클래스를 구성할 수 있습니다. 자세한 내용은 "Recommended etcd practices" 및 "Persistent storage using Logical Volume Manager storage"를 참조하십시오.
6.2.6.2. CLI를 사용하여 KubeVirt 플랫폼에서 호스트 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
호스트된 클러스터를 생성하려면 호스팅된 컨트롤 플레인 CLI(명령줄 인터페이스) hcp 를 사용할 수 있습니다.
프로세스
다음 명령을 입력하여 KubeVirt 플랫폼을 사용하여 호스팅된 클러스터를 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고--release-image플래그를 사용하여 특정 OpenShift Container Platform 릴리스로 호스팅 클러스터를 설정할 수 있습니다.--node-pool-replicas플래그에 따라 두 개의 가상 머신 작업자 복제본이 있는 클러스터에 대한 기본 노드 풀이 생성됩니다.잠시 후 다음 명령을 입력하여 호스팅된 컨트롤 플레인 포드가 실행 중인지 확인합니다.
oc -n clusters-<hosted-cluster-name> get pods
$ oc -n clusters-<hosted-cluster-name> get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow KubeVirt 가상 머신에서 지원하는 작업자 노드가 있는 호스팅된 클러스터는 일반적으로 완전히 프로비저닝되는 데 10-15분이 걸립니다.
검증
호스트 클러스터의 상태를 확인하려면 다음 명령을 입력하여 해당
HostedCluster리소스를 참조하십시오.oc get --namespace clusters hostedclusters
$ oc get --namespace clusters hostedclustersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 완전히 프로비저닝된
HostedCluster오브젝트를 설명하는 다음 예제 출력을 참조하십시오.NAMESPACE NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE clusters my-hosted-cluster <4.x.0> example-admin-kubeconfig Completed True False The hosted control plane is available
NAMESPACE NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE clusters my-hosted-cluster <4.x.0> example-admin-kubeconfig Completed True False The hosted control plane is availableCopy to Clipboard Copied! Toggle word wrap Toggle overflow &
lt;4.x.0>을 사용하려는 지원되는 OpenShift Container Platform 버전으로 바꿉니다.
6.2.6.3. OpenShift Virtualization에서 호스팅된 컨트롤 플레인의 기본 수신 및 DNS 구성 링크 복사링크가 클립보드에 복사되었습니다!
모든 OpenShift Container Platform 클러스터에는 기본 애플리케이션 Ingress 컨트롤러가 포함되어 있으며, 이와 연결된 와일드카드 DNS 레코드가 있어야 합니다. 기본적으로 HyperShift KubeVirt 공급자를 사용하여 생성된 호스팅 클러스터는 KubeVirt 가상 머신이 실행되는 OpenShift Container Platform 클러스터의 하위 도메인이 자동으로 됩니다.
예를 들어 OpenShift Container Platform 클러스터에 다음과 같은 기본 인그레스 DNS 항목이 있을 수 있습니다.
*.apps.mgmt-cluster.example.com
*.apps.mgmt-cluster.example.com
결과적으로 guest 라는 이름의 KubeVirt 호스팅 클러스터에는 다음과 같은 기본 수신이 있습니다.
*.apps.guest.apps.mgmt-cluster.example.com
*.apps.guest.apps.mgmt-cluster.example.com
프로세스
기본 인그레스 DNS가 제대로 작동하려면 KubeVirt 가상 머신을 호스팅하는 클러스터에서 와일드카드 DNS 경로를 허용해야 합니다.
다음 명령을 입력하여 이 동작을 구성할 수 있습니다.
oc patch ingresscontroller -n openshift-ingress-operator default \ --type=json \ -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'$ oc patch ingresscontroller -n openshift-ingress-operator default \ --type=json \ -p '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
기본 호스팅 클러스터 수신을 사용하는 경우 포트 443을 통한 HTTPS 트래픽으로 제한됩니다. 포트 80을 통한 일반 HTTP 트래픽이 거부됩니다. 이 제한은 기본 수신 동작에만 적용됩니다.
6.2.6.4. 수신 및 DNS 동작 사용자 정의 링크 복사링크가 클립보드에 복사되었습니다!
기본 수신 및 DNS 동작을 사용하지 않으려면 생성 시 KubeVirt 호스팅 클러스터를 고유 기본 도메인으로 구성할 수 있습니다. 이 옵션을 사용하려면 생성 중에 수동 구성 단계가 필요하며 클러스터 생성, 로드 밸런서 생성 및 와일드카드 DNS 구성의 세 가지 주요 단계가 포함됩니다.
6.2.6.4.1. 기본 도메인을 지정하는 호스팅된 클러스터 배포 링크 복사링크가 클립보드에 복사되었습니다!
기본 도메인을 지정하는 호스팅 클러스터를 생성하려면 다음 단계를 완료합니다.
프로세스
다음 명령을 실행합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 결과적으로 호스팅된 클러스터에는 클러스터 이름과 기본 도메인(예:
.apps.example.hypershift.lab)에 대해 구성된 수신 와일드카드가 있습니다. 호스트 클러스터는 고유한 기본 도메인을 사용하여 호스팅 클러스터를 생성한 후 필요한 DNS 레코드 및 로드 밸런서를 구성해야 하므로부분적상태로 유지됩니다.
검증
다음 명령을 입력하여 호스팅 클러스터의 상태를 확인합니다.
oc get --namespace clusters hostedclusters
$ oc get --namespace clusters hostedclustersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE example example-admin-kubeconfig Partial True False The hosted control plane is available
NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE example example-admin-kubeconfig Partial True False The hosted control plane is availableCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 클러스터에 액세스합니다.
hcp create kubeconfig --name <hosted_cluster_name> \ > <hosted_cluster_name>-kubeconfig
$ hcp create kubeconfig --name <hosted_cluster_name> \ > <hosted_cluster_name>-kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc --kubeconfig <hosted_cluster_name>-kubeconfig get co
$ oc --kubeconfig <hosted_cluster_name>-kubeconfig get coCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE console <4.x.0> False False False 30m RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.example.hypershift.lab): Get "https://console-openshift-console.apps.example.hypershift.lab": dial tcp: lookup console-openshift-console.apps.example.hypershift.lab on 172.31.0.10:53: no such host ingress <4.x.0> True False True 28m The "default" ingress controller reports Degraded=True: DegradedConditions: One or more other status conditions indicate a degraded state: CanaryChecksSucceeding=False (CanaryChecksRepetitiveFailures: Canary route checks for the default ingress controller are failing)
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE console <4.x.0> False False False 30m RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.example.hypershift.lab): Get "https://console-openshift-console.apps.example.hypershift.lab": dial tcp: lookup console-openshift-console.apps.example.hypershift.lab on 172.31.0.10:53: no such host ingress <4.x.0> True False True 28m The "default" ingress controller reports Degraded=True: DegradedConditions: One or more other status conditions indicate a degraded state: CanaryChecksSucceeding=False (CanaryChecksRepetitiveFailures: Canary route checks for the default ingress controller are failing)Copy to Clipboard Copied! Toggle word wrap Toggle overflow &
lt;4.x.0>을 사용하려는 지원되는 OpenShift Container Platform 버전으로 바꿉니다.
다음 단계
출력에서 오류를 수정하려면 "로드 밸런서 설정" 및 " 와일드카드 DNS 설정"의 단계를 완료합니다.
호스팅 클러스터가 베어 메탈에 있는 경우 로드 밸런서 서비스를 설정하려면 MetalLB가 필요할 수 있습니다. 자세한 내용은 " MetalLB 구성"을 참조하십시오.
6.2.6.4.2. 로드 밸런서 설정 링크 복사링크가 클립보드에 복사되었습니다!
Ingress 트래픽을 KubeVirt VM으로 라우팅하고 로드 밸런서 IP 주소에 와일드카드 DNS 항목을 할당하는 로드 밸런서 서비스를 설정합니다.
프로세스
호스팅된 클러스터 인그레스를 노출하는
NodePort서비스가 이미 존재합니다. 노드 포트를 내보내고 해당 포트를 대상으로 하는 로드 밸런서 서비스를 생성할 수 있습니다.다음 명령을 입력하여 HTTP 노드 포트를 가져옵니다.
oc --kubeconfig <hosted_cluster_name>-kubeconfig get services \ -n openshift-ingress router-nodeport-default \ -o jsonpath='{.spec.ports[?(@.name=="http")].nodePort}'$ oc --kubeconfig <hosted_cluster_name>-kubeconfig get services \ -n openshift-ingress router-nodeport-default \ -o jsonpath='{.spec.ports[?(@.name=="http")].nodePort}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 단계에서 사용할 HTTP 노드 포트 값을 확인합니다.
다음 명령을 입력하여 HTTPS 노드 포트를 가져옵니다.
oc --kubeconfig <hosted_cluster_name>-kubeconfig get services \ -n openshift-ingress router-nodeport-default \ -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}'$ oc --kubeconfig <hosted_cluster_name>-kubeconfig get services \ -n openshift-ingress router-nodeport-default \ -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 단계에서 사용할 HTTPS 노드 포트 값을 확인합니다.
YAML 파일에 다음 정보를 입력합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 로드 밸런서 서비스를 생성합니다.
oc create -f <file_name>.yaml
$ oc create -f <file_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.2.6.4.3. 와일드카드 DNS 설정 링크 복사링크가 클립보드에 복사되었습니다!
로드 밸런서 서비스의 외부 IP를 참조하는 와일드카드 DNS 레코드 또는 CNAME을 설정합니다.
프로세스
다음 명령을 입력하여 외부 IP 주소를 가져옵니다.
oc -n clusters-<hosted_cluster_name> get service <hosted-cluster-name>-apps \ -o jsonpath='{.status.loadBalancer.ingress[0].ip}'$ oc -n clusters-<hosted_cluster_name> get service <hosted-cluster-name>-apps \ -o jsonpath='{.status.loadBalancer.ingress[0].ip}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
192.168.20.30
192.168.20.30Copy to Clipboard Copied! Toggle word wrap Toggle overflow 외부 IP 주소를 참조하는 와일드카드 DNS 항목을 구성합니다. 다음 예제 DNS 항목을 확인합니다.
*.apps.<hosted_cluster_name\>.<base_domain\>.
*.apps.<hosted_cluster_name\>.<base_domain\>.Copy to Clipboard Copied! Toggle word wrap Toggle overflow DNS 항목은 클러스터 내부 및 외부에서 라우팅할 수 있어야 합니다.
DNS 확인 예
dig +short test.apps.example.hypershift.lab 192.168.20.30
dig +short test.apps.example.hypershift.lab 192.168.20.30Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 입력하여 호스팅 클러스터 상태가
Partial에서Completed로 이동했는지 확인합니다.oc get --namespace clusters hostedclusters
$ oc get --namespace clusters hostedclustersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE example <4.x.0> example-admin-kubeconfig Completed True False The hosted control plane is available
NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE example <4.x.0> example-admin-kubeconfig Completed True False The hosted control plane is availableCopy to Clipboard Copied! Toggle word wrap Toggle overflow &
lt;4.x.0>을 사용하려는 지원되는 OpenShift Container Platform 버전으로 바꿉니다.
6.2.7. 배포 완료 링크 복사링크가 클립보드에 복사되었습니다!
컨트롤 플레인과 데이터 플레인의 두 가지 관점에서 호스팅 클러스터 배포를 모니터링할 수 있습니다.
6.2.7.1. 컨트롤 플레인 모니터링 링크 복사링크가 클립보드에 복사되었습니다!
배포가 진행되는 동안 다음 아티팩트에 대한 정보를 수집하여 컨트롤 플레인을 모니터링할 수 있습니다.
- HyperShift Operator
-
HostedControlPlanePod - 베어 메탈 호스트
- 에이전트
-
InfraEnv리소스 -
HostedCluster및NodePool리소스
프로세스
다음 명령을 입력하여 컨트롤 플레인을 모니터링합니다.
export KUBECONFIG=/root/.kcli/clusters/hub-ipv4/auth/kubeconfig
$ export KUBECONFIG=/root/.kcli/clusters/hub-ipv4/auth/kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.2.7.2. 데이터 플레인 모니터링 링크 복사링크가 클립보드에 복사되었습니다!
배포가 진행되는 동안 다음 아티팩트에 대한 정보를 수집하여 데이터 플레인을 모니터링할 수 있습니다.
- 클러스터 버전
- 특히 노드가 클러스터에 참여하는지 여부에 대한 노드
- 클러스터 Operator
프로세스
다음 명령을 입력합니다.
oc get secret -n clusters-hosted-ipv4 admin-kubeconfig \ -o jsonpath='{.data.kubeconfig}' | base64 -d > /root/hc_admin_kubeconfig.yaml$ oc get secret -n clusters-hosted-ipv4 admin-kubeconfig \ -o jsonpath='{.data.kubeconfig}' | base64 -d > /root/hc_admin_kubeconfig.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow export KUBECONFIG=/root/hc_admin_kubeconfig.yaml
$ export KUBECONFIG=/root/hc_admin_kubeconfig.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow watch "oc get clusterversion,nodes,co"
$ watch "oc get clusterversion,nodes,co"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3. 연결이 끊긴 환경의 베어 메탈에 호스팅된 컨트롤 플레인 배포 링크 복사링크가 클립보드에 복사되었습니다!
베어 메탈에서 호스팅되는 컨트롤 플레인을 프로비저닝할 때 에이전트 플랫폼을 사용합니다. Kubernetes Operator의 에이전트 플랫폼과 다중 클러스터 엔진은 함께 작동하여 연결이 끊긴 배포를 활성화합니다. 에이전트 플랫폼은 중앙 인프라 관리 서비스를 사용하여 호스트된 클러스터에 작업자 노드를 추가합니다. 중앙 인프라 관리 서비스에 대한 소개는 중앙 인프라 관리 서비스 활성화를 참조하십시오.
6.3.1. 베어 메탈의 연결이 끊긴 환경 아키텍처 링크 복사링크가 클립보드에 복사되었습니다!
다음 다이어그램은 연결이 끊긴 환경의 예제 아키텍처를 보여줍니다.
- 연결이 끊긴 배포가 작동하는지 확인하기 위해 TLS 지원, 웹 서버 및 DNS를 사용하여 레지스트리 인증서 배포를 포함한 인프라 서비스를 구성합니다.
openshift-config네임스페이스에 구성 맵을 생성합니다. 이 예에서 구성 맵의 이름은registry-config입니다. 구성 맵의 내용은 레지스트리 CA 인증서입니다. 구성 맵의 data 필드에는 다음 키/값이 포함되어야 합니다.-
키: <
registry_dns_domain_name>..<port> (예:registry.hypershiftdomain.lab..5000:). 포트를 지정할 때 레지스트리 DNS 도메인 이름 뒤에..를 배치해야 합니다. value: 인증서 콘텐츠
구성 맵 생성에 대한 자세한 내용은 호스팅된 컨트롤 플레인의 연결이 끊긴 설치에 대한 TLS 인증서 구성 을 참조하십시오.
-
키: <
-
images.config.openshift.ioCR(사용자 정의 리소스) 사양을 수정하고 이름이registry-config인additionalTrustedCA라는 새 필드를 추가합니다. 두 개의 데이터 필드가 포함된 구성 맵을 생성합니다. 한 필드에는
RAW형식의registries.conf파일이 포함되어 있고 다른 필드에는 레지스트리 CA가 포함되어 있으며ca-bundle.crt라는 이름이 있습니다. 구성 맵은multicluster-engine네임스페이스에 속하며 구성 맵 이름은 다른 오브젝트에서 참조됩니다. 구성 맵의 예는 다음 샘플 구성을 참조하십시오.Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
다중 클러스터 엔진 Operator 네임스페이스에서 Agent 및
hypershift-addon애드온을 둘 다 활성화하는multiclusterengineCR을 생성합니다. 다중 클러스터 엔진 Operator 네임스페이스에는 연결이 끊긴 배포에서 동작을 수정하려면 구성 맵이 포함되어야 합니다. 네임스페이스에는multicluster-engine,assisted-service,hypershift-addon-managerPod도 포함되어 있습니다. 호스팅된 클러스터를 배포하는 데 필요한 다음 오브젝트를 생성합니다.
- 보안: 시크릿에는 풀 시크릿, SSH 키 및 etcd 암호화 키가 포함됩니다.
- 구성 맵: 구성 맵에는 프라이빗 레지스트리의 CA 인증서가 포함되어 있습니다.
-
HostedCluster:HostedCluster리소스는 사용자가 생성하려는 클러스터의 구성을 정의합니다. -
NodePool:NodePool리소스는 데이터 플레인에 사용할 머신을 참조하는 노드 풀을 식별합니다.
-
호스팅된 클러스터 오브젝트를 생성하면 HyperShift Operator에서 컨트롤 플레인 Pod를 수용하도록
HostedControlPlane네임스페이스를 설정합니다. 네임스페이스는 에이전트, 베어 메탈 호스트(BMH) 및InfraEnv리소스와 같은 구성 요소도 호스팅합니다. 나중에InfraEnv리소스를 생성하고 ISO 생성 후 BMC(Baseboard Management Controller) 인증 정보가 포함된 BMH 및 해당 시크릿을 생성합니다. -
openshift-machine-api네임스페이스의 Metal3 Operator는 새 BMH를 검사합니다. 그런 다음 Metal3 Operator는 다중 클러스터 엔진 Operator 네임스페이스에서AgentServiceConfigCR을 통해 지정된 구성된LiveISO및RootFS값을 사용하여 BMC에 연결을 시도합니다. -
HostedCluster리소스의 작업자 노드가 시작되면 에이전트 컨테이너가 시작됩니다. 이 에이전트는 배포를 완료하기 위한 작업을 오케스트레이션하는 지원 서비스와의 연락처를 설정합니다. 처음에NodePool리소스를HostedCluster리소스의 작업자 노드 수로 스케일링해야 합니다. 지원 서비스는 나머지 작업을 관리합니다. - 이 시점에서 배포 프로세스가 완료될 때까지 기다립니다.
6.3.2. 연결이 끊긴 환경에서 베어 메탈에 호스팅된 컨트롤 플레인을 배포하기 위한 요구사항 링크 복사링크가 클립보드에 복사되었습니다!
연결이 끊긴 환경에서 호스팅되는 컨트롤 플레인을 구성하려면 다음 사전 요구 사항을 충족해야 합니다.
- cpu: 제공된 CPU 수에 따라 동시에 실행할 수 있는 호스트 클러스터 수가 결정됩니다. 일반적으로 노드 3개당 각 노드에 16개의 CPU를 사용합니다. 최소 개발의 경우 노드 3개에 각 노드에 12개의 CPU를 사용할 수 있습니다.
- memory: 호스트할 수 있는 호스트 클러스터 수에 영향을 미칩니다. 각 노드에 48GB의 RAM을 사용합니다. 최소한의 개발의 경우 18GB의 RAM이면 충분합니다.
스토리지: 다중 클러스터 엔진 Operator에 SSD 스토리지를 사용합니다.
- 관리 클러스터: 250GB.
- 레지스트리: 필요한 스토리지는 호스팅되는 릴리스, 운영자 및 이미지 수에 따라 다릅니다. 허용 가능한 숫자는 500GB일 수 있으며, 호스트 클러스터를 호스팅하는 디스크와 분리되는 것이 좋습니다.
- 웹 서버: 필요한 스토리지는 호스팅되는 ISO 및 이미지 수에 따라 다릅니다. 허용 가능한 숫자는 500GB일 수 있습니다.
프로덕션: 프로덕션 환경의 경우 관리 클러스터, 레지스트리 및 웹 서버를 다른 디스크에서 분리합니다. 이 예에서는 프로덕션에 대한 가능한 구성을 보여줍니다.
- 레지스트리: 2TB
- 관리 클러스터: 500GB
- 웹 서버: 2TB
6.3.3. 릴리스 이미지 다이제스트 추출 링크 복사링크가 클립보드에 복사되었습니다!
태그된 이미지를 사용하여 OpenShift Container Platform 릴리스 이미지 다이제스트를 추출할 수 있습니다.
프로세스
다음 명령을 실행하여 이미지 다이제스트를 가져옵니다.
oc adm release info <tagged_openshift_release_image> | grep "Pull From"
$ oc adm release info <tagged_openshift_release_image> | grep "Pull From"Copy to Clipboard Copied! Toggle word wrap Toggle overflow <
tagged_openshift_release_image>를 지원되는 OpenShift Container Platform 버전에 대한 태그된 이미지로 바꿉니다(예:quay.io/openshift-release-dev/ocp-release:4.14.0-x8_64).출력 예
Pull From: quay.io/openshift-release-dev/ocp-release@sha256:69d1292f64a2b67227c5592c1a7d499c7d00376e498634ff8e1946bc9ccdddfe
Pull From: quay.io/openshift-release-dev/ocp-release@sha256:69d1292f64a2b67227c5592c1a7d499c7d00376e498634ff8e1946bc9ccdddfeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.4. 베어 메탈의 DNS 구성 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 클러스터의 API 서버는 NodePort 서비스로 노출됩니다. API Server에 연결할 수 있는 대상을 가리키는 api.<hosted_cluster_name>.<base_domain >에 대한 DNS 항목이 있어야 합니다.
DNS 항목은 호스팅된 컨트롤 플레인을 실행하는 관리 클러스터에서 노드 중 하나를 가리키는 레코드만큼 간단할 수 있습니다. 이 항목은 들어오는 트래픽을 인그레스 포드로 리디렉션하기 위해 배포된 로드 밸런서를 가리킬 수도 있습니다.
DNS 구성 예
이전 예에서 *.apps.example.krnl.es. IN A 192.168.122.23 은 구성된 경우 호스팅 클러스터 또는 로드 밸런서의 노드입니다.
IPv6 네트워크에서 연결이 끊긴 환경에 대해 DNS를 구성하는 경우 구성은 다음 예와 같습니다.
IPv6 네트워크의 DNS 구성 예
듀얼 스택 네트워크에서 연결이 끊긴 환경에 대해 DNS를 구성하는 경우 IPv4 및 IPv6 모두에 대한 DNS 항목을 포함해야 합니다.
듀얼 스택 네트워크의 DNS 구성 예
6.3.5. 연결이 끊긴 환경에서 호스팅된 컨트롤 플레인의 레지스트리 배포 링크 복사링크가 클립보드에 복사되었습니다!
개발 환경의 경우 Podman 컨테이너를 사용하여 소규모 자체 호스팅 레지스트리를 배포합니다. 프로덕션 환경의 경우 Red Hat Quay, Nexus 또는 Artifactory와 같은 엔터프라이즈 호스팅 레지스트리를 배포합니다.
프로세스
Podman을 사용하여 작은 레지스트리를 배포하려면 다음 단계를 완료합니다.
권한 있는 사용자로
${HOME}디렉터리에 액세스하고 다음 스크립트를 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
PULL_SECRET위치를 설정에 적합한 위치로 교체합니다.
스크립트 파일 이름을
registry.sh로 지정하고 저장합니다. 스크립트를 실행하면 다음 정보를 가져옵니다.- 하이퍼바이저 호스트 이름을 기반으로 하는 레지스트리 이름
- 필요한 인증 정보 및 사용자 액세스 세부 정보
다음과 같이 실행 플래그를 추가하여 권한을 조정합니다.
chmod u+x ${HOME}/registry.sh$ chmod u+x ${HOME}/registry.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow 매개변수 없이 스크립트를 실행하려면 다음 명령을 입력합니다.
${HOME}/registry.sh$ ${HOME}/registry.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow 스크립트가 서버를 시작합니다. 스크립트는 관리 목적으로
systemd서비스를 사용합니다.스크립트를 관리해야 하는 경우 다음 명령을 사용할 수 있습니다.
systemctl status
$ systemctl statusCopy to Clipboard Copied! Toggle word wrap Toggle overflow systemctl start
$ systemctl startCopy to Clipboard Copied! Toggle word wrap Toggle overflow systemctl stop
$ systemctl stopCopy to Clipboard Copied! Toggle word wrap Toggle overflow
레지스트리의 루트 폴더는 /opt/registry 디렉터리에 있으며 다음 하위 디렉터리가 포함되어 있습니다.
-
인증서에는TLS 인증서가 포함되어 있습니다. -
auth에는 인증 정보가 포함됩니다. -
데이터에는 레지스트리 이미지가 포함되어 있습니다. -
conf에는 레지스트리 구성이 포함되어 있습니다.
6.3.6. 연결이 끊긴 환경에서 호스팅된 컨트롤 플레인의 관리 클러스터 설정 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 관리 클러스터를 설정하려면 Kubernetes Operator의 다중 클러스터 엔진이 설치되어 있는지 확인해야 합니다. 다중 클러스터 엔진 Operator는 공급자 전체에 클러스터를 배포하는 데 중요한 역할을 합니다.
사전 요구 사항
- 관리 클러스터와 대상 베어 메탈 호스트(BMH)의 BMC(Baseboard Management Controller) 간에 양방향 연결이 있어야 합니다. 또는 에이전트 공급자를 통해 Boot It Yourself 접근 방식을 따릅니다.
호스트된 클러스터는 관리 클러스터 호스트 이름 및
*.apps호스트 이름의 API 호스트 이름을 확인하고 연결할 수 있어야 합니다. 다음은 관리 클러스터의 API 호스트 이름과*.apps호스트 이름의 예입니다.-
api.management-cluster.internal.domain.com -
console-openshift-console.apps.management-cluster.internal.domain.com
-
관리 클러스터는 호스팅된 클러스터의 API 및
*.apps호스트 이름을 확인하고 연결할 수 있어야 합니다. 다음은 호스팅된 클러스터의 API 호스트 이름과*.apps호스트 이름의 예입니다.-
api.sno-hosted-cluster-1.internal.domain.com -
console-openshift-console.apps.sno-hosted-cluster-1.internal.domain.com
-
프로세스
- OpenShift Container Platform 클러스터에 다중 클러스터 엔진 Operator 2.4 이상을 설치합니다. OpenShift Container Platform 소프트웨어 카탈로그에서 다중 클러스터 엔진 Operator를 Operator로 설치할 수 있습니다. HyperShift Operator는 다중 클러스터 엔진 Operator에 포함되어 있습니다. 다중 클러스터 엔진 Operator 설치에 대한 자세한 내용은 Red Hat Advanced Cluster Management 설명서의 "Multicluster 엔진 Operator 설치 및 업그레이드"를 참조하십시오.
- HyperShift Operator가 설치되어 있는지 확인합니다. HyperShift Operator는 멀티 클러스터 엔진 Operator에 자동으로 포함되지만 수동으로 설치해야 하는 경우 "local-cluster용 hypershift-addon 관리 클러스터 애드온 활성화"의 단계를 따르십시오.
다음 단계
다음으로 웹 서버를 구성합니다.
6.3.7. 연결이 끊긴 환경에서 호스팅된 컨트롤 플레인의 웹 서버 구성 링크 복사링크가 클립보드에 복사되었습니다!
호스트 클러스터로 배포 중인 OpenShift Container Platform 릴리스와 연결된 RHCOS(Red Hat Enterprise Linux CoreOS) 이미지를 호스팅하도록 추가 웹 서버를 구성해야 합니다.
프로세스
웹 서버를 구성하려면 다음 단계를 완료합니다.
다음 명령을 입력하여 사용할 OpenShift Container Platform 릴리스에서
openshift-install바이너리를 추출합니다.oc adm -a ${LOCAL_SECRET_JSON} release extract --command=openshift-install \ "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"$ oc adm -a ${LOCAL_SECRET_JSON} release extract --command=openshift-install \ "${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-${ARCHITECTURE}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 스크립트를 실행합니다. 이 스크립트는
/opt/srv디렉터리에 폴더를 생성합니다. 폴더에는 작업자 노드를 프로비저닝하는 RHCOS 이미지가 포함되어 있습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
다운로드가 완료되면 컨테이너가 실행되어 웹 서버에서 이미지를 호스팅합니다. 컨테이너는 공식 HTTPd 이미지의 변형을 사용하여 IPv6 네트워크에서도 작업할 수 있습니다.
6.3.8. 연결이 끊긴 환경에서 호스팅된 컨트롤 플레인의 이미지 미러링 구성 링크 복사링크가 클립보드에 복사되었습니다!
이미지 미러링은 registry.redhat.com 또는 quay.io 와 같은 외부 레지스트리에서 이미지를 가져와서 프라이빗 레지스트리에 저장하는 프로세스입니다.
다음 절차에서는 ImageSetConfiguration 오브젝트를 사용하는 바이너리인 oc-mirror 툴이 사용됩니다. 파일에서 다음 정보를 지정할 수 있습니다.
-
미러링할 OpenShift Container Platform 버전입니다. 버전은
quay.io에 있습니다. - 미러링할 추가 Operator입니다. 패키지를 개별적으로 선택합니다.
- 리포지토리에 추가할 추가 이미지입니다.
사전 요구 사항
- 미러링 프로세스를 시작하기 전에 레지스트리 서버가 실행 중인지 확인합니다.
프로세스
이미지 미러링을 구성하려면 다음 단계를 완료합니다.
-
이미지를 푸시하려는 프라이빗 레지스트리와 미러링할 레지스트리를 사용하여
${HOME}/.docker/config.json파일이 업데이트되었는지 확인합니다. 다음 예제를 사용하여 미러링에 사용할
ImageSetConfiguration오브젝트를 만듭니다. 환경에 맞게 필요에 따라 값을 바꿉니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 미러링 프로세스를 시작합니다.
oc-mirror --v2 --config imagesetconfig.yaml \ --workspace file://mirror-file docker://<registry>
$ oc-mirror --v2 --config imagesetconfig.yaml \ --workspace file://mirror-file docker://<registry>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 미러링 프로세스가 완료되면 IDMS(
ImageDigestMirrorSet),ImageTagMirrorSet(ITMS) 및 호스팅된 클러스터에 적용할 카탈로그 소스가 포함된mirror-file이라는 새 폴더가 있습니다.imagesetconfig.yaml파일을 다음과 같이 구성하여 OpenShift Container Platform의 Nightly 또는 CI 버전을 미러링합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 부분적으로 연결이 끊긴 환경이 있는 경우 다음 명령을 입력하여 이미지 세트 구성의 이미지를 레지스트리로 미러링합니다.
oc mirror -c imagesetconfig.yaml \ --workspace file://<file_path> docker://<mirror_registry_url> --v2
$ oc mirror -c imagesetconfig.yaml \ --workspace file://<file_path> docker://<mirror_registry_url> --v2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 자세한 내용은 "부분 연결이 끊긴 환경에서 이미지 세트 미러링"을 참조하십시오.
완전히 연결이 끊긴 환경이 있는 경우 다음 단계를 수행합니다.
다음 명령을 입력하여 지정된 이미지 세트 구성의 이미지를 디스크로 미러링합니다.
oc mirror -c imagesetconfig.yaml file://<file_path> --v2
$ oc mirror -c imagesetconfig.yaml file://<file_path> --v2Copy to Clipboard Copied! Toggle word wrap Toggle overflow 자세한 내용은 "완전하게 연결이 끊긴 환경에서 이미지 세트 미러링"을 참조하십시오.
디스크에서 이미지 세트 파일을 처리하고 다음 명령을 입력하여 콘텐츠를 대상 미러 레지스트리에 미러링합니다.
oc mirror -c imagesetconfig.yaml \ --from file://<file_path> docker://<mirror_registry_url> --v2
$ oc mirror -c imagesetconfig.yaml \ --from file://<file_path> docker://<mirror_registry_url> --v2Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 연결이 끊긴 네트워크에 설치 단계에 따라 최신 다중 클러스터 엔진 Operator 이미지를 미러링합니다.
6.3.9. 관리 클러스터에 오브젝트 적용 링크 복사링크가 클립보드에 복사되었습니다!
미러링 프로세스가 완료되면 관리 클러스터에 두 개의 오브젝트를 적용해야 합니다.
-
ImageContentSourcePolicy(ICSP) 또는ImageDigestMirrorSet(IDMS) - 카탈로그 소스
oc-mirror 툴을 사용하는 경우 출력 아티팩트는 oc-mirror-workspace/results-XXXXXX/ 이라는 폴더에 있습니다.
ICSP 또는 IDMS는 노드를 재시작하지 않고 각 노드에서 kubelet을 다시 시작하는 MachineConfig 변경을 시작합니다. 노드가 READY 로 표시되면 새로 생성된 카탈로그 소스를 적용해야 합니다.
카탈로그 소스는 카탈로그 이미지 다운로드 및 처리와 같은 openshift-marketplace Operator에서 작업을 시작하여 해당 이미지에 포함된 모든 PackageManifest 를 검색합니다.
프로세스
새 소스를 확인하려면 새
CatalogSource를 소스로 사용하여 다음 명령을 실행합니다.oc get packagemanifest
$ oc get packagemanifestCopy to Clipboard Copied! Toggle word wrap Toggle overflow 아티팩트를 적용하려면 다음 단계를 완료합니다.
다음 명령을 입력하여 ICSP 또는 IDMS 아티팩트를 생성합니다.
oc apply -f oc-mirror-workspace/results-XXXXXX/imageContentSourcePolicy.yaml
$ oc apply -f oc-mirror-workspace/results-XXXXXX/imageContentSourcePolicy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 노드가 준비될 때까지 기다린 다음 다음 명령을 입력합니다.
oc apply -f catalogSource-XXXXXXXX-index.yaml
$ oc apply -f catalogSource-XXXXXXXX-index.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
OLM 카탈로그를 미러링하고 미러를 가리키도록 호스팅 클러스터를 구성합니다.
관리(기본값) OLMCatalogPlacement 모드를 사용하면 관리 클러스터의 ICSP에서 재정의 정보를 사용하여 OLM 카탈로그에 사용되는 이미지 스트림이 자동으로 수정되지 않습니다.-
원래 이름 및 태그를 사용하여 OLM 카탈로그가 내부 레지스트리에 올바르게 미러링된 경우
hypershift.openshift.io/olm-catalogs-is-registry-overrides주석을HostedCluster리소스에 추가합니다. 형식은"sr1=dr1,sr2=dr2"입니다. 여기서 소스 레지스트리 문자열은 키이고 대상 레지스트리는 값입니다. OLM 카탈로그 이미지 스트림 메커니즘을 바이패스하려면
HostedCluster리소스에서 다음 4개의 주석을 사용하여 OLM Operator 카탈로그에 사용할 4개의 이미지의 주소를 직접 지정합니다.-
hypershift.openshift.io/certified-operators-catalog-image -
hypershift.openshift.io/community-operators-catalog-image -
hypershift.openshift.io/redhat-marketplace-catalog-image -
hypershift.openshift.io/redhat-operators-catalog-image
-
-
원래 이름 및 태그를 사용하여 OLM 카탈로그가 내부 레지스트리에 올바르게 미러링된 경우
이 경우 이미지 스트림이 생성되지 않으며 Operator 업데이트를 가져오려면 내부 미러를 새로 고칠 때 주석 값을 업데이트해야 합니다.
다음 단계
호스팅된 컨트롤 플레인의 연결이 끊긴 설치를 위해 다중 클러스터 엔진 Operator 배포 단계를 완료하여 다중 클러스터 엔진 Operator를 배포합니다.
6.3.10. AgentServiceConfig 리소스 배포 링크 복사링크가 클립보드에 복사되었습니다!
AgentServiceConfig 사용자 정의 리소스는 다중 클러스터 엔진 Operator의 일부인 지원 서비스 애드온의 필수 구성 요소입니다. 베어 메탈 클러스터 배포를 담당합니다. 애드온이 활성화되면 AgentServiceConfig 리소스를 배포하여 애드온을 구성합니다.
AgentServiceConfig 리소스를 구성하는 것 외에도 연결이 끊긴 환경에서 다중 클러스터 엔진 Operator가 제대로 작동하는지 확인하기 위해 추가 구성 맵을 포함해야 합니다.
프로세스
배포를 사용자 지정하는 연결이 끊긴 세부 정보가 포함된 다음 구성 맵을 추가하여 사용자 정의 레지스트리를 구성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
dns.base.domain.name을 DNS 기본 도메인 이름으로 교체합니다.
오브젝트에는 다음 두 개의 필드가 있습니다.
- 사용자 정의 CA: 이 필드에는 배포의 다양한 프로세스에 로드되는 CA(인증 기관)가 포함되어 있습니다.
-
Registry:
Registries.conf필드에는 원래 소스 레지스트리가 아닌 미러 레지스트리에서 사용해야 하는 이미지 및 네임스페이스에 대한 정보가 포함되어 있습니다.
다음 예와 같이
AssistedServiceConfig오브젝트를 추가하여 Assisted Service를 구성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
metadata.annotations["unsupported.agent-install.openshift.io/assisted-service-configmap"]주석은 Operator가 동작을 사용자 정의하는 데 사용하는 구성 맵 이름을 참조합니다.- 2
spec.mirrorRegistryRef.name주석은 Assisted Service Operator가 사용하는 연결이 끊긴 레지스트리 정보가 포함된 구성 맵을 가리킵니다. 이 구성 맵은 배포 프로세스 중에 해당 리소스를 추가합니다.- 3
spec.osImages필드에는 이 Operator에서 배포할 수 있는 다양한 버전이 포함되어 있습니다. 이 필드는 필수입니다. 이 예제에서는 이미RootFS및LiveISO파일을 다운로드했다고 가정합니다.- 4
- 배포하려는 모든 OpenShift Container Platform 릴리스에 대해
cpuArchitecture하위 섹션을 추가합니다. 이 예에서는cpuArchitecture하위 섹션이 4.14 및 4.15에 포함되어 있습니다. - 5
rootFSUrl및url필드에서dns.base.domain.name을 DNS 기본 도메인 이름으로 교체합니다.
해당 오브젝트를 단일 파일에 연결하고 관리 클러스터에 적용하여 모든 오브젝트를 배포합니다. 이렇게 하려면 다음 명령을 입력합니다.
oc apply -f agentServiceConfig.yaml
$ oc apply -f agentServiceConfig.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 명령은 두 개의 pod를 트리거합니다.
출력 예
assisted-image-service-0 1/1 Running 2 11d assisted-service-668b49548-9m7xw 2/2 Running 5 11d
assisted-image-service-0 1/1 Running 2 11d1 assisted-service-668b49548-9m7xw 2/2 Running 5 11d2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 단계
TLS 인증서를 구성합니다.
6.3.11. 호스팅된 컨트롤 플레인의 연결이 끊긴 설치를 위한 TLS 인증서 구성 링크 복사링크가 클립보드에 복사되었습니다!
연결이 끊긴 배포에서 제대로 작동하려면 관리 클러스터에서 레지스트리 CA 인증서와 호스팅된 클러스터의 작업자 노드를 구성해야 합니다.
6.3.11.1. 관리 클러스터에 레지스트리 CA 추가 링크 복사링크가 클립보드에 복사되었습니다!
레지스트리 CA를 관리 클러스터에 추가하려면 다음 단계를 완료합니다.
프로세스
다음 예와 유사한 구성 맵을 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터 전체 오브젝트
image.config.openshift.io를 패치하여 다음 사양을 포함합니다.spec: additionalTrustedCA: - name: registry-configspec: additionalTrustedCA: - name: registry-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이 패치로 인해 컨트롤 플레인 노드는 프라이빗 레지스트리에서 이미지를 검색할 수 있으며 HyperShift Operator는 호스팅된 클러스터 배포를 위해 OpenShift Container Platform 페이로드를 추출할 수 있습니다.
오브젝트 패치 프로세스를 완료하는 데 몇 분이 걸릴 수 있습니다.
6.3.11.2. 호스트된 클러스터의 작업자 노드에 레지스트리 CA 추가 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 클러스터의 데이터 플레인 작업자가 프라이빗 레지스트리에서 이미지를 검색하려면 레지스트리 CA를 작업자 노드에 추가해야 합니다.
프로세스
hc.spec.additionalTrustBundle파일에서 다음 사양을 추가합니다.spec: additionalTrustBundle: - name: user-ca-bundlespec: additionalTrustBundle: - name: user-ca-bundle1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
user-ca-bundle항목은 다음 단계에서 생성하는 구성 맵입니다.
HostedCluster오브젝트가 생성된 동일한 네임스페이스에서user-ca-bundle구성 맵을 생성합니다. 구성 맵은 다음 예와 유사합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
HostedCluster오브젝트가 생성되는 네임스페이스를 지정합니다.
6.3.12. 베어 메탈에서 호스트 클러스터 생성 링크 복사링크가 클립보드에 복사되었습니다!
호스팅 클러스터는 관리 클러스터에서 호스팅되는 컨트롤 플레인 및 API 끝점이 있는 OpenShift Container Platform 클러스터입니다. 호스트된 클러스터에는 컨트롤 플레인과 해당 데이터 플레인이 포함됩니다.
6.3.12.1. 호스트된 클러스터 오브젝트 배포 링크 복사링크가 클립보드에 복사되었습니다!
일반적으로 HyperShift Operator는 HostedControlPlane 네임스페이스를 생성합니다. 그러나 이 경우 HyperShift Operator가 HostedCluster 오브젝트를 조정하기 전에 모든 오브젝트를 포함해야 합니다. 그러면 Operator가 조정 프로세스를 시작하면 모든 오브젝트를 찾을 수 있습니다.
프로세스
네임스페이스에 대한 다음 정보를 사용하여 YAML 파일을 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow HostedCluster배포에 포함할 구성 맵 및 시크릿에 대한 다음 정보를 사용하여 YAML 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 지원 서비스 에이전트가 호스팅된 컨트롤 플레인과 동일한
HostedControlPlane네임스페이스에 있을 수 있고 클러스터 API에서 계속 관리할 수 있도록 RBAC 역할이 포함된 YAML 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 필요에 따라 값을 교체하여
HostedCluster오브젝트에 대한 정보를 사용하여 YAML 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1 7 9 12 13
- <
;hosted_cluster_name>을 호스팅된 클러스터로 바꿉니다. - 2 8
- &
lt;hosted_cluster_namespace>를 호스팅된 클러스터 네임스페이스의 이름으로 바꿉니다. - 3
imageContentSources섹션에는 호스팅된 클러스터 내의 사용자 워크로드에 대한 미러 참조가 포함되어 있습니다.- 4 5 6 10
- &
lt;dns.base.domain.name>을 DNS 기본 도메인 이름으로 바꿉니다. - 11
- &
lt;4.x.y>를 사용하려는 지원되는 OpenShift Container Platform 버전으로 바꿉니다.
YAML 파일에 정의된 모든 오브젝트를 파일에 연결하고 관리 클러스터에 적용하여 해당 오브젝트를 생성합니다. 이렇게 하려면 다음 명령을 입력합니다.
oc apply -f 01-4.14-hosted_cluster-nodeport.yaml
$ oc apply -f 01-4.14-hosted_cluster-nodeport.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 호스트 클러스터를 사용할 수 있으면 출력은 다음 예와 같습니다.
출력 예
NAMESPACE NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE clusters hosted-dual hosted-admin-kubeconfig Partial True False The hosted control plane is available
NAMESPACE NAME VERSION KUBECONFIG PROGRESS AVAILABLE PROGRESSING MESSAGE clusters hosted-dual hosted-admin-kubeconfig Partial True False The hosted control plane is availableCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.12.2. 호스트된 클러스터에 대한 NodePool 오브젝트 생성 링크 복사링크가 클립보드에 복사되었습니다!
NodePool 은 호스팅된 클러스터와 연결된 확장 가능한 작업자 노드 집합입니다. NodePool 머신 아키텍처는 특정 풀 내에서 일관되게 유지되며 컨트롤 플레인의 머신 아키텍처와 독립적입니다.
프로세스
NodePool오브젝트에 대한 다음 정보를 사용하여 YAML 파일을 생성하여 필요에 따라 값을 바꿉니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- <
;hosted_cluster_name>을 호스팅된 클러스터로 바꿉니다. - 2
- &
lt;hosted_cluster_namespace>를 호스팅된 클러스터 네임스페이스의 이름으로 바꿉니다. - 3
- 노드가 제거되면 노드가 다시 생성되지 않기 때문에
autoRepair필드가false로 설정됩니다. - 4
upgradeType은 업그레이드 중에 동일한 베어 메탈 노드가 재사용됨을 나타내는InPlace로 설정됩니다.- 5
- 이
NodePool에 포함된 모든 노드는 다음 OpenShift Container Platform 버전4.x.y-x86_64를 기반으로 합니다. <dns.base.domain.name> 값을 DNS 기본 도메인 이름으로 바꾸고4.x.y값을 사용하려는 지원되는 OpenShift Container Platform 버전으로 바꿉니다. - 6
replicas값을2로 설정하여 호스팅된 클러스터에 두 개의 노드 풀 복제본을 생성할 수 있습니다.
다음 명령을 입력하여
NodePool오브젝트를 생성합니다.oc apply -f 02-nodepool.yaml
$ oc apply -f 02-nodepool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAMESPACE NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE clusters hosted-dual hosted 0 False False 4.x.y-x86_64
NAMESPACE NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE clusters hosted-dual hosted 0 False False 4.x.y-x86_64Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.12.3. 호스트된 클러스터에 대한 InfraEnv 리소스 생성 링크 복사링크가 클립보드에 복사되었습니다!
InfraEnv 리소스는 pullSecretRef 및 sshAuthorizedKey 와 같은 필수 세부 정보를 포함하는 지원 서비스 오브젝트입니다. 이러한 세부 사항은 호스팅된 클러스터에 대해 사용자 지정된 RHCOS(Red Hat Enterprise Linux CoreOS) 부팅 이미지를 생성하는 데 사용됩니다.
둘 이상의 InfraEnv 리소스를 호스팅할 수 있으며 각각 특정 유형의 호스트를 채택할 수 있습니다. 예를 들어, RAM 용량이 큰 호스트 간에 서버 POD를 나눌 수 있습니다.
프로세스
필요에 따라 값을 교체하여
InfraEnv리소스에 대한 다음 정보를 사용하여 YAML 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
- <hosted_cluster_namespace>
- 호스팅된 클러스터 네임스페이스의 이름을 지정합니다.
- pullSecretRef
-
가져오기 보안이 사용되는
InfraEnv와 동일한 네임스페이스에 있는 구성 맵 참조를 지정합니다. - sshAuthorizedKey
-
부팅 이미지에 배치된 SSH 공개 키를 지정합니다. SSH 키를 사용하면
core사용자로 작업자 노드에 액세스할 수 있습니다.
다음 명령을 입력하여
InfraEnv리소스를 생성합니다.oc apply -f 03-infraenv.yaml
$ oc apply -f 03-infraenv.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAMESPACE NAME ISO CREATED AT clusters-hosted-dual hosted 2023-09-11T15:14:10Z
NAMESPACE NAME ISO CREATED AT clusters-hosted-dual hosted 2023-09-11T15:14:10ZCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3.12.4. 호스트 클러스터를 위한 베어 메탈 호스트 생성 링크 복사링크가 클립보드에 복사되었습니다!
베어 메탈 호스트 는 Metal3 Operator가 식별할 수 있도록 물리적 및 논리 세부 정보를 포함하는 openshift-machine-api 오브젝트입니다. 이러한 세부 사항은 에이전트 라고 하는 기타 지원 서비스 오브젝트와 연결됩니다.
사전 요구 사항
- 베어 메탈 호스트 및 대상 노드를 생성하기 전에 대상 머신이 준비되어 있어야 합니다.
- 클러스터에서 사용할 베어 메탈 인프라에 RHCOS(Red Hat Enterprise Linux CoreOS) 컴퓨팅 머신을 설치했습니다.
프로세스
베어 메탈 호스트를 생성하려면 다음 단계를 완료합니다.
다음 정보를 사용하여 YAML 파일을 생성합니다. 베어 메탈 호스트에 입력할 세부 정보에 대한 자세한 내용은 "BMO를 사용하여 사용자 프로비저닝 클러스터에서 새 호스트 프로비저닝"을 참조하십시오.
베어 메탈 호스트 인증 정보를 보유하는 시크릿이 하나 이상 있으므로 각 작업자 노드에 대해 두 개 이상의 오브젝트를 생성해야 합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
- <hosted_cluster_name>
- 호스팅된 클러스터의 이름을 지정합니다.
- <hosted_cluster_namespace>
- 호스팅된 클러스터 네임스페이스의 이름을 지정합니다.
- 암호
- Base64 형식의 BMC(Baseboard Management Controller)의 암호를 지정합니다.
- 사용자 이름
- Base64 형식으로 BMC의 사용자 이름을 지정합니다.
- infraenvs.agent-install.openshift.io
-
지원 설치 프로그램과
BareMetalHost오브젝트 간의 링크 역할을 합니다. - bmac.agent-install.openshift.io/hostname
- 배포 중에 채택된 노드 이름을 나타냅니다.
- automatedCleaningMode
- Metal3 Operator에 의해 노드가 지워지지 않도록 합니다.
- disableCertificateVerification
-
클라이언트의 인증서 유효성 검사를 바이패스하려면
true로 설정됩니다. - address
- 작업자 노드의 BMC 주소를 나타냅니다.
- credentialsName
- 사용자 및 암호 인증 정보가 저장된 시크릿을 가리킵니다.
- bootMACAddress
- 노드가 시작되는 인터페이스 MAC 주소를 나타냅니다.
- 온라인
-
BareMetalHost오브젝트가 생성된 후 노드의 상태를 정의합니다.
다음 명령을 입력하여
BareMetalHost오브젝트를 배포합니다.oc apply -f 04-bmh.yaml
$ oc apply -f 04-bmh.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 프로세스 중에 다음 출력을 볼 수 있습니다.
이 출력은 프로세스가 노드에 연결을 시도 중임을 나타냅니다.
출력 예
NAMESPACE NAME STATE CONSUMER ONLINE ERROR AGE clusters-hosted hosted-worker0 registering true 2s clusters-hosted hosted-worker1 registering true 2s clusters-hosted hosted-worker2 registering true 2s
NAMESPACE NAME STATE CONSUMER ONLINE ERROR AGE clusters-hosted hosted-worker0 registering true 2s clusters-hosted hosted-worker1 registering true 2s clusters-hosted hosted-worker2 registering true 2sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이 출력은 노드가 시작됨을 나타냅니다.
출력 예
NAMESPACE NAME STATE CONSUMER ONLINE ERROR AGE clusters-hosted hosted-worker0 provisioning true 16s clusters-hosted hosted-worker1 provisioning true 16s clusters-hosted hosted-worker2 provisioning true 16s
NAMESPACE NAME STATE CONSUMER ONLINE ERROR AGE clusters-hosted hosted-worker0 provisioning true 16s clusters-hosted hosted-worker1 provisioning true 16s clusters-hosted hosted-worker2 provisioning true 16sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이 출력은 노드가 성공적으로 시작되었음을 나타냅니다.
출력 예
NAMESPACE NAME STATE CONSUMER ONLINE ERROR AGE clusters-hosted hosted-worker0 provisioned true 67s clusters-hosted hosted-worker1 provisioned true 67s clusters-hosted hosted-worker2 provisioned true 67s
NAMESPACE NAME STATE CONSUMER ONLINE ERROR AGE clusters-hosted hosted-worker0 provisioned true 67s clusters-hosted hosted-worker1 provisioned true 67s clusters-hosted hosted-worker2 provisioned true 67sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
노드가 시작된 후 다음 예와 같이 네임스페이스의 에이전트를 확인합니다.
출력 예
NAMESPACE NAME CLUSTER APPROVED ROLE STAGE clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0411 true auto-assign clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0412 true auto-assign clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0413 true auto-assign
NAMESPACE NAME CLUSTER APPROVED ROLE STAGE clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0411 true auto-assign clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0412 true auto-assign clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0413 true auto-assignCopy to Clipboard Copied! Toggle word wrap Toggle overflow 에이전트는 설치에 사용할 수 있는 노드를 나타냅니다. 호스트 클러스터에 노드를 할당하려면 노드 풀을 확장합니다.
6.3.12.5. 노드 풀 확장 링크 복사링크가 클립보드에 복사되었습니다!
베어 메탈 호스트를 생성한 후 해당 상태가 Registering 에서 Provisioning (프로비저닝)으로 변경됨. 노드는 에이전트의 LiveISO 및 에이전트 라는 기본 Pod로 시작합니다. 해당 에이전트는 OpenShift Container Platform 페이로드를 설치하기 위해 Assisted Service Operator에서 지침을 받습니다.
프로세스
노드 풀을 확장하려면 다음 명령을 입력합니다.
oc -n <hosted_cluster_namespace> scale nodepool <hosted_cluster_name> \ --replicas 3
$ oc -n <hosted_cluster_namespace> scale nodepool <hosted_cluster_name> \ --replicas 3Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
-
<hosted_cluster_namespace>는 호스팅된 클러스터 네임스페이스의 이름입니다. -
<hosted_cluster_name>은 호스팅된 클러스터의 이름입니다.
-
확장 프로세스가 완료되면 에이전트가 호스팅된 클러스터에 할당되어 있습니다.
출력 예
NAMESPACE NAME CLUSTER APPROVED ROLE STAGE clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0411 hosted true auto-assign clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0412 hosted true auto-assign clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0413 hosted true auto-assign
NAMESPACE NAME CLUSTER APPROVED ROLE STAGE clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0411 hosted true auto-assign clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0412 hosted true auto-assign clusters-hosted aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa0413 hosted true auto-assignCopy to Clipboard Copied! Toggle word wrap Toggle overflow 또한 노드 풀 복제본이 설정되어 있습니다.
출력 예
NAMESPACE NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE clusters hosted hosted 3 False False <4.x.y>-x86_64 Minimum availability requires 3 replicas, current 0 available
NAMESPACE NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE clusters hosted hosted 3 False False <4.x.y>-x86_64 Minimum availability requires 3 replicas, current 0 availableCopy to Clipboard Copied! Toggle word wrap Toggle overflow &
lt;4.x.y>를 사용하려는 지원되는 OpenShift Container Platform 버전으로 바꿉니다.- 노드가 클러스터에 참여할 때까지 기다립니다. 프로세스 중에 에이전트는 단계 및 상태에 대한 업데이트를 제공합니다.
6.4. 연결이 끊긴 환경에서 IBM Z에 호스팅된 컨트롤 플레인 배포 링크 복사링크가 클립보드에 복사되었습니다!
연결이 끊긴 환경의 호스팅된 컨트롤 플레인 배포는 독립형 OpenShift Container Platform과 다르게 작동합니다.
호스팅된 컨트롤 플레인에는 다음 두 가지 환경이 포함됩니다.
- 컨트롤 플레인: 호스팅된 컨트롤 플레인 Pod가 컨트롤 플레인 Operator에 의해 실행되고 관리되는 관리 클러스터에 있습니다.
- 데이터 플레인: 워크로드 및 기타 몇 개의 Pod가 Hosted Cluster Config Operator에 의해 관리되는 호스트 클러스터의 작업자에서 찾습니다.
데이터 플레인의 ICSP( ImagetentSourcePolicy ) 사용자 정의 리소스는 호스팅된 클러스터 매니페스트의 ImageContentSources API를 통해 관리됩니다.
컨트롤 플레인의 경우 ICSP 오브젝트는 관리 클러스터에서 관리됩니다. 이러한 오브젝트는 HyperShift Operator에서 구문 분석하고 Control Plane Operator와 registry-overrides 항목으로 공유됩니다. 이러한 항목은 호스팅된 컨트롤 플레인 네임스페이스에서 사용 가능한 배포 중 하나에 인수로 삽입됩니다.
호스팅된 컨트롤 플레인에서 연결이 끊긴 레지스트리를 사용하려면 먼저 관리 클러스터에 적절한 ICSP를 생성해야 합니다. 그런 다음 데이터 플레인에 연결이 끊긴 워크로드를 배포하려면 호스트 클러스터 매니페스트의 ImageContentSources 필드에 원하는 항목을 추가해야 합니다.
6.4.1. 연결이 끊긴 환경에서 IBM Z에 호스팅된 컨트롤 플레인을 배포하기 위한 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
- 미러 레지스트리입니다. 자세한 내용은 "Red Hat OpenShift용 미러 레지스트리를 사용하여 미러 레지스트리 생성"을 참조하십시오.
- 연결이 끊긴 설치를 위한 미러링된 이미지입니다. 자세한 내용은 "oc-mirror 플러그인을 사용하여 연결이 끊긴 설치의 이미지 미러링"을 참조하십시오.
6.4.2. 관리 클러스터에 인증 정보 및 레지스트리 인증 기관 추가 링크 복사링크가 클립보드에 복사되었습니다!
관리 클러스터에서 미러 레지스트리 이미지를 가져오려면 먼저 미러 레지스트리의 인증 기관과 인증 기관을 관리 클러스터에 추가해야 합니다. 다음 절차를 사용하십시오.
프로세스
다음 명령을 실행하여 미러 레지스트리의 인증서로
ConfigMap을 생성합니다.oc apply -f registry-config.yaml
$ oc apply -f registry-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow registry-config.yaml 파일 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 항목을 포함하도록
image.config.openshift.io클러스터 전체 오브젝트를 패치합니다.spec: additionalTrustedCA: - name: registry-configspec: additionalTrustedCA: - name: registry-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow 관리 클러스터 풀 시크릿을 업데이트하여 미러 레지스트리의 인증 정보를 추가합니다.
다음 명령을 실행하여 클러스터에서 풀 시크릿을 JSON 형식으로 가져옵니다.
oc get secret/pull-secret -n openshift-config -o json \ | jq -r '.data.".dockerconfigjson"' \ | base64 -d > authfile
$ oc get secret/pull-secret -n openshift-config -o json \ | jq -r '.data.".dockerconfigjson"' \ | base64 -d > authfileCopy to Clipboard Copied! Toggle word wrap Toggle overflow 인증 기관의 인증 정보가 있는 섹션을 포함하도록 가져온 시크릿 JSON 파일을 편집합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 클러스터에서 풀 시크릿을 업데이트합니다.
oc set data secret/pull-secret -n openshift-config \ --from-file=.dockerconfigjson=authfile
$ oc set data secret/pull-secret -n openshift-config \ --from-file=.dockerconfigjson=authfileCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.4.3. AgentServiceConfig 리소스의 레지스트리 인증 기관을 미러 레지스트리로 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
이미지에 미러 레지스트리를 사용하는 경우 에이전트는 이미지를 안전하게 가져오려면 레지스트리의 인증서를 신뢰해야 합니다. ConfigMap 을 생성하여 미러 레지스트리의 인증 기관을 AgentServiceConfig 사용자 정의 리소스에 추가할 수 있습니다.
사전 요구 사항
- Kubernetes Operator를 위해 다중 클러스터 엔진이 설치되어 있어야 합니다.
프로세스
다중 클러스터 엔진 Operator를 설치한 동일한 네임스페이스에서 미러 레지스트리 세부 정보를 사용하여
ConfigMap리소스를 생성합니다. 이ConfigMap리소스를 사용하면 호스팅 클러스터 작업자에게 미러 레지스트리에서 이미지를 검색할 수 있는 기능을 부여할 수 있습니다.ConfigMap 파일 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 여기서 &
lt;mirror_registry>는 미러 레지스트리의 이름입니다.
AgentServiceConfig리소스를 패치하여 생성한ConfigMap리소스를 포함합니다.AgentServiceConfig리소스가 없으면 다음 콘텐츠가 포함된AgentServiceConfig리소스를 생성합니다.spec: mirrorRegistryRef: name: mirror-configspec: mirrorRegistryRef: name: mirror-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.4.4. 호스트 클러스터에 레지스트리 인증 기관 추가 링크 복사링크가 클립보드에 복사되었습니다!
연결이 끊긴 환경에서 IBM Z에 호스팅되는 컨트롤 플레인을 배포하는 경우 additional-trust-bundle 및 image-content-sources 리소스를 포함합니다. 이러한 리소스를 사용하면 호스팅된 클러스터가 데이터 플레인 작업자에 인증 기관을 삽입하여 레지스트리에서 이미지를 가져올 수 있습니다.
image-content-sources정보를 사용하여icsp.yaml파일을 생성합니다.image-content-sources정보는oc-mirror를 사용하여 이미지를 미러링한 후 생성된ImageContentSourcePolicyYAML 파일에서 사용할 수 있습니다.ImageContentSourcePolicy 파일 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 호스트된 클러스터를 생성하고
additional-trust-bundle인증서를 제공하여 다음 예와 같이 컴퓨팅 노드를 인증서로 업데이트합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;hosted_cluster_name>을 호스트된 클러스터 이름으로 바꿉니다. - 2
- 풀 시크릿의 경로를 바꿉니다(예:
/user/name/pullsecret). - 3
<hosted_control_plane_namespace>를 호스트된 컨트롤 플레인 네임스페이스의 이름으로 바꿉니다(예:클러스터 호스팅).- 4
- 이름을 기본 도메인으로 바꿉니다(예:
example.com). - 5
- etcd 스토리지 클래스 이름을 교체합니다(예:
lvm-storageclass). - 6
- SSH 공개 키의 경로를 바꿉니다. 기본 파일 경로는
~/.ssh/id_rsa.pub입니다. - 7 8
- 사용하려는 지원되는 OpenShift Container Platform 버전으로 바꿉니다(예:
4.20.0-multi). - 9
- 미러 레지스트리의 인증 기관 경로를 교체합니다.
6.5. 연결이 끊긴 환경에서 사용자 워크로드 모니터링 링크 복사링크가 클립보드에 복사되었습니다!
하이퍼shift-addon 관리 클러스터 애드온은 HyperShift Operator에서 --enable-uwm-telemetry-remote-write 옵션을 활성화합니다. 이 옵션을 활성화하면 사용자 워크로드 모니터링이 활성화되고 컨트롤 플레인에서 Telemetry 메트릭을 원격으로 작성할 수 있습니다.
6.5.1. 사용자 워크로드 모니터링 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
인터넷에 연결되지 않은 OpenShift Container Platform 클러스터에 다중 클러스터 엔진 Operator를 설치하는 경우 다음 명령을 입력하여 HyperShift Operator의 사용자 워크로드 모니터링 기능을 실행하려고 하면 오류와 함께 기능이 실패합니다.
oc get events -n hypershift
$ oc get events -n hypershift
오류 예
LAST SEEN TYPE REASON OBJECT MESSAGE 4m46s Warning ReconcileError deployment/operator Failed to ensure UWM telemetry remote write: cannot get telemeter client secret: Secret "telemeter-client" not found
LAST SEEN TYPE REASON OBJECT MESSAGE
4m46s Warning ReconcileError deployment/operator Failed to ensure UWM telemetry remote write: cannot get telemeter client secret: Secret "telemeter-client" not found
오류를 해결하려면 local-cluster 네임스페이스에 구성 맵을 생성하여 사용자 워크로드 모니터링 옵션을 비활성화해야 합니다. 애드온을 활성화하기 전이나 후에 구성 맵을 생성할 수 있습니다. 애드온 에이전트는 HyperShift Operator를 재구성합니다.
프로세스
다음 구성 맵을 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 구성 맵을 적용합니다.
oc apply -f <filename>.yaml
$ oc apply -f <filename>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6.5.2. 호스트된 컨트롤 플레인 기능의 상태 확인 링크 복사링크가 클립보드에 복사되었습니다!
호스트된 컨트롤 플레인 기능은 기본적으로 활성화되어 있습니다.
프로세스
기능이 비활성화되고 이를 활성화하려면 다음 명령을 입력합니다. &
lt;multiclusterengine>을 다중 클러스터 엔진 Operator 인스턴스의 이름으로 바꿉니다.oc patch mce <multiclusterengine> --type=merge -p \ '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": true}]}}}'$ oc patch mce <multiclusterengine> --type=merge -p \ '{"spec":{"overrides":{"components":[{"name":"hypershift","enabled": true}]}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 기능을 활성화하면
hypershift-addon관리 클러스터 애드온이로컬 클러스터 관리 클러스터에설치되고 애드온 에이전트는 다중 클러스터 엔진 Operator 허브 클러스터에 HyperShift Operator를 설치합니다.다음 명령을 입력하여
hypershift-addon관리 클러스터 애드온이 설치되었는지 확인합니다.oc get managedclusteraddons -n local-cluster hypershift-addon
$ oc get managedclusteraddons -n local-cluster hypershift-addonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME AVAILABLE DEGRADED PROGRESSING hypershift-addon True False
NAME AVAILABLE DEGRADED PROGRESSING hypershift-addon True FalseCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이 프로세스 중에 시간 초과를 방지하려면 다음 명령을 입력합니다.
oc wait --for=condition=Degraded=True managedclusteraddons/hypershift-addon \ -n local-cluster --timeout=5m
$ oc wait --for=condition=Degraded=True managedclusteraddons/hypershift-addon \ -n local-cluster --timeout=5mCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc wait --for=condition=Available=True managedclusteraddons/hypershift-addon \ -n local-cluster --timeout=5m
$ oc wait --for=condition=Available=True managedclusteraddons/hypershift-addon \ -n local-cluster --timeout=5mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 프로세스가 완료되면
hypershift-addon관리 클러스터 애드온 및 HyperShift Operator가 설치되고로컬 클러스터관리 클러스터를 호스팅 및 관리할 수 있습니다.
6.5.3. 인프라 노드에서 실행되도록 하이퍼shift-addon 관리 클러스터 애드온 구성 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 hypershift-addon 관리 클러스터 애드온에 노드 배치 기본 설정은 지정되지 않습니다. 인프라 노드에서 애드온을 실행하는 것이 좋습니다. 이렇게 하면 서브스크립션 수와 별도의 유지 관리 및 관리 작업에 대해 청구 비용이 발생하지 않도록 할 수 있습니다.
프로세스
- hub 클러스터에 로그인합니다.
다음 명령을 입력하여 편집할
hypershift-addon-deploy-config배포 구성 사양을 엽니다.oc edit addondeploymentconfig hypershift-addon-deploy-config \ -n multicluster-engine
$ oc edit addondeploymentconfig hypershift-addon-deploy-config \ -n multicluster-engineCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예와 같이
nodePlacement필드를 사양에 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
변경 사항을 저장합니다.
하이퍼shift-addon관리 클러스터 애드온은 신규 및 기존 관리 클러스터를 위해 인프라 노드에 배포됩니다.
7장. 호스팅된 컨트롤 플레인의 인증서 구성 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 컨트롤 플레인을 사용하면 인증서를 구성하는 단계가 독립 실행형 OpenShift Container Platform과 다릅니다.
7.1. 호스트된 클러스터에서 사용자 정의 API 서버 인증서 구성 링크 복사링크가 클립보드에 복사되었습니다!
API 서버의 사용자 정의 인증서를 구성하려면 HostedCluster 구성의 spec.configuration.apiServer 섹션에 인증서 세부 정보를 지정합니다.
day-1 또는 day-2 작업 중에 사용자 정의 인증서를 구성할 수 있습니다. 그러나 호스트 클러스터 생성 중에 서비스 게시 전략은 변경할 수 없으므로 구성하려는 Kubernetes API 서버의 호스트 이름이 무엇인지 알아야 합니다.
사전 요구 사항
관리 클러스터에 사용자 정의 인증서가 포함된 Kubernetes 시크릿을 생성했습니다. 보안에는 다음 키가 포함되어 있습니다.
-
TLS.crt: 인증서 -
TLS.key: 개인 키
-
-
HostedCluster구성에 로드 밸런서를 사용하는 서비스 게시 전략이 포함된 경우 인증서의 SAN(주체 대체 이름)이 내부 API 끝점(api-int)과 충돌하지 않는지 확인합니다. 내부 API 끝점은 플랫폼에서 자동으로 생성 및 관리합니다. 사용자 정의 인증서와 내부 API 끝점 모두에서 동일한 호스트 이름을 사용하는 경우 라우팅 충돌이 발생할 수 있습니다. 이 규칙의 유일한 예외는Private또는PublicAndPrivate구성이 있는 공급자로 AWS를 사용하는 경우입니다. 이러한 경우 SAN 충돌은 플랫폼에 의해 관리됩니다. - 인증서는 외부 API 끝점에 유효해야 합니다.
- 인증서의 유효 기간은 클러스터의 예상 라이프 사이클과 일치합니다.
프로세스
다음 명령을 입력하여 사용자 정의 인증서로 보안을 생성합니다.
oc create secret tls sample-hosted-kas-custom-cert \ --cert=path/to/cert.crt \ --key=path/to/key.key \ -n <hosted_cluster_namespace>
$ oc create secret tls sample-hosted-kas-custom-cert \ --cert=path/to/cert.crt \ --key=path/to/key.key \ -n <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예와 같이 사용자 정의 인증서 세부 정보를 사용하여
HostedCluster구성을 업데이트합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여
HostedCluster구성에 변경 사항을 적용합니다.oc apply -f <hosted_cluster_config>.yaml
$ oc apply -f <hosted_cluster_config>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
- API 서버 pod를 확인하여 새 인증서가 마운트되었는지 확인합니다.
- 사용자 정의 도메인 이름을 사용하여 API 서버에 대한 연결을 테스트합니다.
-
브라우저에서 인증서 세부 정보를 확인하거나
openssl과 같은 도구를 사용하여 확인합니다.
7.2. 호스트 클러스터의 Kubernetes API 서버 구성 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 클러스터에 대한 Kubernetes API 서버를 사용자 지정하려면 다음 단계를 완료합니다.
사전 요구 사항
- 실행 중인 호스트 클러스터가 있어야 합니다.
-
HostedCluster리소스를 수정할 수 있습니다. Kubernetes API 서버에 사용할 사용자 정의 DNS 도메인이 있습니다.
- 사용자 정의 DNS 도메인을 올바르게 구성하고 확인할 수 있어야 합니다.
- DNS 도메인에는 유효한 TLS 인증서가 구성되어 있어야 합니다.
- 도메인에 대한 네트워크 액세스는 사용자 환경에 올바르게 구성되어 있어야 합니다.
- 사용자 정의 DNS 도메인은 호스팅된 클러스터 전체에서 고유해야 합니다.
- 사용자 정의 인증서가 구성되어 있습니다. 자세한 내용은 "호스트된 클러스터에서 사용자 정의 API 서버 인증서 구성"을 참조하십시오.
프로세스
공급자 플랫폼에서
kubeAPIServerDNSNameURL이 Kubernetes API 서버가 노출되는 IP 주소를 가리키도록 DNS 레코드를 구성합니다. DNS 레코드를 올바르게 구성하고 클러스터에서 확인할 수 있어야 합니다.DNS 레코드를 구성하는 명령 예
dig + short kubeAPIServerDNSName
$ dig + short kubeAPIServerDNSNameCopy to Clipboard Copied! Toggle word wrap Toggle overflow HostedCluster사양에서 다음 예와 같이kubeAPIServerDNSName필드를 수정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 구성을 적용합니다.
oc -f <hosted_cluster_spec>.yaml
$ oc -f <hosted_cluster_spec>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 구성이 적용되면 HyperShift Operator에서 사용자 정의 DNS 도메인을 가리키는 새
kubeconfig시크릿을 생성합니다.CLI 또는 콘솔을 사용하여
kubeconfig시크릿을 검색합니다.CLI를 사용하여 시크릿을 검색하려면 다음 명령을 입력합니다.
kubectl get secret <hosted_cluster_name>-custom-admin-kubeconfig \ -n <cluster_namespace> \ -o jsonpath='{.data.kubeconfig}' | base64 -d$ kubectl get secret <hosted_cluster_name>-custom-admin-kubeconfig \ -n <cluster_namespace> \ -o jsonpath='{.data.kubeconfig}' | base64 -dCopy to Clipboard Copied! Toggle word wrap Toggle overflow 콘솔을 사용하여 시크릿을 검색하려면 호스팅된 클러스터로 이동하고 Kubeconfig 다운로드를 클릭합니다.
참고콘솔에서 show login 명령 옵션을 사용하여 새
kubeconfig시크릿을 사용할 수 없습니다.
7.3. 사용자 정의 DNS를 사용하여 호스트 클러스터에 액세스 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
사용자 지정 DNS를 사용하여 호스팅 클러스터에 액세스할 때 문제가 발생하면 다음 단계를 완료합니다.
절차
- DNS 레코드가 올바르게 구성되어 해결되었는지 확인합니다.
사용자 정의 도메인의 TLS 인증서가 유효한지 확인하고 다음 명령을 입력하여 도메인에 SAN이 올바른지 확인합니다.
oc get secret \ -n clusters <serving_certificate_name> \ -o jsonpath='{.data.tls\.crt}' | base64 \ -d |openssl x509 -text -noout -$ oc get secret \ -n clusters <serving_certificate_name> \ -o jsonpath='{.data.tls\.crt}' | base64 \ -d |openssl x509 -text -noout -Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 사용자 지정 도메인에 대한 네트워크 연결이 작동하는지 확인합니다.
HostedCluster리소스에서 다음 예와 같이 상태에 올바른 사용자 지정kubeconfig정보가 표시되는지 확인합니다.HostedCluster상태 예status: customKubeconfig: name: sample-hosted-custom-admin-kubeconfigstatus: customKubeconfig: name: sample-hosted-custom-admin-kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여
HostedControlPlane네임스페이스에서kube-apiserver로그를 확인합니다.oc logs -n <hosted_control_plane_namespace> \ -l app=kube-apiserver -f -c kube-apiserver
$ oc logs -n <hosted_control_plane_namespace> \ -l app=kube-apiserver -f -c kube-apiserverCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8장. 호스트된 컨트롤 플레인 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 컨트롤 플레인을 업데이트하려면 호스팅된 클러스터 및 노드 풀을 업데이트해야 합니다. 업데이트 프로세스 중에 클러스터가 완전히 작동하려면 컨트롤 플레인 및 노드 업데이트를 완료하는 동안 Kubernetes 버전 스큐 정책의 요구 사항을 충족해야 합니다.
8.1. 호스팅된 컨트롤 플레인을 업그레이드하기 위한 요구사항 링크 복사링크가 클립보드에 복사되었습니다!
Kubernetes Operator의 멀티 클러스터 엔진은 하나 이상의 OpenShift Container Platform 클러스터를 관리할 수 있습니다. OpenShift Container Platform에서 호스팅된 클러스터를 생성한 후 multicluster 엔진 Operator에서 호스팅된 클러스터를 관리 클러스터로 가져와야 합니다. 그런 다음 OpenShift Container Platform 클러스터를 관리 클러스터로 사용할 수 있습니다.
호스팅된 컨트롤 플레인 업데이트를 시작하기 전에 다음 요구 사항을 고려하십시오.
- OpenShift Virtualization을 공급자로 사용할 때 OpenShift Container Platform 클러스터에 베어 메탈 플랫폼을 사용해야 합니다.
-
베어 메탈 또는 OpenShift Virtualization을 호스팅된 클러스터의 클라우드 플랫폼으로 사용해야 합니다. 호스팅된 클러스터의 플랫폼 유형은
HostedClusterCR(사용자 정의 리소스)의spec.Platform.type사양에서 찾을 수 있습니다.
호스팅된 컨트롤 플레인을 다음 순서로 업데이트해야 합니다.
- OpenShift Container Platform 클러스터를 최신 버전으로 업그레이드합니다. 자세한 내용은 "웹 콘솔을 사용하여 클러스터 업그레이드" 또는 " CLI를 사용하여 클러스터 업그레이드"를 참조하십시오.
- multicluster 엔진 Operator를 최신 버전으로 업그레이드합니다. 자세한 내용은 "설치된 Operator 업그레이드"를 참조하십시오.
- 호스팅된 클러스터 및 노드 풀을 이전 OpenShift Container Platform 버전에서 최신 버전으로 업그레이드합니다. 자세한 내용은 "호스트 클러스터에서 컨트롤 플레인 업그레이드" 및 "호스트된 클러스터에서 노드 풀 업그레이드"를 참조하십시오.
8.2. 호스트 클러스터에서 채널 설정 링크 복사링크가 클립보드에 복사되었습니다!
HostedCluster CR(사용자 정의 리소스)의 HostedCluster.Status 필드에서 사용 가능한 업데이트를 확인할 수 있습니다.
사용 가능한 업데이트는 호스팅된 클러스터의 CVO(Cluster Version Operator)에서 가져오지 않습니다. 사용 가능한 업데이트 목록은 HostedCluster CR(사용자 정의 리소스)의 다음 필드에서 사용 가능한 업데이트와 다를 수 있습니다.
-
status.version.availableUpdates -
status.version.conditionalUpdates
초기 HostedCluster CR에는 status.version.availableUpdates 및 status.version.conditionalUpdates 필드에 정보가 없습니다. spec.channel 필드를 안정적인 OpenShift Container Platform 릴리스 버전으로 설정하면 HyperShift Operator가 HostedCluster CR을 조정하고 사용 가능한 조건부 업데이트로 status.version 필드를 업데이트합니다.
채널 구성이 포함된 HostedCluster CR의 다음 예제를 참조하십시오.
- 1
- &
lt;4.y>를spec.release에서 지정한 OpenShift Container Platform 릴리스 버전으로 바꿉니다. 예를 들어spec.release를ocp-release:4.16.4-multi로 설정하는 경우spec.channel을stable-4.16으로 설정해야 합니다.
HostedCluster CR에서 채널을 구성한 후 status.version. availableUpdates 및 필드의 출력을 보려면 다음 명령을 실행합니다.
status.version.conditionalUpdates
oc get -n <hosted_cluster_namespace> hostedcluster <hosted_cluster_name> -o yaml
$ oc get -n <hosted_cluster_namespace> hostedcluster <hosted_cluster_name> -o yaml
출력 예
8.3. 호스트된 클러스터에서 OpenShift Container Platform 버전 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 컨트롤 플레인을 사용하면 컨트롤 플레인과 데이터 플레인 간의 업데이트를 분리할 수 있습니다.
클러스터 서비스 공급자 또는 클러스터 관리자는 컨트롤 플레인과 데이터를 별도로 관리할 수 있습니다.
NodePool CR을 수정하여 HostedCluster CR(사용자 정의 리소스) 및 노드를 수정하여 컨트롤 플레인을 업데이트할 수 있습니다. HostedCluster 및 NodePool CR 모두 .release 필드에 OpenShift Container Platform 릴리스 이미지를 지정합니다.
업데이트 프로세스 중에 호스팅 클러스터를 완전히 작동하려면 컨트롤 플레인 및 노드 업데이트가 Kubernetes 버전 스큐 정책을 따라야 합니다.
8.3.1. 다중 클러스터 엔진 Operator 허브 관리 클러스터 링크 복사링크가 클립보드에 복사되었습니다!
Kubernetes Operator용 멀티 클러스터 엔진에는 관리 클러스터가 지원되는 상태로 유지되려면 특정 OpenShift Container Platform 버전이 필요합니다. OpenShift Container Platform 웹 콘솔의 소프트웨어 카탈로그에서 다중 클러스터 엔진 Operator를 설치할 수 있습니다.
다중 클러스터 엔진 Operator 버전은 다음과 같은 지원을 참조하십시오.
멀티 클러스터 엔진 Operator는 다음 OpenShift Container Platform 버전을 지원합니다.
- 릴리스되지 않은 최신 버전
- 최신 릴리스 버전
- 최신 릴리스 버전 이전 두 버전
또한 RHACM(Red Hat Advanced Cluster Management)의 일부로 다중 클러스터 엔진 Operator 버전을 가져올 수도 있습니다.
8.3.2. 호스트 클러스터에서 지원되는 OpenShift Container Platform 버전 링크 복사링크가 클립보드에 복사되었습니다!
호스트 클러스터를 배포할 때 관리 클러스터의 OpenShift Container Platform 버전은 호스팅된 클러스터의 OpenShift Container Platform 버전에 영향을 미치지 않습니다.
HyperShift Operator는 hypershift 네임스페이스에 supported-versions ConfigMap을 생성합니다. supported-versions ConfigMap은 배포할 수 있는 지원되는 OpenShift Container Platform 버전 범위를 설명합니다.
supported-versions ConfigMap의 다음 예제를 참조하십시오.
호스트된 클러스터를 생성하려면 지원 버전 범위에서 OpenShift Container Platform 버전을 사용해야 합니다. 그러나 다중 클러스터 엔진 Operator는 n+1 과 n-2 OpenShift Container Platform 버전 간에만 관리할 수 있습니다. 여기서 n 은 현재 마이너 버전을 정의합니다. 다중 클러스터 엔진 Operator 지원 매트릭스를 확인하여 다중 클러스터 엔진 Operator에서 관리하는 호스트 클러스터가 지원되는 OpenShift Container Platform 범위 내에 있는지 확인할 수 있습니다.
OpenShift Container Platform에 호스트된 클러스터의 상위 버전을 배포하려면 새 버전의 Hypershift Operator를 배포하려면 multicluster 엔진 Operator를 새 마이너 버전 릴리스로 업데이트해야 합니다. 다중 클러스터 엔진 Operator를 새 패치 또는 z-stream으로 업그레이드해도 HyperShift Operator가 다음 버전으로 업데이트되지 않습니다.
관리 클러스터에서 OpenShift Container Platform 4.16에 지원되는 OpenShift Container Platform 버전을 보여주는 hcp version 명령의 다음 예제 출력을 참조하십시오.
Client Version: openshift/hypershift: fe67b47fb60e483fe60e4755a02b3be393256343. Latest supported OCP: 4.17.0 Server Version: 05864f61f24a8517731664f8091cedcfc5f9b60d Server Supports OCP Versions: 4.17, 4.16, 4.15, 4.14
Client Version: openshift/hypershift: fe67b47fb60e483fe60e4755a02b3be393256343. Latest supported OCP: 4.17.0
Server Version: 05864f61f24a8517731664f8091cedcfc5f9b60d
Server Supports OCP Versions: 4.17, 4.16, 4.15, 4.14
8.4. 호스팅된 클러스터 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
spec.release.image 값은 컨트롤 플레인의 버전을 지정합니다. HostedCluster 오브젝트는 의도한 spec.release.image 값을 HostedControlPlane.spec.releaseImage 값으로 전송하고 적절한 Control Plane Operator 버전을 실행합니다.
호스팅된 컨트롤 플레인은 새로운 버전의 CVO(Cluster Version Operator)를 통해 OpenShift Container Platform 구성 요소와 함께 새 버전의 컨트롤 플레인 구성 요소의 롤아웃을 관리합니다.
호스팅된 컨트롤 플레인에서 NodeHealthCheck 리소스는 CVO의 상태를 감지할 수 없습니다. 클러스터 관리자는 새 수정 작업이 클러스터 업데이트를 방해하지 않도록 클러스터 업데이트와 같은 중요한 작업을 수행하기 전에 NodeHealthCheck 에서 트리거한 수정을 수동으로 일시 중지해야 합니다.
수정을 일시 중지하려면 NodeHealthCheck 리소스의 pauseRequests 필드 값으로 pause-test-cluster 와 같은 문자열 배열을 입력합니다. 자세한 내용은 Node Health Check Operator 정보를 참조하십시오.
클러스터 업데이트가 완료되면 수정을 편집하거나 삭제할 수 있습니다. Compute → NodeHealthCheck 페이지로 이동하여 노드 상태 점검을 클릭한 다음 드롭다운 목록이 표시되는 작업을 클릭합니다.
8.5. 노드 풀 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
노드 풀을 사용하면 spec.release 및 spec.config 값을 노출하여 노드에서 실행 중인 소프트웨어를 구성할 수 있습니다. 다음과 같은 방법으로 롤링 노드 풀 업데이트를 시작할 수 있습니다.
-
spec.release또는spec.config값을 변경합니다. - AWS 인스턴스 유형과 같은 플랫폼별 필드를 변경합니다. 결과는 새 유형의 새 인스턴스 집합입니다.
- 클러스터 구성을 변경하면 변경 사항이 노드로 전파됩니다.
노드 풀은 업데이트 및 인플레이스 업데이트를 교체할 수 있습니다. nodepool.spec.release 값은 특정 노드 풀의 버전을 지정합니다. NodePool 오브젝트는 .spec.management.upgradeType 값에 따라 교체 또는 인플레이스 롤링 업데이트를 완료합니다.
노드 풀을 생성한 후에는 업데이트 유형을 변경할 수 없습니다. 업데이트 유형을 변경하려면 노드 풀을 생성하고 다른 노드를 삭제해야 합니다.
8.5.1. 노드 풀 교체 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
교체 업데이트는 이전 버전에서 이전 인스턴스를 제거하는 동안 새 버전에 인스턴스를 생성합니다. 이 업데이트 유형은 이러한 수준의 불변성을 비용 효율적으로 사용하는 클라우드 환경에서 효과가 있습니다.
교체 업데이트에서는 노드가 완전히 다시 프로비저닝되므로수동 변경 사항이 유지되지 않습니다.
8.5.2. 노드 풀의 인플레이스 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
인플레이스 업데이트는 인스턴스의 운영 체제를 직접 업데이트합니다. 이 유형은 베어 메탈과 같이 인프라 제약 조건이 높은 환경에 적합합니다.
인플레이스 업데이트는 수동 변경 사항을 유지할 수 있지만 kubelet 인증서와 같이 클러스터가 직접 관리하는 파일 시스템 또는 운영 체제 구성을 수동으로 변경하면 오류를 보고합니다.
8.6. 호스트 클러스터에서 노드 풀 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 클러스터의 노드 풀을 업데이트하여 OpenShift Container Platform 버전을 업데이트할 수 있습니다. 노드 풀 버전은 호스팅된 컨트롤 플레인 버전을 초과해서는 안 됩니다.
NodePool CR(사용자 정의 리소스)의 .spec.release 필드에는 노드 풀 버전이 표시됩니다.
프로세스
다음 명령을 입력하여 노드 풀에서
spec.release.image값을 변경합니다.oc patch nodepool <node_pool_name> -n <hosted_cluster_namespace> \ --type=merge \ -p '{"spec":{"nodeDrainTimeout":"60s","release":{"image":"<openshift_release_image>"}}}'$ oc patch nodepool <node_pool_name> -n <hosted_cluster_namespace> \1 --type=merge \ -p '{"spec":{"nodeDrainTimeout":"60s","release":{"image":"<openshift_release_image>"}}}'2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
새 버전이 롤아웃되었는지 확인하려면 다음 명령을 실행하여 노드 풀에서
.status.conditions값을 확인합니다.oc get -n <hosted_cluster_namespace> nodepool <node_pool_name> -o yaml
$ oc get -n <hosted_cluster_namespace> nodepool <node_pool_name> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;4.y.z>를 지원되는 OpenShift Container Platform 버전으로 교체합니다.
8.7. 호스트 클러스터에서 컨트롤 플레인 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 컨트롤 플레인에서는 호스팅된 클러스터를 업데이트하여 OpenShift Container Platform 버전을 업그레이드할 수 있습니다. HostedCluster CR(사용자 정의 리소스)의 .spec.release 에는 컨트롤 플레인의 버전이 표시됩니다. HostedCluster 는 .spec.release 필드를 HostedControlPlane.spec.release 로 업데이트하고 적절한 Control Plane Operator 버전을 실행합니다.
HostedControlPlane 리소스는 새 버전의 CVO(Cluster Version Operator)를 통해 데이터 플레인의 OpenShift Container Platform 구성 요소와 함께 새 버전의 컨트롤 플레인 구성 요소의 롤아웃을 오케스트레이션합니다. HostedControlPlane 에는 다음과 같은 아티팩트가 포함되어 있습니다.
- CVO
- CNO(Cluster Network Operator)
- Cluster Ingress Operator
- Kube API 서버, 스케줄러 및 관리자에 대한 매니페스트
- 머신 승인자
- 자동 스케일러
- Kube API 서버, ignition 및 konnectivity와 같은 컨트롤 플레인 끝점에 대한 수신을 활성화하는 인프라 리소스
status.version.availableUpdates 및 status.version.conditionalUpdates 필드의 정보를 사용하여 컨트롤 플레인을 업데이트하도록 HostedCluster CR에서 .spec.release 필드를 설정할 수 있습니다.
프로세스
다음 명령을 입력하여
하이퍼shift.openshift.io/force-upgrade-to=<openshift_release_image> 주석을 호스트된 클러스터에 추가합니다.oc annotate hostedcluster \ -n <hosted_cluster_namespace> <hosted_cluster_name> \ "hypershift.openshift.io/force-upgrade-to=<openshift_release_image>" \ --overwrite
$ oc annotate hostedcluster \ -n <hosted_cluster_namespace> <hosted_cluster_name> \1 "hypershift.openshift.io/force-upgrade-to=<openshift_release_image>" \2 --overwriteCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- <
hosted_cluster_name> 및 <hosted_cluster_namespace>를 호스팅된 클러스터 이름 및 호스팅 클러스터 네임스페이스로 각각 바꿉니다. - 2
- <
openshift_release_image> 변수는 업그레이드할 새 OpenShift Container Platform 릴리스 이미지를 지정합니다(예:quay.io/openshift-release-dev/ocp-release:4.y.z-x86_64). <4.y.z>를 지원되는 OpenShift Container Platform 버전으로 교체합니다.
다음 명령을 입력하여 호스팅된 클러스터에서
spec.release.image값을 변경합니다.oc patch hostedcluster <hosted_cluster_name> -n <hosted_cluster_namespace> \ --type=merge \ -p '{"spec":{"release":{"image":"<openshift_release_image>"}}}'$ oc patch hostedcluster <hosted_cluster_name> -n <hosted_cluster_namespace> \ --type=merge \ -p '{"spec":{"release":{"image":"<openshift_release_image>"}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
새 버전이 롤아웃되었는지 확인하려면 다음 명령을 실행하여 호스팅된 클러스터에서
.status.conditions및.status.version값을 확인합니다.oc get -n <hosted_cluster_namespace> hostedcluster <hosted_cluster_name> \ -o yaml
$ oc get -n <hosted_cluster_namespace> hostedcluster <hosted_cluster_name> \ -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.8. 다중 클러스터 엔진 Operator 콘솔을 사용하여 호스트 클러스터 클러스터 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
다중 클러스터 엔진 Operator 콘솔을 사용하여 호스팅 클러스터를 업데이트할 수 있습니다.
호스팅 클러스터를 업데이트하기 전에 호스팅 클러스터의 사용 가능한 조건부 업데이트를 참조해야 합니다. 잘못된 릴리스 버전을 선택하면 호스팅된 클러스터가 중단될 수 있습니다.
프로세스
- 모든 클러스터를 선택합니다.
- 인프라 → 클러스터로 이동하여 관리되는 호스팅 클러스터를 확인합니다.
- 사용 가능한 업그레이드 링크를 클릭하여 컨트롤 플레인 및 노드 풀을 업데이트합니다.
9장. 호스트된 컨트롤 플레인의 고가용성 링크 복사링크가 클립보드에 복사되었습니다!
9.1. 호스트된 컨트롤 플레인의 고가용성 정보 링크 복사링크가 클립보드에 복사되었습니다!
다음 작업을 구현하여 호스트된 컨트롤 플레인의 HA(고가용성)를 유지 관리할 수 있습니다.
- 호스트 클러스터의 etcd 멤버를 복구합니다.
- 호스트 클러스터의 etcd를 백업하고 복원합니다.
- 호스트된 클러스터에 대한 재해 복구 프로세스를 수행합니다.
9.1.1. 실패한 관리 클러스터 구성 요소의 영향 링크 복사링크가 클립보드에 복사되었습니다!
관리 클러스터 구성 요소가 실패하면 워크로드에 영향을 미치지 않습니다. OpenShift Container Platform 관리 클러스터에서 컨트롤 플레인은 데이터 플레인과 분리되어 복원력을 제공합니다.
다음 표에서는 컨트롤 플레인 및 데이터 플레인에 실패한 관리 클러스터 구성 요소의 영향을 설명합니다. 그러나 표에는 관리 클러스터 구성 요소 실패의 모든 시나리오가 포함되어 있지 않습니다.
| 실패한 구성 요소의 이름 | 호스팅된 컨트롤 플레인 API 상태 | 호스트된 클러스터 데이터 플레인 상태 |
|---|---|---|
| 작업자 노드 | Available | Available |
| 가용성 영역 | Available | Available |
| 관리 클러스터 컨트롤 플레인 | Available | Available |
| 관리 클러스터 컨트롤 플레인 및 작업자 노드 | 사용할 수 없음 | Available |
9.2. 호스트된 컨트롤 플레인을 위한 비정상적인 etcd 클러스터 복구 링크 복사링크가 클립보드에 복사되었습니다!
고가용성 컨트롤 플레인에서 세 개의 etcd pod는 etcd 클러스터에서 상태 저장 세트의 일부로 실행됩니다. etcd 클러스터를 복구하려면 etcd 클러스터 상태를 확인하여 비정상 etcd pod를 확인합니다.
9.2.1. etcd 클러스터 상태 확인 링크 복사링크가 클립보드에 복사되었습니다!
etcd pod에 로그인하여 etcd 클러스터 상태의 상태를 확인할 수 있습니다.
프로세스
다음 명령을 입력하여 etcd pod에 로그인합니다.
oc rsh -n openshift-etcd -c etcd <etcd_pod_name>
$ oc rsh -n openshift-etcd -c etcd <etcd_pod_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 etcd 클러스터의 상태를 출력합니다.
etcdctl endpoint status -w table
sh-4.4# etcdctl endpoint status -w tableCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.2.2. 실패한 etcd pod 복구 링크 복사링크가 클립보드에 복사되었습니다!
3-노드 클러스터의 각 etcd pod에는 데이터를 저장할 자체 PVC(영구 볼륨 클레임)가 있습니다. 데이터가 손상되거나 누락되어 etcd pod가 실패할 수 있습니다. 실패한 etcd pod 및 해당 PVC를 복구할 수 있습니다.
프로세스
etcd pod가 실패했는지 확인하려면 다음 명령을 입력합니다.
oc get pods -l app=etcd -n openshift-etcd
$ oc get pods -l app=etcd -n openshift-etcdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME READY STATUS RESTARTS AGE etcd-0 2/2 Running 0 64m etcd-1 2/2 Running 0 45m etcd-2 1/2 CrashLoopBackOff 1 (5s ago) 64m
NAME READY STATUS RESTARTS AGE etcd-0 2/2 Running 0 64m etcd-1 2/2 Running 0 45m etcd-2 1/2 CrashLoopBackOff 1 (5s ago) 64mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 실패한 etcd pod는
CrashLoopBackOff또는Error상태가 될 수 있습니다.다음 명령을 입력하여 실패한 Pod 및 해당 PVC를 삭제합니다.
oc delete pods etcd-2 -n openshift-etcd
$ oc delete pods etcd-2 -n openshift-etcdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 입력하여 새 etcd pod가 실행 중인지 확인합니다.
oc get pods -l app=etcd -n openshift-etcd
$ oc get pods -l app=etcd -n openshift-etcdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME READY STATUS RESTARTS AGE etcd-0 2/2 Running 0 67m etcd-1 2/2 Running 0 48m etcd-2 2/2 Running 0 2m2s
NAME READY STATUS RESTARTS AGE etcd-0 2/2 Running 0 67m etcd-1 2/2 Running 0 48m etcd-2 2/2 Running 0 2m2sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
9.3. 온프레미스 환경에서 etcd 백업 및 복원 링크 복사링크가 클립보드에 복사되었습니다!
온프레미스 환경의 호스팅 클러스터에서 etcd를 백업하고 복원하여 오류를 수정할 수 있습니다.
9.3.1. 온프레미스 환경의 호스팅 클러스터에서 etcd 백업 및 복원 링크 복사링크가 클립보드에 복사되었습니다!
호스트 클러스터에서 etcd를 백업하고 복원하면 3개의 노드 클러스터의 etcd 멤버의 손상된 데이터 또는 누락된 데이터와 같은 오류를 해결할 수 있습니다. etcd 클러스터의 여러 멤버가 데이터 손실이 발생하거나 CrashLoopBackOff 상태인 경우 이 접근 방식은 etcd 쿼럼 손실을 방지하는 데 도움이 됩니다.
베어 메탈의 다른 관리 클러스터에서 etcd를 복원하는 것은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 다음 링크를 참조하십시오.
사전 요구 사항
-
oc및jq바이너리가 설치되어 있습니다.
절차
먼저 환경 변수를 설정합니다.
다음 명령을 입력하여 호스팅된 클러스터에 대한 환경 변수를 설정하여 필요에 따라 값을 바꿉니다.
CLUSTER_NAME=my-cluster
$ CLUSTER_NAME=my-clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow HOSTED_CLUSTER_NAMESPACE=clusters
$ HOSTED_CLUSTER_NAMESPACE=clustersCopy to Clipboard Copied! Toggle word wrap Toggle overflow CONTROL_PLANE_NAMESPACE="${HOSTED_CLUSTER_NAMESPACE}-${CLUSTER_NAME}"$ CONTROL_PLANE_NAMESPACE="${HOSTED_CLUSTER_NAMESPACE}-${CLUSTER_NAME}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 호스팅 클러스터의 조정을 일시 중지하여 필요에 따라 값을 교체합니다.
oc patch -n ${HOSTED_CLUSTER_NAMESPACE} hostedclusters/${CLUSTER_NAME} \ -p '{"spec":{"pausedUntil":"true"}}' --type=merge$ oc patch -n ${HOSTED_CLUSTER_NAMESPACE} hostedclusters/${CLUSTER_NAME} \ -p '{"spec":{"pausedUntil":"true"}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
다음으로 다음 방법 중 하나를 사용하여 etcd의 스냅샷을 만듭니다.
- 이전에 백업한 etcd 스냅샷을 사용합니다.
사용 가능한 etcd pod가 있는 경우 다음 단계를 완료하여 활성 etcd pod에서 스냅샷을 만듭니다.
다음 명령을 입력하여 etcd pod를 나열합니다.
oc get -n ${CONTROL_PLANE_NAMESPACE} pods -l app=etcd$ oc get -n ${CONTROL_PLANE_NAMESPACE} pods -l app=etcdCopy to Clipboard Copied! Toggle word wrap Toggle overflow Pod 데이터베이스의 스냅샷을 가져와서 다음 명령을 입력하여 시스템에 로컬로 저장합니다.
ETCD_POD=etcd-0
$ ETCD_POD=etcd-0Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 스냅샷이 성공했는지 확인합니다.
oc exec -n ${CONTROL_PLANE_NAMESPACE} -c etcd -t ${ETCD_POD} -- \ env ETCDCTL_API=3 /usr/bin/etcdctl -w table snapshot status \ /var/lib/snapshot.db$ oc exec -n ${CONTROL_PLANE_NAMESPACE} -c etcd -t ${ETCD_POD} -- \ env ETCDCTL_API=3 /usr/bin/etcdctl -w table snapshot status \ /var/lib/snapshot.dbCopy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 명령을 입력하여 스냅샷의 로컬 사본을 만듭니다.
oc cp -c etcd ${CONTROL_PLANE_NAMESPACE}/${ETCD_POD}:/var/lib/snapshot.db \ /tmp/etcd.snapshot.db$ oc cp -c etcd ${CONTROL_PLANE_NAMESPACE}/${ETCD_POD}:/var/lib/snapshot.db \ /tmp/etcd.snapshot.dbCopy to Clipboard Copied! Toggle word wrap Toggle overflow etcd 영구 스토리지에서 스냅샷 데이터베이스의 사본을 만듭니다.
다음 명령을 입력하여 etcd pod를 나열합니다.
oc get -n ${CONTROL_PLANE_NAMESPACE} pods -l app=etcd$ oc get -n ${CONTROL_PLANE_NAMESPACE} pods -l app=etcdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 실행 중인 Pod를 찾아
ETCD_POD: ETCD_POD=etcd-0의 값으로 설정한 다음 다음 명령을 입력하여 스냅샷 데이터베이스를 복사합니다.oc cp -c etcd \ ${CONTROL_PLANE_NAMESPACE}/${ETCD_POD}:/var/lib/data/member/snap/db \ /tmp/etcd.snapshot.db$ oc cp -c etcd \ ${CONTROL_PLANE_NAMESPACE}/${ETCD_POD}:/var/lib/data/member/snap/db \ /tmp/etcd.snapshot.dbCopy to Clipboard Copied! Toggle word wrap Toggle overflow
다음으로 다음 명령을 입력하여 etcd 상태 저장 세트를 축소합니다.
oc scale -n ${CONTROL_PLANE_NAMESPACE} statefulset/etcd --replicas=0$ oc scale -n ${CONTROL_PLANE_NAMESPACE} statefulset/etcd --replicas=0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 두 번째 및 세 번째 멤버의 볼륨을 삭제합니다.
oc delete -n ${CONTROL_PLANE_NAMESPACE} pvc/data-etcd-1 pvc/data-etcd-2$ oc delete -n ${CONTROL_PLANE_NAMESPACE} pvc/data-etcd-1 pvc/data-etcd-2Copy to Clipboard Copied! Toggle word wrap Toggle overflow pod를 생성하여 첫 번째 etcd 멤버의 데이터에 액세스합니다.
다음 명령을 입력하여 etcd 이미지를 가져옵니다.
ETCD_IMAGE=$(oc get -n ${CONTROL_PLANE_NAMESPACE} statefulset/etcd \ -o jsonpath='{ .spec.template.spec.containers[0].image }')$ ETCD_IMAGE=$(oc get -n ${CONTROL_PLANE_NAMESPACE} statefulset/etcd \ -o jsonpath='{ .spec.template.spec.containers[0].image }')Copy to Clipboard Copied! Toggle word wrap Toggle overflow etcd 데이터에 액세스할 수 있는 pod를 만듭니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow etcd-datapod의 상태를 확인하고 다음 명령을 입력하여 실행할 때까지 기다립니다.oc get -n ${CONTROL_PLANE_NAMESPACE} pods -l app=etcd-data$ oc get -n ${CONTROL_PLANE_NAMESPACE} pods -l app=etcd-dataCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여
etcd-datapod의 이름을 가져옵니다.DATA_POD=$(oc get -n ${CONTROL_PLANE_NAMESPACE} pods --no-headers \ -l app=etcd-data -o name | cut -d/ -f2)$ DATA_POD=$(oc get -n ${CONTROL_PLANE_NAMESPACE} pods --no-headers \ -l app=etcd-data -o name | cut -d/ -f2)Copy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 명령을 입력하여 etcd 스냅샷을 포드에 복사합니다.
oc cp /tmp/etcd.snapshot.db \ ${CONTROL_PLANE_NAMESPACE}/${DATA_POD}:/var/lib/restored.snap.db$ oc cp /tmp/etcd.snapshot.db \ ${CONTROL_PLANE_NAMESPACE}/${DATA_POD}:/var/lib/restored.snap.dbCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여
etcd-data포드에서 이전 데이터를 제거합니다.oc exec -n ${CONTROL_PLANE_NAMESPACE} ${DATA_POD} -- rm -rf /var/lib/data$ oc exec -n ${CONTROL_PLANE_NAMESPACE} ${DATA_POD} -- rm -rf /var/lib/dataCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc exec -n ${CONTROL_PLANE_NAMESPACE} ${DATA_POD} -- mkdir -p /var/lib/data$ oc exec -n ${CONTROL_PLANE_NAMESPACE} ${DATA_POD} -- mkdir -p /var/lib/dataCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 etcd 스냅샷을 복원합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 포드에서 임시 etcd 스냅샷을 제거하십시오.
oc exec -n ${CONTROL_PLANE_NAMESPACE} ${DATA_POD} -- \ rm /var/lib/restored.snap.db$ oc exec -n ${CONTROL_PLANE_NAMESPACE} ${DATA_POD} -- \ rm /var/lib/restored.snap.dbCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 데이터 액세스 배포를 삭제합니다.
oc delete -n ${CONTROL_PLANE_NAMESPACE} deployment/etcd-data$ oc delete -n ${CONTROL_PLANE_NAMESPACE} deployment/etcd-dataCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 etcd 클러스터를 확장합니다.
oc scale -n ${CONTROL_PLANE_NAMESPACE} statefulset/etcd --replicas=3$ oc scale -n ${CONTROL_PLANE_NAMESPACE} statefulset/etcd --replicas=3Copy to Clipboard Copied! Toggle word wrap Toggle overflow etcd 멤버 pod가 반환되고 다음 명령을 입력하여 사용 가능한 것으로 보고할 때까지 기다립니다.
oc get -n ${CONTROL_PLANE_NAMESPACE} pods -l app=etcd -w$ oc get -n ${CONTROL_PLANE_NAMESPACE} pods -l app=etcd -wCopy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 명령을 입력하여 호스팅 클러스터의 조정을 복원합니다.
oc patch -n ${HOSTED_CLUSTER_NAMESPACE} hostedclusters/${CLUSTER_NAME} \ -p '{"spec":{"pausedUntil":"null"}}' --type=merge$ oc patch -n ${HOSTED_CLUSTER_NAMESPACE} hostedclusters/${CLUSTER_NAME} \ -p '{"spec":{"pausedUntil":"null"}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 호스팅 클러스터를 수동으로 롤아웃합니다.
oc annotate hostedcluster -n \ <hosted_cluster_namespace> <hosted_cluster_name> \ hypershift.openshift.io/restart-date=$(date --iso-8601=seconds)
$ oc annotate hostedcluster -n \ <hosted_cluster_namespace> <hosted_cluster_name> \ hypershift.openshift.io/restart-date=$(date --iso-8601=seconds)Copy to Clipboard Copied! Toggle word wrap Toggle overflow Multus 승인 컨트롤러 및 네트워크 노드 ID Pod가 아직 시작되지 않습니다.
다음 명령을 입력하여 etcd의 두 번째 및 세 번째 멤버의 포드와 해당 PVC를 삭제합니다.
oc delete -n ${CONTROL_PLANE_NAMESPACE} pvc/data-etcd-1 pod/etcd-1 --wait=false$ oc delete -n ${CONTROL_PLANE_NAMESPACE} pvc/data-etcd-1 pod/etcd-1 --wait=falseCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete -n ${CONTROL_PLANE_NAMESPACE} pvc/data-etcd-2 pod/etcd-2 --wait=false$ oc delete -n ${CONTROL_PLANE_NAMESPACE} pvc/data-etcd-2 pod/etcd-2 --wait=falseCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 호스팅 클러스터를 수동으로 다시 롤아웃합니다.
oc annotate hostedcluster -n \ <hosted_cluster_namespace> <hosted_cluster_name> \ hypershift.openshift.io/restart-date=$(date --iso-8601=seconds) \ --overwrite
$ oc annotate hostedcluster -n \ <hosted_cluster_namespace> <hosted_cluster_name> \ hypershift.openshift.io/restart-date=$(date --iso-8601=seconds) \ --overwriteCopy to Clipboard Copied! Toggle word wrap Toggle overflow 몇 분 후에 컨트롤 플레인 Pod가 실행되기 시작합니다.
9.4. AWS에서 etcd 백업 및 복원 링크 복사링크가 클립보드에 복사되었습니다!
AWS(Amazon Web Services)의 호스팅 클러스터에서 etcd를 백업하고 복원하여 오류를 수정할 수 있습니다.
9.4.1. 호스트 클러스터의 etcd 스냅샷 생성 링크 복사링크가 클립보드에 복사되었습니다!
호스트 클러스터의 etcd를 백업하려면 etcd의 스냅샷을 작성해야 합니다. 나중에 스냅샷을 사용하여 etcd를 복원할 수 있습니다.
이 절차에는 API 다운타임이 필요합니다.
프로세스
다음 명령을 입력하여 호스트 클러스터의 조정을 일시 중지합니다.
oc patch -n clusters hostedclusters/<hosted_cluster_name> \ -p '{"spec":{"pausedUntil":"true"}}' --type=merge$ oc patch -n clusters hostedclusters/<hosted_cluster_name> \ -p '{"spec":{"pausedUntil":"true"}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 모든 etcd-writer 배포를 중지합니다.
oc scale deployment -n <hosted_cluster_namespace> --replicas=0 \ kube-apiserver openshift-apiserver openshift-oauth-apiserver
$ oc scale deployment -n <hosted_cluster_namespace> --replicas=0 \ kube-apiserver openshift-apiserver openshift-oauth-apiserverCopy to Clipboard Copied! Toggle word wrap Toggle overflow etcd 스냅샷을 만들려면 다음 명령을 입력하여 각 etcd 컨테이너에서
exec명령을 사용하십시오.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 스냅샷 상태를 확인하려면 다음 명령을 실행하여 각 etcd 컨테이너에서
exec명령을 사용하십시오.oc exec -it <etcd_pod_name> -n <hosted_cluster_namespace> -- \ env ETCDCTL_API=3 /usr/bin/etcdctl -w table snapshot status \ /var/lib/data/snapshot.db
$ oc exec -it <etcd_pod_name> -n <hosted_cluster_namespace> -- \ env ETCDCTL_API=3 /usr/bin/etcdctl -w table snapshot status \ /var/lib/data/snapshot.dbCopy to Clipboard Copied! Toggle word wrap Toggle overflow 스냅샷 데이터를 S3 버킷과 같이 나중에 검색할 수 있는 위치에 복사합니다. 다음 예제를 참조하십시오.
참고다음 예제에서는 서명 버전 2를 사용합니다. 서명 버전 4를 지원하는 리전에 있는 경우
us-east-2리전과 같이 서명 버전 4를 사용합니다. 그렇지 않으면 스냅샷을 S3 버킷에 복사할 때 업로드가 실패합니다.예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 나중에 새 클러스터에서 스냅샷을 복원하려면 호스팅된 클러스터가 참조하는 암호화 시크릿을 저장합니다.
다음 명령을 입력하여 보안 암호화 키를 가져옵니다.
oc get hostedcluster <hosted_cluster_name> \ -o=jsonpath='{.spec.secretEncryption.aescbc}' {"activeKey":{"name":"<hosted_cluster_name>-etcd-encryption-key"}}$ oc get hostedcluster <hosted_cluster_name> \ -o=jsonpath='{.spec.secretEncryption.aescbc}' {"activeKey":{"name":"<hosted_cluster_name>-etcd-encryption-key"}}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 보안 암호화 키를 저장합니다.
oc get secret <hosted_cluster_name>-etcd-encryption-key \ -o=jsonpath='{.data.key}'$ oc get secret <hosted_cluster_name>-etcd-encryption-key \ -o=jsonpath='{.data.key}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 새 클러스터에서 스냅샷을 복원할 때 이 키의 암호를 해독할 수 있습니다.
다음 명령을 입력하여 모든 etcd-writer 배포를 다시 시작합니다.
oc scale deployment -n <control_plane_namespace> --replicas=3 \ kube-apiserver openshift-apiserver openshift-oauth-apiserver
$ oc scale deployment -n <control_plane_namespace> --replicas=3 \ kube-apiserver openshift-apiserver openshift-oauth-apiserverCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 호스팅 클러스터의 조정을 다시 시작합니다.
oc patch -n <hosted_cluster_namespace> \ -p '[\{"op": "remove", "path": "/spec/pausedUntil"}]' --type=json$ oc patch -n <hosted_cluster_namespace> \ -p '[\{"op": "remove", "path": "/spec/pausedUntil"}]' --type=jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 단계
etcd 스냅샷을 복원하십시오.
9.4.2. 호스트 클러스터에서 etcd 스냅샷 복원 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 클러스터에서 etcd 스냅샷이 있는 경우 복원할 수 있습니다. 현재 클러스터 생성 중에만 etcd 스냅샷을 복원할 수 있습니다.
etcd 스냅샷을 복원하려면 create cluster --render 명령에서 출력을 수정하고 HostedCluster 사양의 etcd 섹션에 restoreSnapshotURL 값을 정의합니다.
hcp create 명령의 --render 플래그는 시크릿을 렌더링하지 않습니다. 보안을 렌더링하려면 hcp create 명령에서 --render 및 --render-sensitive 플래그를 모두 사용해야 합니다.
사전 요구 사항
호스팅된 클러스터에서 etcd 스냅샷을 작성했습니다.
절차
awsCLI(명령줄 인터페이스)에서 인증 정보를 etcd 배포에 전달하지 않고 S3에서 etcd 스냅샷을 다운로드할 수 있도록 사전 서명된 URL을 생성합니다.ETCD_SNAPSHOT=${ETCD_SNAPSHOT:-"s3://${BUCKET_NAME}/${CLUSTER_NAME}-snapshot.db"} ETCD_SNAPSHOT_URL=$(aws s3 presign ${ETCD_SNAPSHOT})ETCD_SNAPSHOT=${ETCD_SNAPSHOT:-"s3://${BUCKET_NAME}/${CLUSTER_NAME}-snapshot.db"} ETCD_SNAPSHOT_URL=$(aws s3 presign ${ETCD_SNAPSHOT})Copy to Clipboard Copied! Toggle word wrap Toggle overflow URL을 참조하도록
HostedCluster사양을 수정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
spec.secretEncryption.aescbc값에서 참조한 보안에 이전 단계에서 저장한 것과 동일한 AES 키가 포함되어 있는지 확인합니다.
9.5. OpenShift Virtualization에서 호스트 클러스터 백업 및 복원 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Virtualization에서 호스트 클러스터를 백업 및 복원하여 오류를 수정할 수 있습니다.
9.5.1. OpenShift Virtualization에서 호스트된 클러스터 백업 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Virtualization에서 호스팅된 클러스터를 백업하면 호스팅된 클러스터가 계속 실행될 수 있습니다. 백업에는 호스팅된 컨트롤 플레인 구성 요소와 호스팅된 클러스터의 etcd가 포함되어 있습니다.
호스팅된 클러스터가 외부 인프라에서 컴퓨팅 노드를 실행하지 않는 경우 KubeVirt CSI에서 프로비저닝한 PVC(영구 볼륨 클레임)에 저장된 호스팅된 클러스터 워크로드 데이터도 백업됩니다. 백업에는 컴퓨팅 노드로 사용되는 KubeVirt VM(가상 머신)이 포함되어 있지 않습니다. 복원 프로세스가 완료되면 해당 VM이 자동으로 다시 생성됩니다.
프로세스
다음 예와 유사한 YAML 파일을 생성하여 Velero 백업 리소스를 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 이 필드는 백업할 오브젝트에서 네임스페이스를 선택합니다. 호스팅 클러스터와 호스팅된 컨트롤 플레인의 네임스페이스를 포함합니다. 이 예에서
클러스터는 호스팅된 클러스터의 네임스페이스이며, 클러스터 호스팅은호스팅된컨트롤 플레인의 네임스페이스입니다. 기본적으로HostedControlPlane네임스페이스는clusters-<hosted_cluster_name>입니다. - 2
- 호스팅된 클러스터 노드로 사용되는 VM의 부팅 이미지는 대규모 PVC에 저장됩니다. 백업 시간과 스토리지 크기를 줄이기 위해 이 라벨 선택기를 추가하여 해당 PVC를 백업에서 필터링할 수 있습니다.
- 3
- 이 필드와
datamover필드를 사용하면 CSIVolumeSnapshots를 원격 클라우드 스토리지에 자동으로 업로드할 수 있습니다. - 4
- 이 필드 및
스냅샷 CryostatData필드를 사용하면 CSIVolumeSnapshots를 원격 클라우드 스토리지에 자동으로 업로드할 수 있습니다. - 5
- 이 필드는 기본적으로 모든 볼륨에 Pod 볼륨 파일 시스템 백업이 사용되는지 여부를 나타냅니다. 원하는 PVC를 백업하려면 이 값을
false로 설정합니다.
다음 명령을 입력하여 YAML 파일에 변경 사항을 적용합니다.
oc apply -f <backup_file_name>.yaml
$ oc apply -f <backup_file_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow &
lt;backup_file_name>을 파일 이름으로 바꿉니다.backup 오브젝트 상태 및 Velero 로그에서 백업 프로세스를 모니터링합니다.
백업 오브젝트 상태를 모니터링하려면 다음 명령을 입력합니다.
watch "oc get backups.velero.io -n openshift-adp <backup_file_name> -o jsonpath='{.status}' | jq"$ watch "oc get backups.velero.io -n openshift-adp <backup_file_name> -o jsonpath='{.status}' | jq"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Velero 로그를 모니터링하려면 다음 명령을 입력합니다.
oc logs -n openshift-adp -ldeploy=velero -f
$ oc logs -n openshift-adp -ldeploy=velero -fCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
-
status.phase필드가 완료되면 백업 프로세스가완료된것으로 간주됩니다.
9.5.2. OpenShift Virtualization에서 호스트된 클러스터 복원 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Virtualization에서 호스트된 클러스터를 백업한 후 백업을 복원할 수 있습니다.
복원 프로세스는 백업을 생성한 동일한 관리 클러스터에서만 완료할 수 있습니다.
프로세스
-
HostedControlPlane네임스페이스에서 Pod 또는 PVC(영구 볼륨 클레임)가 실행되고 있지 않은지 확인합니다. 관리 클러스터에서 다음 오브젝트를 삭제합니다.
-
HostedCluster -
NodePool - PVCs
-
다음 예와 유사한 복원 매니페스트 YAML 파일을 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 YAML 파일에 변경 사항을 적용합니다.
oc apply -f <restore_resource_file_name>.yaml
$ oc apply -f <restore_resource_file_name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow &
lt;restore_resource_file_name>을 파일 이름으로 바꿉니다.복원 상태 필드 및 Velero 로그를 확인하여 복원 프로세스를 모니터링합니다.
복원 상태 필드를 확인하려면 다음 명령을 입력합니다.
watch "oc get restores.velero.io -n openshift-adp <backup_file_name> -o jsonpath='{.status}' | jq"$ watch "oc get restores.velero.io -n openshift-adp <backup_file_name> -o jsonpath='{.status}' | jq"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Velero 로그를 확인하려면 다음 명령을 입력합니다.
oc logs -n openshift-adp -ldeploy=velero -f
$ oc logs -n openshift-adp -ldeploy=velero -fCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
-
status.phase필드가 완료되면 복원 프로세스가완료된것으로 간주됩니다.
다음 단계
- 잠시 후 KubeVirt VM이 생성되고 호스팅된 클러스터에 컴퓨팅 노드로 참여합니다. 호스팅된 클러스터 워크로드가 예상대로 다시 실행되고 있는지 확인합니다.
9.6. AWS에서 호스트된 클러스터에 대한 재해 복구 링크 복사링크가 클립보드에 복사되었습니다!
호스트 클러스터를 AWS(Amazon Web Services) 내의 동일한 리전으로 복구할 수 있습니다. 예를 들어 관리 클러스터 업그레이드에 실패하고 호스트 클러스터가 읽기 전용 상태인 경우 재해 복구가 필요합니다.
재해 복구 프로세스에는 다음 단계가 포함됩니다.
- 소스 관리 클러스터에서 호스트된 클러스터 백업
- 대상 관리 클러스터에서 호스팅 클러스터 복원
- 소스 관리 클러스터에서 호스팅 클러스터 삭제
프로세스 중에 워크로드가 계속 실행됩니다. 기간 동안 클러스터 API를 사용할 수 없지만, 이는 작업자 노드에서 실행 중인 서비스에는 영향을 미치지 않습니다.
API 서버 URL을 유지하려면 소스 관리 클러스터와 대상 관리 클러스터에 모두 --external-dns 플래그가 있어야 합니다. 이렇게 하면 서버 URL이 https://api-sample-hosted.sample-hosted.aws.openshift.com 로 끝납니다. 다음 예제를 참조하십시오.
예: 외부 DNS 플래그
--external-dns-provider=aws \ --external-dns-credentials=<path_to_aws_credentials_file> \ --external-dns-domain-filter=<basedomain>
--external-dns-provider=aws \
--external-dns-credentials=<path_to_aws_credentials_file> \
--external-dns-domain-filter=<basedomain>
API 서버 URL을 유지하기 위해 --external-dns 플래그를 포함하지 않으면 호스팅된 클러스터를 마이그레이션할 수 없습니다.
9.6.1. 백업 및 복원 프로세스 개요 링크 복사링크가 클립보드에 복사되었습니다!
백업 및 복원 프로세스는 다음과 같이 작동합니다.
관리 클러스터 1에서 소스 관리 클러스터로 간주할 수 있는 컨트롤 플레인 및 작업자는 외부 DNS API를 사용하여 상호 작용합니다. 외부 DNS API에 액세스할 수 있으며 로드 밸런서는 관리 클러스터 간에 위치합니다.
etcd, 컨트롤 플레인 및 작업자 노드가 포함된 호스팅 클러스터의 스냅샷을 생성합니다. 이 프로세스 중에 작업자 노드는 액세스할 수 없는 경우에도 외부 DNS API에 계속 액세스하려고 합니다. 워크로드가 실행 중이고 컨트롤 플레인은 로컬 매니페스트 파일에 저장되고 etcd는 S3 버킷으로 백업됩니다. 데이터 플레인이 활성 상태이고 컨트롤 플레인이 일시 중지되었습니다.
대상 관리 클러스터 2로 간주할 수 있는 관리 클러스터 2에서는 S3 버킷에서 etcd를 복원하고 로컬 매니페스트 파일에서 컨트롤 플레인을 복원합니다. 이 프로세스 중에 외부 DNS API가 중지되고 호스팅된 클러스터 API에 액세스할 수 없게 되고 API를 사용하는 모든 작업자는 매니페스트 파일을 업데이트할 수 없지만 워크로드는 여전히 실행 중입니다.
외부 DNS API에 다시 액세스할 수 있으며 작업자 노드는 이를 사용하여 관리 클러스터 2로 이동합니다. 외부 DNS API는 컨트롤 플레인을 가리키는 로드 밸런서에 액세스할 수 있습니다.
관리 클러스터 2에서 컨트롤 플레인 및 작업자 노드는 외부 DNS API를 사용하여 상호 작용합니다. etcd의 S3 백업을 제외하고 관리 클러스터 1에서 리소스가 삭제됩니다. 관리 클러스터 1에서 호스트 클러스터를 다시 설정하려고 하면 작동하지 않습니다.
9.6.2. AWS에서 호스팅 클러스터 백업 링크 복사링크가 클립보드에 복사되었습니다!
대상 관리 클러스터에서 호스팅된 클러스터를 복구하려면 먼저 모든 관련 데이터를 백업해야 합니다.
프로세스
다음 명령을 입력하여 소스 관리 클러스터를 선언할 구성 맵 파일을 생성합니다.
oc create configmap mgmt-parent-cluster -n default \ --from-literal=from=${MGMT_CLUSTER_NAME}$ oc create configmap mgmt-parent-cluster -n default \ --from-literal=from=${MGMT_CLUSTER_NAME}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 호스팅 클러스터 및 노드 풀에서 조정을 종료합니다.
PAUSED_UNTIL="true"
$ PAUSED_UNTIL="true"Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc patch -n ${HC_CLUSTER_NS} hostedclusters/${HC_CLUSTER_NAME} \ -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge$ oc patch -n ${HC_CLUSTER_NS} hostedclusters/${HC_CLUSTER_NAME} \ -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc patch -n ${HC_CLUSTER_NS} nodepools/${NODEPOOLS} \ -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=merge$ oc patch -n ${HC_CLUSTER_NS} nodepools/${NODEPOOLS} \ -p '{"spec":{"pausedUntil":"'${PAUSED_UNTIL}'"}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 \ kube-apiserver openshift-apiserver openshift-oauth-apiserver control-plane-operator$ oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 \ kube-apiserver openshift-apiserver openshift-oauth-apiserver control-plane-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 bash 스크립트를 실행하여 etcd를 백업하고 S3 버킷에 데이터를 업로드합니다.
작은 정보이 스크립트를 함수로 래핑하고 기본 함수에서 호출합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow etcd 백업에 대한 자세한 내용은 "호스트 클러스터에서 etcd 백업 및 복원"을 참조하십시오.
다음 명령을 입력하여 Kubernetes 및 OpenShift Container Platform 오브젝트를 백업합니다. 다음 오브젝트를 백업해야 합니다.
-
HostedCluster 네임스페이스의
HostedCluster및NodePool오브젝트 -
HostedCluster 네임스페이스의
HostedCluster시크릿 -
HostedControl Plane 네임 스페이스의
HostedControlPlane -
호스팅 컨트롤 플레인 네임스페이스의
Cluster -
호스팅된 컨트롤 플레인 네임스페이스에서
AWSCluster,AWSMachineTemplate,AWSMachine -
Hosted Control Plane 네임스페이스에서
MachineDeployments,MachineSets,Machines 호스팅된 컨트롤 플레인 네임스페이스의
ControlPlane시크릿다음 명령을 입력합니다.
mkdir -p ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS} \ ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}$ mkdir -p ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS} \ ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}Copy to Clipboard Copied! Toggle word wrap Toggle overflow chmod 700 ${BACKUP_DIR}/namespaces/$ chmod 700 ${BACKUP_DIR}/namespaces/Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여
HostedCluster네임스페이스에서HostedCluster오브젝트를 백업합니다.echo "Backing Up HostedCluster Objects:"
$ echo "Backing Up HostedCluster Objects:"Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get hc ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS} -o yaml > \ ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}.yaml$ oc get hc ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS} -o yaml > \ ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow echo "--> HostedCluster"
$ echo "--> HostedCluster"Copy to Clipboard Copied! Toggle word wrap Toggle overflow sed -i '' -e '/^status:$/,$d' \ ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}.yaml$ sed -i '' -e '/^status:$/,$d' \ ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/hc-${HC_CLUSTER_NAME}.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여
HostedCluster네임스페이스에서NodePool오브젝트를 백업합니다.oc get np ${NODEPOOLS} -n ${HC_CLUSTER_NS} -o yaml > \ ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-${NODEPOOLS}.yaml$ oc get np ${NODEPOOLS} -n ${HC_CLUSTER_NS} -o yaml > \ ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-${NODEPOOLS}.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow echo "--> NodePool"
$ echo "--> NodePool"Copy to Clipboard Copied! Toggle word wrap Toggle overflow sed -i '' -e '/^status:$/,$ d' \ ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-${NODEPOOLS}.yaml$ sed -i '' -e '/^status:$/,$ d' \ ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-${NODEPOOLS}.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 쉘 스크립트를 실행하여
HostedCluster네임스페이스에 보안을 백업합니다.echo "--> HostedCluster Secrets:" for s in $(oc get secret -n ${HC_CLUSTER_NS} | grep "^${HC_CLUSTER_NAME}" | awk '{print $1}'); do oc get secret -n ${HC_CLUSTER_NS} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/secret-${s}.yaml done$ echo "--> HostedCluster Secrets:" for s in $(oc get secret -n ${HC_CLUSTER_NS} | grep "^${HC_CLUSTER_NAME}" | awk '{print $1}'); do oc get secret -n ${HC_CLUSTER_NS} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/secret-${s}.yaml doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 쉘 스크립트를 실행하여
HostedCluster컨트롤 플레인 네임스페이스에서 보안을 백업합니다.echo "--> HostedCluster ControlPlane Secrets:" for s in $(oc get secret -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} | egrep -v "docker|service-account-token|oauth-openshift|NAME|token-${HC_CLUSTER_NAME}" | awk '{print $1}'); do oc get secret -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/secret-${s}.yaml done$ echo "--> HostedCluster ControlPlane Secrets:" for s in $(oc get secret -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} | egrep -v "docker|service-account-token|oauth-openshift|NAME|token-${HC_CLUSTER_NAME}" | awk '{print $1}'); do oc get secret -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/secret-${s}.yaml doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 호스팅된 컨트롤 플레인을 백업합니다.
echo "--> HostedControlPlane:"
$ echo "--> HostedControlPlane:"Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get hcp ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > \ ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/hcp-${HC_CLUSTER_NAME}.yaml$ oc get hcp ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > \ ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/hcp-${HC_CLUSTER_NAME}.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 클러스터를 백업합니다.
echo "--> Cluster:"
$ echo "--> Cluster:"Copy to Clipboard Copied! Toggle word wrap Toggle overflow CL_NAME=$(oc get hcp ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} \ -o jsonpath={.metadata.labels.\*} | grep ${HC_CLUSTER_NAME})$ CL_NAME=$(oc get hcp ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} \ -o jsonpath={.metadata.labels.\*} | grep ${HC_CLUSTER_NAME})Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get cluster ${CL_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > \ ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/cl-${HC_CLUSTER_NAME}.yaml$ oc get cluster ${CL_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > \ ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/cl-${HC_CLUSTER_NAME}.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 AWS 클러스터를 백업합니다.
echo "--> AWS Cluster:"
$ echo "--> AWS Cluster:"Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get awscluster ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > \ ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awscl-${HC_CLUSTER_NAME}.yaml$ oc get awscluster ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > \ ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awscl-${HC_CLUSTER_NAME}.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 AWS
MachineTemplate오브젝트를 백업합니다.echo "--> AWS Machine Template:"
$ echo "--> AWS Machine Template:"Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get awsmachinetemplate ${NODEPOOLS} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > \ ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsmt-${HC_CLUSTER_NAME}.yaml$ oc get awsmachinetemplate ${NODEPOOLS} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o yaml > \ ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsmt-${HC_CLUSTER_NAME}.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 쉘 스크립트를 실행하여 AWS
Machines오브젝트를 백업합니다.echo "--> AWS Machine:"
$ echo "--> AWS Machine:"Copy to Clipboard Copied! Toggle word wrap Toggle overflow CL_NAME=$(oc get hcp ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o jsonpath={.metadata.labels.\*} | grep ${HC_CLUSTER_NAME}) for s in $(oc get awsmachines -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --no-headers | grep ${CL_NAME} | cut -f1 -d\ ); do oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} awsmachines $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsm-${s}.yaml done$ CL_NAME=$(oc get hcp ${HC_CLUSTER_NAME} -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o jsonpath={.metadata.labels.\*} | grep ${HC_CLUSTER_NAME}) for s in $(oc get awsmachines -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --no-headers | grep ${CL_NAME} | cut -f1 -d\ ); do oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} awsmachines $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsm-${s}.yaml doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 쉘 스크립트를 실행하여
MachineDeployments오브젝트를 백업합니다.echo "--> HostedCluster MachineDeployments:" for s in $(oc get machinedeployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do mdp_name=$(echo ${s} | cut -f 2 -d /) oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machinedeployment-${mdp_name}.yaml done$ echo "--> HostedCluster MachineDeployments:" for s in $(oc get machinedeployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do mdp_name=$(echo ${s} | cut -f 2 -d /) oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machinedeployment-${mdp_name}.yaml doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 쉘 스크립트를 실행하여
MachineSets오브젝트를 백업합니다.echo "--> HostedCluster MachineSets:" for s in $(oc get machineset -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do ms_name=$(echo ${s} | cut -f 2 -d /) oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machineset-${ms_name}.yaml done$ echo "--> HostedCluster MachineSets:" for s in $(oc get machineset -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do ms_name=$(echo ${s} | cut -f 2 -d /) oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machineset-${ms_name}.yaml doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 쉘 스크립트를 실행하여 호스팅된 컨트롤 플레인 네임스페이스에서
Machines오브젝트를 백업합니다.echo "--> HostedCluster Machine:" for s in $(oc get machine -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do m_name=$(echo ${s} | cut -f 2 -d /) oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machine-${m_name}.yaml done$ echo "--> HostedCluster Machine:" for s in $(oc get machine -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do m_name=$(echo ${s} | cut -f 2 -d /) oc get -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} $s -o yaml > ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machine-${m_name}.yaml doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
HostedCluster 네임스페이스의
다음 명령을 입력하여
ControlPlane경로를 정리합니다.oc delete routes -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all$ oc delete routes -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow 해당 명령을 입력하면 ExternalDNS Operator가 Route53 항목을 삭제할 수 있습니다.
다음 스크립트를 실행하여 Route53 항목이 정리되었는지 확인합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
모든 OpenShift Container Platform 오브젝트 및 S3 버킷을 확인하여 모든 것이 예상대로 표시되는지 확인합니다.
다음 단계
호스팅된 클러스터를 복원합니다.
9.6.3. 호스팅된 클러스터 복원 링크 복사링크가 클립보드에 복사되었습니다!
백업한 모든 오브젝트를 수집하고 대상 관리 클러스터에 복원합니다.
사전 요구 사항
소스 관리 클러스터에서 데이터를 백업합니다.
대상 관리 클러스터의 kubeconfig 파일이 KUBECONFIG 변수에 설정되거나 스크립트를 사용하는 경우 MGMT2_KUBECONFIG 변수에 배치되었는지 확인합니다. export KUBECONFIG=<Kubeconfig FilePath>를 사용하거나 스크립트를 사용하는 경우 export KUBECONFIG=$MGMT2_KUBECONFIG} 를 사용합니다.
절차
다음 명령을 입력하여 복원 중인 클러스터의 네임스페이스가 새 관리 클러스터에 포함되어 있지 않은지 확인합니다.
export KUBECONFIG=${MGMT2_KUBECONFIG}$ export KUBECONFIG=${MGMT2_KUBECONFIG}Copy to Clipboard Copied! Toggle word wrap Toggle overflow BACKUP_DIR=${HC_CLUSTER_DIR}/backup$ BACKUP_DIR=${HC_CLUSTER_DIR}/backupCopy to Clipboard Copied! Toggle word wrap Toggle overflow 대상 관리 클러스터의 네임스페이스 삭제
oc delete ns ${HC_CLUSTER_NS} || true$ oc delete ns ${HC_CLUSTER_NS} || trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete ns ${HC_CLUSTER_NS}-{HC_CLUSTER_NAME} || true$ oc delete ns ${HC_CLUSTER_NS}-{HC_CLUSTER_NAME} || trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 삭제된 네임스페이스를 다시 생성합니다.
네임스페이스 생성 명령
oc new-project ${HC_CLUSTER_NS}$ oc new-project ${HC_CLUSTER_NS}Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc new-project ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}$ oc new-project ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 HC 네임스페이스에 보안을 복원합니다.
oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/secret-*$ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/secret-*Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여
HostedCluster컨트롤 플레인 네임스페이스에서 오브젝트를 복원합니다.시크릿 명령 복원
oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/secret-*$ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/secret-*Copy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터 복원 명령
oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/hcp-*$ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/hcp-*Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/cl-*$ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/cl-*Copy to Clipboard Copied! Toggle word wrap Toggle overflow 노드와 노드 풀을 복구하여 AWS 인스턴스를 재사용하는 경우 다음 명령을 입력하여 HC 컨트롤 플레인 네임스페이스에서 오브젝트를 복원합니다.
AWS 명령
oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awscl-*$ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awscl-*Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsmt-*$ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsmt-*Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsm-*$ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/awsm-*Copy to Clipboard Copied! Toggle word wrap Toggle overflow 머신 명령
oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machinedeployment-*$ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machinedeployment-*Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machineset-*$ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machineset-*Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machine-*$ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}/machine-*Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 bash 스크립트를 실행하여 etcd 데이터 및 호스팅 클러스터를 복원합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 노드와 노드 풀을 복구하여 AWS 인스턴스를 재사용하는 경우 다음 명령을 입력하여 노드 풀을 복원합니다.
oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-*$ oc apply -f ${BACKUP_DIR}/namespaces/${HC_CLUSTER_NS}/np-*Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
노드가 완전히 복원되었는지 확인하려면 다음 기능을 사용합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 단계
클러스터를 종료하고 삭제합니다.
9.6.4. 소스 관리 클러스터에서 호스트된 클러스터 삭제 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 클러스터를 백업하고 대상 관리 클러스터로 복원한 후 소스 관리 클러스터에서 호스팅된 클러스터를 종료하고 삭제합니다.
사전 요구 사항
데이터를 백업하고 소스 관리 클러스터에 복원했습니다.
대상 관리 클러스터의 kubeconfig 파일이 KUBECONFIG 변수에 설정되거나 스크립트를 사용하는 경우 MGMT_KUBECONFIG 변수에 배치되었는지 확인합니다. export KUBECONFIG=<Kubeconfig FilePath>를 사용하거나 스크립트를 사용하는 경우 export KUBECONFIG=$MGMT_KUBECONFIG} 를 사용합니다.
절차
다음 명령을 입력하여
deployment및statefulset오브젝트를 확장합니다.중요spec.persistentVolumeClaimRetentionPolicy.whenScaled필드의 값이Delete로 설정된 경우 데이터 손실이 발생할 수 있으므로 상태 저장 세트를 스케일링하지 마십시오.이 문제를 해결하려면
spec.persistentVolumeClaimRetentionPolicy.whenScaled필드의 값을Retain으로 업데이트합니다. 상태 저장 세트를 조정하는 컨트롤러가 없는지 확인하고 값을Delete로 다시 반환하여 데이터가 손실될 수 있습니다.export KUBECONFIG=${MGMT_KUBECONFIG}$ export KUBECONFIG=${MGMT_KUBECONFIG}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 배포 명령 축소
oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 --all$ oc scale deployment -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc scale statefulset.apps -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 --all$ oc scale statefulset.apps -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --replicas=0 --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow sleep 15
$ sleep 15Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여
NodePool오브젝트를 삭제합니다.NODEPOOLS=$(oc get nodepools -n ${HC_CLUSTER_NS} -o=jsonpath='{.items[?(@.spec.clusterName=="'${HC_CLUSTER_NAME}'")].metadata.name}') if [[ ! -z "${NODEPOOLS}" ]];then oc patch -n "${HC_CLUSTER_NS}" nodepool ${NODEPOOLS} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' oc delete np -n ${HC_CLUSTER_NS} ${NODEPOOLS} fiNODEPOOLS=$(oc get nodepools -n ${HC_CLUSTER_NS} -o=jsonpath='{.items[?(@.spec.clusterName=="'${HC_CLUSTER_NAME}'")].metadata.name}') if [[ ! -z "${NODEPOOLS}" ]];then oc patch -n "${HC_CLUSTER_NS}" nodepool ${NODEPOOLS} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' oc delete np -n ${HC_CLUSTER_NS} ${NODEPOOLS} fiCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여
machine및machineset오브젝트를 삭제합니다.# Machines for m in $(oc get machines -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' || true oc delete -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} || true done# Machines for m in $(oc get machines -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name); do oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' || true oc delete -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} || true doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete machineset -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all || true$ oc delete machineset -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all || trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 클러스터 오브젝트를 삭제합니다.
C_NAME=$(oc get cluster -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name)$ C_NAME=$(oc get cluster -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name)Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${C_NAME} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]'$ oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${C_NAME} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete cluster.cluster.x-k8s.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all$ oc delete cluster.cluster.x-k8s.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이러한 명령을 입력하여 AWS 머신(Kubernetes 오브젝트)을 삭제합니다. 실제 AWS 머신 삭제에 대해 우려하지 마십시오. 클라우드 인스턴스는 영향을 받지 않습니다.
for m in $(oc get awsmachine.infrastructure.cluster.x-k8s.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name) do oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' || true oc delete -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} || true donefor m in $(oc get awsmachine.infrastructure.cluster.x-k8s.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} -o name) do oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]' || true oc delete -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} ${m} || true doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여
HostedControlPlane및ControlPlaneHC 네임스페이스 오브젝트를 삭제합니다.HCP 및 ControlPlane HC NS 명령 삭제
oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} hostedcontrolplane.hypershift.openshift.io ${HC_CLUSTER_NAME} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]'$ oc patch -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} hostedcontrolplane.hypershift.openshift.io ${HC_CLUSTER_NAME} --type=json --patch='[ { "op":"remove", "path": "/metadata/finalizers" }]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete hostedcontrolplane.hypershift.openshift.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --all$ oc delete hostedcontrolplane.hypershift.openshift.io -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete ns ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} || true$ oc delete ns ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME} || trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여
HostedCluster및 HC 네임스페이스 오브젝트를 삭제합니다.HC 및 HC 네임스페이스 명령 삭제
oc -n ${HC_CLUSTER_NS} patch hostedclusters ${HC_CLUSTER_NAME} -p '{"metadata":{"finalizers":null}}' --type merge || true$ oc -n ${HC_CLUSTER_NS} patch hostedclusters ${HC_CLUSTER_NAME} -p '{"metadata":{"finalizers":null}}' --type merge || trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete hc -n ${HC_CLUSTER_NS} ${HC_CLUSTER_NAME} || true$ oc delete hc -n ${HC_CLUSTER_NS} ${HC_CLUSTER_NAME} || trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete ns ${HC_CLUSTER_NS} || true$ oc delete ns ${HC_CLUSTER_NS} || trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
모든 것이 작동하는지 확인하려면 다음 명령을 입력합니다.
검증 명령
export KUBECONFIG=${MGMT2_KUBECONFIG}$ export KUBECONFIG=${MGMT2_KUBECONFIG}Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get hc -n ${HC_CLUSTER_NS}$ oc get hc -n ${HC_CLUSTER_NS}Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get np -n ${HC_CLUSTER_NS}$ oc get np -n ${HC_CLUSTER_NS}Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get pod -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}$ oc get pod -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get machines -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}$ oc get machines -n ${HC_CLUSTER_NS}-${HC_CLUSTER_NAME}Copy to Clipboard Copied! Toggle word wrap Toggle overflow HostedCluster 내부 명령
export KUBECONFIG=${HC_KUBECONFIG}$ export KUBECONFIG=${HC_KUBECONFIG}Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get clusterversion
$ oc get clusterversionCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 단계
새 관리 클러스터에서 실행되는 새 OVN 컨트롤 플레인에 연결할 수 있도록 호스팅 클러스터에서 OVN Pod를 삭제합니다.
-
호스팅 클러스터의 kubeconfig 경로를 사용하여
KUBECONFIG환경 변수를 로드합니다. 다음 명령을 입력합니다.
oc delete pod -n openshift-ovn-kubernetes --all
$ oc delete pod -n openshift-ovn-kubernetes --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow
9.7. OADP를 사용하여 호스트된 클러스터에 대한 재해 복구 링크 복사링크가 클립보드에 복사되었습니다!
OADP(OpenShift API for Data Protection) Operator를 사용하여 AWS(Amazon Web Services) 및 베어 메탈에서 재해 복구를 수행할 수 있습니다.
OADP(OpenShift API for Data Protection)의 재해 복구 프로세스에는 다음 단계가 포함됩니다.
- OADP를 사용하도록 Amazon Web Services 또는 베어 메탈과 같은 플랫폼 준비
- 데이터 플레인 워크로드 백업
- 컨트롤 플레인 워크로드 백업
- OADP를 사용하여 호스트 클러스터 복원
9.7.1. 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
관리 클러스터에서 다음 사전 요구 사항을 충족해야 합니다.
- OADP Operator가 설치되어 있어야 합니다.
- 스토리지 클래스를 생성하셨습니다.
-
cluster-admin권한이 있는 클러스터에 액세스할 수 있습니다. - 카탈로그 소스를 통해 OADP 서브스크립션에 액세스할 수 있습니다.
- S3, Microsoft Azure, Google Cloud 또는 MinIO와 같은 OADP와 호환되는 클라우드 스토리지 공급자에 액세스할 수 있습니다.
- 연결이 끊긴 환경에서는 OADP와 호환되는 자체 호스팅 스토리지 공급자(예: Red Hat OpenShift Data Foundation 또는 MinIO )에 액세스할 수 있습니다.
- 호스팅된 컨트롤 플레인 pod가 실행 중입니다.
9.7.2. OADP를 사용하도록 AWS 준비 링크 복사링크가 클립보드에 복사되었습니다!
호스트된 클러스터에 대한 재해 복구를 수행하려면 AWS(Amazon Web Services) S3 호환 스토리지에서 OADP(OpenShift API for Data Protection)를 사용할 수 있습니다. DataProtectionApplication 오브젝트를 생성하면 openshift-adp 네임스페이스에 새 velero 배포 및 node-agent Pod가 생성됩니다.
OADP를 사용하도록 AWS를 준비하려면 "Multicloud Object Gateway로 데이터 보호를 위한 OpenShift API 구성"을 참조하십시오.
다음 단계
- 데이터 플레인 워크로드 백업
- 컨트롤 플레인 워크로드 백업
9.7.3. OADP를 사용하도록 베어 메탈 준비 링크 복사링크가 클립보드에 복사되었습니다!
호스트된 클러스터에 대한 재해 복구를 수행하려면 베어 메탈에서 OADP(OpenShift API for Data Protection)를 사용할 수 있습니다. DataProtectionApplication 오브젝트를 생성하면 openshift-adp 네임스페이스에 새 velero 배포 및 node-agent Pod가 생성됩니다.
OADP를 사용하도록 베어 메탈을 준비하려면 "AWS S3 호환 스토리지로 데이터 보호를 위한 OpenShift API 구성"을 참조하십시오.
다음 단계
- 데이터 플레인 워크로드 백업
- 컨트롤 플레인 워크로드 백업
9.7.4. 데이터 플레인 워크로드 백업 링크 복사링크가 클립보드에 복사되었습니다!
데이터 플레인 워크로드가 중요하지 않은 경우 이 절차를 건너뛸 수 있습니다. OADP Operator를 사용하여 데이터 플레인 워크로드를 백업하려면 "애플리케이션 백업"을 참조하십시오.
다음 단계
- OADP를 사용하여 호스트 클러스터 복원
9.7.5. 컨트롤 플레인 워크로드 백업 링크 복사링크가 클립보드에 복사되었습니다!
Backup CR(사용자 정의 리소스)을 생성하여 컨트롤 플레인 워크로드를 백업할 수 있습니다. 이 단계는 플랫폼이 AWS인지 베어 메탈인지에 따라 다릅니다.
9.7.5.1. AWS에서 컨트롤 플레인 워크로드 백업 링크 복사링크가 클립보드에 복사되었습니다!
Backup CR(사용자 정의 리소스)을 생성하여 컨트롤 플레인 워크로드를 백업할 수 있습니다.
백업 프로세스를 모니터링하고 관찰하려면 "백업 및 복원 프로세스 예약"을 참조하십시오.
프로세스
다음 명령을 실행하여
HostedCluster리소스의 조정을 일시 중지합니다.oc --kubeconfig <management_cluster_kubeconfig_file> \ patch hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name> \ --type json -p '[{"op": "add", "path": "/spec/pausedUntil", "value": "true"}]'$ oc --kubeconfig <management_cluster_kubeconfig_file> \ patch hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name> \ --type json -p '[{"op": "add", "path": "/spec/pausedUntil", "value": "true"}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 호스트 클러스터의 인프라 ID를 가져옵니다.
oc get hostedcluster -n local-cluster <hosted_cluster_name> -o=jsonpath="{.spec.infraID}"$ oc get hostedcluster -n local-cluster <hosted_cluster_name> -o=jsonpath="{.spec.infraID}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 단계에서 사용할 인프라 ID를 기록해 둡니다.
다음 명령을 실행하여
cluster.cluster.x-k8s.io리소스의 조정을 일시 중지합니다.oc --kubeconfig <management_cluster_kubeconfig_file> \ patch cluster.cluster.x-k8s.io \ -n local-cluster-<hosted_cluster_name> <hosted_cluster_infra_id> \ --type json -p '[{"op": "add", "path": "/spec/paused", "value": true}]'$ oc --kubeconfig <management_cluster_kubeconfig_file> \ patch cluster.cluster.x-k8s.io \ -n local-cluster-<hosted_cluster_name> <hosted_cluster_infra_id> \ --type json -p '[{"op": "add", "path": "/spec/paused", "value": true}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
NodePool리소스의 조정을 일시 중지합니다.oc --kubeconfig <management_cluster_kubeconfig_file> \ patch nodepool -n <hosted_cluster_namespace> <node_pool_name> \ --type json -p '[{"op": "add", "path": "/spec/pausedUntil", "value": "true"}]'$ oc --kubeconfig <management_cluster_kubeconfig_file> \ patch nodepool -n <hosted_cluster_namespace> <node_pool_name> \ --type json -p '[{"op": "add", "path": "/spec/pausedUntil", "value": "true"}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
AgentCluster리소스의 조정을 일시 중지합니다.oc --kubeconfig <management_cluster_kubeconfig_file> \ annotate agentcluster -n <hosted_control_plane_namespace> \ cluster.x-k8s.io/paused=true --all'
$ oc --kubeconfig <management_cluster_kubeconfig_file> \ annotate agentcluster -n <hosted_control_plane_namespace> \ cluster.x-k8s.io/paused=true --all'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
AgentMachine리소스의 조정을 일시 중지합니다.oc --kubeconfig <management_cluster_kubeconfig_file> \ annotate agentmachine -n <hosted_control_plane_namespace> \ cluster.x-k8s.io/paused=true --all'
$ oc --kubeconfig <management_cluster_kubeconfig_file> \ annotate agentmachine -n <hosted_control_plane_namespace> \ cluster.x-k8s.io/paused=true --all'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 호스팅된 컨트롤 플레인 네임스페이스를 삭제하지 않도록
HostedCluster리소스에 주석을 답니다.oc --kubeconfig <management_cluster_kubeconfig_file> \ annotate hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name> \ hypershift.openshift.io/skip-delete-hosted-controlplane-namespace=true
$ oc --kubeconfig <management_cluster_kubeconfig_file> \ annotate hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name> \ hypershift.openshift.io/skip-delete-hosted-controlplane-namespace=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow BackupCR을 정의하는 YAML 파일을 생성합니다.예 9.1.
backup-control-plane.yaml파일 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
backup_resource_name을Backup리소스의 이름으로 교체합니다.- 2
- 특정 네임스페이스를 선택하여 오브젝트를 백업합니다. 호스팅 클러스터 네임스페이스와 호스팅된 컨트롤 플레인 네임스페이스를 포함해야 합니다.
- 3
<hosted_cluster_namespace>를 호스트된 클러스터 네임스페이스의 이름으로 바꿉니다(예:클러스터).- 4
<hosted_control_plane_namespace>를 호스트된 컨트롤 플레인 네임스페이스의 이름으로 바꿉니다(예:클러스터 호스팅).- 5
- 별도의 네임스페이스에
infraenv리소스를 생성해야 합니다. 백업 프로세스 중에infraenv리소스를 삭제하지 마십시오. - 6 7
- CSI 볼륨 스냅샷을 활성화하고 컨트롤 플레인 워크로드를 클라우드 스토리지에 자동으로 업로드합니다.
- 8
- PV(영구 볼륨)의
fs-backup방법을 기본값으로 설정합니다. 이 설정은 CSI(Container Storage Interface) 볼륨 스냅샷과fs-backup방법을 조합할 때 유용합니다.
참고CSI 볼륨 스냅샷을 사용하려면
backup.velero.io/backup-volumes-excludes=<pv_name>주석을 PV에 추가해야 합니다.다음 명령을 실행하여
BackupCR을 적용합니다.oc apply -f backup-control-plane.yaml
$ oc apply -f backup-control-plane.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 실행하여
status.phase의 값이완료되었는지 확인합니다.oc get backups.velero.io <backup_resource_name> -n openshift-adp \ -o jsonpath='{.status.phase}'$ oc get backups.velero.io <backup_resource_name> -n openshift-adp \ -o jsonpath='{.status.phase}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 단계
- OADP를 사용하여 호스트 클러스터 복원
9.7.5.2. 베어 메탈 플랫폼에서 컨트롤 플레인 워크로드 백업 링크 복사링크가 클립보드에 복사되었습니다!
Backup CR(사용자 정의 리소스)을 생성하여 컨트롤 플레인 워크로드를 백업할 수 있습니다.
백업 프로세스를 모니터링하고 관찰하려면 "백업 및 복원 프로세스 예약"을 참조하십시오.
프로세스
다음 명령을 실행하여
HostedCluster리소스의 조정을 일시 중지합니다.oc --kubeconfig <management_cluster_kubeconfig_file> \ patch hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name> \ --type json -p '[{"op": "add", "path": "/spec/pausedUntil", "value": "true"}]'$ oc --kubeconfig <management_cluster_kubeconfig_file> \ patch hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name> \ --type json -p '[{"op": "add", "path": "/spec/pausedUntil", "value": "true"}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 호스트 클러스터의 인프라 ID를 가져옵니다.
oc --kubeconfig <management_cluster_kubeconfig_file> \ get hostedcluster -n <hosted_cluster_namespace> \ <hosted_cluster_name> -o=jsonpath="{.spec.infraID}"$ oc --kubeconfig <management_cluster_kubeconfig_file> \ get hostedcluster -n <hosted_cluster_namespace> \ <hosted_cluster_name> -o=jsonpath="{.spec.infraID}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 다음 단계에서 사용할 인프라 ID를 기록해 둡니다.
다음 명령을 실행하여
cluster.cluster.x-k8s.io리소스의 조정을 일시 중지합니다.oc --kubeconfig <management_cluster_kubeconfig_file> \ annotate cluster -n <hosted_control_plane_namespace> \ <hosted_cluster_infra_id> cluster.x-k8s.io/paused=true
$ oc --kubeconfig <management_cluster_kubeconfig_file> \ annotate cluster -n <hosted_control_plane_namespace> \ <hosted_cluster_infra_id> cluster.x-k8s.io/paused=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
NodePool리소스의 조정을 일시 중지합니다.oc --kubeconfig <management_cluster_kubeconfig_file> \ patch nodepool -n <hosted_cluster_namespace> <node_pool_name> \ --type json -p '[{"op": "add", "path": "/spec/pausedUntil", "value": "true"}]'$ oc --kubeconfig <management_cluster_kubeconfig_file> \ patch nodepool -n <hosted_cluster_namespace> <node_pool_name> \ --type json -p '[{"op": "add", "path": "/spec/pausedUntil", "value": "true"}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
AgentCluster리소스의 조정을 일시 중지합니다.oc --kubeconfig <management_cluster_kubeconfig_file> \ annotate agentcluster -n <hosted_control_plane_namespace> \ cluster.x-k8s.io/paused=true --all
$ oc --kubeconfig <management_cluster_kubeconfig_file> \ annotate agentcluster -n <hosted_control_plane_namespace> \ cluster.x-k8s.io/paused=true --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
AgentMachine리소스의 조정을 일시 중지합니다.oc --kubeconfig <management_cluster_kubeconfig_file> \ annotate agentmachine -n <hosted_control_plane_namespace> \ cluster.x-k8s.io/paused=true --all
$ oc --kubeconfig <management_cluster_kubeconfig_file> \ annotate agentmachine -n <hosted_control_plane_namespace> \ cluster.x-k8s.io/paused=true --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow 동일한 관리 클러스터를 백업하고 복원하는 경우 다음 명령을 실행하여 호스팅된 컨트롤 플레인 네임스페이스를 삭제하지 않도록
HostedCluster리소스에 주석을 답니다.oc --kubeconfig <management_cluster_kubeconfig_file> \ annotate hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name> \ hypershift.openshift.io/skip-delete-hosted-controlplane-namespace=true
$ oc --kubeconfig <management_cluster_kubeconfig_file> \ annotate hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name> \ hypershift.openshift.io/skip-delete-hosted-controlplane-namespace=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow BackupCR을 정의하는 YAML 파일을 생성합니다.예 9.2.
backup-control-plane.yaml파일 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
backup_resource_name을Backup리소스의 이름으로 교체합니다.- 2
- 특정 네임스페이스를 선택하여 오브젝트를 백업합니다. 호스팅 클러스터 네임스페이스와 호스팅된 컨트롤 플레인 네임스페이스를 포함해야 합니다.
- 3
<hosted_cluster_namespace>를 호스트된 클러스터 네임스페이스의 이름으로 바꿉니다(예:클러스터).- 4
<hosted_control_plane_namespace>를 호스트된 컨트롤 플레인 네임스페이스의 이름으로 바꿉니다(예:클러스터 호스팅).- 5
- &
lt;agent_namespace>를에이전트,BMH및InfraEnvCR이 있는 네임스페이스(예:에이전트)로 바꿉니다. - 6 7
- CSI 볼륨 스냅샷을 활성화하고 컨트롤 플레인 워크로드를 클라우드 스토리지에 자동으로 업로드합니다.
- 8
- PV(영구 볼륨)의
fs-backup방법을 기본값으로 설정합니다. 이 설정은 CSI(Container Storage Interface) 볼륨 스냅샷과fs-backup방법을 조합할 때 유용합니다.
참고CSI 볼륨 스냅샷을 사용하려면
backup.velero.io/backup-volumes-excludes=<pv_name>주석을 PV에 추가해야 합니다.다음 명령을 실행하여
BackupCR을 적용합니다.oc apply -f backup-control-plane.yaml
$ oc apply -f backup-control-plane.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 실행하여
status.phase의 값이완료되었는지 확인합니다.oc get backups.velero.io <backup_resource_name> -n openshift-adp \ -o jsonpath='{.status.phase}'$ oc get backups.velero.io <backup_resource_name> -n openshift-adp \ -o jsonpath='{.status.phase}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 단계
- OADP를 사용하여 호스트된 클러스터를 복원합니다.
9.7.6. OADP를 사용하여 호스트 클러스터 복원 링크 복사링크가 클립보드에 복사되었습니다!
호스트 클러스터를 동일한 관리 클러스터 또는 새 관리 클러스터로 복원할 수 있습니다.
9.7.6.1. OADP를 사용하여 호스트 클러스터를 동일한 관리 클러스터로 복원 링크 복사링크가 클립보드에 복사되었습니다!
Restore CR(사용자 정의 리소스)을 생성하여 호스팅된 클러스터를 복원할 수 있습니다.
- 인플레이스 업데이트를 사용하는 경우 InfraEnv에는 예비 노드가 필요하지 않습니다. 새 관리 클러스터에서 작업자 노드를 다시 프로비저닝해야 합니다.
- 교체 업데이트를 사용하는 경우 작업자 노드를 배포하려면 InfraEnv에 대한 예비 노드가 필요합니다.
호스트 클러스터를 백업한 후 이를 삭제하여 복원 프로세스를 시작해야 합니다. 노드 프로비저닝을 시작하려면 호스팅 클러스터를 삭제하기 전에 데이터 플레인의 워크로드를 백업해야 합니다.
사전 요구 사항
- 콘솔을 사용하여 호스팅된 클러스터를 삭제하여 클러스터 제거 단계를 완료했습니다.
- 클러스터를 제거한 후 나머지 리소스 제거 단계를 완료했습니다.
백업 프로세스를 모니터링하고 관찰하려면 "백업 및 복원 프로세스 예약"을 참조하십시오.
프로세스
다음 명령을 실행하여 호스팅된 컨트롤 플레인 네임스페이스에 Pod 및 PVC(영구 볼륨 클레임)가 없는지 확인합니다.
oc get pod pvc -n <hosted_control_plane_namespace>
$ oc get pod pvc -n <hosted_control_plane_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예상 출력
No resources found
No resources foundCopy to Clipboard Copied! Toggle word wrap Toggle overflow RestoreCR을 정의하는 YAML 파일을 생성합니다.restore-hosted-cluster.yaml파일의 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow 중요별도의 네임스페이스에
infraenv리소스를 생성해야 합니다. 복원 프로세스 중에infraenv리소스를 삭제하지 마십시오. 새 노드를 다시 프로비저닝하려면infraenv리소스가 필요합니다.다음 명령을 실행하여
RestoreCR을 적용합니다.oc apply -f restore-hosted-cluster.yaml
$ oc apply -f restore-hosted-cluster.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
status.phase의 값이완료되었는지 확인합니다.oc get hostedcluster <hosted_cluster_name> -n <hosted_cluster_namespace> \ -o jsonpath='{.status.phase}'$ oc get hostedcluster <hosted_cluster_name> -n <hosted_cluster_namespace> \ -o jsonpath='{.status.phase}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 복원 프로세스가 완료되면 컨트롤 플레인 워크로드를 백업하는 동안 일시 중지된
HostedCluster및NodePool리소스의 조정을 시작합니다.다음 명령을 실행하여
HostedCluster리소스의 조정을 시작합니다.oc --kubeconfig <management_cluster_kubeconfig_file> \ patch hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name> \ --type json \ -p '[{"op": "add", "path": "/spec/pausedUntil", "value": "false"}]'$ oc --kubeconfig <management_cluster_kubeconfig_file> \ patch hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name> \ --type json \ -p '[{"op": "add", "path": "/spec/pausedUntil", "value": "false"}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
NodePool리소스의 조정을 시작합니다.oc --kubeconfig <management_cluster_kubeconfig_file> \ patch nodepool -n <hosted_cluster_namespace> <node_pool_name> \ --type json \ -p '[{"op": "add", "path": "/spec/pausedUntil", "value": "false"}]'$ oc --kubeconfig <management_cluster_kubeconfig_file> \ patch nodepool -n <hosted_cluster_namespace> <node_pool_name> \ --type json \ -p '[{"op": "add", "path": "/spec/pausedUntil", "value": "false"}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
컨트롤 플레인 워크로드를 백업하는 동안 일시 중지된 에이전트 공급자 리소스의 조정을 시작합니다.
다음 명령을 실행하여
AgentCluster리소스의 조정을 시작합니다.oc --kubeconfig <management_cluster_kubeconfig_file> \ annotate agentcluster -n <hosted_control_plane_namespace> \ cluster.x-k8s.io/paused- --overwrite=true --all
$ oc --kubeconfig <management_cluster_kubeconfig_file> \ annotate agentcluster -n <hosted_control_plane_namespace> \ cluster.x-k8s.io/paused- --overwrite=true --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
AgentMachine리소스의 조정을 시작합니다.oc --kubeconfig <management_cluster_kubeconfig_file> \ annotate agentmachine -n <hosted_control_plane_namespace> \ cluster.x-k8s.io/paused- --overwrite=true --all
$ oc --kubeconfig <management_cluster_kubeconfig_file> \ annotate agentmachine -n <hosted_control_plane_namespace> \ cluster.x-k8s.io/paused- --overwrite=true --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 명령을 실행하여 호스팅된 컨트롤 플레인 네임스페이스를 수동으로 삭제하지 않도록
HostedCluster리소스에서hypershift.openshift.io/skip-delete-hosted-controlplane-namespace-annotations을 제거합니다.oc --kubeconfig <management_cluster_kubeconfig_file> \ annotate hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name> \ hypershift.openshift.io/skip-delete-hosted-controlplane-namespace- \ --overwrite=true --all
$ oc --kubeconfig <management_cluster_kubeconfig_file> \ annotate hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name> \ hypershift.openshift.io/skip-delete-hosted-controlplane-namespace- \ --overwrite=true --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow
9.7.6.2. OADP를 사용하여 호스팅된 클러스터를 새 관리 클러스터로 복원 링크 복사링크가 클립보드에 복사되었습니다!
Restore CR(사용자 정의 리소스)을 생성하여 호스팅된 클러스터를 새 관리 클러스터로 복원할 수 있습니다.
-
인플레이스 업데이트를 사용하는 경우
InfraEnv리소스에는 예비 노드가 필요하지 않습니다. 대신 새 관리 클러스터에서 작업자 노드를 다시 프로비저닝해야 합니다. -
교체 업데이트를 사용하는 경우 작업자 노드를 배포하려면
InfraEnv리소스에 대한 예비 노드가 필요합니다.
사전 요구 사항
-
OADP(OpenShift API for Data Protection)를 사용하도록 새 관리 클러스터를 구성했습니다.
RestoreCR이 백업 스토리지에 액세스할 수 있도록 새 관리 클러스터에 백업한 관리 클러스터와 동일한 DPA(Data Protection Application)가 있어야 합니다. 호스팅된 클러스터의 DNS를 확인하도록 새 관리 클러스터의 네트워킹 설정을 구성했습니다.
- 호스트의 DNS는 새 관리 클러스터와 호스팅 클러스터의 IP로 확인되어야 합니다.
- 호스팅 클러스터는 새 관리 클러스터의 IP로 확인되어야 합니다.
백업 프로세스를 모니터링하고 관찰하려면 "백업 및 복원 프로세스 예약"을 참조하십시오.
백업을 생성한 관리 클러스터가 아닌 호스트 클러스터를 복원할 새 관리 클러스터에서 다음 단계를 완료합니다.
프로세스
RestoreCR을 정의하는 YAML 파일을 생성합니다.restore-hosted-cluster.yaml파일의 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<restore_resource_name>을Restore리소스의 이름으로 바꿉니다.- 2
- 특정 네임스페이스를 선택하여 오브젝트를 백업합니다. 호스팅 클러스터 네임스페이스와 호스팅된 컨트롤 플레인 네임스페이스를 포함해야 합니다.
- 3
<hosted_cluster_namespace>를 호스트된 클러스터 네임스페이스의 이름으로 바꿉니다(예:클러스터).- 4
<hosted_control_plane_namespace>를 호스트된 컨트롤 플레인 네임스페이스의 이름으로 바꿉니다(예:클러스터 호스팅).- 5
- &
lt;agent_namespace>를에이전트,BMH및InfraEnvCR이 있는 네임스페이스(예:에이전트)로 바꿉니다. - 6
<backup_resource_name>을Backup리소스의 이름으로 바꿉니다.- 7
- Red Hat Advanced Cluster Management를 사용하지 않는 경우 이 필드를 생략할 수 있습니다.
- 8
- PV(영구 볼륨) 및 해당 Pod의 복구를 시작합니다.
- 9
- 백업된 콘텐츠를 사용하여 기존 오브젝트를 덮어쓰는지 확인합니다.
다음 명령을 실행하여
RestoreCR을 적용합니다.oc --kubeconfig <restore_management_kubeconfig> apply -f restore-hosted-cluster.yaml
$ oc --kubeconfig <restore_management_kubeconfig> apply -f restore-hosted-cluster.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
status.값이 완료되었는지 확인합니다.phaseoc --kubeconfig <restore_management_kubeconfig> \ get restore.velero.io <restore_resource_name> \ -n openshift-adp -o jsonpath='{.status.phase}'$ oc --kubeconfig <restore_management_kubeconfig> \ get restore.velero.io <restore_resource_name> \ -n openshift-adp -o jsonpath='{.status.phase}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 모든 CR이 복원되었는지 확인합니다.
oc --kubeconfig <restore_management_kubeconfig> get infraenv -n <agent_namespace>
$ oc --kubeconfig <restore_management_kubeconfig> get infraenv -n <agent_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc --kubeconfig <restore_management_kubeconfig> get agent -n <agent_namespace>
$ oc --kubeconfig <restore_management_kubeconfig> get agent -n <agent_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc --kubeconfig <restore_management_kubeconfig> get bmh -n <agent_namespace>
$ oc --kubeconfig <restore_management_kubeconfig> get bmh -n <agent_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc --kubeconfig <restore_management_kubeconfig> get hostedcluster -n <hosted_cluster_namespace>
$ oc --kubeconfig <restore_management_kubeconfig> get hostedcluster -n <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc --kubeconfig <restore_management_kubeconfig> get nodepool -n <hosted_cluster_namespace>
$ oc --kubeconfig <restore_management_kubeconfig> get nodepool -n <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc --kubeconfig <restore_management_kubeconfig> get agentmachine -n <hosted_controlplane_namespace>
$ oc --kubeconfig <restore_management_kubeconfig> get agentmachine -n <hosted_controlplane_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc --kubeconfig <restore_management_kubeconfig> get agentcluster -n <hosted_controlplane_namespace>
$ oc --kubeconfig <restore_management_kubeconfig> get agentcluster -n <hosted_controlplane_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 새 관리 클러스터를 기본 관리 클러스터로 사용하려면 다음 단계를 완료하십시오. 그렇지 않으면 기본 관리 클러스터로 백업한 관리 클러스터를 사용하려는 경우 "OADP를 사용하여 호스팅된 클러스터를 동일한 관리 클러스터에 배치"에서 5 - 8단계를 완료합니다.
다음 명령을 실행하여 백업한 관리 클러스터에서 Cluster API 배포를 제거합니다.
oc --kubeconfig <backup_management_kubeconfig> delete deploy cluster-api \ -n <hosted_control_plane_namespace>
$ oc --kubeconfig <backup_management_kubeconfig> delete deploy cluster-api \ -n <hosted_control_plane_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 하나의 Cluster API만 한 번에 클러스터에 액세스할 수 있으므로 이 단계에서는 새 관리 클러스터의 Cluster API가 올바르게 작동합니다.
복원 프로세스가 완료되면 컨트롤 플레인 워크로드를 백업하는 동안 일시 중지된
HostedCluster및NodePool리소스의 조정을 시작합니다.다음 명령을 실행하여
HostedCluster리소스의 조정을 시작합니다.oc --kubeconfig <restore_management_kubeconfig> \ patch hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name> \ --type json \ -p '[{"op": "replace", "path": "/spec/pausedUntil", "value": "false"}]'$ oc --kubeconfig <restore_management_kubeconfig> \ patch hostedcluster -n <hosted_cluster_namespace> <hosted_cluster_name> \ --type json \ -p '[{"op": "replace", "path": "/spec/pausedUntil", "value": "false"}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
NodePool리소스의 조정을 시작합니다.oc --kubeconfig <restore_management_kubeconfig> \ patch nodepool -n <hosted_cluster_namespace> <node_pool_name> \ --type json \ -p '[{"op": "replace", "path": "/spec/pausedUntil", "value": "false"}]'$ oc --kubeconfig <restore_management_kubeconfig> \ patch nodepool -n <hosted_cluster_namespace> <node_pool_name> \ --type json \ -p '[{"op": "replace", "path": "/spec/pausedUntil", "value": "false"}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 호스팅된 컨트롤 플레인을 사용할 수 있는지 확인합니다.
oc --kubeconfig <restore_management_kubeconfig> get hostedcluster
$ oc --kubeconfig <restore_management_kubeconfig> get hostedclusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 호스트된 클러스터가 다음 명령을 실행하여 클러스터 운영자를 사용할 수 있는지 확인합니다.
oc get co --kubeconfig <hosted_cluster_kubeconfig>
$ oc get co --kubeconfig <hosted_cluster_kubeconfig>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
컨트롤 플레인 워크로드를 백업하는 동안 일시 중지된 에이전트 공급자 리소스의 조정을 시작합니다.
다음 명령을 실행하여
AgentCluster리소스의 조정을 시작합니다.oc --kubeconfig <restore_management_kubeconfig> \ annotate agentcluster -n <hosted_control_plane_namespace> \ cluster.x-k8s.io/paused- --overwrite=true --all
$ oc --kubeconfig <restore_management_kubeconfig> \ annotate agentcluster -n <hosted_control_plane_namespace> \ cluster.x-k8s.io/paused- --overwrite=true --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
AgentMachine리소스의 조정을 시작합니다.oc --kubeconfig <restore_management_kubeconfig> \ annotate agentmachine -n <hosted_control_plane_namespace> \ cluster.x-k8s.io/paused- --overwrite=true --all
$ oc --kubeconfig <restore_management_kubeconfig> \ annotate agentmachine -n <hosted_control_plane_namespace> \ cluster.x-k8s.io/paused- --overwrite=true --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
클러스터리소스의 조정을 시작합니다.oc --kubeconfig <restore_management_kubeconfig> \ annotate cluster -n <hosted_control_plane_namespace> \ cluster.x-k8s.io/paused- --overwrite=true --all
$ oc --kubeconfig <restore_management_kubeconfig> \ annotate cluster -n <hosted_control_plane_namespace> \ cluster.x-k8s.io/paused- --overwrite=true --allCopy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 명령을 실행하여 노드 풀이 예상대로 작동하는지 확인합니다.
oc --kubeconfig <restore_management_kubeconfig> \ get nodepool -n <hosted_cluster_namespace>
$ oc --kubeconfig <restore_management_kubeconfig> \ get nodepool -n <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE hosted-0 hosted-0 3 3 False False 4.17.11 False False
NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE hosted-0 hosted-0 3 3 False False 4.17.11 False FalseCopy to Clipboard Copied! Toggle word wrap Toggle overflow 선택 사항: 충돌이 없고 새 관리 클러스터에 지속적인 기능이 있는지 확인하려면 다음 단계를 완료하여 백업 관리 클러스터에서
HostedCluster리소스를 제거합니다.ClusterDeployment리소스에서 백업한 관리 클러스터에서 다음 명령을 실행하여spec.preserveOnDelete매개변수를true로 설정합니다.oc --kubeconfig <backup_management_kubeconfig> patch \ -n <hosted_control_plane_namespace> \ ClusterDeployment/<hosted_cluster_name> -p \ '{"spec":{"preserveOnDelete":'true'}}' \ --type=merge$ oc --kubeconfig <backup_management_kubeconfig> patch \ -n <hosted_control_plane_namespace> \ ClusterDeployment/<hosted_cluster_name> -p \ '{"spec":{"preserveOnDelete":'true'}}' \ --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이 단계에서는 호스트가 프로비저닝 해제되지 않습니다.
다음 명령을 실행하여 머신을 삭제합니다.
oc --kubeconfig <backup_management_kubeconfig> patch \ <machine_name> -n <hosted_control_plane_namespace> -p \ '[{"op":"remove","path":"/metadata/finalizers"}]' \ --type=merge$ oc --kubeconfig <backup_management_kubeconfig> patch \ <machine_name> -n <hosted_control_plane_namespace> -p \ '[{"op":"remove","path":"/metadata/finalizers"}]' \ --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc --kubeconfig <backup_management_kubeconfig> \ delete machine <machine_name> \ -n <hosted_control_plane_namespace>
$ oc --kubeconfig <backup_management_kubeconfig> \ delete machine <machine_name> \ -n <hosted_control_plane_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
Agent및 Cluster 리소스를 삭제합니다.Clusteroc --kubeconfig <backup_management_kubeconfig> \ delete agentcluster <hosted_cluster_name> \ -n <hosted_control_plane_namespace>
$ oc --kubeconfig <backup_management_kubeconfig> \ delete agentcluster <hosted_cluster_name> \ -n <hosted_control_plane_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc --kubeconfig <backup_management_kubeconfig> \ patch cluster <cluster_name> \ -n <hosted_control_plane_namespace> \ -p '[{"op":"remove","path":"/metadata/finalizers"}]' \ --type=json$ oc --kubeconfig <backup_management_kubeconfig> \ patch cluster <cluster_name> \ -n <hosted_control_plane_namespace> \ -p '[{"op":"remove","path":"/metadata/finalizers"}]' \ --type=jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc --kubeconfig <backup_management_kubeconfig> \ delete cluster <cluster_name> \ -n <hosted_control_plane_namespace>
$ oc --kubeconfig <backup_management_kubeconfig> \ delete cluster <cluster_name> \ -n <hosted_control_plane_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Red Hat Advanced Cluster Management를 사용하는 경우 다음 명령을 실행하여 관리 클러스터를 삭제합니다.
oc --kubeconfig <backup_management_kubeconfig> \ patch managedcluster <hosted_cluster_name> \ -n <hosted_cluster_namespace> \ -p '[{"op":"remove","path":"/metadata/finalizers"}]' \ --type=json$ oc --kubeconfig <backup_management_kubeconfig> \ patch managedcluster <hosted_cluster_name> \ -n <hosted_cluster_namespace> \ -p '[{"op":"remove","path":"/metadata/finalizers"}]' \ --type=jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc --kubeconfig <backup_management_kubeconfig> \ delete managedcluster <hosted_cluster_name> \ -n <hosted_cluster_namespace>
$ oc --kubeconfig <backup_management_kubeconfig> \ delete managedcluster <hosted_cluster_name> \ -n <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
HostedCluster리소스를 삭제합니다.oc --kubeconfig <backup_management_kubeconfig> \ delete hostedcluster \ -n <hosted_cluster_namespace> <hosted_cluster_name>
$ oc --kubeconfig <backup_management_kubeconfig> \ delete hostedcluster \ -n <hosted_cluster_namespace> <hosted_cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.7.7. 백업 및 복원 프로세스 관찰 링크 복사링크가 클립보드에 복사되었습니다!
OADP(OpenShift API for Data Protection)를 사용하여 호스팅된 클러스터를 백업하고 복원할 때 프로세스를 모니터링하고 관찰할 수 있습니다.
프로세스
다음 명령을 실행하여 백업 프로세스를 관찰합니다.
watch "oc get backups.velero.io -n openshift-adp <backup_resource_name> -o jsonpath='{.status}'"$ watch "oc get backups.velero.io -n openshift-adp <backup_resource_name> -o jsonpath='{.status}'"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 복원 프로세스를 관찰합니다.
watch "oc get restores.velero.io -n openshift-adp <backup_resource_name> -o jsonpath='{.status}'"$ watch "oc get restores.velero.io -n openshift-adp <backup_resource_name> -o jsonpath='{.status}'"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 Velero 로그를 관찰합니다.
oc logs -n openshift-adp -ldeploy=velero -f
$ oc logs -n openshift-adp -ldeploy=velero -fCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 모든 OADP 오브젝트의 진행 상황을 확인합니다.
watch "echo BackupRepositories:;echo;oc get backuprepositories.velero.io -A;echo; echo BackupStorageLocations: ;echo; oc get backupstoragelocations.velero.io -A;echo;echo DataUploads: ;echo;oc get datauploads.velero.io -A;echo;echo DataDownloads: ;echo;oc get datadownloads.velero.io -n openshift-adp; echo;echo VolumeSnapshotLocations: ;echo;oc get volumesnapshotlocations.velero.io -A;echo;echo Backups:;echo;oc get backup -A; echo;echo Restores:;echo;oc get restore -A"
$ watch "echo BackupRepositories:;echo;oc get backuprepositories.velero.io -A;echo; echo BackupStorageLocations: ;echo; oc get backupstoragelocations.velero.io -A;echo;echo DataUploads: ;echo;oc get datauploads.velero.io -A;echo;echo DataDownloads: ;echo;oc get datadownloads.velero.io -n openshift-adp; echo;echo VolumeSnapshotLocations: ;echo;oc get volumesnapshotlocations.velero.io -A;echo;echo Backups:;echo;oc get backup -A; echo;echo Restores:;echo;oc get restore -A"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.7.8. velero CLI를 사용하여 백업 및 복원 리소스 설명 링크 복사링크가 클립보드에 복사되었습니다!
데이터 보호를 위한 OpenShift API를 사용하는 경우 velero CLI(명령줄 인터페이스)를 사용하여 Backup 및 Restore 리소스에 대한 자세한 정보를 얻을 수 있습니다.
프로세스
다음 명령을 실행하여 컨테이너에서
veleroCLI를 사용하도록 별칭을 생성합니다.alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'
$ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
RestoreCR(사용자 정의 리소스)에 대한 세부 정보를 가져옵니다.velero restore describe <restore_resource_name> --details
$ velero restore describe <restore_resource_name> --details1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<restore_resource_name>을Restore리소스의 이름으로 바꿉니다.
다음 명령을 실행하여
BackupCR에 대한 세부 정보를 가져옵니다.velero restore describe <backup_resource_name> --details
$ velero restore describe <backup_resource_name> --details1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<backup_resource_name>을Backup리소스의 이름으로 바꿉니다.
9.8. OADP를 사용하여 호스트된 클러스터에 대한 자동화된 재해 복구 링크 복사링크가 클립보드에 복사되었습니다!
베어 메탈 또는 AWS(Amazon Web Services) 플랫폼의 호스팅된 클러스터에서는 OpenShift API for Data Protection(OADP) Operator를 사용하여 일부 백업 및 복원 단계를 자동화할 수 있습니다.
프로세스에는 다음 단계가 포함됩니다.
- OADP 구성
- DPA(Data Protection Application) 정의
- 데이터 플레인 워크로드 백업
- 컨트롤 플레인 워크로드 백업
- OADP를 사용하여 호스트 클러스터 복원
9.8.1. 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
관리 클러스터에서 다음 사전 요구 사항을 충족해야 합니다.
- OADP Operator가 설치되어 있어야 합니다.
- 스토리지 클래스를 생성하셨습니다.
-
cluster-admin권한이 있는 클러스터에 액세스할 수 있습니다. - 카탈로그 소스를 통해 OADP 서브스크립션에 액세스할 수 있습니다.
- S3, Microsoft Azure, Google Cloud 또는 MinIO와 같은 OADP와 호환되는 클라우드 스토리지 공급자에 액세스할 수 있습니다.
- 연결이 끊긴 환경에서는 OADP와 호환되는 자체 호스팅 스토리지 공급자(예: Red Hat OpenShift Data Foundation 또는 MinIO )에 액세스할 수 있습니다.
- 호스팅된 컨트롤 플레인 pod가 실행 중입니다.
9.8.2. OADP 구성 링크 복사링크가 클립보드에 복사되었습니다!
호스트 클러스터가 AWS에 있는 경우 "Multicloud Object Gateway를 사용하여 OpenShift API 구성"의 단계를 수행하여 OADP를 구성합니다.
호스트 클러스터가 베어 메탈 플랫폼에 있는 경우 "AWS S3 호환 스토리지로 OpenShift API 구성"의 단계를 수행하여 OADP를 구성합니다.
9.8.3. DPA를 사용하여 백업 및 복원 프로세스 자동화 링크 복사링크가 클립보드에 복사되었습니다!
DPA(Data Protection Application)를 사용하여 백업 및 복원 프로세스의 일부를 자동화할 수 있습니다. DPA를 사용하면 리소스 조정을 일시 중지하고 다시 시작하는 단계가 자동화됩니다. DPA는 백업 위치 및 Velero Pod 구성을 포함한 정보를 정의합니다.
DataProtectionApplication 개체를 정의하여 DPA를 만들 수 있습니다.
프로세스
베어 메탈 플랫폼을 사용하는 경우 다음 단계를 완료하여 DPA를 생성할 수 있습니다.
다음 예와 유사한 매니페스트 파일을 생성합니다.
예 9.3.
dpa.yaml파일 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 DPA 오브젝트를 생성합니다.
oc create -f dpa.yaml
$ oc create -f dpa.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow DataProtectionApplication오브젝트를 생성하면openshift-adp네임스페이스에 새velero배포 및node-agentPod가 생성됩니다.
AWS(Amazon Web Services)를 사용하는 경우 다음 단계를 완료하여 DPA를 생성할 수 있습니다.
다음 예와 유사한 매니페스트 파일을 생성합니다.
예 9.4.
dpa.yaml파일 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 DPA 리소스를 생성합니다.
oc create -f dpa.yaml
$ oc create -f dpa.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow DataProtectionApplication오브젝트를 생성하면openshift-adp네임스페이스에 새velero배포 및node-agentPod가 생성됩니다.
다음 단계
- 데이터 플레인 워크로드를 백업합니다.
9.8.4. 데이터 플레인 워크로드 백업 링크 복사링크가 클립보드에 복사되었습니다!
OADP Operator를 사용하여 데이터 플레인 워크로드를 백업하려면 "애플리케이션 백업"을 참조하십시오. 데이터 플레인 워크로드가 중요하지 않은 경우 이 절차를 건너뛸 수 있습니다.
9.8.5. 컨트롤 플레인 워크로드 백업 링크 복사링크가 클립보드에 복사되었습니다!
Backup CR(사용자 정의 리소스)을 생성하여 컨트롤 플레인 워크로드를 백업할 수 있습니다.
백업 프로세스를 모니터링하고 관찰하려면 "백업 및 복원 프로세스 예약"을 참조하십시오.
프로세스
BackupCR을 정의하는 YAML 파일을 생성합니다.예 9.5.
backup-control-plane.yaml파일 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
backup_resource_name을Backup리소스의 이름으로 교체합니다.- 2
- 특정 네임스페이스를 선택하여 오브젝트를 백업합니다. 호스팅 클러스터 네임스페이스와 호스팅된 컨트롤 플레인 네임스페이스를 포함해야 합니다.
- 3
<hosted_cluster_namespace>를 호스트된 클러스터 네임스페이스의 이름으로 바꿉니다(예:클러스터).- 4
<hosted_control_plane_namespace>를 호스트된 컨트롤 플레인 네임스페이스의 이름으로 바꿉니다(예:클러스터 호스팅).- 5
- 별도의 네임스페이스에
infraenv리소스를 생성해야 합니다. 백업 프로세스 중에infraenv리소스를 삭제하지 마십시오. - 6 7
- CSI 볼륨 스냅샷을 활성화하고 컨트롤 플레인 워크로드를 클라우드 스토리지에 자동으로 업로드합니다.
- 8
- PV(영구 볼륨)의
fs-backup방법을 기본값으로 설정합니다. 이 설정은 CSI(Container Storage Interface) 볼륨 스냅샷과fs-backup방법을 조합할 때 유용합니다.
참고CSI 볼륨 스냅샷을 사용하려면
backup.velero.io/backup-volumes-excludes=<pv_name>주석을 PV에 추가해야 합니다.다음 명령을 실행하여
BackupCR을 적용합니다.oc apply -f backup-control-plane.yaml
$ oc apply -f backup-control-plane.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 실행하여
status.값이 완료되었는지 확인합니다.phaseoc get backups.velero.io <backup_resource_name> -n openshift-adp \ -o jsonpath='{.status.phase}'$ oc get backups.velero.io <backup_resource_name> -n openshift-adp \ -o jsonpath='{.status.phase}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 단계
- OADP를 사용하여 호스트된 클러스터를 복원합니다.
9.8.6. OADP를 사용하여 호스트 클러스터 복원 링크 복사링크가 클립보드에 복사되었습니다!
Restore CR(사용자 정의 리소스)을 생성하여 호스팅된 클러스터를 복원할 수 있습니다.
-
인플레이스 업데이트를 사용하는 경우
InfraEnv리소스에는 예비 노드가 필요하지 않습니다. 새 관리 클러스터에서 작업자 노드를 다시 프로비저닝해야 합니다. -
교체 업데이트를 사용하는 경우 작업자 노드를 배포하려면
InfraEnv리소스에 대한 예비 노드가 필요합니다.
호스트 클러스터를 백업한 후 이를 삭제하여 복원 프로세스를 시작해야 합니다. 노드 프로비저닝을 시작하려면 호스팅 클러스터를 삭제하기 전에 데이터 플레인의 워크로드를 백업해야 합니다.
사전 요구 사항
- 콘솔(RHACM 문서)을 사용하여 호스트된 클러스터를 삭제하여 클러스터 제거 단계를 완료했습니다.
- 클러스터(RHACM 문서)를 제거한 후 나머지 리소스 제거 단계를 완료했습니다.
백업 프로세스를 모니터링하고 관찰하려면 "백업 및 복원 프로세스 예약"을 참조하십시오.
프로세스
다음 명령을 실행하여 호스팅된 컨트롤 플레인 네임스페이스에 Pod 및 PVC(영구 볼륨 클레임)가 없는지 확인합니다.
oc get pod pvc -n <hosted_control_plane_namespace>
$ oc get pod pvc -n <hosted_control_plane_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예상 출력
No resources found
No resources foundCopy to Clipboard Copied! Toggle word wrap Toggle overflow RestoreCR을 정의하는 YAML 파일을 생성합니다.restore-hosted-cluster.yaml파일의 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow 중요별도의 네임스페이스에
InfraEnv리소스를 생성해야 합니다. 복원 프로세스 중에InfraEnv리소스를 삭제하지 마십시오. 새 노드를 다시 프로비저닝하려면InfraEnv리소스가 필요합니다.다음 명령을 실행하여
RestoreCR을 적용합니다.oc apply -f restore-hosted-cluster.yaml
$ oc apply -f restore-hosted-cluster.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
status.phase의 값이완료되었는지 확인합니다.oc get hostedcluster <hosted_cluster_name> -n <hosted_cluster_namespace> \ -o jsonpath='{.status.phase}'$ oc get hostedcluster <hosted_cluster_name> -n <hosted_cluster_namespace> \ -o jsonpath='{.status.phase}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.8.7. 백업 및 복원 프로세스 관찰 링크 복사링크가 클립보드에 복사되었습니다!
OADP(OpenShift API for Data Protection)를 사용하여 호스팅된 클러스터를 백업하고 복원할 때 프로세스를 모니터링하고 관찰할 수 있습니다.
프로세스
다음 명령을 실행하여 백업 프로세스를 관찰합니다.
watch "oc get backups.velero.io -n openshift-adp <backup_resource_name> -o jsonpath='{.status}'"$ watch "oc get backups.velero.io -n openshift-adp <backup_resource_name> -o jsonpath='{.status}'"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 복원 프로세스를 관찰합니다.
watch "oc get restores.velero.io -n openshift-adp <backup_resource_name> -o jsonpath='{.status}'"$ watch "oc get restores.velero.io -n openshift-adp <backup_resource_name> -o jsonpath='{.status}'"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 Velero 로그를 관찰합니다.
oc logs -n openshift-adp -ldeploy=velero -f
$ oc logs -n openshift-adp -ldeploy=velero -fCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 모든 OADP 오브젝트의 진행 상황을 확인합니다.
watch "echo BackupRepositories:;echo;oc get backuprepositories.velero.io -A;echo; echo BackupStorageLocations: ;echo; oc get backupstoragelocations.velero.io -A;echo;echo DataUploads: ;echo;oc get datauploads.velero.io -A;echo;echo DataDownloads: ;echo;oc get datadownloads.velero.io -n openshift-adp; echo;echo VolumeSnapshotLocations: ;echo;oc get volumesnapshotlocations.velero.io -A;echo;echo Backups:;echo;oc get backup -A; echo;echo Restores:;echo;oc get restore -A"
$ watch "echo BackupRepositories:;echo;oc get backuprepositories.velero.io -A;echo; echo BackupStorageLocations: ;echo; oc get backupstoragelocations.velero.io -A;echo;echo DataUploads: ;echo;oc get datauploads.velero.io -A;echo;echo DataDownloads: ;echo;oc get datadownloads.velero.io -n openshift-adp; echo;echo VolumeSnapshotLocations: ;echo;oc get volumesnapshotlocations.velero.io -A;echo;echo Backups:;echo;oc get backup -A; echo;echo Restores:;echo;oc get restore -A"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.8.8. velero CLI를 사용하여 백업 및 복원 리소스 설명 링크 복사링크가 클립보드에 복사되었습니다!
데이터 보호를 위한 OpenShift API를 사용하는 경우 velero CLI(명령줄 인터페이스)를 사용하여 Backup 및 Restore 리소스에 대한 자세한 정보를 얻을 수 있습니다.
프로세스
다음 명령을 실행하여 컨테이너에서
veleroCLI를 사용하도록 별칭을 생성합니다.alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'
$ alias velero='oc -n openshift-adp exec deployment/velero -c velero -it -- ./velero'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
RestoreCR(사용자 정의 리소스)에 대한 세부 정보를 가져옵니다.velero restore describe <restore_resource_name> --details
$ velero restore describe <restore_resource_name> --details1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<restore_resource_name>을Restore리소스의 이름으로 바꿉니다.
다음 명령을 실행하여
BackupCR에 대한 세부 정보를 가져옵니다.velero restore describe <backup_resource_name> --details
$ velero restore describe <backup_resource_name> --details1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<backup_resource_name>을Backup리소스의 이름으로 바꿉니다.
10장. 호스팅된 컨트롤 플레인에 대한 인증 및 권한 부여 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 컨트롤 플레인에는 내장 OAuth 서버가 포함되어 있습니다. OpenShift Container Platform API에 인증하기 위해 OAuth 액세스 토큰을 가져올 수 있습니다. 호스팅 클러스터를 생성한 후 ID 공급자를 지정하여 OAuth를 구성할 수 있습니다.
10.1. CLI를 사용하여 호스팅된 클러스터에 대한 OAuth 서버 구성 링크 복사링크가 클립보드에 복사되었습니다!
CLI를 사용하여 호스팅된 클러스터에 대한 내부 OAuth 서버를 구성할 수 있습니다.
지원되는 ID 공급자에 대해 OAuth를 구성할 수 있습니다.
-
oidc -
htpasswd -
Keystone -
ldap -
basic-authentication -
request-header -
github -
gitlab -
google
OAuth 구성에서 ID 공급자를 추가하면 기본 kubeadmin 사용자 공급자가 제거됩니다.
ID 공급자를 구성할 때 먼저 호스팅 클러스터에서 하나 이상의 NodePool 복제본을 구성해야 합니다. DNS 확인을 위한 트래픽은 작업자 노드를 통해 전송됩니다. htpasswd 및 request-header ID 공급자에 대해 NodePool 복제본을 사전에 구성할 필요가 없습니다.
사전 요구 사항
- 호스팅된 클러스터를 생성하셨습니다.
프로세스
다음 명령을 실행하여 호스팅 클러스터에서
HostedClusterCR(사용자 정의 리소스)을 편집합니다.oc edit hostedcluster <hosted_cluster_name> -n <hosted_cluster_namespace>
$ oc edit hostedcluster <hosted_cluster_name> -n <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예제를 사용하여
HostedClusterCR에 OAuth 구성을 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 호스팅된 클러스터 이름을 지정합니다.
- 2
- 호스팅된 클러스터 네임스페이스를 지정합니다.
- 3
- 이 공급자 이름은 ID 클레임 값 앞에 접두어로 지정되어 ID 이름을 형성합니다. 공급자 이름은 리디렉션 URL을 빌드하는 데도 사용됩니다.
- 4
- 이메일 주소로 사용할 속성 목록을 정의합니다.
- 5
- 표시 이름으로 사용할 속성 목록을 정의합니다.
- 6
- 기본 사용자 이름으로 사용할 속성 목록을 정의합니다.
- 7
- OpenID 공급자에 등록된 클라이언트의 ID를 정의합니다. 클라이언트가
https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name> URL로 리디렉션되도록 허용해야 합니다. - 8
- OpenID 공급자에 등록된 클라이언트의 시크릿을 정의합니다.
- 9
- OpenID 사양에 설명된 Issuer Identifier 입니다. 쿼리 또는 조각 구성 요소 없이
https를 사용해야 합니다. - 10
- 이 공급자와
User오브젝트의 ID 간에 매핑이 설정되는 방법을 제어하는 매핑 방법을 정의합니다.
- 파일을 저장하여 변경 사항을 적용합니다.
10.2. 웹 콘솔을 사용하여 호스트 클러스터의 OAuth 서버 구성 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 웹 콘솔을 사용하여 호스팅된 클러스터에 대한 내부 OAuth 서버를 구성할 수 있습니다.
지원되는 ID 공급자에 대해 OAuth를 구성할 수 있습니다.
-
oidc -
htpasswd -
Keystone -
ldap -
basic-authentication -
request-header -
github -
gitlab -
google
OAuth 구성에서 ID 공급자를 추가하면 기본 kubeadmin 사용자 공급자가 제거됩니다.
ID 공급자를 구성할 때 먼저 호스팅 클러스터에서 하나 이상의 NodePool 복제본을 구성해야 합니다. DNS 확인을 위한 트래픽은 작업자 노드를 통해 전송됩니다. htpasswd 및 request-header ID 공급자에 대해 NodePool 복제본을 사전에 구성할 필요가 없습니다.
사전 요구 사항
-
cluster-admin권한이 있는 사용자로 로그인했습니다. - 호스팅된 클러스터를 생성하셨습니다.
프로세스
- 홈 → API Explorer 로 이동합니다.
-
Filter by kind 상자를 사용하여
HostedCluster리소스를 검색합니다. -
편집하려는
HostedCluster리소스를 클릭합니다. - Instances 탭을 클릭합니다.
-
호스팅된 클러스터 이름 항목 옆에 있는 옵션 메뉴
를 클릭하고 호스트 클러스터 편집을 클릭합니다.
YAML 파일에 OAuth 구성을 추가합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 이 공급자 이름은 ID 클레임 값 앞에 접두어로 지정되어 ID 이름을 형성합니다. 공급자 이름은 리디렉션 URL을 빌드하는 데도 사용됩니다.
- 2
- 이메일 주소로 사용할 속성 목록을 정의합니다.
- 3
- 표시 이름으로 사용할 속성 목록을 정의합니다.
- 4
- 기본 사용자 이름으로 사용할 속성 목록을 정의합니다.
- 5
- OpenID 공급자에 등록된 클라이언트의 ID를 정의합니다. 클라이언트가
https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name> URL로 리디렉션되도록 허용해야 합니다. - 6
- OpenID 공급자에 등록된 클라이언트의 시크릿을 정의합니다.
- 7
- OpenID 사양에 설명된 Issuer Identifier 입니다. 쿼리 또는 조각 구성 요소 없이
https를 사용해야 합니다. - 8
- 이 공급자와
User오브젝트의 ID 간에 매핑이 설정되는 방법을 제어하는 매핑 방법을 정의합니다.
- 저장을 클릭합니다.
10.3. AWS의 호스팅된 클러스터에서 CCO를 사용하여 구성 요소 IAM 역할 할당 링크 복사링크가 클립보드에 복사되었습니다!
AWS(Amazon Web Services)의 호스팅된 클러스터에서 CCO(Cloud Credential Operator)를 사용하여 단기적이고 제한된 권한 보안 인증 정보를 제공하는 IAM 역할을 할당할 수 있습니다. 기본적으로 CCO는 호스팅된 컨트롤 플레인에서 실행됩니다.
CCO는 AWS의 호스팅된 클러스터에 대해서만 수동 모드를 지원합니다. 기본적으로 호스팅 클러스터는 수동 모드로 구성됩니다. 관리 클러스터는 수동 이외의 모드를 사용할 수 있습니다.
10.4. AWS의 호스트 클러스터에서 CCO 설치 확인 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 컨트롤 플레인에서 CCO(Cloud Credential Operator)가 올바르게 실행되고 있는지 확인할 수 있습니다.
사전 요구 사항
- AWS(Amazon Web Services)에서 호스팅된 클러스터를 구성했습니다.
프로세스
다음 명령을 실행하여 CCO가 호스팅 클러스터의 수동 모드로 구성되었는지 확인합니다.
oc get cloudcredentials <hosted_cluster_name> \ -n <hosted_cluster_namespace> \ -o=jsonpath={.spec.credentialsMode}$ oc get cloudcredentials <hosted_cluster_name> \ -n <hosted_cluster_namespace> \ -o=jsonpath={.spec.credentialsMode}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예상 출력
Manual
ManualCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
serviceAccountIssuer리소스의 값이 비어 있지 않은지 확인합니다.oc get authentication cluster --kubeconfig <hosted_cluster_name>.kubeconfig \ -o jsonpath --template '{.spec.serviceAccountIssuer }'$ oc get authentication cluster --kubeconfig <hosted_cluster_name>.kubeconfig \ -o jsonpath --template '{.spec.serviceAccountIssuer }'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
https://aos-hypershift-ci-oidc-29999.s3.us-east-2.amazonaws.com/hypershift-ci-29999
https://aos-hypershift-ci-oidc-29999.s3.us-east-2.amazonaws.com/hypershift-ci-29999Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.5. Operator가 AWS STS를 사용하여 CCO 기반 워크플로우를 지원하도록 활성화 링크 복사링크가 클립보드에 복사되었습니다!
OLM(Operator Lifecycle Manager)에서 프로젝트를 실행하도록 프로젝트를 설계하는 Operator 작성자는 CCO(Cloud Credential Operator)를 지원하도록 프로젝트를 사용자 정의하여 Operator를 STS 사용 OpenShift Container Platform 클러스터에서 AWS에 대해 인증할 수 있습니다.
이 방법을 사용하면 Operator에서 CredentialsRequest 오브젝트를 생성하고 결과 Secret 오브젝트를 읽는 데 필요한 RBAC 권한이 필요합니다.
기본적으로 Operator 배포와 관련된 Pod는 serviceAccountToken 볼륨을 마운트하여 결과 Secret 오브젝트에서 서비스 계정 토큰을 참조할 수 있습니다.
전제 조건
- OpenShift Container Platform 4.14 이상
- STS 모드의 클러스터
- OLM 기반 Operator 프로젝트
프로세스
Operator 프로젝트의 CSV(
ClusterServiceVersion) 오브젝트를 업데이트합니다.Operator에
CredentialsRequests오브젝트를 생성할 수 있는 RBAC 권한이 있는지 확인합니다.예 10.1.
clusterPermissions목록의 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow AWS STS를 사용하여 이 CCO 기반 워크플로우 방법에 대한 지원을 클레임하려면 다음 주석을 추가합니다.
# ... metadata: annotations: features.operators.openshift.io/token-auth-aws: "true"
# ... metadata: annotations: features.operators.openshift.io/token-auth-aws: "true"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Operator 프로젝트 코드를 업데이트합니다.
Subscription오브젝트를 통해 Pod에 설정된 환경 변수에서 ARN 역할을 가져옵니다. 예를 들면 다음과 같습니다.// Get ENV var roleARN := os.Getenv("ROLEARN") setupLog.Info("getting role ARN", "role ARN = ", roleARN) webIdentityTokenPath := "/var/run/secrets/openshift/serviceaccount/token"// Get ENV var roleARN := os.Getenv("ROLEARN") setupLog.Info("getting role ARN", "role ARN = ", roleARN) webIdentityTokenPath := "/var/run/secrets/openshift/serviceaccount/token"Copy to Clipboard Copied! Toggle word wrap Toggle overflow CredentialsRequest개체를 패치하고 적용할 준비가 되었는지 확인합니다. 예를 들면 다음과 같습니다.예 10.2.
CredentialsRequest오브젝트 생성 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow 또는 YAML 형식의
CredentialsRequest오브젝트(예: Operator 프로젝트 코드의 일부)에서 시작하는 경우 다르게 처리할 수 있습니다.예 10.3. YAML 형식의
CredentialsRequest오브젝트 생성 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고Operator 번들에
CredentialsRequest오브젝트를 추가하는 것은 현재 지원되지 않습니다.인증 정보 요청에 ARN 및 웹 ID 토큰 경로를 추가하고 Operator 초기화 중에 적용합니다.
예 10.4. Operator 초기화 중
CredentialsRequest오브젝트 적용 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow Operator에서 조정 중인 다른 항목과 함께 호출되는 다음 예와 같이 Operator가 CCO에서
Secret오브젝트가 표시될 때까지 기다릴 수 있습니다.예 10.5.
Secret오브젝트 대기의 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
시간 초과값은 CCO에서 추가된CredentialsRequest오브젝트를 감지하고Secret오브젝트를 생성하는 속도의 추정치를 기반으로 합니다. Operator가 아직 클라우드 리소스에 액세스하지 않는 이유를 확인할 수 있는 클러스터 관리자에게 시간을 낮추거나 사용자 정의 피드백을 생성하는 것을 고려할 수 있습니다.
인증 정보 요청에서 CCO에서 생성한 보안을 읽고 해당 시크릿의 데이터가 포함된 AWS 구성 파일을 생성하여 AWS 구성을 설정합니다.
예 10.6. AWS 구성 생성 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 중요시크릿은 존재하는 것으로 가정되지만 Operator 코드는 이 시크릿을 사용할 때 대기하고 재시도하여 CCO에 시간을 할애하여 보안을 생성해야 합니다.
또한 대기 기간은 결국 OpenShift Container Platform 클러스터 버전 및 CCO가 STS 탐지를 사용하여
CredentialsRequest오브젝트 워크플로를 지원하지 않는 이전 버전일 수 있음을 사용자에게 시간 초과하고 경고해야 합니다. 이러한 경우 다른 방법을 사용하여 시크릿을 추가해야 함을 사용자에게 지시합니다.AWS SDK 세션을 구성합니다. 예를 들면 다음과 같습니다.
예 10.7. AWS SDK 세션 구성 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11장. 호스트된 컨트롤 플레인에 대한 머신 구성 처리 링크 복사링크가 클립보드에 복사되었습니다!
독립 실행형 OpenShift Container Platform 클러스터에서 머신 구성 풀은 노드 세트를 관리합니다. MachineConfigPool CR(사용자 정의 리소스)을 사용하여 머신 구성을 처리할 수 있습니다.
NodePool CR의 nodepool.spec.config 필드에서 machineconfiguration.openshift.io 리소스를 참조할 수 있습니다.
호스팅된 컨트롤 플레인에서는 MachineConfigPool CR이 존재하지 않습니다. 노드 풀에는 컴퓨팅 노드 세트가 포함되어 있습니다. 노드 풀을 사용하여 머신 구성을 처리할 수 있습니다. 클러스터 자동 스케일러를 사용하여 호스팅된 클러스터에서 워크로드를 관리할 수 있습니다.
OpenShift Container Platform 4.18 이상에서는 작업자 노드의 기본 컨테이너 런타임이 runC에서 crun으로 변경됩니다.
11.1. 호스팅된 컨트롤 플레인의 노드 풀 구성 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 컨트롤 플레인에서는 관리 클러스터의 구성 맵 내에 MachineConfig 오브젝트를 생성하여 노드 풀을 구성할 수 있습니다.
절차
관리 클러스터의 구성 맵 내에
MachineConfig오브젝트를 생성하려면 다음 정보를 입력합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
MachineConfig오브젝트가 저장된 노드의 경로를 설정합니다.
구성 맵에 오브젝트를 추가한 후 다음과 같이 구성 맵을 노드 풀에 적용할 수 있습니다.
$ oc edit nodepool <nodepool_name> --namespace <hosted_cluster_namespace>
$ oc edit nodepool <nodepool_name> --namespace <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;configmap_name>을 구성 맵 이름으로 바꿉니다.
11.2. 노드 풀의 kubelet 구성 참조 링크 복사링크가 클립보드에 복사되었습니다!
노드 풀에서 kubelet 구성을 참조하려면 구성 맵에 kubelet 구성을 추가한 다음 NodePool 리소스에 구성 맵을 적용합니다.
프로세스
다음 정보를 입력하여 관리 클러스터의 구성 맵 내부에 kubelet 구성을 추가합니다.
kubelet 구성이 있는
ConfigMap오브젝트의 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 노드 풀에 구성 맵을 적용합니다.
$ oc edit nodepool <nodepool_name> --namespace clusters
$ oc edit nodepool <nodepool_name> --namespace clusters1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;nodepool_name>을 노드 풀 이름으로 바꿉니다.
NodePool리소스 구성의 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;configmap_name>을 구성 맵 이름으로 바꿉니다.
11.3. 호스트 클러스터에서 노드 튜닝 구성 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 클러스터의 노드에 노드 수준 튜닝을 설정하려면 Node Tuning Operator를 사용할 수 있습니다. 호스팅된 컨트롤 플레인에서는 Tuned 오브젝트가 포함된 구성 맵을 생성하고 노드 풀에 해당 구성 맵을 참조하여 노드 튜닝을 구성할 수 있습니다.
절차
유효한 tuned 매니페스트가 포함된 구성 맵을 생성하고 노드 풀에서 매니페스트를 참조합니다. 다음 예에서
Tuned매니페스트는tuned-1-node-label노드 라벨이 임의의 값이 포함된 노드에서vm.dirty_ratio를 55로 설정하는 프로필을 정의합니다.tuned-1.yaml이라는 파일에 다음ConfigMap매니페스트를 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고Tuned 사양의
spec.recommend섹션에 있는 항목에 라벨을 추가하지 않으면 node-pool 기반 일치로 간주되므로spec.recommend섹션에서 가장 높은 우선 순위 프로필이 풀의 노드에 적용됩니다. Tuned.spec.recommend.match섹션에서 레이블 값을 설정하여 보다 세분화된 노드 레이블 기반 일치를 수행할 수 있지만 노드 레이블은 노드 풀의.spec.management.upgradeType값을InPlace로 설정하지 않는 한 업그레이드 중에 유지되지 않습니다.관리 클러스터에
ConfigMap오브젝트를 생성합니다.oc --kubeconfig="$MGMT_KUBECONFIG" create -f tuned-1.yaml
$ oc --kubeconfig="$MGMT_KUBECONFIG" create -f tuned-1.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 노드 풀을 편집하거나 하나를 생성하여 노드 풀의
spec.tuningConfig필드에서ConfigMap오브젝트를 참조합니다. 이 예에서는 2개의 노드가 포함된nodepool-1이라는NodePool이 하나만 있다고 가정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고여러 노드 풀에서 동일한 구성 맵을 참조할 수 있습니다. 호스팅된 컨트롤 플레인에서 Node Tuning Operator는 노드 풀 이름과 네임스페이스의 해시를 Tuned CR 이름에 추가하여 구별합니다. 이 경우 동일한 호스트 클러스터에 대해 다른 Tuned CR에 동일한 이름의 여러 TuneD 프로필을 생성하지 마십시오.
검증
이제 Tuned 매니페스트가 포함된 ConfigMap 오브젝트를 생성하여 NodePool 에서 참조하므로 Node Tuning Operator가 Tuned 오브젝트를 호스팅된 클러스터에 동기화합니다. 정의된 Tuned 오브젝트와 각 노드에 적용되는 TuneD 프로필을 확인할 수 있습니다.
호스트 클러스터에서
Tuned오브젝트를 나열합니다.oc --kubeconfig="$HC_KUBECONFIG" get tuned.tuned.openshift.io \ -n openshift-cluster-node-tuning-operator
$ oc --kubeconfig="$HC_KUBECONFIG" get tuned.tuned.openshift.io \ -n openshift-cluster-node-tuning-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME AGE default 7m36s rendered 7m36s tuned-1 65s
NAME AGE default 7m36s rendered 7m36s tuned-1 65sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 호스팅된 클러스터의
Profile오브젝트를 나열합니다.oc --kubeconfig="$HC_KUBECONFIG" get profile.tuned.openshift.io \ -n openshift-cluster-node-tuning-operator
$ oc --kubeconfig="$HC_KUBECONFIG" get profile.tuned.openshift.io \ -n openshift-cluster-node-tuning-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME TUNED APPLIED DEGRADED AGE nodepool-1-worker-1 tuned-1-profile True False 7m43s nodepool-1-worker-2 tuned-1-profile True False 7m14s
NAME TUNED APPLIED DEGRADED AGE nodepool-1-worker-1 tuned-1-profile True False 7m43s nodepool-1-worker-2 tuned-1-profile True False 7m14sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고사용자 지정 프로필이 생성되지 않으면 기본적으로
openshift-node프로필이 적용됩니다.튜닝이 올바르게 적용되었는지 확인하려면 노드에서 디버그 쉘을 시작하고 sysctl 값을 확인합니다.
oc --kubeconfig="$HC_KUBECONFIG" \ debug node/nodepool-1-worker-1 -- chroot /host sysctl vm.dirty_ratio
$ oc --kubeconfig="$HC_KUBECONFIG" \ debug node/nodepool-1-worker-1 -- chroot /host sysctl vm.dirty_ratioCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
vm.dirty_ratio = 55
vm.dirty_ratio = 55Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.4. 호스트된 컨트롤 플레인을 위한 SR-IOV Operator 배포 링크 복사링크가 클립보드에 복사되었습니다!
호스팅 서비스 클러스터를 구성하고 배포한 후 호스팅된 클러스터에서 SR-IOV Operator에 대한 서브스크립션을 생성할 수 있습니다. SR-IOV Pod는 컨트롤 플레인이 아닌 작업자 머신에서 실행됩니다.
사전 요구 사항
AWS에 호스팅 클러스터를 구성하고 배포해야 합니다.
프로세스
네임스페이스 및 Operator 그룹을 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow SR-IOV Operator에 대한 서브스크립션을 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
SR-IOV Operator가 준비되었는지 확인하려면 다음 명령을 실행하고 결과 출력을 확인합니다.
oc get csv -n openshift-sriov-network-operator
$ oc get csv -n openshift-sriov-network-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME DISPLAY VERSION REPLACES PHASE sriov-network-operator.4.20.0-202211021237 SR-IOV Network Operator 4.20.0-202211021237 sriov-network-operator.4.20.0-202210290517 Succeeded
NAME DISPLAY VERSION REPLACES PHASE sriov-network-operator.4.20.0-202211021237 SR-IOV Network Operator 4.20.0-202211021237 sriov-network-operator.4.20.0-202210290517 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow SR-IOV Pod가 배포되었는지 확인하려면 다음 명령을 실행합니다.
oc get pods -n openshift-sriov-network-operator
$ oc get pods -n openshift-sriov-network-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.5. 호스팅된 클러스터의 NTP 서버 구성 링크 복사링크가 클립보드에 복사되었습니다!
Butane을 사용하여 호스팅된 클러스터에 대한 NTP(Network Time Protocol) 서버를 구성할 수 있습니다.
프로세스
chrony.conf파일의 내용을 포함하는 Butane 구성 파일99-worker-chrony.bu를 만듭니다. Butane에 대한 자세한 내용은 " Butane을 사용하여 머신 구성 생성"을 참조하십시오.99-worker-chrony.bu구성 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고머신 간 통신의 경우 UDP(User Datagram Protocol) 포트의 NTP는
123입니다. 외부 NTP 시간 서버를 구성한 경우 UDP 포트123을 열어야 합니다.Butane을 사용하여 Butane이 노드에 전송하는 구성이 포함된
MachineConfig파일99-worker-chrony.yaml을 생성합니다. 다음 명령을 실행합니다.butane 99-worker-chrony.bu -o 99-worker-chrony.yaml
$ butane 99-worker-chrony.bu -o 99-worker-chrony.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 예:
99-worker-chrony.yaml구성Copy to Clipboard Copied! Toggle word wrap Toggle overflow 관리 클러스터의 구성 맵 내에
99-worker-chrony.yaml파일의 내용을 추가합니다.구성 맵 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;namespace>를클러스터와같이 노드 풀을 생성한 네임스페이스 이름으로 바꿉니다.
다음 명령을 실행하여 노드 풀에 구성 맵을 적용합니다.
oc edit nodepool <nodepool_name> --namespace <hosted_cluster_namespace>
$ oc edit nodepool <nodepool_name> --namespace <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow NodePool구성의 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;configmap_name>을 구성 맵 이름으로 바꿉니다.
InfraEnvCR(사용자 정의 리소스)을 정의하는infra-env.yaml파일에 NTP 서버 목록을 추가합니다.infra-env.yaml파일 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;ntp_server>를 NTP 서버의 이름으로 바꿉니다. 호스트 인벤토리 및InfraEnvCR 생성에 대한 자세한 내용은 "호스트 인벤토리 생성"을 참조하십시오.
다음 명령을 실행하여
InfraEnvCR을 적용합니다.oc apply -f infra-env.yaml
$ oc apply -f infra-env.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 필드를 확인하여 호스트 인벤토리의 상태를 확인합니다.
-
conditions: 이미지가 성공적으로 생성되었는지를 나타내는 표준 Kubernetes 상태입니다. -
isoDownloadURL: Discovery Image를 다운로드할 URL입니다. createdTime: 이미지가 마지막으로 생성된 시간입니다.InfraEnvCR을 수정하는 경우 새 이미지를 다운로드하기 전에 타임스탬프를 업데이트했는지 확인합니다.다음 명령을 실행하여 호스트 인벤토리가 생성되었는지 확인합니다.
oc describe infraenv <infraenv_resource_name> -n <infraenv_namespace>
$ oc describe infraenv <infraenv_resource_name> -n <infraenv_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고InfraEnvCR을 수정하는 경우InfraEnvCR이createdTime필드를 확인하여 새 검색 이미지를 생성했는지 확인합니다. 이미 호스트를 부팅한 경우 최신 Discovery Image를 사용하여 다시 부팅합니다.
-
11.6. 호스트 클러스터에서 워크로드 확장 및 축소 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 클러스터의 워크로드를 확장하고 축소하려면 scale UpAndScaleDown 동작을 사용할 수 있습니다. 워크로드를 추가할 때 컴퓨팅 노드는 확장되고 워크로드를 삭제할 때 축소됩니다.
사전 요구 사항
-
HostedCluster및NodePool리소스를 생성했습니다.
프로세스
스케일링 동작을
ScaleUpAndScaleDown으로 설정하여 호스팅된 클러스터에 대한 클러스터 자동 스케일링을 활성화합니다. 다음 명령을 실행합니다.oc patch -n <hosted_cluster_namespace> \ hostedcluster <hosted_cluster_name> \ --type=merge \ --patch='{"spec": {"autoscaling": {"scaling": "ScaleUpAndScaleDown", "maxPodGracePeriod": 60, "scaleDown": {"utilizationThresholdPercent": 50}}}}'$ oc patch -n <hosted_cluster_namespace> \ hostedcluster <hosted_cluster_name> \ --type=merge \ --patch='{"spec": {"autoscaling": {"scaling": "ScaleUpAndScaleDown", "maxPodGracePeriod": 60, "scaleDown": {"utilizationThresholdPercent": 50}}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터 자동 스케일러가 노드 수를 관리할 수 있도록
NodePool리소스에서spec.replicas필드를 제거합니다. 다음 명령을 실행합니다.oc patch -n <hosted_cluster_namespace> \ nodepool <node_pool_name> \ --type=json \ --patch='[{"op": "remove", "path": "/spec/replicas"}]'$ oc patch -n <hosted_cluster_namespace> \ nodepool <node_pool_name> \ --type=json \ --patch='[{"op": "remove", "path": "/spec/replicas"}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터 자동 스케일링을 활성화하여 노드 풀의 최소 및 최대 노드 수를 구성합니다. 다음 명령을 실행합니다.
oc patch -n <hosted_cluster_namespace> \ nodepool <nodepool_name> \ --type=merge --patch='{"spec": {"autoScaling": {"max": 3, "min": 1}}}'$ oc patch -n <hosted_cluster_namespace> \ nodepool <nodepool_name> \ --type=merge --patch='{"spec": {"autoScaling": {"max": 3, "min": 1}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
모든 컴퓨팅 노드가
Ready상태에 있는지 확인하려면 다음 명령을 실행합니다.oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.7. 호스트 클러스터에서 워크로드 확장 링크 복사링크가 클립보드에 복사되었습니다!
호스트 클러스터의 워크로드를 확장하려면 scale UpOnly 동작을 사용할 수 있습니다.
사전 요구 사항
-
HostedCluster및NodePool리소스를 생성했습니다.
프로세스
스케일링 동작을
scaleUpOnly로 설정하여 호스팅된 클러스터에 대한 클러스터 자동 스케일링을 활성화합니다. 다음 명령을 실행합니다.oc patch -n <hosted_cluster_namespace> hostedcluster <hosted_cluster_name> --type=merge --patch='{"spec": {"autoscaling": {"scaling": "ScaleUpOnly", "maxPodGracePeriod": 60}}}'$ oc patch -n <hosted_cluster_namespace> hostedcluster <hosted_cluster_name> --type=merge --patch='{"spec": {"autoscaling": {"scaling": "ScaleUpOnly", "maxPodGracePeriod": 60}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터 자동 스케일러가 노드 수를 관리할 수 있도록
NodePool리소스에서spec.replicas필드를 제거합니다. 다음 명령을 실행합니다.oc patch -n clusters nodepool <node_pool_name> --type=json --patch='[{"op": "remove", "path": "/spec/replicas"}]'$ oc patch -n clusters nodepool <node_pool_name> --type=json --patch='[{"op": "remove", "path": "/spec/replicas"}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터 자동 스케일링을 활성화하여 노드 풀의 최소 및 최대 노드 수를 구성합니다. 다음 명령을 실행합니다.
oc patch -n <hosted_cluster_namespace> nodepool <nodepool_name> --type=merge --patch='{"spec": {"autoScaling": {"max": 3, "min": 1}}}'$ oc patch -n <hosted_cluster_namespace> nodepool <nodepool_name> --type=merge --patch='{"spec": {"autoScaling": {"max": 3, "min": 1}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 실행하여 모든 컴퓨팅 노드가
Ready상태에 있는지 확인합니다.oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 노드 풀의 노드 수를 확인하여 컴퓨팅 노드가 성공적으로 확장되었는지 확인합니다. 다음 명령을 실행합니다.
oc --kubeconfig nested.config get nodes -l 'hypershift.openshift.io/nodePool=<node_pool_name>'
$ oc --kubeconfig nested.config get nodes -l 'hypershift.openshift.io/nodePool=<node_pool_name>'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.8. 호스트 클러스터에서 우선순위 확장기 설정 링크 복사링크가 클립보드에 복사되었습니다!
호스트된 클러스터의 우선순위를 사용하여 노드 풀의 우선 순위를 정의하고 우선 순위가 낮은 머신보다 우선 순위가 높은 머신을 생성할 수 있습니다.
사전 요구 사항
-
HostedCluster및NodePool리소스를 생성했습니다.
프로세스
노드 풀의 우선 순위를 정의하려면 호스팅된 클러스터에
priority-expander-configmap.yaml이라는 구성 맵을 생성합니다. 숫자가 낮은 노드 풀은 높은 우선 순위를 갖습니다. 다음 예제 구성을 참조하십시오.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
kubeconfig파일을 생성합니다.hcp create kubeconfig --name <hosted_cluster_name> --namespace <hosted_cluster_namespace> > nested.config
$ hcp create kubeconfig --name <hosted_cluster_name> --namespace <hosted_cluster_namespace> > nested.configCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
ConfigMap오브젝트를 생성합니다.oc --kubeconfig nested.config create -f priority-expander-configmap.yaml
$ oc --kubeconfig nested.config create -f priority-expander-configmap.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 호스팅된 클러스터의 우선 순위 확장기를 설정하여 클러스터 자동 스케일링을 활성화합니다. 다음 명령을 실행합니다.
oc patch -n <hosted_cluster_namespace> \ hostedcluster <hosted_cluster_name> \ --type=merge \ --patch='{"spec": {"autoscaling": {"scaling": "ScaleUpOnly", "maxPodGracePeriod": 60, "expanders": ["Priority"]}}}'$ oc patch -n <hosted_cluster_namespace> \ hostedcluster <hosted_cluster_name> \ --type=merge \ --patch='{"spec": {"autoscaling": {"scaling": "ScaleUpOnly", "maxPodGracePeriod": 60, "expanders": ["Priority"]}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터 자동 스케일러가 노드 수를 관리할 수 있도록
NodePool리소스에서spec.replicas필드를 제거합니다. 다음 명령을 실행합니다.oc patch -n <hosted_cluster_namespace> \ nodepool <node_pool_name> \ --type=json --patch='[{"op": "remove", "path": "/spec/replicas"}]'$ oc patch -n <hosted_cluster_namespace> \ nodepool <node_pool_name> \ --type=json --patch='[{"op": "remove", "path": "/spec/replicas"}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터 자동 스케일링을 활성화하여 노드 풀의 최소 및 최대 노드 수를 구성합니다. 다음 명령을 실행합니다.
oc patch -n <hosted_cluster_namespace> \ nodepool <nodepool_name> \ --type=merge --patch='{"spec": {"autoScaling": {"max": 3, "min": 1}}}'$ oc patch -n <hosted_cluster_namespace> \ nodepool <nodepool_name> \ --type=merge --patch='{"spec": {"autoScaling": {"max": 3, "min": 1}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
새 워크로드를 적용한 후 우선순위 노드 풀과 연결된 컴퓨팅 노드가 먼저 확장되었는지 확인합니다. 다음 명령을 실행하여 컴퓨팅 노드의 상태를 확인합니다.
oc --kubeconfig nested.config get nodes -l 'hypershift.openshift.io/nodePool=<node_pool_name>'
$ oc --kubeconfig nested.config get nodes -l 'hypershift.openshift.io/nodePool=<node_pool_name>'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.9. 호스트 클러스터에서 무시된 라벨의 균형 조정 링크 복사링크가 클립보드에 복사되었습니다!
노드 풀을 확장한 후 balancingIgnoredLabels 를 사용하여 노드 풀에 머신을 균등하게 배포할 수 있습니다.
사전 요구 사항
-
HostedCluster및NodePool리소스를 생성했습니다.
프로세스
동일한 라벨 값을 사용하여 각 관련 노드 풀에
node.group.balancing.ignored레이블을 추가합니다. 다음 명령을 실행합니다.oc patch -n <hosted_cluster_namespace> \ nodepool <node_pool_name> \ --type=merge \ --patch='{"spec": {"nodeLabels": {"node.group.balancing.ignored": "<label_name>"}}}'$ oc patch -n <hosted_cluster_namespace> \ nodepool <node_pool_name> \ --type=merge \ --patch='{"spec": {"nodeLabels": {"node.group.balancing.ignored": "<label_name>"}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 호스팅된 클러스터에 대한 클러스터 자동 스케일링을 활성화합니다.
oc patch -n <hosted_cluster_namespace> \ hostedcluster <hosted_cluster_name> \ --type=merge \ --patch='{"spec": {"autoscaling": {"balancingIgnoredLabels": ["node.group.balancing.ignored"]}}}'$ oc patch -n <hosted_cluster_namespace> \ hostedcluster <hosted_cluster_name> \ --type=merge \ --patch='{"spec": {"autoscaling": {"balancingIgnoredLabels": ["node.group.balancing.ignored"]}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터 자동 스케일러가 노드 수를 관리할 수 있도록
NodePool리소스에서spec.replicas필드를 제거합니다. 다음 명령을 실행합니다.oc patch -n <hosted_cluster_namespace> \ nodepool <node_pool_name> \ --type=json \ --patch='[{"op": "remove", "path": "/spec/replicas"}]'$ oc patch -n <hosted_cluster_namespace> \ nodepool <node_pool_name> \ --type=json \ --patch='[{"op": "remove", "path": "/spec/replicas"}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터 자동 스케일링을 활성화하여 노드 풀의 최소 및 최대 노드 수를 구성합니다. 다음 명령을 실행합니다.
oc patch -n <hosted_cluster_namespace> \ nodepool <nodepool_name> \ --type=merge --patch='{"spec": {"autoScaling": {"max": 3, "min": 1}}}'$ oc patch -n <hosted_cluster_namespace> \ nodepool <nodepool_name> \ --type=merge --patch='{"spec": {"autoScaling": {"max": 3, "min": 1}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
kubeconfig파일을 생성합니다.hcp create kubeconfig \ --name <hosted_cluster_name> \ --namespace <hosted_cluster_namespace> > nested.config
$ hcp create kubeconfig \ --name <hosted_cluster_name> \ --namespace <hosted_cluster_namespace> > nested.configCopy to Clipboard Copied! Toggle word wrap Toggle overflow 노드 풀을 확장한 후 다음 명령을 실행하여 모든 컴퓨팅 노드가
Ready상태에 있는지 확인합니다.oc --kubeconfig nested.config get nodes -l 'hypershift.openshift.io/nodePool=<node_pool_name>'
$ oc --kubeconfig nested.config get nodes -l 'hypershift.openshift.io/nodePool=<node_pool_name>'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 새 노드에
node.group.balancing.ignored라벨이 포함되어 있는지 확인합니다.oc --kubeconfig nested.config get nodes \ -l 'hypershift.openshift.io/nodePool=<node_pool_name>' \ -o jsonpath='{.items[*].metadata.labels}' | grep "node.group.balancing.ignored"$ oc --kubeconfig nested.config get nodes \ -l 'hypershift.openshift.io/nodePool=<node_pool_name>' \ -o jsonpath='{.items[*].metadata.labels}' | grep "node.group.balancing.ignored"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 호스팅된 클러스터에 대한 클러스터 자동 스케일링을 활성화합니다.
oc patch -n <hosted_cluster_namespace> \ hostedcluster <hosted_cluster_name> \ --type=merge \ --patch='{"spec": {"autoscaling": {"balancingIgnoredLabels": ["node.group.balancing.ignored"]}}}'$ oc patch -n <hosted_cluster_namespace> \ hostedcluster <hosted_cluster_name> \ --type=merge \ --patch='{"spec": {"autoscaling": {"balancingIgnoredLabels": ["node.group.balancing.ignored"]}}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
각 노드 풀에서 프로비저닝한 노드 수가 균등하게 분배되었는지 확인합니다. 예를 들어 레이블 값이 동일한 노드 풀을 세 개 생성한 경우 노드 수는 3, 2, 3일 수 있습니다. 다음 명령을 실행합니다.
oc --kubeconfig nested.config get nodes -l 'hypershift.openshift.io/nodePool=<node_pool_name>'
$ oc --kubeconfig nested.config get nodes -l 'hypershift.openshift.io/nodePool=<node_pool_name>'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12장. 호스트 클러스터에서 기능 게이트 사용 링크 복사링크가 클립보드에 복사되었습니다!
호스트 클러스터에서 기능 게이트를 사용하여 기본 기능 세트의 일부가 아닌 기능을 활성화할 수 있습니다. 호스팅된 클러스터에서 기능 게이트를 사용하여 TechPreviewNoUpgrade 기능을 활성화할 수 있습니다.
12.1. 기능 게이트를 사용하여 기능 세트 활성화 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift CLI로 HostedCluster CR(사용자 정의 리소스)을 편집하여 호스트 클러스터에서 TechPreviewNoUpgrade 기능을 활성화할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다.
프로세스
다음 명령을 실행하여 호스팅 클러스터에서 편집할
HostedClusterCR을 엽니다.oc edit hostedcluster <hosted_cluster_name> -n <hosted_cluster_namespace>
$ oc edit hostedcluster <hosted_cluster_name> -n <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow featureSet필드에 값을 입력하여 기능 세트를 정의합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 주의클러스터에서
TechPreviewNoUpgrade기능 세트를 활성화하면 취소할 수 없으며 마이너 버전 업데이트를 방지할 수 없습니다. 이 기능 세트를 사용하면 테스트 클러스터에서 이러한 기술 프리뷰 기능을 완전히 테스트할 수 있습니다. 프로덕션 클러스터에서 이 기능 세트를 활성화하지 마십시오.- 파일을 저장하여 변경 사항을 적용합니다.
검증
다음 명령을 실행하여 호스트 클러스터에서
TechPreviewNoUpgrade기능 게이트가 활성화되어 있는지 확인합니다.oc get featuregate cluster -o yaml
$ oc get featuregate cluster -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
13장. 호스트된 컨트롤 플레인에 대한 가시성 링크 복사링크가 클립보드에 복사되었습니다!
메트릭 세트를 구성하여 호스팅되는 컨트롤 플레인의 메트릭을 수집할 수 있습니다. HyperShift Operator는 관리하는 각 호스팅 클러스터의 관리 클러스터에서 모니터링 대시보드를 생성하거나 삭제할 수 있습니다.
13.1. 호스팅된 컨트롤 플레인에 대한 메트릭 세트 구성 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat OpenShift Container Platform의 호스트된 컨트롤 플레인은 각 컨트롤 플레인 네임스페이스에서 ServiceMonitor 리소스를 생성하여 Prometheus 스택이 컨트롤 플레인에서 지표를 수집할 수 있습니다. ServiceMonitor 리소스는 메트릭 재레이블을 사용하여 etcd 또는 Kubernetes API 서버와 같은 특정 구성 요소에서 포함되거나 제외되는 메트릭을 정의합니다. 컨트롤 플레인에서 생성하는 메트릭 수는 이를 수집하는 모니터링 스택의 리소스 요구 사항에 직접적인 영향을 미칩니다.
모든 상황에 적용되는 고정된 수의 메트릭을 생성하는 대신 각 컨트롤 플레인에 생성할 메트릭 세트를 식별하는 메트릭 세트를 구성할 수 있습니다. 다음 메트릭 세트가 지원됩니다.
-
Telemetry: 이러한 메트릭은 Telemetry에 필요합니다. 이 세트는 기본 세트이며 가장 작은 메트릭 세트입니다. -
SRE:이 세트에는 경고를 생성하고 컨트롤 플레인 구성 요소의 문제 해결을 허용하는 데 필요한 메트릭이 포함되어 있습니다. -
All: 이 세트에는 독립 실행형 OpenShift Container Platform 컨트롤 플레인 구성 요소에서 생성하는 모든 메트릭이 포함됩니다.
메트릭 세트를 구성하려면 다음 명령을 입력하여 HyperShift Operator 배포에서 METRICS_SET 환경 변수를 설정합니다.
oc set env -n hypershift deployment/operator METRICS_SET=All
$ oc set env -n hypershift deployment/operator METRICS_SET=All
13.1.1. SRE 메트릭 세트 구성 링크 복사링크가 클립보드에 복사되었습니다!
SRE 메트릭 세트를 지정하면 HyperShift Operator는 단일 key: config 를 사용하여 sre-metric-set 이라는 구성 맵을 찾습니다. config 키 값에는 컨트롤 플레인 구성 요소로 구성된 RelabelConfigs 세트가 포함되어야 합니다.
다음 구성 요소를 지정할 수 있습니다.
-
etcd -
kubeAPIServer -
kubeControllerManager -
openshiftAPIServer -
openshiftControllerManager -
openshiftRouteControllerManager -
cvo -
olm -
catalogOperator -
registryOperator -
nodeTuningOperator -
controlPlaneOperator -
hostedClusterConfigOperator
다음 예에는 SRE 메트릭 세트 구성이 설명되어 있습니다.
13.2. 호스트 클러스터에서 모니터링 대시보드 활성화 링크 복사링크가 클립보드에 복사되었습니다!
구성 맵을 생성하여 호스트 클러스터에서 모니터링 대시보드를 활성화할 수 있습니다.
프로세스
local-cluster네임스페이스에hypershift-operator-install-flags구성 맵을 생성합니다. 다음 예제 구성을 참조하십시오.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
--monitoring-dashboards --metrics-set=All플래그는 모든 메트릭에 대한 모니터링 대시보드를 추가합니다.
다음 환경 변수를 포함하도록
hypershift네임스페이스에서 HyperShift Operator 배포를 업데이트할 때까지 몇 분 정도 기다립니다.- name: MONITORING_DASHBOARDS value: "1"- name: MONITORING_DASHBOARDS value: "1"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 모니터링 대시보드가 활성화된 경우 HyperShift Operator가 관리하는 각 호스팅 클러스터에 대해 Operator는
openshift-config-managed네임스페이스에cp-<hosted_cluster_namespace>-<hosted_cluster_name>이라는 구성 맵을 생성합니다. 여기서 <hosted_cluster_namespace>는 호스팅된 클러스터의 네임스페이스이고 <hosted_cluster_name>은 호스트된 클러스터의 이름입니다. 결과적으로 관리 클러스터의 관리 콘솔에 새 대시보드가 추가됩니다.- 대시보드를 보려면 관리 클러스터 콘솔에 로그인하고 모니터링 → 대시보드를 클릭하여 호스트 클러스터의 대시보드로 이동합니다.
-
선택 사항: 호스트 클러스터에서 모니터링 대시보드를 비활성화하려면
hypershift-operator-install-flags구성 맵에서--monitoring-dashboards --metrics-set=All플래그를 제거합니다. 호스트 클러스터를 삭제하면 해당 대시보드도 삭제됩니다.
13.2.1. 대시보드 사용자 정의 링크 복사링크가 클립보드에 복사되었습니다!
HyperShift Operator는 호스트된 각 클러스터에 대한 대시보드를 생성하기 위해 Operator 네임스페이스(hypershift)의 monitoring-dashboard-template 구성 맵에 저장된 템플릿을 사용합니다. 이 템플릿에는 대시보드에 대한 메트릭이 포함된 Grafana 패널 세트가 포함되어 있습니다. 구성 맵의 콘텐츠를 편집하여 대시보드를 사용자 지정할 수 있습니다.
대시보드가 생성되면 다음 문자열이 특정 호스팅 클러스터에 해당하는 값으로 교체됩니다.
| 이름 | 설명 |
|---|---|
|
| 호스트된 클러스터의 이름 |
|
| 호스팅된 클러스터의 네임스페이스 |
|
| 호스팅된 클러스터의 컨트롤 플레인 Pod가 배치되는 네임스페이스 |
|
|
호스팅된 클러스터 메트릭의 |
14장. 호스트된 컨트롤 플레인 네트워킹 링크 복사링크가 클립보드에 복사되었습니다!
독립 실행형 OpenShift Container Platform의 경우 프록시 지원은 기본적으로 클러스터의 워크로드가 HTTP 또는 HTTPS 프록시를 사용하여 외부 서비스에 액세스하도록 구성되어 있는지 확인하고, 구성된 경우 NO_PROXY 설정을 준수하고 프록시용으로 구성된 신뢰 번들을 수락하는 것입니다.
호스팅된 컨트롤 플레인의 경우 프록시 지원에 다음과 같은 추가 사용 사례가 포함됩니다.
14.1. 외부 서비스에 액세스해야 하는 컨트롤 플레인 워크로드 링크 복사링크가 클립보드에 복사되었습니다!
컨트롤 플레인에서 실행되는 Operator는 호스팅된 클러스터에 대해 구성된 프록시를 통해 외부 서비스에 액세스해야 합니다. 프록시는 일반적으로 데이터 플레인을 통해서만 액세스할 수 있습니다. 컨트롤 플레인 워크로드는 다음과 같습니다.
- Control Plane Operator는 OAuth 서버 구성을 생성할 때 특정 ID 공급자에서 끝점을 검증하고 가져와야 합니다.
- OAuth 서버에는 LDAP가 아닌 ID 공급자 액세스 권한이 필요합니다.
- OpenShift API 서버는 이미지 레지스트리 메타데이터 가져오기를 처리합니다.
- Ingress Operator는 외부 카나리아 경로를 검증하려면 액세스할 수 있어야 합니다.
-
DNS(Domain Name Service) 프로토콜이 예상대로 작동하도록 하려면 TCP(Transmission Control Protocol) 및 UDP(User Datagram Protocol)에서 방화벽 포트
53을 열어야 합니다.
호스팅된 클러스터에서는 컨트롤 플레인 Operator, Ingress Operator, OAuth 서버 및 OpenShift API 서버 Pod에서 시작된 트래픽을 데이터 플레인을 통해 구성된 프록시로 보낸 다음 최종 대상으로 보내야 합니다.
예를 들어 프록시 액세스가 필요한 레지스트리에서 OpenShift 이미지 스트림을 가져오는 경우와 같이 호스팅된 클러스터가 제로 컴퓨팅 노드로 감소하면 일부 작업을 수행할 수 없습니다.
14.2. Ignition 엔드포인트에 액세스해야 하는 컴퓨팅 노드 링크 복사링크가 클립보드에 복사되었습니다!
컴퓨팅 노드에 ignition 엔드포인트에 액세스하는 데 프록시가 필요한 경우 컴퓨팅 노드에 구성된 user-data stub에서 프록시를 구성해야 합니다. 시스템이 Ignition URL에 액세스하는 데 프록시가 필요한 경우 프록시 구성이 스텁에 포함됩니다.
스텁은 다음 예와 유사합니다.
---
{"ignition":{"config":{"merge":[{"httpHeaders":[{"name":"Authorization","value":"Bearer ..."},{"name":"TargetConfigVersionHash","value":"a4c1b0dd"}],"source":"https://ignition.controlplanehost.example.com/ignition","verification":{}}],"replace":{"verification":{}}},"proxy":{"httpProxy":"http://proxy.example.org:3128", "httpsProxy":"https://proxy.example.org:3129", "noProxy":"host.example.org"},"security":{"tls":{"certificateAuthorities":[{"source":"...","verification":{}}]}},"timeouts":{},"version":"3.2.0"},"passwd":{},"storage":{},"systemd":{}}
---
---
{"ignition":{"config":{"merge":[{"httpHeaders":[{"name":"Authorization","value":"Bearer ..."},{"name":"TargetConfigVersionHash","value":"a4c1b0dd"}],"source":"https://ignition.controlplanehost.example.com/ignition","verification":{}}],"replace":{"verification":{}}},"proxy":{"httpProxy":"http://proxy.example.org:3128", "httpsProxy":"https://proxy.example.org:3129", "noProxy":"host.example.org"},"security":{"tls":{"certificateAuthorities":[{"source":"...","verification":{}}]}},"timeouts":{},"version":"3.2.0"},"passwd":{},"storage":{},"systemd":{}}
---
14.3. API 서버에 액세스해야 하는 컴퓨팅 노드 링크 복사링크가 클립보드에 복사되었습니다!
이 사용 사례는 호스팅되는 컨트롤 플레인이 있는 AWS의 Red Hat OpenShift Service가 아닌 자체 관리형 호스팅 컨트롤 플레인과 관련이 있습니다.
컨트롤 플레인과의 통신을 위해 호스팅되는 컨트롤 플레인은 IP 주소 172.20.0.1에서 수신 대기하는 모든 컴퓨팅 노드의 로컬 프록시를 사용하고 트래픽을 API 서버로 전달합니다. API 서버에 액세스하는 데 외부 프록시가 필요한 경우 해당 로컬 프록시에서 외부 프록시를 사용하여 트래픽을 보내야 합니다. 프록시가 필요하지 않은 경우 호스팅되는 컨트롤 플레인은 TCP를 통해서만 패킷을 전달하는 로컬 프록시에 haproxy 를 사용합니다. 프록시가 필요한 경우 호스팅되는 컨트롤 플레인은 사용자 정의 프록시, control-plane-operator-kubernetes-default-proxy 를 사용하여 외부 프록시를 통해 트래픽을 보냅니다.
14.4. 외부 액세스가 필요한 관리 클러스터 링크 복사링크가 클립보드에 복사되었습니다!
HyperShift Operator에는 관리 클러스터의 OpenShift 글로벌 프록시 구성을 모니터링하고 자체 배포에서 프록시 환경 변수를 설정하는 컨트롤러가 있습니다. 외부 액세스가 필요한 컨트롤 플레인 배포는 관리 클러스터의 프록시 환경 변수를 사용하여 구성됩니다.
14.5. 보조 네트워크가 있고 기본 pod 네트워크가 없는 프록시 및 호스팅 클러스터를 사용하는 관리 클러스터 링크 복사링크가 클립보드에 복사되었습니다!
관리 클러스터가 프록시 구성을 사용하고 보조 네트워크를 사용하여 호스팅된 클러스터를 구성하지만 기본 pod 네트워크를 연결하지 않는 경우 보조 네트워크의 CIDR을 프록시 구성에 추가합니다. 특히 관리 클러스터의 프록시 구성의 noProxy 섹션에 보조 네트워크의 CIDR을 추가해야 합니다. 그렇지 않으면 Kubernetes API 서버가 프록시를 통해 일부 API 요청을 라우팅합니다. 호스팅된 클러스터 구성에서 보조 네트워크의 CIDR이 noProxy 섹션에 자동으로 추가됩니다.
15장. 호스트된 컨트롤 플레인 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
호스트된 컨트롤 플레인에 문제가 있는 경우 다음 정보를 참조하여 문제 해결을 안내하십시오.
15.1. 호스트된 컨트롤 플레인 문제를 해결하기 위한 정보 수집 링크 복사링크가 클립보드에 복사되었습니다!
호스트 클러스터 관련 문제를 해결해야 하는 경우 must-gather 명령을 실행하여 정보를 수집할 수 있습니다. 명령은 관리 클러스터 및 호스팅 클러스터에 대한 출력을 생성합니다.
관리 클러스터의 출력에는 다음 내용이 포함됩니다.
- 클러스터 범위 리소스: 이러한 리소스는 관리 클러스터의 노드 정의입니다.
-
hypershift-dump압축 파일: 이 파일은 다른 사용자와 콘텐츠를 공유해야 하는 경우에 유용합니다. - 네임스페이스 리소스: 이러한 리소스에는 구성 맵, 서비스, 이벤트 및 로그와 같은 관련 네임스페이스의 모든 오브젝트가 포함됩니다.
- 네트워크 로그: 이 로그에는 OVN northbound 및 southbound 데이터베이스와 각각에 대한 상태가 포함됩니다.
- 호스트 클러스터: 이 수준의 출력에는 호스팅된 클러스터 내부의 모든 리소스가 포함됩니다.
호스팅 클러스터의 출력에는 다음 내용이 포함됩니다.
- 클러스터 범위 리소스: 이러한 리소스에는 노드 및 CRD와 같은 모든 클러스터 전체 오브젝트가 포함됩니다.
- 네임스페이스 리소스: 이러한 리소스에는 구성 맵, 서비스, 이벤트 및 로그와 같은 관련 네임스페이스의 모든 오브젝트가 포함됩니다.
출력에 클러스터의 보안 오브젝트가 포함되어 있지 않지만 보안 이름에 대한 참조를 포함할 수 있습니다.
사전 요구 사항
-
관리 클러스터에 대한
cluster-admin액세스 권한이 있어야 합니다. -
HostedCluster리소스의name값과 CR이 배포된 네임스페이스가 필요합니다. -
hcp명령줄 인터페이스가 설치되어 있어야 합니다. 자세한 내용은 "호스팅된 컨트롤 플레인 명령줄 인터페이스 설치"를 참조하십시오. -
OpenShift CLI(
oc)가 설치되어 있어야 합니다. -
kubeconfig파일이 로드되고 관리 클러스터를 가리키는지 확인해야 합니다.
프로세스
문제 해결을 위해 출력을 수집하려면 다음 명령을 입력합니다.
oc adm must-gather \ --image=registry.redhat.io/multicluster-engine/must-gather-rhel9:v<mce_version> \ /usr/bin/gather hosted-cluster-namespace=HOSTEDCLUSTERNAMESPACE \ hosted-cluster-name=HOSTEDCLUSTERNAME \ --dest-dir=NAME ; tar -cvzf NAME.tgz NAME
$ oc adm must-gather \ --image=registry.redhat.io/multicluster-engine/must-gather-rhel9:v<mce_version> \ /usr/bin/gather hosted-cluster-namespace=HOSTEDCLUSTERNAMESPACE \ hosted-cluster-name=HOSTEDCLUSTERNAME \ --dest-dir=NAME ; tar -cvzf NAME.tgz NAMECopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
-
<
;mce_version>을 사용 중인 다중 클러스터 엔진 Operator 버전(예:2.6)으로 바꿉니다. -
hosted-cluster-namespace=HOSTEDCLUSTERNAMESPACE매개변수는 선택 사항입니다. 이를 포함하지 않으면 호스트 클러스터가 기본 네임스페이스인 클러스터인 것처럼 명령이실행됩니다. -
명령 결과를 압축 파일에 저장하려면
--dest-dir=NAME매개변수를 지정하고NAME을 결과를 저장하려는 디렉터리의 이름으로 교체합니다.
-
<
15.2. 호스트된 클러스터에 대한 OpenShift Container Platform 데이터 수집 링크 복사링크가 클립보드에 복사되었습니다!
멀티 클러스터 엔진 Operator 웹 콘솔을 사용하거나 CLI를 사용하여 호스팅된 클러스터에 대한 OpenShift Container Platform 디버깅 정보를 수집할 수 있습니다.
15.2.1. CLI를 사용하여 호스트된 클러스터의 데이터 수집 링크 복사링크가 클립보드에 복사되었습니다!
CLI를 사용하여 호스팅된 클러스터에 대한 OpenShift Container Platform 디버깅 정보를 수집할 수 있습니다.
사전 요구 사항
-
관리 클러스터에 대한
cluster-admin액세스 권한이 있어야 합니다. -
HostedCluster리소스의name값과 CR이 배포된 네임스페이스가 필요합니다. -
hcp명령줄 인터페이스가 설치되어 있어야 합니다. 자세한 내용은 "호스팅된 컨트롤 플레인 명령줄 인터페이스 설치"를 참조하십시오. -
OpenShift CLI(
oc)가 설치되어 있어야 합니다. -
kubeconfig파일이 로드되고 관리 클러스터를 가리키는지 확인해야 합니다.
프로세스
다음 명령을 입력하여
kubeconfig파일을 생성합니다.hcp create kubeconfig --namespace <hosted_cluster_namespace> \ --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
$ hcp create kubeconfig --namespace <hosted_cluster_namespace> \ --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow kubeconfig파일을 저장한 후 다음 예제 명령을 입력하여 호스팅된 클러스터에 액세스할 수 있습니다.oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow . 다음 명령을 입력하여 must-gather 정보를 수집합니다.
oc adm must-gather
$ oc adm must-gatherCopy to Clipboard Copied! Toggle word wrap Toggle overflow
15.2.2. 웹 콘솔을 사용하여 호스트된 클러스터의 데이터 수집 링크 복사링크가 클립보드에 복사되었습니다!
다중 클러스터 엔진 Operator 웹 콘솔을 사용하여 호스트된 클러스터에 대한 OpenShift Container Platform 디버깅 정보를 수집할 수 있습니다.
사전 요구 사항
-
관리 클러스터에 대한
cluster-admin액세스 권한이 있어야 합니다. -
HostedCluster리소스의name값과 CR이 배포된 네임스페이스가 필요합니다. -
hcp명령줄 인터페이스가 설치되어 있어야 합니다. 자세한 내용은 "호스팅된 컨트롤 플레인 명령줄 인터페이스 설치"를 참조하십시오. -
OpenShift CLI(
oc)가 설치되어 있어야 합니다. -
kubeconfig파일이 로드되고 관리 클러스터를 가리키는지 확인해야 합니다.
프로세스
- 웹 콘솔에서 모든 클러스터를 선택하고 문제를 해결할 클러스터를 선택합니다.
- 오른쪽 상단에서 Download kubeconfig 를 선택합니다.
-
다운로드한
kubeconfig파일을 내보냅니다. 다음 명령을 입력하여 must-gather 정보를 수집합니다.
oc adm must-gather
$ oc adm must-gatherCopy to Clipboard Copied! Toggle word wrap Toggle overflow
15.3. 연결이 끊긴 환경에서 must-gather 명령 입력 링크 복사링크가 클립보드에 복사되었습니다!
연결이 끊긴 환경에서 must-gather 명령을 실행하려면 다음 단계를 완료합니다.
프로세스
- 연결이 끊긴 환경에서 Red Hat Operator 카탈로그 이미지를 미러 레지스트리에 미러링합니다. 자세한 내용은 연결이 끊긴 네트워크에 설치를 참조하십시오.
다음 명령을 실행하여 미러 레지스트리에서 이미지를 참조하는 로그를 추출합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.4. OpenShift Virtualization에서 호스트된 클러스터 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Virtualization에서 호스트된 클러스터의 문제를 해결할 때 최상위 HostedCluster 및 NodePool 리소스로 시작한 다음 근본 원인을 찾을 때까지 스택을 축소합니다. 다음 단계는 일반적인 문제의 근본 원인을 찾는 데 도움이 될 수 있습니다.
15.4.1. HostedCluster 리소스가 부분적인 상태로 유지됨 링크 복사링크가 클립보드에 복사되었습니다!
HostedCluster 리소스가 보류 중이므로 호스트 컨트롤 플레인이 완전히 온라인 상태가 아닌 경우 사전 요구 사항, 리소스 조건 및 노드 및 Operator 상태를 확인하여 문제를 식별합니다.
프로세스
- OpenShift Virtualization에서 호스트된 클러스터의 모든 사전 요구 사항을 충족하는지 확인합니다.
-
진행을 방지하는 검증 오류는
HostedCluster및NodePool리소스의 조건을 확인합니다. 호스팅 클러스터의
kubeconfig파일을 사용하여 호스트 클러스터의 상태를 검사합니다.-
oc get clusteroperators명령의 출력을 보고 보류 중인 클러스터 Operator를 확인합니다. -
oc get nodes명령의 출력을 보고 작업자 노드가 준비되었는지 확인합니다.
-
15.4.2. 등록된 작업자 노드 없음 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 컨트롤 플레인에 작업자 노드가 등록되지 않았기 때문에 호스팅된 컨트롤 플레인이 완전히 온라인 상태가 아닌 경우 호스트 컨트롤 플레인의 다양한 부분의 상태를 확인하여 문제를 확인합니다.
프로세스
-
문제가 발생할 수 있음을 나타내는 실패의
HostedCluster및NodePool조건을 확인합니다. 다음 명령을 입력하여
NodePool리소스의 KubeVirt 작업자 노드 VM(가상 머신) 상태를 확인합니다.oc get vm -n <namespace>
$ oc get vm -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow VM이 프로비저닝 상태에 있는 경우 다음 명령을 입력하여 가져오기 Pod가 완료되지 않은 이유에 대한 이해를 위해 VM 네임스페이스 내에서 CDI 가져오기 Pod를 확인합니다.
oc get pods -n <namespace> | grep "import"
$ oc get pods -n <namespace> | grep "import"Copy to Clipboard Copied! Toggle word wrap Toggle overflow VM이 시작 상태에 있는 경우 다음 명령을 입력하여 virt-launcher Pod의 상태를 확인합니다.
oc get pods -n <namespace> -l kubevirt.io=virt-launcher
$ oc get pods -n <namespace> -l kubevirt.io=virt-launcherCopy to Clipboard Copied! Toggle word wrap Toggle overflow virt-launcher Pod가 보류 중 상태인 경우 Pod가 예약되지 않은 이유를 조사합니다. 예를 들어 virt-launcher Pod를 실행하는 데 리소스가 부족할 수 있습니다.
- VM이 실행 중이지만 작업자 노드로 등록되지 않은 경우 웹 콘솔을 사용하여 영향을 받는 VM 중 하나에 대한 VNC 액세스를 얻습니다. VNC 출력은 Ignition 구성이 적용되었는지 여부를 나타냅니다. VM이 시작 시 호스팅된 컨트롤 플레인 ignition 서버에 액세스할 수 없는 경우 VM을 올바르게 프로비저닝할 수 없습니다.
- Ignition 구성이 적용되지만 VM이 여전히 노드로 등록되지 않은 경우 문제 식별을 참조하십시오. 시작 중에 VM 콘솔 로그에 액세스하는 방법을 알아보려면 VM 콘솔 로그에 액세스합니다.
15.4.3. 작업자 노드는 NotReady 상태에 있습니다. 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 생성 중에 네트워킹 스택이 롤아웃되는 동안 노드가 일시적으로 NotReady 상태로 들어갑니다. 이 과정의 일부는 정상입니다. 그러나 프로세스의 이 부분이 15분 이상 걸리는 경우 노드 오브젝트 및 Pod를 조사하여 문제를 식별합니다.
프로세스
다음 명령을 입력하여 노드 오브젝트의 조건을 확인하고 노드가 준비되지 않은 이유를 확인합니다.
oc get nodes -o yaml
$ oc get nodes -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 입력하여 클러스터 내에서 실패한 Pod를 찾습니다.
oc get pods -A --field-selector=status.phase!=Running,status,phase!=Succeeded
$ oc get pods -A --field-selector=status.phase!=Running,status,phase!=SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow
15.4.4. Ingress 및 콘솔 클러스터 Operator는 온라인 상태가 아닙니다. 링크 복사링크가 클립보드에 복사되었습니다!
Ingress 및 콘솔 클러스터 Operator가 온라인 상태가 아니므로 호스팅 컨트롤 플레인이 완전히 온라인 상태가 아닌 경우 와일드카드 DNS 경로 및 로드 밸런서를 확인합니다.
프로세스
클러스터에서 기본 Ingress 동작을 사용하는 경우 다음 명령을 입력하여 가상 머신(VM)이 호스팅되는 OpenShift Container Platform 클러스터에서 와일드카드 DNS 경로가 활성화되어 있는지 확인합니다.
oc patch ingresscontroller -n openshift-ingress-operator \ default --type=json -p \ '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'$ oc patch ingresscontroller -n openshift-ingress-operator \ default --type=json -p \ '[{ "op": "add", "path": "/spec/routeAdmission", "value": {wildcardPolicy: "WildcardsAllowed"}}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 호스팅된 컨트롤 플레인에 사용자 정의 기본 도메인을 사용하는 경우 다음 단계를 완료합니다.
- 로드 밸런서가 VM pod를 올바르게 대상으로 지정 중인지 확인합니다.
- 와일드카드 DNS 항목이 로드 밸런서 IP 주소를 대상으로 하는지 확인합니다.
15.4.5. 호스팅된 클러스터의 로드 밸런서 서비스를 사용할 수 없음 링크 복사링크가 클립보드에 복사되었습니다!
로드 밸런서 서비스를 사용할 수 없기 때문에 호스팅되는 컨트롤 플레인이 완전히 온라인 상태가 되지 않는 경우 이벤트, 세부 정보 및 Kubernetes Cluster Configuration Manager(KCCM) Pod를 확인합니다.
프로세스
- 호스팅된 클러스터 내에서 로드 밸런서 서비스와 연결된 이벤트 및 세부 정보를 찾습니다.
기본적으로 호스팅된 클러스터의 로드 밸런서는 호스팅된 컨트롤 플레인 네임스페이스 내의 kubevirt-cloud-controller-manager에 의해 처리됩니다. KCCM Pod가 온라인 상태인지 확인하고 오류 또는 경고에 대한 로그를 확인합니다. 호스팅된 컨트롤 플레인 네임스페이스에서 KCCM Pod를 식별하려면 다음 명령을 입력합니다.
oc get pods -n <hosted_control_plane_namespace> \ -l app=cloud-controller-manager
$ oc get pods -n <hosted_control_plane_namespace> \ -l app=cloud-controller-managerCopy to Clipboard Copied! Toggle word wrap Toggle overflow
15.4.6. 호스트된 클러스터 PVC를 사용할 수 없음 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 클러스터의 PVC(영구 볼륨 클레임)를 사용할 수 없기 때문에 호스팅된 컨트롤 플레인이 완전히 온라인 상태가 아닌 경우 PVC 이벤트 및 세부 정보 및 구성 요소 로그를 확인합니다.
프로세스
- PVC와 연결된 이벤트 및 세부 정보를 찾아 발생하는 오류를 파악합니다.
PVC가 Pod에 연결하지 못하는 경우 호스트 클러스터 내에서 kubevirt-csi-node
데몬 세트구성 요소의 로그를 확인하여 문제를 추가로 조사합니다. 각 노드의 kubevirt-csi-node Pod를 식별하려면 다음 명령을 입력합니다.oc get pods -n openshift-cluster-csi-drivers -o wide \ -l app=kubevirt-csi-driver
$ oc get pods -n openshift-cluster-csi-drivers -o wide \ -l app=kubevirt-csi-driverCopy to Clipboard Copied! Toggle word wrap Toggle overflow PVC가 PV(영구 볼륨)에 바인딩할 수 없는 경우 호스팅된 컨트롤 플레인 네임스페이스 내에서 kubevirt-csi-controller 구성 요소의 로그를 확인합니다. 호스팅된 컨트롤 플레인 네임스페이스 내에서 kubevirt-csi-controller Pod를 식별하려면 다음 명령을 입력합니다.
oc get pods -n <hcp namespace> -l app=kubevirt-csi-driver
$ oc get pods -n <hcp namespace> -l app=kubevirt-csi-driverCopy to Clipboard Copied! Toggle word wrap Toggle overflow
15.4.7. VM 노드가 클러스터에 올바르게 참여하지 않음 링크 복사링크가 클립보드에 복사되었습니다!
VM 노드가 클러스터에 올바르게 참여하지 않기 때문에 호스팅된 컨트롤 플레인이 완전히 온라인 상태가 아닌 경우 VM 콘솔 로그에 액세스합니다.
프로세스
- VM 콘솔 로그에 액세스하려면 OpenShift Virtualization Hosted Control Plane 클러스터의 VM 부분에 대한 직렬 콘솔 로그를 가져오는 방법의 단계를 완료합니다.
15.4.8. RHCOS 이미지 미러링 실패 링크 복사링크가 클립보드에 복사되었습니다!
연결이 끊긴 환경의 OpenShift Virtualization의 호스팅된 컨트롤 플레인의 경우 oc-mirror 가 RHCOS(Red Hat Enterprise Linux CoreOS) 이미지를 내부 레지스트리에 자동으로 미러링하지 못합니다. 첫 번째 호스트 클러스터를 생성할 때 내부 레지스트리에서 부팅 이미지를 사용할 수 없기 때문에 Kubevirt 가상 머신이 부팅되지 않습니다.
이 문제를 해결하려면 RHCOS 이미지를 내부 레지스트리에 수동으로 미러링합니다.
프로세스
다음 명령을 실행하여 내부 레지스트리 이름을 가져옵니다.
oc get imagecontentsourcepolicy -o json \ | jq -r '.items[].spec.repositoryDigestMirrors[0].mirrors[0]'
$ oc get imagecontentsourcepolicy -o json \ | jq -r '.items[].spec.repositoryDigestMirrors[0].mirrors[0]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 페이로드 이미지를 가져옵니다.
oc get clusterversion version -ojsonpath='{.status.desired.image}'$ oc get clusterversion version -ojsonpath='{.status.desired.image}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 호스팅된 클러스터의 페이로드 이미지에서 부팅 이미지가 포함된
0000_50_installer_coreos-bootimages.yaml파일을 추출합니다. <payload_image>를 페이로드 이미지 이름으로 바꿉니다. 다음 명령을 실행합니다.oc image extract \ --file /release-manifests/0000_50_installer_coreos-bootimages.yaml \ <payload_image> --confirm
$ oc image extract \ --file /release-manifests/0000_50_installer_coreos-bootimages.yaml \ <payload_image> --confirmCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 RHCOS 이미지를 가져옵니다.
cat 0000_50_installer_coreos-bootimages.yaml | yq -r .data.stream \ | jq -r '.architectures.x86_64.images.kubevirt."digest-ref"'
$ cat 0000_50_installer_coreos-bootimages.yaml | yq -r .data.stream \ | jq -r '.architectures.x86_64.images.kubevirt."digest-ref"'Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHCOS 이미지를 내부 레지스트리에 미러링합니다. <
rhcos_image>를 RHCOS 이미지로 바꿉니다(예:quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:d9643ead36b1c026be664c9c65c11433c6cdffd93ba229141d134a4a694 . <internal_registry>를 내부 레지스트리의 이름으로 바꿉니다(예:virthost.ostest.test.metalkube.org:5000/localimages/ocp-v4.0-art-dev). 다음 명령을 실행합니다.oc image mirror <rhcos_image> <internal_registry>
$ oc image mirror <rhcos_image> <internal_registry>Copy to Clipboard Copied! Toggle word wrap Toggle overflow ImageDigestMirrorSet오브젝트를 정의하는rhcos-boot-kubevirt.yaml이라는 YAML 파일을 생성합니다. 다음 예제 구성을 참조하십시오.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
rhcos-boot-kubevirt.yaml파일을 적용하여ImageDigestMirrorSet오브젝트를 생성합니다.oc apply -f rhcos-boot-kubevirt.yaml
$ oc apply -f rhcos-boot-kubevirt.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
15.4.9. 베어 메탈이 아닌 클러스터를 late binding 풀로 반환 링크 복사링크가 클립보드에 복사되었습니다!
BareMetalHosts 없이 늦은 바인딩 관리 클러스터를 사용하는 경우 늦은 바인딩 클러스터를 삭제하고 노드를 Discovery ISO로 돌아가려면 추가 수동 단계를 완료해야 합니다.
BareMetalHosts 가 없는 최신 바인딩 관리 클러스터의 경우 클러스터 정보를 제거해도 모든 노드를 Discovery ISO로 자동으로 반환하지는 않습니다.
프로세스
늦은 바인딩으로 베어 메탈 노드가 아닌 노드를 바인딩 해제하려면 다음 단계를 완료하십시오.
- 클러스터 정보를 제거합니다. 자세한 내용은 관리에서 클러스터 제거를 참조하십시오.
- 루트 디스크를 정리합니다.
- Discovery ISO를 사용하여 수동으로 재부팅합니다.
15.5. 베어 메탈에서 호스트 클러스터 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
다음 정보는 베어 메탈에서 호스팅되는 컨트롤 플레인 문제 해결에 적용됩니다.
15.5.1. 베어 메탈의 호스팅된 컨트롤 플레인에 노드를 추가하지 못했습니다 링크 복사링크가 클립보드에 복사되었습니다!
지원 설치 관리자를 사용하여 프로비저닝된 노드로 호스팅되는 컨트롤 플레인 클러스터를 확장할 때 호스트는 포트 22642가 포함된 URL로 Ignition을 가져오지 못합니다. 해당 URL은 호스팅된 컨트롤 플레인에서 유효하지 않으며 클러스터에 문제가 있음을 나타냅니다.
프로세스
문제를 확인하려면 assisted-service 로그를 검토합니다.
oc logs -n multicluster-engine <assisted_service_pod_name>
$ oc logs -n multicluster-engine <assisted_service_pod_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 지원 서비스 Pod 이름을 지정합니다.
로그에서 다음 예와 유사한 오류를 찾습니다.
error="failed to get pull secret for update: invalid pull secret data in secret pull-secret"
error="failed to get pull secret for update: invalid pull secret data in secret pull-secret"Copy to Clipboard Copied! Toggle word wrap Toggle overflow pull secret must contain auth for \"registry.redhat.io\"
pull secret must contain auth for \"registry.redhat.io\"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 문제를 해결하려면 Kubernetes Operator 설명서의 다중 클러스터 엔진의 "네임스페이스에 풀 시크릿 추가"를 참조하십시오.
참고호스팅된 컨트롤 플레인을 사용하려면 독립 실행형 Operator 또는 Red Hat Advanced Cluster Management의 일부로 다중 클러스터 엔진 Operator가 설치되어 있어야 합니다. Operator에는 Red Hat Advanced Cluster Management와 밀접한 관계가 있으므로 Operator에 대한 문서가 해당 제품 설명서에 게시됩니다. Red Hat Advanced Cluster Management를 사용하지 않더라도 다중 클러스터 엔진 Operator를 포함하는 문서의 부분은 호스팅된 컨트롤 플레인과 관련이 있습니다.
15.6. 호스팅된 컨트롤 플레인 구성 요소 다시 시작 링크 복사링크가 클립보드에 복사되었습니다!
호스트된 컨트롤 플레인의 관리자인 경우 hypershift.openshift.io/restart-date 주석을 사용하여 특정 HostedCluster 리소스에 대한 모든 컨트롤 플레인 구성 요소를 다시 시작할 수 있습니다. 예를 들어 인증서 교체를 위해 컨트롤 플레인 구성 요소를 다시 시작해야 할 수 있습니다.
프로세스
컨트롤 플레인을 다시 시작하려면 다음 명령을 입력하여
HostedCluster리소스에 주석을 답니다.oc annotate hostedcluster \ -n <hosted_cluster_namespace> \ <hosted_cluster_name> \ hypershift.openshift.io/restart-date=$(date --iso-8601=seconds)
$ oc annotate hostedcluster \ -n <hosted_cluster_namespace> \ <hosted_cluster_name> \ hypershift.openshift.io/restart-date=$(date --iso-8601=seconds)1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 주석 값이 변경될 때마다 컨트롤 플레인이 다시 시작됩니다.
date명령은 고유한 문자열의 소스로 사용됩니다. 주석은 타임스탬프가 아닌 문자열로 처리됩니다.
검증
컨트롤 플레인을 다시 시작한 후 다음 호스팅 컨트롤 플레인 구성 요소가 일반적으로 재시작됩니다.
다른 구성 요소에서 구현한 변경 사항의 측면 효과로 일부 추가 구성 요소가 다시 시작될 수 있습니다.
- catalog-operator
- certified-operators-catalog
- cluster-api
- cluster-autoscaler
- cluster-policy-controller
- cluster-version-operator
- community-operators-catalog
- control-plane-operator
- hosted-cluster-config-operator
- ignition-server
- ingress-operator
- konnectivity-agent
- konnectivity-server
- kube-apiserver
- kube-controller-manager
- kube-scheduler
- machine-approver
- oauth-openshift
- olm-operator
- openshift-apiserver
- openshift-controller-manager
- openshift-oauth-apiserver
- packageserver
- redhat-marketplace-catalog
- redhat-operators-catalog
15.7. 호스트 클러스터 및 호스팅된 컨트롤 플레인의 조정 일시 중지 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 인스턴스 관리자인 경우 호스트 클러스터 및 호스팅된 컨트롤 플레인의 조정을 일시 중지할 수 있습니다. etcd 데이터베이스를 백업 및 복원하거나 호스팅된 클러스터 또는 호스팅된 컨트롤 플레인 문제를 디버깅해야 하는 경우 조정을 일시 중지해야 할 수 있습니다.
프로세스
호스트 클러스터 및 호스팅된 컨트롤 플레인에 대한 조정을 일시 중지하려면
HostedCluster리소스의pausedUntil필드를 채웁니다.특정 시간까지 조정을 일시 중지하려면 다음 명령을 입력합니다.
oc patch -n <hosted_cluster_namespace> \ hostedclusters/<hosted_cluster_name> \ -p '{"spec":{"pausedUntil":"<timestamp>"}}' \ --type=merge$ oc patch -n <hosted_cluster_namespace> \ hostedclusters/<hosted_cluster_name> \ -p '{"spec":{"pausedUntil":"<timestamp>"}}' \ --type=merge1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- RFC339 형식으로 타임스탬프를 지정합니다(예:
2024-03-03T03:28:48Z). 지정된 시간이 전달될 때까지 조정이 일시 중지됩니다.
조정을 무기한 일시 중지하려면 다음 명령을 입력합니다.
oc patch -n <hosted_cluster_namespace> \ hostedclusters/<hosted_cluster_name> \ -p '{"spec":{"pausedUntil":"true"}}' \ --type=merge$ oc patch -n <hosted_cluster_namespace> \ hostedclusters/<hosted_cluster_name> \ -p '{"spec":{"pausedUntil":"true"}}' \ --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow HostedCluster리소스에서 필드를 제거할 때까지 조정이 일시 중지됩니다.HostedCluster리소스에 대한 일시 중지 조정 필드가 채워지면 관련HostedControlPlane리소스에 필드가 자동으로 추가됩니다.
pausedUntil필드를 제거하려면 다음 패치 명령을 입력합니다.oc patch -n <hosted_cluster_namespace> \ hostedclusters/<hosted_cluster_name> \ -p '{"spec":{"pausedUntil":null}}' \ --type=merge$ oc patch -n <hosted_cluster_namespace> \ hostedclusters/<hosted_cluster_name> \ -p '{"spec":{"pausedUntil":null}}' \ --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
15.8. 데이터 플레인을 0으로 축소 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 컨트롤 플레인을 사용하지 않는 경우 리소스 및 비용을 절약하기 위해 데이터 플레인을 0으로 축소할 수 있습니다.
데이터 플레인을 0으로 축소할 준비가 되었는지 확인합니다. 작업자 노드의 워크로드는 축소 후 사라집니다.
프로세스
다음 명령을 실행하여 호스팅 클러스터에 액세스하도록
kubeconfig파일을 설정합니다.export KUBECONFIG=<install_directory>/auth/kubeconfig
$ export KUBECONFIG=<install_directory>/auth/kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 호스팅된 클러스터에 연결된
NodePool리소스의 이름을 가져옵니다.oc get nodepool --namespace <hosted_cluster_namespace>
$ oc get nodepool --namespace <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 선택 사항: Pod가 드레이닝되지 않도록 다음 명령을 실행하여
NodePool리소스에nodeDrainTimeout필드를 추가합니다.oc edit nodepool <nodepool_name> --namespace <hosted_cluster_namespace>
$ oc edit nodepool <nodepool_name> --namespace <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고노드 드레이닝 프로세스가 일정 기간 동안 계속될 수 있도록
nodeDrainTimeout필드의 값을 적절하게 설정할 수 있습니다(예:nodeDrainTimeout: 1m).다음 명령을 실행하여 호스팅된 클러스터에 연결된
NodePool리소스를 축소합니다.oc scale nodepool/<nodepool_name> --namespace <hosted_cluster_namespace> \ --replicas=0
$ oc scale nodepool/<nodepool_name> --namespace <hosted_cluster_namespace> \ --replicas=0Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고데이터 계획을 0으로 축소한 후 컨트롤 플레인의 일부 Pod는
Pending상태를 유지하고 호스팅된 컨트롤 플레인은 계속 실행 중입니다. 필요한 경우NodePool리소스를 확장할 수 있습니다.선택 사항: 다음 명령을 실행하여 호스팅된 클러스터에 연결된
NodePool리소스를 확장합니다.oc scale nodepool/<nodepool_name> --namespace <hosted_cluster_namespace> --replicas=1
$ oc scale nodepool/<nodepool_name> --namespace <hosted_cluster_namespace> --replicas=1Copy to Clipboard Copied! Toggle word wrap Toggle overflow NodePool리소스를 다시 확장한 후NodePool리소스가Ready상태에서 사용 가능하게 될 때까지 몇 분 정도 기다립니다.
검증
다음 명령을 실행하여
nodeDrainTimeout필드의 값이0s보다 큰지 확인합니다.oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -ojsonpath='{.spec.nodeDrainTimeout}'$ oc get nodepool -n <hosted_cluster_namespace> <nodepool_name> -ojsonpath='{.spec.nodeDrainTimeout}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.9. 클러스터에 참여하지 않는 에이전트 서비스 실패 및 에이전트 링크 복사링크가 클립보드에 복사되었습니다!
부팅 아티팩트를 사용하여 시스템을 부팅한 후 에이전트가 클러스터에 참여하지 못하는 경우도 있습니다. agent.service 로그에 다음 오류가 있는지 확인하여 이 문제를 확인할 수 있습니다.
Error: copying system image from manifest list: Source image rejected: A signature was required, but no signature exists
Error: copying system image from manifest list: Source image rejected: A signature was required, but no signature exists
이 문제는 서명이 없는 경우 이미지 서명 확인이 실패하기 때문에 발생합니다. 이 문제를 해결하려면 컨테이너 정책을 수정하여 서명 확인을 비활성화할 수 있습니다.
프로세스
-
InfraEnv매니페스트에ignitionConfigOverride필드를 추가하여/etc/containers/policy.json파일을 재정의합니다. 이렇게 하면 컨테이너 이미지에 대한 서명 확인이 비활성화됩니다. ignitionConfigOverride의 base64로 인코딩된 콘텐츠를 이미지 레지스트리에 따라 필요한/etc/containers/policy.json구성으로 교체합니다.예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ignitionConfigOverride를 사용한 InfraEnv 매니페스트 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow
16장. 호스트된 클러스터 삭제 링크 복사링크가 클립보드에 복사되었습니다!
16.1. AWS에서 호스트된 클러스터 삭제 링크 복사링크가 클립보드에 복사되었습니다!
CLI(명령줄 인터페이스)를 사용하여 AWS(Amazon Web Services)에서 호스트 클러스터 및 관리되는 클러스터 리소스를 삭제할 수 있습니다.
16.1.1. CLI를 사용하여 AWS에서 호스트된 클러스터 제거 링크 복사링크가 클립보드에 복사되었습니다!
CLI(명령줄 인터페이스)를 사용하여 AWS(Amazon Web Services)에서 호스팅된 클러스터를 제거할 수 있습니다.
프로세스
다음 명령을 실행하여 다중 클러스터 엔진 Operator에서 관리 클러스터 리소스를 삭제합니다.
oc delete managedcluster <hosted_cluster_name>
$ oc delete managedcluster <hosted_cluster_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;hosted_cluster_name>을 클러스터 이름으로 바꿉니다.
다음 명령을 실행하여 호스팅된 클러스터 및 해당 백엔드 리소스를 삭제합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 중요AWS STS(Security Token Service)에 대한 세션 토큰이 만료된 경우 다음 명령을 실행하여
sts-creds.json이라는 JSON 파일에서 STS 인증 정보를 검색합니다.aws sts get-session-token --output json > sts-creds.json
$ aws sts get-session-token --output json > sts-creds.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow
16.2. 베어 메탈에서 호스트 클러스터 삭제 링크 복사링크가 클립보드에 복사되었습니다!
CLI(명령줄 인터페이스) 또는 다중 클러스터 엔진 Operator 웹 콘솔을 사용하여 베어 메탈에서 호스트된 클러스터를 삭제할 수 있습니다.
16.2.1. CLI를 사용하여 베어 메탈에서 호스트 클러스터 제거 링크 복사링크가 클립보드에 복사되었습니다!
CLI(명령줄 인터페이스)를 사용하여 호스트된 클러스터를 생성한 경우 명령을 실행하여 호스트 클러스터 및 해당 백엔드 리소스를 제거할 수 있습니다.
프로세스
다음 명령을 실행하여 호스팅된 클러스터 및 해당 백엔드 리소스를 삭제합니다.
oc delete -f <hosted_cluster_config>.yaml
$ oc delete -f <hosted_cluster_config>.yaml1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 호스팅 클러스터를 생성할 때 렌더링된 구성 YAML 파일의 이름을 지정합니다.
참고구성 파일에
--render및--render-sensitive플래그를 지정하지 않고 호스팅 클러스터를 생성한 경우 백엔드 리소스를 수동으로 제거해야 합니다.
16.2.2. 웹 콘솔을 사용하여 베어 메탈에서 호스트 클러스터 제거 링크 복사링크가 클립보드에 복사되었습니다!
다중 클러스터 엔진 Operator 웹 콘솔을 사용하여 베어 메탈에서 호스팅된 클러스터를 제거할 수 있습니다.
프로세스
- 콘솔에서 인프라 → 클러스터를 클릭합니다.
- 클러스터 페이지에서 삭제할 클러스터를 선택합니다.
- 작업 메뉴에서 클러스터 삭제 를 선택하여 클러스터를 제거합니다.
16.3. OpenShift Virtualization에서 호스트된 클러스터 삭제 링크 복사링크가 클립보드에 복사되었습니다!
CLI(명령줄 인터페이스)를 사용하여 OpenShift Virtualization에서 호스트 클러스터 및 관리되는 클러스터 리소스를 삭제할 수 있습니다.
16.3.1. CLI를 사용하여 OpenShift Virtualization에서 호스트된 클러스터 제거 링크 복사링크가 클립보드에 복사되었습니다!
CLI(명령줄 인터페이스)를 사용하여 OpenShift Virtualization에서 호스트 클러스터 및 관리되는 클러스터 리소스를 제거할 수 있습니다.
프로세스
다음 명령을 실행하여 다중 클러스터 엔진 Operator에서 관리 클러스터 리소스를 삭제합니다.
oc delete managedcluster <hosted_cluster_name>
$ oc delete managedcluster <hosted_cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 호스팅된 클러스터 및 해당 백엔드 리소스를 삭제합니다.
hcp destroy cluster kubevirt --name <hosted_cluster_name>
$ hcp destroy cluster kubevirt --name <hosted_cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
16.4. IBM Z에서 호스트된 클러스터 삭제 링크 복사링크가 클립보드에 복사되었습니다!
CLI(명령줄 인터페이스)를 사용하여 IBM Z 컴퓨팅 노드 및 관리되는 클러스터 리소스를 사용하여 x86 베어 메탈에서 호스팅 클러스터를 삭제할 수 있습니다.
16.4.1. IBM Z 컴퓨팅 노드를 사용하여 x86 베어 메탈에서 호스트 클러스터 제거 링크 복사링크가 클립보드에 복사되었습니다!
IBM Z® 컴퓨팅 노드가 있는 x86 베어 메탈에서 호스팅 클러스터 및 관리형 클러스터를 삭제하려면 CLI(명령줄 인터페이스)를 사용할 수 있습니다.
프로세스
다음 명령을 실행하여
NodePool오브젝트를0노드로 확장합니다.oc -n <hosted_cluster_namespace> scale nodepool <nodepool_name> \ --replicas 0
$ oc -n <hosted_cluster_namespace> scale nodepool <nodepool_name> \ --replicas 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow NodePool개체가0으로 확장되면 컴퓨팅 노드가 호스팅 클러스터에서 분리됩니다. OpenShift Container Platform 버전 4.17에서 이 기능은 KVM을 사용하는 IBM Z에만 적용됩니다. z/VM 및 LPAR의 경우 컴퓨팅 노드를 수동으로 삭제해야 합니다.컴퓨팅 노드를 클러스터에 다시 연결하려는 경우 원하는 컴퓨팅 노드 수를 사용하여
NodePool오브젝트를 확장할 수 있습니다. z/VM 및 LPAR이 에이전트를 재사용하려면Discovery이미지를 사용하여 해당 에이전트를 다시 생성해야 합니다.중요컴퓨팅 노드가 호스팅 클러스터에서 분리되지 않거나
Notready상태에 있는 경우 다음 명령을 실행하여 컴퓨팅 노드를 수동으로 삭제합니다.oc --kubeconfig <hosted_cluster_name>.kubeconfig delete \ node <compute_node_name>
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig delete \ node <compute_node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow PR/SM( Processor Resource/Systems Manager) 모드에서 OSA 네트워크 장치를 사용하는 경우 자동 확장이 지원되지 않습니다. 축소 프로세스 중 새 에이전트가 결합되므로 기존 에이전트를 수동으로 삭제하고 노드 풀을 확장해야 합니다.
다음 명령을 입력하여 컴퓨팅 노드의 상태를 확인합니다.
oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 컴퓨팅 노드가 호스팅 클러스터에서 분리되면 에이전트의 상태가
자동 할당으로 변경됩니다.다음 명령을 실행하여 클러스터에서 에이전트를 삭제합니다.
oc -n <hosted_control_plane_namespace> delete agent <agent_name>
$ oc -n <hosted_control_plane_namespace> delete agent <agent_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고클러스터에서 에이전트를 삭제한 후 에이전트로 생성한 가상 머신을 삭제할 수 있습니다.
다음 명령을 실행하여 호스트된 클러스터를 삭제합니다.
hcp destroy cluster agent --name <hosted_cluster_name> \ --namespace <hosted_cluster_namespace>
$ hcp destroy cluster agent --name <hosted_cluster_name> \ --namespace <hosted_cluster_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
16.5. IBM Power에서 호스트된 클러스터 삭제 링크 복사링크가 클립보드에 복사되었습니다!
CLI(명령줄 인터페이스)를 사용하여 IBM Power에서 호스팅된 클러스터를 삭제할 수 있습니다.
16.5.1. CLI를 사용하여 IBM Power에서 호스트된 클러스터 제거 링크 복사링크가 클립보드에 복사되었습니다!
IBM Power에서 호스팅된 클러스터를 삭제하려면 hcp CLI(명령줄 인터페이스)를 사용할 수 있습니다.
프로세스
다음 명령을 실행하여 호스트된 클러스터를 삭제합니다.
hcp destroy cluster agent --name=<hosted_cluster_name> \ --namespace=<hosted_cluster_namespace> \ --cluster-grace-period <duration>
$ hcp destroy cluster agent --name=<hosted_cluster_name> \1 --namespace=<hosted_cluster_namespace> \2 --cluster-grace-period <duration>3 Copy to Clipboard Copied! Toggle word wrap Toggle overflow
16.6. OpenStack에서 호스팅된 컨트롤 플레인 삭제 링크 복사링크가 클립보드에 복사되었습니다!
16.6.1. CLI를 사용하여 호스트된 클러스터 제거 링크 복사링크가 클립보드에 복사되었습니다!
hcp CLI 툴을 사용하여 RHOSP(Red Hat OpenStack Platform)에서 호스트 클러스터 및 관련 리소스를 삭제할 수 있습니다.
사전 요구 사항
-
호스팅된 컨트롤 플레인 CLI를 설치했습니다.
hcp.
프로세스
클러스터 및 관련 리소스를 삭제하려면 다음 명령을 실행합니다.
hcp destroy cluster openstack --name=<cluster_name>
$ hcp destroy cluster openstack --name=<cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
<cluster_name>- 호스트 클러스터의 이름입니다.
프로세스가 완료되면 클러스터와 연결된 모든 리소스가 삭제됩니다.
16.7. 베어 메탈이 아닌 에이전트 시스템에서 호스트 클러스터 제거 링크 복사링크가 클립보드에 복사되었습니다!
CLI(명령줄 인터페이스) 또는 다중 클러스터 엔진 Operator 웹 콘솔을 사용하여 베어 메탈이 아닌 에이전트 머신에서 호스트된 클러스터를 제거할 수 있습니다.
16.7.1. 베어 메탈이 아닌 에이전트 시스템에서 호스트 클러스터 제거 링크 복사링크가 클립보드에 복사되었습니다!
hcp CLI(명령줄 인터페이스)를 사용하여 비bare-metal 에이전트 시스템에서 호스팅된 클러스터를 제거할 수 있습니다.
프로세스
다음 명령을 실행하여 호스팅된 클러스터 및 해당 백엔드 리소스를 삭제합니다.
hcp destroy cluster agent --name <hosted_cluster_name>
$ hcp destroy cluster agent --name <hosted_cluster_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;hosted_cluster_name>을 호스트된 클러스터 이름으로 바꿉니다.
16.7.2. 웹 콘솔을 사용하여 베어 메탈이 아닌 에이전트 시스템에서 호스트 클러스터 제거 링크 복사링크가 클립보드에 복사되었습니다!
다중 클러스터 엔진 Operator 웹 콘솔을 사용하여 베어 메탈이 아닌 에이전트 머신에서 호스트된 클러스터를 제거할 수 있습니다.
프로세스
- 콘솔에서 인프라 → 클러스터를 클릭합니다.
- 클러스터 페이지에서 삭제할 클러스터를 선택합니다.
- 작업 메뉴에서 클러스터 삭제 를 선택하여 클러스터를 제거합니다.
17장. 수동으로 호스트 클러스터 가져오기 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 컨트롤 플레인을 사용할 수 있게 되면 호스팅된 클러스터는 멀티 클러스터 엔진 Operator로 자동으로 가져옵니다.
17.1. 가져온 호스팅 클러스터를 관리하는 데 대한 제한 사항 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 클러스터는 독립 실행형 OpenShift Container Platform 또는 타사 클러스터와 달리 Kubernetes Operator의 로컬 멀티 클러스터 엔진으로 자동으로 가져옵니다. 호스팅된 클러스터는 에이전트에서 클러스터의 리소스를 사용하지 않도록 호스팅 모드에서 일부 에이전트를 실행합니다.
호스팅된 클러스터를 자동으로 가져오는 경우 관리 클러스터에서 HostedCluster 리소스를 사용하여 호스팅된 클러스터에서 노드 풀과 컨트롤 플레인을 업데이트할 수 있습니다. 노드 풀과 컨트롤 플레인을 업데이트하려면 "호스트 클러스터에서 노드 풀 업그레이드" 및 "호스팅 클러스터에서 컨트롤 플레인 업그레이드"를 참조하십시오.
RHACM(Red Hat Advanced Cluster Management)을 사용하여 호스팅된 클러스터를 로컬 다중 클러스터 엔진 Operator 이외의 위치로 가져올 수 있습니다. 자세한 내용은 "Red Hat Advanced Cluster Management에서 Kubernetes Operator 호스팅 클러스터용 다중 클러스터 엔진 검색"을 참조하십시오.
이 토폴로지에서는 클러스터가 호스팅되는 Kubernetes Operator에 대한 명령줄 인터페이스 또는 로컬 다중 클러스터 엔진의 콘솔을 사용하여 호스팅되는 클러스터를 업데이트해야 합니다. RHACM 허브 클러스터를 통해 호스팅된 클러스터를 업데이트할 수 없습니다.
17.3. 수동으로 호스트 클러스터 가져오기 링크 복사링크가 클립보드에 복사되었습니다!
호스트 클러스터를 수동으로 가져오려면 다음 단계를 완료합니다.
프로세스
- 콘솔에서 인프라 → 클러스터를 클릭하고 가져올 호스팅 클러스터를 선택합니다.
호스팅 클러스터 가져오기 를 클릭합니다.
참고검색된 호스트 클러스터의 경우 콘솔에서 가져올 수도 있지만 클러스터는 업그레이드 가능한 상태여야 합니다. 호스팅된 컨트롤 플레인을 사용할 수 없기 때문에 호스팅된 클러스터가 업그레이드 가능한 상태가 아닌 경우 클러스터의 가져오기가 비활성화됩니다. 가져오기 를 클릭하여 프로세스를 시작합니다. 클러스터가 업데이트를 수신하는 동안 상태가
Importing된 다음Ready로 변경됩니다.
17.4. AWS에서 수동으로 호스트 클러스터 가져오기 링크 복사링크가 클립보드에 복사되었습니다!
명령줄 인터페이스를 사용하여 AWS(Amazon Web Services)에서 호스팅 클러스터를 가져올 수도 있습니다.
프로세스
다음 샘플 YAML 파일을 사용하여
ManagedCluster리소스를 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;hosted_cluster_name>을 호스트된 클러스터 이름으로 바꿉니다.
다음 명령을 실행하여 리소스를 적용합니다.
oc apply -f <file_name>
$ oc apply -f <file_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;file_name>을 이전 단계에서 생성한 YAML 파일 이름으로 바꿉니다.
Red Hat Advanced Cluster Management를 설치한 경우 다음 샘플 YAML 파일을 사용하여
KlusterletAddonConfig리소스를 생성합니다. 다중 클러스터 엔진 Operator만 설치한 경우 다음 단계를 건너뜁니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 리소스를 적용합니다.
oc apply -f <file_name>
$ oc apply -f <file_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;file_name>을 이전 단계에서 생성한 YAML 파일 이름으로 바꿉니다.
가져오기 프로세스가 완료되면 콘솔에 호스팅된 클러스터가 표시됩니다. 다음 명령을 실행하여 호스팅 클러스터의 상태를 확인할 수도 있습니다.
oc get managedcluster <hosted_cluster_name>
$ oc get managedcluster <hosted_cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.5. 멀티 클러스터 엔진 Operator로 호스트 클러스터 자동 가져오기 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
컨트롤 플레인을 사용할 수 있게 되면 호스팅된 클러스터는 멀티 클러스터 엔진 Operator로 자동으로 가져옵니다. 필요한 경우 호스팅 클러스터의 자동 가져오기를 비활성화할 수 있습니다.
자동 가져오기를 비활성화하더라도 이전에 가져온 호스팅 클러스터는 영향을 받지 않습니다. 다중 클러스터 엔진 Operator 2.5로 업그레이드하고 자동 가져오기가 활성화되면 컨트롤 플레인을 사용할 수 있는 경우 가져오지 않은 모든 호스팅 클러스터를 자동으로 가져옵니다.
Red Hat Advanced Cluster Management가 설치된 경우 모든 Red Hat Advanced Cluster Management 애드온도 활성화됩니다.
자동 가져오기가 비활성화되면 새로 생성된 호스팅 클러스터만 자동으로 가져오지 않습니다. 이미 가져온 호스트 클러스터는 영향을 받지 않습니다. 콘솔을 사용하거나 ManagedCluster 및 KlusterletAddonConfig 사용자 정의 리소스를 생성하여 클러스터를 수동으로 가져올 수 있습니다.
프로세스
호스트 클러스터의 자동 가져오기를 비활성화하려면 다음 단계를 완료합니다.
허브 클러스터에서 다음 명령을 입력하여 다중 클러스터 엔진 Operator가 설치된 네임스페이스의
AddonDeploymentConfig리소스에 있는hypershift-addon-deploy-config사양을 엽니다.oc edit addondeploymentconfig hypershift-addon-deploy-config \ -n multicluster-engine
$ oc edit addondeploymentconfig hypershift-addon-deploy-config \ -n multicluster-engineCopy to Clipboard Copied! Toggle word wrap Toggle overflow spec.customizedVariables섹션에서 다음 예와 같이 값이"true"인autoImportDisabled변수를 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
자동 가져오기를 다시 활성화하려면
autoImportDisabled변수 값을"false"로 설정하거나AddonDeploymentConfig리소스에서 변수를 제거합니다.
Legal Notice
링크 복사링크가 클립보드에 복사되었습니다!
Copyright © 2025 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 Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
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.