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. 호스트 클러스터에서 우선순위 확장기 설정

이제 호스트 클러스터에서 우선 순위 확장기를 구성하여 우선 순위가 낮은 머신보다 우선 순위가 높은 머신을 생성할 수 있습니다. 자세한 내용은 호스팅 클러스터에서 우선순위 확장기 설정을 참조하십시오.

이 릴리스에서 연결이 끊긴 환경에서 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 액세스에 영향을 미칠 수 있는 중요한 유지 관리 작업을 수행하지 못했습니다.

    이번 릴리스에서는 HostedCluster API의 버전 기록 필드에서 최대 항목 검증 제약 조건이 제거되어 검증 오류를 트리거하지 않고 기록이 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
        Copy to Clipboard Toggle word wrap
      • 다음 명령을 실행하여 0 노드가 클러스터에 있는지 확인합니다.

        $ oc get nodes --kubeconfig
        Copy to Clipboard Toggle word wrap
      • 다음 명령을 실행하여 0 에이전트가 클러스터에 바인딩된 것으로 보고되었는지 확인합니다.

        $ oc get agents -A
        Copy to Clipboard Toggle word wrap
  • 듀얼 스택 네트워크를 사용하는 환경에서 호스팅 클러스터를 생성할 때 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의 노드 풀에서 컨트롤 플레인을 실행해야 합니다.
Expand
표 1.1. 호스트된 컨트롤 플레인 GA 및 TP 추적기
기능4.184.194.20

베어 메탈이 아닌 에이전트 시스템을 사용하는 OpenShift Container Platform용 호스팅 컨트롤 플레인

기술 프리뷰

기술 프리뷰

기술 프리뷰

RHOSP의 OpenShift Container Platform용 호스팅 컨트롤 플레인

개발자 프리뷰

기술 프리뷰

기술 프리뷰

사용자 정의 테인트 및 톨러레이션

기술 프리뷰

기술 프리뷰

기술 프리뷰

OpenShift Virtualization을 위해 호스팅된 컨트롤 플레인의 NVIDIA GPU 장치

기술 프리뷰

기술 프리뷰

기술 프리뷰

연결이 끊긴 환경에서 IBM Z에서 호스팅되는 컨트롤 플레인

기술 프리뷰

기술 프리뷰

일반적으로 사용 가능

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2025 Red Hat